Building an Agentic Fraud Investigation System with TigerGraph, LangGraph & MCP

TL;DR : We built a 9-node LangGraph agent that investigates fraud cases end-to-end. It uses TigerGraph Community Edition as the knowledge graph substrate, TigerGraph MCP for tool access, and NVIDIA NIM for LLM reasoning. It produced FinCEN-standard SAR narratives for cases requiring regulatory filing, and wrote every case back to the graph as memory for future investigations. All 20 HHGOA benchmark cases were investigated end-to-end.

The Problem

Traditional fraud detection systems flag suspicious transactions and stop there. A human analyst then has to:

• Investigate the transaction against its full context
• Look up prior cases for the same customer, device, or card
• Determine which fraud pattern applies (if any)
• Decide the next best action per policy
• File a regulatory report when required
• Write the case into a permanent record

What we Built

The goal was not to replace the existing fraud detection model. Instead, We built an investigation layer that takes a flagged case and carries it through evidence collection, graph-based investigation, reasoning, policy checks, action execution, and permanent case storage.

The system is built around a 9-node LangGraph workflow, with TigerGraph serving as the investigation substrate and memory layer. TigerGraph MCP exposes graph operations as tools, while NVIDIA NIM handles the parts of the workflow that benefit from LLM reasoning.

System Architecture

The system is organized into distinct layers, with the graph providing the investigation context, MCP exposing graph operations as tools, and LangGraph coordinating the investigation workflow.

The Data Layer

The investigation starts with the HHGOA benchmark data. Instead of treating each transaction as an isolated row, the system loads the relevant entities and relationships into TigerGraph so an investigation can traverse the connections around a suspicious transaction.

The graph contains customers, cards, transactions, devices, email domains, billing regions, closed cases, investigation cases, resolved cases, documented patterns, and evidence. These entities are connected through relationships such as ownership, transactions, shared devices, prior investigations, and case outcomes.

The loaded graph contains 41,011 transactions, 5,565 closed cases, 1,927 cards, 1,896 customers, 2,034 device profiles, 47 email domains, and 96 billing regions. The benchmark includes 20 investigation cases, with additional case-linked transaction data loaded to provide investigation context.

Why a Graph?

A suspicious transaction rarely makes sense in isolation. Its strongest evidence may come from relationships: a device shared across customers, a card connected to previous fraud cases, repeated transactions involving the same entities, or a pattern that only becomes visible when those relationships are traversed.

TigerGraph as the Investigation Substrate

TigerGraph is not just being used as a database for storing transactions. It acts as the relationship layer that the investigation agent queries while building context around a case.

The graph contains 11 vertex types and 21 edge types. This lets the investigation move from a suspicious transaction to its customer, card, device, email domain, billing region, related transactions, and historical cases through explicit relationships.

The MCP Tool Layer

Rather than giving the LLM unrestricted access to the graph, the system exposes investigation capabilities through MCP tools. The TigerGraph MCP layer provides 69 built-in tools, while six custom HHGOA tools expose the operations most relevant to the investigation workflow.

get_transaction_context
find_connected_entities
detect_pattern
find_similar_cases
record_evidence
close_case

Traversing the Investigation Graph

Fraud Pattern Detection

The investigation layer includes four deterministic pattern detectors. These detectors turn graph relationships and transaction history into structured evidence that the agent can reason over.

1. Shared Device Ring

This detector traverses device relationships and checks how many customers are associated with the same device. A device shared across multiple customers can provide evidence of a coordinated fraud pattern.

2. Velocity Burst

This detector counts transactions within defined time windows, including the previous hour and previous 24 hours. A sudden increase in transaction activity can indicate abnormal behavior.

3. Amount Anomaly

This detector compares the transaction amount against the card's historical average. A significant deviation from the card's normal transaction amount becomes an additional investigation signal.

4. New Device With Proxy

This detector checks whether the transaction originates from a new device and whether proxy information is present. The combination provides another signal that can be evaluated alongside the other evidence.

The 9-Node Investigation Agent

The investigation is orchestrated as a 9-node LangGraph workflow. The workflow combines deterministic evidence and policy steps with LLM-based investigation and action recommendation, while allowing the agent to request additional evidence when the case is not yet sufficiently supported.

The 9-node workflow from case creation through investigation, policy enforcement, resolution, and graph write-back.

Building an Evidence Pack

The agent does not send the entire graph to the LLM. Instead, the deterministic evidence-collection step builds a curated Evidence Pack containing the information needed for the investigation.

The Evidence Pack can include the transaction context, connected entities, detected patterns, similar prior cases, missing evidence, and contradictions. This keeps the reasoning context focused while preserving the graph relationships that matter to the case.

What Goes Into the Evidence Pack?

• Trigger information
• Transaction context
• Connected entities
• Detected fraud patterns
• Similar prior cases
• Missing evidence
• Contradictions

Evidence Sufficiency

Before the agent recommends an action, the system checks whether the available evidence is sufficient to support a decision. This step is deterministic rather than LLM-driven.

The sufficiency assessment evaluates four dimensions of uncertainty: graph evidence, behavioral evidence, prior-case evidence, and contradictory evidence. Each dimension receives an ordinal score from 0 to 3, and the combined score determines whether the investigation can proceed.

Contradictions Take Priority

A high evidence score does not automatically make a case sufficient. If the investigation contains a hard contradiction, the system overrides the normal sufficiency calculation and requires additional evidence before proceeding.

If the case remains insufficient, the agent enters the evidence-request loop. The mock evidence APIs provide additional seeded evidence, and the investigation can repeat this process for up to three rounds before moving forward.

Sufficiency Score

Recommendation and Policy Enforcement

Once the evidence is sufficient, the agent generates a set of recommended actions. The recommendation step uses NVIDIA NIM to reason over the Evidence Pack and determine which actions are supported by the available evidence.

Policy Enforcement

The recommended actions are not executed directly from the LLM output. A deterministic policy layer evaluates each recommendation against predefined authorization tiers and routes it to the appropriate execution or approval path.

The policy tiers are:

Auto
L1
L2

The final execution step either performs an automatically authorized action or routes the case for the required level of approval. This keeps the LLM responsible for reasoning and recommendation while deterministic logic controls what the system is actually allowed to execute.

Writing the Investigation Back to the Graph

The investigation does not end when an action is executed. The system writes the investigation result back into TigerGraph so that the case becomes part of the graph's persistent investigation history.

The write-back step creates the relevant InvestigationCase, Evidence, and ResolvedCase records and connects them to the entities involved in the investigation. This allows future investigations to use previous cases as structured evidence rather than treating them as unrelated historical documents.

From Investigation to Case Memory

This creates a feedback loop: the graph provides context for the current investigation, and the completed investigation becomes new context that can be retrieved in future cases.

A Complete Investigation: HHG-014

To make the workflow concrete, here is one of the HHGOA benchmark cases processed by the system: HHG-014.

The investigation concluded with a closed_fraud status and a fraud verdict. The system identified the card_not_present_new_device pattern, with an exposure of $74.96, and found four similar prior cases: CC-1066, CC-2964, CC-3587, and CC-1673.

Recommended Actions

The investigation produced two actions:

• BLOCK_CARD — L1 action based on the shared-device origin identified during investigation
• CREATE_CASE — automatic action based on the identified ring pattern

The completed investigation was written back to the graph, and a SAR file was generated for the case.

From Investigation to SAR

When a case meets the reporting criteria, the system generates a FinCEN-standard Suspicious Activity Report (SAR) narrative from the completed investigation. The reporting step uses the structured investigation result so that the narrative remains connected to the evidence, case outcome, and actions recorded during the investigation.

For HHG-014, the investigation produced a SAR file alongside the final case result. This keeps regulatory reporting as part of the same end-to-end workflow rather than treating it as a separate manual step after the investigation is complete.

Reliability and Design Choices

The system deliberately separates LLM reasoning from deterministic parts of the investigation. This makes the workflow more predictable while still allowing the agent to handle the parts of the process that benefit from flexible reasoning.

Deterministic Where It Matters

Evidence sufficiency, policy enforcement, and action execution are handled deterministically. These steps use explicit rules rather than relying on the LLM to decide whether evidence is sufficient or whether an action is authorized.

Graph-Based Case Memory

Previous investigations are stored as structured graph records instead of being treated only as text documents. This allows the system to retrieve prior cases through their relationships with customers, cards, devices, transactions, and other entities.

Structured Outputs

The investigation workflow uses structured outputs between its stages. This keeps evidence, recommendations, policy decisions, and final case results separated and makes the workflow easier to trace and debug.

Provider Fallback

The LLM layer supports multiple providers through a common wrapper. NVIDIA NIM is the primary provider, with Gemini and Groq available as fallback providers. This helps the system continue operating when a provider reaches a rate limit or becomes temporarily unavailable.

Curated Evidence Instead of Raw Graph Dumps

The agent does not send the entire graph to the LLM. Instead, it builds a focused Evidence Pack containing the transaction context, connected entities, detected patterns, prior cases, missing evidence, and contradictions. This keeps the reasoning context focused on information relevant to the investigation.

Results

The system was evaluated against all 20 HHGOA benchmark cases. Each case was processed through the complete investigation workflow, from evidence collection and graph-based investigation through action recommendation, policy enforcement, and graph write-back.

The evaluation tracks the final case outcomes, regulatory reports, recommended actions, and investigation latency across the benchmark.

The benchmark results show that the complete investigation pipeline can process the cases end-to-end while preserving the investigation context and writing the resulting case records back into the graph.

Action Distribution

The system also records which actions were recommended and executed across the benchmark cases. This provides a view of how the investigation agent translated evidence into operational outcomes.

Across the 20 benchmark cases, the most frequently recommended actions were MONITOR_CARD, VERIFY_WITH_CUSTOMER, and CREATE_CASE. BLOCK_CARD was recommended for cases with confirmed customer denial or shared-device evidence. FILE_REPORT was issued for the 10 cases that met the SAR threshold. Each action was routed to its authoritative approval tier — auto for monitoring and case creation, L1 for card blocks under $2,500 exposure, and L2 for SAR filings.

Lessons Learned

Building the investigation workflow highlighted several practical challenges that are easy to overlook when designing an agentic system.

LLM Rate Limits Matter

LLM-based investigation and recommendation steps introduce external rate limits and availability constraints. A multi-provider wrapper helped reduce the impact of provider-specific limits by allowing the system to fall back to another supported provider.

Deterministic Logic Is More Reliable for Critical Decisions

The investigation showed that some decisions are better handled by deterministic logic. Evidence sufficiency, policy enforcement, and approval routing use explicit rules so that the LLM does not directly control critical workflow decisions.

Structured Graph Writes Are Valuable

Writing completed investigations back into the graph makes case history immediately useful to future investigations. Instead of relying only on unstructured historical documents, the system preserves relationships between cases and the entities involved.

Prompt Structure Matters

The quality of LLM reasoning depends heavily on how the investigation context is structured. Providing a focused Evidence Pack with clearly separated evidence, patterns, prior cases, missing information, and contradictions produces a more useful reasoning context than passing large amounts of raw graph data.

Agentic Does Not Mean Everything Should Be an LLM

One of the biggest design lessons was that the strongest architecture was a hybrid one. The LLM handles flexible investigation and recommendation, while deterministic components handle evidence collection, sufficiency checks, policy enforcement, execution, and graph write-back.

What's Next

The current system demonstrates the complete investigation workflow on the HHGOA benchmark. The next step is to extend the prototype toward a more complete investigation environment.

Full Dataset Integration

The current benchmark evaluation focuses on the 20 investigation cases. A larger dataset integration would provide a broader environment for evaluating graph-based investigation and case memory.

Live Agent Runs in the UI

The current frontend presents investigation results and case data. A future version could allow investigators to trigger agent runs directly from the interface and observe the investigation as it progresses.

More Fraud Detectors

Additional deterministic detectors can be added to identify more behavioral and relationship-based fraud patterns. These detectors would provide the agent with a broader set of structured signals during investigation.

Sufficiency Calibration

The current evidence sufficiency score uses fixed weights and a defined threshold. Future evaluation can calibrate these values against a larger set of investigation outcomes to determine how well the scoring system separates sufficiently supported cases from cases requiring additional evidence.

Human-in-the-Loop L2 Integration

The current policy layer supports automatic, L1, and L2 authorization tiers. A future implementation could connect the L2 path to a real human approval workflow so that higher-risk actions can be reviewed before execution.

Try It Yourself

The complete project is available on GitHub, including the investigation workflow, graph configuration, custom HHGOA tools, frontend, and benchmark answer files.

Repository

You can find the project here:

https://github.com/subratkumarpadhy4/HHGoa

Benchmark Answers

The generated investigation answers are available in the results/answers/ directory. These files contain the outputs produced for the benchmark cases and can be used to inspect the investigation results in more detail.

Running the Project

The project can be run locally using Docker on Windows or Linux. The repository contains the required setup and configuration needed to reproduce the investigation environment.

The goal is to make the system reproducible so that others can explore the graph structure, investigation workflow, agent reasoning, and resulting case records.

Screenshots

Here are a few views of the system in action.

Investigation Dashboard

The dashboard provides an overview of the investigation results, including the case summary, reasoning chain, recommended actions, and investigation status.

Graph Investigation View

The graph view shows how the investigation traverses relationships between transactions, customers, cards, devices, and prior cases.

Case Details and SAR

The case details view brings together the structured investigation result and generated SAR output for a completed case.

Case Queue

The case queue provides an overview of the cases processed by the system and their current investigation status.

Acknowledgements

This project was built as a team effort. Thanks to everyone who contributed to the development, investigation workflow, graph modeling, frontend, testing, and evaluation of the system.

Team:

1. SUBRAT KUMAR PADHY
2. PRIYANSHU JENA
3. DINESH KUMAR