One Phone Number Exposes a Five-Person Money Laundering Ring: FalkorDB Graph Queries 169x Faster

Most anti-money laundering (AML) systems still scan transaction records row by row, while criminals have long since learned to hide their criminal structures in the connections between accounts. A hackathon project called Financial Crime Agent demonstrates another approach: using a graph database and an AI agent to trace through relationship networks, identifying a five-person money laundering ring controlled by the same iPhone 15 Pro in 8.4 milliseconds.

Why Row-by-Row Checks Can't Catch Money Laundering

A $48,000 transfer at 2 AM looks like just a number in a spreadsheet. A rule engine evaluating row by row would likely let it pass. Money launderers exploit exactly this, constructing structures that only become visible from a global perspective:

• Wash Rings: Funds flow from A to B to C to D and back to A. Each hop looks like normal business—the cycle itself is the crime.
• Shell company layering: Funds are split and passed through layer upon layer of shell entities, stretching the distance between source and destination.
• Device collisions: Multiple "different" customers share the same physical phone, which usually means one person is operating multiple identities.

What these patterns share is that they don't exist in any single row of records—they exist in the relationships between records. This is precisely the problem relational databases are worst at.

The Gap Between SQL and openCypher: 1420ms vs. 8.4ms

The project author ran a benchmark: finding fund paths of 2 to 5 hops that eventually return to the starting point. With recursive SQL, each hop means another self-join on the same large table, with intermediate results growing exponentially with depth. On a small dataset, this query takes 1420 milliseconds, accompanied by large amounts of temporary data and lock contention.

The same query in FalkorDB's openCypher takes just one line:

MATCH path = (a:Account)-[:TRANSFERRED_TO*2..5]->(a)
RETURN path

The result: 8.4 milliseconds, roughly 169x faster, with no joins at all. Finding device rings is equally direct: match two accounts pointing to the same device via USES_DEVICE, aggregate, and filter for devices with at least 5 associated accounts.

The author notes that the root cause of the performance gap is index-free adjacency: in a graph database, each node directly points to its neighbors, so traversing an edge is just a pointer jump. The cost depends on the actual size of the graph being visited, not the size of the entire table. A five-hop traversal doesn't pay for the billions of rows it never touches.

The complexity trap of recursive SQL: The original article mentions that recursive SQL performs a self-join on the same large table at every hop, with intermediate results growing exponentially. Behind this lies the fundamental limitation of relational databases when executing multi-hop queries: they have no persistent concept of "edges." Relationships between accounts can only be expressed implicitly through foreign keys or join tables, so every hop requires rescanning and rejoining the base tables. When the query depth is k, the intermediate result size grows roughly as branching_factor^k, and the database must also maintain temporary tables, sorting, and hash indexes for each recursion level, amplifying I/O and memory overhead. Even with indexes, the optimizer struggles to plan globally across recursion levels. This is exactly where the 1420 milliseconds comes from—the cost is tied to the overall table size, not to the subgraph that actually needs to be visited. Graph databases bypass this bottleneck at its root by materializing relationships as pointers.

Index-free adjacency: This is the core storage mechanism of native graph databases. Each node physically stores pointers directly to its adjacent nodes, so traversing an edge is a single in-memory pointer jump—no need to query a global index to locate neighbors. As a result, the cost of a k-hop traversal is roughly proportional to the number of nodes and edges actually visited along the way, which is fundamentally different from the traditional relational cost model of "look up index, fetch row, then join." The direct benefit: when the graph scales to billions of nodes, a local query touching only a few hundred nodes still maintains millisecond latency—it doesn't slow down as the table grows. The trade-off is that graph databases are better suited for local traversals than full-table aggregation scans, and storage must maintain bidirectional pointers for every edge.

How the Agent Works Like an Investigator

The AI agent is designed as "a tireless junior investigator." When a suspicious account triggers an alert, it:

1. Traverses the graph outward along fund flows and shared attributes (such as devices);
2. Discovers that five accounts are bound to the same hardware ID;
3. Highlights this ring in the interface and fades innocent nodes into the background;
4. Drafts a FinCEN Suspicious Activity Report (SAR) based on its findings.

The tech stack is relatively simple: React + Vite for the frontend, TailwindCSS for styling, Cytoscape.js for rendering the relationship graph, and FalkorDB underneath. Cytoscape was chosen because it can style nodes by state, perfectly meeting the highlighting and fading requirements.

The author specifically notes that highlighting and fading may seem like small features, but they were the favorite part of the demo. Real investigators face information overload—when five suspicious nodes light up and everything else goes quiet, the answer is simply "right there," understandable without reading a report.

FinCEN SAR and suspicious activity reports: A SAR (Suspicious Activity Report) is a legally mandated report that U.S. financial institutions must submit to the Financial Crimes Enforcement Network (FinCEN) to report suspected money laundering, fraud, or other suspicious transactions. Under the Bank Secrecy Act, institutions meeting the filing threshold must submit within specified deadlines, and the contents are subject to confidentiality provisions—the reported party must not be informed. SARs carry real legal consequences: they enter law enforcement and regulatory databases and may trigger account freezes, further investigation, or even criminal proceedings. Therefore, SAR drafting must be based on verifiable facts and chains of evidence; the narrative section must explain who, when, how, and how much money was involved. This also explains why the original article insists that a human compliance officer give the final signature—the act of submission itself creates legal liability.

Keeping the Agent Honest: The Graph Is the Witness, the Model Only Tells the Story

Large language models have a habit: confidently fabricating content. In the financial crime domain, this is extremely dangerous—wrongly accusing a real person is serious harm, not a fun bug.

So the author made a key design decision: every step in the agent's reasoning timeline must point to real nodes and edges in the graph. When it claims that Rivera, Lee, Kim, Patel, and Chen share a device, users can click to see the query results proving it.

The graph is the witness; the language model only narrates what the graph returns.

From this the author draws a more general conclusion: fix hallucinations with architecture, not prompts. If the agent can only report what the database provides, fabricated evidence has nowhere to hide.

Constraining hallucinations through architecture: LLM hallucinations stem from their generation mechanism—they continue text probabilistically and do not inherently verify facts. Common "prompt fixes" only remind the model on the input side not to fabricate; they cannot prevent it from inventing entities or relationships within a long reasoning chain. The approach proposed in the original article is an "architectural" constraint: limiting the evidence the model can cite to the results returned by graph database queries, with every assertion by the agent accompanied by the corresponding node, edge, or Cypher query—effectively adding a verifiable provenance layer to the generation process. Such approaches are often described in the industry as a variant of retrieval-augmented generation (RAG) or tool-calling constraints—the model no longer recalls freely but can only relay facts provided by external systems. In regulated scenarios, this "auditable reasoning chain" matters more than the model's own accuracy, because regulators need verifiable evidence, not plausible-sounding narratives.

The Final Signature Still Belongs to a Human

The agent does not convict anyone. Submitting a SAR has real legal effect and may lead to account freezes and law enforcement involvement—this must be decided by a trained person who bears responsibility.

The agent handles the slow, tedious work—traversing the graph, gathering evidence, drafting the narrative—then hands the case file with supporting evidence to a compliance officer. The compliance officer reviews the context, applies judgment, and provides the final legal signature.

The author believes this is the only realistic path for AI to enter regulated industries. Regulators don't care how smart the model is; they care who is accountable and whether the work process can be demonstrated. Human sign-off answers the former; the graph-linked timeline answers the latter.

Project Takeaways and Future Directions

The author summarizes several lessons from this build: graph databases are not a nice-to-have for AML, because fraud itself is graph-shaped; Cypher is not only faster but also more readable, making queries easier to audit and trust; and the value of the reasoning timeline even exceeds the speed improvement—a mysterious risk score of 94 makes people nervous, but a trail showing "this is the device, these are the five accounts, these are the transfers between them" is what regulators can actually verify.

Future plans include: streaming transaction processing so rings are flagged as they form; entity resolution across phone numbers, addresses, IPs, and beneficial owners; using graph algorithms like community detection to automatically rank suspicious clusters; and formal case management with audit logs and multiple reviewers.

As the author puts it: criminals are already thinking in networks—our tools should too.

The project is open-sourced on GitHub and offers an online demo.