FraudLens - TigerGraph

Atharva — Thu, 24 Sep 2026 20:00:37 +0000

Building an Autonomous GraphRAG Fraud Investigation & Next-Best-Action Agent with TigerGraph

A deep-dive into graph-native financial crime investigation, evidence-sufficiency gating, and self-updating institutional memory.

Author: Team Hacker House Goa 2026

Stack: TigerGraph Savanna · GSQL & Native Algorithms · Model Context Protocol (MCP) · LangGraph · Claude / Anthropic · FastAPI · React & Tailwind

1. Executive Summary: Moving Beyond "Is Fraud" Labels

In real-world banking operations, transactions do not arrive with an "Is Fraud" label. What institutions actually have is an ocean of high-velocity authorizations, imperfect heuristic risk scores from ML models, and fragmented customer reports.

Traditional rules engines and isolated machine learning classifiers suffer from two fatal failure modes:

High False Positive Rates: Legitimate cardholders making unusual travel purchases or high-ticket electronics purchases get their cards blocked abruptly, causing customer churn and reputational harm.
Blindness to Syndicates: Sophisticated card-testing rings and account takeover gangs deliberately keep individual transaction scores low (e.g. $1–$3 authorizations) while distributing operations across dozens of cards and synthetic identities.

To solve this, we engineered an Autonomous GraphRAG Fraud Investigation & Next-Best-Action System powered by TigerGraph Savanna as the system of record. Instead of relying on static thresholds or dumping uncurated rows into an LLM prompt, our agent executes an 8-step inspectable state machine that traverses graph topology, gathers multi-hop evidence, measures uncertainty, pauses to request additional validation, and recommends regulatory actions with complete auditability.

2. How TigerGraph Powers the Solution

TigerGraph is not used as a passive database; it serves as the computational heart of the entire investigation workflow:

System of Record for Topology:
The FraudGraph schema exposes relationships that make fraud rings visible at the storage layer:
- SHARED_DEVICE_PROFILE (Customer ↔ Customer): Direct undirected edge connecting customers whose transactions share hardware fingerprints (DeviceInfo, OS, browser, screen resolution).
- NEXT_TRANSACTION (Transaction → Transaction): Temporal chains allowing instant detection of rapid-fire micro-authorizations.
- CASE_SIMILAR_TO (FraudCase ↔ FraudCase): Weighted edges linking past closed cases (CC-0001 through CC-5565) to new investigations.
Native GSQL Algorithms (No Python Reimplementation):
- connected_components: BFS label-propagation running inside TigerGraph to partition the customer network into syndicate clusters.
- velocity_burst_detection: Sliding-window query identifying Rule R5 card-testing patterns (3+ authorizations < $5 within an hour).
- shared_attribute_ring_detection: Discovers multi-card sharing across common devices or regional clusters.
- prior_case_similarity: Multi-factor memory retrieval computing similarity over shared entities, patterns, and dollar exposures.
TigerGraph MCP Tool Interface:
All interactions between the LangGraph agent and the graph occur through typed Model Context Protocol (MCP) tool wrappers. Every call is structured, validated, and logged to tool_call_log.jsonl with millisecond latency tracking.

3. The Three Chosen Differentiators

Rather than building superficial features, we focused our engineering on three decisive capabilities:

Differentiator A: Graph-Native Fraud-Ring Detection

Fraud syndicates frequently rotate cards and synthetic identities, but they reuse physical devices, emulators, and connection endpoints. By executing native connected component queries across SHARED_DEVICE_PROFILE and SHARED_CARD edges, our system maps entire criminal rings in single-hop graph traversals. When an alert fires on a single card (e.g. HHG-014), the agent automatically identifies all connected cards in the cluster and applies MONITOR_CONNECTED_CARDS.

Differentiator B: Explicit Evidence-Sufficiency Gating with Confidence Scores

The agent does not blindly jump from trigger to verdict. It computes an atomic confidence score based on the weighted sum of factual evidence:
$$\text{Confidence} = \min\left(1.0, \frac{\sum w_i}{2.0}\right)$$

If $\text{Confidence} \ge 0.70$ or stopping conditions are met: The agent proceeds directly to action formulation.
If $\text{Confidence} < 0.70$ on an uncertain case: The investigation genuinely pauses at Step 4, emits an evidence_request (e.g. customer verification or step-up authentication), simulates the response, and resumes in Step 6 with Bayesian probability adjustments.

Differentiator C: Self-Updating Institutional Memory

When an investigation closes, the system persists the verdict, exposure, and findings as a FraudCase vertex and writes CASE_SIMILAR_TO edges to historical cases. Subsequent investigations query this memory. In the final case dossier, previous cases are explicitly cited:

"Consistent with prior pattern seen in Case CC-0141 (confirmed out-of-region use, $268.43)."
This ensures that lessons learned from earlier cases visibly boost future confidence and prevent repeat investigation cycles.

4. The "Before vs After" Next-Best-Action Dynamic

Under bank Fraud Policy v1.0, actions must evolve as evidence arrives. Here is how our agent handled Case HHG-001:

Initial Alert: Real-time model scored transaction 3514030 ($77.07, billing region 444.0) at 0.61.
Initial Recommendation (Before Verification):
- Under Rule R1, because the case rested on a single model signal with probability below 0.70, blocking the card would be a policy breach.
- Initial Actions: VERIFY_WITH_CUSTOMER (route: auto), CREATE_CASE (route: auto).
Evidence Request: Agent requested customer validation: "Customer states they did not make this purchase and still has the card."
Final Recommendation (After Verification):
- Denial increased fraud probability from 0.24 to 0.52.
- Under Rule R2, action escalated to BLOCK_CARD (route: L1, exposure < $2,500) and CREATE_CASE (route: auto).
- SAR Gating: Exposure ($77.07) was below the $1,000 threshold with no shared device; SAR was correctly gated out (sar.file = False).

Conversely, in Case HHG-010 ($1,000.03 online), customer denial triggered an automatic Suspicious Activity Report (SAR) filed under FinCEN 31 CFR 1020.320 and routed BLOCK_CARD to L2 manager review.

5. Policy-Driven Governance & Action Protection

Every next-best-action adheres to a strict permission matrix:

auto: Actions executable directly by the AI agent (ALLOW_TRANSACTION, MONITOR_CARD, VERIFY_WITH_CUSTOMER, STEP_UP_AUTH, CREATE_CASE, CLOSE_NO_FRAUD).
L1: Requires Level-1 Team Lead sign-off (DECLINE_TRANSACTION, BLOCK_CARD when exposure $\le \$2,500$).
L2: Requires Level-2 Fraud Manager sign-off (BLOCK_CARD when exposure $> \$2,500$, BLOCK_ALL_CARDS, FILE_REPORT).

The downstream mock-action-service enforces this cryptographically: any attempt to execute an L1 or L2 action without an authenticated approval_event_id is immediately rejected with a logged policy citation in permission_log.jsonl.

6. Results on the 20 Benchmark Cases

Running our batch benchmark runner (python eval/benchmark_runner.py --all) evaluated all 20 exam cases non-interactively:

Pass Rate: 20 / 20 Cases (100% Schema & Logic Compliance)
Average Latency: 0.01s / case
SAR Precision: Exactly 2 cases generated regulatory filings (HHG-010 for $1,000+ exposure; HHG-014 for multi-card syndicate ring), while 18 were safely gated out.
Graph Persistence: 20/20 cases written to TigerGraph with assigned graph_case_id vertices.

7. Key Learnings & Future Enhancements

GraphRAG vs. Raw RAG: Dumping hundreds of Vesta feature columns into an LLM context creates hallucination and latency. Pre-aggregating graph topology into structured evidence sections (Baseline, Syndicate Context, Prior Memory) cut prompt tokens by 75% while dramatically improving reasoning accuracy.
Deterministic Gating: Giving the LLM an explicit numerical uncertainty threshold (0.70) forced the agent to behave like a cautious human investigator rather than a trigger-happy classifier.
Future Roadmap: Integrating streaming transaction graphs via Kafka directly into TigerGraph Savanna, and deploying Graph Neural Networks (GNNs) directly on TigerGraph Cloud for automated inductive link prediction.

Built for TigerGraph × Hacker House Goa 2026 Hackathon.

DEV Community: Atharva