Jul 31 / Aneta Klosek

Graph Databases vs. Money Laundering

AITHEA Insights

Graph Databases and Money Laundering: Why Networks Catch What Rules Miss

How layering, structuring, and funnel accounts become invisible to transaction-level monitoring — and visible to graph.

2–5% of global GDP is laundered every year, per the UN Office on Drugs and Crime
$800B–$2T estimated laundered globally per year (UNODC)
<1% of illicit financial flows are currently seized or frozen (UNODC)

Most anti-money laundering systems were built to answer one question: does this transaction look wrong on its own? That question worked reasonably well when laundering meant one large, obviously suspicious wire transfer. It works much less well today, because the transactions that matter most rarely look wrong in isolation. They look wrong only when you connect them to the transactions around them — and that is precisely the layer where rule-based, transaction-level monitoring stops seeing anything at all.

The scale of the problem is why this gap matters. The United Nations Office on Drugs and Crime estimates that 2–5% of global GDP, or roughly $800 billion to $2 trillion, is laundered every year, and that less than 1% of illicit financial flows are ever seized or frozen. That enforcement gap isn't primarily a resourcing problem. It's a data-modeling problem.

Why transaction-level rules stop working

Conventional monitoring systems store data the way relational databases store everything: in tables of accounts, tables of customers, tables of transactions. A rule engine scans those tables for thresholds — deposits under $10,000, transfers to high-risk countries, round-dollar amounts. Each rule is a snapshot of a single row, evaluated on its own.

The problem is that laundering typologies are not designed to trip a single-row rule. They're designed to be broken into pieces small enough, and spread across enough intermediaries, that no individual piece ever looks abnormal. Researchers writing in the AML/CFT Journal put it plainly: conventional systems relying primarily on rule-based and transactional patterns struggle to detect the relational behavior of financial crime, because the crime pattern lives in the network topology, not in any one transaction.

Three typologies that hide from rules

  • Structuring (smurfing): a large sum is broken into many small deposits, each below a reporting threshold, made across multiple accounts or by multiple people, then consolidated later. Every individual deposit is unremarkable; the pattern only exists across accounts.
  • Layering: funds are pushed through a long chain of transfers — shell companies, intermediary accounts, multiple institutions — specifically to separate the money from its criminal origin. Each hop is a normal-looking transfer.
  • Funnel accounts: deposits arrive from many disparate, often geographically scattered sources into one account, which then withdraws or forwards the funds elsewhere. No single deposit is large; the funnel is defined by the shape of the inflows, not their size.
Structuring → Layering → Funnel: one scheme, three shapes STRUCTURING 3 small deposits 1 account LAYERING source destination FUNNEL ACCOUNT scattered inflows → one outflow
Each individual transfer looks ordinary. The pattern only appears when the connections between accounts are drawn as a network.

What a graph database sees differently

A graph database models the same data — accounts, customers, devices, merchants, transactions — but stores the relationships between them as first-class objects, not as rows that have to be joined together at query time. Instead of asking "does this row cross a threshold," the system can ask "does this account sit at the center of an unusual number of short, incoming transfers from otherwise unconnected sources, followed by a rapid outgoing transfer?" That is a question about shape and connection, and it's the question structuring, layering, and funnel accounts are specifically built to survive when data lives in tables.

Industry analysis from graph vendor TigerGraph explains the practical constraint plainly: relational systems that require multiple joins across tables to trace a chain of transfers can take hours or days to execute those queries, which makes real-time detection impractical. Graph platforms, by contrast, are built to traverse multi-hop chains — following money across accounts, intermediaries, and devices — inside the time window an investigation actually needs.

This isn't purely vendor claim. A 2025 study published in the AML/CFT Journal tested whether laundering typologies could be identified from network structure alone — measures like how central an account is, how many hops separate it from other accounts, and the direction funds flow through it. Using those graph-derived metrics, the researchers found statistically significant differences between laundering-linked and normal accounts across five of six network metrics tested, and a neural network trained on those metrics classified 17 known typologies with roughly 80% accuracy. The core finding: the crime signature was visible in the network's topology, independent of any single transaction's size or timing.

Same data, two views TRANSACTION TABLE (rule engine view) Acct A → $4,980 deposit ✓ under threshold Acct B → $4,950 deposit ✓ under threshold Acct C → $4,999 deposit ✓ under threshold Result: no alert triggered GRAPH VIEW (network of accounts) shared device + timing pattern Result: structuring pattern flagged
Three deposits pass every threshold rule individually. Once the accounts are connected in a graph, the shared device and timing turn three clean rows into one flagged pattern.

The limits worth stating plainly

A typology match is a lead, not a verdict. Graph analysis surfaces structures — loops, funnels, layering chains — that are consistent with known laundering patterns. It does not, on its own, prove laundering occurred. Investigators still need to review the flagged connections, and the underlying data behind each match should be preserved so a second reviewer can reproduce the finding. Graph tools change what compliance teams can see; they don't replace the judgment applied to what they see.

The takeaway

Money laundering typologies are, by design, invisible to any system that evaluates one transaction at a time. Structuring hides in the fact that no single deposit is large. Layering hides in the length of the chain. Funnel accounts hide in the number of unrelated sources feeding one destination. None of that is a property of a transaction — it's a property of a network. That's the specific gap graph databases are built to close, and it's why financial-crime teams are increasingly modeling their data as a graph from the start, rather than bolting network analysis onto a relational system after the fact.

Sources: UNODC, "Money-Laundering" overview and regional reporting (unodc.org); Alham, Tsabitah & Zaman, "Money Laundering Typology Detection Using Graph Analytics and Neural Networks," AML/CFT Journal, 4(1), 2025; TigerGraph, "Money Laundering Detection with AML Graph Analytics" and "How Graph Analysis Finds Repeating Laundering Patterns," tigergraph.com; Linkurious, "Graph analytics and anti-money laundering: 8 use cases," linkurious.com. This article is for informational purposes and is not legal or compliance advice.
Disclaimer & Copyright

This article is published by AITHEA GmbH for informational and educational purposes only. It is intended to provide general insights into compliance, technology, and related topics, and does not constitute legal, regulatory, or professional advice. Readers should seek appropriate professional guidance before making decisions based on the content provided.

The views and opinions expressed in this article are those of the author(s) and do not necessarily reflect the official position of AITHEA GmbH, its partners, or affiliated organisations.

Artificial intelligence (AI) tools are actively used in the creation of this content. AI may support the drafting of text and the improvement of structure, clarity, and readability. However, all content is based on human-defined topics, reviewed against relevant sources, and critically validated by the author(s). AI is not used as a source of truth, but as a supporting tool to enhance communication.

All content is the intellectual property of AITHEA GmbH unless otherwise stated. Reproduction, distribution, or translation for non-commercial purposes is permitted, provided that appropriate credit is given and the source is clearly acknowledged. For any commercial use, prior written permission is required. © Aithea, 2026.
Created with