How we combined TigerGr
aph, LangGraph, MCP, evidence analysis, case memory, and policy-based decisions to investigate suspicious transactions.
Introduction
Fraud detection is often treated as a classification problem: given a transaction, determine whether it is suspicious or legitimate.
But real fraud investigation requires more than a risk score.
When a transaction is flagged, an investigator needs to understand the context around it:
Who is the customer?
Which card was used?
Which device was involved?
Are there related transactions?
What historical information is available?
What evidence supports the suspicion?
What evidence contradicts it?
Is the available evidence sufficient?
What action should be taken?
For the TigerGraph × Hacker House Goa challenge, our team built FraudGraph Investigator, an AI-powered fraud investigation system that combines connected-data investigation, agentic workflows, evidence analysis, uncertainty assessment, and policy-governed actions.
What We Built
FraudGraph Investigator takes a suspicious transaction and turns it into a structured investigation.
Instead of simply treating a high-risk transaction as fraud, our system follows a complete investigation workflow:
Suspicious Transaction → Investigation Planning → Evidence Collection → Evidence Analysis → Hypothesis Evaluation → Uncertainty Assessment → Evidence Sufficiency → Policy Evaluation → Next-Best Action → Case Memory
The system can produce three main actions:
BLOCK_CARD
VERIFY_WITH_CUSTOMER
ESCALATE
A key design principle was to separate AI-assisted investigation from the final operational decision. The investigation produces evidence and reasoning, while explicit policy rules govern the final action.
System Architecture
Our system consists of several layers:
Investigator UI
↓
FastAPI API
↓
LangGraph Investigation Workflow
↓
MCP Investigation Tools
↓
TigerGraph / Dataset
↓
Evidence Analysis
↓
Policy Engine
↓
Next-Best Action
The architecture separates the data layer, investigation workflow, reasoning, policy enforcement, and user interface.
This makes the system easier to test, inspect, and extend.
Why We Used TigerGraph
Fraud rarely exists as an isolated transaction.
A transaction can be connected to several entities, including:
Customer → Card → Transaction → Device → Location → Related Transactions
It can also connect to historical investigation information.
This is where graph-based investigation becomes useful.
Instead of looking at only one transaction, our system can investigate the relationships surrounding that transaction.
TigerGraph provides the graph-oriented foundation for this approach, allowing connected entities and their relationships to become part of the investigation.
The key question changes from:
"How risky is this transaction?"
to:
"What else is connected to this transaction, and what does that context tell us?"
Using MCP for Investigation
We used Model Context Protocol (MCP) to expose investigation capabilities as structured tools.
The agent does not directly manipulate the underlying data. Instead, it requests specific investigation operations through MCP.
The general flow is:
LangGraph Agent → MCP Tool → Data/Graph Layer → Structured Evidence → Investigation Workflow
The investigation tools provide targeted information such as:
Transaction details
Customer information
Connected entities
Shared devices
Historical fraud information
Related activity
Temporal patterns
Geographic/contextual signals
The returned information becomes evidence that can be used during the investigation.
LangGraph Investigation Workflow
We used LangGraph to orchestrate the investigation as a structured workflow instead of relying on a single LLM call.
The workflow moves through several stages.
- Case Loaded
The suspicious transaction and case information are loaded.
- Investigation Planned
The system determines what evidence needs to be collected.
- Evidence Collected
MCP tools retrieve the required information from the available data sources.
- Evidence Analysed
The collected information is organized and classified.
- Hypotheses Evaluated
Possible explanations for the transaction are considered, such as:
Card-not-present fraud
New-device activity
Card testing
Out-of-region usage
- Uncertainty Assessed
The workflow evaluates how uncertain the investigation remains.
- Evidence Sufficiency
The system determines whether enough evidence exists to support an operational decision.
- Policy Evaluation
The investigation state and evidence are evaluated against deterministic policy rules.
- Action Determined
The system produces the next-best action.
- Case Memory Written
The investigation result is stored so that future investigations can use historical context.
Evidence Sufficiency vs. Uncertainty
One of the important design decisions in our system was to separate evidence sufficiency from uncertainty.
These are not the same thing.
A case can have enough evidence to support a decision while still having significant uncertainty.
For example:
Evidence Sufficiency: SUFFICIENT
Uncertainty: HIGH
This distinction prevents the system from treating a high risk score as the only factor in determining the final action.
The investigation considers both the available evidence and the remaining uncertainty.
HHG-010 Case Study
One of our benchmark cases is HHG-010.
The investigation produced:
Customer: C10434
Transaction: 3506725
Risk Score: 0.90
Amount: $1,000.03
Status: COMPLETE
Evidence: SUFFICIENT
Uncertainty: HIGH
Recommended Action: ESCALATE
The system identified both supporting and contradictory evidence.
For example, the investigation found:
$0 confirmed fraud + $1,000.03 pending exposure
The transaction used a desktop/Windows device
The customer had no prior confirmed fraud cases
The result was therefore not simply:
High Risk → BLOCK
Instead, the investigation resulted in:
High Risk + Sufficient Evidence + High Uncertainty → ESCALATE → Senior Analyst Approval
This demonstrates an important principle of our system:
Investigate first, then act based on evidence and policy.
Historical Case Memory
Fraud investigations should not always start from zero.
FraudGraph Investigator includes a case memory layer that stores information from previous investigations.
This provides historical context such as:
Customer history
Previous transactions
Previous investigation outcomes
Cards involved
Previous actions
Approval information
The goal is to make future investigations more context-aware while keeping the information structured and traceable.
Policy-Governed Decisions
Another important component is the deterministic policy layer.
The LLM assists with investigation and reasoning, but operational actions are controlled through explicit policy rules.
The overall decision flow is:
Evidence + Investigation State + Uncertainty + Risk/Exposure
↓
Policy Engine
↓
BLOCK_CARD / VERIFY_WITH_CUSTOMER / ESCALATE
This separation helps keep the final operational action governed rather than allowing an LLM to directly make an unrestricted decision.
Investigator Dashboard
We built an interactive FastAPI-based investigator dashboard to make the investigation results accessible through a single interface.
The dashboard provides:
Case navigation
Investigation reports
Risk information
Supporting evidence
Contradictory evidence
Hypotheses
Case memory
Investigation workflow
Recommended action
Benchmark results
Validation status
An investigator can move from the overall benchmark view into an individual case and inspect the evidence and reasoning behind the result.
Benchmark Results
We evaluated the complete workflow across 20 benchmark investigations.
The expected action distribution was:
Action Cases
BLOCK_CARD 15
VERIFY_WITH_CUSTOMER 4
ESCALATE 1
Total 20
Our benchmark dashboard showed:
20 total cases
20 reports loaded
20/20 cases with sufficient evidence
0 benchmark errors
0 benchmark warnings
The end-to-end validation also checked the expected action invariants across the benchmark cases.
Technology Stack
Technology Role
TigerGraph Connected graph investigation
LangGraph Agent/workflow orchestration
MCP Structured investigation tools
Python Core implementation
FastAPI API and investigator dashboard
Case Memory Historical investigation context
Policy Engine Deterministic action governance
What We Learned
The biggest lesson from this project was that building an AI investigation system is not only about choosing an LLM.
A practical system also needs:
Connected Data + Investigation Tools + Agent Workflow + Evidence + Uncertainty + Policy + Testing + User Interface
Graph technology was particularly useful because fraud investigations naturally involve relationships between entities.
We also learned the importance of separating:
What the model reasons about → What evidence exists → What the policy allows → What action is finally taken
Future Improvements
There are several areas we would explore in a production version.
Real-Time Graph Integration
The system could be connected to continuously updated transaction streams and a production TigerGraph environment.
Advanced Graph Analytics
Additional graph algorithms could help identify:
Fraud rings
Suspicious communities
Entity similarity
Coordinated transaction patterns
Suspicious subgraphs
Improved Case Memory
A larger historical investigation repository could provide richer contextual reasoning.
Human-in-the-Loop Investigation
Investigators could approve, reject, or request additional evidence before a final action.
Production Monitoring
A production deployment would also require monitoring for data drift, model drift, investigation latency, policy violations, false positives, and changing fraud patterns.
Conclusion
FraudGraph Investigator was built around a simple idea:
Fraud investigation should be evidence-driven, connected, and governed — not just a prediction from a single transaction.
By combining TigerGraph, LangGraph, MCP, case memory, evidence analysis, and deterministic policy rules, we created an end-to-end investigation workflow that moves from a suspicious transaction to an explainable next-best action.
The project gave us hands-on experience building an AI system where graph relationships, agentic workflows, evidence, uncertainty, and governance work together.
Thanks to TigerGraph and Hacker House Goa for providing the challenge and the opportunity to build around connected-data intelligence.
Top comments (0)