“How cross-border money laundering hides in graph data — a Neo4j walkthrough”

Using Neo4j to track money laundering, have you ever wondered how money laundering works? And why we shouldn’t use tables in tracking them.

Rule-Based Transaction Monitoring Systems

The dominant approach in AML compliance today is rule-based transaction monitoring, in which compliance teams define fixed rules that are evaluated against each incoming transaction. When a transaction matches a rule, an alert is generated and routed to a human analyst for review. In the normal banking system, they mostly use a role-based system for tracking money laundering, for example like “if money sent is > than $10,000 - Flag an alert”, which could raise a very much number of false alerts and routed to a human analyst for review.

The Graph Database Approach

The central innovation of RegTech AML is the use of a native graph database — specifically Neo4j — as the foundation for detection, rather than a relational database or a rule engine operating on isolated transaction rows. A relational database stores data in rows and columns. Finding relationships between entities requires joining multiple tables — an operation whose computational cost grows exponentially as chain depth increases. A query asking "find all entities connected to Person X through four or more intermediate companies" requires four successive table joins, each of which multiplies the data volume to be scanned. In a database containing millions of accounts and transactions, such a query is impractical in real time. As Napier AI (2024) notes: "Unlike relational databases which store data in rows and columns, graph databases excel in representing networks of entities and the dynamic relationship between them." Neo4j's native graph storage materialises joins as edges, allowing complex relationship queries to run in milliseconds rather than minutes.

The Three Detection Patterns

Shell Company Layering:
Shell Company layering is line of ownership, that ends up owning itself, for example like Company A owns Company B, Company B owns Company C, Company C owns Company D, Company D owns Company E then Company E owns back Company A, so that what makes it shell layering, A Company shouldn’t own’s its self-that’s a red flag.

Circular Flows:
Circular Flows is similar to the shell layering rounding, but it deals mostly with transaction, when the Account A transfers to Account B, Account B transfers to Account C, Account C transfers to Account D, Account D transfers to Account E and Account E transfers back to Account A, this is where the red flags lies, it’s should go back to itself.

Rapid Pass-Through:
Rapid pass-Through is when Account A, Account B, Account C, Account D, Account E all send money to Account X(hub account), Then Account X sends all the money to five other Account retaining less than 5% in the it’s account and all the transaction occurs within 1 hour, and that the red flag , because a company is supposed to retain some money in their account maybe for purchasing of goods and maintenances within Company, as long as All these transaction moves fast within an hour and still leaves less than 5%( account left empty ) that’s the problem.

Graph Visualization

Neo4j Browser provides native graph visualization of query results, rendering nodes as labelled dots and relationships as directional arrows. The following queries are optimised to produce visual graph outputs (rather than tabular results) for the purposes of demonstration:
So, this is the step-by-step process of visualization using Neo4j(Query)

VIZ 1 — SHOW THE ENTIRE DATABASE AS A GRAPH: it shows ALL nodes and relationships as a visual network.

Query: “MATCH (n) RETURN n”;

VIZ 2 — SHOW THE DATABASE SCHEMA (node types + relationship types): This shows the blueprint of the database — what types of nodes exist and how they are connected, without showing actual data.

Query: “CALL db.schema.visualization()”;

VIZ 3— SHELL LAYERING: Show the circular ownership loop as a GRAPH: Returns the shell company chain as a visual path — dots connected by arrows.

Query: “MATCH path = (a:Entity)-[:OWNS*2..6]->(a)
RETURN path;” 

if an entity(company) owns any other entity(Company) from two to six and still owns back it’s self.

VIZ 4 — CIRCULAR FLOW: Show the money loop as a GRAPH: Returns the 5-account circular flow as a visual ring of dots and arrows.  ACC-CIRC-A → B → C → D → E → (back to A)

Query: MATCH path = (a:Account)-[:TRANSFERRED*3..6]->(a)
RETURN path; 

VIZ 5 — RAPID PASS-THROUGH - Show the hub and its connections as a GRAPH: Returns the hub account with all its inbound and outbound connections.  a star shape — many sources feeding into hub, hub feeding many destinations.

Query: MATCH(src:Account)-[r1:SENT]->(tIn:Transaction)-[r2:RECEIVED_BY]->(hub:Account {account_id:"ACC-HUB-001"})
WITH hub, collect(src) AS sources, collect(tIn) AS inbound, collect(r1) AS sentRels, collect(r2) AS receivedRels
MATCH (hub)-[r3:SENT]->(tOut:Transaction)-[r4:RECEIVED_BY]->(dst:Account)
RETURN hub,
       sources, inbound,
       collect(tOut) AS outbound,
       collect(dst) AS destinations,
       sentRels, receivedRels,
       collect(r3) AS outSentRels,
       collect(r4) AS outReceivedRels;

VIZ 6 — SHOW ONLY THE SHELL COMPANY NETWORK (Entity nodes + OWNS relationships): This is the clean view of just the ownership structure, this explains Shell layer quite well, because in shell layering the Company A owns Company B, Company B owns Company C and Company C owns back Company A which hides the actual owner, but when the actual owner is then tracked, the entity is then known as UBO (Ultimate Beneficial owner) of all the Companies all together.

Query: MATCH (e:Entity)-[r:OWNS|UBO_OF]->(e2:Entity)
RETURN e, r, e2; 

VIZ 7 — SHOW MONEY FLOW (Accounts + Transactions only): Shows only the financial movement — accounts as dots, transactions as nodes, this is still the rapid pass-through pattern and within the Transaction node the timestamp contain the actual time the money was sent or received, used to check if all the transaction all together was within one hour, that’s why by right of the screenshot, this is a line of transaction, which the time the money was sent and the time money takes more than an hour, which is normal

Query: “MATCH (src:Account)-[s:SENT]->(t:Transaction)-[rb:RECEIVED_BY]->(dst:Account)
RETURN src, s, t, rb, dst
LIMIT 30;”

VIZ 8 — SHOW FULL NETWORK FOR ONE SPECIFIC CRIMINAL (Victor Osei): This shows everything connected to Victor — his shell companies, accounts, transactions and showing how the graph reveals the full picture of one criminal.

Query: MATCH path = (v:Entity {name:"Victor Osei"})-[*1..4]->(n)
RETURN path;  

Why This Reduces False Positives

Rule-based systems flag on single-transaction thresholds with no context, for example: if money sent > $10,000; flag an alert, there will be lots of alerts (false positives) but with the graph pattern, it give structural red flag for example: if there is a loop in the ownership, which is not supposed to be (which is against the rules  Abnormal) or a loop of transaction that also look abnormal too and also if there is a rapid transfer of money from different account to a single hub account which transfers the money to all other accounts just "5%" (percent is redundant with the % sign) of the money that’s very abnormal, and with the graph pattern a single node like an entity could store attribute like if KYC(know your consumer) is verified, if the entity is a PEP(Politically Exposed Person), if the country the transaction was made, or transferred to is on the gray list or black list, all these sum up to raise a red flag.

Risk Signal	Points Added	Rationale
Country on FATF BlackList	+50	Highest-risk regulatory environment; non-cooperation with global AML standards
Country on FATF GreyList	+25	Under active international monitoring; limited beneficial ownership disclosure
Circular ownership loop detected	+40	Structurally impossible in legitimate business; definitive shell indicator
KYC status not Verified/Pending	+20	Identity not confirmed; basic due diligence not completed
PEP flag (Politically Exposed Person)	+15	Elevated corruption risk by regulatory definition

The combined score determines the disposition:

Score Range	Disposition	Action
0–29	CLEAR	Transaction proceeds normally; no investigator action required
30–59	MONITOR	Logged automatically; analyst reviews at next scheduled triage cycle
60 and above	ESCALATE	Immediate manual review; Suspicious Activity Report (SAR) may be filed

The near-miss validation results demonstrate the effectiveness of this approach. For example: Hartfield Logistics Ltd — a verified UK holding company with a KYC-compliant three-tier structure — scores zero (CLEAR), despite making a USD 250,000 intercompany transfer. The shell network, by contrast, scores 85 (ESCALATE): Cayman Islands GreyList (+25), circular ownership loop (+40), KYC Pending (+20). Same structural complexity; completely different treatment. This is the mechanism behind the reported 0% false positive rate across all three near-miss validation cases.

Note: ”names are from a synthetic dataset used for coursework"

Conclusion:

Graph databases don't replace compliance teams, but they surface the shape of laundering that row-by-row rules miss entirely.