FraudGraph: Building an Agentic Fraud Investigation System with TigerGraph and LangGraph
TigerGraph × HHGoa 2026 — Agentic Fraud Investigation
Fraud investigation is rarely a problem of finding a single suspicious transaction.
A transaction can look suspicious in isolation, but the real signal may only become visible when we connect it to the customer's history, other cards, devices, regions, email identities, previous investigations, and the bank's fraud policies.
That was the problem we set out to solve with FraudGraph: an agentic fraud investigation system that does not simply classify a transaction as fraudulent, but investigates the surrounding graph, gathers evidence, evaluates uncertainty, requests additional evidence when necessary, and determines the next appropriate action while respecting predefined policies and human approval boundaries.
The system was built for the TigerGraph × HHGoa 2026 Agentic Fraud Investigation challenge.
The Problem
Traditional fraud detection systems are very good at producing signals.
A bank may already have a model-generated risk score for a transaction. But a risk score alone does not answer the questions an investigator actually needs to answer:
- What happened?
- Is this transaction connected to other suspicious activity?
- Has this card behaved similarly before?
- Is the device associated with other cards?
- Are multiple cards sharing a suspicious origin?
- Does this resemble a previous investigation?
- What evidence is still missing?
- Should the card be blocked?
- Should the case be escalated?
- Is a regulatory report required?
- Does the action require human approval?
The challenge dataset intentionally reflects this problem. It contains roughly 590,000 transactions, identity/device information, historical closed investigations, fraud policies, known fraud patterns, and 20 benchmark cases. Importantly, the transactions contain model risk scores but no direct Is Fraud flag.
So the objective was not simply:
"Predict fraud."
It was:
"Investigate the case and make a defensible next decision."
Our Approach
We built FraudGraph around one central idea:
The graph provides the evidence. The agent orchestrates the investigation. Deterministic policy logic controls what can actually happen.
The resulting architecture combines:
- TigerGraph for relationship-oriented investigation
- GraphRAG for evidence retrieval and contextual grounding
- LangGraph for investigation workflow orchestration
- Deterministic fraud-policy rules for action validation
- Case memory for previous investigations and outcomes
- MCP graph tools for exposing graph capabilities to the agent
- Streamlit for the investigation interface
- A local graph backend for fast development and reproducible testing
The challenge explicitly encouraged using TigerGraph for graph traversal, pattern detection, relationship analysis and investigation, with GraphRAG grounding the agent using graph and policy evidence.
Architecture
At a high level, an investigation follows this pipeline:
┌─────────────────────┐
│ Fraud Trigger │
│ Risk / Customer / │
│ Analyst Request │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ LangGraph │
│ Investigation Loop │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ GraphRAG │
│ Evidence Gathering │
└──────────┬──────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Transactions Devices History
│ │ │
└─────────────┼─────────────┘
│
▼
┌─────────────────────┐
│ Pattern Detection │
│ + Risk Assessment │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Is evidence enough? │
└───────┬───────┬─────┘
│ │
YES NO
│ │
│ ▼
│ Evidence Request
│ │
│ ▼
│ Reassessment
│ │
└───────┤
▼
┌─────────────────────┐
│ Deterministic │
│ Policy Engine R1-R10│
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Approval Routing │
│ Auto / L1 / L2 │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Case + SAR + Memory │
└─────────────────────┘
The important design decision here was to avoid putting the entire investigation inside the LLM.
The LLM can reason over evidence and help orchestrate the investigation, but graph retrieval, policy enforcement, approval routing, and validation remain controlled by deterministic application logic.
Modeling Fraud as a Graph
Fraud is inherently relational.
Instead of treating every transaction as an independent row, FraudGraph represents entities and their relationships.
The graph contains entities such as:
- Customers
- Cards
- Transactions
- Device profiles
- Regions
- Email identities
- Closed investigation cases
- Policies
For example:
Customer
│
├── owns ──► Card
│ │
│ ├── made ──► Transaction
│ │
│ └── used ──► Device
│
└── associated with ──► Region
Device ──► multiple Cards
Email ──► multiple Cards
Previous Case ──► Transaction / Card / Customer
This representation makes questions such as these natural:
"What other cards have been used from this device?"
"What transactions happened around this suspicious transaction?"
"Does this card share a device with other cards?"
"Has this customer or card appeared in previous investigations?"
These are graph questions rather than simple row-level classification questions.
Using TigerGraph as the Investigation Layer
TigerGraph is the relationship engine behind the production-style graph path.
We created:
- A graph schema
- Loading jobs
- Investigation GSQL queries
- A TigerGraph store implementation
- Graph-tool interfaces exposed through MCP
The ingestion pipeline processes the source dataset in chunks and prepares graph-compatible CSVs for TigerGraph.
The final ingestion verification processed:
- 590,742 transactions
- 144,432 identity records
- 13,553 cards
- 5,565 closed cases
The pipeline also exports slim CSVs for TigerGraph loading, including transactions, customers, cards, devices, closed cases, emails and regions.
We also implemented a local in-memory graph store.
That was deliberate.
It allowed us to run the same investigation contracts during development and automated testing without making every test dependent on a remote graph deployment. The local and TigerGraph implementations expose the same conceptual investigation operations.
Graph Queries
The TigerGraph layer contains investigation queries for operations such as:
- Card history
- Device neighbors
- Connected cards
- Transaction windows
- Customer relationships
- Related closed cases
- Graph-based investigation evidence
The agent does not need to understand how the graph is physically stored.
Instead, it can request a capability such as:
device_neighbors(device_id)
and receive structured evidence.
This separation became particularly useful when connecting the graph to the agent through MCP.
TigerGraph MCP + Agent Tools
We exposed the graph capabilities through an MCP server.
The MCP layer provides the agent with structured graph tools instead of requiring the model to generate arbitrary database operations.
The final implementation exposes 15 graph tools through MCP.
Conceptually:
LangGraph Agent
│
▼
MCP
│
▼
Graph Investigation Tools
│
▼
TigerGraph
This gives the agent a controlled interface to the graph while keeping graph access separate from the reasoning layer.
GraphRAG: Giving the Agent the Right Context
Retrieving graph data is not enough.
A fraud investigator needs context.
For each investigation, the GraphRAG layer assembles an evidence bundle containing relevant information such as:
- Card history
- Transaction windows
- Device connections
- Billing regions
- Behavioral patterns
- Relevant fraud policies
- Similar historical cases
- Detected fraud patterns
The evidence is then passed to the reasoning layer as structured investigation context instead of simply dumping raw graph data into the LLM.
This was especially important because the challenge required the agent to use the graph as an evidence source while also incorporating fraud policies, procedures and typologies.
The Agentic Investigation Loop
The core of FraudGraph is a LangGraph state machine.
An investigation can be triggered by:
- A model risk signal
- A customer report
- An analyst request
The state machine then moves through investigation, evidence gathering, assessment, evidence requests, reassessment, action selection and persistence.
The implemented pipeline includes:
- Trigger
- Create/open case
- Gather graph evidence
- Retrieve policy and prior-case context
- Detect fraud patterns
- Assess risk and uncertainty
- Determine whether additional evidence is required
- Request evidence when necessary
- Reassess
- Apply deterministic policy
- Route actions according to approval requirements
- Persist the case
- Generate SAR information when required
This mirrors the investigation flow specified by the challenge: trigger → investigate → gather evidence → assess uncertainty → gather more evidence if needed → take action → explain the decision.
Uncertainty Is a First-Class Concept
One of the most important design decisions was not forcing every case into an immediate yes/no decision.
A fraud investigation can be uncertain.
For example:
High risk score
+
New device
+
Suspicious transaction pattern
-
No supporting historical evidence
↓
Request additional evidence
The system can request:
- Customer validation
- Step-up authentication
- Additional analyst information
After the evidence is received, the case is reassessed.
The system records both the initial and final assessment and captures what changed between them.
This creates a more realistic investigation loop than simply asking an LLM:
"Is this fraud?"
Deterministic Policy Enforcement
We deliberately separated reasoning from authorization.
The agent can recommend an action, but it cannot simply bypass the bank's policy.
FraudGraph implements deterministic R1–R10 policy rules covering things such as:
- Verification before blocking
- Customer confirmation or denial
- Card testing
- Shared-origin activity
- Disputed recurring charges
- Escalation thresholds
- Card-block limits
The policy engine then routes actions through:
AUTO
L1 approval
L2 approval
Auto-approved actions can be executed by the mock executor.
L1 and L2 actions remain pending human approval.
This means the agent can reason about what should happen without being given unrestricted authority to execute sensitive actions.
Case Memory
Fraud investigations should not exist in isolation.
A previously investigated card, device, customer or fraud pattern can provide valuable context for a new investigation.
FraudGraph therefore persists investigation records and outcomes back into the graph store.
The system can retrieve related historical cases and use them as part of the evidence bundle.
This turns the graph into more than a transaction database.
It becomes an investigation memory.
SAR Generation
When policy requires a suspicious activity report, FraudGraph generates a structured SAR representation.
The implementation validates:
- Subjects
- Activity dates
- Exposure amount
- Narrative structure
- Required entities
- Agreement between the action and SAR state
The SAR generation was also deliberately separated from free-form LLM output so that important fields remain structured and consistent.
One of the Hardest Problems: False Graph Connections
One of our most interesting debugging discoveries came from the graph itself.
A graph can be extremely powerful — but a bad relationship can be worse than no relationship.
Initially, common email domains such as:
gmail.com
hotmail.com
yahoo.com
anonymous.com
could create huge shared-origin clusters.
That meant unrelated cards could appear connected simply because they used the same generic email provider.
In one case, the problem could connect thousands of cards through a generic domain.
We fixed this by:
- Excluding common email domains from shared-origin detection.
- Applying cluster-size limits.
- Keeping smaller, meaningful clusters as potential shared-origin evidence.
The final constraints limit email/region clusters to small groups and device clusters to a larger but bounded size.
This was a valuable lesson:
A graph does not automatically produce meaningful relationships. The semantics of an edge matter as much as the edge itself.
Another Real-World Problem: Device Identity
We also found a subtle device identity problem.
Device profiles were constructed from:
device_info | os | browser | screen
but inconsistent whitespace could produce different identifiers for what was logically the same device profile.
For example:
Windows | | edge 16.0 |
and:
Windows | | edge 16.0 |
could differ at the raw-string level because of trailing whitespace.
That matters enormously in a graph.
One character can turn:
Device A
into:
Device B
We introduced canonical device-profile normalization and added regression tests covering missing components and extra whitespace.
This ensured that ingestion, storage, lookup and export all use the same canonical identifier.
Explainability
A fraud investigation is not complete when the system produces:
fraud = true
An analyst needs to know why.
FraudGraph therefore records evidence references and investigation findings so that the final case can explain:
- Which transactions were relevant
- Which entities were connected
- Which graph relationships mattered
- Which fraud pattern was detected
- What uncertainty remained
- What additional evidence was requested
- Why an action was recommended
- Whether approval was required
- What changed after new evidence
This follows the challenge's requirement that the agent explain the evidence, uncertainty, decisions and actions behind its recommendations.
Benchmarking the Complete System
We did not want to validate the system only through individual examples.
The repository includes a full benchmark runner and strict case validator.
The final verification included:
pytest -q
with:
49 passed
The complete 20-case benchmark was also executed:
python -m app.run_benchmark
and produced:
20/20 benchmark cases
The generated case files were then passed through the strict validator with:
Total validation errors: 0
The validation covers things such as known entity IDs, verdict constraints, SAR consistency, deterministic action routing and evidence-request requirements.
The repository therefore contains the complete benchmark output:
cases/
├── HHG-001.json
├── HHG-002.json
├── ...
├── HHG-020.json
└── benchmark_report.json
What We Learned
1. Graphs are about semantics, not just connections
Our shared-email-domain bug was probably the clearest example.
A technically valid edge can still represent a meaningless relationship.
Fraud graphs need carefully designed relationship semantics.
2. Agents should not own the entire decision system
LLMs are useful for:
- Reasoning
- Tool selection
- Evidence synthesis
- Explanations
- Handling investigation flow
But deterministic systems are better suited for:
- Policy enforcement
- Approval requirements
- Schema validation
- Action authorization
- Safety constraints
Keeping those responsibilities separate made the system considerably easier to reason about.
3. Uncertainty makes the agent more useful
A real investigation often needs another piece of evidence.
Instead of forcing an immediate verdict, the system can ask:
"What is the most useful evidence to obtain next?"
That changes the agent from a classifier into an investigator.
4. Data normalization is part of graph engineering
Device identifiers, email identities, regions and other graph keys need canonicalization.
A tiny formatting inconsistency can silently fragment a graph and change the investigation result.
5. Automated validation matters
With 20 benchmark cases and structured answer requirements, manual inspection is not enough.
The benchmark runner and strict validator gave us a repeatable way to verify the complete system after changes.
What We Would Improve With More Time
There are several areas we would continue developing.
Better learned fraud scoring
The current assessment layer combines deterministic pattern detection, evidence groups and heuristic probability calculations.
A future version could incorporate a trained graph-aware fraud model while retaining the deterministic policy layer.
More sophisticated graph algorithms
There is considerable room for additional graph analytics:
- Community detection
- Graph embeddings
- Temporal motifs
- Entity-resolution models
- Fraud-ring discovery
- Anomaly propagation
Better analyst experience
The current Streamlit interface demonstrates the investigation workflow, but a production system could provide a richer case-management experience with:
- Interactive graph visualization
- Evidence timelines
- Analyst annotations
- Approval queues
- Investigation replay
- Side-by-side before/after assessments
More historical learning
The case-memory layer can eventually become a stronger feedback loop where confirmed investigation outcomes continuously improve pattern detection and retrieval.
Final Architecture
The resulting system can be summarized as:
┌───────────────────┐
│ Fraud Signal │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ LangGraph │
│ Investigation │
│ State Machine │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ GraphRAG │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ TigerGraph / │
│ Local Graph Store │
└─────────┬─────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Transactions Devices Case Memory
│ │ │
└─────────────┼─────────────┘
▼
┌───────────────────┐
│ Pattern Detection │
│ + Assessment │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Evidence Request │
│ / Reassessment │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Policy Engine │
│ R1–R10 │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Approval Routing │
│ AUTO / L1 / L2 │
└─────────┬─────────┘
│
▼
┌─────────────────────────┐
│ Case / SAR / Audit / UI │
└─────────────────────────┘
The key architectural principle is simple:
The agent investigates. The graph provides relationships. GraphRAG provides context. Deterministic policy controls actions. Humans retain authority where required.
Closing
Building FraudGraph changed how we think about agentic fraud investigation.
The interesting part was not making an LLM say "fraud" or "not fraud."
The interesting part was building the machinery around that decision:
finding the right evidence, understanding relationships, recognizing uncertainty, deciding what evidence to request next, applying policy, respecting approval boundaries, remembering previous investigations, and producing a defensible case record.
TigerGraph was particularly valuable because fraud is fundamentally relational. Once transactions, cards, devices, customers, regions and historical investigations become connected entities, investigation becomes a graph traversal problem as much as a classification problem.
The final system combines that graph foundation with an agentic investigation loop and deterministic controls, resulting in a system that can move from an initial fraud signal to an evidence-backed investigation and an actionable, policy-aware recommendation.
For us, the biggest lesson was:
Don't build an agent that merely answers questions about fraud. Build an agent that can investigate.
Top comments (0)