Learn more about the latest security and privacy threats
Back

AML Transaction Monitoring in 2026: What the Regulations Actually Require

Michelangelo FrigoMichelangelo Frigo(Co-Founder at Zyphe)Published May 15, 2026Updated May 4, 2026
Radar screen tracking transactions with a flagged red alert blip

Volume thresholds are not an AML transaction monitoring program. Regulators expect typology coverage, identity-linked alerts, and audit-ready logs.

Table of contents

TL;DR

FinCEN filed roughly 4.6 million Suspicious Activity Reports in 2024, the highest annual volume on record. 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 AML transaction monitoring program 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.

FinCEN filed 4.6 million SARs last year. Monitoring for volume thresholds is 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).

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). The UK FCA expects "as soon as practicable" through the NCA's SAR Online portal. The EU AMLD6 transposition leaves filing timelines to member states but standardises content requirements. 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 the current high-water mark for US AML transaction monitoring enforcement. The FinCEN AML/CFT Program Rule (effective January 1, 2026) added a "Reasonably Designed and Risk-Based" standard that raises the documentation bar materially.

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. AMLA introduces "per-decision defensibility": every alert closure, every SAR-filing-or-not decision, must be documented with a reasoned basis the regulator can audit. AMLA has direct supervisory authority over the largest CASPs and approximately 40 EU banks, with national supervisors handling the rest. The Revolut Bank UAB EUR 3.5 million Bank of Lithuania penalty (April 2025) is the early signal of how AMLA-era supervision will treat AML transaction monitoring documentation gaps.

United Kingdom: FCA, Money Laundering Regulations 2017, and the SAR Online 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 SAR Online. The FCA's enforcement appetite escalated sharply through 2024-2025: Starling Bank GBP 29 million Final Notice (October 2024), Monzo Bank GBP 21 million Final Notice (July 2025), and the Revolut GBP 3.1 million Final Notice (2024) all cited AML transaction monitoring gaps as primary findings, with "control framework inconsistency" appearing in each Final Notice.

Side-by-side: AML transaction monitoring obligations across the three regimes

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

Four failure modes show up in almost every Final Notice and FinCEN consent order. 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. The Cash App / Block USD 160 million FinCEN penalty (March 2025) and the Robinhood Crypto USD 30 million NYDFS penalty (August 2022) both cited identity-linkage gaps. 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.

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. The TD Bank penalty cited exactly this pattern. AMLA's per-decision defensibility framing makes the documentation requirement 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. The Starling and Monzo Final Notices both cited specific backlog figures (counts of unreviewed alerts and average age) as core findings. The right metric to instrument: median and 95th-percentile alert age, broken down by typology and by analyst.

Recent enforcement that should be in your AML transaction monitoring business case

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 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 that produced the TD Bank, Starling, and Monzo Final Notices.

A senior compliance lead at a LATAM bank we work with described the operational reality this way on a customer call: "we onboard 12 million clients, we hold 80% of the data we collected at onboarding, and we have no good answer for why." Zyphe's answer is to remove the data and keep the credential. The monitoring layer reads the credential. The breach surface stays at zero. The audit trail is the credential plus the alert log plus the triage record, all timestamped, all reproducible. Charlene Wang, Zyphe's CRO, framed it on a customer call in March 2026: "the monitoring layer should know who the user is at every alert. If it doesn't, you are running a queueing system, not an AML program." For the deeper architecture, see our decentralised KYC primer and our perpetual KYC piece.

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 FATF Recommendation 20 named typologies 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 a published industry baseline of 5-8%, because the identity layer eliminates the noise that comes from monitoring against unverified accounts.

The AML transaction monitoring maturity checklist

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 Final Notices proved that volume-threshold rules without typology coverage 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 a 5-8% precision rate, and between a queueing system and a compliance program.

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

  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
Michelangelo FrigoMichelangelo Frigo(Co-Founder at Zyphe)Michelangelo Frigo is a privacy and identity infrastructure expert and co-founder of Zyphe.

Frequently Asked Questions

AML transaction monitoring is the continuous surveillance of customer transactions for indicators of money laundering, terrorist financing, sanctions evasion, and fraud, with documented triage and SAR filing where regulatory thresholds are met. Modern AML transaction monitoring combines rule-based detection (for legally mandated typologies) with behavioural analytics (for novel anomalies), linked to verified identity at every alert.

Real-time monitoring scores each transaction at authorisation time and can block or hold before settlement. Batch monitoring runs end-of-day rules across the day's flows. Real-time is required for instant payment rails (FedNow, SEPA Instant, UPI, Pix). Batch survives for slower rails. Most modern programs run a hybrid: real-time for cliff-edge rules, batch for cross-product behavioural patterns.

AMLA's per-decision defensibility standard requires every alert closure, every SAR-filing-or-not decision, to be documented with a reasoned basis the regulator can audit. Closing alerts in batches with one-line notes is no longer compliant under the new EU framework. AML transaction monitoring software that does not generate per-decision triage records is structurally non-compliant in the EU after 2025.

SAR filing timing is jurisdiction-specific. FinCEN requires SAR filing within 30 calendar days of detection (60 if no suspect identified). The UK FCA expects "as soon as practicable" through the NCA's SAR Online portal. The EU under AMLD6 leaves filing timelines to member-state transposition but standardises content requirements. AML transaction monitoring software with SAR-clock tracking is the operational fix.

Threshold-only rules without typology coverage. The fintech that monitors for "transaction > USD 10,000" without rules for structuring, layering, mule activity, and peeling chains is monitoring volume, not laundering. Every recent FinCEN, FCA, and Bank of Lithuania Final Notice cited typology coverage gaps as primary findings. A program without a documented typology library will fail the next audit.

Mule account detection requires identity-linked monitoring. The signature is a newly verified account, low KYC tier, receiving funds and immediately forwarding to a counterparty in a higher-risk jurisdiction. Without the identity attributes joined to the alert payload, the rule cannot fire deterministically. Zyphe carries the verified credential into every alert, which makes mule detection a rule-level outcome rather than a manual triage finding.

Zyphe issues a verifiable credential at KYC, bound to the user's account. Monitoring rules join against the credential as part of the alert evaluation. KYC tier, sanctions status, PEP status, and jurisdictional whitelist are available at rule time. Sanctions re-screening at the credential layer revokes credentials in real time, so the next alert that checks credential status fails deterministically. Identity and monitoring are the same system.

Five core metrics, weekly: median and 95th-percentile alert age (overall and per typology); alert-to-triage time; SAR filing clock (alerts open beyond regulatory threshold); precision rate (alerts producing a SAR or documented escalation, target 15% or higher); and rule-level false-positive rates. Software that does not surface these metrics on a CCO dashboard is the wrong AML transaction monitoring software.