The dirty secret nobody puts in the vendor deck
Transaction monitoring is, on paper, one of the most powerful tools in the financial crime compliance arsenal. In practice, at most firms, it spends most of its time generating noise.
The average rule-based TM system fires between 85–97% false positives. That means for every 100 alerts your analysts review, three to fifteen actually matter. The rest are your salaried compliance team doing elaborate paperwork to confirm that a retired schoolteacher in Solihull did, in fact, make their usual monthly transfer to their daughter.
And yet, get it wrong — let the real signals slip through — and the consequences are existential. The Canaccord Genuity consent order, issued in March 2026, found at least 160 SARs unfiled and thousands of suspicious transactions flowing undetected, all because TM design relied on static reports reviewed by overwhelmed staff.
Transaction monitoring must be sensitive enough to catch criminals, specific enough not to drown analysts in noise, fast enough to be real-time, and explainable enough to satisfy regulators. Building something that does all four at once is genuinely hard. This guide explains how the industry has tried — and what the AI-era answer actually looks like.
What transaction monitoring actually does
At its core, TM is a surveillance function. Every transaction your customers make passes through a detection engine that compares it against a library of scenarios — behavioural patterns associated with financial crime. When a transaction (or a pattern of transactions) matches a scenario beyond a defined threshold, it generates an alert for a human analyst to review.
The anatomy of a TM rule
Rules are the building blocks of every TM system. Each rule is essentially a hypothesis: "if a customer does X, it might mean Y." Here's what a real-world rule looks like under the hood:
-- Typology: Customer splits large amount into multiple sub-threshold transactions
TRIGGER WHEN:
transaction_count >= 5 within 72 hours
AND each_amount < £9,500 sub-threshold
AND total_amount >= £20,000 aggregate
AND transaction_type IN (CASH_IN, ATM, BRANCH)
EXCLUDE IF:
customer_risk_tier = LOW
AND historical_pattern_match = TRUE known behaviour
ALERT SCORE: HIGH (72) → Route to Senior Analyst queue
Most banks run 200–500 rules simultaneously, each designed for a different typology. The problem: rules are static. They can't learn. And criminals have learned to live below them.
The four inputs every TM system uses
- Transaction data — amount, currency, channel, counterparty, timestamp, reference
- Customer profile — risk tier, business type, onboarding CDD, historical behaviour, PEP/sanctions status
- Peer group benchmarking — is this customer's behaviour unusual compared to similar profiles?
- External intelligence — typology reports from FATF, NCA, FCA; jurisdiction risk; sanctions list updates
The FCA requires firms to have "automated systems to help detect suspicious transactions." Critically, FG25/3 (2025) clarified that rule-based TM alone may not meet the standard for complex or high-volume payment flows — firms should evidence they have considered whether ML-enhanced detection is appropriate for their risk profile.
What happens when an alert fires
The alert is just the beginning. What happens next is a structured workflow that most compliance teams have quietly customised into something the textbooks wouldn't recognise. Here's the actual journey:
TM engine fires. Alert created with score, triggering rule ID, customer data snapshot, and transaction detail. Routed to queue based on risk score — high scores go to senior analysts, standard scores to L1 triage.
Analyst opens the alert. Reviews triggering transaction, customer risk profile, previous alert history, and account activity. The key question: is this consistent with what I know about this customer? Most alerts end here — closed as false positive with documented rationale.
Alert escalated because something didn't add up. Analyst builds a 360° picture — runs PEP/sanctions check, reviews linked accounts, maps counterparty network, checks open-source information, reviews any previous SARs. Usually a 2–4 hour process.
If L2 finds credible grounds for suspicion, analyst prepares an internal escalation pack — summary of facts, timeline, risk indicators, and recommended action. MLRO reviews and decides: SAR or no SAR. Clock starts here — NCA requires a DAML SAR within 7 working days if assets need to be frozen.
If MLRO agrees suspicion exists, a Suspicious Activity Report is filed with the NCA via SARs Online. The firm enters a "consent period" — cannot process the transaction until NCA grants consent (or 7 working days elapse). Full audit trail maintained for 5 years minimum.
Alert outcome is fed back into the TM system. Was this a true positive? Did it lead to a SAR? This data should drive rule tuning — adjusting thresholds, refining exclusion logic, retiring dead rules. Without this loop, TM programmes degrade over time.
The financial crime patterns TM systems are hunting
TM rules are only as good as the typologies they're built to detect. Each card below shows a real typology, the red flags that appear in transaction data, and the rule logic that catches it — or tries to.
Structuring (Smurfing)
Breaking up large sums into multiple sub-threshold deposits to avoid reporting triggers
Layering via Rapid Fund Movement
Passing funds through chains of accounts to obscure the trail between placement and integration
Money Mule Networks
Using third-party accounts (often unwitting or recruited victims) to receive and forward funds, adding a layer of deniability
Trade-Based Money Laundering
Manipulating international trade invoices to move value across borders under the guise of legitimate commerce
Crypto-to-Fiat Laundering
Converting illicit cryptocurrency proceeds into clean fiat currency via exchanges, P2P platforms, or OTC desks
Why rule-based systems are losing the arms race
Rule-based TM was fit for purpose in an era when financial crime was slower, simpler, and less global. That era is over. Here's the structural breakdown:
The False Positive Problem — visualised
Of 1,000 alerts generated in a typical rule-based TM system:
Source: Industry benchmarks, ACAMS survey data, vendor performance claims (independently validated figures vary)
The five structural failures
- Threshold rigidity — A rule that fires at £9,999 will not fire at £9,998. Criminals know this. They also know you know, but they do it anyway because compliance teams rarely adjust thresholds quickly.
- No memory — Each transaction is assessed in isolation unless the rule specifically looks at historical patterns. A criminal who spaces out suspicious activity over months can stay invisible.
- No context — A rule can't know that a spike in outbound transfers is because your customer just sold their house. Analysts have to figure that out manually.
- Typology lag — New crime methods emerge constantly. Building and validating a new rule takes weeks or months. By then, criminals have moved on.
- Tuning debt — Every rule that isn't regularly reviewed accumulates stale logic. Firms with 300+ rules rarely review all of them annually. Dead rules generate false positives forever.
FinCEN's June 2024 guidance explicitly cited machine learning as a tool that can improve customer risk assessment and reduce false positives. The FCA's FG25/3 flagged that over-reliance on legacy TM may not constitute an adequate programme for complex payment firms. Rule-only systems are no longer just inefficient — they're increasingly hard to defend under examination.
How machine learning is rewriting the TM playbook
The shift from rules to AI isn't a single switch — it's a spectrum. Most firms are somewhere in the middle. Here's how the technology has evolved:
What AI does that rules can't
| Capability | Rule-Based | ML-Augmented | AI-Native |
|---|---|---|---|
| Detect known typologies | ✓ Strong | ✓ Strong | ✓ Strong |
| Adapt to new crime patterns | ✗ Weeks/months | ~ Partial | ✓ Real-time |
| Reduce false positives | ✗ 85–97% FP rate | ~ 50–70% FP rate | ✓ 30–40% FP rate |
| Network / relationship analysis | ✗ Single-account only | ~ Limited | ✓ Graph-level |
| Regulatory explainability | ✓ Fully explainable | ✓ Rules still visible | ~ Requires SHAP/LIME |
| Implementation cost | ✓ Low | ~ Medium | ✗ High |
| Handles real-time payments | ✗ Batch typically | ~ Partially | ✓ Millisecond scoring |
Try it: The alert triage simulator
This is what an analyst sees. Three alerts, each with a customer profile and transaction pattern. You decide: close as false positive, request more information, or escalate. Then see how a seasoned analyst would call it.
Trigger: 5 cash deposits in 3 days totalling £18,400. Largest single: £4,100. All branch deposits, different locations.
Context note: Account notes show customer called in last week — "selling personal items after house clearance."
Trigger: £85,000 received from 3 different UK companies. £82,000 transferred out within 6 hours to accounts in UAE and Hong Kong. Balance: £3,000.
Context note: No CDD notes on counterparties. Director is a PEP (local councillor).
Trigger: £6,200 received from 4 different individuals (varying amounts: £800, £1,400, £2,100, £1,900). No money transferred out yet.
Context note: Sender accounts are all personal current accounts. Student recently updated their address — moved back to home city.
What a well-run TM programme actually looks like
Most published frameworks describe what firms should do. Very few describe what it looks like when they do it well. Here's the difference between a TM programme that works and one that just exists:
1. Rule inventory with documented rationale
Every rule has a written typology mapping, performance metrics (alert volume, true positive rate, false positive rate, SAR yield), and a review date. Rules that haven't generated a true positive in 18 months are challenged, not just retained.
2. Tiered analyst routing
Not all alerts go to the same queue. High-score complex alerts go to experienced analysts. Low-score routine alerts go to L1 triage with structured decision aids. This preserves experienced analyst capacity for the cases that need it.
3. Tuning cycles, not tuning panic
Threshold adjustments happen on a documented cycle — quarterly or after significant product changes — not reactively when an examiner asks why alert volume is 800% above industry benchmark. Every tuning decision has a rationale memo.
4. The feedback loop is closed
SAR outcomes, case dispositions, and law enforcement feedback (where received) feed back into rule calibration. TM systems that don't learn from their own outputs degrade year on year.
5. TM is integrated with CDD
Customer risk scores aren't static. A TM alert that's closed as a false positive should still update the customer's behavioural profile. A pattern of false-positive alerts from the same customer may itself be a signal worth investigating.
The FCA has increasingly used skilled persons reviews (Section 166 reviews) to assess TM effectiveness at individual firms. The key metrics they examine: alert volume vs. SAR yield, time-to-close on escalated alerts, documentation quality on closed alerts, and evidence that rules are reviewed and updated against current typologies. A TM programme with a 97% false positive rate and no documented tuning history is a regulatory liability.
Knowledge check
The practitioner's honest verdict
Transaction monitoring is not a solved problem. It is a continuous calibration exercise between detection sensitivity, analyst capacity, and regulatory expectation — played against an adversary who is actively trying to stay invisible.
Rule-based systems built the foundations. They're auditable, explainable, and understood by examiners. They'll remain part of the picture for years. But they are no longer sufficient on their own for firms processing complex or high-volume payment flows.
The firms doing this well aren't the ones who have replaced rules with AI. They're the ones who have built a feedback loop — rules that learn, thresholds that move, analysts who spend their time on genuine risk rather than noise, and a clear audit trail that tells regulators a coherent story.
That's the standard. Most firms aren't there yet. The ones who will get there fastest are the ones who understand that TM effectiveness is a design problem, not a headcount problem.
FinCrimeRadar's free screening tool lets you run live sanctions, PEP, and adverse media checks — the same type of data that feeds context into TM alert triage. See how real-world screening works.