Building an Autonomous Fraud Investigation Agent with TigerGraph, GraphRAG & Case Memory
Introduction
Financial fraud is increasingly organized. Fraudsters can coordinate multiple cards, devices, accounts, merchants, and transactions rather than operating through isolated events.
Traditional rule-based systems and transaction-level ML models can identify suspicious activity, but they can struggle to expose the relationships connecting seemingly independent events. Fraud analysts often need to manually correlate transaction histories, device relationships, previous cases, and investigation evidence.
For the Hacker House Goa (HHGOA) Challenge, we built an Autonomous AI Fraud Investigation System combining TigerGraph, GraphRAG, precedent case memory, deterministic fraud policies, and agentic workflows.
The goal was to move from simply flagging suspicious transactions to helping investigators understand why an alert is suspicious, what connected evidence exists, how similar cases were handled, and what action should be taken next.
System Architecture
Our system combines several components:
1. TigerGraph Investigation Layer
The graph contains:
- 634,810+ vertices
- 2,505,246+ edges
- Customers
- Payment cards
- Transactions
- Device profiles
- Historical fraud cases
Parameterized GSQL queries perform multi-hop graph traversals to uncover relationships between entities.
This allows the investigation agent to move beyond an individual transaction and examine connected entities such as:
Transaction → Card → Customer → Device → Other Cards → Historical Cases
2. Precedent Case Memory
The system contains 5,565 historical closed fraud cases.
We use BM25-based retrieval to identify relevant previous cases and provide investigators with precedent information.
Temporal cutoffs are applied during retrieval to reduce the risk of future-data leakage when evaluating historical scenarios.
3. GraphRAG Evidence Aggregation
The GraphRAG layer combines graph-derived evidence with historical case context.
For an incoming alert, the system can:
- Inspect the transaction.
- Trace the associated card and customer.
- Investigate device sharing.
- Discover connected entities.
- Retrieve relevant historical cases.
- Aggregate the evidence.
- Pass grounded context to the reasoning layer.
This allows the agent to reason over relationships and evidence, rather than relying only on isolated transaction features.
4. Fraud Policy Governance Engine
We implemented deterministic fraud policies R1–R10.
The policy layer evaluates investigation evidence and determines the appropriate workflow, including routing such as:
autoL1_analystL2_senior_manager
The system can also generate SAR-related investigation output when the configured policy conditions are met.
The policy engine is intentionally deterministic so that the LLM does not independently decide which governance rules apply.
5. Interactive Evidence Simulator
Some fraud alerts require additional verification.
Our simulator supports investigation scenarios such as:
- Customer travel verification
- Out-of-band confirmation
- Step-up authentication
This allows investigators to explore how additional evidence can change the investigation outcome.
6. Full-Stack Interface & MCP
We developed an interactive web interface with:
- Glassmorphic UI
- Radial graph visualization
- Investigation dashboards
- Evidence exploration
- Fraud case workflows
We also implemented a Model Context Protocol (MCP) server exposing 7 JSON-RPC tools, allowing an LLM-based agent to interact with the investigation system through structured tools.
Case Study: The 52-Card Device Syndicate
One of our benchmark investigations was Case HHG-014.
The analyst initially flagged transaction 3478561, involving approximately $74.96 on card C13487-K1.
A baseline tabular model assigned the transaction a relatively low risk score of 0.05.
However, the graph investigation produced a very different picture.
Using a device-sharing traversal, the system discovered that the associated Samsung SM-G935F device fingerprint had been used across 52 distinct payment cards spanning multiple customer accounts.
The graph also connected the device to 4 historical confirmed fraud cases.
This demonstrates why relationship-aware investigation can reveal signals that may not be obvious from an individual transaction alone.
The agent then used the discovered evidence to:
- Escalate the investigation outcome
- Trigger the relevant configured policy rules
- Route the case for higher-level review
- Generate a SAR-oriented narrative
- Produce card-freeze / containment playbook recommendations
Results & Evaluation
Our benchmark evaluation produced the following results:
- 20/20 benchmark cases evaluated
- 100% schema compliance
- 55/55 automated unit tests passing
- 0 false-cleared cases on the evaluated high-risk syndicated alerts
- Sub-50 ms reported end-to-end investigation pipeline latency
These results were obtained from our challenge evaluation environment and should be interpreted within the scope of the benchmark rather than as production fraud-detection performance.
Why Graph-Based Investigation Matters
The central idea behind the project is simple:
A suspicious transaction is often only one piece of a much larger relationship network.
A transaction may appear harmless when viewed independently.
But when connected with:
Cards + Customers + Devices + Transactions + Historical Cases
the underlying pattern can become much clearer.
TigerGraph provides the graph foundation for discovering these relationships, while GraphRAG and precedent memory provide contextual evidence for the agent.
The result is an investigation workflow designed to help analysts move from:
Alert → Evidence → Connected Pattern → Precedent → Policy → Action
Technology Stack
Graph & Data
- TigerGraph
- GSQL
- Graph analytics
- BM25 retrieval
AI & Reasoning
- GraphRAG
- Agentic AI
- LLM-based reasoning
- Precedent case memory
Backend
- REST APIs
- MCP / JSON-RPC
- Policy engine
Frontend
- Interactive web dashboard
- Glassmorphic UI
- Graph visualization
Testing
- Automated unit tests
- Benchmark case evaluation
- Schema validation
Conclusion
The Hacker House Goa challenge gave us an opportunity to explore how graph databases and agentic AI can work together for fraud investigation.
Instead of treating every transaction as an isolated event, our system builds an investigation around the relationships connecting transactions, cards, customers, devices, and historical cases.
By combining TigerGraph + GraphRAG + Case Memory + Deterministic Policy Governance + MCP, we created an end-to-end prototype for autonomous, evidence-driven fraud investigation.
The project demonstrates how graph-based context can complement traditional transaction-level fraud detection and provide investigators with a richer view of complex fraud patterns.
Project Links
🔗 GitHub:
https://github.com/Rishi-212005/HHGoa-Tigergraph-Fraud-Agent
🌐 Live Demo:
https://hhgoa-tigergraph-fraud-agent.onrender.com/
🎥 Project Explanation:
https://drive.google.com/file/d/170vRSUwG2hjoBFmp2zWIeqXyr4EzNFh0/view
Top comments (1)
The precedent case memory is the differentiator here. GraphRAG can surface connected evidence, but policy governance needs to stay explicit so each decision remains reviewable.