FraudLens - TigerGraph A team of developers built FraudLens, an autonomous GraphRAG fraud investigation and next-best-action agent that uses TigerGraph Savanna as its system of record, combining native GSQL algorithms with a LangGraph state machine and Model Context Protocol tool wrappers. The system runs an 8-step inspectable workflow that traverses graph topology for multi-hop evidence, gates actions on a computed confidence score, and persists verdicts as FraudCase vertices with CASE_SIMILAR_TO edges to build self-updating institutional memory. In a demonstration case, the agent escalated from VERIFY_WITH_CUSTOMER to BLOCK_CARD and CREATE_CASE as evidence accumulated. 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.