Transaction Monitoring: The Complete Guide for AML Compliance
Transaction monitoring is the AML control that scrutinises customer transactions after they occur to detect activity that may indicate money laundering, terrorist financing, fraud, or sanctions evasion. This guide explains how transaction monitoring works, how scenarios are designed and tuned, and how a regulator-grade alert workflow connects monitoring to suspicious activity reporting.
Transaction monitoring sits at the operational heart of every AML programme. KYC and customer due diligence establish what the firm knows about the customer at onboarding; transaction monitoring tests that knowledge against what the customer actually does. When the gap between expected and observed behaviour widens, the monitoring system raises an alert — and the firm's ability to evaluate that alert correctly determines whether genuine financial crime is detected and reported.
Regulators have shifted decisively in recent years from prescriptive rules toward outcome-based supervision of transaction monitoring. They no longer ask "do you have a monitoring system?" — they ask whether the system is genuinely calibrated to the firm's risk profile, whether alerts are reviewed by competent analysts within reasonable timeframes, and whether the firm's SAR filings are consistent with the typologies that should be visible in its book.
How Transaction Monitoring Differs From Transaction Screening
The two terms are often used interchangeably and they should not be. The distinction matters operationally, technically, and from a regulatory perspective.
The clearest way to draw the line:
- Transaction screening happens before a payment is executed. It checks the originator, beneficiary, intermediaries, and free-text fields against sanctions lists. The output is binary: release the payment or hold it. Latency is measured in milliseconds.
- Transaction monitoring happens after the transaction has settled. It analyses transaction patterns over time to detect behaviour that suggests money laundering, terrorist financing, or fraud. The output is an alert that an analyst investigates over hours or days.
- Screening uses name matching against a fixed watchlist; monitoring uses scenario logic against the customer's historical behaviour and peer-group baselines.
- Both controls are required. A firm with screening but no monitoring is exposed to laundering by non-sanctioned customers; a firm with monitoring but no screening is exposed to direct sanctions violations.
See our sanctions screening guide for the corresponding deep-dive on the screening side.
The Anatomy of a Detection Scenario
A detection scenario is a logical rule, statistical model, or machine-learning classifier that flags transactions or transaction patterns matching a defined risk pattern. Every transaction monitoring system is ultimately a library of scenarios applied to the customer's transaction history.
Effective scenarios are designed around recognised money-laundering typologies — the patterns of behaviour that criminals actually use to move illicit funds. The Financial Action Task Force, the Egmont Group, and national FIUs publish typology reports that should be the starting point for scenario design.
The scenarios that appear in almost every well-designed monitoring programme include:
- Structuring (smurfing) — multiple deposits or withdrawals just below the cash reporting threshold, suggesting deliberate evasion.
- Rapid pass-through (layering) — funds received and sent onward within a short window, with the firm acting as an intermediate point in a longer chain.
- Round-amount transactions — repeated transfers of suspiciously round figures that do not correlate with normal commercial activity.
- Velocity anomalies — sudden, large changes in transaction frequency or value that are inconsistent with the customer's historical pattern.
- Geographic risk concentration — transactions involving high-risk jurisdictions disproportionate to the customer's declared business.
- Counterparty risk concentration — disproportionate exposure to a single counterparty or set of related counterparties.
- Dormant-then-active accounts — accounts inactive for extended periods that suddenly receive significant funds.
Rule-Based vs Behavioural vs Machine-Learning Detection
Modern transaction monitoring platforms combine three detection approaches. Each has strengths the others lack, and a programme that relies on only one is materially weaker.
Rule-Based Detection
Rule-based scenarios are deterministic: if a customer makes more than X transactions of more than Y in a Z-day window, raise an alert. They are transparent, easy to document, and easy to defend to a regulator. They are also rigid — they catch what they are configured to catch and miss everything else. Every monitoring programme starts with rule-based scenarios for the well-known typologies.
Behavioural Profiling
Behavioural detection compares each customer's current activity against their own historical baseline and against peer groups of similar customers. A customer who has averaged $20,000 in monthly outflows for two years and suddenly sends $400,000 in a week is anomalous regardless of whether any rule was breached. Behavioural profiling catches deviations that rules cannot anticipate.
Machine-Learning Models
Supervised models trained on historical SAR outcomes can dramatically improve precision — they learn which combinations of features actually correlate with confirmed suspicious activity. Unsupervised models surface novel patterns that no rule was designed to catch. Machine learning works best as a layer on top of rule-based and behavioural detection, not as a replacement.
The False Positive Problem
Every transaction monitoring programme generates false positives — alerts that, on investigation, do not correspond to suspicious activity. Industry research consistently puts the false-positive rate of legacy rule-based systems at 90% or higher. Some banks investigate hundreds of thousands of alerts a year to confirm a few thousand SARs.
The cost of false positives is operational: every alert consumes analyst time, and the budget for analyst time is finite. When false positives crowd out genuine investigations, the programme misses real laundering. Reducing false positives is therefore not a nice-to-have — it is a core compliance objective.
Modern platforms address false positives through three mechanisms working in combination: scenario tuning (adjusting thresholds and parameters based on the firm's actual data), contextual scoring (incorporating the customer's risk rating, history, and product set into the alert), and supervised learning on disposition data (training models to recognise the patterns that distinguish true from false alerts in the firm's own book). See our deeper guide on reducing false positives in AML screening.
The Alert Lifecycle: From Detection to SAR
An alert is only the start of the process. What happens between the alert being raised and the case being closed determines whether the monitoring programme actually works.
A regulator-grade alert lifecycle has six stages:
- Generation — the scenario fires and the alert is queued with full context: triggering transactions, customer profile, risk rating, prior alerts.
- Triage — a Level 1 analyst reviews the alert against documented decision criteria and either closes it as a false positive or escalates it for deeper investigation.
- Investigation — a Level 2 analyst conducts enhanced review, gathers additional information, contacts the relationship manager or the customer where appropriate, and documents findings.
- Determination — the investigator concludes whether suspicion is warranted. If yes, the case is escalated to the MLRO; if no, the case is closed with documented rationale.
- SAR decision — the MLRO determines whether the matter requires a Suspicious Activity Report and, if so, prepares and files the SAR. See our guide on suspicious activity reporting.
- Post-filing actions — the firm decides whether to maintain, restrict, or exit the customer relationship in light of the findings.
Every step must be documented, time-stamped, and auditable. A regulator examining the programme will trace sample alerts end-to-end and challenge any gap in the chain of evidence.
Designing a Programme That Stands Up to Scrutiny
A transaction monitoring programme is not a technology procurement decision — it is a control framework. The technology matters, but the framework around it matters more.
The programme must begin with a documented assessment of the firm's exposure: what products it offers, what customer segments it serves, what jurisdictions it operates in, what payment channels it provides. From that assessment, scenarios are selected and calibrated. From the calibration, threshold values are set. From the thresholds, alerts are generated. From the alerts, investigations are conducted. From the investigations, SARs are filed. And every quarter, the entire chain is reviewed against the firm's actual SAR outcomes — to confirm that the programme is detecting what it should and not drowning in noise.
One Constellation's transaction monitoring platform ships with a configurable scenario library aligned to FATF, MAS, FCA, and FinCEN typology guidance, and lets compliance teams tune scenarios against their own data without engineering involvement.
Transaction Monitoring That Detects More and Investigates Less
One Constellation combines rule-based, behavioural, and machine-learning detection in a single platform — with structured alert workflows, integrated case management, and full audit trails for every regulator interaction.
