Building an Explainable Fraud Investigation Platform with TigerGraph

Introduction

Fraud rarely happens through a single transaction. A suspicious transaction can be connected to multiple accounts, devices, IP addresses, and previous fraud cases.

The challenge is not just detecting suspicious activity, but understanding:

What happened, what is connected, and what evidence supports the investigation?

For the TigerGraph Hackathon, we built a multi-agent fraud investigation platform combining graph analytics, historical case retrieval, MCP tools, evidence validation, and an optional LLM narrative layer.

What We Built

The platform takes a flagged transaction and runs it through an automated investigation workflow:

Suspicious Transaction
        ↓
Multi-Agent Investigation
        ↓
TigerGraph + Historical Cases
        ↓
Evidence & Rule Validation
        ↓
Explainable Investigation

Instead of returning only a risk score, the system provides supporting evidence that an investigator can inspect.

The repository includes 20 structured investigation cases, from HHG-001 to HHG-020.

Architecture

The system is built with a FastAPI backend, investigation coordinator, agent workflow, MCP tools, TigerGraph, vector retrieval, and case data.

              Web Interface
                    ↓
                FastAPI
                    ↓
          Investigation Coordinator
                    ↓
       ┌────────────┼────────────┐
       ↓            ↓            ↓
    Agents       MCP Tools   Validation
       └────────────┼────────────┘
                    ↓
          ┌─────────┴─────────┐
          ↓                   ↓
     TigerGraph          Vector Store
          ↓                   ↓
  Relationship Data    Historical Cases

This separation makes the system easier to test and extend.

How TigerGraph Is Used

Fraud investigation is fundamentally a relationship problem.

An account can be connected to transactions, other accounts, devices, IPs, and previous fraud cases.

For example:

Account A
    ↓
Transaction
    ↓
Account B
    ↓
Shared Device
    ↓
Previous Fraud Case

TigerGraph allows us to represent and investigate these relationships as a graph.

We also added a deployment script for schema installation, loading jobs, GSQL queries, CSV streaming, and backend activation.

Graph + Historical Case Retrieval

TigerGraph helps answer:

“What is connected?”

Our vector retrieval system helps answer:

“Have we seen something similar before?”

We indexed 5,565 closed cases and use cosine similarity to retrieve relevant historical cases.

This combines:

Relationship context + Historical precedent

within the same investigation.

Agentic Capabilities

The investigation is divided into specialized responsibilities instead of relying on one component.

Agents can use MCP tools for:

• Transaction lookup
• Graph investigation
• Historical case retrieval
• Evidence retrieval
• Validation

A coordinator combines these results into the final investigation output.

We also implemented:

GET /api/investigate/{txn_id}

which runs the investigation pipeline on demand for a flagged transaction.

Optional LLM Layer

The platform includes an optional LLM-powered narrative agent.

LLM Enabled  → LLM Narrative
LLM Disabled → Deterministic Narrative

The deterministic fallback means the core investigation does not depend entirely on an external LLM service.

Testing and Reliability

We added automated tests covering data loading, agent coordination, validation, MCP tools, vector retrieval, narrative fallback, deployment, and QA.

Final verification:

• 8/8 tests passing
• 20/20 cases verified
• 100% QA audit

What We Learned

Fraud Is a Relationship Problem

A transaction alone provides limited context. Graph relationships can reveal the larger network around it.

Historical Cases Add Context

Previous investigations can provide useful precedent for new cases.

Agentic Systems Benefit from Separation

Separating graph analysis, case retrieval, validation, and coordination makes the system easier to understand and extend.

Explainability Matters

Instead of simply saying “this transaction is risky,” an investigation system should show the relationships and evidence behind the result.

What's Next?

Future improvements could include:

• Production-grade embeddings and vector databases
• Real-time transaction ingestion
• Advanced graph algorithms
• Human-in-the-loop analyst workflows
• More evidence-grounded LLM reasoning

Conclusion

Our goal was to build more than a fraud detection system.

We built an investigation assistant that connects transactions, entities, relationships, and historical cases into one explainable workflow.

By combining TigerGraph, multi-agent workflows, MCP tools, vector retrieval, and optional LLM capabilities, the platform helps move from a suspicious transaction toward a structured investigation.

Don't just flag the transaction. Investigate the network behind it.

Project Repository

GitHub — HHGOA Task 04

Built for the TigerGraph Hackat