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.
Top comments (0)