Short answer: transaction monitoring is the ongoing review of customer activity to spot transactions that look unusual for that customer or suggest money laundering, terrorist financing or fraud. Systems raise alerts, analysts investigate them, and where suspicion remains the firm files a suspicious activity report. It is the main detection control after onboarding, and it sits in the "tools and technologies" part of the CAMS outline.
Where it fits
Customer due diligence tells the firm who the customer is and what activity to expect. Transaction monitoring checks whether actual activity matches that expectation. The FATF standard calls this ongoing due diligence: scrutiny of transactions throughout the relationship to make sure they are consistent with the firm's knowledge of the customer, their business and risk profile, including the source of funds where necessary.
How a typical system works
- Data in. Account, customer and transaction data from core banking, cards, payments and trade systems. Poor or missing data is the most common reason monitoring fails.
- Rules and scenarios. Logic written to catch known typologies: cash just below a threshold, rapid in-and-out movement, activity with high-risk countries, sudden changes in volume, dormant accounts waking up.
- Segmentation and thresholds. Customers are grouped (retail, small business, private bank, money service business) so thresholds fit each group's normal behaviour.
- Alerts. A rule that fires produces an alert, often grouped into a case per customer.
- Investigation. An analyst reviews the customer profile, the history and the counterparties, asks for information if needed, and decides: close with a documented reason, escalate, or recommend a report.
- Reporting and follow-up. If suspicion remains, the case goes to the MLRO or financial crime unit for a suspicious activity report, and the relationship may be reviewed or exited.
Why tuning matters
Most alerts turn out not to be suspicious. Too many false positives swamp analysts; thresholds set too high miss real activity. Good practice is to:
- Tune thresholds on data, not guesswork, and document the reasons for each change.
- Test above the line (alerts generated at current thresholds) and below the line (activity just under the thresholds) to see whether lowering them would find more suspicious cases.
- Run independent validation of the system and its data at regular intervals and after major changes.
- Review scenarios against current typologies and the firm's own risk assessment, not once at implementation and never again.
Rules, models and AI
Rules are transparent and easy to explain to a regulator but easy to evade. Statistical and machine-learning models can spot patterns across many variables and reduce false positives, but must be explainable, validated and governed. Regulators accept newer methods when firms can show they work and understand them; they do not accept black boxes nobody can explain.
Real-time vs batch
Batch monitoring reviews transactions after the fact (daily or weekly). Real-time or near-real-time monitoring can stop or hold a payment before it is made, which matters for fast payment systems and for sanctions. Screening against sanctions lists is a separate control with a different purpose: sanctions screening basics.
Exam angles
- Monitoring must be risk-based: more intense for higher-risk customers, products and countries.
- Monitoring is only as good as the customer information behind it; expected activity captured at onboarding is the baseline.
- Documenting why an alert was closed is as important as the decision itself.
- Below-the-line testing and independent validation are standard "what should the firm do to improve the system" answers.
- Monitoring finds unusual activity; suspicion is a human judgement that leads to a report: how SAR/STR reporting works.