Building FraudGraph Investigator: An AI-Powered Graph-Based Fraud Investigation System

A team competing in the TigerGraph × Hacker House Goa challenge built FraudGraph Investigator, an AI-powered fraud investigation system that turns a flagged transaction into a structured investigation workflow. The system combines TigerGraph's connected-data graph, a LangGraph-orchestrated agent workflow, and MCP-exposed investigation tools to collect and analyze evidence, assess uncertainty, and evaluate evidence sufficiency before a policy engine selects a next-best action such as BLOCK_CARD, VERIFY_WITH_CUSTOMER, or ESCALATE. A key design principle separates AI-assisted investigation and reasoning from the final operational decision, which is governed by explicit policy rules.

How we combined TigerGr aph, LangGraph, MCP, evidence analysis, case memory, and policy-based decisions to investigate suspicious transactions. https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Faq1io2sv3i7o5pbvcsjr.png Introduction Fraud detection is often treated as a classification problem: given a transaction, determine whether it is suspicious or legitimate. But real fraud investigation requires more than a risk score. When a transaction is flagged, an investigator needs to understand the context around it: Who is the customer? Which card was used? Which device was involved? Are there related transactions? What historical information is available? What evidence supports the suspicion? What evidence contradicts it? Is the available evidence sufficient? What action should be taken? For the TigerGraph × Hacker House Goa challenge, our team built FraudGraph Investigator, an AI-powered fraud investigation system that combines connected-data investigation, agentic workflows, evidence analysis, uncertainty assessment, and policy-governed actions. What We Built FraudGraph Investigator takes a suspicious transaction and turns it into a structured investigation. Instead of simply treating a high-risk transaction as fraud, our system follows a complete investigation workflow: Suspicious Transaction → Investigation Planning → Evidence Collection → Evidence Analysis → Hypothesis Evaluation → Uncertainty Assessment → Evidence Sufficiency → Policy Evaluation → Next-Best Action → Case Memory The system can produce three main actions: BLOCK CARD VERIFY WITH CUSTOMER ESCALATE A key design principle was to separate AI-assisted investigation from the final operational decision. The investigation produces evidence and reasoning, while explicit policy rules govern the final action. System Architecture Our system consists of several layers: Investigator UI ↓ FastAPI API ↓ LangGraph Investigation Workflow ↓ MCP Investigation Tools ↓ TigerGraph / Dataset ↓ Evidence Analysis ↓ Policy Engine ↓ Next-Best Action The architecture separates the data layer, investigation workflow, reasoning, policy enforcement, and user interface. This makes the system easier to test, inspect, and extend. Why We Used TigerGraph Fraud rarely exists as an isolated transaction. A transaction can be connected to several entities, including: Customer → Card → Transaction → Device → Location → Related Transactions It can also connect to historical investigation information. This is where graph-based investigation becomes useful. Instead of looking at only one transaction, our system can investigate the relationships surrounding that transaction. TigerGraph provides the graph-oriented foundation for this approach, allowing connected entities and their relationships to become part of the investigation. The key question changes from: "How risky is this transaction?" to: "What else is connected to this transaction, and what does that context tell us?" Using MCP for Investigation We used Model Context Protocol MCP to expose investigation capabilities as structured tools. The agent does not directly manipulate the underlying data. Instead, it requests specific investigation operations through MCP. The general flow is: LangGraph Agent → MCP Tool → Data/Graph Layer → Structured Evidence → Investigation Workflow The investigation tools provide targeted information such as: Transaction details Customer information Connected entities Shared devices Historical fraud information Related activity Temporal patterns Geographic/contextual signals The returned information becomes evidence that can be used during the investigation. LangGraph Investigation Workflow We used LangGraph to orchestrate the investigation as a structured workflow instead of relying on a single LLM call. The workflow moves through several stages. The suspicious transaction and case information are loaded. The system determines what evidence needs to be collected. MCP tools retrieve the required information from the available data sources. The collected information is organized and classified. Possible explanations for the transaction are considered, such as: Card-not-present fraud New-device activity Card testing Out-of-region usage The workflow evaluates how uncertain the investigation remains. The system determines whether enough evidence exists to support an operational decision. The investigation state and evidence are evaluated against deterministic policy rules. The system produces the next-best action. The investigation result is stored so that future investigations can use historical context. Evidence Sufficiency vs. Uncertainty One of the important design decisions in our system was to separate evidence sufficiency from uncertainty. These are not the same thing. A case can have enough evidence to support a decision while still having significant uncertainty. For example: Evidence Sufficiency: SUFFICIENT Uncertainty: HIGH This distinction prevents the system from treating a high risk score as the only factor in determining the final action. The investigation considers both the available evidence and the remaining uncertainty. HHG-010 Case Study One of our benchmark cases is HHG-010. The investigation produced: Customer: C10434 Transaction: 3506725 Risk Score: 0.90 Amount: $1,000.03 Status: COMPLETE Evidence: SUFFICIENT Uncertainty: HIGH Recommended Action: ESCALATE The system identified both supporting and contradictory evidence. For example, the investigation found: $0 confirmed fraud + $1,000.03 pending exposure The transaction used a desktop/Windows device The customer had no prior confirmed fraud cases The result was therefore not simply: High Risk → BLOCK Instead, the investigation resulted in: High Risk + Sufficient Evidence + High Uncertainty → ESCALATE → Senior Analyst Approval This demonstrates an important principle of our system: Investigate first, then act based on evidence and policy. Historical Case Memory Fraud investigations should not always start from zero. FraudGraph Investigator includes a case memory layer that stores information from previous investigations. This provides historical context such as: Customer history Previous transactions Previous investigation outcomes Cards involved Previous actions Approval information The goal is to make future investigations more context-aware while keeping the information structured and traceable. Policy-Governed Decisions Another important component is the deterministic policy layer. The LLM assists with investigation and reasoning, but operational actions are controlled through explicit policy rules. The overall decision flow is: Evidence + Investigation State + Uncertainty + Risk/Exposure ↓ Policy Engine BLOCK CARD / VERIFY WITH CUSTOMER / ESCALATE This separation helps keep the final operational action governed rather than allowing an LLM to directly make an unrestricted decision. Investigator Dashboard We built an interactive FastAPI-based investigator dashboard to make the investigation results accessible through a single interface. The dashboard provides: Case navigation Investigation reports Risk information Supporting evidence Contradictory evidence Hypotheses Case memory Investigation workflow Recommended action Benchmark results Validation status An investigator can move from the overall benchmark view into an individual case and inspect the evidence and reasoning behind the result. Benchmark Results We evaluated the complete workflow across 20 benchmark investigations. The expected action distribution was: Action Cases BLOCK CARD 15 VERIFY WITH CUSTOMER 4 ESCALATE 1 Total 20 Our benchmark dashboard showed: 20 total cases 20 reports loaded 20/20 cases with sufficient evidence 0 benchmark errors 0 benchmark warnings The end-to-end validation also checked the expected action invariants across the benchmark cases. Technology Stack Technology Role TigerGraph Connected graph investigation LangGraph Agent/workflow orchestration MCP Structured investigation tools Python Core implementation FastAPI API and investigator dashboard Case Memory Historical investigation context Policy Engine Deterministic action governance What We Learned The biggest lesson from this project was that building an AI investigation system is not only about choosing an LLM. A practical system also needs: Connected Data + Investigation Tools + Agent Workflow + Evidence + Uncertainty + Policy + Testing + User Interface Graph technology was particularly useful because fraud investigations naturally involve relationships between entities. We also learned the importance of separating: What the model reasons about → What evidence exists → What the policy allows → What action is finally taken Future Improvements There are several areas we would explore in a production version. Real-Time Graph Integration The system could be connected to continuously updated transaction streams and a production TigerGraph environment. Advanced Graph Analytics Additional graph algorithms could help identify: Fraud rings Suspicious communities Entity similarity Coordinated transaction patterns Suspicious subgraphs Improved Case Memory A larger historical investigation repository could provide richer contextual reasoning. Human-in-the-Loop Investigation Investigators could approve, reject, or request additional evidence before a final action. Production Monitoring A production deployment would also require monitoring for data drift, model drift, investigation latency, policy violations, false positives, and changing fraud patterns. Conclusion FraudGraph Investigator was built around a simple idea: Fraud investigation should be evidence-driven, connected, and governed — not just a prediction from a single transaction. By combining TigerGraph, LangGraph, MCP, case memory, evidence analysis, and deterministic policy rules, we created an end-to-end investigation workflow that moves from a suspicious transaction to an explainable next-best action. The project gave us hands-on experience building an AI system where graph relationships, agentic workflows, evidence, uncertainty, and governance work together. Thanks to TigerGraph and Hacker House Goa for providing the challenge and the opportunity to build around connected-data intelligence.