Building RAVEL: Detecting Complex Fraud Rings with TigerGraph Cloud & Agentic GraphRAG A two-person team built RAVEL, an autonomous forensic investigation workstation combining TigerGraph Cloud, compiled GSQL, FastAPI, LangGraph and Cytoscape.js, to detect coordinated payment fraud rings. In benchmarks against 20 IEEE-CIS fraud cases, the system reported 100% ring recovery, 0.0% hallucination, and multi-hop graph traversal in 0.238 seconds versus 24.2 seconds for standard approaches, with 66 of 66 automated tests passing. TigerGraph Hacker House Goa — Agentic Fraud Investigation Challenge Team / Co-Authors: Nikhil Kumar Panigrahi https://dev.to/nikhilkumarpanigrahi & Sai Manohari Godavarty https://dev.to/saimanoharigodavarty Live Workstation: https://ravel-u8sl.onrender.com/ https://ravel-u8sl.onrender.com/ GitHub Repository: https://github.com/nikhilkumarpanigrahi/Ravel https://github.com/nikhilkumarpanigrahi/Ravel Video Walkthrough: https://drive.google.com/file/d/1RPplFn7suYCryYVRs8 xCaBcBLqq7cZU/view?usp=sharing https://drive.google.com/file/d/1RPplFn7suYCryYVRs8 xCaBcBLqq7cZU/view?usp=sharing Core Architecture: TigerGraph Cloud release 4.2.5 , Compiled C++ GSQL, FastAPI, LangGraph, Cytoscape.js For the TigerGraph Hacker House Goa Challenge, my teammate Sai Manohari Godavarty https://dev.to/saimanoharigodavarty and I set out to tackle a problem that fraud analysts deal with every single day: coordinated payment fraud rings. In real-world fraud operations, investigators spend 30 to 45 minutes on every single suspicious transaction. They have to jump across multiple tools, cross-reference IP logs and hardware fingerprints, trace transaction histories across accounts, and draft compliance narratives. By the time someone connects the dots manually, the fraudulent funds have already moved. To fix this operational lag, we built RAVEL Relational Active Valuation and Evidence Loop . It is an autonomous forensic investigation workstation that combines: | Forensic Metric | RAVEL Performance | Standard Tabular / LLM | Impact & Value | |---|---|---|---| | Fraud Exposure Protected | $4,727.17 | $0.00 Undetected | 100% ring recovery across all 20 challenge cases | | Policy Conformity | 100.0% 8/8 Rules | ~65.0% | Zero regulatory or bank policy breaches | | Hallucination Rate | 0.0% | 15.0% | 100% of facts grounded in GSQL graph paths | | Multi-Hop Traversal Speed | 0.238 seconds | 24.2 seconds | ~100x faster retrieval with compiled GSQL | | Automated Test Coverage | 66 / 66 Passing | N/A | Full unit, graph adapter, and state machine tests | To see why graphs are necessary here, look at how standard fraud systems evaluate transactions. Take Case HHG-020 directly from the IEEE-CIS challenge pack: { "transaction id": 3509359, "customer id": "C12265", "card id": "C12265-K2", "amount": 125.08, "risk score": 0.52, "channel": "online" } If you feed this record into standard tabular models like XGBoost or a plain LLM prompt: To a tabular system, this alert looks completely normal. When we ran a 4-hop graph traversal in TigerGraph on Customer C12265, the topology showed something completely different: php Customer C12265 -- Txn 3509359 -- Device DEV-91024 | +-------------------+------------------+-------------------+ | | | | Txn 3508112 Txn 3508189 Txn 3509001 ... 32 More | | | | Card C8891-K1 Card C4412-K3 Card C9901-K1 35 Cards Total Caption: Case HHG-020 — Interactive TigerGraph multi-hop traversal in the RAVEL canvas uncovering the 35-card device collusion ring. That single 125 dollar purchase was part of a coordinated bot operation running across 35 compromised payment cards on the exact same physical hardware device. Traditional databases store transactions in flat rows. Flat tables have no concept of relational topology. If your retrieval mechanism cannot see connections between entities, even the largest language model in the world will miss the fraud ring. You do not need a larger model; you need a graph. To understand the difference in architecture, we benchmarked three common approaches against the same 20 IEEE fraud cases: +-------------------------------------------------------------------------------------------------------------+ | THE THREE INVESTIGATION PIPELINES | +------------------------------+---------------------------------------+--------------------------------------+ | Pipeline 1: LLM-Only | Pipeline 2: Basic Vector RAG | Pipeline 3: RAVEL TigerGraph | | Baseline Prompting | Vector Search + Context Dump | Compiled GSQL + Active Learning | +------------------------------+---------------------------------------+--------------------------------------+ | - Relies on pre-trained bias | - Pulls text chunks by similarity | - Traverses explicit multi-hop edges | | - Zero relational awareness | - High token usage from context bloat | - 100x speedup via compiled C++ GSQL | | - Frequent hallucinations | - Misses multi-customer collusion | - Exact citation and graph paths | | - Fails on complex rings | - Slow and expensive per query | - Deterministic 14-state governance | +------------------------------+---------------------------------------+--------------------------------------+ Here, you pass the transaction JSON to an LLM and ask it whether the transaction is fraudulent. Without external retrieval, the model guesses based on prompt semantics. It hallucinates nonexistent card patterns and cannot legally justify freezing an account or filing a compliance report. Here, transaction histories and customer notes are converted into text chunks and retrieved via cosine similarity. Vector search finds semantic text similarity, not relational topology. Searching for "high velocity electronics purchase" returns dozens of unrelated customers buying gadgets, but it cannot answer: "Find all payment cards used on any device linked to Customer X in the last 48 hours." The prompt gets flooded with irrelevant tokens while the actual ring goes undetected. TigerGraph models entities explicitly as Customer, Card, Transaction, Device, BillingRegion, and FraudCase vertices. The agent queries compiled GSQL procedures on demand, measures hypothesis uncertainty using Shannon Entropy, and backs every finding with an auditable graph path. In 0.238 seconds, TigerGraph isolates the 35-card ring and hands structured evidence to the LLM to draft a formal FinCEN Suspicious Activity Report. | Evaluation Metric | Pipeline 1 LLM-Only | Pipeline 2 Basic Vector RAG | Pipeline 3 RAVEL / TigerGraph | |---|---|---|---| | Multi-Hop Ring Detection | Fails 0% | Fails Vector blindness | Verified 4 hops in 0.238s | | Evidence Citation Coverage | 0.0% | 42.5% Vague text chunks | 100.0% Exact Graph Vertices | | Hallucination Rate | 38.0% | 14.5% | 0.0% Strictly Grounded | | Query Latency | ~2.5s | ~7.8s Vector scan + LLM | 0.238s Compiled C++ GSQL | | Token Cost per Case | Baseline ~1k tokens | High ~9.5k tokens | Controlled ~1.8k tokens | | Regulatory SAR Compliance | None 0% | Partial notes 30% | Fully Compliant FinCEN 31 USC 5318g | | Human-in-the-Loop Governance | None | None | Dual-Key L1/L2 Approval Drawer | Instead of running an open-ended prompt chain that risks looping indefinitely, RAVEL operates an active learning loop guided by a 14-state deterministic state machine: flowchart TD subgraph IntakeStage "1. Alert Intake and Seeding" A "Payment Alert Event