# FraudLens - TigerGraph > Source: > Published: 2026-09-24 20:00:37+00:00 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 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: 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. 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` ↔ `DeviceInfo`, OS, browser, screen resolution).` NEXT_TRANSACTION` (`Transaction` → `CASE_SIMILAR_TO` (`FraudCase` ↔ `CC-0001` through `CC-5565`) to new investigations. **Native GSQL Algorithms (No Python Reimplementation):** `connected_components`:` velocity_burst_detection`:` shared_attribute_ring_detection`:` prior_case_similarity`: **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. Rather than building superficial features, we focused our engineering on three decisive capabilities: 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`. 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)$$ `evidence_request` (e.g. customer verification or step-up authentication), simulates the response, and resumes in Step 6 with Bayesian probability adjustments. 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. Under bank Fraud Policy v1.0, actions must evolve as evidence arrives. Here is how our agent handled **Case HHG-001**: `3514030` ($77.07, billing region 444.0) at `0.61`.` VERIFY_WITH_CUSTOMER` (route: `auto`), `CREATE_CASE` (route: `BLOCK_CARD` (route: `L1`, exposure < $2,500) and `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. Every next-best-action adheres to a strict permission matrix: `ALLOW_TRANSACTION`, `MONITOR_CARD`, `STEP_UP_AUTH`, `CLOSE_NO_FRAUD`).` DECLINE_TRANSACTION`, `L2`` 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`. Running our batch benchmark runner (`python eval/benchmark_runner.py --all`) evaluated all 20 exam cases non-interactively: `graph_case_id` vertices. *Built for TigerGraph × Hacker House Goa 2026 Hackathon.*