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