From detecting suspicious transactions to investigating them, resolving uncertainty, and determining the next best action.
Fraud detection is often treated as a classification problem:
“Is this transaction fraudulent?”
But real-world fraud investigation is much more complicated.
An investigator needs to understand:
- Why is the transaction suspicious?
- What entities are connected to it?
- What evidence supports or contradicts the suspicion?
- Have similar cases appeared before?
- Is there enough evidence to take action?
- What additional evidence should be collected?
- What should happen next?
- Can the entire decision be explained and audited?
For the TigerGraph × Hacker House Goa 2026 Hackathon, we built FraudLens to address this investigation problem.
FraudLens is an agentic fraud investigation system powered by TigerGraph that combines graph-based evidence, historical case memory, uncertainty assessment, controlled evidence collection, and policy-constrained Next Best Action recommendations.
🎯 The Problem
A suspicious transaction rarely exists in isolation.
Consider a simple investigation:
Transaction
│
▼
Card
│
▼
Customer
│
▼
Device
/ \
Card A Card B
The transaction itself may not provide enough information.
However, the relationships around that transaction can reveal:
- shared devices
- connected cards
- unusual transaction velocity
- related accounts
- repeated behavioral patterns
- previous investigations
This creates a fundamental problem with transaction-only analysis:
Fraud is often a network problem, not just a transaction problem.
We therefore designed FraudLens around a knowledge graph so that the investigation agent can move beyond a single transaction and explore its surrounding entity network.
🧠 Our Approach
FraudLens follows an investigation loop rather than producing a single prediction.
Trigger
↓
Investigate
↓
Gather Evidence
↓
Assess Risk & Uncertainty
↓
Is Evidence Sufficient?
│
├── No → Request Additional Evidence
│ ↓
│ Reassess Investigation
│ ↓
└─────────────┘
↓
Determine Next Best Action
↓
Apply Policy & Approval
↓
Explain Decision
↓
Write Case Back to Graph
This is the core idea behind FraudLens:
Detection starts the investigation; it doesn't finish it.
🏗️ System Architecture
FraudLens combines several layers rather than relying on a single AI model.
┌──────────────────────┐
│ Fraud Signal │
│ Transaction / Case │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Agentic Planner │
│ Investigate / Plan │
└──────────┬───────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌──────────────┐
│ TigerGraph │ │ GraphRAG │ │ Evidence │
│ Knowledge │ │ Case Memory │ │ Collection │
│ Graph │ │ │ │ │
└──────┬──────┘ └──────┬──────┘ └──────┬───────┘
│ │ │
└─────────────────┼─────────────────┘
▼
┌──────────────────────┐
│ Risk & Uncertainty │
│ Assessment │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Policy Engine │
│ Rules & Permissions │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Next Best Action │
│ + Approval Route │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Case Writeback & │
│ Verification │
└──────────────────────┘
The architecture deliberately separates AI reasoning from deterministic investigation controls.
The agent can reason over evidence and explain findings, while the policy layer constrains what actions are allowed.
🐯 Why TigerGraph?
TigerGraph is at the center of FraudLens because relationships are fundamental to fraud investigation.
Instead of retrieving isolated records, we can traverse connected entities.
For example:
Transaction
↓
Card
↓
Customer
↓
Device
↓
Connected Cards
↓
Related Transactions
This enables the investigation agent to gather multi-hop evidence from the graph.
The graph therefore serves two purposes:
- Investigation data source
- Relationship intelligence layer
It is not simply a graph visualization added to the UI.
The graph actively contributes evidence to the investigation.
🔎 Multi-Hop Investigation
One of the most important capabilities of FraudLens is multi-hop investigation.
Suppose a transaction is associated with a device.
Instead of stopping there, the agent can investigate:
Transaction
↓
Card
↓
Customer
↓
Device
↙ ↘
Card A Card B
↓
Transactions
These relationships can reveal patterns that may not be visible when analyzing individual records.
The FraudLens graph interface allows investigators to:
- Expand entities
- Explore connected relationships
- Inspect entity details
- Follow multi-hop paths
- Identify suspicious relationship patterns
- Understand how graph evidence contributes to the case
📸 Knowledge Graph
[INSERT SCREENSHOT: TigerGraph Multi-Hop Investigation Graph]
📊 Risk Is Not the Same as Certainty
A major design decision was to avoid treating a fraud risk score as a final verdict.
FraudLens tracks multiple dimensions:
| Signal | Purpose |
|---|---|
| Risk Level | Overall severity |
| Fraud Probability Estimate | Current estimate of fraud likelihood |
| Confidence | Confidence in the assessment |
| Evidence Sufficiency | Whether there is enough evidence to act |
| Supporting Evidence | Evidence strengthening the hypothesis |
| Contradicting Evidence | Evidence weakening the hypothesis |
| Missing Evidence | Evidence that is still required |
This allows the system to distinguish between:
“This activity looks suspicious.”
and:
“We have enough evidence to take a defensible action.”
That distinction is essential for an investigation system.
🧾 Evidence Explorer
FraudLens organizes evidence into three categories.
🟢 Supporting Evidence
Evidence that strengthens the current hypothesis.
Examples can include:
- suspicious transaction behavior
- abnormal velocity
- connected suspicious entities
- shared-device relationships
- similar historical cases
🔴 Contradicting Evidence
Evidence that challenges the current hypothesis.
🟡 Missing Evidence
Information that could materially change the investigation but is not currently available.
This makes the investigation more transparent than a single AI-generated explanation.
The investigator can see not only what the system thinks, but also what the system knows and what it does not know.
📸 Evidence Explorer
[INSERT SCREENSHOT: Evidence Explorer]
🧠 GraphRAG & Historical Case Memory
Fraud investigations can benefit from organizational memory.
A new case may resemble investigations that have already been completed.
FraudLens therefore incorporates historical case retrieval into the investigation process.
Our retrieval layer combines:
Graph Retrieval + Semantic Retrieval + Graph-Aware Reranking
Historical investigations can provide context around:
- similar fraud patterns
- previous case outcomes
- related entity structures
- evidence combinations
- investigation history
The retrieved cases are used as contextual evidence rather than automatically determining the outcome of the current case.
This distinction is important because every investigation still needs to be grounded in its own current evidence.
🤖 The Investigation Agent
The agent coordinates the investigation process.
Its responsibilities include:
- Creating and progressing the case
- Planning investigation steps
- Gathering graph evidence
- Retrieving relevant historical cases
- Assessing risk and uncertainty
- Determining whether evidence is sufficient
- Requesting additional evidence when required
- Reassessing after new evidence
- Generating the Next Best Action
- Explaining the decision
- Updating the investigation record
The agent therefore acts as an investigation orchestrator, rather than simply being a chatbot.
❓ Knowing When More Evidence Is Needed
One of the most important agentic capabilities is knowing when to stop — and when not to stop.
If the evidence is insufficient, FraudLens can request additional evidence through controlled investigation actions.
Examples include:
- Customer validation
- Step-up authentication
- Additional analyst information
- Other investigation-specific evidence
The important part is that the request is tied to the current uncertainty.
Instead of:
“Need more data.”
FraudLens aims to answer:
“What is missing, and why could this information change the investigation?”
This turns evidence collection into an intentional investigation step.
🔄 Reassessment After Additional Evidence
Collecting additional evidence is only useful if the investigation actually reassesses the case.
FraudLens follows:
Initial Assessment
↓
Identify Uncertainty
↓
Request Evidence
↓
Receive Evidence
↓
Re-run Investigation
↓
Updated Risk
↓
Updated Confidence
↓
Updated Next Best Action
This creates a visible before-and-after investigation state.
Before
Risk / Confidence
↓
Remaining Uncertainty
↓
Initial Recommendation
After
Additional Evidence
↓
Reassessment
↓
Updated Risk / Confidence
↓
Updated Recommendation
This allows an investigator to understand what changed and why.
📸 Before/After Reassessment
[INSERT SCREENSHOT: Initial vs Final Assessment]
⚡ Next Best Action
Once sufficient evidence is available, FraudLens determines the Next Best Action (NBA).
Depending on the investigation and policy, possible actions include:
- Allow transaction
- Block transaction
- Monitor account
- Warn customer
- Request additional evidence
- Create or escalate a case
- Require human approval
- File a report when required
The system also records the approval route.
This creates an important separation:
AI Recommendation ≠ Automatic Authorization
The recommended action must still operate within the defined policy and permission model.
🛡️ Policy-Constrained AI
Another core design principle was:
The LLM should reason over and explain the investigation, but it should not bypass the control layer.
FraudLens uses deterministic fraud policies to constrain actions.
The AI layer focuses on:
- reasoning over evidence
- planning investigation steps
- synthesizing findings
- explaining uncertainty
- explaining recommendations
The policy layer controls:
- available actions
- escalation requirements
- approval routes
- policy-specific constraints
This gives FraudLens a hybrid architecture:
AI Reasoning
+
Graph Intelligence
+
Historical Memory
+
Deterministic Policies
=
Controlled Agentic Investigation
📝 Explainability & Investigation Timeline
A fraud investigation needs to be auditable.
FraudLens maintains a structured case progression such as:
Triggered
↓
Investigating
↓
Evidence Gathered
↓
Uncertainty Assessed
↓
Additional Evidence
↓
Reassessment
↓
Action Recommended
↓
Approval
↓
Resolution
The case records important investigation information including:
- findings
- evidence
- risk
- confidence
- evidence requests
- recommendations
- approval route
- final outcome
- investigation timeline
This allows an investigator to reconstruct how the case evolved.
💾 Writing the Investigation Back to TigerGraph
TigerGraph is not only used to retrieve investigation evidence.
FraudLens can also write the completed investigation back into the graph.
After writing, the system performs read-after-write verification so that the stored case can be checked rather than assuming that a successful write operation means the case was correctly persisted.
The resulting loop is:
Investigate
↓
Decide
↓
Resolve
↓
Write Back
↓
Verify
↓
Future Case Memory
This closes the investigation lifecycle.
🖥️ The FraudLens Command Center
We designed the UI around the investigator's workflow.
The major sections include:
Investigations
Search and manage fraud investigation cases.
Evidence Explorer
Review supporting, contradicting, and missing evidence.
Knowledge Graph
Explore the TigerGraph entity network.
AI Audit
Review investigation reasoning, uncertainty, and agent activity.
Decisions
Review Next Best Action recommendations and approval requirements.
Case Memory
Explore historical investigations.
Policies
Understand the rules controlling available actions.
The objective was to make the system feel like an investigation command center, rather than a generic AI chat interface.
📸 FraudLens Dashboard
[INSERT SCREENSHOT: Main Dashboard]
🧪 Evaluation
For the hackathon benchmark, FraudLens is evaluated against the provided investigation cases.
The evaluation focuses on the core outcomes of the investigation workflow:
- Investigation accuracy
- Fraud pattern identification
- Risk assessment
- Evidence quality
- Next Best Action
- Explainability
- Case progression
- Additional evidence handling
The benchmark cases provide a controlled environment for evaluating whether the agent can move from a fraud signal to a defensible investigation outcome.
📊 Benchmark Results
[INSERT YOUR FINAL VERIFIED 20-CASE BENCHMARK TABLE/CHART HERE]
We intentionally avoid presenting unverified performance numbers in this write-up. The final published numbers should come directly from the validated benchmark run used for submission.
🧩 Key Engineering Challenges
Building FraudLens required solving several interconnected engineering problems.
1. Multi-hop Graph Investigation
We needed the agent to move from a transaction to connected entities and use those relationships as investigation evidence.
2. Evidence & Uncertainty
Risk, probability, confidence, and evidence sufficiency needed to remain separate concepts.
3. Historical Case Retrieval
Previous investigations needed to provide useful context without becoming a substitute for current evidence.
4. Agentic Control
The agent needed to determine when additional investigation was necessary and when sufficient evidence existed.
5. Policy Enforcement
AI-generated reasoning needed to operate within deterministic fraud policies and approval requirements.
6. Auditability
The entire investigation needed to remain traceable from trigger to resolution.
7. Graph Writeback
The completed case needed to become part of the persistent investigation record and be verified after writing.
🚀 What We Learned
One of the biggest lessons from building FraudLens was that an effective AI agent is not simply an LLM with tools.
A reliable investigation agent needs multiple layers working together:
LLM
│
Reasoning & Planning
│
┌───────┼────────┐
▼ ▼ ▼
Graph Memory Evidence
│ │ │
└───────┼────────┘
▼
Risk & Uncertainty
│
▼
Policy Engine
│
▼
Next Best Action
│
▼
Human Approval
│
▼
Case Writeback
The LLM provides reasoning and synthesis.
TigerGraph provides relationship intelligence.
GraphRAG provides historical context.
Evidence collection resolves uncertainty.
The policy engine constrains decisions.
And the case record provides an auditable investigation history.
🔮 What's Next?
FraudLens provides the foundation for a broader fraud investigation platform.
Potential future improvements include:
- More advanced graph-based fraud pattern detection
- Additional investigation signals
- Improved semantic case retrieval
- More sophisticated uncertainty estimation
- Analyst feedback loops
- Automated case prioritization
- Expanded policy and approval workflows
- Richer investigation analytics
- Continuous learning from resolved cases
The long-term goal is to make fraud investigation increasingly evidence-driven, explainable, and operationally actionable.
🏁 Conclusion
Fraud detection shouldn't end with a risk score.
A suspicious transaction should trigger an investigation.
That investigation should:
Explore the relationships → Gather evidence → Understand uncertainty → Request what is missing → Reassess → Determine the next best action → Apply policy → Explain the decision → Write the case back.
That is the idea behind FraudLens.
By combining TigerGraph, agentic AI, GraphRAG, historical case memory, controlled evidence collection, uncertainty assessment, and policy-constrained decision making, we built a system that treats fraud as an investigation problem rather than simply a classification problem.
FraudLens doesn't just detect suspicious transactions — it investigates the evidence, resolves uncertainty, and determines the next best action.
🔗 Project Resources
GitHub:
https://github.com/theanshukr/FRAUDLENS
Hackathon:
TigerGraph × Hacker House Goa 2026
👥 Team
Team: Blunder
Built by:
Anshu Kumar
Kanav Sharma
Manik Mehra
🛠️ Tech Stack
- TigerGraph — Knowledge Graph & graph-based investigation
- GSQL / TigerGraph Queries — Graph retrieval and investigation
- TigerGraph MCP — Agent-to-graph tool integration
- GraphRAG — Historical case retrieval and contextual reasoning
- LLM — Investigation reasoning, synthesis and explanation
- Python — Agent and backend orchestration
- FastAPI — Backend API
- Next.js — Investigation interface
- Policy Engine — Deterministic fraud action controls
Tags
#TigerGraph #FraudDetection #FraudInvestigation #AI #AgenticAI #GraphRAG #GraphDatabase #GenerativeAI #Hackathon #Python
Top comments (0)