Building FraudGraph AI: Agentic Fraud Investigation with TigerGraph and GraphRAG

A hackathon team built FraudGraph AI, an agentic fraud investigation platform that combines TigerGraph's graph database with GraphRAG to trace relationships between transactions, cards, customers, and merchants. The system separates fraud probability, confidence, and uncertainty, and splits next-best-action recommendations from a policy layer that authorizes or blocks actions with human-in-the-loop approval.

Fraud investigation is rarely about looking at a single transaction in isolation. A suspicious transaction can be connected to a customer, multiple cards, previous transactions, devices, and historical cases. The challenge is not only detecting that something looks unusual, but also understanding the relationships behind it, gathering supporting evidence, assessing uncertainty, deciding what to do next, and ensuring that the action follows policy. For our recent hackathon project, we built FraudGraph AI, an agentic fraud investigation platform designed around this problem. The Core Idea Instead of treating fraud detection as: Transaction → Fraud Score → Decision we designed the system as an investigation workflow: Transaction → Investigation → Graph Evidence → Risk & Uncertainty → Next Best Action → Policy/HITL → Execution → Case Memory The goal was to make the investigation process explainable and structured rather than relying on a single opaque score. Architecture The system is divided into several stages. The investigation starts with a flagged transaction and its trigger information. The Investigation Engine gathers relevant evidence and normalizes it into a structured evidence model. Evidence is classified so that the system can distinguish between directly observed facts, observations, and inferences. This gives the later reasoning stages a clear evidence base instead of passing around unstructured investigation output. The graph layer is one of the most important parts of FraudGraph AI. Fraud relationships are naturally graph-shaped: Customer → Card → Transaction → Merchant/Entity → Related Transaction A graph allows the investigation to move across these relationships and identify connections that may not be obvious from a single transaction. TigerGraph is used as the graph investigation layer, while GraphRAG provides structured context from the graph for downstream reasoning. This allows the system to ask questions such as: Which transactions are connected to the flagged transaction? Which cards are associated with the customer? What other activity is connected to those entities? Are there related entities or previous cases that provide additional context? What evidence supports the suspected fraud pattern? The graph context is then passed into the reasoning pipeline rather than treating the transaction as an isolated record. After evidence collection, FraudGraph AI evaluates risk. An important design decision was to separate fraud probability, confidence, and uncertainty. A high fraud probability does not automatically mean that the evidence is complete or that the system should immediately take an irreversible action. The reasoning layer aggregates independent evidence signals while attempting to avoid double-counting correlated evidence. The result contains: Fraud probability Confidence Uncertainty Evidence-derived risk signals This gives the investigation a more complete picture than a single binary fraud/not-fraud classification. The next stage answers: What should the investigation do next based on the current evidence and risk? The Next Best Action engine produces a deterministic and explainable recommendation based on the investigation and risk assessment. Possible actions can include monitoring, blocking, declining, verification, or other investigation actions supported by the system. An important architectural distinction is that Next Best Action is not the same thing as policy authorization. The NBA engine recommends an action. The policy layer determines whether that action is actually permitted. The recommended action then passes through the policy layer. The policy engine evaluates the action against the configured policy rules and determines: Whether the action is permitted Which policy rules apply Whether approval is required What approval level is required Whether the case should be blocked This creates a separation between: Recommendation → Authorization For actions requiring human review, the workflow can move into a Human-in-the-Loop approval state rather than executing automatically. This is particularly important for fraud investigations where an automated system should not blindly perform every high-impact action. The final stage handles execution and investigation persistence. Where policy permits automatic execution, the action is passed to the execution layer. The system also stores the investigation as case memory, allowing the resulting case information and execution references to become part of the investigation record. This creates a complete workflow: Investigate → Reason → Recommend → Authorize → Execute → Remember rather than ending the process after generating a fraud score. Benchmarking We also built a benchmark evaluation harness around the authoritative 20-case benchmark. Each case is processed through the same production pipeline: Investigation Risk and uncertainty assessment Next Best Action Policy evaluation Execution or approval handling Case-memory persistence The benchmark runner records information including evidence count, detected pattern, affected transactions, connected cards, exposure, fraud probability, confidence, uncertainty, recommended actions, policy results, execution state, and case-memory status. This allows the complete investigation workflow to be evaluated rather than measuring only whether a fraud classifier produced a particular score.