# FraudTrace: Teaching an AI Agent to Follow the Money on a Graph

An analyst asks: "Which accounts are linked to flagged transaction T-9001?" The agent then:

"Who shares a device with the sender of this transaction, and who do they send money to?" is a multi-hop question. In SQL that is a chain of joins you must plan in advance. Vector search finds similar text, not shared devices. In a graph database the agent follows relationships directly.

1. The fraud graph. fraud_data holds Person, Account, Device, IPAddress, Merchant and Transaction nodes: 5,000 accounts and 50,000 transactions of synthetic data, with three planted patterns hidden in normal activity (a fraud ring, mule accounts, and synthetic identities that share one device and address). The answer key is kept outside the graph so the agent has to discover the patterns itself.

2. Native algorithms. FalkorDB's algorithms work best on relationships between nodes of the same type, so I derive two relationship types inside the graph: PAID (money flow between accounts) and LINKED (accounts that share a device, IP or address). On top of those the agent can use:

3. Memory as a graph. Every analyst gets their own graph, memory_<analyst>, with Investigation, Finding, Entity and Feedback nodes. A new finding about the same entities supersedes the old one but keeps the history. When the analyst marks a finding as a false positive, the risk score for those accounts drops on later investigations. Analysts cannot see each other's memory, because the backend injects the analyst identity and the model never chooses it.

All 17 tools are served by an MCP server: read tools (profiles, neighbours, shared devices, communities, cycles, shortest path), memory tools, and action tools (flag accounts, hold a transaction, open a case). The agent discovers the tools and picks them itself, with no hard-coded flow.

Thanks to FalkorDB and WeMakeDevs for the hackathon.