Transaction Monitoring, ML Evolution, and SAR Filing
In Lesson 9, you built the AML framework: three lines of defence, CDD, EDD, PEPs, and beneficial ownership. That framework governs the customer relationship from onboarding onward. This lesson covers what happens during the relationship -- how the bank monitors the millions of transactions flowing through its systems daily, how it identifies suspicious patterns, and what happens when suspicion is confirmed.
Traditional transaction monitoring systems generate an enormous volume of alerts -- and the vast majority are false positives. Industry data consistently reports false positive rates of 95% or higher in rules-based systems. At a typical large bank processing 300,000 alerts per year, with each alert requiring approximately 20 minutes of analyst investigation, the compliance function consumes over 100,000 analyst hours annually -- the equivalent of more than 50 full-time employees doing nothing but reviewing false alerts. This is the problem that machine learning is beginning to solve, with production deployments from vendors such as Featurespace, NICE Actimize, and Temenos demonstrating 50-70% reductions in false positive rates while maintaining or improving detection of genuine suspicious activity.
Rules-Based Transaction Monitoring
Rules-based TM systems use predefined rules to flag transactions that match known money laundering typologies:
Common Typology Rules
| Typology | Rule Logic | What It Detects |
|---|---|---|
| Structuring | Multiple cash deposits just below the reporting threshold (e.g., multiple deposits of $9,500 when the threshold is $10,000) | Deliberate splitting to avoid Currency Transaction Reports |
| Round-tripping | Funds leave the account, pass through intermediaries, and return to the same or related account | Creating the appearance of legitimate business transactions |
| Velocity | Unusually high number of transactions in a short period, inconsistent with customer profile | Rapid movement of funds to obscure the trail |
| Geographic | Transactions involving high-risk jurisdictions (FATF grey/black list countries) | Cross-border laundering through weak AML regimes |
| Peer group anomaly | Transaction volume or value significantly exceeds the average for similar customers | Activity inconsistent with expected business patterns |
Limitations of Rules
Rules are transparent and auditable -- a regulator can examine exactly why an alert was generated. But they have significant weaknesses:
- Static thresholds are easy to circumvent (deposit $9,499 instead of $9,500)
- No adaptive learning -- rules do not improve based on investigation outcomes
- High false positive rates -- 95-99% of alerts are cleared as legitimate activity
- Limited pattern complexity -- rules struggle with multi-step, cross-account typologies
ML-Based Transaction Monitoring
Machine learning approaches address these limitations by learning patterns from historical data:
ML Typology Detection
| ML Approach | How It Works | Advantage Over Rules |
|---|---|---|
| Peer group analysis | Clusters customers by profile (industry, turnover, geography) and flags behaviour that deviates significantly from the peer group | Adapts thresholds to each customer segment rather than using one threshold for all |
| Network analysis | Maps relationships between accounts, customers, and counterparties to identify hidden connections and circular flows | Detects round-tripping and layering across multiple accounts that rules-based systems miss |
| Behavioural anomaly detection | Uses autoencoders or other unsupervised models to learn a customer's "normal" behaviour and flag deviations | Detects novel typologies that no rule has been written for |
| Supervised classification | Trains on labelled alert outcomes (suspicious vs legitimate) to predict which new alerts are likely to be genuine | Directly reduces false positive rate by learning from analyst decisions |
The False Positive Problem
The operational impact of false positives is severe:
| Metric | Rules-Based | ML-Enhanced |
|---|---|---|
| False positive rate | 95-99% | 40-60% (after ML layer) |
| Alert volume (300K/year) | 285K-297K false | 120K-180K false |
| Analyst hours wasted | 95K-99K hours | 40K-60K hours |
| FTE equivalent | 50-52 FTE | 21-31 FTE |
| Cost at GBP 50K/FTE | GBP 2.5M-2.6M | GBP 1.1M-1.6M |
Production deployments from leading vendors have demonstrated these reductions. However, regulators require model governance including explainability, regular validation, and documented evidence that ML does not suppress genuine alerts.
Regulators accept ML in transaction monitoring but require evidence that the models do not create blind spots. Key governance requirements include: documented model development and validation, back-testing against historical SARs, ongoing monitoring of model performance (detection rate, false positive rate, model drift), and the ability to explain to an examiner why a specific alert was or was not generated.
The SAR Filing Workflow
When a transaction monitoring alert or other information indicates potential suspicious activity, the bank must follow a defined workflow:
Alert-to-SAR Pipeline
Alert Generated (rules or ML)
|
v
Triage (L1 analyst -- 5-10 minutes)
|-- Clear: Document rationale, close alert
|-- Escalate: Pass to investigation
v
Investigation (L2 analyst -- 2-8 hours)
|-- Gather supporting data (transaction history,
| customer profile, counterparty analysis)
|-- Document findings
|-- Decision: Suspicious or not suspicious
v
MLRO Review (if suspicious)
|-- Review investigation narrative
|-- Make filing decision (personal liability)
v
SAR Filed with Reporting Authority
|-- UK: National Crime Agency (NCA)
|-- USA: Financial Crimes Enforcement Network (FinCEN)
|-- Australia: Australian Transaction Reports and
| Analysis Centre (AUSTRAC)
|-- EU: National Financial Intelligence Unit (FIU)
v
Consent Regime (UK only)
|-- If bank needs consent to continue transaction
|-- NCA has 7 working days to respond
|-- If no response, bank may proceed
SAR Content Requirements
A SAR must include:
- Subject identification -- full name, date of birth, address, account numbers
- Transaction details -- dates, amounts, counterparties, channels
- Suspicion narrative -- what triggered the suspicion, what makes the activity unusual
- Typology match -- which money laundering typology the activity matches (if identifiable)
- Supporting evidence -- transaction records, KYC documentation, adverse media findings
Filing Timelines
| Jurisdiction | Reporting Body | Timing |
|---|---|---|
| UK | National Crime Agency (NCA) | "As soon as practicable" after suspicion formed |
| USA | FinCEN | Within 30 calendar days of initial detection (60 days if no suspect identified) |
| Australia | AUSTRAC | Within 3 business days for suspicious matter reports |
| EU | National FIU | Varies by member state (typically "without delay") |
The Tipping-Off Prohibition
Tipping-off is the act of informing any person that a SAR has been filed, that an investigation is being considered, or that information has been disclosed to law enforcement. Under UK law (POCA 2002 s333A), tipping-off is a criminal offence in the regulated sector.
What Constitutes Tipping-Off
| Tipping-Off | Not Tipping-Off |
|---|---|
| Telling the customer a SAR has been filed | Explaining general account restrictions ("our terms permit us to restrict accounts") |
| Telling a colleague who has no need to know | Discussing with colleagues who are directly involved in the investigation |
| Hinting that "we have concerns about your account" | Providing general AML training to staff |
| Telling the customer their account is "under investigation" | Declining a transaction without giving a specific reason |
Penalties
On summary conviction (UK): up to three months' imprisonment and/or a fine. On indictment: up to two years' imprisonment and/or an unlimited fine.
Implications for AI Agents
An AI agent operating in banking must be designed with tipping-off safeguards:
- Never include SAR status in customer-facing output -- no chatbot, no email, no report visible to the customer should reference a SAR
- Never include investigation status in general audit trails -- investigation data must be segregated from operational systems
- Never respond to customer queries about account restrictions with specific AML references -- the agent should use generic language ("restrictions applied in accordance with our terms")
- Log all SAR-related data in a restricted-access system -- separate from general CRM or banking systems
If a banking AI agent reveals SAR information to a customer -- whether through a chatbot response, an automated notification, or a system-generated letter -- the bank and potentially the individuals who designed and deployed the system face criminal liability for tipping-off. This is not a compliance nice-to-have. It is a criminal law requirement that must be built into every banking AI system from architecture through deployment.
Exercise 6: TM Alert Investigation
Investigate the following three transaction monitoring alerts. For each, determine whether the activity is suspicious, which typology it matches, and whether a SAR should be filed.
Alert 1: Mohammed Al-Rashid
| Field | Details |
|---|---|
| Customer | Mohammed Al-Rashid, UK resident, retail banking customer |
| Account type | Personal current account |
| Expected activity | Monthly salary deposit (GBP 4,200), regular household expenses |
| Flagged activity | 14 cash deposits over 18 days, amounts ranging from GBP 8,900 to GBP 9,800, total GBP 131,600 |
| Customer explanation (if asked) | Not yet contacted |
| Additional context | Customer has never made cash deposits exceeding GBP 500 in the previous 3 years |
Alert 2: Meridian Trading Ltd
| Field | Details |
|---|---|
| Customer | Meridian Trading Ltd, UK-registered import/export company |
| Account type | Business current account |
| Expected activity | Monthly turnover GBP 200K-400K, payments to/from EU suppliers |
| Flagged activity | 6 wire transfers in one week totalling GBP 2.1M to a company in the UAE, then GBP 1.95M received from a different UAE company 3 days later |
| Customer explanation (if asked) | Not yet contacted |
| Additional context | Meridian has no previously declared trading relationship with UAE counterparties. The receiving UAE company was incorporated 4 months ago |
Alert 3: Amara Diallo
| Field | Details |
|---|---|
| Customer | Amara Diallo, UK resident, private banking customer |
| Account type | High-value personal account (GBP 2.4M balance) |
| Expected activity | Quarterly dividend income, occasional property-related transactions |
| Flagged activity | GBP 180,000 wire transfer to a Senegalese bank account. Recipient name matches a Senegalese government official listed on PEP databases |
| Customer explanation (if asked) | Not yet contacted |
| Additional context | Amara Diallo is the sister of the recipient. The recipient is a current Minister of Agriculture in Senegal |
Your tasks for each alert:
- Which typology does this match (structuring, round-tripping, velocity, geographic, PEP)?
- What additional information would you gather during investigation?
- Would rules-based or ML-based TM be more effective at detecting this pattern? Why?
- Based on the information provided, would you recommend filing a SAR?
- What must you NOT do before the investigation is complete?
Alert 1 -- Mohammed Al-Rashid: Typology: Structuring -- 14 cash deposits, all just below the GBP 10,000 Enhanced CDD threshold, from a customer with no history of cash transactions. Classic structuring pattern. SAR recommendation: Yes -- the pattern is consistent with structuring, and the total amount (GBP 131,600) is material. Rules-based TM would detect this via a structuring rule. Do NOT contact the customer to ask about the deposits before the SAR filing decision -- this could constitute tipping-off.
Alert 2 -- Meridian Trading Ltd: Typology: Round-tripping with geographic risk -- Funds sent to UAE, similar amount returned from a different UAE entity. The recipient company is newly incorporated. This matches layering through shell companies in a jurisdiction with historically weaker AML controls. ML network analysis would be more effective than rules at linking the two UAE entities. SAR recommendation: Yes -- the pattern and the newly incorporated counterparty are strong indicators. Additional investigation: beneficial ownership of both UAE companies, any connection between them.
Alert 3 -- Amara Diallo: Typology: PEP-related -- Transfer to a family member who is a current senior government official (PEP). This is not automatically suspicious -- family transfers are normal. But the PEP connection and the amount require investigation. Additional investigation: Is the amount consistent with a gift or family support? What is the minister's declared income and wealth? Is there adverse media on the minister? SAR recommendation: Requires further investigation -- PEP status alone does not make the transaction suspicious, but the combination of amount, jurisdiction, and PEP status warrants thorough EDD review before a filing decision.
Using the Banking Plugin
The aml-typologies and aml-sar-drafting skills identify money laundering typology matches and draft SAR narratives for MLRO review. Here is a worked example.
Worked example. Thomas Andersen, AML Investigation Analyst at Nordic Shield Bank, is investigating a transaction monitoring alert flagged for structuring. He types:
Analyse this TM alert and draft SAR narrative if warranted:
Customer: Retail banking, salaried employee, GBP 3,800/month
Flagged activity: 14 cash deposits over 18 days
Amounts: GBP 8,900 to GBP 9,800 each
Total: GBP 131,600
Customer history: Zero cash deposits exceeding GBP 500
in previous 3 years
Jurisdiction: UK NCA
The agent routes through aml-typologies and aml-sar-drafting and responds:
GOVERNING STANDARD: AML — UK POCA 2002
DOMAIN: Transaction Monitoring — Typology Analysis + SAR Draft
JURISDICTION: United Kingdom — NCA (National Crime Agency)
TYPOLOGY MATCH
Primary: STRUCTURING (confidence: HIGH)
Pattern: 14 cash deposits averaging GBP 9,400 over 18 days,
all below GBP 10,000 enhanced CDD threshold
Behavioural anomaly: Customer has no prior cash deposit
history. Activity inconsistent with salaried profile.
Total deposited: GBP 131,600
SAR NARRATIVE (DRAFT — requires MLRO review)
Subject deposited GBP 131,600 in cash across 14
transactions over 18 business days. All deposits fell
between GBP 8,900 and GBP 9,800, below the GBP 10,000
threshold. Subject's account history shows monthly salary
of GBP 3,800 and no cash deposits exceeding GBP 500 in
the preceding 36 months. The pattern is consistent with
the structuring typology — deliberate splitting of cash
deposits to avoid enhanced scrutiny thresholds.
IMPORTANT: Do NOT contact the customer regarding this
activity prior to MLRO filing decision (tipping-off
prohibition — POCA 2002 s333A).
NOTE: The professional (MLRO) reviews the narrative and
makes the SAR filing decision; the agent identified the
typology and drafted the narrative. The agent must never
file the SAR or disclose its existence.
Thomas reviews the typology match and narrative accuracy, then escalates the draft to the MLRO for the filing decision -- a step that carries personal criminal liability and must always be made by a human.
Try With AI
Use these prompts in Claude or your preferred AI assistant to deepen your understanding of transaction monitoring and SAR filing.
Prompt 1: Structuring Detection
A bank customer's account shows the following cash deposit
pattern over 4 weeks:
Week 1: GBP 9,500, GBP 9,200, GBP 9,800
Week 2: GBP 9,100, GBP 9,700, GBP 9,400
Week 3: GBP 9,300, GBP 9,600, GBP 9,900
Week 4: GBP 9,000, GBP 9,500, GBP 9,800
The customer's profile says: salaried employee, GBP 3,800/month.
1. What typology does this match?
2. Write the rules-based TM rule that would detect this pattern
(specify threshold, frequency, and lookback period)
3. Why might the rule miss a more sophisticated variant?
4. How would ML peer group analysis detect this without
a fixed threshold?
5. Draft the suspicion narrative for a SAR, covering:
what, when, how much, why it is suspicious, and which
typology it matches
Do NOT include any information that could identify a real person.
What you are learning: Writing a TM rule forces you to think precisely about detection parameters. Writing a SAR narrative forces you to articulate suspicion clearly. Both skills transfer directly to building AI agents that generate investigation narratives -- an agent that produces vague narratives ("the activity seems unusual") is useless, while one that produces specific narratives ("14 cash deposits averaging GBP 9,407 over 18 days, all below the GBP 10,000 threshold, from a customer with zero prior cash deposit history") is operationally valuable.
Prompt 2: Rules vs ML Trade-Offs
A bank is deciding between upgrading its rules-based TM system
or implementing an ML-based system. The current system generates
250,000 alerts per year with a 97% false positive rate.
Compare the two options across these dimensions:
1. False positive reduction potential
2. Detection of novel (previously unknown) typologies
3. Regulatory acceptance and model governance requirements
4. Implementation cost and timeline
5. Explainability (can you tell a regulator WHY an alert
was generated?)
6. Ongoing maintenance burden
For each dimension, give your assessment of rules-based vs ML.
Then recommend: should the bank implement a pure ML system,
a hybrid (ML layer on top of rules), or enhance its rules?
Justify with specific trade-offs.
What you are learning: The rules-vs-ML decision is not binary. Most production deployments use a hybrid approach -- rules for known typologies (high explainability), ML for anomaly detection (high adaptability). Understanding this architectural decision is essential for building banking AI agents that integrate with existing compliance infrastructure rather than replacing it.
Prompt 3: Tipping-Off Scenario Analysis
A bank has filed a SAR on a business customer. The following
situations arise. For EACH, determine:
(a) Does this constitute tipping-off?
(b) If yes, what law is violated and what is the penalty?
(c) What should the person do instead?
1. The relationship manager calls the customer and says:
"We've noticed some unusual activity on your account
and have reported it to the authorities"
2. The compliance officer discusses the SAR with a colleague
in the IT department who has no involvement in the case
3. The AI chatbot responds to a customer query about a frozen
account with: "Your account has been restricted pending
an AML investigation"
4. A branch manager tells a customer: "I'm sorry, I cannot
process this transaction at the moment. Our terms and
conditions allow us to apply restrictions to any account"
5. The bank's automated letter system sends a template letter
stating: "Your account has been referred to our financial
crime team for review"
For scenario 3, explain specifically how this AI system
should have been designed to prevent the tipping-off.
What you are learning: Tipping-off is one of the highest-consequence risks in banking AI design. A single disclosure by an AI system can trigger criminal prosecution. By analysing these scenarios, you build the judgment needed to design AI systems with appropriate safeguards -- restricted-access data architectures, sanitised customer-facing language, and separation between investigation systems and operational systems. This is not a compliance checkbox; it is a criminal law requirement that must inform every architecture decision in banking AI.