Important Note : First, apologies for the gap in newsletters over the past month.
While tracking AI developments, one thing became clear: real enterprise adoption is moving far slower than the hype suggests. That shift pushed me to focus on building something practical—aimed at solving real problems with personal finance, not just riding the noise.
The project is still a work in progress. If it proves fruitful, I’ll share the full breakdown—what worked, what didn’t, and a clear guide on how to build something similar. More updates soon as I test this in a live environment. Now, Let’s get back to it.
Quick Recap: Traditional AML rules flag known patterns. Unsupervised learning finds the patterns you didn't know to look for—clustering transactions to reveal hidden networks, unusual behaviors, and emerging fraud schemes that rule-based systems miss.
A major European bank's AML team was confident. They had 47 rules detecting suspicious activity. Transaction over €10K? Flag it. Multiple cross-border transfers in 24 hours? Flag it. Cash deposits followed by wire transfers? Flag it.
Then the regulator arrived with a spreadsheet.
"Why didn't you catch this network?" the regulator asked, pointing to 200+ transactions across 18 months. The bank's compliance officer reviewed the data: none triggered alerts. Amounts were just under thresholds. Timing was irregular. Countries weren't on watchlists.
"How did you find this?" the officer asked.
"We didn't write a rule," the regulator said. "We just looked for accounts that behaved differently than everyone else. These 47 accounts cluster together when you graph their transaction patterns. They don't match your typical customer behavior. That's the signal."
The bank had spent 18 months building better rules. The regulator had found the pattern in 2 hours using unsupervised learning—no labels, no prior fraud examples, just "show me what's unusual."
This is the reality of modern AML: The most dangerous patterns aren't the ones you know. They're the ones criminals invented last month that don't match any rule you wrote. Unsupervised learning finds them by asking a simpler question: "What's different?"
Why Unsupervised Learning Matters for AML
The Rule-Based Problem
Traditional AML systems rely on supervised learning and rules: "If transaction matches known fraud pattern X, flag it." This works when you know what fraud looks like.
The limitation: Criminals adapt. They learn your thresholds, avoid your watchlists, and design transactions that slip past every rule.
What this means in practice:
A bank flags transactions over $10K. Criminals structure 15 transactions at $9,800 each.
A bank flags rapid cross-border transfers. Criminals wait 72 hours between each transfer.
A bank flags countries on OFAC lists. Criminals route through non-listed intermediaries.
Rules assume fraud is static. Fraud is dynamic.
What Unsupervised Learning Does Differently
Unsupervised learning doesn't look for known patterns. It looks for anomalies—things that don't fit normal behavior.
Core concept: Instead of asking "Does this match fraud pattern X?", unsupervised learning asks:
"What does normal customer behavior look like across thousands of accounts?"
"Which accounts behave differently from that normal pattern?"
"Do those unusual accounts cluster together, suggesting coordination?"
Why this matters in BFSI: Regulators (FinCEN, EBA, FCA, 2025-2026 guidance) increasingly expect banks to detect emerging threats, not just known patterns. Unsupervised learning is how banks find what they don't yet know to look for.
How Unsupervised Learning Works Conceptually
Step 1: Represent Transactions as Numbers
Every transaction becomes a set of features (attributes that describe it):
Amount
Frequency (transactions per week)
Geographic spread (number of countries involved)
Time patterns (weekday vs. weekend, business hours vs. odd hours)
Counterparty diversity (number of unique recipients)
Account age
Example: A normal customer might have:
Average transaction: $450
Frequency: 8 transactions/month
Geographic spread: 1 country (domestic only)
Time pattern: 85% during business hours
Counterparties: 12 unique recipients
Account age: 4 years
An unusual customer might have:
Average transaction: $9,200
Frequency: 47 transactions/month
Geographic spread: 9 countries
Time pattern: 60% outside business hours
Counterparties: 200+ unique recipients
Account age: 3 months
Both accounts exist. Neither triggers classic rules. But one is clearly unusual.
Step 2: Clustering (Finding Groups)
Clustering is the process of grouping similar accounts together based on their features.
How it works: Imagine plotting every account on a graph where:
X-axis = Transaction frequency
Y-axis = Average transaction amount
Normal retail customers cluster together in one area (low frequency, low amount). Business accounts cluster in another (moderate frequency, moderate-to-high amount). High-net-worth individuals cluster elsewhere (low frequency, high amount).
Then you see outliers: Accounts that don't fit any cluster. They're in empty space on the graph—far from typical behavior.
Why this matters in BFSI: Those outliers are investigation candidates. They're not necessarily fraud, but they're unusual enough to warrant human review.
The key insight: You didn't need labeled fraud data to find them. You just needed to know what "normal" looks like—and clustering reveals that automatically.
Step 3: Anomaly Detection (Finding the Unusual)
Anomaly detection extends clustering by asking: "Which accounts are far from any normal cluster?"
Two types of anomalies:
Isolated anomalies: Single account behaving unusually (e.g., sudden spike in transaction volume after 2 years of dormancy)
Clustered anomalies: Group of accounts behaving unusually together (e.g., 15 accounts all sending money to the same offshore entity, none individually suspicious)
Why this matters in BFSI: Type 2 (clustered anomalies) reveals networks—the most dangerous AML risk. These are coordinated fraud rings, money laundering operations, or organized schemes.
How it works: If 20 accounts cluster together but that cluster is far from normal customer behavior, the system flags the entire network for investigation.
Example from production (2024): A large UK bank discovered a network of 34 "students" opening accounts, receiving small deposits, then wiring funds to the same cryptocurrency exchange. None triggered individual alerts (small amounts, legitimate-looking profiles). Clustering revealed they were all connected—same deposit patterns, same timing, same final destination. Turned out to be a money laundering front.
How Unsupervised Learning is Implemented in Practice
Workflow: From Data to Investigation
Step 1: Feature Engineering (Define What to Measure)
Banks choose which transaction attributes matter:
Transaction amounts (mean, median, variance)
Frequency (daily, weekly, monthly counts)
Geographic diversity (number of countries, high-risk jurisdictions)
Counterparty analysis (number of unique recipients, relationship longevity)
Time patterns (business hours vs. off-hours, weekday vs. weekend)
Velocity (rate of change in transaction volume)
Key decision: Which features best distinguish normal from unusual in your customer base? Retail banks prioritize different features than investment banks.
Step 2: Run Clustering Algorithm
Common algorithms:
K-means: Divides accounts into K groups based on similarity
DBSCAN: Finds clusters of varying shapes and flags outliers that don't fit any cluster
Isolation Forest: Specifically designed to find anomalies by isolating unusual data points
Why DBSCAN often wins in AML: It doesn't require pre-specifying the number of clusters (K-means does), and it naturally identifies outliers as "noise" points that don't belong to any cluster.
What banks actually deploy (2025-2026):
DBSCAN for transaction-level anomaly detection
Isolation Forest for account-level risk scoring
Graph-based clustering (e.g., Louvain algorithm) for network detection
Step 3: Generate Investigation Queue
Unsupervised learning outputs a risk score or anomaly flag for each account. Banks rank accounts by how far they deviate from normal and send the top N% to investigators.
Typical threshold: Top 1-5% of unusual accounts go to human review.
Why this matters: AML teams can't investigate everyone. Unsupervised learning prioritizes the most unusual accounts—those with the highest likelihood of hidden risk.
Step 4: Human Oversight (The Critical Layer)
Unsupervised learning doesn't make decisions. It generates investigation leads.
Why this matters in BFSI: Regulators require human judgment for AML decisions. Algorithms can suggest; humans must decide.
What investigators do:
Review flagged accounts
Examine transaction history in detail
Check external data sources (OFAC lists, adverse media)
Determine if behavior is suspicious or benign (e.g., legitimate business expansion vs. structuring)
File Suspicious Activity Reports (SARs) if warranted, or clear the account
Feedback loop: Investigator decisions feed back into the model. If an account flagged as anomalous is cleared as legitimate, that information refines future clustering (e.g., "accounts with this pattern are actually normal for high-growth startups").
How It Affects All Stakeholders
For AML Investigators
Before unsupervised learning:
Reviewed alerts from 47 rules
High false positive rate (95%+ of alerts were false alarms)
Missed novel fraud patterns (no rule = no alert)
With unsupervised learning:
Receive prioritized queue of genuinely unusual accounts
Lower false positive rate (anomalies are statistically rare)
Catch emerging fraud schemes early (before rules are written)
The practical impact: Investigators spend less time clearing false alarms and more time investigating real threats.
For Compliance Officers
Value: Demonstrates to regulators that the bank is proactive, not just reactive.
Regulatory expectation (2025-2026): FinCEN, EBA, and FCA increasingly expect banks to use advanced analytics (including unsupervised learning) to detect emerging AML threats.
Why this matters: During audits, compliance can point to unsupervised learning as evidence of "going beyond minimum requirements." Shows the bank isn't just checking boxes—it's actively hunting for unknown risks.
For Risk Committees
What they care about: "Are we exposed to AML risks we don't see?"
Unsupervised learning answers that question: "Here are the accounts that don't fit our normal customer behavior. We're investigating them."
The governance value: Risk committees want assurance that the bank is looking for unknown threats, not just known ones. Unsupervised learning provides that assurance.
For Data Scientists / ML Engineers
Challenge: Unsupervised learning is harder to validate than supervised learning.
Why: No ground truth labels. You can't calculate "accuracy" when you don't know what fraud looks like in advance.
How banks validate (2025-2026 practice):
Precision of investigation outcomes: Of flagged accounts, what % resulted in SARs? (Target: 10-20% SAR rate is considered good)
Coverage of known fraud: When fraud is discovered through other means (e.g., customer complaint), was it flagged by the model? (Target: 80%+ coverage)
Comparison to rule-based systems: Does unsupervised learning catch cases that rules missed?
The practical impact: Data scientists must design validation frameworks without traditional accuracy metrics. This is unfamiliar territory for many ML teams.
For Regulators
What they want: Evidence that banks are detecting emerging threats, not just historical patterns.
Why unsupervised learning matters: It shows the bank is actively searching for the unknown, not passively waiting for known fraud to appear.
Regulatory scrutiny (2025-2026): Regulators increasingly ask:
"How do you detect fraud patterns you haven't seen before?"
"What's your process for finding coordinated networks?"
"How do you validate that your system catches novel schemes?"
Unsupervised learning is the answer to all three questions.
Regulatory & Practical Context (2025-2026 Baseline)
What Regulators Expect
FinCEN (US, 2025 guidance):
Banks must use risk-based approaches to AML monitoring
Advanced analytics (including unsupervised learning) increasingly expected for large banks
Validation of detection systems required (can you prove your system works?)
EBA (Europe, 2026 guidance):
Banks must detect emerging ML/TF risks (money laundering / terrorist financing)
Static rule-based systems alone are insufficient for large, complex banks
Annual AML system audits must demonstrate effectiveness
FCA (UK, 2025 guidance):
Financial crime detection must be "proportionate to risks faced"
For high-risk banks (international, high-volume), advanced analytics expected
Suspicious Activity Reports must show evidence of thorough investigation
The regulatory shift: Regulators aren't mandating unsupervised learning explicitly, but they're making it nearly impossible to meet expectations without it. "Detect emerging threats" is code for "use advanced analytics."
Production Challenges (What Banks Actually Face)
Challenge 1: Feature Selection is Hard
Choosing the right transaction features makes or breaks the model. Include too many features (e.g., 50+ attributes), and everything looks unusual. Include too few (e.g., just amount and frequency), and you miss coordinated networks.
What works (2025-2026 practice):
Start with 8-12 core features (amount, frequency, geography, counterparties, timing)
Add domain-specific features (e.g., for trade finance: shipment timing, commodity type)
Iteratively refine based on investigator feedback
Challenge 2: Explaining Anomalies to Investigators
Unsupervised learning flags accounts as "unusual." But investigators need to know why the account is unusual.
The solution: Provide feature importance alongside anomaly scores.
Example output:
Account ID: 47291
Anomaly Score: 0.87 (top 2% most unusual)
Why unusual:
Transaction frequency: 340% above cluster average
Geographic spread: 12 countries (typical: 1-2)
Counterparties: 180 unique (typical: 5-15)
Now investigators understand what makes the account anomalous and can focus their review accordingly.
Challenge 3: Managing False Positives
Unsupervised learning reduces false positives compared to rule-based systems, but doesn't eliminate them.
Why: "Unusual" ≠ "fraudulent." High-growth startups, new business lines, and legitimate international operations all look unusual compared to typical retail customers.
How banks manage this (2025-2026):
Segment customers first: Run separate clustering for retail, business, high-net-worth, and institutional customers. What's unusual for retail may be normal for business accounts.
Incorporate investigator feedback: If an account is cleared as legitimate, adjust clustering to recognize similar accounts as normal in the future.
Use multi-tier systems: Unsupervised learning generates leads → rules filter out known-legitimate patterns → remaining accounts go to human review.
Looking Ahead (2026-2030)
Trend 1: Graph-Based Network Detection (2026-2027)
Current clustering looks at individual accounts. Next-generation systems look at networks—the connections between accounts.
How it works: Build a graph where accounts are nodes and transactions are edges. Cluster the graph to find tightly connected subgraphs (groups of accounts transacting primarily with each other).
Why this matters: Money laundering often involves layering—moving money through multiple accounts to obscure the source. Graph clustering reveals these networks even when no single account looks suspicious.
What's coming: Banks are deploying graph-based AML systems (using Neo4j, TigerGraph, or AWS Neptune) to detect coordinated fraud rings.
Trend 2: Real-Time Anomaly Detection (2027-2028)
Current systems run nightly batch jobs (cluster all accounts, flag anomalies, generate investigation queue).
The shift: Real-time systems that flag anomalies as transactions occur.
Why this matters: Catching fraud in real-time allows banks to block transactions before money leaves the system. Batch detection catches fraud after the fact, when funds are already gone.
The challenge: Real-time clustering is computationally expensive. Banks are exploring incremental clustering algorithms that update clusters continuously instead of recalculating from scratch.
Trend 3: Hybrid Supervised + Unsupervised Models (2028-2030)
The future isn't pure unsupervised learning—it's hybrid systems that combine both approaches:
Supervised models catch known fraud patterns (fast, accurate for familiar threats)
Unsupervised models catch novel patterns (slower, exploratory, detects unknowns)
How they work together:
Supervised model flags high-confidence fraud (e.g., matches known laundering patterns)
Unsupervised model flags unusual accounts that don't match any known pattern
Investigators review both queues, prioritized by risk score
Why this matters: Supervised learning is good at what it knows. Unsupervised learning finds what supervised learning can't. Together, they provide comprehensive coverage.
HIVE Summary
Key takeaways:
Unsupervised learning finds AML threats by detecting anomalies—accounts that don't fit normal customer behavior—without needing labeled fraud data.
Clustering groups similar accounts together; outliers (accounts far from any cluster) become investigation candidates.
Networks matter: Coordinated fraud rings often involve multiple accounts that individually look normal but cluster together in unusual ways.
Unsupervised learning complements rule-based systems by catching emerging threats that don't match known patterns.
Start here:
If your AML system is purely rule-based: Add unsupervised learning to detect novel patterns. Start with DBSCAN or Isolation Forest on transaction-level features (amount, frequency, geography).
If you're already using unsupervised learning: Segment customers (retail, business, institutional) before clustering to reduce false positives. Run separate models for each segment.
If investigators complain about false positives: Provide feature importance with anomaly scores so investigators understand why an account was flagged (e.g., "transaction frequency 340% above normal").
If regulators ask how you detect emerging threats: Point to unsupervised learning as evidence of proactive detection. Show validation metrics (% of flagged accounts that resulted in SARs).
Looking ahead (2026-2030):
Graph-based clustering (2026-2027) will detect coordinated networks by analyzing connections between accounts, not just individual behavior.
Real-time anomaly detection (2027-2028) will shift from nightly batch jobs to flagging unusual transactions as they occur, enabling in-flight intervention.
Hybrid supervised + unsupervised systems (2028-2030) will combine both approaches: supervised models for known fraud, unsupervised for unknown threats.
Open questions:
How do banks validate unsupervised models when there's no ground truth? Current metrics (SAR rate, coverage) are imperfect proxies for model effectiveness.
What's the right balance between false positives (catching legitimate unusual behavior) and false negatives (missing real fraud)? Banks are still calibrating thresholds.
Can unsupervised learning scale to real-time detection without prohibitive compute costs? Graph clustering is expensive; incremental algorithms are still experimental.
Jargon Buster
Unsupervised Learning: Machine learning that finds patterns in data without labeled examples (no pre-identified fraud cases needed). Why it matters in BFSI: Enables detection of emerging AML threats that don't match known fraud patterns—critical for regulatory compliance.
Clustering: Grouping similar data points together based on their features (e.g., grouping accounts with similar transaction patterns). Why it matters in BFSI: Reveals which accounts behave normally and which are outliers, guiding AML investigations.
Anomaly Detection: Identifying data points that deviate significantly from normal behavior (outliers). Why it matters in BFSI: Flags accounts for AML review that rule-based systems would miss—accounts that are unusual but don't match known fraud patterns.
DBSCAN (Density-Based Spatial Clustering): Clustering algorithm that groups data based on density and identifies outliers as points that don't belong to any cluster. Why it matters in BFSI: Preferred for AML because it automatically flags anomalies without requiring pre-specified cluster counts.
Feature Engineering: Selecting and defining measurable attributes (features) that describe transactions (e.g., amount, frequency, geography). Why it matters in BFSI: Quality of features determines model effectiveness—choosing the right features is critical for finding real AML threats vs. noise.
Isolation Forest: Anomaly detection algorithm that isolates unusual data points by randomly splitting the dataset. Why it matters in BFSI: Specifically designed for anomaly detection; faster than clustering for large datasets and effective at finding rare, unusual accounts.
False Positive: An alert flagging legitimate activity as suspicious. Why it matters in BFSI: High false positive rates waste investigator time and delay detection of real threats; reducing false positives is a key goal of unsupervised learning.
Graph Clustering: Clustering accounts based on their transaction connections (who sends money to whom), not just individual behavior. Why it matters in BFSI: Detects coordinated fraud networks where individual accounts look normal but their connections reveal organized schemes.
Fun Facts
On Anomaly Detection Precision: A large US bank implementing unsupervised learning in 2024 discovered their rule-based system had a 97% false positive rate (97 out of 100 alerts were legitimate activity). After deploying DBSCAN clustering, the false positive rate dropped to 85%—still high, but investigators cleared 12% more cases correctly. The remaining 3% SAR rate (Suspicious Activity Reports filed) was 4x higher than the rule-based system. Lesson: Unsupervised learning doesn't eliminate false positives, but it significantly improves precision, letting investigators focus on genuinely unusual accounts.
On Network Detection: A European bank's unsupervised learning system flagged a cluster of 22 accounts in 2025 that individually looked normal—small transactions, domestic recipients, no OFAC matches. Graph-based clustering revealed they all sent money to the same three intermediate accounts, which then wired funds to a single offshore entity. None of the 22 accounts triggered rule-based alerts because amounts were below thresholds. The network structure gave it away. Investigators discovered a €4.2M laundering operation. Lesson: Anomaly detection on individual accounts misses coordinated schemes; graph clustering is essential for network detection.
For Further Reading
FinCEN Guidance on Advanced Analytics for AML (US Department of Treasury, 2025) | https://www.fincen.gov/resources/advisories/fincen-advisory-advanced-analytics | Official US guidance on expectations for banks using AI and advanced analytics in AML detection.
EBA Guidelines on ML/TF Risk Factors (European Banking Authority, 2026) | https://www.eba.europa.eu/regulation-and-policy/anti-money-laundering-and-countering-financing-terrorism | European regulatory framework for AML risk detection, emphasizing emerging threat identification.
Unsupervised Learning for Financial Crime Detection (Deloitte, 2025) | https://www2.deloitte.com/us/en/pages/risk/articles/unsupervised-learning-aml.html | Practical guide on deploying clustering and anomaly detection in financial services.
Graph-Based Network Analysis for AML (Accenture, 2024) | https://www.accenture.com/us-en/insights/banking/graph-analytics-anti-money-laundering | Overview of graph clustering techniques for detecting coordinated fraud networks.
DBSCAN Clustering Algorithm Explained (Towards Data Science, 2024) | https://towardsdatascience.com/dbscan-clustering-explained | Technical deep-dive on DBSCAN and why it's effective for anomaly detection in AML contexts.
Next up: We're moving to Week 21 Sunday: How Risk Committees Interpret AI Outputs—translating technical dashboards and model exceptions into narratives that non-technical governance bodies can act on.
This is part of our ongoing work understanding AI deployment in financial systems. If you're implementing unsupervised learning for AML or facing validation challenges, share your experience.
— The AITechHive Team