By Akhil, Om and Lovesh

Building an Agentic Fraud Investigator with TigerGraph, LangGraph, and Gemini

Most fraud systems answer one question: is this transaction suspicious? A bank analyst needs three answers: what happened, how confident are we, and what should the bank do next?

For the TigerGraph × Hacker House Goa challenge, we built an agent that answers all three. It takes a fraud alert, investigates it against a graph of transaction data, decides whether it's fraud, legitimate, or unclear, and recommends a next action under the bank's written policy.

Demo: Google Drive
Code: OMIZOOMI/tigergraph-fraud-investigation

The Problem

The challenge dataset is derived from IEEE-CIS: roughly 590,000 card transactions and 144,000 identity records, with the fraud label removed. Each transaction carries only a risk score from a detection model, and the agent had to investigate 20 benchmark cases.

A high risk score is not proof of fraud. Plenty of legitimate activity looks odd on the surface, so the agent has to weigh evidence and know when it doesn't have enough to decide. That is a relationship problem: is this card tied to a device that many other cards use, do the regions make sense, and did similar past cases turn out to be fraud?

What We Built

An agentic investigation pipeline that:

• Compares a suspicious transaction against the cardholder's own history.
• Looks for related devices, regions, transactions, and closed cases.
• Classifies the case as fraud, legitimate, or uncertain, and flags undocumented patterns that don't match known typologies.
• Requests additional (simulated) customer evidence and shows how the recommendation dynamically changes.
• Routes the decision for approval (auto, L1, or L2 analyst) based on exposure amounts and uncertainty policies.
• Writes the result back to TigerGraph and saves a readable JSON answer file for every case.

Architecture

case_pack.csv ──► run_investigation.py
                        │
                        ▼
              ┌───────────────────┐
              │ LangGraph         │
              │ Investigator node │◄──── TigerGraph MCP client ──► TigerGraph (FraudGraph)
              │        │          │◄──── local case memory (closed_cases_history.csv)
              │        ▼          │
              │ Decision node     │
              │        │          │
              │ Evidence needed?  │
              │   yes │     │ no  │
              │       ▼     ▼     │
              │ Simulate   Save & │
              │ evidence   close  │
              └───────────┬────────┘
                          ▼
                cases/<case_id>.json  +  write-back to TigerGraph

Data loading: Transactions and identity data are loaded into TigerGraph using a GSQL schema mapping vertices like Customer, Card, Device, Transaction, and BillingRegion, connected by edges such as HAS_CARD, USED_DEVICE, and TRANSACTED_IN.

LangGraph orchestrator: A state machine with an investigator node, a decision node, an evidence-simulation node, and a save-and-close node. The loop matters: the agent makes an initial recommendation, asks for more evidence if it isn't sure, then decides again.

TigerGraph MCP client: The agent doesn't write raw database calls. It retrieves transaction and relationship evidence through the official TigerGraph MCP server, meaning all graph access goes through standard, governed tools.

Gemini: gemini-3.5-flash-lite executes the reasoning over the retrieved evidence and produces the strictly typed JSON verdicts and summaries.

How We Used TigerGraph

TigerGraph performed three critical jobs:

1. Evidence retrieval: Multi-hop questions such as "which other cards share this device?" or "does this billing region fit the customer's history?" are complex graph traversals, not simple table joins. Rather than hardcoding static GSQL, the MCP integration allowed Gemini to dynamically fetch subgraph transaction histories based on the active case context.
2. Grounding: Every claim in the final output points back to specific node IDs in the graph, so a human reviewer can definitively trace a conclusion back to its source data.
3. Case memory: After each investigation, the agent writes the case back into the graph, ensuring future investigations can query that precedent and learn from it.

Uncertainty and Next-Best Actions

The agent doesn't force a yes-or-no answer. When evidence conflicts or the fraud probability falls between 0.30 and 0.70, it securely halts and returns an uncertain verdict.

Each case output records an initial recommendation, a final recommendation after evidence is considered, and a what_changed field explaining why the action stayed the same or shifted. Based on strict organizational rules (Policy R8), high-exposure cases (over $500) or highly uncertain verdicts are immediately escalated to L1 or L2 analysts. The output also autonomously decides whether filing a Suspicious Activity Report (SAR) is legally appropriate based on the exposure threshold.

We also designed the output for non-engineers. Each JSON file contains a plain-language summary, the supporting graph evidence, an array of similar_prior_cases, and the exact recommended action.

Results

• 100% Completion: Investigated all 20 benchmark cases and successfully produced 20 schema-compliant answer files.
• Performance: Achieved an average investigation time of ~50 seconds per case (with full latency metrics recorded natively in the outputs).
• Adaptive Routing: Case HHG-001 successfully surfaced a historic out-of-region fraud pattern, recommending a BLOCK_CARD action routed to L1 (due to low exposure of $77.07).
• Trap Handling: Case HHG-019 triggered our uncertainty threshold, dynamically shifting the verdict to uncertain and escalating to an analyst rather than making a reckless automated decision.

Challenges and Limitations

During heavy multi-tool query loops, we experienced occasional HTTP 500 timeouts when the MCP attempted to pull massive historical precedents simultaneously. To ensure stability for the benchmark run, the current version utilizes a local pandas fallback parsing closed_cases_history.csv for case memory. It keeps precedent retrieval highly reliable for the demo. In a production environment, we would move that memory into a dedicated historical-case vertex in TigerGraph and query it through the same governed MCP layer.

What We Learned

• Model the graph first: Once the data was structured cleanly into nodes and edges, the complex analytical queries became remarkably simple.
• Uncertainty is a feature: Letting the agent say "I'm not sure, I need more evidence" and enforcing a probability trap (0.30–0.70) made the pipeline infinitely more trustworthy than an LLM hallucinating a forced verdict.
• Explainability is part of the product: Fraud reviewers shouldn't have to read Python or interpret raw database dumps to understand a decision.
• Fault tolerance is engineering: Building the exponential backoff logic and the local CSV fallback layer wasn't just a hackathon workaround—it was a masterclass in designing resilient microservices that degrade gracefully instead of crashing.

Try It

git clone https://github.com/OMIZOOMI/tigergraph-fraud-investigation
cd tigergraph-fraud-investigation
python3 -m venv venv && source venv/bin/activate
pip install -r requirements.txt
cp .env.example .env   # add TigerGraph + Gemini credentials
python run_investigation.py