TigerAttack: Building an Evidence-Grounded Fraud Investigation Agent with TigerGraph, GraphRAG & MCP

Rohit Sharma — Wed, 23 Sep 2026 17:50:16 +0000

Fraud investigation is rarely a single-query problem.

A suspicious transaction may look normal in isolation, while its surrounding relationships — shared devices, connected identities, transaction velocity, previous cases, customer history, and behavioral patterns — reveal a much larger picture.

For the TigerGraph × Hacker House Goa challenge, we built TigerAttack, an agentic fraud investigation platform designed to investigate these relationships, gather evidence, reason under uncertainty, and recommend the next action while maintaining a complete investigation trail.

Graph + Retrieval + Deterministic Analytics + Agentic Reasoning

The goal was not to build another chatbot that generates a fraud explanation.

The goal was to build an investigation system where the agent's conclusions are grounded in retrieved evidence.

What We Built

TigerAttack starts with an investigation trigger such as:

A suspicious transaction
A customer dispute
A fraud-risk signal
An analyst-initiated investigation

From there, the system automatically performs an investigation lifecycle:

Investigation Trigger
↓
Evidence Collection
↓
Graph Investigation
↓
Historical Case Retrieval
↓
Fraud Pattern Detection
↓
Risk & Exposure Assessment
↓
Evidence Sufficiency Check
↓
Additional Evidence Request
↓
Policy Evaluation
↓
Next-Best Action
↓
Case Update + Audit Trail
↓
Case Memory

The important part is that the agent does not simply ask an LLM:

"Is this transaction fraudulent?"

Instead, it first gathers structured evidence and then reasons over that evidence.

Architecture

TigerAttack is organized into three major application layers.

Frontend — Investigation Command Center

The frontend provides investigators with a visual view of:

Active investigations
Risk signals
Retrieved evidence
Fraud patterns
Customer and transaction context
Historical cases
Recommended actions
Approval requirements
Audit information
Case progression

The interface is designed around an investigation workflow rather than a generic conversational chatbot.

FastAPI Backend — Intelligence Layer

The FastAPI backend is the orchestration layer.

It coordinates:

Investigation state
TigerGraph queries
TigerGraph MCP tools
GraphRAG retrieval
Historical case memory
Fraud pattern detection
Risk calculations
Exposure calculations
Policy evaluation
Evidence requests
Action recommendations
Case updates
SAR generation
Audit logging

The backend essentially acts as the control plane connecting the graph, retrieval systems, deterministic engines, and reasoning model.

TigerGraph — Investigation Graph

TigerGraph acts as the central investigation graph.

Instead of treating every transaction as an isolated database row, we represent the relationships between entities.

A simplified representation looks like:

Customer
│
├── owns ──> Card / Account
│ │
│ └── performs ──> Transaction
│ │
│ ├── Merchant
│ ├── Device
│ └── Identity
│
└── connected to ──> Previous Cases

This makes relationship-based investigation possible.

For example, a transaction may look relatively ordinary by itself.

The graph can reveal that:

Transaction
│
├── Device → connected to multiple customers
│
├── Customer → unusual transaction velocity
│
├── Identity → connected to previous activity
│
└── Customer → related historical fraud cases

That connected context is extremely difficult to obtain from isolated rows alone.

How We Used TigerGraph

TigerGraph is not being used merely as a database.

It is the investigation engine.

We use graph relationships to investigate:

Transaction history
Customer behavior
Connected cards/accounts
Shared identities
Device relationships
Transaction velocity
Behavioral anomalies
Historical fraud cases
Fraud patterns
Financial exposure

We use GSQL to create reusable investigation queries instead of writing case-specific logic for individual benchmark cases.

The agent can therefore request structured investigation operations such as:

Get Transaction Context
↓
Get Customer History
↓
Find Related Entities
↓
Find Shared Devices / Identities
↓
Analyze Transaction Velocity
↓
Find Historical Cases
↓
Calculate Exposure
↓
Build Evidence Pack

This makes the graph an active part of the reasoning process rather than a decorative component of the architecture.

TigerGraph MCP

To connect the agentic backend with TigerGraph, we use the TigerGraph MCP integration.

The MCP layer exposes graph capabilities as tools that the investigation agent can invoke.

Conceptually:

TigerAttack Agent
│
│ tool calls
▼
TigerGraph MCP
│
▼
TigerGraph
│
├── GSQL
├── Graph Traversals
├── Relationship Analysis
└── Investigation Data
│
▼
Structured Evidence
│
▼
TigerEffect Agent

This creates a controlled boundary between the reasoning layer and the graph.

Instead of allowing the LLM to directly interpret raw database contents, the agent requests specific investigation operations and receives structured results.

This also gives us a clearer provenance trail for the evidence used during an investigation.

GraphRAG: Connecting Graph Evidence With Context

Graph evidence alone is not enough.

A fraud investigation also requires context such as:

Fraud policies
Fraud typologies
Investigation procedures
Regulatory requirements
Historical case information

This is where our GraphRAG layer comes in.

The retrieval pipeline combines structured graph evidence with relevant contextual information.

              Investigation
                   │
         ┌─────────┴─────────┐
         ↓                   ↓
   TigerGraph             Retrieval
   Graph Evidence         Knowledge
         │                   │
         │             ┌─────┴─────┐
         │             │ Policies  │
         │             │ Typologies│
         │             │ Past Cases│
         │             └───────────┘
         │                   │
         └─────────┬─────────┘
                   ↓
             Evidence Pack
                   ↓
              Reasoning Layer

The reasoning model therefore receives relevant context instead of being asked to reason over an entire dataset.

The Agentic Investigation Loop

The most important part of TigerAttack is the investigation loop.

The agent does not have to make a decision immediately.

It can recognize when the available evidence is insufficient and request additional evidence.

Example

Suppose a transaction has a high risk signal.

The first investigation may find:

High-risk transaction
+
New device
+
Unusual transaction velocity

But that may not be enough to confidently determine what happened.

Instead of forcing a conclusion, the agent can transition into an evidence-gathering state.

Evidence Insufficient
↓
Request Additional Evidence
↓
Customer Validation / Step-up Authentication
↓
Evidence Received
↓
Reassess
↓
Policy Evaluation
↓
Next-Best Action

This is important because real fraud investigation is an uncertainty-management problem.

Deterministic Fraud Analytics

We deliberately do not make the LLM responsible for every calculation.

Deterministic components handle things such as:

Risk calculations
Transaction patterns
Exposure calculations
Policy rules
Evidence sufficiency
Action constraints

The LLM is primarily used for:

Evidence synthesis
Investigation planning
Pattern interpretation
Explanation
Uncertainty reasoning
Natural-language case summaries

This separation makes the system more predictable and auditable.

A useful mental model for the architecture is:

TigerGraph
↓
Facts

Deterministic Engines
↓
Measurements

GraphRAG
↓
Context

LLM / Agent
↓
Reasoning

Policy Engine
↓
Allowed Action

Case Memory
↓
Future Investigation
Case Memory

An investigation should not disappear after the response is generated.

TigerAttack maintains case memory containing:

Findings
Evidence
Decisions
Actions
Outcomes
Investigation history

Future investigations can retrieve similar historical cases and use their outcomes as additional context.

This creates a feedback loop:

Investigation
↓
Evidence
↓
Decision
↓
Outcome
↓
Case Memory
↓
Future Investigation

The system therefore becomes more useful as the investigation history grows.

Explainability and Grounding

One of our main design principles was:

Every important conclusion should be traceable back to evidence.

The agent separates:

Retrieved facts

from

Reasoning

and

Recommended action

For example:

Evidence:
• Transaction originated from a new device
• Device is associated with multiple identities
• Customer shows abnormal transaction velocity
• Related historical case exists

Reasoning:
The combined relationship and behavioral signals
increase the likelihood of coordinated or unauthorized activity.

Action:
Request additional customer validation / escalate according
to the applicable fraud policy.

This prevents the system from treating an LLM-generated statement as evidence.

Validation Results

We evaluated the investigation pipeline against the challenge's 20 benchmark cases.

Our latest backend validation completed:

20/20 benchmark investigations completed
140/140 MCP calls completed
300 graph evidence items retrieved
100 historical case records retrieved
12 evidence requests and reassessments
20/20 case-memory write/readbacks
412 audit events generated
0 grounding failures
94 automated tests passed

These numbers describe pipeline execution and grounding behavior; they should not be interpreted as a claim of 100% fraud-detection accuracy.

One useful engineering lesson from validation was that integration metadata can sometimes be incomplete even when the underlying graph query execution succeeds. We therefore kept the actual query execution and returned evidence as the source of truth rather than treating metadata availability as evidence accuracy.

What We Learned

The biggest lesson was simple:

Reliable AI requires more than an LLM.

The graph provides connected context.

Deterministic engines provide reproducible calculations.

The policy engine constrains decisions.

GraphRAG provides relevant contextual knowledge.

The agent coordinates the investigation.

And provenance connects the final explanation back to evidence.

The strongest part of the system is therefore not any single model.

It is the combination of these components.

What We Would Improve

With additional development time, we would extend TigerAttack with:

Real-Time Investigation Streaming

Support streaming transaction and behavioral signals so investigations can react to events continuously.

Advanced Temporal Fraud Detection

Add more sophisticated time-window and sequence-based graph algorithms for detecting evolving fraud campaigns.

Analyst Feedback Loops

Allow analysts to provide structured feedback on evidence quality, recommendations, and investigation outcomes.

Stronger Evaluation

Expand the evaluation framework with larger datasets, additional fraud typologies, adversarial cases, and systematic model comparisons.

Production Observability

Add production-grade authentication, metrics, tracing, monitoring, and operational alerting.

Richer Graph Visualization

Allow investigators to visually explore the relationship graph behind a recommendation instead of only viewing the summarized evidence.

Final Architecture

At a high level, the complete system looks like this:

                ┌──────────────────────┐
                │     Investigator     │
                │     Next.js UI       │
                └──────────┬───────────┘
                           │
                           ▼
                ┌──────────────────────┐
                │    FastAPI Backend   │
                │                      │
                │ Investigation Agent  │
                │ Policy Engine        │
                │ Risk Engine          │
                │ Case Management      │
                │ Audit + SAR          │
                └──────────┬───────────┘
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
   TigerGraph MCP      GraphRAG        Case Memory
          │                │                │
          ▼                ▼                ▼
   ┌────────────┐   ┌─────────────┐  ┌─────────────┐
   │ TigerGraph │   │ Policies /  │  │ Historical  │
   │            │   │ Typologies  │  │ Cases       │
   │ Customers  │   │ Procedures  │  │ Outcomes    │
   │ Transactions│  │ Context     │  │ Decisions   │
   │ Devices    │   └──────┬──────┘  └─────────────┘
   │ Identities │          │
   │ Cases      │          │
   └─────┬──────┘          │
         │                 │
         └────────┬────────┘
                  ▼
          ┌───────────────┐
          │ Evidence Pack │
          └───────┬───────┘
                  ▼
          ┌───────────────┐
          │ Reasoning LLM │
          └───────┬───────┘
                  ▼
         ┌──────────────────┐
         │ Next-Best Action │
         │ + Explanation    │
         └────────┬─────────┘
                  ▼
          Case + Audit Trail

Conclusion

TigerAttack was built around a simple principle:

Don't ask an AI to guess what happened. Give it the graph, the evidence, the policy, and the tools to investigate what happened.

By combining TigerGraph, GSQL, TigerGraph MCP, GraphRAG, deterministic fraud analytics, case memory, and agentic reasoning, we built an investigation workflow that is designed to be evidence-grounded, explainable, policy-aware, and useful to real analysts.

The result is not simply an AI that says "this looks fraudulent."

It is an agent that can investigate why, determine what evidence is missing, understand what the policy permits, and produce a traceable next-best action.

TigerAttack — Investigate the graph. Ground the evidence. Explain the decision.

DEV Community: Rohit Sharma

TigerAttack: Building an Evidence-Grounded Fraud Investigation Agent with TigerGraph, GraphRAG & MCP