Hacker House Goa 2026 — TigerGraph Agentic Fraud Investigation Challenge
What happens after a fraud detection model flags a transaction?
Usually, not much automation.
A model might produce something like:
Transaction: 3514030
Risk Score: 0.61
But a risk score isn't a fraud verdict.
An analyst still needs to investigate the transaction, understand the customer's history, identify connected cards and devices, look for similar historical cases, evaluate applicable policies, determine whether additional evidence is required, and finally decide what action should be taken.
That investigation can involve dozens of queries across multiple systems and can take significant analyst time.
We built FraudNet to explore a different approach:
What if a fraud risk score became the starting point for an autonomous investigation rather than the end of a machine-learning pipeline?
FraudNet combines TigerGraph, TigerGraph MCP, GraphRAG, LLM reasoning, deterministic policy enforcement, and case memory into an agentic fraud investigation workflow.
The result is a system that can investigate a suspicious transaction, gather multi-hop graph evidence, identify uncertainty, request additional evidence when necessary, enforce deterministic policies, and write completed investigations back into the graph as organizational memory.
1. The Problem: A Risk Score Isn't an Investigation
Traditional fraud systems are generally good at answering:
"How suspicious is this transaction?"
They are much less capable of answering:
"Why is this transaction suspicious, what is it connected to, what evidence supports that conclusion, what policies apply, and what should happen next?"
Consider a transaction with a moderately high risk score.
An analyst might need to investigate:
- Previous transactions from the card
- Customer travel history
- Other cards belonging to the customer
- Devices used by those cards
- IP addresses and device fingerprints
- Other transactions associated with the same device
- Historical fraud cases
- Known fraud typologies
- Internal bank policies
- Regulatory reporting requirements
- Aggregate exposure across connected entities
The interesting part is that these aren't isolated pieces of information.
They form a relationship graph.
For example:
Customer
│
└── OWNS
│
Card
│
MADE
│
Transaction
│
FROM_DEVICE
│
Device
│
FROM_DEVICE
│
Other Transaction
│
MADE
│
Other Card
A suspicious transaction may become significantly more meaningful when the graph reveals that its device is shared by dozens of unrelated payment cards.
This is where FraudNet starts.
2. What We Built
FraudNet is an autonomous fraud investigation workstation built around a graph-native architecture.
At a high level:
Case Trigger
(case_pack.csv)
│
▼
┌───────────────────────────────┐
│ Investigation Workflow │
│ 12-stage deterministic graph │
└──────────────┬────────────────┘
│
┌───────┼────────┐
│ │ │
▼ ▼ ▼
TigerGraph GraphRAG LLM
│ │ │
│ │ └── Evidence synthesis
│ │ Uncertainty assessment
│ │ Fraud probability
│ │
│ ├── Policies
│ ├── Typologies
│ └── Case Memory
│
└── Multi-hop evidence
│
▼
Evidence Request Loop
│
▼
Deterministic PolicyEngine
│
┌──────┴──────┐
▼ ▼
Final Action SAR Filing
│
▼
TigerGraph
Writeback
│
▼
Case Memory
The important architectural principle is the separation of responsibilities:
- TigerGraph provides relationship-grounded evidence.
- GraphRAG provides contextual knowledge.
- The LLM performs reasoning and synthesis.
- The PolicyEngine controls consequential actions.
This prevents the LLM from becoming the final authority.
3. Why a Graph?
Fraud is fundamentally relational.
Suppose we have:
Card A → Device X
Card B → Device X
Card C → Device X
...
Card AH → Device X
A transaction-level model might see each transaction independently.
A graph can immediately expose the relationship:
┌── Card A
│
├── Card B
│
├── Card C
│
Device X ────┼── ...
│
└── Card AH
That relationship can become a powerful investigation signal.
FraudNet uses TigerGraph to traverse relationships such as:
Customer
↓
Card
↓
Transaction
↓
Device
↓
Other Transactions
↓
Other Cards
This allows the investigation agent to reason about connected entities rather than isolated rows.
4. TigerGraph: The Investigation Evidence Layer
The FraudNet graph runs on a live TigerGraph Cloud instance.
The graph contains entities such as:
- Customers
- Cards
- Transactions
- Devices
- Historical cases
and their relationships.
Examples include:
Customer ──OWNS────────> Card
Card ──MADE────────────> Transaction
Transaction ──FROM_DEVICE──> Device
Card ──HAS_HISTORY─────> Transaction
This allows FraudNet to perform investigation-specific graph traversals.
Some of the primary graph operations include:
get_transaction_context
get_card_history
get_customer_history
get_connected_cards
get_device_neighbors
get_transaction_chain
get_similar_closed_cases
detect_card_testing
write_case
One particularly useful operation is:
get_device_neighbors
Instead of asking an LLM to inspect thousands of transaction records and infer relationships, TigerGraph can directly answer:
"What other cards and transactions are connected to this device?"
The graph does the relationship discovery.
The LLM then interprets the result.
That distinction is important.
5. TigerGraph MCP: Giving the Agent Controlled Graph Access
We didn't want the LLM generating arbitrary GSQL.
That would introduce unnecessary risks:
- Invalid queries
- Uncontrolled database access
- Large context responses
- Accidental mutations
- Credential exposure
- Difficult-to-audit behavior
Instead, FraudNet uses the official TigerGraph MCP package (tigergraph-mcp v1.0.3) as the interface between the reasoning layer and TigerGraph.
Conceptually:
LLM
│
│ MCP tool call
▼
TigerGraph MCP
│
▼
Typed investigation operation
│
▼
TigerGraph
The agent can request:
get_device_neighbors(device_id)
rather than generating arbitrary database queries.
This gives us three major benefits.
1. Controlled Access
The LLM only has access to explicitly exposed investigation capabilities.
2. Smaller Context
The MCP layer can return structured investigation results rather than dumping entire graph neighborhoods into the model context.
3. Better Security Boundaries
Credentials and bearer tokens remain isolated inside the adapter layer rather than becoming part of the reasoning context.
The LLM reasons about the result, not the database implementation.
6. GraphRAG: Connecting Graph Evidence With Institutional Knowledge
Graph evidence alone isn't enough.
An investigator also needs context:
- What does this fraud pattern mean?
- What policy applies?
- Has the organization seen similar cases?
- What action was taken previously?
FraudNet therefore uses a GraphRAG layer containing three major knowledge collections.
Policy Knowledge
Bank operating policies covering:
R1 – R10
These include approval thresholds, escalation requirements, and regulatory triggers.
Fraud Typologies
FraudNet includes documented patterns such as:
card_testing
card_not_present_fraud
card_not_present_new_device
out_of_region_use
account_takeover
It also supports guidance for undocumented abuse patterns.
Historical Case Memory
The system includes:
5,565 historical closed cases
from:
closed_cases_history.csv
Retrieved information is tagged with its provenance:
policy
typology
case_memory
This means the reasoning layer knows where its contextual information came from.
7. The 12-Stage Agentic Workflow
The core investigation logic lives in:
src/agent/workflow.py
src/agent/nodes.py
The workflow consists of 12 stages.
1. load_case
Loads the investigation trigger from case_pack.csv.
The trigger can originate from a risk score, analyst request, or customer report.
2. investigate_transaction
Retrieves transaction context, risk signals, and relevant transaction attributes.
3. investigate_relationships
Traverses customer history, card history, connected cards, and device relationships.
4. retrieve_prior_cases
Searches historical closed investigations for similar patterns.
5. assess_evidence
The LLM synthesizes the collected evidence into structured findings.
6. assess_uncertainty
The agent determines whether the current evidence is sufficient or whether ambiguity remains.
7. request_evidence
If uncertainty is unresolved, the agent generates an appropriate evidence request.
8. reassess_case
New evidence is incorporated and the investigation is reassessed.
9. apply_policy
The deterministic PolicyEngine evaluates the investigation against institutional rules.
10. prepare_case
The system prepares the final case package, including reporting and approval requirements.
11. write_case
The completed investigation is persisted back into TigerGraph.
12. finish
The system produces the final benchmark-compliant JSON output.
The result is not simply:
LLM → answer
Instead:
Trigger
↓
Graph Investigation
↓
Historical Context
↓
LLM Evidence Synthesis
↓
Uncertainty
↓
Additional Evidence (if needed)
↓
Policy Enforcement
↓
Case Writeback
↓
Final Output
8. The Important Part: Uncertainty
One of the design decisions we cared about most was avoiding premature conclusions.
A suspicious signal doesn't necessarily mean fraud.
Consider HHG-001.
The transaction had:
Risk Score: 0.61
Amount: $77.07
Transaction: 3514030
Card: C12382-K1
The transaction occurred in an unusual billing region.
At first glance, that looks suspicious.
But the graph revealed that the customer had a history of traveling.
Instead of immediately blocking the card, FraudNet recognized that the evidence was ambiguous.
The agent initiated:
customer_validation
The simulated customer response confirmed that the cardholder had authorized the transaction.
The case then went through the policy layer and resulted in:
CLOSE_NO_FRAUD
Exposure:
$0.00
SAR:
Rejected
The important behavior here wasn't simply the final verdict.
It was the decision to gather more evidence before acting.
9. When the Graph Changes Everything: HHG-014
Now consider a very different case.
HHG-014 involved:
Transaction: 3478561
Amount: $74.96
Card: C13487-K1
The investigation initially considered customer verification.
Then the graph traversal revealed something much more significant.
A single device profile:
SM-G935F Build/NRD90M | Android 7.0
was connected to:
34 distinct payment cards
The graph transformed the investigation.
Instead of:
Suspicious transaction
the evidence now looked like:
Device
│
┌──────────┼──────────┐
│ │ │
Card 1 Card 2 Card 3
│ │ │
... ... ...
│
Card 34
GraphRAG also retrieved historical syndicate cases:
CC-2985
CC-3035
CC-2649
CC-2971
The evidence supported a coordinated device-based attack.
The fraud probability was updated to:
0.95
The policy layer then enforced actions including:
CREATE_CASE
FILE_REPORT
ESCALATE_TO_ANALYST
MONITOR_CONNECTED_CARDS
and a SAR was generated covering the immediate exposure and connected entities.
Finally, the completed case was persisted back into TigerGraph.
This is exactly the kind of investigation where graph technology provides information that would be difficult to derive from an isolated transaction record.
10. LLM Reasoning vs. Deterministic Policy
This was one of the most important architectural choices in FraudNet.
LLMs are useful for:
- Synthesizing evidence
- Explaining relationships
- Identifying potential patterns
- Assessing uncertainty
- Producing human-readable reasoning
But they should not be trusted as the sole authority for deterministic institutional rules.
Therefore:
LLM Recommendation
│
▼
┌─────────────────────┐
│ PolicyEngine │
│ │
│ R1 → R10 │
│ Exposure thresholds │
│ Approval routing │
│ SAR requirements │
└──────────┬──────────┘
│
▼
Final Enforced Action
The PolicyEngine lives in:
src/policy/engine.py
It controls permitted actions such as:
BLOCK_CARD
BLOCK_ALL_CARDS
MONITOR_CONNECTED_CARDS
CREATE_CASE
FILE_REPORT
CLOSE_NO_FRAUD
It also determines approval routes:
AUTO
L1
L2
The system explicitly records:
Initial LLM recommendation
↓
Policy evaluation
↓
Final enforced decision
This separation makes the investigation trace significantly easier to audit.
11. SAR Generation
FraudNet also generates structured Suspicious Activity Report data when the applicable policy rules require it.
The generated report includes information such as:
- Filing justification
- Transaction sequence
- Relevant graph relationships
- Subject identifiers
- Connected cards
- Device information
- Aggregate exposure
The important architectural distinction is that the LLM doesn't independently decide:
"This should be reported."
Instead:
Evidence
↓
LLM recommendation
↓
Deterministic PolicyEngine
↓
SAR requirement
↓
Structured SAR output
This keeps regulatory actions tied to explicit policy logic.
12. Grounding the Agent
Agentic systems introduce another major problem:
How do we know the model isn't inventing entities?
FraudNet addresses this with two validation layers.
Schema Validation
Implemented through:
evaluation/validate_schema.py
Pydantic schemas enforce structural requirements and cross-field invariants.
For example, outputs cannot contain contradictory combinations of actions, verdicts, SAR states, and approval requirements.
Entity Integrity
Implemented through:
evaluation/check_integrity.py
The system validates entity references against an in-memory registry containing:
631,219 ground-truth entities
This includes:
Transaction IDs
Card IDs
Customer IDs
Device profiles
Therefore, if the LLM produces an entity that doesn't exist in the underlying dataset, the result can be rejected.
The goal is simple:
Reason freely, but never invent the underlying facts.
13. The Investigation Control Room
We also built a lightweight Flask-based Investigation Control Room under:
ui/
The interface operates in replay mode over canonical benchmark outputs.
It includes several views.
Interactive Evidence Graph
A D3.js force-directed visualization shows:
Customers
Cards
Transactions
Devices
Cases
and their relationships.
Selecting an entity highlights the supporting evidence.
Investigation Trace
The UI reconstructs the 12-stage investigation timeline from stored evidence references.
PolicyEngine Gate
The UI visualizes:
LLM Recommendation
↓
PolicyEngine Evaluation
↓
Final Enforced Action
Uncertainty View
The interface displays:
- Fraud probability
- Uncertainty
- Initial recommendation
- Final decision
Case Memory
Relevant historical investigations retrieved by GraphRAG are displayed as precedents.
Benchmark Dashboard
The /benchmark route provides a 20-case benchmark matrix and aggregate operational statistics.
A key transparency feature is that replay-derived fields and simulated customer responses are explicitly labeled in the UI rather than presented as live external events.
14. Benchmark Results
FraudNet was benchmarked across all 20 cases in case_pack.csv using live TigerGraph Cloud and Groq's openai/gpt-oss-20b endpoint.
| Metric | Result |
|---|---|
| Total cases executed | 20 / 20 |
| Output schema validation | 20 / 20 passed |
| Entity integrity validation | 20 / 20 passed |
| Ground-truth entities checked | 631,219 |
| Fraud verdicts | 18 |
| Legitimate verdicts | 2 |
| Mandatory SARs filed | 10 |
| Evidence-request loops | 16 |
| Average latency | 30.0 seconds |
| Minimum latency | 19.1 seconds |
| Maximum latency | 95.0 seconds |
| Average tool calls/case | 5.6 |
| Average token usage/case | 676 |
| Total detected fraud exposure | $3,515.23 |
We did not report classification accuracy or F1 because official benchmark ground truth was not published.
That distinction matters.
A system can produce internally valid and reproducible outputs without having a verified classification ground truth.
15. Resilience and Failure Handling
An autonomous investigation system also has to handle things going wrong.
FraudNet includes several resilience mechanisms.
TigerGraph Fallback
If TigerGraph Cloud experiences a transient connection failure, the GraphAdapter can fall back to an in-memory graph mirror loaded from the raw CSV datasets.
Configuration:
TG_BACKEND=auto
This allows the investigation pipeline to continue without depending exclusively on a live database connection.
JSON Recovery
LLM responses aren't always perfectly formatted.
FraudNet includes recovery logic for cases such as:
{ ... }
wrapped in Markdown fences or truncated JSON responses.
The recovery layer can strip Markdown fences and repair certain incomplete structures before schema validation.
Credential Scrubbing
API keys, database credentials, and bearer tokens are scrubbed before timeline states are logged or persisted.
Idempotent Writes
Before writing a case back to TigerGraph, existing vertex IDs are checked to prevent duplicate case nodes.
16. What We Learned
Graphs Let the LLM Focus on Reasoning
One of the strongest lessons from building FraudNet was that the LLM should not be responsible for discovering every relationship.
Asking an LLM to inspect large collections of raw transaction data and discover a device syndicate is inefficient and prone to errors.
Instead:
TigerGraph
↓
Find connected entities
↓
Structured evidence
↓
LLM
↓
Reason about evidence
For HHG-014, the graph could directly expose the connection between one device and 34 cards.
The LLM didn't need to calculate that relationship itself.
It needed to understand what that relationship meant.
Deterministic Rules Belong Outside the LLM
Another major lesson was the importance of separating:
Reasoning
from:
Enforcement
The LLM can say:
"The evidence strongly suggests coordinated fraud."
The PolicyEngine determines what actions are actually permitted.
This architecture makes the system easier to reason about, test, audit, and modify.
17. Current Limitations
FraudNet is an engineering prototype and benchmark system, not a production financial deployment.
There are several limitations.
Customer Verification Is Simulated
The offline benchmark uses simulated customer responses based on the underlying case context.
A production implementation would connect the evidence-request layer to real systems such as:
SMS
Push notifications
Customer portals
Banking applications
Webhook listeners
Replay UI Instead of Live Streaming
The current Control Room replays completed investigation traces.
A production version could use:
Server-Sent Events
WebSockets
to stream investigation events as they happen.
Benchmark Ground Truth
The benchmark does not provide official classification ground truth, so we report operational and validation metrics rather than claiming accuracy.
18. Future Roadmap
There are several directions we would explore next.
1. Live Multi-Hop Graph Expansion
Instead of only displaying the final graph, allow analysts to interactively expand:
Transaction
↓
Device
↓
Connected Cards
↓
Connected Transactions
↓
Historical Cases
during an active investigation.
2. Analyst Override Analysis
Track where analysts disagree with automated recommendations and use those patterns to propose candidate policy refinements for human review.
The important distinction would be:
Agent proposes
Compliance approves
PolicyEngine enforces
rather than allowing the system to autonomously rewrite compliance rules.
3. Proactive Graph Analytics
Run algorithms such as:
PageRank
Louvain community detection
Connected-component analysis
to identify emerging device or account clusters before individual transactions are flagged.
This could move the architecture from:
Reactive Investigation
toward:
Proactive Fraud Intelligence
19. The Architecture in One Picture
The overall FraudNet design can be summarized as:
┌────────────────────┐
│ Fraud Trigger │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Agentic Workflow │
│ 12 Stages │
└─────────┬──────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ TigerGraph │ │ GraphRAG │ │ LLM │
│ │ │ │ │ │
│ Relations │ │ Policies │ │ Reasoning │
│ Topology │ │ Typologies │ │ Synthesis │
│ History │ │ Case Memory│ │ Uncertainty│
└─────┬──────┘ └─────┬──────┘ └─────┬──────┘
│ │ │
└──────────────────┼──────────────────┘
▼
┌────────────────────┐
│ Evidence Evaluation│
└─────────┬──────────┘
│
Uncertainty?
/ \
Yes No
│ │
▼ │
Evidence Request │
│ │
└──────┬───────┘
▼
┌────────────────────┐
│ PolicyEngine │
│ R1 → R10 │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Final Enforcement │
│ + SAR + Approval │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ TigerGraph Writeback│
│ Case Memory │
└────────────────────┘
The key idea is that each component has a clearly defined responsibility.
20. Conclusion
FraudNet started with a simple question:
Can an AI agent investigate fraud rather than simply score it?
Our approach was to combine four capabilities:
Graph Intelligence
+
Retrieval-Augmented Knowledge
+
LLM Reasoning
+
Deterministic Enforcement
TigerGraph provides the relationship structure.
TigerGraph MCP gives the agent controlled access to that structure.
GraphRAG provides policy, typology, and historical case context.
The LLM synthesizes evidence and handles uncertainty.
The PolicyEngine ensures that consequential actions remain deterministic.
And the final investigation is written back into the graph as organizational memory.
The result is not an LLM sitting on top of a database.
It is an investigation architecture where:
The graph discovers the evidence, the agent reasons over it, the policy engine controls the action, and the investigation becomes memory for the next case.
Links
GitHub Repository:
https://github.com/aaryamanmishra/tigergraph-agentic-fraud-investigation
Demo:
https://youtu.be/79AmYJ6bY3o
Built for:
Hacker House Goa 2026 — TigerGraph Agentic Fraud Investigation Challenge
Tech Stack
TigerGraph Cloud
TigerGraph MCP v1.0.3
GraphRAG
Groq
openai/gpt-oss-20b
Python
Pydantic
Flask
D3.js
GSQL
TigerGraph #GraphRAG #MCP #AgenticAI #FraudDetection #GenerativeAI #LLM #Python #AIEngineering #GraphDatabase #HackerHouseGoa
Top comments (0)