FraudNet: Building an Autonomous, Graph-Native Fraud Investigation Agent with TigerGraph, MCP, and GraphRAG

Aman Ayubkhan Pathan — Thu, 24 Sep 2026 17:18:03 +0000

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

DEV Community: Aman Ayubkhan Pathan

FraudNet: Building an Autonomous, Graph-Native Fraud Investigation Agent with TigerGraph, MCP, and GraphRAG

1. The Problem: A Risk Score Isn't an Investigation

2. What We Built

3. Why a Graph?

4. TigerGraph: The Investigation Evidence Layer

5. TigerGraph MCP: Giving the Agent Controlled Graph Access

1. Controlled Access

2. Smaller Context

3. Better Security Boundaries

6. GraphRAG: Connecting Graph Evidence With Institutional Knowledge

Policy Knowledge

Fraud Typologies

Historical Case Memory

7. The 12-Stage Agentic Workflow

1. load_case

2. investigate_transaction

3. investigate_relationships

4. retrieve_prior_cases

5. assess_evidence

6. assess_uncertainty

7. request_evidence

8. reassess_case

9. apply_policy

10. prepare_case

11. write_case

12. finish

8. The Important Part: Uncertainty

9. When the Graph Changes Everything: HHG-014

10. LLM Reasoning vs. Deterministic Policy

11. SAR Generation

12. Grounding the Agent

Schema Validation

Entity Integrity

13. The Investigation Control Room

Interactive Evidence Graph

Investigation Trace

PolicyEngine Gate

Uncertainty View

Case Memory

Benchmark Dashboard

14. Benchmark Results

15. Resilience and Failure Handling

TigerGraph Fallback

JSON Recovery

Credential Scrubbing

Idempotent Writes

16. What We Learned

Graphs Let the LLM Focus on Reasoning

Deterministic Rules Belong Outside the LLM

17. Current Limitations

Customer Verification Is Simulated

Replay UI Instead of Live Streaming

Benchmark Ground Truth

18. Future Roadmap

1. Live Multi-Hop Graph Expansion

2. Analyst Override Analysis

3. Proactive Graph Analytics

19. The Architecture in One Picture

20. Conclusion

Links

Tech Stack

TigerGraph #GraphRAG #MCP #AgenticAI #FraudDetection #GenerativeAI #LLM #Python #AIEngineering #GraphDatabase #HackerHouseGoa

1. `load_case`

2. `investigate_transaction`

3. `investigate_relationships`

4. `retrieve_prior_cases`

5. `assess_evidence`

6. `assess_uncertainty`

7. `request_evidence`

8. `reassess_case`

9. `apply_policy`

10. `prepare_case`

11. `write_case`

12. `finish`