Transaction Monitoring

The average bank's transaction monitoring system generates thousands of alerts per month. Over 95 per cent are false positives. Each one costs 15 to 50 pounds in analyst time to investigate and close. The mathematics of this problem is simple: a system optimised for detection that ignores the cost of investigation is a system designed to waste money.

What is transaction monitoring?

Transaction monitoring is the surveillance of customer transactions to identify activity that may indicate money laundering, terrorist financing, fraud, or other financial crime. It is a core obligation under anti-money laundering regulations. Every bank, payment institution, and increasingly every crypto asset service provider must operate a transaction monitoring system proportionate to the nature and scale of their business.

Traditional systems operate on rules. A rule might flag any cash deposit above 10,000 pounds, any international transfer to a high-risk jurisdiction, or any pattern of transactions that resembles structuring (breaking large amounts into smaller ones to avoid reporting thresholds). Each rule generates alerts. Each alert enters a queue. An analyst reviews the customer's history, assesses the context, and decides whether to dismiss the alert, escalate it, or file a suspicious activity report.

The false positive rate is the central operational problem. Rules are blunt instruments. A cash-intensive business that regularly deposits large amounts triggers the same rules as a money launderer. A customer who frequently sends money to family in a high-risk jurisdiction looks, to a rule-based system, like a sanctions evasion risk. The rules cannot distinguish context. The analyst can, but at a cost that scales linearly with alert volume.

The landscape

The FCA has been clear that it expects transaction monitoring systems to be effective, not just present. Enforcement actions have targeted institutions where monitoring systems were poorly calibrated: rules that generated excessive false positives without corresponding detection of genuine suspicious activity, alert backlogs that meant alerts were closed without proper investigation, and inadequate tuning processes that allowed known deficiencies to persist.

The shift from rules-based to risk-based monitoring is the defining trend. Rather than applying uniform thresholds across all customers, risk-based systems calibrate expectations to the customer's profile. A cash deposit of 15,000 pounds from a cash-intensive retail business is expected behaviour. The same deposit from a salaried professional with no history of cash transactions is anomalous. The monitoring system must know the difference, which requires integration with KYC data and customer risk profiles.

Real-time payment systems compress the monitoring window. Under the UK's Faster Payments, a transfer settles in seconds. A monitoring system that analyses transactions in batch overnight cannot intervene before the funds leave the account. Real-time monitoring for real-time payments is becoming a regulatory expectation, not a competitive advantage.

The EU AMLA will set harmonised expectations for transaction monitoring across the EU, reducing the current variation between member states. For institutions operating cross-border, this simplifies the compliance landscape but raises the bar: the new standard will reflect the stricter end of current national requirements.

How AI changes this

Alert scoring is the most deployed AI application in transaction monitoring. Machine learning models trained on historical alert dispositions assign a risk score to each new alert, predicting the likelihood that it represents genuine suspicious activity. Analysts work the queue from highest to lowest score. Institutions deploying this approach report 40 to 60 per cent reductions in false positive investigation time without increasing missed genuine cases. This is alert triage at its most effective.

Behavioural analytics replaces static rules with dynamic customer profiles. The system learns each customer's normal transaction pattern and flags deviations from that pattern. A customer who suddenly begins making large international transfers behaves differently from one who has always done so. The model adapts as the customer's behaviour evolves, reducing the false positives that arise from applying fixed rules to changing lives.

Network analysis identifies money laundering typologies that transaction-level monitoring cannot see. Layering, where funds pass through multiple accounts to obscure their origin, is invisible when each transaction is assessed independently. Graph-based models that map the flow of funds across the network of accounts reveal patterns that individual transaction rules miss. This connects directly to financial crime analytics at the enterprise level.

Automated narrative generation uses large language models to draft the investigation summary for closed alerts and suspicious activity reports. Analysts spend a significant portion of their time writing these narratives. AI-generated drafts reduce the time per alert while maintaining consistency and completeness. The analyst reviews, edits, and approves rather than writing from scratch.

What to know before you start

Deploying AI alongside your existing rules engine is lower risk than replacing it. Score the alerts your rules generate rather than changing the alert generation logic. This approach is easier to validate, easier to explain to the regulator, and delivers immediate productivity gains. Replacing the rules engine entirely with an AI-native system is more transformative but requires a fundamentally different regulatory dialogue.

Model validation is mandatory. The PRA's SS1/23 on model risk management applies to transaction monitoring models. You must demonstrate that the model performs across customer segments, that it does not introduce discriminatory bias, and that it degrades gracefully when data distributions shift. Budget for ongoing monitoring, not just initial validation.

Your analysts are your training data. The quality of an alert scoring model depends on the quality of historical alert dispositions. If analysts have been closing alerts with inconsistent rationale, or if the dismiss-versus-escalate decision varies between individuals, the training data will be noisy. Review and standardise your alert disposition process before training the model.

Start with false positive reduction on your highest-volume alert type. Identify the rule that generates the most alerts with the lowest conversion to SARs. Deploy a scoring model on this single rule. Measure the reduction in investigation time and the impact on detection rates. This contained pilot builds evidence for broader deployment while limiting risk.