Building an Agentic Fraud Investigation Agent with TigerGraph

Shampita Bhattacharjee — Fri, 25 Sep 2026 06:24:41 +0000

Introduction

Fraud detection is often treated as a classification problem: a transaction receives a risk score and the system decides whether it is fraudulent.

Real-world fraud investigation is more complicated.

A suspicious transaction needs to be investigated in context. An analyst may need to examine the customer's transaction history, connected cards, devices, IP addresses, merchants, previous fraud cases, known fraud patterns, and applicable policies before deciding what should happen next.

For the TigerGraph Agentic Fraud Investigation Hackathon (HHGOA), we built an Agentic Fraud Investigation Agent that treats a fraud signal as the beginning of an investigation rather than the final answer.

Our system can:

Start an investigation from a fraud signal, customer report, or analyst trigger
Retrieve connected evidence from TigerGraph
Detect fraud patterns using graph-based analysis
Search previous investigations for similar cases
Assess fraud probability and uncertainty
Request additional evidence when confidence is insufficient
Reassess the case after receiving new evidence
Recommend the next best action
Apply policy and permission controls
Maintain an investigation audit trail
Write completed cases back into the graph as future case memory
Present the investigation through an analyst dashboard

The complete implementation is available on GitHub.

The Core Idea

The central idea behind our system is simple:

A fraud score should trigger an investigation, not automatically determine the outcome.

The repository explicitly implements an uncertainty-aware investigation loop. The agent starts with an initial assessment, gathers graph evidence, evaluates confidence, requests additional evidence when necessary, and updates its recommendation before closing the investigation.

This is particularly important because the model risk score is only one signal.

For example, a high-risk transaction involving a customer's usual device and merchant can mean something very different from a similar score involving a new device and unusual transaction behavior.

The system therefore combines the initial model score with graph-derived behavioral signals.

System Architecture

The overall architecture consists of five major layers:

                ┌──────────────────────┐
                │   Fraud Trigger      │
                │ Risk / Customer /    │
                │ Analyst              │
                └──────────┬───────────┘
                           │
                           ▼
                ┌──────────────────────┐
                │   LangGraph Agent    │
                │ Investigation Loop   │
                └──────────┬───────────┘
                           │
      ┌────────────────────┼────────────────────┐
      │                    │                    │
      ▼                    ▼                    ▼

┌────────────────┐ ┌─────────────────┐ ┌───────────────┐
│ TigerGraph │ │ GraphRAG │ │ Case Memory │
│ │ │ │ │ │
│ Customers │ │ Policy │ │ Prior Cases │
│ Cards │ │ Typologies │ │ Outcomes │
│ Transactions │ │ Regulations │ │ Relationships │
│ Devices │ │ Evidence │ │ │
│ IPs │ │ │ │ │
│ Merchants │ │ │ │ │
└───────┬────────┘ └────────┬────────┘ └───────┬───────┘
│ │ │
└─────────────────────┼────────────────────┘
▼
┌──────────────────────┐
│ Risk + Uncertainty │
│ Assessment │
└──────────┬───────────┘
│
┌─────────┴─────────┐
│ │
Uncertain Sufficient
│ │
▼ ▼
┌─────────────┐ ┌──────────────┐
│ Request │ │ Next Best │
│ Evidence │ │ Action │
└──────┬──────┘ └──────┬───────┘
│ │
└───────┐ ┌───────┘
▼ ▼
┌──────────────┐
│ Policy Engine│
└──────┬───────┘
│
┌──────────┴──────────┐
▼ ▼
Auto Actions Human Approval
│ │
└──────────┬──────────┘
▼
┌────────────────────┐
│ Case + Audit Trail │
│ Write Back to Graph│
└────────────────────┘

The repository implements this architecture using a LangGraph investigation state machine, TigerGraph queries, GraphRAG grounding, policy controls, case memory, and a Streamlit dashboard.

Technology Stack

The main technologies used in the implementation are:

Component Technology
Agent orchestration LangGraph
LLM integration LangChain
LLM providers OpenAI / Anthropic / Google Gemini support
Graph database TigerGraph
TigerGraph Python client pyTigerGraph
Graph query language GSQL
Agent graph tools TigerGraph MCP-compatible layer
Retrieval / grounding GraphRAG
Backend / agent Python
Dashboard Streamlit
Visualization Plotly + NetworkX
Data processing Pandas + NumPy
Validation Pytest

The dependency configuration confirms LangGraph, LangChain, provider integrations, pyTigerGraph, Streamlit, Plotly, NetworkX, Pandas, NumPy, Pydantic and Pytest.

Why TigerGraph?

Fraud investigations are naturally suited to graph databases because the important information is highly connected.

Our graph models entities such as:

Customers
Cards
Transactions
Devices
IP addresses
Merchants
Fraud cases
Fraud patterns

Instead of looking at a transaction independently, the agent can traverse its relationships and investigate the surrounding context.

The repository's graph schema and queries are designed specifically for:

Multi-hop evidence retrieval
Shared-attribute/ring detection
Transaction velocity analysis
Fraud pattern detection
Similar-case retrieval

GSQL Investigation Queries

The graph investigation layer provides several types of queries.

For example, the system can examine:

Evidence subgraph

Retrieve the neighbourhood surrounding a suspicious transaction, including related customers, cards, devices, IPs and merchants.

Card history

Build a behavioral baseline for the card, including:

Previous transaction count
Average transaction amount
Maximum amount
Previously used products
Regions
Transaction channels
Transaction velocity

Look at transactions occurring within a defined time window to identify bursts or testing sequences.

Device relationships

Identify other cards that have used the same device profile.

Regional activity

Determine whether a card is being used in an unfamiliar region and whether activity in the home region continues simultaneously.

Recurring transaction detection

Check whether a disputed transaction resembles the customer's historical recurring payment pattern.

These investigative operations are exposed through the graph client and correspond to the graph/tool layer available to the agent.

TigerGraph MCP Integration

We designed the tool layer so that the agent can interact with TigerGraph through either:

TigerGraph MCP, connected to a real TigerGraph Savanna/Community Edition instance, or
A direct GraphClient implementation used for offline execution and testing.

The tool names and parameters are intentionally aligned with the installed GSQL query names. This means the investigation logic does not need to change when switching between direct execution and MCP-based access.

This separation also allowed us to develop and demonstrate the system without requiring every execution environment to have a live TigerGraph cluster.

Offline Mode

One practical challenge with large fraud datasets is that the complete transaction file is large.

The implementation therefore supports an offline mode.

Instead of requiring a live TigerGraph instance, the GraphClient can answer the same investigation questions using the supplied CSV data and Pandas.

The implementation also loads only the transaction columns required by the investigation rather than loading every column from the original dataset into memory.

This gives us two execution modes:

            Investigation Agent
                   │
          ┌────────┴────────┐
          │                 │
          ▼                 ▼
    ONLINE MODE        OFFLINE MODE
          │                 │
    pyTigerGraph       Pandas/CSV
          │                 │
          ▼                 ▼
    TigerGraph          Local Data

The Investigation Agent

The core workflow is implemented in agent/investigator.py.

The investigation proceeds through several stages.

Step 1 — Trigger

A fraud signal, customer report, or analyst request starts the investigation.

Step 2 — Open Case

The system creates an investigation case and records the trigger.

Step 3 — Gather Evidence

The agent queries the graph and gathers:

Transaction information
Device information
Card history
Transaction bursts
Regional activity
Shared devices
Previous fraud cases
Step 4 — Assess Risk

The system combines the available signals to calculate a fraud probability, classify the fraud pattern, and identify remaining evidence gaps.

Step 5 — Initial Next Best Action

Importantly, the system records the initial recommendation before requesting additional evidence.

This is required by the benchmark and allows us to demonstrate how the recommendation changes during the investigation.

Step 6 — Request Additional Evidence

If the evidence is insufficient, the agent can request actions such as customer validation or step-up authentication.

Step 7 — Reassess

The newly received evidence is incorporated into the assessment.

Step 8 — Final Action

The system produces a final recommendation.

Step 9 — Case Memory

The completed case is written back into the graph so that future investigations can retrieve it.

This entire flow is implemented in the Investigator workflow.

Uncertainty-Aware Fraud Assessment

Rather than allowing the initial model score to determine the verdict, our assessment layer starts from an uncertain baseline and incorporates multiple independent signals.

The implementation considers signals such as:

Model risk score
New device
Proxy connection
Card-testing sequence
Out-of-profile transaction amount
Transaction burst
Out-of-region activity
Shared device
Previous fraud cases
Previous cleared cases
Customer response
Step-up authentication result

The model score is intentionally treated as a weak prior rather than the final answer. Graph-derived evidence contributes additional weight to the assessment.

The system also supports several fraud patterns:

card_testing
card_not_present_fraud
card_not_present_new_device
out_of_region_use
account_takeover
undocumented
none

An important capability is identifying an undocumented coordinated pattern when shared-device activity connects multiple cards and previous fraud evidence exists.

GraphRAG: Combining Policy and Evidence

A major part of the architecture is our GraphRAG grounding layer.

We deliberately do not send raw transaction tables directly to the LLM.

Instead, the system builds a curated context containing:

Graph evidence

Evidence claims retrieved from the knowledge graph, including their provenance.

Similar cases

Previously closed investigations and their outcomes.

Policy information

Relevant sections from the fraud policy, fraud typologies and SAR guidance.

The LLM then receives this curated context.

This allows the LLM to focus on reasoning, synthesis and explanation, while the graph remains responsible for structured investigation and evidence retrieval.

This separation is an important design principle:

The LLM reasons over evidence; it does not replace graph analysis.

LLM Layer

The implementation is provider-agnostic.

It supports:

OpenAI
Anthropic
Google Gemini

through LangChain integrations.

The LLM is primarily used for:

Case summaries
Evidence-grounded explanations
SAR narratives
Natural-language synthesis

The system also has a deterministic fallback.

If an LLM provider or API key is unavailable, the investigation can still run using structured templates. This makes the benchmark and demonstration pipeline reproducible without making the entire investigation dependent on an external model.

Policy and Permission Engine

A fraud agent should not have unrestricted authority.

Our policy engine defines an explicit action catalog.

Actions include:

ALLOW_TRANSACTION
DECLINE_TRANSACTION
MONITOR_CARD
WARN_CUSTOMER
VERIFY_WITH_CUSTOMER
STEP_UP_AUTH
BLOCK_CARD
CREATE_CASE
FILE_REPORT
ESCALATE_TO_ANALYST
CLOSE_NO_FRAUD

The system also assigns approval routes:

auto
L1
L2

For example, BLOCK_CARD can be routed to L1 or L2 depending on exposure, while actions such as filing a report or blocking all cards require the higher approval route.

Actions outside the predefined catalog are rejected by the policy layer.

This prevents the agent from inventing arbitrary actions.

Evidence Requests

When the agent is uncertain, it does not simply guess.

It can request additional evidence.

The implementation currently supports simulated:

Customer validation
Step-up authentication

The evidence request is recorded in the case.

The investigation is then reassessed using the newly obtained information.

This creates a feedback loop:

Initial Evidence
↓
Risk Assessment
↓
Is Evidence Sufficient?
↓
No
↓
Request Evidence
↓
Receive Response
↓
Reassess
↓
Next Best Action

Case Memory

One of the most important features of the system is that completed investigations become future knowledge.

After an investigation is completed, the case is written back into TigerGraph.

The stored information includes:

Case ID
Customer
Card
Fraud pattern
Verdict
Status
Fraud probability
Affected transactions
Connected cards
Investigation summary
Outcome

Future investigations can then search this case memory for similar historical investigations.

This creates a continuous learning-style workflow:

New Investigation
↓
Graph Evidence
↓
Previous Cases
↓
Decision
↓
Write New Case
↓
Future Investigation
↓
Previous Cases + New Case

The system therefore becomes more context-aware as more cases are processed.

Next Best Action

The system records the next best action at two points:

Initial

Before additional evidence is requested.

Final

After the additional evidence has been received.

This is important because the recommended action can change during the investigation.

For example:

Initial assessment
↓
VERIFY_WITH_CUSTOMER
STEP_UP_AUTH
MONITOR_CARD

↓

Customer evidence

↓

Updated assessment
↓
BLOCK_CARD
CREATE_CASE
WARN_CUSTOMER

The dashboard also explicitly displays this initial-versus-final action history.

Analyst Dashboard

To make the agent's investigation observable, we built a Streamlit analyst dashboard.

The dashboard provides:

Case Details
Fraud probability
Fraud pattern
Exposure
Case status
SAR status
Graph tool calls
Investigation latency
Evidence

Each evidence item is displayed with its source and provenance.

Investigation Timeline

The analyst can see the sequence of investigation events.

Evidence Graph

The dashboard visualizes connections between:

Transactions
Cards
Devices
Previous cases
Next Best Action

The dashboard displays:

Initial actions
Final actions
What changed
Approval Queue

Actions requiring L1/L2 approval are presented to the analyst.

Answer File

The complete benchmark JSON can also be inspected from the interface.

Example Investigation: HHG-001

One of the generated case files demonstrates the full investigation flow.

For case HHG-001, transaction 3514030 was investigated with an initial risk score of 0.61.

The system did not immediately treat that score as a fraud verdict.

Instead, it gathered additional evidence, including graph context and historical cases.

The investigation then requested additional customer evidence.

After the evidence was received, the fraud probability increased to 0.81, and the recommended actions were updated accordingly.

The generated case record contains the evidence, prior cases, initial and final next-best actions, stop reason, tool-call count and latency.

The repository's case output provides the complete machine-readable investigation record.

Benchmark Execution

The repository includes a benchmark runner designed around the HHGOA submission format.

The benchmark runner:

Reads the case pack
Runs the Investigator on each case
Produces one JSON answer file per case
Records verdict
Records fraud probability
Records fraud pattern
Records exposure
Records SAR decision
Records final actions

For the official benchmark, the runner can be pointed to the HHGOA dataset containing the 20 evaluation cases.

Engineering for Reproducibility

A key engineering goal was making the system runnable even without a live TigerGraph cluster or LLM provider.

The repository therefore provides:

Offline graph execution
Deterministic fallback narratives
Sample data
Automated tests
Benchmark runner
Streamlit dashboard

This makes it possible to demonstrate the investigation pipeline end-to-end while retaining a production-style integration path through TigerGraph and MCP.

What We Learned

The biggest lesson from building this system was that fraud investigation is fundamentally a context and evidence problem.

A single transaction does not provide enough information.

Relationships between entities often reveal patterns that are invisible when examining individual records.

TigerGraph was particularly useful for representing those relationships and performing graph-native investigation.

We also learned that an agentic system needs more than an LLM.

The LLM provides reasoning and natural-language synthesis, but reliable investigation requires:

Structured tools
Explicit policies
Evidence provenance
Uncertainty handling
Approval controls
Case memory
Audit trails

Our architecture therefore keeps the LLM inside a controlled investigation workflow rather than giving it unrestricted authority.

What We Would Improve

With more time, we would improve several areas.

Larger-scale graph retrieval

The current GraphRAG implementation uses transparent keyword retrieval for policy documents. At larger scale, this could be replaced or extended with TigerGraph vector search.

More external evidence

Additional identity, device and financial signals could improve investigations.

Richer graph algorithms

More advanced graph algorithms could be added for coordinated fraud rings and entity-level risk propagation.

Production integrations

The current action layer contains simulated integrations for actions such as customer messages, freezes, card blocks, SAR filing and CRM updates. These could be replaced with real controlled APIs in a production environment.

Improved investigation UX

The Streamlit dashboard could be expanded into a production-grade fraud analyst application with richer case management and collaboration features.

Performance optimization

Large-scale investigations could benefit from further optimization of graph queries, retrieval and LLM calls.

Conclusion

We built an Agentic Fraud Investigation Agent powered by TigerGraph that goes beyond simple fraud classification.

The system combines:

TigerGraph + GSQL + LangGraph + GraphRAG + LLMs + Case Memory + Policy Controls + MCP-compatible Tools + Streamlit

to create an investigation loop that can:

Detect → Investigate → Gather Evidence → Assess Uncertainty → Request Evidence → Reassess → Recommend Action → Record → Learn from Previous Cases

The key idea is that an effective fraud investigation agent should not simply answer:

“Is this transaction fraudulent?”

Instead, it should be able to ask:

“What evidence do I have, what am I still uncertain about, what evidence should I gather next, and what action is justified by the available evidence and policy?”

That is the approach we implemented with TigerGraph.

Project

GitHub: TigerGraph Agentic Fraud Investigation — GitHub

DEV Community: Shampita Bhattacharjee

Building an Agentic Fraud Investigation Agent with TigerGraph