Transaction Monitoring
Transaction monitoring is the ongoing review of customer transactions against expected behavior to identify activity that may indicate money laundering, fraud, or sanctions evasion. It runs continuously after onboarding, generates alerts when activity breaches a rule or deviates from a customer’s established pattern, and feeds the investigations that end in a Suspicious Activity Report or in nothing at all.
| Also called | AML transaction monitoring, TM |
| When it runs | Continuously, post-onboarding — the ongoing half of customer due diligence |
| Primary output | Alerts, which analysts triage into cases, which may become SARs |
| Detection approaches | Rules and thresholds, statistical anomaly detection, network analysis, machine learning models |
| Typical alert outcome | The large majority close without a filing |
| Governing obligation (U.S.) | Bank Secrecy Act; SAR filing under 31 CFR Chapter X |
| Model governance | Scenarios and thresholds require documented tuning and periodic validation |
| Key dependency | The customer profile built at onboarding — monitoring compares against it |
How it works
Monitoring is a comparison, and the comparison needs two sides. One side is the transaction: amount, counterparty, geography, channel, timing, instrument. The other is the expectation — what this customer, given what the institution knows about them, ought to be doing. Everything difficult about transaction monitoring lives in the quality of that second side.
Detection scenarios are the mechanism. A scenario encodes a pattern worth flagging: cash deposits just under a reporting threshold, rapid movement of funds in and out of an account, payments to a jurisdiction the customer has no stated connection to, a sudden change in velocity or average value. Each scenario carries thresholds, and the thresholds are the tuning surface. Set them tight and analysts drown; set them loose and the pattern the scenario exists to catch passes through.
Alerts then enter a workflow. An analyst reviews the activity, pulls the customer file, and decides whether the behavior has an explanation. Most do. When it does not, the case escalates, and if the institution knows or suspects the transaction involves illicit funds or has no apparent lawful purpose, it files a Suspicious Activity Report. Telling the customer that a report has been filed is itself an offense.
Rules, models, and why both persist
Rules-based scenarios are explainable, auditable, and easy for a regulator to inspect. They are also static: a rule that flags structuring below a threshold is trivially defeated by someone who knows the threshold. Behavioral and machine-learning approaches catch patterns nobody wrote down, but they carry a governance burden — a model that cannot explain why it alerted is difficult to defend in an examination.
Most institutions run both, and the honest reason is regulatory rather than technical. Rules provide the demonstrable coverage an examiner expects. Models catch what the rules miss. Neither replaces the other, and a program that has quietly let its rule set ossify while adding models on top has two problems rather than one.
Why transaction monitoring matters for identity verification
The connection is not obvious and it is the most useful thing on this page. Transaction monitoring compares behavior against a profile, and the profile is assembled at onboarding. If the identity captured during the Customer Identification Program was wrong — a synthetic identity, a stolen one, a real person acting as a mule — then the baseline is wrong, and monitoring dutifully compares new activity against a fiction.
This is why synthetic identity fraud is so difficult for monitoring to catch. A synthetic account behaves impeccably for months, building exactly the profile the system will later measure against, and then busts out in a single window. Nothing deviates from the baseline because the fraudster built the baseline. The failure happened at account opening, and monitoring inherits it.
The same logic applies to sanctions and adverse media. Screening a name against a watchlist is only as good as the confidence that the name belongs to the person who opened the account. Strong identity document verification at onboarding is what makes the ongoing checks mean something, and AML, PEP and sanctions screening becomes a different exercise when the underlying identity is verified rather than asserted.
Transaction monitoring compared with adjacent controls
| Control | When it runs | What it asks |
|---|---|---|
| Customer Identification Program | Account opening | Is this person who they claim to be? |
| Customer due diligence | Onboarding, then periodically | What risk does this customer present, and what should normal look like? |
| Transaction monitoring | Continuously, post-onboarding | Does this activity match what we expected from this customer? |
| Sanctions screening | Onboarding and ongoing, per transaction | Does this party appear on a restricted list? |
| Fraud detection | Real time, at the transaction | Is this transaction unauthorized or loss-bearing right now? |
Fraud detection and transaction monitoring are routinely conflated and answer different questions. Fraud asks whether the institution or the customer is about to lose money, and it needs an answer in milliseconds. AML monitoring asks whether the money is dirty, and it can take days. The two functions increasingly share data and rarely share a team.
What transaction monitoring can’t do
It cannot detect what it has no scenario for. Novel typologies pass through until someone writes a rule or a model learns the shape. Detection lags the method.
It cannot fix a bad baseline. Activity is measured against an expectation set at onboarding. Where the identity behind the account is false, monitoring measures deviation from a fabricated norm.
It cannot tell you who acted. A monitoring system sees an account and a transaction. Whether the person instructing the payment is the accountholder, a coerced mule, or someone who has taken the account over is a question about identity, not about the transaction.
Alert volume is not coverage. A program generating enormous alert counts with a low conversion to filings is producing work, not necessarily detection. Tuning is the discipline, and undertuned scenarios are a common examination finding.
Frequently asked questions
Is transaction monitoring the same as fraud detection?
No. Fraud detection works in real time to stop an unauthorized or loss-bearing transaction. AML transaction monitoring works retrospectively to identify activity suggesting money laundering or other financial crime, and its output is an investigation rather than a declined payment.
Does every alert lead to a Suspicious Activity Report?
No, and most do not. Alerts are triage signals. An analyst reviews the activity against the customer file, and the large majority resolve with an ordinary explanation. Only cases where the institution knows or suspects illicit activity, or sees no apparent lawful purpose, result in a filing.
What makes a transaction monitoring program fail an examination?
Most commonly, scenarios and thresholds that have not been tuned or validated, coverage gaps where a product or channel is not monitored, and backlogs of unreviewed alerts. Weak underlying customer data is a frequent root cause of all three.
How does identity verification improve transaction monitoring?
Monitoring measures activity against a profile built at onboarding. Verifying the identity behind the account means the baseline describes a real person, so deviation from it carries information. Where the identity is synthetic or stolen, the baseline is fabricated and monitoring compares against it faithfully.
Related reading
- Suspicious Activity Report — the filing a monitoring alert may eventually become, and the confidentiality rules around it
- Customer due diligence — how the expected-behavior profile that monitoring compares against is built
- Bust-out fraud — the pattern that defeats baseline monitoring by patiently constructing the baseline
- When should the KYC process be performed? — why the timing of identity checks shapes everything that follows
