Building TRACE: An Agentic Fraud Investigation System with TigerGraph and Gemini

Krapnshiii — Fri, 25 Sep 2026 06:26:31 +0000

A fraud alert tells you where to look. It does not tell you what happened.

An unfamiliar device profile, an unusual transaction, or a high risk score can justify an investigation. But deciding what to do requires context: the customer’s history, connected activity, previous investigations, and the policy governing the next action.

For the TigerGraph Agentic Fraud Investigation challenge, I built TRACE, a prototype agentic fraud investigation system that brings those pieces together.

TRACE produces an explainable investigation record: what evidence was considered, what remains uncertain, whether more information is needed, and which actions require human approval.

What I Built

TRACE combines:

TigerGraph for transaction relationships, historical cases, investigation memory, and vector retrieval.
The official TigerGraph MCP package for exposing controlled graph queries to the investigation pipeline.
Gemini 2.5 Flash for evidence-grounded reasoning and structured assessments.
Local embeddings using sentence-transformers/all-MiniLM-L6-v2 for semantic search without hosted embedding API quota issues.
A Python policy engine for action recommendations, SAR decisions, validation, and approval routes.
An analyst dashboard for reviewing evidence, findings, decisions, and proposed actions.

The benchmark contains:

590,742 transactions
5,565 closed investigations
13,553 customers
20 fraud alerts to investigate

The system is a prototype. Customer responses can be explicitly simulated, and actions such as blocking a card or filing a report remain recommendations. TRACE does not execute banking actions.

Architecture

The investigation flow is:

Benchmark CSVs
   ↓
Local preparation and reference checks
   ↓
TigerGraph entities, relationships, and vector indexes
   ↓
Evidence retrieval through official TigerGraph MCP
   ↓
Gemini initial assessment and simulated verification, when needed
   ↓
Deterministic policy recommendations and approval routes
   ↓
Output validation
   ↓
Investigation written to TigerGraph and read back
   ↓
Case JSON and analyst dashboard

Local preparation creates an indexed staging database for loading and validation. The original source CSVs remain unchanged.

TigerGraph supplies the relationship evidence. Semantic retrieval adds relevant historical narratives and policy material. Gemini interprets that context, while Python calculates exposure, validates grounding, applies policy, and determines approval routes.

Before exporting an answer, the pipeline writes the investigation to TigerGraph and compares the stored answer with the generated record. That read-back check makes graph persistence a verified step rather than just a log message.

How TigerGraph Is Used

The graph connects customers, cards, transactions, device profiles, email domains, billing regions, historical cases, investigations, and supporting documents.

These relationships support questions such as:

What activity preceded the flagged transaction?
Has this customer used the same billing region before?
Which transactions share a device profile?
What historical investigations are relevant?
Does the surrounding activity support the suspected fraud pattern or a legitimate explanation?

Installed GSQL queries retrieve these relationships within defined time windows.

Transaction evidence is bounded by the alert’s opening time. Historical case outcomes are eligible only after those cases have closed. This prevents the investigation from using future outcomes as if they were already known.

TigerGraph also stores vectors used for semantic retrieval. The embedding model runs locally, but similarity search happens inside TigerGraph.

A Difficult Modeling Decision: Card Identity

The transaction file does not directly provide card IDs.
Some card assignments are explicit in the supplied case references. Additional assignments are inferred by matching customer, card network, and card type against those references.

TRACE preserves the distinction between explicit assignments and inferred relationships. Transactions that cannot be resolved remain connected to their customers without an invented card ID.

This matters because a useful investigation graph should expose uncertainty rather than hide it behind apparently precise relationships.

Why I Moved Embeddings Onto My Computer

The initial implementation used Gemini’s embedding API. Indexing stopped when the free-tier daily quota was exhausted.
Repeated cooldowns could not resolve a daily quota limit, so I moved semantic embeddings to a local model: sentence-transformers/all-MiniLM-L6-v2.

It produces 384-dimensional vectors, which are stored in a separate TigerGraph vector attribute. Both documents and search queries use the same local model. The older Gemini vectors remain separate, because vectors from different models should not be mixed.

Long text is processed in overlapping token windows and combined into a normalized document vector. This avoids silently discarding the end of a document, although combining windows can dilute very specific topics. That is a trade-off I would improve with more precise chunk-level retrieval.

The local approach removed the embedding API quota bottleneck. Gemini still handles investigation reasoning and remains subject to generation limits.

Agentic Capabilities

TRACE produces an initial assessment and can identify when additional evidence is needed, such as customer validation or analyst follow-up.
For this benchmark, a response can be simulated. That assumption is recorded explicitly, and the final assessment reflects it.

Each output preserves:

The initial recommendation before additional evidence is requested
The assumed verification response, when used
The final recommendation after that response
An explanation of what changed
The required approval route for each action
SAR filing when required by policy
A stopping reason
A graph persistence receipt

The current retrieval sequence is selected by Python rules using the alert’s features. A future version would move more of this into adaptive LLM tool selection.
Similarly, TRACE retrieves supplied historical investigations and writes new investigations into the graph. A future improvement would make newly generated investigations searchable as memory for later cases, while keeping simulated conclusions separate from confirmed outcomes.

Final Results

TRACE completed all 20 benchmark fraud investigations.
Each investigation produces:

An internal case record
Grounded graph and historical evidence
Findings, risk indicators, and a final decision
A fraud probability and estimated exposure
The next best action and approval route before requesting evidence
A final action and approval route after receiving additional evidence
A suspicious activity report when required by policy
A graph persistence receipt confirming that the investigation was written back to TigerGraph

All 20 JSON answer files passed structural validation and live TigerGraph read-back verification.

The final agent verdict distribution was:

17 fraud cases
3 legitimate cases

Verification Summary

Check	Result
Transaction count reconciled	590,742
Historical case count reconciled	5,565
Customer count reconciled	13,553
Flagged transaction attributes checked	All 20 alerts
Local vectors uploaded	5,565 historical cases and 13 documents
Native TigerGraph vector retrieval	Verified
Official TigerGraph MCP connection	Verified
20 answer files generated	Complete
Live graph read-back	Passed
Automated tests	85 passing tests

What I Learned

A shared device profile is a lead, not proof. A browser and operating-system configuration can be common across many customers. Shared configurations or billing regions alone do not establish coordinated fraud.

Identifiers need precise contracts. During testing, the model sometimes placed customer IDs in card-ID fields or used device descriptions where graph IDs were required. Explicit validation and exact-match conversion helped catch those errors.

Structured output still needs validation. Valid JSON does not guarantee valid evidence, correct policy application, or a supported conclusion.

Integration details matter. The official MCP server returned responses in a format that required careful parsing. Testing against the actual server response helped uncover those mismatches.

Persistence should be checked. Recording that a case was “written to the graph” is meaningful only when the write is verified through read-back.

What I Would Improve Next

With more time, I would add:

Adaptive tool selection so the agent chooses the next graph query based on remaining uncertainty
Stronger TigerGraph-native pattern detection for transaction sequences, fraud rings, and community structures
Provenance-aware case memory so new investigation records can be retrieved later without treating simulated outcomes as confirmed facts
More precise document retrieval by indexing policy and narrative chunks separately
Analyst feedback loops for improving recommendations over time
Benchmark evaluation when labelled answers become available
A richer dashboard with visual evidence paths and clearer before/after recommendation changes

The most valuable part of this project was learning to distinguish a plausible explanation from a defensible investigation.

TRACE is built around that distinction: evidence first, explicit uncertainty, and actions governed by policy.

Built for the TigerGraph Agentic Fraud Investigation challenge with @TigerGraphDB and @247pmstudio.

Code:Github Repository

DEV Community: Krapnshiii