INTRODUCTION: THE ANTI-MONEY LAUNDERING OBLIGATION

In Lessons 8.1 and 8.2, we built the fraud detection infrastructure—anomaly detection on consent velocity, device fingerprinting, and behavioral biometrics. These systems detect operational fraud: a compromised TPP credential, a stolen session token, or a PSU tricked into granting malicious consent. However, a significant portion of financial crime is not immediately apparent from individual events. It manifests as a pattern across multiple transactions, multiple accounts, and multiple banks.

Money Laundering (ML) and Terrorist Financing (TF) are complex, multi-layered crimes. A single payment is legitimate; a thousand payments over a month, structured to avoid reporting thresholds, is not. A payment to an account in a high-risk jurisdiction is not necessarily suspicious; a series of payments to a jurisdiction with no apparent business purpose, followed by immediate transfers to other accounts, is.

The regulatory framework for AML/CFT is global and stringent:

• FATF (Financial Action Task Force) Recommendations: The global standard for AML/CFT. Recommendation 10 requires financial institutions to conduct Customer Due Diligence (CDD). Recommendation 16 requires reporting of suspicious transactions. Recommendation 6 requires sanctions screening.

• EU 6th Anti-Money Laundering Directive (6AMLD) : Criminalises money laundering and requires financial institutions to have robust AML controls.

• UK Money Laundering Regulations 2017: Implement FATF recommendations in the UK. Requires registration with the FCA, CDD, and Suspicious Activity Reporting (SAR).

• EBA Guidelines on AML/CFT (EBA/GL/2022/01) : Provide detailed guidance on how to implement AML/CFT controls in the EU.

For an ASPSP providing Open Banking APIs, AML/CFT compliance is non-negotiable. The CMA Order 2017 (Article 58) can be used to enforce AML controls if the API becomes a vector for money laundering.

This lesson deconstructs the AML/CFT compliance engine. We define the AML Transaction Monitoring Rules that detect suspicious patterns: (1) Structuring (splitting large transactions to avoid reporting thresholds), (2) Velocity (rapid movement of funds), (3) Circular Transactions (funds moving in a cycle), (4) Beneficiary Risk (payments to high-risk jurisdictions or entities), and (5) Anomalous Amounts (amounts just below reporting thresholds). We implement these rules using a Rule Engine (e.g., Drools, or a decision tree). We formalise the Sanctions and PEP Screening process: we maintain a watchlist database of sanctioned entities, politically exposed persons (PEPs), and adverse media. We implement fuzzy matching algorithms (Levenshtein distance, Jaro-Winkler, Soundex) to match customer names against the watchlist, minimising false positives. We also design the Suspicious Activity Reporting (SAR) pipeline: when a rule is triggered, the case is escalated to an AML investigator, who reviews the transaction, and if suspicious, submits an SAR to the Financial Intelligence Unit (FIU) within the regulatory timeframe (typically 24-48 hours).

We will quantify the latency budget for AML screening: watchlist lookup (2ms), fuzzy matching (5ms), rule engine execution (2ms), and case escalation (10ms). The total overhead is under 20ms, well within the 850ms UK SLA. We will also derive the false positive rate for the rule engine (which is typically 5-10%, requiring manual review) and the false negative rate (which must be < 0.1% to avoid regulatory fines).

LEARNING OBJECTIVES

1. Define the AML Transaction Monitoring Rules—categorising the five rule types: (1) Structuring (payments < £10,000 but multiple in short time), (2) Velocity (sudden increase in payment volume), (3) Circular Transactions (funds moving in a cycle), (4) Beneficiary Risk (payments to high-risk countries or sanctioned entities), and (5) Anomalous Amounts (amounts just below reporting thresholds). We will derive the exact SQL-like rules for each type.

2. Implement the Rule Engine Architecture—designing a forward-chaining rule engine (like Drools) that evaluates rules against the transaction context, with a latency of under 2ms (p95). We will formalise the Rete algorithm (the underlying matching engine) and prove that its complexity is O(α * β) where α is the number of facts and β is the number of rules.

3. Design the Sanctions and PEP Watchlist—defining the watchlist data model: { name, alias, date_of_birth, nationality, sanction_type, risk_score, last_updated }. We will implement fuzzy matching using Levenshtein distance (for exact spelling variations) and Soundex (for phonetic variations), and we will set the threshold to maximise the F1-score.

4. Formalize the Screening Process—defining the screening pipeline: input (customer name, DOB, nationality) → fuzzy matching (top 10 candidates) → exact matching on DOB and nationality → risk score calculation. We will derive the probability of a false positive (matching a legitimate customer to a sanctioned entity) and prove that it is < 0.01%.

5. Quantify the AML Screening Latency—measuring the time for watchlist lookup (2ms), fuzzy matching (5ms), rule engine execution (2ms), and case escalation (10ms), and proving that the total overhead is under 20ms (p95).

6. Design the Suspicious Activity Reporting (SAR) Pipeline—defining the life-cycle of a SAR: (1) Rule Trigger → (2) Case Creation → (3) Investigation → (4) Decision (Report or Not) → (5) Submission to FIU. We will quantify the regulatory timeline (report within 24 hours of suspicion) and the internal SLA (investigation completed within 48 hours).

PART 1: THE AML TRANSACTION MONITORING RULES — The Regulatory Pattern Library

AML rules are a set of Boolean conditions that, when evaluated against a transaction (or a sequence of transactions), determine whether the transaction is suspicious. We define five core rule types.

1.1 Structuring (Smurfing)

Structuring is the practice of splitting a large transaction into multiple smaller transactions to avoid the reporting threshold (typically £10,000 in the UK, $10,000 in the US).

Rule Definition:

IF (Number_of_Payments > 3 in 24 hours) 
AND (SUM(Amount) > 9,500) 
AND (MAX(Amount) < 10,000) 
AND (Same_Beneficiary = True) 
THEN Alert(Structuring)

Mathematical Formula:
Let P = {p1, p2, ..., pn} be the set of payments in the last 24 hours. The structuring score is:

S_struct = n × (1 - min(Amount_i) / max(Amount_i))

If S_struct > 0.5, flag as suspicious.

1.2 Velocity (Sudden Increase)

A sudden increase in payment volume is a strong indicator of fraud or money laundering.

Rule Definition:

IF (Current_Hour_Rate > 3 × Average_Hour_Rate) 
AND (Current_Hour_Rate > 5) 
THEN Alert(Velocity)

Mathematical Formula:
Let λ be the average hourly rate over the last 7 days. Let λ_current be the current hourly rate.

Z = (λ_current - λ) / sqrt(λ) (Poisson standardisation)

If Z > 3, flag as suspicious.

1.3 Circular Transactions

A circular transaction occurs when funds move from Account A → B → C → A, creating a cycle.

Rule Definition:

IF (Cycle_Exists(A, B, C, D) in 7 days) 
THEN Alert(Circular)

Graph Algorithm:
We construct a directed graph where nodes are accounts and edges are payments. We run a depth-first search (DFS) to detect cycles. If a cycle is found, alert.

Complexity: O(V + E) where V is the number of accounts and E is the number of payments.

1.4 Beneficiary Risk

Payments to high-risk jurisdictions or sanctioned entities are suspicious.

Rule Definition:

IF (Beneficiary_Country in High_Risk_List) 
OR (Beneficiary_Name in Sanctions_List) 
THEN Alert(High_Risk)

High-Risk List: Countries identified by FATF as “High-Risk Jurisdictions Subject to a Call for Action” (e.g., Iran, North Korea, Myanmar). The list is updated quarterly.

1.5 Anomalous Amounts

Payments just below the reporting threshold (£9,900) are suspicious.

Rule Definition:

IF (Amount > 9,500 AND Amount < 10,000) 
THEN Alert(Just_Below_Threshold)

PART 2: THE RULE ENGINE ARCHITECTURE — Drools and the Rete Algorithm

We implement the AML rules using a rule engine (e.g., Drools, IBM ODM, or a custom decision tree). The rule engine evaluates the rules against the transaction context (facts) and generates alerts.

The Rete Algorithm:

The Rete algorithm is a pattern-matching algorithm that optimises the evaluation of rule-based systems. It constructs a directed acyclic graph (DAG) where nodes represent patterns (conditions) and edges represent the flow of facts.

Complexity:

• Naive evaluation: O(F × R) where F is the number of facts and R is the number of rules.

• Rete: O(α × β) where α is the number of facts per rule and β is the number of rules. For typical AML workloads (100 rules, 1,000 facts), this is O(1,000).

Latency: The rule engine evaluates the facts and generates alerts in under 2ms (p95) for 100 rules.

PART 3: SANCTIONS AND PEP SCREENING — Watchlist Management and Fuzzy Matching

Sanctions and PEP screening involves checking the customer’s name against a watchlist of sanctioned entities and politically exposed persons.

3.1 The Watchlist Data Model

Sanctions_Entry {
    id: UUID,
    full_name: String,
    aliases: String[],
    date_of_birth: Date,
    nationality: String,
    sanction_type: String,  // e.g., "UN", "US", "UK"
    risk_score: Float,      // 0.0 to 1.0
    last_updated: Date
}

3.2 Fuzzy Matching Algorithms

We use three fuzzy matching algorithms and combine their scores:

1. Levenshtein Distance (edit distance): d(s1, s2) = minimum number of single-character edits.
   Sim_Lev = 1 - d / max(|s1|, |s2|)

2. Jaro-Winkler: Gives higher weight to prefix matches.
   Sim_JW = Sim_J + 0.1 × l × (1 - Sim_J) where l is the prefix length.

3. Soundex: Phonetic encoding. Soundex(s1) == Soundex(s2).

Combined Score:
Sim_Total = 0.4 × Sim_Lev + 0.4 × Sim_JW + 0.2 × Soundex_Match

Threshold: If Sim_Total > 0.85, we flag a potential match.

3.3 False Positive Rate

The false positive rate for sanctions screening is approximately 1% (1 in 100 names matches a watchlist entry incorrectly). This is acceptable, as the match is reviewed by a human investigator.

PART 4: THE SUSPICIOUS ACTIVITY REPORTING (SAR) PIPELINE

The SAR pipeline is the process from initial alert to final submission to the FIU.

+-----------------------------------------------------------------------+
|                  SUSPICIOUS ACTIVITY REPORTING (SAR) PIPELINE          |
+-----------------------------------------------------------------------+
|                                                                        |
|  Stage 1: Rule Trigger                                                 |
|  +------------------------------------------------------------------+  |
|  |  • An AML rule fires (e.g., structuring detected).               |  |
|  |  • An alert is generated with the transaction details.           |  |
|  |  • Latency: < 20ms (API request).                               |  |
|  +------------------------------------------------------------------+  |
|          |                                                            |
|          v                                                            |
|  Stage 2: Case Creation                                               |
|  +------------------------------------------------------------------+  |
|  |  • A case is created in the AML case management system.          |  |
|  |  • The case is assigned to an AML investigator.                  |  |
|  |  • Latency: < 100ms (batch).                                     |  |
|  +------------------------------------------------------------------+  |
|          |                                                            |
|          v                                                            |
|  Stage 3: Investigation                                               |
|  +------------------------------------------------------------------+  |
|  |  • The AML investigator reviews the transaction.                 |  |
|  |  • They check customer history, transaction graph, and risk.     |  |
|  |  • Latency: 24-48 hours (human).                                |  |
|  +------------------------------------------------------------------+  |
|          |                                                            |
|          v                                                            |
|  Stage 4: Decision                                                    |
|  +------------------------------------------------------------------+  |
|  |  • If suspicious → Report.                                       |  |
|  |  • If not suspicious → Close case.                               |  |
|  |  • Latency: N/A (decision).                                     |  |
|  +------------------------------------------------------------------+  |
|          |                                                            |
|          v                                                            |
|  Stage 5: SAR Submission                                              |
|  +------------------------------------------------------------------+  |
|  |  • The AML investigator submits the SAR to the FIU.              |  |
|  |  • The submission includes transaction details, customer info.   |  |
|  |  • Latency: < 1 hour (after decision).                          |  |
|  +------------------------------------------------------------------+  |
|                                                                        |
|  Regulatory Timeline:                                                  |
|  - Suspicion must be reported within 24 hours.                       |
|  - Investigation must be completed within 48 hours.                 |
+-----------------------------------------------------------------------+

PART 5: LATENCY BUDGET AND PERFORMANCE

Conclusion: The AML screening adds < 20ms of latency to the API request, which is well within the 850ms UK SLA.

CLOSING — THE AML COMPLIANCE ENGINE

The AML/CFT compliance engine is a critical component of the Open Banking infrastructure. The transaction monitoring rules detect structured payments, velocity anomalies, circular transactions, and payments to high-risk entities. The sanctions and PEP screening ensures that the ASPSP does not facilitate transactions with sanctioned individuals. The SAR pipeline ensures that suspicious transactions are reported to the FIU within the regulatory timeframe.

Operational Risk: If the AML rules generate too many false positives (e.g., 20%), the investigation team will be overwhelmed. The rule thresholds must be calibrated to balance detection (sensitivity) against false positives (specificity). The optimal threshold is derived from the ROC curve (as in Lesson 8.1).

Key Takeaways:

• Rules: Structuring, Velocity, Circular, Beneficiary Risk, Anomalous Amounts.

• Rule Engine: Drools / Rete algorithm, latency < 2ms.

• Sanctions Screening: Fuzzy matching (Levenshtein, Jaro-Winkler, Soundex), latency < 5ms.

• SAR Pipeline: Trigger → Case → Investigation → Report.

• Regulatory Timeline: Report within 24 hours.

Transition to Lesson 8.4: With the AML rule engine and watchlist screening in place, we now turn to Machine Learning for Fraud Detection—how to build supervised (Random Forest, XGBoost) and unsupervised (Isolation Forest, Autoencoders) models to detect emerging fraud patterns that are not covered by static rules. We will derive the feature engineering pipeline, the model training and retraining process, and the online scoring architecture (with < 10ms latency).