CaseGuard: Winning with Uncertainty-Gated Agentic Fraud Investigation on TigerGraph

A team built CaseGuard, an autonomous AI fraud investigator that combines TigerGraph, GSQL, GraphRAG and agentic reasoning to investigate suspicious transactions, gather extra evidence when confidence is low, recommend next-best actions and generate FinCEN SAR narratives. The system uses native GSQL queries for graph computation while an uncertainty gate defers to customer verification or step-up authentication instead of guessing, and closed cases are written back into the graph as institutional memory. Evaluated against all 20 official Hacker House Goa benchmark cases, CaseGuard reported 100% schema and policy compliance, correct fraud-typology identification and calibrated auto, L1 and L2 approval routing.

🚨 Introduction Traditional fraud systems often make a simple fraud vs. legitimate decision from static thresholds or risk scores. But real fraud investigations are rarely that simple. A transaction can look suspicious because of a new device, unusual geography, or rapid small payments — while still being completely legitimate. That is why we built CaseGuard: an autonomous AI fraud investigator designed to know what it doesn't know. CaseGuard combines TigerGraph, GSQL, GraphRAG, and agentic reasoning to investigate suspicious transactions, gather additional evidence when confidence is low, recommend the next-best action, generate SAR narratives, and remember previous cases. 🏗️ Architecture The CaseGuard workflow is: Alert → TigerGraph Analysis → Fraud Pattern Detection → GraphRAG Policy Grounding → Uncertainty Gate → Evidence Gathering → Next-Best Action → SAR Generation → Case Memory TigerGraph acts as the cognitive spine of the system. Our graph contains entities such as: Customer Card Transaction DeviceProfile BillingRegion ClosedCase InvestigationCase These entities are connected through relationships such as OWNS, MADE, FROM DEVICE, BILLED IN, and INVOLVES. ⚡ How We Used TigerGraph Instead of asking an LLM to perform complex graph calculations, CaseGuard uses native GSQL queries. The card window query analyzes transaction windows to detect rapid micro-authorizations followed by larger spending. The device neighbors query expands through shared devices to discover connections between multiple accounts. In benchmark case HHG-014, the graph revealed one Android device connected to 52 customer cards. The region burst query compares transaction geography against a customer's historical behavior to identify suspicious out-of-region activity. 🧠 Uncertainty-Gated AI One of our main ideas is simple: If the system isn't confident, it shouldn't guess. For example, if an alert is based only on a moderate risk score, CaseGuard does not immediately block the customer. Instead, it follows policy and requests additional evidence, such as: Customer verification Step-up authentication Transaction confirmation This creates a safer investigation workflow instead of relying on a single signal. 🔄 Next-Best Action CaseGuard generates recommendations at two stages. Before Evidence The system may recommend: ALLOW + VERIFY WITH CUSTOMER or DECLINE + STEP UP AUTH After Evidence If evidence confirms fraud, the recommendation can evolve into actions such as: BLOCK CARD CREATE CASE FILE REPORT with appropriate approval routing such as auto, L1, or L2. 🧠 TigerGraph Case Memory CaseGuard doesn't forget completed investigations. Every closed case is stored back into TigerGraph using the insert case vertex query. For example, when HHG-012 generated an out-of-region alert, CaseGuard retrieved a previous case containing legitimate travel history for the same cardholder and used that information to clear the alert. This turns previous investigations into institutional memory. 📄 Automated SAR Generation When a case meets the required reporting conditions, CaseGuard can generate a structured FinCEN Suspicious Activity Report SAR narrative. This helps investigators move from detection to documentation without manually reconstructing the entire investigation. 📊 Results We evaluated CaseGuard against all 20 official Hacker House Goa benchmark cases. Our documented results included: ✅ 100% schema and policy compliance ✅ Correct identification of multiple fraud typologies ✅ Calibrated auto, L1, and L2 approval routing ✅ Case-memory retrieval for previous investigations 💡 What We Learned The biggest lesson was the importance of separating graph computation from LLM reasoning. TigerGraph handles the deterministic relationship and graph analysis, while the AI layer focuses on interpreting structured evidence and making policy-grounded decisions. We also found that storing investigation outcomes directly in the graph provides useful entity-level memory for future investigations. 🚀 Future Improvements With more development time, we would add: Real-time streaming using Kafka/Redpanda. Community detection using graph algorithms such as Louvain or WCC. Interactive analyst co-pilot with conversational investigation capabilities. 🏁 Conclusion CaseGuard demonstrates how TigerGraph + GSQL + GraphRAG + Agentic AI can work together to create a more explainable and evidence-driven fraud investigation workflow. Instead of simply asking: "Is this transaction fraud?" CaseGuard asks: "What evidence do we have, what don't we know, and what should we do next?" That's the idea behind CaseGuard — an investigator that knows what it doesn't know. 🕵️♀️⚡