AML Transaction Monitoring in 2026: What the Regulations Actually Require

Key highlights

• Volume-threshold rules are not an AML transaction monitoring program in 2026. Regulators expect named typology coverage, alerts linked to verified identity, documented triage, and reproducible audit trails.
• The TD Bank, Starling, Monzo, and Revolut enforcement actions all turned on financial crime controls that did not keep up with the business: transaction monitoring that missed activity, sanctions screening that ran against part of the list, and onboarding that let high-risk customers through.
• Documentation is structural. Every alert closure and every SAR-filing-or-not decision must carry a reasoned basis the regulator can audit later.
• A 30-day-plus alert backlog is the single best leading indicator of audit failure, because alerts age past the SAR filing window and closure notes get compressed under time pressure.
• Joining alerts to the verified identity layer is the architectural inversion that catches mule accounts at onboarding rather than post-facto, lifting precision to roughly 22%, against the 5 to 10% implied by the 90 to 95% false-positive rates commonly reported for rules-based monitoring.
• Audit-ready programs build six primitives: a documented typology library, identity-linked alerts, risk-tiered customers, per-decision triage records, a SAR clock pipeline, and an independent audit cadence.

AML transaction monitoring is the continuous, risk-based, reproducible surveillance of customer transactions for named money-laundering typologies, with every alert linked to a verified identity and documented for audit. At the regulatory floor it is not point-in-time, not uniform, and not improvised. The programs writing seven-figure cheques to FinCEN, the FCA, and BaFin built rules and alerts but skipped identity linkage and the reproducible audit trail.

Financial institutions filed roughly 4.7 million Suspicious Activity Reports with FinCEN in fiscal year 2024. Most fintechs and banks monitor for volume thresholds and call it an AML transaction monitoring program. That is not enough in 2026. Regulators expect named typology coverage, alerts linked to verified identity, documented triage, and reproducible audit trails. The TD Bank USD 1.3 billion FinCEN penalty (October 2024), the Starling GBP 29 million FCA fine (October 2024), and the Monzo GBP 21 million FCA fine (July 2025) all turned on financial crime control gaps that look the same when the regulator opens the case file. This piece is what your CCO, your VP of risk, and your DPO need to read together.

Why is monitoring for volume thresholds not an AML transaction monitoring program?

The line most fintechs cross in their second year of operation is the line where AML transaction monitoring stops being a checkbox and starts being a regulator-readable artefact. Most fintech compliance teams, when audited honestly, are running rules that look like "alert when a transaction exceeds USD 10,000" and "alert when daily aggregate exceeds USD 50,000." Those are volume-threshold rules. They are necessary. They are not sufficient. They have not been sufficient since 4AMLD took effect in 2017.

The regulations expect AML transaction monitoring to do four distinct things at once. Surveil for named typologies (structuring, layering, mule activity, terrorist financing, sanctions evasion, trade-based laundering). Link every alert to a verified identity record so that a SAR filing has a real person attached to it. Triage alerts on a documented basis with reproducible criteria. Produce an audit trail that a regulator can replay months or years later. The fintechs that built only the first half (rules and alerts) and skipped the second half (identity linkage and audit trail) are the ones currently writing seven-figure cheques to FinCEN, the FCA, and BaFin.

This piece is the operating-level walkthrough for a compliance manager building or rebuilding an AML transaction monitoring program in 2026. What the regulations actually require, where the regulator audits land in practice, what the maturity gaps look like, and how to close them with an AML transaction monitoring stack that integrates with the KYC layer rather than sitting next to it.

What does AML transaction monitoring actually require?

AML transaction monitoring at the regulatory floor is continuous (not point-in-time), risk-based (not uniform), and reproducible (not improvised). Three distinctions are doing real work in 2026.

Real-time vs batch

Real-time monitoring scores a transaction at authorisation time and can block, hold, or flag before settlement. Batch monitoring runs end-of-day rules across the day's flows and flags retrospectively. Real-time is now table-stakes for instant payments (FedNow, SEPA Instant, UPI, Pix) where settlement happens in seconds and post-facto blocking is impossible. Batch survives only for slower rails (ACH, wire, card) where chargebacks and clawbacks are still feasible. Most modern AML transaction monitoring stacks run a hybrid: real-time scoring for the cliff-edge rules (sanctioned counterparty, structuring at deposit, mule signatures), batch reconciliation for pattern-based rules (peeling chains, velocity over a window, cross-product behaviour).

For exchanges building the wider monitoring posture, see our AML strategy for crypto exchanges.

Rule-based vs ML-based

Rule-based monitoring is deterministic. Conditions are written as predicates ("if transaction > X and counterparty in country Y and customer KYC tier < Z, alert"). Auditable, explainable, and the regulator's preferred starting point. ML-based monitoring uses anomaly detection or supervised classifiers to score transactions against a learned model of normal customer behaviour. Strong on novel typology detection and on noise reduction, but the explainability burden is real: regulators want to know why a model fired, what features mattered, and whether a human reviewed the output. Most programs in 2026 run both, with rule-based logic for the legally mandated typologies and ML scoring for the long-tail behavioural anomalies. Pure ML programs without rule-based backstops are a regulator-relations red flag.

SAR filing triggers

A SAR (Suspicious Activity Report in the US, STR equivalent elsewhere) is the regulatory output. Filing thresholds and timing are jurisdiction-specific. FinCEN requires SAR filing within 30 calendar days of detection (60 if no suspect identified). In the UK, the Proceeds of Crime Act 2002 requires disclosure as soon as practicable, through the National Crime Agency's SAR Portal (which replaced SAR Online in March 2024). In the EU, obliged entities report to their national FIU promptly, under national law transposing the AML Directive today and under Article 69 of the AML Regulation (EU) 2024/1624 from 10 July 2027. Most failures the regulator finds are not "you should have filed and did not." They are "you filed late, you filed without sufficient detail, or you closed the alert without filing and your documentation does not justify the close."

For the deeper SAR-filing operating model and the FATF Recommendation 20 framing, see our automated compliance reporting piece.

How do AML transaction monitoring requirements differ by jurisdiction?

The regulations rhyme but they do not match line for line. AML transaction monitoring programs that pass a US audit can fail an EU audit on documentation depth, and vice versa. Three jurisdictions matter most for fintechs and banks operating cross-border in 2026.

United States: FinCEN and the Bank Secrecy Act

The Bank Secrecy Act (BSA) is the foundational AML transaction monitoring statute in the US, with FinCEN as the primary supervisor. Key obligations include Currency Transaction Reports (CTRs) for cash transactions above USD 10,000, SAR filing within 30 days of detection, customer identification (CIP), beneficial ownership verification, and a documented AML program with five pillars (designated AML compliance officer, training, independent audit, internal policies, and customer due diligence). The TD Bank USD 1.3 billion FinCEN penalty (October 2024, USD 3.1 billion combined) cited deficiencies across all five pillars and is, in FinCEN's words, the largest penalty against a depository institution in Treasury and FinCEN history. FinCEN's AML/CFT program rule is still a proposal: FinCEN first proposed it in July 2024 and published a new proposed rule on 10 April 2026 that would rebuild programs around a documented risk assessment process. Until a final rule is issued, the existing program requirements apply.

The five-pillar program model and its identity foundations are unpacked in our CIP compliance checklist.

European Union: 6AMLD, AMLA, and the new single rulebook

The Sixth Anti-Money Laundering Directive (6AMLD) took effect December 2020 and harmonised predicate offence definitions across member states. The 2024-2025 EU package added a single rulebook regulation (AMLR), a directive (AMLD6 in the new numbering), and the new Anti-Money Laundering Authority (AMLA) operational from 2025 in Frankfurt. The single rulebook, the AML Regulation (EU) 2024/1624, applies directly from 10 July 2027. In 2026, obliged entities, CASPs included, are supervised by their national competent authorities; AMLA selects about 40 entities for direct supervision in 2027 and starts supervising them in 2028, six months after it publishes the list. The Revolut Bank UAB EUR 3.5 million Bank of Lithuania penalty (April 2025) shows what a national supervisor already looks for: the Bank of Lithuania found shortcomings in how the bank monitored business relationships and transactions, so suspicious transactions were not always identified.

For how the EU single rulebook reshapes onboarding obligations, read our MiCA KYC requirements guide.

United Kingdom: FCA, Money Laundering Regulations 2017, and the SAR regime

The UK's Money Laundering Regulations 2017 (as amended) implement FATF Recommendations and require AML transaction monitoring proportionate to identified risk. The FCA Handbook (SYSC 6.1, SYSC 6.3) sets out systems and controls expectations. The National Crime Agency (NCA) administers the SAR regime through its SAR Portal, which replaced SAR Online in March 2024. The FCA's enforcement appetite escalated sharply through 2024-2025. The Starling Bank GBP 29 million Final Notice (October 2024) found that Starling's automated sanctions screening had, since 2017, checked customers against only part of the sanctions list, and that it had opened over 54,000 accounts for high-risk customers in breach of a requirement agreed with the FCA. The Monzo Bank GBP 21 million Final Notice (July 2025) found inadequate onboarding, customer risk assessment and transaction monitoring systems, and repeated breaches of a similar restriction on high-risk customers.

What are the most common AML transaction monitoring failures regulators have already cited?

Four failure modes recur in transaction monitoring programmes. Each one is preventable with AML transaction monitoring software that builds the audit trail as the side effect of the workflow rather than as an after-the-fact reconstruction.

Threshold-only rules with no typology coverage

The fintech that runs "alert when transaction > USD 10,000" without rules for structuring (multiple sub-threshold transactions in a 24-hour window), layering (multiple intermediate accounts before a final beneficiary), mule indicators (newly verified account receiving and immediately forwarding), or peeling chains is monitoring volume, not laundering. The regulator's first audit question is "show me your typology coverage." A list of named typologies with the rule logic that detects each is the right answer. "We monitor for unusual activity" is not.

Alerts not linked to verified identity

Monitoring that fires alerts on account IDs without joining to the underlying KYC record is the architecture failure that lets mule networks scale. Block paid USD 80 million to 48 state regulators over Cash App's BSA/AML program (January 2025) and a further USD 40 million to NYDFS (April 2025), whose findings included customer due diligence gaps; the Robinhood Crypto USD 30 million NYDFS penalty (August 2022) also cited anti-money laundering program failures. The fix is architectural: alerts must carry the verified identity attestation, the KYC tier, and the perpetual KYC re-screening status at the moment of the alert. See our perpetual KYC piece for the deeper continuous-CDD argument.

The mechanics of beating KYC with mule accounts are covered in our piece on synthetic identity fraud.

No documentation of alert triage or alert closure

Most monitoring tools generate more alerts than analysts can review. Backlogs build. Alerts get closed in batches with one-line notes ("reviewed, no action"). When the regulator pulls the case file 18 months later, the closure rationale does not reproduce. FinCEN's TD Bank release notes that the bank allowed significant backlogs of potentially suspicious activity to persist. Supervisors treat the documentation requirement as structural, not stylistic. AML transaction monitoring software that does not write a structured triage record (analyst, time, predicate state, closure reason, escalation path) for every alert is selling a queueing system, not compliance.

Alert backlogs as a leading indicator of program failure

A 30-day-plus alert backlog is the single best leading indicator that a program is going to fail an audit. Backlogs mean alerts age beyond the SAR filing window. They mean closure documentation gets compressed under time pressure. They mean SARs get filed late or not at all. NYDFS's April 2025 action against Block found that rapid growth had produced a severe transaction alert backlog that the firm left unaddressed for a significant period. The right metric to instrument: median and 95th-percentile alert age, broken down by typology and by analyst.

How do you build an AML transaction monitoring program that survives an audit?

The audit-survival pattern across all three jurisdictions converges on the same six elements. AML transaction monitoring software that builds these as primitives rather than as configurations is what an auditable program looks like in 2026.

1. Documented typology library. Named typologies with rule logic, source citation (FATF guidance, FinCEN advisory, FCA thematic review), version history, and last-reviewed date.
2. Identity-linked alert surface. Every alert carries the verified KYC record, the KYC tier, and the perpetual re-screening status at the moment of the alert.
3. Risk-tiered customer model. AML transaction monitoring intensity varies with customer risk band. Standard CDD for low-risk, enhanced CDD with elevated thresholds and additional rule coverage for high-risk.
4. Per-decision triage record. Every alert produces a structured triage record (analyst, time, evidence reviewed, closure rationale, escalation outcome). Closure without documentation is not closure.
5. SAR filing pipeline with clock tracking. From alert open to SAR filed (or alert closed with documentation), the clock is visible and tracked. Backlog metrics surface to the CCO weekly, not quarterly.
6. Independent audit and tuning cadence. AML transaction monitoring rules need to be tuned. False positives degrade analyst attention. False negatives miss typology coverage. Independent annual audit is the regulatory floor; quarterly tuning is the operating practice.

For the broader risk-assessment framing, see our crypto risk-assessment guide and our building a robust AML strategy for crypto exchanges piece.

How does Zyphe's AML transaction monitoring connect to the identity layer?

The architectural pattern that catches mule accounts at onboarding rather than after the laundering has already moved is the one that makes the identity layer and the monitoring layer the same system, not adjacent systems. Zyphe's AML monitoring product is built around exactly this commitment.

When a user goes through KYC verification, Zyphe issues a verifiable credential bound to the user's wallet or account. The credential carries the KYC tier, the jurisdictional whitelist, the sanctions-clearance status, the PEP status, and the verification timestamp. Monitoring rules then run against the transaction stream with the verified credential available as a join key. Mule indicators (newly verified account, low-tier KYC, immediate forwarding to high-risk counterparty) fire deterministically at the rule level because the identity attributes are right there in the alert payload.

The credential-binding mechanism is detailed in our explainer on the KYC passport.

The continuous-monitoring side mirrors the credential layer. Sanctions and PEP re-screening run on a defined cadence at the credential layer. A user whose status changes has their credential revoked in real time. The next rule that checks the credential status fails the transaction without a separate sanctions API call. This is the architectural inversion that gets monitoring out of the post-facto reconciliation pattern.

The continuous sanctions and PEP re-screening argument is made in full in our perpetual KYC piece.

Zyphe's approach is to keep the source documents encrypted in the end user's own vault and give the business the credential. The monitoring layer reads the credential, and there is no central store of customer PII to breach. The audit trail is the credential plus the alert log plus the triage record, all timestamped, all reproducible. If the monitoring layer does not know who the user is at every alert, it is a queueing system, not an AML program. For the deeper architecture, see our decentralised KYC primer and our perpetual KYC piece.

Keeping the credential instead of a central copy of the documents is the core of our decentralised KYC primer.

The Zyphe stack ships with: real-time scoring at authorisation time for cliff-edge rules; batch pattern detection for cross-product behavioural rules; an out-of-the-box typology library covering typologies drawn from FATF guidance plus jurisdiction-specific FinCEN/FCA/BaFin advisories; identity-linked alert payloads; per-decision triage records; SAR filing pipeline with clock tracking; and audit-export in regulator-ready formats. Median alert-to-triage time at production customers is under 4 hours for cliff-edge rules and under 24 hours for behavioural rules. The Zyphe AML monitoring precision rate (alerts that produce a SAR or a documented escalation) runs at approximately 22%, versus the 5 to 10% implied by the 90 to 95% false-positive rates commonly reported for rules-based monitoring, because the identity layer eliminates the noise that comes from monitoring against unverified accounts.

How do you score your AML transaction monitoring program's maturity?

A 20-question checklist a compliance manager can run against the current AML transaction monitoring program in under an hour. Score each item 0 (not in place), 1 (partial), 2 (in place and documented). Maximum 40. Below 20 is a remediation project. 20-30 is operational. 30+ is audit-ready.

Typology coverage

1. Documented typology library with named typologies and rule logic
2. Source citation for each typology (FATF, FinCEN, FCA, BaFin advisory)
3. Version history and last-reviewed date per rule
4. Coverage for structuring, layering, mule indicators, and peeling chains

Identity linkage
5. Every alert carries the verified KYC record
6. KYC tier visible in alert payload
7. Perpetual KYC re-screening status visible at alert time
8. Sanctions and PEP status as join keys, not separate API calls

Risk tiering
9. Customer risk-band model documented and applied
10. Monitoring intensity varies with risk band
11. EDD elevated thresholds and additional rules for high-risk

Per-decision triage
12. Every alert produces a structured triage record
13. Triage records include analyst, time, evidence reviewed, closure rationale
14. Closure rationale references rule predicates and identity attributes

SAR pipeline
15. SAR filing clock tracked from alert open to SAR filed
16. Backlog metrics (median, 95th percentile age) surface to CCO weekly
17. Late SAR filings trigger escalation and post-mortem

Audit posture
18. Independent annual audit, quarterly tuning cycle
19. Audit-export available in regulator-ready format on demand
20. Program tested against the typology library annually

For an external benchmark perspective on continuous monitoring maturity, see the Wolfsberg Group's anti-money laundering principles.

The bottom line

AML transaction monitoring in 2026 is not a faster version of 2018 transaction monitoring. The regulatory bar moved. The TD Bank, Starling, Monzo, and Revolut enforcement actions proved that financial crime controls which do not keep pace with the business are now an enforcement target rather than a compliance posture. The AML transaction monitoring programs that pass their next audit are the ones that build identity linkage, per-decision triage, and SAR-clock tracking as primitives rather than as configurations. The architectural inversion that catches mule accounts at onboarding rather than post-facto is the difference between a 22% precision rate and the 5 to 10% typical of rules-based monitoring, and between a queueing system and a compliance program.

See how Zyphe AML transaction monitoring works, book a demo or see the AML product.

When is heavier AML transaction monitoring not the right call?

Real-time scoring is not always the answer. Batch monitoring still survives for slower rails like ACH, wire, and card, where chargebacks and clawbacks remain feasible. Forcing real-time blocking onto those flows adds latency and false positives without a settlement risk that justifies it. Match the monitoring mode to the rail: real-time for instant payments where post-facto blocking is impossible, batch reconciliation for pattern-based rules where the money can still be recovered.

Pure machine-learning monitoring without a rule-based backstop is the other wrong call. It is a regulator-relations red flag, because the explainability burden is real: regulators want to know why a model fired, what features mattered, and whether a human reviewed the output. Keep deterministic rule logic for the legally mandated typologies and reserve ML scoring for the long-tail behavioural anomalies. More rules and more alerts are also not automatically better. A 30-day-plus backlog of unreviewed alerts is itself a leading indicator of failure, so adding coverage you cannot triage on time makes the audit posture worse, not stronger.

Related resources

1. AML strategy for crypto exchanges, Building a robust AML strategy
2. Perpetual KYC, Why one-time KYC fails
3. Adverse media screening, The AMLA noise-floor reframe
4. CFT screening for financial institutions, Five breakdown points
5. Automated compliance reporting, SAR pipeline mechanics
6. KYB software guide, How to verify businesses without the manual overhead
7. Decentralised KYC primer, What it is, how it works in 2026
8. Risk assessments, Conducting effective risk assessments in crypto compliance
9. AML product page, Zyphe AML monitoring