# Detecting fraud and money laundering in real time
A $48,000 wire leaves a small business account at 2:14 a.m., headed to a beneficiary bank in a country the customer has never transacted with. The customer usually moves $3,000 to $5,000 during business hours. Within 200 milliseconds, before the payment clears, the bank's monitoring stack has to decide: let it through, hold it, or freeze it and call the customer.
That decision is a data problem. This lesson traces that wire through the layers of detection that modern banks run, and shows why the hardest challenge is not catching bad actors, but not drowning in false alarms.
First, define the terms, because banks treat them differently.
Fraud is theft: someone moves money without authorization. The victim is usually the customer or the bank. Speed matters most, because the money can vanish in minutes.
Money laundering is disguising the origin of money that is already illicit (drug proceeds, corruption, sanctions evasion). The bank is not the direct victim; it is the pipepipeAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition →. Regulators require banks to detect and report it under
Both rely on the same raw material: transaction data, customer data, and behavioral patterns. But fraud detection optimizes for real-time interception, while AML optimizes for building a defensible case a regulator will accept.
The oldest and still most common layer is a rules engine: hard-coded if-then logic written by analysts.
Our $48,000 wire trips several rules at once:
Rules are transparent and easy to explain to an examiner, which regulators like. A classic AML rule is structuring detection: flagging deposits just under the $10,000 reporting threshold that triggers a Currency Transaction Report in the US. If someone deposits $9,500 three days in a row, a rule catches it.
The weakness: rules are brittle and generate enormous noise. A threshold of "$10,000 in a day" flags a wedding caterer and a launderer identically. This is the false-positive problem, and it is the central cost driver of the entire system.
Here is the uncomfortable math. Industry practitioners commonly estimate that more than 90 percent of AML alerts are false positives (the exact figure varies by bank and is hard to verify publicly, so treat it as a widely cited estimate, not a precise statistic).
Every alert becomes work. A human investigator pulls the customer's history, checks the beneficiary, and writes a disposition. That costs money and time. Large banks run investigation teams in the thousands.
So the goal is not "catch everything." It is catch more true positives while cutting false positives, because analyst capacity is finite. A model that flags 10,000 transactions to catch 5 real cases can be worse than a smarter model that flags 200 to catch 4.
Keep that trade-off in mind. Every layer we add exists to sharpen it.
Rules look at one transaction or one account. Network analysis (also called graph analysis) looks at relationships between many accounts.
Money laundering rarely happens in a single account. It moves through chains: a mule account receives funds, splits them, forwards them, and layers them across banks to obscure the trail. Any single hop looks normal. The pattern only appears when you connect the dots.
Graph techniques model accounts as nodes and transactions as edges, then look for suspicious structures:
Our $48,000 wire gets re-examined in context. If the beneficiary account received similar-sized wires from six unrelated senders that same night and immediately forwarded them onward, that is a classic mule pattern, invisible to a single-transaction rule but obvious on the graph.
For a plain-language primer on how criminals structure these flows, the Financial Action Task Force (the global AML standard-setter) publishes accessible material at fatf-gafi.org.
🎬 [VIDEO: "How Money Laundering Works" — youtube.com — a clear animated explainer of the place, layer, integrate model behind AML detection]
Rules encode what we already know. Machine learning (ML) finds patterns we did not write down.
Two flavors matter here.
Supervised learning trains on labeled history: past transactions marked fraud or not-fraud. The model learns combinations of features (amount, time, device, location, beneficiary risk, account age) that correlate with confirmed fraud. It then scores new transactions from 0 to 1.
The catch: supervised models need clean labels. Fraud you caught is labeled; fraud you missed is silently labeled "good." The model inherits your blind spots.
Unsupervised learning needs no labels. It flags anomalies: behavior that deviates from a customer's own baseline or from peers. Our 2:14 a.m. wire is anomalous against the customer's own history, so an unsupervised model surfaces it even if that exact pattern was never seen before.
Modern stacks combine all three layers. A common design routes a transaction through rules first (fast, cheap), then scores survivors with ML, then enriches high scores with network features before a human ever sees them.
Here is a simplified scoring step:
# Combine signals into a single risk score
def score_transaction(txn, customer, graph):
rule_hits = count_rule_triggers(txn, customer) # e.g. 3
ml_score = fraud_model.predict_proba(txn) # 0.0 - 1.0
graph_risk = graph.mule_pattern_score(txn.payee) # 0.0 - 1.0
risk = (0.3 * min(rule_hits / 5, 1)
+ 0.4 * ml_score
+ 0.3 * graph_risk)
if risk > 0.85:
return "BLOCK_AND_REVIEW"
elif risk > 0.5:
return "HOLD_FOR_ANALYST"
return "ALLOW"The weights are not arbitrary. Banks tune them against the false-positive tax, deciding how many analyst hours each threshold will cost.
An ML model can be accurate and still be unusable, because banks must explain decisions to regulators and, when they block a legitimate payment, to customers.
If a model freezes a customer's wire, the bank cannot say "the neural network felt uneasy." It needs reason codes: "flagged for unusual amount, new beneficiary country, off-hours timing." This is why interpretable techniques and tools like SHAP (a method that attributes a score to each input feature) sit alongside the models. Regulators increasingly expect model governance, documentation, and bias testing, not just accuracy.
This is the tension of the whole field: the most powerful models are often the least explainable, and banking cannot fully trade explainability for performance.
Knowledge check
1. What is the fundamental distinction between fraud and money laundering as detection problems?
2. In a money laundering scenario, what role does the bank typically play?
3. Why do regulators tend to favor rules engines over more opaque detection methods?
4. Select ALL correct answers about why the $48,000 wire would trip a rules engine.
Select all the correct answers.
5. Select ALL correct answers about what fraud and money laundering detection have in common.
Select all the correct answers.
Detection is only half the system. Once our wire is flagged, a workflow kicks in.
For fraud, the bank may hold the payment and trigger a step-up authentication: a call or app prompt to confirm the customer really initiated it. If confirmed, the wire releases. If not, it is blocked and the mule account may be reported.
For AML, if an investigator confirms suspicion, the bank files a Suspicious Activity Report (SAR), a confidential report to financial regulators (FinCEN in the US). Crucially, the bank usually cannot tell the customer a SAR was filed ("tipping off" is prohibited). The customer sees nothing; the report goes to authorities who may connect it to other banks' filings.
This is why data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → matters so much. A SAR built on messy data gets ignored. A well-supported one, enriched with network evidence, becomes actionable intelligence.
One bank sees only its own slice of a laundering network. The mule chain often crosses institutions. That structural blind spot is driving information sharing arrangements and consortium models where banks contribute signals to detect cross-bank patterns, within strict privacy rules.
Emerging techniques like privacy-preserving analytics (analyzing shared risk signals without exposing raw customer data) aim to let banks collaborate without violating data protection law. This is an active frontier in 2026, not a solved problem.