DEV Community: Pritha Pal

Building an Agentic Fraud Investigation System with TigerGraph and 11 AI Agents

Pritha Pal — Fri, 25 Sep 2026 08:07:12 +0000

TigerGraph Hacker House Goa — Agentic Fraud Investigation Challenge

Project: Agentic Fraud Investigation System
Core Technology: TigerGraph + GraphRAG + Multi-Agent AI
LLM Runtime: Ollama + Llama 3
Graph Platform: TigerGraph Savanna
Frontend: React + Tailwind CSS
Backend: Python
Repository: GitHub Repository

Quick Summary: What We Built

Fraud investigation is rarely about looking at a single transaction.

A suspicious transaction may be connected to the same customer, card, device, email domain, billing region, or previously investigated fraud case. The real challenge is finding those relationships and turning them into actionable evidence.

For the TigerGraph Hacker House Goa challenge, we built an Agentic Fraud Investigation System that combines:

TigerGraph for relationship-based fraud investigation.
GraphRAG for retrieving evidence from connected entities and graph relationships.
11 specialized AI agents for different investigation tasks.
Llama 3 through Ollama for local LLM reasoning.
TigerGraph MCP integration for allowing agents to interact with graph data.
Human-in-the-loop approval for important investigation actions.
React + Tailwind CSS for an analyst-focused investigation workspace.

The goal was simple:

Instead of asking an AI model to guess whether a transaction is fraudulent, give it the tools to investigate the evidence behind the transaction.

Why Fraud Investigation Needs Graphs

Consider a transaction:

Transaction
ID: TXN-10042
Amount: $420
Risk Score: 0.62
Channel: Online

Looking at this transaction alone doesn't tell us much.

But imagine that the same transaction is connected to:

Customer
   |
   +---- Card
   |
   +---- Device
   |
   +---- Email Domain
   |
   +---- Billing Region
   |
   +---- Previous Transaction
   |
   +---- Previous Fraud Case

Now the investigation becomes much more interesting.

The same device might have been used by multiple customers.

The same card might be connected to unusual transactions.

The customer might share infrastructure with previously investigated accounts.

A previous closed fraud case might reveal an important pattern.

This is where a graph database becomes extremely useful.

The Problem We Wanted to Solve

Traditional fraud investigation often requires analysts to jump between multiple systems.

A simplified investigation may look like:

Suspicious Transaction
        ↓
Check Customer
        ↓
Check Card
        ↓
Check Device
        ↓
Check Previous Transactions
        ↓
Check Related Customers
        ↓
Check Previous Fraud Cases
        ↓
Evaluate Fraud Pattern
        ↓
Recommend Action

The problem is that these relationships become increasingly difficult to manage as the investigation grows.

A language model can reason over information, but it does not automatically know which entities are connected in the underlying financial network.

That led us to a different architecture:

              User / Analyst
                    |
                    ↓
             Investigation UI
                    |
                    ↓
        Investigation Coordinator
                    |
       ┌────────────┼────────────┐
       ↓            ↓            ↓
   AI Agents    GraphRAG     Evidence
       |            |            |
       └────────────┼────────────┘
                    ↓
              TigerGraph
                    |
                    ↓
          Connected Fraud Evidence

The LLM is not treated as the source of truth.

TigerGraph provides the structured evidence, while the agents reason over that evidence.

Our Architecture

The system is divided into several major layers.

┌──────────────────────────────────────────────┐
│              React Analyst UI                │
│                                              │
│ Chat | Cases | Agents | Graph | Actions      │
└──────────────────────┬───────────────────────┘
                       ↓
┌──────────────────────────────────────────────┐
│        Investigation Application             │
│                                              │
│ Case Management | Agent Coordination         │
│ Evidence Handling | Action Recommendations   │
└──────────────────────┬───────────────────────┘
                       ↓
┌──────────────────────────────────────────────┐
│             11 AI Agents                     │
│                                              │
│ Investigation | Transaction | Graph | Risk   │
│ Evidence | History | Pattern | Action ...    │
└──────────────────────┬───────────────────────┘
                       ↓
┌──────────────────────────────────────────────┐
│             GraphRAG Layer                   │
│                                              │
│ Graph Retrieval + Evidence Grounding         │
└──────────────────────┬───────────────────────┘
                       ↓
┌──────────────────────────────────────────────┐
│              TigerGraph                      │
│                                              │
│ Customer | Card | Transaction | Device       │
│ Email | Region | Closed Cases                │
└──────────────────────────────────────────────┘

The Fraud Graph

At the center of the system is the FraudDetectionGraph.

We model important fraud entities as graph vertices and their relationships as edges.

A simplified representation looks like this:

Customer
   |
   ├── owns ──→ Card
   |
   ├── makes ─→ Transaction
   |
   ├── uses ──→ Device
   |
   ├── has ───→ EmailDomain
   |
   ├── belongs_to ─→ BillingRegion
   |
   └── related_to ─→ ClosedCase

This gives our agents something much more useful than a flat transaction record.

They can investigate the neighborhood around a transaction.

For example:

Customer
   ↓
Transaction
   ↓
Device
   ↓
Other Transactions
   ↓
Other Customers
   ↓
Previous Fraud Cases

This multi-hop relationship is one of the most important parts of the system.

Why TigerGraph?

TigerGraph is used as the relationship and evidence layer of the investigation.

Instead of retrieving isolated records, our agents can ask graph-oriented questions such as:

Which transactions are connected to this customer?

Which devices are shared across customers?

Which cards are associated with the same device?

Are there previous cases connected to this customer?

What entities are connected within multiple hops?

What evidence supports the current investigation?

This is particularly useful for fraud because fraud patterns are often relational.

For example:

Customer A
    ↓
Device X
    ↓
Customer B
    ↓
Device X
    ↓
Customer C

A flat transaction table makes this relationship harder to investigate.

A graph makes the relationship explicit.

The 11-Agent Investigation System

Instead of building one giant AI agent that tries to do everything, we divided the investigation into specialized responsibilities.

The architecture uses an Investigation Coordinator to manage the investigation and delegate work to specialized agents.

The agents work together around the same evidence graph.

The overall flow is:

                    Investigation Coordinator
                              |
          ┌───────────────────┼───────────────────┐
          ↓                   ↓                   ↓
 Transaction Analysis    Graph Analysis      Evidence Analysis
          |                   |                   |
          └───────────────────┼───────────────────┘
                              ↓
                     Fraud Pattern Analysis
                              |
                              ↓
                       Risk Assessment
                              |
                              ↓
                      Action Recommendation

The important design principle is that the agents have different responsibilities rather than repeatedly asking the same LLM to perform the entire investigation.

From Suspicious Transaction to Investigation

A typical investigation follows this pipeline:

Suspicious Transaction
        ↓
Create Investigation Case
        ↓
Collect Available Information
        ↓
Inspect Graph Relationships
        ↓
Analyze Transaction History
        ↓
Check Previous Cases
        ↓
Identify Fraud Patterns
        ↓
Evaluate Evidence
        ↓
Assess Risk
        ↓
Determine Whether More Evidence Is Needed
        ↓
Recommend Next Best Action
        ↓
Human Approval
        ↓
Save Investigation Result

This gives us a repeatable investigation lifecycle.

Risk Score Is Not the Verdict

One important design decision was to avoid treating the input risk_score as the final fraud decision.

For example:

risk_score = 0.72

does not automatically mean:

FRAUD = TRUE

Instead, the risk score becomes one piece of evidence.

The agents can investigate:

transaction behavior
customer history
device relationships
card relationships
geographic information
previous fraud cases
connected entities
graph patterns

The final investigation is therefore based on multiple pieces of evidence, rather than blindly trusting one numerical score.

GraphRAG: Connecting AI Reasoning With Evidence

This is where GraphRAG becomes important.

Traditional RAG commonly follows:

Question
   ↓
Vector Search
   ↓
Relevant Documents
   ↓
LLM
   ↓
Answer

Our architecture is different:

Investigation Question
        ↓
Graph Query
        ↓
Connected Entities
        ↓
Relevant Relationships
        ↓
Evidence Subgraph
        ↓
LLM Reasoning
        ↓
Grounded Investigation Result

Suppose an analyst asks:

"Why was this transaction considered suspicious?"

Instead of simply sending the transaction record to the LLM, the system can retrieve the relevant graph evidence.

The model can then reason over something like:

Transaction TXN-1001
        |
        ├── Customer C100
        |
        ├── Device D44
        |
        ├── Card C100-K2
        |
        └── Previous Case CASE-102
                         |
                         └── Similar Device Pattern

This creates a much stronger connection between the AI response and the underlying data.

TigerGraph MCP

We also integrated the system with the TigerGraph MCP ecosystem.

The purpose is to allow the agentic layer to interact with graph capabilities through structured tools rather than manually embedding every database operation into the LLM prompt.

Conceptually:

AI Agent
   ↓
Tool / MCP Interface
   ↓
TigerGraph
   ↓
Graph Query
   ↓
Structured Evidence
   ↓
AI Agent

This makes the graph a usable tool inside the investigation workflow.

Instead of the agent saying:

"I think this customer is connected to other suspicious accounts."

it can actually request graph evidence and reason from the returned relationships.

The Agentic Investigation Loop

Our investigation system follows an iterative process.

             ┌──────────────────────┐
             │  Start Investigation  │
             └──────────┬───────────┘
                        ↓
                Gather Evidence
                        ↓
                 Query Graph
                        ↓
               Analyze Results
                        ↓
              Is Evidence Enough?
                  /          \
                NO            YES
                ↓              ↓
        Request More Data   Assess Risk
                ↓              ↓
          Query Again      Recommend Action
                               ↓
                         Human Approval
                               ↓
                         Case Resolution

This is important because fraud investigations are rarely solved from a single database query.

The agent can progressively expand the investigation when additional evidence is required.

Evidence-Driven AI

One of the core principles of the system is:

The AI should reason from evidence, not invent evidence.

For example, instead of generating:

"This customer is definitely part of a fraud ring."

the system should be able to show:

Customer C123
    ↓
Device D991
    ↓
7 Transactions
    ↓
4 Different Cards
    ↓
2 Other Customers

The graph provides the underlying evidence.

The LLM then turns that evidence into an understandable investigation explanation.

This separation is important:

TigerGraph → Evidence
Agents     → Analysis
LLM        → Explanation
Analyst    → Decision

The Analyst Workstation

We wanted the application to feel less like a generic chatbot and more like an actual investigation workspace.

The interface contains multiple investigation views:

Case Management

Analysts can view active investigation cases and select a specific case for analysis.

AI Chat

The analyst can ask questions such as:

Why was this transaction flagged?

What devices are connected to this customer?

Are there related transactions?

Show me suspicious relationships.

What evidence supports this risk assessment?

Agent Activity

The interface exposes what the investigation system is doing instead of hiding the entire process behind one loading indicator.

Fraud Graph

The graph view provides a visual representation of relationships between:

Customers
Cards
Transactions
Devices
Accounts
Email Domains
Billing Regions
Closed Cases

Action Center

When the investigation produces a recommended action, the analyst can review the recommendation before approving or rejecting it.

Visualizing Fraud Relationships

Graph visualization is particularly useful when the investigation contains many relationships.

A simplified fraud ring might look like:

              Customer A
                  |
                Card A
                  |
               Txn 101
                  |
               Device X
             /    |    \
            /     |     \
        Txn 102 Txn 103 Txn 104
          |       |       |
       Card B   Card C   Card D
          |       |       |
      Customer B Customer C Customer D

The important insight is not necessarily one transaction.

It is the structure connecting the transactions.

The graph allows the analyst to visually explore those relationships.

Next Best Action

Finding suspicious activity is only part of the investigation.

The system also needs to answer:

What should happen next?

Depending on the evidence and policy context, possible actions can include:

ALLOW
DECLINE
MONITOR
VERIFY
STEP-UP VERIFICATION
BLOCK
CREATE CASE
GENERATE REPORT

The recommendation is then presented to the analyst.

For higher-impact actions, the system supports human approval rather than silently executing an irreversible decision.

Human-in-the-Loop Governance

We deliberately avoided designing the system as a completely uncontrolled autonomous system.

The workflow can include:

AI Investigation
      ↓
Evidence Collection
      ↓
Risk Assessment
      ↓
Action Recommendation
      ↓
┌──────────────────────┐
│ Analyst Approval     │
│                      │
│   APPROVE / REJECT   │
└──────────┬───────────┘
           ↓
      Action / Case

This creates a balance between:

AI-assisted investigation
automated evidence gathering
explainability
analyst control

The system is therefore designed as an investigation assistant and decision-support workspace, rather than a black-box replacement for the analyst.

The Technology Stack

The major technologies used in the project are:

Layer	Technology
Frontend	React + Tailwind CSS
Backend	Python
LLM	Llama 3
LLM Runtime	Ollama
Graph Database	TigerGraph Savanna
Graph Querying	GSQL
GraphRAG	Graph-based retrieval + evidence grounding
Agent Architecture	11 Specialized Agents
MCP	TigerGraph MCP
Visualization	Graph-based interactive UI
Dataset	IEEE-CIS Fraud Detection
Deployment	Web application

Working With the IEEE-CIS Fraud Dataset

For evaluation, we worked with the IEEE-CIS fraud dataset and the provided investigation case pack.

The important thing about the dataset is that it contains more than transaction amounts.

It provides information that can be connected across multiple dimensions.

Our graph representation allows these entities to participate in investigations instead of treating every record as an isolated row.

The investigation therefore becomes:

Transaction Data
      +
Customer Information
      +
Device Information
      +
Card Information
      +
Historical Cases
      +
Graph Relationships
      ↓
Investigation Evidence

What We Learned

1. Fraud Is a Relationship Problem

The most important lesson was that fraud investigation is often less about a single transaction and more about the relationships surrounding it.

A suspicious transaction becomes much more meaningful when we understand:

Who?
What?
Where?
When?
Which device?
Which card?
Which customer?
Which previous case?
Which connected entities?

Graphs naturally represent these relationships.

2. The LLM Should Not Be the Database

An LLM is excellent at:

reasoning
summarization
explanation
natural-language interaction
synthesizing evidence

But it should not be expected to remember or invent the underlying fraud network.

That belongs in the data layer.

Our architecture therefore separates responsibilities:

TigerGraph
   ↓
Structured Evidence

AI Agents
   ↓
Investigation

LLM
   ↓
Reasoning + Explanation

Analyst
   ↓
Final Approval / Decision

3. Multi-Agent Systems Need Clear Responsibilities

A common mistake in agentic applications is creating multiple agents without giving them meaningful boundaries.

Our approach was to divide investigation tasks into specialized responsibilities.

This makes the overall investigation easier to reason about:

One Large Agent
       ↓
"Do Everything"

versus

Investigation Coordinator
       ↓
Specialized Agents
       ↓
Focused Tasks
       ↓
Combined Investigation

The second architecture gives us clearer separation between different investigation activities.

4. GraphRAG Is Different From Traditional RAG

Vector retrieval answers:

"What text looks similar to my question?"

Graph retrieval can answer:

"What entities and relationships are connected to the entity I'm investigating?"

For fraud investigation, both approaches can be useful, but relationship-heavy questions naturally benefit from graph-based retrieval.

What We Would Improve Next

There are several areas we would like to take further.

1. Advanced Graph Algorithms

We can extend the investigation engine with graph algorithms for:

community detection
connected components
centrality
similarity
anomaly detection
fraud-ring discovery

This would allow the system to combine agentic reasoning with deeper graph analytics.

2. Better Agent Evaluation

Instead of only evaluating the final answer, we want to evaluate:

Agent Selection
        ↓
Tool Selection
        ↓
Evidence Retrieval
        ↓
Reasoning
        ↓
Final Recommendation

This would help identify exactly where an investigation succeeds or fails.

3. Stronger Evidence Tracing

A future version could make every statement in an AI response directly traceable to:

Graph Vertex
        +
Graph Edge
        +
Query
        +
Evidence Timestamp

This would make investigations easier to audit.

4. Real-Time Fraud Streaming

Another direction is connecting real-time transaction streams to the graph:

Transaction Stream
        ↓
Fraud Detection
        ↓
TigerGraph
        ↓
Investigation Trigger
        ↓
11-Agent Investigation
        ↓
Analyst

This would move the system closer to real-time fraud investigation.

Final Thoughts

Building this system changed how we think about agentic AI.

The most important part of an AI investigation system is not simply choosing a larger language model.

It is building the right environment around the model.

For fraud investigation, that environment includes:

Graph Data
    +
GraphRAG
    +
Specialized Agents
    +
LLM Reasoning
    +
Evidence
    +
Human Oversight

TigerGraph provides the relationship layer.

The 11 agents divide the investigation into specialized tasks.

GraphRAG connects those agents to structured evidence.

Llama 3 provides the reasoning and natural-language interface.

And the analyst remains in control of important decisions.

The result is a system designed to move from:

"This transaction looks suspicious."

to:

"Here is the connected evidence, here is the reasoning, here is the recommended next action, and here is the evidence behind it."

That is the direction we believe agentic AI can take fraud investigation: from isolated transaction analysis to connected, evidence-driven investigation.

Project Links

Resource	Link
GitHub Repository	Agentic Fraud Investigation System
Technology	TigerGraph + GraphRAG + 11 AI Agents
LLM	Llama 3 + Ollama
Graph Platform	TigerGraph Savanna
Frontend	React + Tailwind CSS

Built For TigerGraph Hacker House Goa

This project was developed as part of the TigerGraph Hacker House Goa Agentic Fraud Investigation Challenge.

The project explores how graph databases, GraphRAG, multi-agent systems, and human-in-the-loop workflows can work together to build more explainable fraud investigation systems.

Building an Agentic Fraud Investigation System with TigerGraph and 11 AI Agents

Pritha Pal — Fri, 25 Sep 2026 07:32:38 +0000

TigerGraph Hacker House Goa — Agentic Fraud Investigation Challenge

Project: Agentic Fraud Investigation System
Core Technology: TigerGraph + GraphRAG + Multi-Agent AI
LLM Runtime: Ollama + Llama 3
Graph Platform: TigerGraph Savanna
Frontend: React + Tailwind CSS
Backend: Python
Repository: GitHub Repository

Quick Summary: What We Built

Fraud investigation is rarely about looking at a single transaction.

For the TigerGraph Hacker House Goa challenge, we built an Agentic Fraud Investigation System that combines:

TigerGraph for relationship-based fraud investigation.
GraphRAG for retrieving evidence from connected entities and graph relationships.
11 specialized AI agents for different investigation tasks.
Llama 3 through Ollama for local LLM reasoning.
TigerGraph MCP integration for allowing agents to interact with graph data.
Human-in-the-loop approval for important investigation actions.
React + Tailwind CSS for an analyst-focused investigation workspace.

The goal was simple:

Instead of asking an AI model to guess whether a transaction is fraudulent, give it the tools to investigate the evidence behind the transaction.

Why Fraud Investigation Needs Graphs

Consider a transaction:

Looking at this transaction alone doesn't tell us much.

But imagine that the same transaction is connected to:

Now the investigation becomes much more interesting.

The same device might have been used by multiple customers.

The same card might be connected to unusual transactions.

The customer might share infrastructure with previously investigated accounts.

A previous closed fraud case might reveal an important pattern.

This is where a graph database becomes extremely useful.

The Problem We Wanted to Solve

Traditional fraud investigation often requires analysts to jump between multiple systems.

A simplified investigation may look like:

The problem is that these relationships become increasingly difficult to manage as the investigation grows.

A language model can reason over information, but it does not automatically know which entities are connected in the underlying financial network.

That led us to a different architecture:

The LLM is not treated as the source of truth.

TigerGraph provides the structured evidence, while the agents reason over that evidence.

Our Architecture

The system is divided into several major layers.

The Fraud Graph

At the center of the system is the FraudDetectionGraph.

We model important fraud entities as graph vertices and their relationships as edges.

A simplified representation looks like this:

This gives our agents something much more useful than a flat transaction record.

They can investigate the neighborhood around a transaction.

For example:

This multi-hop relationship is one of the most important parts of the system.

Why TigerGraph?

TigerGraph is used as the relationship and evidence layer of the investigation.

Instead of retrieving isolated records, our agents can ask graph-oriented questions such as:

This is particularly useful for fraud because fraud patterns are often relational.

For example:

A flat transaction table makes this relationship harder to investigate.

A graph makes the relationship explicit.

The 11-Agent Investigation System

Instead of building one giant AI agent that tries to do everything, we divided the investigation into specialized responsibilities.

The architecture uses an Investigation Coordinator to manage the investigation and delegate work to specialized agents.

The agents work together around the same evidence graph.

The overall flow is:

The important design principle is that the agents have different responsibilities rather than repeatedly asking the same LLM to perform the entire investigation.

From Suspicious Transaction to Investigation

A typical investigation follows this pipeline:

This gives us a repeatable investigation lifecycle.

Risk Score Is Not the Verdict

One important design decision was to avoid treating the input risk_score as the final fraud decision.

For example:

does not automatically mean:

Instead, the risk score becomes one piece of evidence.

The agents can investigate:

transaction behavior
customer history
device relationships
card relationships
geographic information
previous fraud cases
connected entities
graph patterns

The final investigation is therefore based on multiple pieces of evidence, rather than blindly trusting one numerical score.

GraphRAG: Connecting AI Reasoning With Evidence

This is where GraphRAG becomes important.

Traditional RAG commonly follows:

Our architecture is different:

Suppose an analyst asks:

"Why was this transaction considered suspicious?"

Instead of simply sending the transaction record to the LLM, the system can retrieve the relevant graph evidence.

The model can then reason over something like:

This creates a much stronger connection between the AI response and the underlying data.

TigerGraph MCP

We also integrated the system with the TigerGraph MCP ecosystem.

The purpose is to allow the agentic layer to interact with graph capabilities through structured tools rather than manually embedding every database operation into the LLM prompt.

Conceptually:

This makes the graph a usable tool inside the investigation workflow.

Instead of the agent saying:

"I think this customer is connected to other suspicious accounts."

it can actually request graph evidence and reason from the returned relationships.

The Agentic Investigation Loop

Our investigation system follows an iterative process.

This is important because fraud investigations are rarely solved from a single database query.

The agent can progressively expand the investigation when additional evidence is required.

Evidence-Driven AI

One of the core principles of the system is:

The AI should reason from evidence, not invent evidence.

For example, instead of generating:

the system should be able to show:

The graph provides the underlying evidence.

The LLM then turns that evidence into an understandable investigation explanation.

This separation is important:

The Analyst Workstation

We wanted the application to feel less like a generic chatbot and more like an actual investigation workspace.

The interface contains multiple investigation views:

Case Management

Analysts can view active investigation cases and select a specific case for analysis.

AI Chat

The analyst can ask questions such as:

Agent Activity

The interface exposes what the investigation system is doing instead of hiding the entire process behind one loading indicator.

Fraud Graph

The graph view provides a visual representation of relationships between:

Action Center

When the investigation produces a recommended action, the analyst can review the recommendation before approving or rejecting it.

Visualizing Fraud Relationships

Graph visualization is particularly useful when the investigation contains many relationships.

A simplified fraud ring might look like:

The important insight is not necessarily one transaction.

It is the structure connecting the transactions.

The graph allows the analyst to visually explore those relationships.

Next Best Action

Finding suspicious activity is only part of the investigation.

The system also needs to answer:

What should happen next?

Depending on the evidence and policy context, possible actions can include:

The recommendation is then presented to the analyst.

For higher-impact actions, the system supports human approval rather than silently executing an irreversible decision.

Human-in-the-Loop Governance

We deliberately avoided designing the system as a completely uncontrolled autonomous system.

The workflow can include:

This creates a balance between:

AI-assisted investigation
automated evidence gathering
explainability
analyst control

The system is therefore designed as an investigation assistant and decision-support workspace, rather than a black-box replacement for the analyst.

The Technology Stack

The major technologies used in the project are:

Layer	Technology
Frontend	React + Tailwind CSS
Backend	Python
LLM	Llama 3
LLM Runtime	Ollama
Graph Database	TigerGraph Savanna
Graph Querying	GSQL
GraphRAG	Graph-based retrieval + evidence grounding
Agent Architecture	11 Specialized Agents
MCP	TigerGraph MCP
Visualization	Graph-based interactive UI
Dataset	IEEE-CIS Fraud Detection
Deployment	Web application

Working With the IEEE-CIS Fraud Dataset

For evaluation, we worked with the IEEE-CIS fraud dataset and the provided investigation case pack.

The important thing about the dataset is that it contains more than transaction amounts.

It provides information that can be connected across multiple dimensions.

Our graph representation allows these entities to participate in investigations instead of treating every record as an isolated row.

The investigation therefore becomes:

What We Learned

1. Fraud Is a Relationship Problem

The most important lesson was that fraud investigation is often less about a single transaction and more about the relationships surrounding it.

A suspicious transaction becomes much more meaningful when we understand:

Graphs naturally represent these relationships.

2. The LLM Should Not Be the Database

An LLM is excellent at:

reasoning
summarization
explanation
natural-language interaction
synthesizing evidence

But it should not be expected to remember or invent the underlying fraud network.

That belongs in the data layer.

Our architecture therefore separates responsibilities:

3. Multi-Agent Systems Need Clear Responsibilities

A common mistake in agentic applications is creating multiple agents without giving them meaningful boundaries.

Our approach was to divide investigation tasks into specialized responsibilities.

This makes the overall investigation easier to reason about:

The second architecture gives us clearer separation between different investigation activities.

4. GraphRAG Is Different From Traditional RAG

Vector retrieval answers:

"What text looks similar to my question?"

Graph retrieval can answer:

"What entities and relationships are connected to the entity I'm investigating?"

For fraud investigation, both approaches can be useful, but relationship-heavy questions naturally benefit from graph-based retrieval.

What We Would Improve Next

There are several areas we would like to take further.

1. Advanced Graph Algorithms

We can extend the investigation engine with graph algorithms for:

community detection
connected components
centrality
similarity
anomaly detection
fraud-ring discovery

This would allow the system to combine agentic reasoning with deeper graph analytics.

2. Better Agent Evaluation

Instead of only evaluating the final answer, we want to evaluate:

This would help identify exactly where an investigation succeeds or fails.

3. Stronger Evidence Tracing

A future version could make every statement in an AI response directly traceable to:

This would make investigations easier to audit.

4. Real-Time Fraud Streaming

Another direction is connecting real-time transaction streams to the graph:

This would move the system closer to real-time fraud investigation.

Final Thoughts

Building this system changed how we think about agentic AI.

The most important part of an AI investigation system is not simply choosing a larger language model.

It is building the right environment around the model.

For fraud investigation, that environment includes:

TigerGraph provides the relationship layer.

The 11 agents divide the investigation into specialized tasks.

GraphRAG connects those agents to structured evidence.

Llama 3 provides the reasoning and natural-language interface.

And the analyst remains in control of important decisions.

The result is a system designed to move from:

"This transaction looks suspicious."

to:

"Here is the connected evidence, here is the reasoning, here is the recommended next action, and here is the evidence behind it."

That is the direction we believe agentic AI can take fraud investigation: from isolated transaction analysis to connected, evidence-driven investigation.

Project Links

Resource	Link
GitHub Repository	Agentic Fraud Investigation System
Technology	TigerGraph + GraphRAG + 11 AI Agents
LLM	Llama 3 + Ollama
Graph Platform	TigerGraph Savanna
Frontend	React + Tailwind CSS

Built For TigerGraph Hacker House Goa

This project was developed as part of the TigerGraph Hacker House Goa Agentic Fraud Investigation Challenge.

The project explores how graph databases, GraphRAG, multi-agent systems, and human-in-the-loop workflows can work together to build more explainable fraud investigation systems.