Building TRACE: Graph-Based Fraud Investigation with TigerGraph and Gemini

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’m building TRACE, a prototype that brings those pieces together.
The goal is to produce 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, and vector retrieval.
• The official TigerGraph MCP server for exposing graph queries to the investigation pipeline.
• Gemini 2.5 Flash for evidence synthesis and structured assessments.
• A local embedding model for semantic search without hosted embedding API quotas.
• A Python policy engine for action recommendations and approval routes.
• An analyst dashboard for reviewing case evidence, assessments, and proposed actions. The benchmark contains 590,742 transactions, 5,565 closed investigations, and 20 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. The 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 and determines policy routes.
Before exporting an answer, the pipeline writes the investigation to TigerGraph and compares the stored answer with the generated record.
How TigerGraph is used
The graph connects customers, cards, transactions, device profiles, email domains, billing regions, and historical cases.
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 pattern—or a legitimate explanation? 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 the vectors used for semantic retrieval. The embedding model runs locally, but similarity search happens in 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 graph must 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 short cooldowns could not resolve a daily limit. I switched to sentence-transformers/all-MiniLM-L6-v2, running on the local CPU. It produces 384-dimensional vectors, which are stored in a separate TigerGraph vector attribute. Both documents and search queries use the same model. The older Gemini vectors remain separate; vectors from different models are not mixed. Long text is processed in overlapping token windows, then combined into a normalized document vector. This avoids silently discarding the end of a document, although combining windows can dilute specific topics—a trade-off worth improving. The local approach removed the embedding API quota bottleneck. Gemini still handles reasoning and remains subject to its own generation limits. The agentic capabilities implemented so far TRACE produces an initial assessment and can identify a need for additional evidence, such as customer validation or analyst information. For this benchmark, the response can be simulated. That assumption is recorded explicitly, and the final assessment reflects it. The output preserves:
• The initial recommendation before additional evidence.
• The assumed verification response.
• The final recommendation after that response.
• An explanation of what changed.
• The required approval route for each action.
• A stopping reason. The current retrieval sequence is selected by Python rules using the alert’s features. More adaptive, model-directed tool selection is planned. Similarly, the system retrieves supplied historical investigations and writes new investigations into the graph. Retrieving those newly generated records—with safeguards separating simulated conclusions from confirmed outcomes—is still an improvement to complete. What has been verified At the time of writing:

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 vector retrieval	Passed a search smoke test and three exact-vector checks
Official MCP connection	Returned the expected 360 transactions for HHG-001
Complete case export and graph read-back	HHG-001 completed

HHG-001 demonstrates the workflow rather than measured classification accuracy.
Its final fraud assessment depended on a simulated customer denial. The episode exposure was $77.07, with recommendations to block the card through L1 approval and file a report through L2 approval. Neither action was executed.
The complete 20-case run is still being tested. Other cases have exposed request-schema, identifier-validation, and network issues. I have not measured accuracy against the hidden benchmark answers.
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 conversions 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 a JSON envelope inside a Markdown code block. Our initial parser expected plain JSON. Testing the actual server response revealed the mismatch.
Persistence should be checked. Recording that a case was “written to the graph” is meaningful only when the write is verified.
What I would improve with more time
First, I would complete and review all 20 benchmark investigations, including the evidence behind every SAR recommendation.
Next, I would add:

• Adaptive tool selection: choose the next graph query according to the uncertainty remaining.
• Stronger graph-side pattern detection: return explicit transaction sequences and relationship evidence from GSQL.
• Provenance-aware case memory: retrieve earlier generated investigations without treating simulated outcomes as established facts.
• More precise document retrieval: index individual policy chunks rather than combining an entire long section into one vector.
• Time-separated evaluation: compare against a simple baseline using historical outcomes excluded from the investigation context.
• A clearer interactive dashboard: visualize evidence paths and show exactly why recommendations changed. The most valuable part of this project has been learning to distinguish a plausible explanation from a defensible investigation. TRACE is being 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.