Every institution subject to the Bank Secrecy Act has to answer one deceptively simple question about each of its customers. Does this activity make sense? AML transaction monitoring is the machinery built to answer that at scale, across millions of payments a day, without a human looking at each one.
It is also the control that fails most publicly. The largest anti-money laundering penalties of the past decade turned on monitoring gaps rather than exotic criminal schemes. The year 2026 has also brought regulatory change that alters how those gaps are judged. This transaction monitoring guide covers what the control is, how it works from data to filed report, and what a defensible program looks like now.
What Is Transaction Monitoring?
Transaction monitoring is the ongoing review of customer transactions to detect activity that may indicate money laundering, terrorist financing, fraud, or other financial crime. Financial institutions compare each transaction against the customer's expected behavior and defined risk scenarios, then investigate anything that falls outside those patterns and report genuine suspicion to authorities.
US regulators and the FFIEC manual use the term suspicious activity monitoring for the same control. It is often confused with transaction screening, and the two answer different questions. Screening is a preventative check that runs against a payment before or as it executes, matching names and payment details to sanctions lists, watchlists, and politically exposed person databases. It asks whether a party is prohibited. Transaction monitoring is a detective control. It looks at behavior across time, volume, counterparties, and geography, and asks whether the pattern is suspicious. A payment can clear screening cleanly and still sit at the center of a laundering typology. The distinction between transaction screening and transaction monitoring matters operationally, because an institution that has one is not covered for the other.
Both controls sit inside a wider AML compliance program that also covers customer due diligence, risk assessment, and sanctions compliance. Transaction monitoring for AML depends on those upstream processes, because a monitoring system can only judge behavior against a customer profile that was built properly in the first place.
Why Transaction Monitoring Matters
BSA/AML transaction monitoring requirements are statutory, not optional. Under 31 CFR 1020.320, a bank must file a Suspicious Activity Report (SAR) once a transaction involves at least $5,000 in aggregate and suspicion attaches to it. The test is whether the institution knows, suspects, or has reason to suspect the funds are illegal, that the transaction evades reporting requirements, or that the activity has no lawful purpose. The filing deadline is 30 calendar days from initial detection, extendable by 30 days if no suspect has been identified, and capped at 60 days in all cases. Separately, cash transactions above $10,000 in a single business day trigger a Currency Transaction Report. Outside the United States the same duty appears as suspicious transaction reporting under the EU's AML framework and the UK's Proceeds of Crime Act; the reporting form differs, the monitoring that produces it does not.
The scale is substantial. FinCEN data shows more than 4.1 million SARs filed across all filer categories in 2025, up roughly 8 percent year over year. Banks, savings associations, and credit unions accounted for about 2.19 million of those.
The history of enforcement explains why transaction monitoring is essential, not merely expected. The reference case remains TD Bank's resolution in October 2024. The Justice Department found the bank did not automatically monitor most domestic ACH activity, most check activity, and several other transaction types. That left 92 percent of total transaction volume unmonitored between January 2018 and April 2024, roughly $18.3 trillion in activity. It added no new monitoring scenarios and made no material changes to existing ones from at least 2014 through late 2022. It also rolled out services such as Zelle without confirming coverage. Three laundering networks moved more than $670 million through the institution. Penalties came to about $3.1 billion, including $1.3 billion to FinCEN, its largest ever against a depository institution.
Examiner expectations for transaction monitoring in banking follow directly from these findings. The FFIEC BSA/AML Examination Manual instructs examiners to map out how the institution monitors, identifies, researches, and reports suspicious activity. They then follow a single alert through the entire process end to end. They assess whether filtering criteria are reasonable, whether the methodology has been independently validated, and whether SAR decisions are timely and well documented.
How Transaction Monitoring Works: From Data to Alert to SAR
The AML transaction monitoring process runs in five stages, and each one can break independently.
Data input. Monitoring consumes transaction records, customer reference data, account relationships, counterparty details, and payment message fields. Coverage is decided here, and it is where the worst failures happen. If a product, channel, or transaction type is not fed into the transaction monitoring system, no rule can catch it. The TD Bank case was not a tuning problem or an alert quality problem. Entire product categories were outside the scope the system ever looked at.
Detection. Scenarios and thresholds run against the data, either in batch overnight or in near real time. Each scenario encodes a typology, and each has parameters that determine when it fires. The customer segmentation behind those parameters matters as much as the thresholds themselves, because a threshold that is sensible for a retail depositor is noise for a cash-intensive business.
Alert generation. A triggered scenario produces an alert, which enters a queue with a risk score and a priority. An alert is a signal for review, not a finding of suspicion, and treating it as either more or less than that causes problems downstream.
Investigation. An analyst gathers account history, KYC and enhanced due diligence records, prior alerts, counterparty information, and negative news, then decides whether the activity has a reasonable explanation. Cases that do not resolve at this level escalate for deeper review.
Reporting. Where suspicion stands after investigation, the institution files a SAR with a narrative explaining what happened and why it is suspicious; this is where AML monitoring and reporting meet, and where examiners look hardest. The FFIEC manual is explicit that narrative quality is examined and that pointing to an attachment instead of writing the explanation is a deficiency. The clock runs from initial detection, not from the date the case is assigned. Missing that window is a violation in itself, independent of whether the underlying suspicion was correct, which is why SAR filing deadlines are tracked as a separate control rather than left to investigator judgment.
Feedback from the last stage should return to the first two. Scenarios that never produce a filed SAR and typologies that investigators keep finding without help from the system are both tuning inputs.
Rules vs. Behavioral Analytics vs. AI
Three detection approaches sit in most programs today, usually layered rather than chosen between.
Rules are deterministic conditions on transaction attributes: Deposits above an amount, a count of transfers inside a window, activity involving a listed jurisdiction. They are transparent and easy to defend to an examiner because the logic can be read. They are also brittle. They catch what they were written to catch and nothing else, and anyone who learns the parameters can stay underneath them.
Behavioral analytics shifts the reference point from a fixed number to the customer. It builds a profile of expected activity from the account's own history and from peer group norms, then flags deviation. A $40,000 wire is unremarkable for one business and a significant anomaly for another with the same nominal risk rating. This absorbs legitimate diversity far better than static thresholds, but it depends on accurate segmentation and enough history to establish a baseline.
AI and machine learning are used in three main ways. Supervised models train on historical alert dispositions and SAR outcomes to score new alerts by likelihood of being productive. Unsupervised methods find anomalies without labels, which helps with typologies nobody has written a rule for yet. Graph and network analytics model accounts and counterparties as a connected structure, making patterns visible that are invisible at the level of a single transaction.
Regulators have supported AI-powered transaction monitoring for some time. In December 2018, the federal banking agencies, NCUA, and FinCEN issued a joint statement on innovation. It confirmed that pilot programs should not by themselves draw supervisory criticism, even where unsuccessful. It also confirmed that finding suspicious activity through an AI pilot would not lead agencies to assume existing processes were deficient. FinCEN's April 2026 proposed program rule goes further, stating the Director would consider an institution's use of artificial intelligence and proactive analytics as evidence of effectiveness.
Common Transaction Monitoring Rules and Scenarios
Scenarios are where typology knowledge becomes detection logic. The core set below appears in nearly every program, in some form.
| Scenario | What it catches | What the alert usually looks like |
|---|---|---|
| Structuring | Deliberate splitting of transactions to stay under reporting thresholds | Several cash deposits just below $10,000 across days, branches, or related accounts |
| Rapid movement of funds | Pass-through and layering activity | Funds arriving and leaving within hours, with the account holding little or no resting balance |
| Geographic risk | Exposure to high-risk or sanctioned jurisdictions | Wires to or from a country with no connection to the customer's stated profile or business |
| Dormant account reactivation | Compromised, sold, or mule accounts | An account inactive for months suddenly receiving large credits, then moving them straight out |
| Funnel accounts | Collection and consolidation of illicit proceeds | Many small credits from unrelated parties, followed by consolidated outbound transfers |
| Round-tripping | Circular flows designed to create a false audit trail | Funds leaving and returning to the same beneficial owner through a chain of intermediaries |
Two things go wrong here in practice. The first is running vendor default scenarios without adapting them, since defaults are sized for a generic institution rather than the customer base actually being monitored. The second is scenario sprawl, where new rules are added after every incident and nothing is ever retired, leaving overlapping logic that multiplies alerts on the same underlying behavior. Building the scenario set is its own discipline, and the working catalog of transaction monitoring rules and scenarios extends well past the six above.
Thresholds and Tuning: Managing False Positives
Widely cited industry analysis puts the false positive rate for traditional rule-based monitoring at 90 to 95 percent. Analysts spend most of their time closing alerts that are never going to lead anywhere, which is expensive and, more importantly, buries the alerts that matter.
Threshold tuning is the structured response. The standard method is above-the-line and below-the-line testing. The current production threshold is the baseline. The institution raises it and reruns the scenario against historical data to see which productive alerts would have been lost. It then lowers the threshold to see whether the extra alerts falling below the line contain genuine risk. If the below-the-line population is entirely noise, the threshold is at or below the right place. If it contains activity that should have been caught, the threshold was too high.
Tuning done well starts before the math, and the practical work to reduce false positives in transaction monitoring mostly concerns input quality rather than detection logic. Stale customer risk data, missing expected-activity fields, and coarse segmentation will defeat any threshold. Segmentation deserves particular attention, because a scenario can look healthy in aggregate while producing pure noise for one customer group and missing activity in another.
Measurement matters too. The alert-to-SAR conversion rate is a poor sole target, since it improves simply by making the system less sensitive. Useful programs track volume and disposition by scenario and by segment, repeat-alert rates on the same customer and behavior, and SAR yield per analyst hour. Every change needs documented rationale, impact analysis, approval, and post-implementation verification. A tuning decision with no paper trail is indistinguishable from a threshold raised to reduce workload.
Alert Management and Investigation
An alert queue without structure becomes a backlog, and a backlog is a regulatory finding waiting to happen. A functioning alert-to-SAR workflow has three parts.
Triage and prioritization. Alerts are tiered by the underlying risk signal, with service levels proportionate to tier. Duplicates and alerts linked to existing cases are consolidated so the same behavior is not investigated twice. Obvious false positives are closed with a documented reason rather than left to age.
Tiered investigation. Level 1 analysts perform an initial review against the customer profile and transaction history and either dispose of the alert with reasoning or escalate. Level 2 investigators handle cases needing deeper work, including counterparty analysis, source of funds review, adverse media checks, and, where appropriate, contact with the customer. Material suspicion escalates to senior compliance, and the SAR filing decision sits with the BSA Officer or, outside the United States, the Money Laundering Reporting Officer.
Case management. A case system holds the alert, the evidence, the analysis, the decision, and the audit trail in one place. Without it, the institution cannot demonstrate what was reviewed or why a filing decision went the way it did.
The October 2025 interagency SAR FAQs changed some long-standing habits here. FinCEN and the banking agencies confirmed that institutions are not required to document decisions not to file a SAR. Nor are they required to conduct a separate post-SAR review of a customer on a fixed 90-day cycle. Both practices had hardened into de facto expectations. Many institutions will keep a lighter version of each for audit purposes, but the resource allocation is now theirs to decide.
Specialized Monitoring Contexts
Some environments need detection logic that standard retail scenarios do not provide.
Cross-Border Payments
Cross-border transaction monitoring depends heavily on payment message quality. The SWIFT coexistence period between legacy MT messages and ISO 20022 ended on 22 November 2025, making structured data the standard for cross-border payments. Richer originator, beneficiary, and purpose fields give monitoring systems far more to work with than truncated free-text remittance lines ever did. A further CBPR+ requirement for structured addresses takes effect in November 2026. Institutions that migrated the plumbing but never updated their scenarios to consume the new fields are leaving the benefit on the table.
Correspondent Banking
Correspondent banking transaction monitoring carries a structural visibility problem. The correspondent sees the respondent as the counterparty on every payment, not the underlying originator. Nested relationships, where a respondent quietly extends its correspondent access to other institutions or payment providers, hide an entire layer of unassessed parties inside a relationship that looks vetted. Nesting is rarely disclosed, so it has to be surfaced through monitoring rather than onboarding. Wire volumes disproportionate to the respondent's declared size, originators outside its stated market, and traffic that does not match its business model are the practical signals.
Crypto and Virtual Assets
Transaction monitoring for crypto and virtual assets works on a different evidence base. Blockchain activity is public but pseudonymous, so on-chain analytics can trace a flow across addresses while telling you nothing about who controls them. The detection job is joining that on-chain picture to off-chain identity and account behavior, then watching for patterns specific to this environment, including mixer use, chain-hopping across networks, and transfers to unhosted wallets. The FATF Travel Rule adds a further layer by requiring originator and beneficiary information to travel with transfers between virtual asset service providers.
Fintechs and Payment Firms
Transaction monitoring for fintechs and payment firms carries a different risk shape again. Onboarding is fast and largely remote, transaction velocity is high, and product lines change faster than scenario libraries usually do. Thresholds inherited from a bank build tend to misfire in both directions here, flooding the queue with normal customer behavior while missing the account that was opened three weeks ago and is already moving unusual volume.
Layering
Layering detection is a network problem more than a transaction problem. Splitting, multi-hop chains, reconsolidation, and circular flows only become recognizable when accounts, entities, and transfers are viewed together. Graph and network analytics are built for exactly this, which is why they have moved from research into production monitoring stacks.
Transaction Monitoring vs. Related Processes
These four controls are regularly confused, and each covers a gap the others do not.
| Control | Question it answers | Timing | What a hit means |
|---|---|---|---|
| Transaction monitoring | Is this behavior suspicious? | Continuous, mostly post-transaction | Investigate, then decide on a SAR |
| Transaction screening | Does this payment involve a prohibited or high-risk party? | Real time, before or during execution | Hold or block pending review |
| Sanctions screening | Is this party legally designated? | Real time, plus a re-screen on every list update | Stop immediately, no suspicion threshold applies |
| Fraud detection | Is this transaction unauthorized or deceptive? | Real time, seconds | Block, challenge, or reverse |
Sanctions screening is binary and list-driven, with no risk-based calibration available. Transaction monitoring is probabilistic and risk-based. The difference between sanctions screening and transaction monitoring is not a matter of degree, and one cannot substitute for the other.
Fraud detection shares more technical ground with monitoring, which is why convergence into a single financial crime function has accelerated. Both draw on the same transaction data, the same device and behavioral signals, and often the same customer. Running them on a shared data layer while keeping separate decisioning workflows improves both, since a fraud incident frequently carries AML implications that a siloed team never sees.
Building and Maturing a Transaction Monitoring Program
Transaction monitoring compliance starts with coverage, not tuning. Produce an inventory of every product, channel, and transaction type the institution offers, and map each one to the monitoring that applies. Gaps here outrank every other finding, because a perfectly calibrated scenario cannot see data it never receives.
Model governance changed materially in 2026. On 17 April 2026, the OCC, Federal Reserve, and FDIC issued revised model risk management guidance through OCC Bulletin 2026-13 and SR 26-2. It rescinds the 2011 guidance that had governed the field, along with the 2021 interagency statement on BSA/AML model risk. The revised framework is shorter and principles-based, tailored to an institution's model risk profile, narrower in its definition of a model, and explicitly not an enforceable standard. Generative and agentic AI are carved out of scope pending separate work.
The disciplines survive even though the prescription has loosened. A model inventory, risk tiering, independent validation with genuine challenge, and ongoing performance monitoring are still what an examiner will look for. Weak practice can still draw criticism on safety and soundness grounds.
Validation of a monitoring system should cover the conceptual soundness of the scenarios, whether the logic was implemented as designed, whether data feeds are complete and accurate, and whether outcomes match intent. Run it on a defined cycle and again after material changes to products, customer base, or the system itself.
Ownership matters as much as method. Someone has to be accountable for the scenario inventory, for approving every parameter change, and for escalating when validation finds a problem, and that accountability should sit outside the team running the system day to day. This is the governance layer that turns transaction monitoring model validation from a periodic exercise into a control.
Examiner readiness is largely about reconstructing decisions. The FFIEC approach is to follow a single alert from generation through disposition. Pick any alert at random, and the institution should be able to produce the scenario logic, the parameters, and the rationale behind them. It should also produce the investigation record and the filing decision.
System selection follows from all of this rather than preceding it. An institution that knows its coverage gaps, its segmentation needs, and its model governance obligations can evaluate transaction monitoring software against real requirements instead of vendor feature lists.
Finally, connect the program to the risk assessment. FinCEN's April 2026 proposed rule would make documented risk assessment processes an express regulatory requirement within the internal controls pillar. Institutions would be expected to review and incorporate the National AML/CFT Priorities and to update promptly when their risk profile changes significantly. The practical consequence is direct. If the risk assessment identifies cross-border wires as the highest exposure and the monitoring program devotes most of its scenarios to cash deposits, that mismatch is now the finding.
Sources
- Financial Crimes Enforcement Network, 31 CFR 1020.320, Reports by banks of suspicious transactions
- Financial Crimes Enforcement Network, SAR Statistics (2025 filing data)
- US Department of Justice, TD Bank pleads guilty to Bank Secrecy Act and money laundering conspiracy violations (10 October 2024)
- Financial Crimes Enforcement Network, FinCEN assesses record $1.3 billion penalty against TD Bank (10 October 2024)
- FFIEC, Bank Secrecy Act / Anti-Money Laundering Examination Manual
- Federal banking agencies, NCUA, and FinCEN, Joint Statement on Innovative Efforts to Combat Money Laundering and Terrorist Financing (3 December 2018)
- Financial Crimes Enforcement Network, Anti-Money Laundering and Countering the Financing of Terrorism Program Requirements, Notice of Proposed Rulemaking fact sheet (April 2026)
- Financial Crimes Enforcement Network and federal banking agencies, Frequently Asked Questions Regarding Suspicious Activity Reporting (October 2025)
- Board of Governors of the Federal Reserve System, SR 26-2, Revised Guidance on Model Risk Management, issued jointly with OCC Bulletin 2026-13 (17 April 2026)
- Swift, ISO 20022 for cross-border payments and reporting (CBPR+)
- Financial Action Task Force, Virtual Assets and Virtual Asset Service Providers (Travel Rule guidance)
