用 FalkorDB 追查詐騙網絡：建構 Fraud Ring Investigator 的經驗

Banks flag suspicious transactions all day. The hard part isn't the flag—it's seeing what's behind it.

Fraud rings can hide in relationships: accounts that share a device, logins from the same IP address, and money that loops between accounts. This is a graph problem, so for Graph Hacks, I built Fraud Ring Investigator, a project that investigates flagged transactions using FalkorDB and explains the evidence behind its findings.

How it works

The graph contains people, accounts, devices, IP addresses, merchants, and money transfers. The project uses synthetic data with three planted fraud rings among legitimate accounts.

For each flagged transaction, the investigation:

• Finds accounts linked through shared devices and IP addresses.
• Groups connected accounts using weakly connected components.
• Ranks potentially important hub accounts.
• Traces money paths as evidence.
• Looks for circular transfer patterns.
• Freezes accounts and creates a compliance case in the graph.

The report includes graph paths and the Cypher queries behind its claims, helping an analyst inspect how the investigation reached its conclusions.

What I learned

1. The relationships you choose matter

My initial approach to weakly connected components included money transfers. That connected separate rings through ordinary accounts. Restricting the analysis to device and IP relationships helped separate the planted rings in my dataset.

2. PageRank doesn't tell the whole story

PageRank can help identify important accounts, but it doesn't capture every kind of activity. An account sending money to multiple other accounts may be important even if PageRank alone doesn't rank it highly. Combining it with transfer degree helped address this in my project.

3. Database details matter

While building the project, I encountered FalkorDB query constraints and duplicate graph nodes. I adjusted the shortest-path queries to fit the engine's requirements and used MERGE to avoid creating duplicate device and IP nodes. This reinforced the importance of testing queries against the actual database.

4. A graph can store investigation outcomes

The project doesn't just query relationships. It also writes investigation outcomes back into the graph: freezing an account and creating a Case node linked to affected accounts. This keeps the investigation evidence and recorded actions connected.

Limitations and next steps

The current project uses a small synthetic dataset and a fixed investigation pipeline. It is a prototype, not a production fraud-detection system. A possible next step is to let an LLM choose which graph investigation tool to call based on the evidence found at each stage.

You can explore the source code here:

Fraud Ring Investigator on GitHub

Building this project taught me that graph databases are useful not just for storing connected data, but also for investigating relationships and producing evidence that people can inspect.