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
Top comments (0)