Building FraudGraph AI: Agentic Fraud Investigation with TigerGraph and GraphRAG

Fraud investigation often requires examining multiple transactions and entities beyond a single incident. A single suspicious transaction can be linked to various customers, cards, transactions, devices, and historical cases. The challenge lies not only in detecting unusual activity but also in understanding the relationships behind it, gathering supporting evidence, assessing uncertainty, deciding next steps, and ensuring actions align with policy.

For a recent hackathon project, the team developed FraudGraph AI, an AI-powered platform designed for agentic fraud investigation. Instead of using a traditional approach where fraud detection follows a linear path of transaction → fraud score → decision, FraudGraph AI employs an investigation workflow: transaction → investigation → graph evidence → risk & uncertainty → next best action → policy/HITL → execution → case memory.

This structured approach aims to make the investigation process more transparent and systematic, rather than relying on a single opaque score.

The system is structured into several stages. The Investigation Engine begins with a flagged transaction and its trigger information. Its role is to gather relevant evidence and normalize it into a structured evidence model. This evidence is classified as direct observations, inferences, or a combination of both, providing a clear evidence base for subsequent reasoning stages.

A critical component is the graph layer, representing fraud relationships naturally. Entities like customer, card, transaction, merchant, and related transactions form a graph structure. TigerGraph and GraphRAG (Graph Representation and Generation) are used to investigate this graph. GraphRAG provides structured context from the graph, enabling the system to ask questions like which transactions are connected to the flagged transaction, which cards belong to the customer, and what other activity exists among those entities.

This graph context is then passed into the reasoning pipeline, rather than treating the transaction as an isolated record.

Following evidence collection, the Risk and Uncertainty Engine evaluates the findings. It distinguishes between fraud probability, confidence, and uncertainty. A high fraud probability does not automatically mean the evidence is complete or that irreversible actions should be taken immediately. The engine aggregates independent evidence signals while avoiding double-counting correlated evidence, resulting in a risk assessment that includes fraud probability, confidence, uncertainty, and evidence-derived risk signals.

The Next Best Action Engine determines the appropriate course of action based on the current evidence and risk assessment. This engine produces a deterministic and explainable recommendation. Possible actions include monitoring, blocking, declining, verification, or other investigation-specific actions. Importantly, the Next Best Action engine is distinct from the policy authorization layer.

While the Next Best Action engine recommends an action, the policy layer evaluates whether the action is permitted, determines required approvals, and defines the approval level needed before the case can proceed.

The Policy Compliance and Human-in-the-Loop stage handles the authorization of actions. The recommended action passes through the policy engine, which checks it against configured policy rules to determine if the action is allowed, which rules apply, whether approval is required, and the approval level needed. For actions requiring human review, the workflow moves into a human-in-the-loop approval state, preventing automated execution of high-impact actions.

This ensures that the system does not blindly perform automated actions, especially in fraud investigations where human judgment is crucial.

Finally, the Execution and Case Memory stage handles the execution of authorized actions and the persistence of investigation details. If the policy permits, the action is executed, and the investigation is stored as case memory. This ensures that the results, execution references, and case information become part of the investigation record, creating a complete workflow: Investigate → Reason → Recommend → Authorize → Execute → Remember.

This approach differs significantly from traditional systems that end after generating a fraud score, providing a more comprehensive and structured investigation process.