🔍 FraudLens: Building an Agentic Fraud Investigation System with TigerGraph

Alec — Thu, 24 Sep 2026 13:51:51 +0000

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

DEV Community: Alec