Building an Agentic GraphRAG Fraud Investigation System with TigerGraph

VENOM GAMING — Thu, 24 Sep 2026 17:11:44 +0000

Fraud investigation is rarely about looking at a single transaction.

A suspicious transaction might only become meaningful when connected to a customer, card, device, merchant, region, previous transactions, and historical fraud cases.

That is where graph-based investigation becomes powerful.

For the TigerGraph HHGOA Agentic Fraud Investigation Hackathon, we built an Agentic GraphRAG Fraud Investigation System designed to investigate suspicious activity, gather connected evidence, assess uncertainty, determine risk, recommend the next best action, and preserve investigation context for future cases.

The system combines:

TigerGraph Savanna Cloud
GSQL graph traversal
GraphRAG-based case memory
Agentic investigation workflow
Policy-based decisioning
Automated SAR narrative generation
D3.js investigation visualization
Cyber-SOC-style analyst workspace

The goal wasn't simply to build another fraud dashboard.

The goal was to build a system that can move from:

Signal → Investigation → Evidence → Reasoning → Action → Memory

1. The Problem

Modern financial fraud is increasingly multi-dimensional.

A suspicious transaction may involve:

Customer
   ↓
Card
   ↓
Transaction
   ↓
Device
   ↓
Region
   ↓
Merchant
   ↓
Historical Cases

Looking at these entities independently makes investigation difficult.

For example, a transaction might look normal by itself.

But when we discover that:

the customer is using a previously unseen device,
the device is connected to multiple entities,
transaction velocity has increased,
the location is inconsistent with previous behavior,
and similar patterns appeared in previously closed fraud cases,

the investigation becomes much more meaningful.

This is the type of relationship-heavy problem where a graph database becomes extremely useful.

2. Our Approach

We designed the system around an agentic investigation loop:

Fraud Signal
     ↓
Initial Investigation
     ↓
Graph Evidence Retrieval
     ↓
Risk & Pattern Assessment
     ↓
Uncertainty Check
     ↓
Additional Evidence
     ↓
Updated Assessment
     ↓
Next Best Action
     ↓
Approval / Execution Route
     ↓
Case Memory Update

Instead of treating fraud detection as a single classification step, the system treats it as an investigation process.

The investigator needs to answer:

What happened?

What entities are connected?

What evidence supports the suspicion?

How strong is that evidence?

What remains uncertain?

What should happen next?

3. System Architecture

The platform is divided into five major layers.

┌───────────────────────────────────────────────┐
│             ANALYST WORKSPACE                 │
│                                               │
│  Dashboard │ Investigations │ Graph Explorer  │
│  Reports   │ Watchlist      │ Settings        │
└───────────────────────┬───────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────┐
│              APPLICATION LAYER                │
│                                               │
│       Python HTTP Server + REST APIs          │
└───────────────────────┬───────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────┐
│           AGENTIC INVESTIGATION ENGINE        │
│                                               │
│ GraphRAG Investigator                         │
│ Policy Evaluator                              │
│ Case Memory                                   │
│ SAR Generator                                 │
└─────────────┬─────────────┬───────────────────┘
              │             │
              ▼             ▼
┌──────────────────┐  ┌────────────────────────┐
│ TigerGraph       │  │ Historical Case Memory │
│ Savanna Cloud    │  │ 5,565 Closed Cases     │
│                  │  │                        │
│ Multi-hop Graph  │  │ Similarity / Precedent │
│ Investigation    │  │ Retrieval              │
└──────────────────┘  └────────────────────────┘

The frontend provides the analyst workspace while the backend coordinates investigation, graph retrieval, policy evaluation, case memory and reporting.

4. Why TigerGraph?

The central reason for using TigerGraph was simple:

Fraud is highly relational.

Traditional tabular analysis can tell us that a transaction has certain attributes.

A graph can tell us how those attributes are connected.

Our investigation graph contains entities such as:

Customer
Card
Transaction
Device
Merchant
Bank
Region

These entities form relationships that can be traversed during investigation.

For example:

Customer
   │
   ├── owns → Card
   │            │
   │            └── performs → Transaction
   │                              │
   │                              ├── uses → Device
   │                              │
   │                              ├── occurs_in → Region
   │                              │
   │                              └── involves → Merchant

This allows the investigator to expand the evidence context instead of examining an isolated transaction.

5. Multi-Hop Investigation with GSQL

One of the important parts of our implementation is graph traversal.

For an investigation, the system can expand the relevant entity neighborhood across multiple hops.

Conceptually:

Customer
   ↓
Card
   ↓
Transaction
   ↓
Device
   ↓
Region

This allows the system to discover relationships that aren't immediately visible from the original trigger.

The TigerGraph connector is implemented through a custom Python wrapper that communicates with TigerGraph Savanna Cloud and executes the required graph queries.

The investigation engine then converts the graph response into structured evidence for the agentic reasoning pipeline.

6. GraphRAG Case Memory

Graph investigation tells us what is connected.

But investigation shouldn't start from zero every time.

That's where our GraphRAG case memory comes in.

We maintain a historical memory bank containing 5,565 closed investigation cases.

When a new benchmark case arrives, the system searches historical investigation context for similar patterns.

Conceptually:

New Case
   │
   ▼
Extract Investigation Signals
   │
   ▼
Retrieve Similar Historical Cases
   │
   ▼
Compare Patterns
   │
   ├── Similar Device Pattern
   ├── Similar Velocity Pattern
   ├── Similar Location Pattern
   └── Similar Cross-Card Pattern
   │
   ▼
Investigation Context

This gives the investigator historical context rather than relying exclusively on the current transaction.

The result is a more contextual investigation workflow:

Current evidence + historical precedent

7. Policy-Driven Investigation

Fraud investigation cannot rely only on an LLM saying:

"This looks suspicious."

There needs to be structured decision logic.

Our system incorporates fraud policy rules, including patterns such as:

anomaly thresholds
velocity/location anomalies
new-device CNP behavior
cross-card syndicate patterns
uncertainty requiring escalation

The policy layer helps transform evidence into structured investigation outcomes.

Conceptually:

Graph Evidence
      +
Historical Evidence
      +
Policy Rules
      ↓
Risk Assessment
      ↓
Next Best Action

This separation between evidence retrieval and policy evaluation is important because it makes the decision process easier to inspect and explain.

8. Initial Decision → Additional Evidence → Final Decision

One of the key ideas in our implementation is that the investigation does not have to stop after the first evidence pass.

The workflow can be represented as:

Initial Trigger
      ↓
Initial Evidence
      ↓
Initial Assessment
      ↓
Is Evidence Sufficient?
      │
   ┌──┴───┐
   │      │
  YES     NO
   │      │
   │      ▼
   │  Request / Gather
   │  Additional Evidence
   │      │
   │      ▼
   │  Updated Assessment
   │      │
   └──────┘
      ↓
Next Best Action

This is much closer to how an actual investigation workflow operates.

The system needs to recognize not only:

"What do I know?"

but also:

"What don't I know yet?"

9. Next Best Action

After investigation, the system determines an appropriate next action based on the evidence and policy context.

Potential actions include:

Allow Transaction
Block Transaction
Monitor Account
Block Account
Warn Customer
Create Fraud Case
Request Additional Evidence
Escalate to Analyst
File Regulatory Report

The system also separates recommendation from approval/execution where required.

This is important for agentic systems operating in sensitive financial workflows.

The agent should not blindly execute every action.

Instead:

Evidence
   ↓
Recommendation
   ↓
Policy / Permission Check
   ↓
Approval Route
   ↓
Execution

10. Automated SAR Generation

Regulatory reporting is another major part of fraud investigation.

Our platform includes an automated FinCEN Suspicious Activity Report narrative generator.

When the investigation meets the applicable reporting criteria, the system synthesizes relevant evidence into a structured narrative.

The generated report can include information such as:

suspicious transaction amounts
affected entities
anomalous devices
relevant behavioral patterns
investigation evidence
policy justification

The purpose is not simply to generate text.

The SAR generation is connected to the investigation context so that the narrative reflects the evidence gathered during the case.

11. The Analyst Command Center

We also wanted the investigation experience to feel like a real analyst workspace rather than a generic CRUD dashboard.

The result is a Cyber-SOC-style investigation interface.

The dashboard combines:

Live Investigation KPIs

Six major telemetry cards provide visibility into:

Total Benchmark Cases
Confirmed Fraud
Cleared False Alarms
Escalated Cases
Total Fraud Exposure
Regulatory SARs

Each KPI uses a compact SVG area visualization rather than a static number.

12. Interactive Graph Visualization

The graph is one of the main investigation surfaces.

Using D3.js, the interface visualizes relationships between:

Customers
Cards
Transactions
Devices
Merchants
Banks
Regions

Entities use semantic visual representations so that analysts can quickly distinguish different entity types.

The graph supports interaction such as:

Search
   ↓
Select Entity
   ↓
Inspect Entity
   ↓
Explore Relationships
   ↓
Expand Connected Evidence

The Graph Explorer also provides pan, zoom and relationship inspection capabilities.

13. Five Investigation Workspaces

Instead of putting everything on one dashboard, we created dedicated investigation modules.

Investigations

Provides:

case search
filtering
sorting
risk/status views
case details
investigation timelines
evidence context

Graph Explorer

Provides:

multi-entity graph exploration
relationship inspection
entity search
interactive graph controls

Reports

Provides:

case intelligence reports
report filtering
report preview
print functionality
report download

Watchlist

Provides:

monitored entities
risk levels
entity creation
persistent browser storage

Settings

Provides:

visual preferences
graph animation controls
UI density
notification settings
default investigation filters
storage reset

The goal was to make each module represent an actual stage of an analyst workflow.

14. Benchmark Evaluation

We evaluated the system against the 20 benchmark investigation cases provided for the challenge.

Our current benchmark output includes:

Metric	Result
Benchmark Cases	20
Confirmed Fraud	16
Cleared False Alarms	2
Escalated Cases	2
Fraud Exposure	$3,588.42
Regulatory SARs	7

These outputs are generated as structured investigation records rather than only dashboard numbers.

Each case can contain investigation evidence, findings, decisions, actions and reporting context.

15. From Detection to Investigation

The biggest conceptual shift in this project was moving away from:

"Is this transaction fraudulent?"

toward:

"Why is this suspicious, what evidence supports it, what remains uncertain, and what should happen next?"

That difference is important.

A useful fraud investigation system needs to connect multiple dimensions:

Transaction
     +
Identity
     +
Device
     +
Behavior
     +
Graph Relationships
     +
Historical Cases
     +
Policy
     ↓
Investigation
     ↓
Decision
     ↓
Action

This is where combining TigerGraph + GraphRAG + Agentic workflows becomes interesting.

16. What We Learned

Building this system highlighted several important engineering lessons.

Graph context matters

Fraud signals become much more meaningful when their relationships are visible.

Memory matters

Historical investigation outcomes can provide valuable context for new cases.

Agents need boundaries

An agent operating in a financial investigation environment needs explicit policy and permission boundaries.

Explainability matters

An investigation result should be backed by evidence rather than only a final classification.

UI is part of the investigation

Even a strong backend becomes difficult to use if an analyst cannot quickly understand the evidence.

17. Future Improvements

There are several directions we would explore beyond the hackathon implementation:

richer real-time streaming transaction ingestion
more sophisticated graph embeddings
expanded historical case memory
stronger automated evidence-request policies
human-in-the-loop approval workflows
deeper graph algorithms for community/syndicate detection
production-grade authentication and authorization
audit logging for every agent action
model evaluation across larger fraud datasets

The long-term goal would be to evolve the prototype into a production-grade investigation platform capable of supporting continuous fraud operations.

18. Final Architecture

At a high level, the complete system looks like this:

                    ┌──────────────────────┐
                    │    Fraud Signal      │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │ Agentic Investigator │
                    └──────────┬───────────┘
                               │
                ┌──────────────┼──────────────┐
                ▼              ▼              ▼
        ┌─────────────┐ ┌────────────┐ ┌──────────────┐
        │ TigerGraph  │ │ GraphRAG   │ │ Policy       │
        │ Evidence    │ │ Memory     │ │ Engine       │
        └──────┬──────┘ └─────┬──────┘ └──────┬───────┘
               │              │               │
               └──────────────┼───────────────┘
                              ▼
                    ┌──────────────────────┐
                    │ Risk & Uncertainty   │
                    │ Assessment            │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │ Next Best Action     │
                    └──────────┬───────────┘
                               │
                       ┌───────┴────────┐
                       ▼                ▼
                ┌────────────┐   ┌──────────────┐
                │ Approval   │   │ SAR / Case   │
                │ Route      │   │ Memory       │
                └────────────┘   └──────────────┘

Conclusion

This project started with a simple question:

Can an AI agent do more than flag suspicious transactions?

Our answer was to build an investigation system around graph evidence, historical memory, policy reasoning and next-best-action workflows.

TigerGraph provides the relationship layer.

GraphRAG provides historical context.

The agentic workflow coordinates investigation.

The policy engine provides structured decision boundaries.

And the analyst dashboard turns all of that into an interactive investigation experience.

The resulting system moves the workflow from:

Detect → Investigate → Explain → Act → Remember

rather than stopping at detection.

That is the direction we explored with TigerGraph HHGOA: building an AI-powered fraud investigator that can reason over connected evidence and help analysts move from a suspicious signal to an explainable next action.

🛠️ Technology Stack

TigerGraph Savanna Cloud · GSQL · GraphRAG · Python · D3.js · REST APIs · Agentic AI · IEEE-CIS Fraud Dataset

🔗 Project

GitHub: https://github.com/doluzar219-ux/TigerGraph-HHGOA

🏆 Built for

TigerGraph HHGOA Agentic Fraud Investigation Hackathon

Tags:
#TigerGraph #GraphRAG #AgenticAI #FraudDetection #FraudInvestigation #GenerativeAI #CyberSecurity #AI #GraphDatabase #Hackathon

DEV Community: VENOM GAMING

Building an Agentic GraphRAG Fraud Investigation System with TigerGraph

1. The Problem

2. Our Approach

3. System Architecture

4. Why TigerGraph?

5. Multi-Hop Investigation with GSQL

6. GraphRAG Case Memory

7. Policy-Driven Investigation

8. Initial Decision → Additional Evidence → Final Decision

9. Next Best Action

10. Automated SAR Generation

11. The Analyst Command Center

Live Investigation KPIs

12. Interactive Graph Visualization

13. Five Investigation Workspaces

Investigations

Graph Explorer

Reports

Watchlist

Settings

14. Benchmark Evaluation

15. From Detection to Investigation

16. What We Learned

Graph context matters

Memory matters

Agents need boundaries

Explainability matters

UI is part of the investigation

17. Future Improvements

18. Final Architecture

Conclusion

🛠️ Technology Stack

🔗 Project

🏆 Built for