Autonomous Fraud Investigation & Next-Best Action with TigerGraph and GraphRAG

chitresh gurjar — Thu, 24 Sep 2026 11:31:00 +0000

A deep dive into building an AI-powered agentic financial crime investigator for HackerHouse Goa 2026.

What if a fraud investigation system could do more than flag suspicious transactions — and actually investigate the surrounding network, gather evidence, learn from previous cases, and recommend the next best action?

That was the problem we set out to solve at HackerHouse Goa 2026.

We built an Agentic Fraud Investigation System using TigerGraph and GraphRAG that turns uncertain fraud alerts into contextual, explainable, and policy-driven actions.

The Problem: Fraud Is a Network Problem

Traditional fraud detection often starts with an individual transaction:

Transaction → Risk Score → Alert → Analyst Review

The problem is that fraud rarely exists in isolation.

A transaction that looks suspicious on its own might actually be legitimate. At the same time, several individually normal transactions can become highly suspicious when viewed as part of a larger network.

For example:

Customer A
   |
  Card A
   |
Transaction 1 ─── Device X
                    |
             ┌──────┴──────┐
             |             |
          Card B        Card C
             |             |
       Transaction 2   Transaction 3

A single transaction may not tell us much.

But a shared device across multiple cards and customers can reveal a completely different picture.

This is where graph technology becomes valuable.

What We Built

We built the TigerGraph Agentic Fraud Investigation System, an autonomous investigation workflow that moves from:

Fraud Alert
    ↓
Graph Investigation
    ↓
Context Retrieval
    ↓
Evidence Gathering
    ↓
Policy Evaluation
    ↓
Next-Best Action
    ↓
Human Escalation / Automated Action

The system investigates relationships between:

Customers
Cards
Transactions
Devices
Billing regions
Historical investigations
New investigation cases

It can also create investigation cases and write the results back into the graph, allowing future investigations to use previous cases as contextual evidence.

For high-exposure or interconnected fraud activity, the system can also generate a FinCEN Suspicious Activity Report (SAR) narrative containing the relevant:

Who
What
When
Where
How
Why

System Architecture

The overall architecture looks like this:

                  ┌─────────────────┐
                  │   Fraud Alert   │
                  └────────┬────────┘
                           │
                           ▼
              ┌────────────────────────┐
              │ TigerGraph Graph Engine │
              │       / GSQL            │
              └────────────┬───────────┘
                           │
                           ▼
              ┌────────────────────────┐
              │   GraphRAG Retrieval   │
              │  Relevant Subgraph     │
              └────────────┬───────────┘
                           │
                           ▼
              ┌────────────────────────┐
              │ Stage 1: Initial       │
              │ Policy Assessment      │
              └────────────┬───────────┘
                           │
                           ▼
              ┌────────────────────────┐
              │ Controlled Evidence    │
              │ Gathering              │
              └────────────┬───────────┘
                           │
                           ▼
              ┌────────────────────────┐
              │ Stage 2: Final         │
              │ Next-Best Action       │
              └────────────┬───────────┘
                           │
                 ┌─────────┴──────────┐
                 ▼                    ▼
        ┌─────────────────┐  ┌─────────────────┐
        │ FinCEN SAR      │  │ Graph Memory    │
        │ Generation      │  │ Writeback       │
        └────────┬────────┘  └────────┬────────┘
                 │                    │
                 └──────────┬─────────┘
                            ▼
                 ┌──────────────────────┐
                 │ Fraud Analyst       │
                 │ Investigation UI    │
                 └──────────────────────┘

The system is built around four major components.

1. TigerGraph as the Fraud Intelligence Layer

The first major decision was to represent fraud activity as a graph instead of treating transactions as isolated rows.

Vertices

Our graph contains entities such as:

Customer
Card
Transaction
DeviceProfile
BillingRegion
ClosedCase
InvestigationCase

For example, a transaction can contain information such as:

Transaction
├── timestamp
├── amount
├── channel
├── risk_score
├── billing_region
├── email_domain
└── device_signature

Edges

Relationships connect these entities:

Customer ──OWNS──────> Card
Card ──MADE──────────> Transaction
Transaction ──FROM_DEVICE──> DeviceProfile
Transaction ──BILLED_IN────> BillingRegion
Transaction ──NEXT──────────> Transaction

InvestigationCase ──INVOLVES──> Transaction
InvestigationCase ──ON_CARD───> Card
InvestigationCase ──CONNECTED_TO──> DeviceProfile

This allows us to ask questions that are difficult to answer using isolated transaction records.

For example:

"What other cards have used this device?"

or:

"What transactions happened around this card within the last 48 hours?"

or:

"Have we seen a similar fraud pattern in a previous investigation?"

2. GraphRAG: Giving the Agent the Right Context

One of the biggest problems with using an LLM for fraud investigation is context.

We could dump thousands of transaction records into an LLM.

That would be expensive, noisy, and difficult to reason about.

Instead, we use GraphRAG.

The graph first retrieves the relevant neighborhood around the suspicious transaction.

For example:

Suspicious Transaction
        │
        ├── Card
        │    ├── Previous Transactions
        │    └── Customer
        │
        ├── Device
        │    ├── Other Cards
        │    └── Other Customers
        │
        ├── Billing Region
        │    └── Historical Usage
        │
        └── Similar Closed Cases

The LLM receives this focused context instead of the entire dataset.

This makes the reasoning process:

More relevant
More explainable
Less expensive
Easier to audit

3. GSQL Queries for Investigation

We implemented several graph queries to investigate different fraud signals.

`card_window`

Retrieves transactions around a suspicious transaction within a defined time window.

One pattern we looked for was:

$2.50 authorization
       ↓
$3.20 authorization
       ↓
$4.10 authorization
       ↓
Large purchase

Individually, these transactions may appear insignificant.

Together, they can represent a potential card-testing pattern.

`device_neighbors`

This query starts from a transaction's device signature and discovers other connected cards or customers.

For example:

Device X
 ├── Card A
 │    └── Customer A
 │
 ├── Card B
 │    └── Customer B
 │
 └── Card C
      └── Customer C

This type of relationship can reveal multi-card activity that would be difficult to detect from transaction-level analysis alone.

`region_deviation`

This query analyzes historical billing-region behavior.

The goal is to distinguish between:

Normal travel
      vs
Potential card cloning / abnormal usage

A single out-of-region transaction is not necessarily fraud.

The surrounding behavioral context matters.

`find_similar_cases`

This query searches historical investigation cases for similar patterns and exposure levels.

This gives the agent a form of case memory.

Instead of treating every investigation as a completely new problem, the system can ask:

"Have we investigated something similar before?"

4. The Agentic Investigation Workflow

The interesting part of the system is not just the graph.

It is how the graph is combined with an agentic decision workflow.

We implemented a two-stage investigation process.

Stage 1 — Initial Assessment

When an alert arrives, the agent evaluates the available evidence.

It considers things such as:

Transaction risk
Transaction velocity
Device relationships
Customer history
Billing-region behavior
Connected cards
Historical cases

The agent then produces an initial action recommendation.

For example:

{
  "action": "VERIFY_WITH_CUSTOMER",
  "confidence": 0.64,
  "reason": "Suspicious transaction detected, but available evidence is insufficient for immediate blocking."
}

The important part is that the system does not automatically treat every high-risk signal as confirmed fraud.

5. Controlled Evidence Gathering

If the available evidence is insufficient, the system can request additional evidence.

For example:

Initial Alert
     ↓
Insufficient Evidence
     ↓
Customer Verification
     ↓
Additional Evidence
     ↓
Re-evaluation

Depending on the situation, the workflow can simulate actions such as:

VERIFY_WITH_CUSTOMER
STEP_UP_AUTH
REQUEST_ADDITIONAL_EVIDENCE

The evidence request and resulting assumptions are recorded as part of the investigation.

6. Stage 2 — Next-Best Action

After additional evidence is available, the agent evaluates the case again.

This creates an important distinction:

BEFORE EVIDENCE
       ↓
Initial Action

AFTER EVIDENCE
       ↓
Final Action

The system also records:

what_changed

This is useful because an analyst can understand why the recommended action changed instead of simply seeing the final decision.

The final action can be routed according to the required level:

AUTO
 ↓
L1 REVIEW
 ↓
L2 REVIEW

This provides a human-in-the-loop boundary rather than allowing the LLM to make unrestricted decisions.

7. Policy Engine

The agent operates within a defined policy layer rather than making decisions purely from an LLM response.

Our policy configuration contains rules such as R1 through R10.

For example, under our investigation policy, an isolated weak signal below a defined confidence threshold should trigger additional verification rather than immediate blocking.

On the other hand, specific combinations of signals — such as connected devices across multiple cards — can trigger stronger investigation workflows.

This separation is important:

LLM
 ↓
Reasoning

Policy Engine
 ↓
Allowed Actions

Human Review
 ↓
Final Authority

The LLM provides reasoning.

The policy layer provides boundaries.

The human remains part of the decision loop for cases requiring escalation.

8. Graph Memory

One of the features we found particularly interesting was investigation memory.

After an investigation is completed, the system writes the resulting case back into TigerGraph.

For example:

InvestigationCase
       │
       ├── INVOLVES → Transaction
       ├── ON_CARD → Card
       ├── CONNECTED_TO → Device
       └── RELATED_TO → Previous Case

Now a future investigation can retrieve the previous case.

This creates a feedback loop:

Investigation
     ↓
Case Result
     ↓
Graph Memory
     ↓
Future Investigation
     ↓
Better Context
     ↓
New Case
     ↓
Graph Memory

The graph gradually becomes not just a representation of financial activity, but also a representation of institutional investigation history.

9. Automated SAR Generation

For investigations that meet the configured exposure or connectivity conditions, the system can generate a FinCEN Suspicious Activity Report narrative.

The narrative is structured around the core investigative questions:

Who?
What?
When?
Where?
How?
Why?

Instead of asking an analyst to manually reconstruct the entire investigation, the agent uses the evidence already collected during the investigation workflow.

The generated narrative can then be reviewed by the appropriate human compliance team.

10. Investigation Dashboard

We built the analyst interface using:

React
Vite
HTML5
Interactive graph visualization

The dashboard provides an investigation-oriented view of the case.

An analyst can inspect:

Transaction
    ↓
Card
    ↓
Customer
    ↓
Device
    ↓
Connected Cards
    ↓
Related Transactions
    ↓
Historical Cases

The UI also supports re-investigation triggers and side-by-side comparison of:

Initial Action
        vs
Final Action

This makes the agent's reasoning process easier to inspect.

What We Learned

1. Fraud Is Often a Graph Problem

A transaction can look completely normal when viewed individually.

Its relationships may tell a different story.

For example:

Transaction → Device → Other Card → Other Customer

can provide substantially more context than:

Transaction → Risk Score

This is where graph-based investigation becomes valuable.

2. Risk Scores Are Inputs, Not Conclusions

A risk score is useful, but it does not contain the entire context of a customer.

A high-risk transaction could be caused by:

Travel
A new device
A legitimate location change
Unusual but legitimate purchasing behavior

Treating the score as the final answer can therefore create unnecessary customer friction.

Our approach was to combine risk signals with relationship context and policy rules.

3. Graph Memory Can Become an Investigation Asset

Writing completed investigations back into the graph creates a continuously growing knowledge layer.

Today's investigation can become context for tomorrow's investigation.

That is a fundamentally different architecture from treating each alert as an isolated event.

What We Would Build Next

The prototype gave us several directions for future development.

1. Graph Neural Networks

We would explore GNN-based embeddings to detect more subtle graph structures.

Instead of relying only on predefined rules, the model could learn patterns such as:

Device → Card → Customer
       ↘ Card → Customer
       ↘ Card → Customer

and identify unusual network structures before traditional rules trigger.

2. Real-Time Streaming with Kafka

The next step would be moving from batch investigation to real-time fraud intervention.

A potential architecture:

Card Authorization
       ↓
Kafka
       ↓
TigerGraph
       ↓
Graph Investigation
       ↓
Agent
       ↓
Policy Engine
       ↓
Authorization Decision

The goal would be to investigate suspicious relationships while the authorization is still being processed.

3. Multi-Agent Investigation

We could also introduce specialized agents with different responsibilities.

For example:

                Investigation
                     │
          ┌──────────┼──────────┐
          ↓          ↓          ↓
     Fraud Agent  Compliance  CX Agent
                     Agent
          │          │          │
          └──────────┼──────────┘
                     ↓
              Policy Engine
                     ↓
              Human Review

Each agent would evaluate the case from a different operational perspective before the final action is selected.

Final Takeaway

The main lesson from this project was simple:

Fraud detection should not stop at identifying suspicious transactions. It should investigate the relationships around them.

TigerGraph gave us the relationship layer.

GraphRAG gave the LLM focused contextual evidence.

The agentic workflow provided investigation and evidence-gathering capabilities.

The policy engine provided deterministic boundaries.

And graph memory allowed completed investigations to become future context.

Together, these components allowed us to move from:

"Something looks suspicious."

to:

"Here is what is connected,
here is what we found,
here is what changed after gathering evidence,
and here is the next action supported by the available evidence and policy."

That is the direction we explored with Autonomous Fraud Investigation & Next-Best Action at HackerHouse Goa 2026.

Tech Stack

Graph Database     → TigerGraph
Graph Query        → GSQL
AI / LLM           → GraphRAG + Agentic Workflow
Frontend           → React + Vite
Visualization      → HTML5 Force-Directed Graph
Backend / Logic    → Agent + Policy Engine
Compliance         → FinCEN SAR Generation

Built with ❤️ for HackerHouse Goa 2026.
Team- Morpheus
(Keertana Gupta & Chitresh Gurjar)

DEV Community: chitresh gurjar

Autonomous Fraud Investigation & Next-Best Action with TigerGraph and GraphRAG

The Problem: Fraud Is a Network Problem

What We Built

System Architecture

1. TigerGraph as the Fraud Intelligence Layer

Vertices

Edges

2. GraphRAG: Giving the Agent the Right Context

3. GSQL Queries for Investigation

card_window

device_neighbors

region_deviation

find_similar_cases

4. The Agentic Investigation Workflow

Stage 1 — Initial Assessment

5. Controlled Evidence Gathering

6. Stage 2 — Next-Best Action

7. Policy Engine

8. Graph Memory

9. Automated SAR Generation

10. Investigation Dashboard

What We Learned

1. Fraud Is Often a Graph Problem

2. Risk Scores Are Inputs, Not Conclusions

3. Graph Memory Can Become an Investigation Asset

What We Would Build Next

1. Graph Neural Networks

2. Real-Time Streaming with Kafka

3. Multi-Agent Investigation

Final Takeaway

Tech Stack

`card_window`

`device_neighbors`

`region_deviation`

`find_similar_cases`