# Building RAVEL: Detecting Complex Fraud Rings with TigerGraph Cloud & Agentic GraphRAG

> Source: <https://dev.to/nikhilkumarpanigrahi/building-ravel-detecting-complex-fraud-rings-with-tigergraph-cloud-agentic-graphrag-4711>
> Published: 2026-09-24 16:21:12+00:00

**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<br/>(Risk Score, Denial, Channel)"] --> B["Case Dossier Seeder<br/>(Extract Target and Entity IDs)"]
        B --> C["Prior Belief Baseline<br/>(Compute Initial P0 Fraud)"]
    end

    subgraph ActiveCore ["2. TigerGraph Active Intelligence Engine"]
        C --> D["Shannon Entropy Evaluator<br/>(Quantify Uncertainty)"]
        D --> E{"Is Uncertainty Settled?<br/>H(S) <= 0.22 bits?"}
        E -- "NO: High Uncertainty" --> F["Value of Information (VoI)<br/>Rank Queries: E[Loss] - Cost"]
        F --> G[("TigerGraph Cloud<br/>Compiled C++ GSQL Multi-Hop")]
        G --> H["Bayesian Belief Shift<br/>(Update Posterior Likelihood)"]
        H --> D
    end

    subgraph GovernanceStage ["3. Resolution and Governance"]
        E -- "YES: Decision Ready" --> I["3D Pareto Counterfactual Engine<br/>(Loss vs Friction vs Compliance)"]
        I --> J["Bank Policy Rules (R1-R8)<br/>(Determine Next-Best Action)"]
        J --> K{"Dual-Key Gate<br/>Human Approval Needed?"}
        K -- "High Impact" --> L["Analyst Approval Drawer<br/>(Human-in-the-Loop L1/L2)"]
        K -- "Pre-Authorized" --> M["Action Execution<br/>(BLOCK_CARD, DECLINE_TXN)"]
        L --> M
        M --> N["FinCEN SAR Synthesis<br/>(31 U.S.C. 5318g)"]
        N --> O[("TigerGraph Case Memory<br/>Write-Back FraudCase Vertex")]
    end
```

In banking operations, an AI agent cannot be an unpredictable black box. RAVEL enforces strict deterministic state progression:

``` php
TRIGGERED -> CASE_CREATED -> INVESTIGATING -> EVIDENCE_COLLECTED -> ASSESSING 
-> EVIDENCE_REQUESTED -> EVIDENCE_RECEIVED -> REASSESSING -> POLICY_EVALUATION 
-> ACTION_PROPOSED -> APPROVAL_PENDING -> ACTION_EXECUTED -> CASE_CLOSED -> MEMORY_UPDATED
```

*Caption: The RAVEL 14-State Autonomous Lifecycle Trace — providing deterministic finite state orchestration and an auditable transition log for every investigation.*

If an action involves high financial or customer impact (like freezing an enterprise card or filing a federal report), the state machine halts in APPROVAL_PENDING until an analyst signs off in the workstation drawer.

TigerGraph serves as the primary computational engine in RAVEL. Our graph is hosted on TigerGraph Cloud (release 4.2.5) using the FraudDetectionGraph schema:

```
+----------------------------------------------------------------------------------------+
|                                 TIGERGRAPH GRAPH SCHEMA                                |
+-----------------------+-----------------------------+----------------------------------+
| Vertex Type           | Primary Key                 | Key Attributes                   |
+-----------------------+-----------------------------+----------------------------------+
| Customer              | id (STRING)                 | name, risk_score                 |
| Card                  | id (STRING)                 | card_type, expiration, status    |
| Transaction           | id (STRING)                 | amount, timestamp, channel, score|
| Device                | id (STRING)                 | device_fingerprint, ip_address   |
| BillingRegion         | id (STRING)                 | region_code, risk_multiplier     |
| FraudCase             | id (STRING)                 | verdict, confidence, sar_filed   |
+-----------------------+-----------------------------+----------------------------------+
```

When we first built our prototype on day one, we queried TigerGraph using sequential REST++ endpoint calls:

Total latency per case was 24.44 seconds. Because our agent performs three to four exploratory steps during an investigation, analyzing a single case took over two minutes. That would never work in production.

TigerGraph's core architectural advantage is that GSQL queries can be installed directly into the Graph Processing Engine (GPE), which compiles them into native C++ shared objects:

```
USE GRAPH FraudDetectionGraph

CREATE OR REPLACE QUERY shared_devices(VERTEX<Customer> cust, INT lim = 50) 
FOR GRAPH FraudDetectionGraph SYNTAX v2 {
    C = {cust};

    # Hop 1: Customer -> All Historical Transactions
    Txns = SELECT t FROM C:c -(transaction_of_customer:e)- Transaction:t;

    # Hop 2: Transactions -> Hardware Device Profiles
    Devs = SELECT d FROM Txns:t -(transaction_uses_device:e)- Device:d;

    # Hop 3: Devices -> Other Connected Transactions
    OtherTxns = SELECT t2 FROM Devs:d -(transaction_uses_device:e)- Transaction:t2;

    # Hop 4: Connected Transactions -> Colluding Customers
    OtherCust = SELECT c2 FROM OtherTxns:t2 -(transaction_of_customer:e)- Customer:c2 
                WHERE c2 != cust 
                LIMIT lim;

    PRINT Devs, OtherCust;
}
INSTALL QUERY shared_devices;
```

Running INSTALL QUERY compiles the GSQL procedure into machine code.

The latency improvement was immediate:

```
+---------------------------------------------------------------------------------------+
|                             TIGERGRAPH LATENCY BENCHMARK                              |
+------------------------------------+-----------------------+--------------------------+
| Operation                          | Before (REST++ Loop)  | Now (Compiled C++ GSQL)  |
+------------------------------------+-----------------------+--------------------------+
| shared_devices (4-Hop Ring)        | 24.44 seconds         | 0.238 seconds (100x)     |
| card_window (Time-Windowed Txns)   | 4.10 seconds          | 0.237 seconds (17x)      |
| card_history (Customer Txn Stream) | 4.14 seconds          | 1.207 seconds (3.5x)     |
| Total Case Investigation           | ~166 seconds          | ~39 seconds (4.2x)       |
+------------------------------------+-----------------------+--------------------------+
```

Dropping latency from 24.44 seconds down to 0.238 seconds gave our agent the throughput to perform live multi-hop forensics within real-time SLA limits.

Many autonomous agents run into issues because they lack a defined stopping condition. They either make premature guesses or loop indefinitely calling tools.

RAVEL quantifies hypothesis uncertainty using Shannon Binary Entropy:

```
H(S) = -p * log2(p) - (1 - p) * log2(1 - p)
```

Where `p` is the posterior probability: `P(Fraud | Evidence)`.

``` php
# From src/ravel/domain/services/entropy.py
def calculate_entropy(p: float) -> float:
    """Calculate Shannon binary entropy in bits."""
    if p <= 0.0 or p >= 1.0:
        return 0.0
    return -p * math.log2(p) - (1 - p) * math.log2(1 - p)
```

To choose the next step, our Value of Information (VoI) optimizer ranks potential inquiries:

```
VoI = Expected_Loss_Reduction - Inquiry_Friction_Cost
```

The agent dispatches a query only if the expected drop in uncertainty outweighs the friction cost. Once uncertainty reaches H(S) <= 0.22 bits, the investigation concludes.

When an alert fires, choosing the next best action is not always straightforward:

Blocking cards aggressively hurts customer retention. False positive declines cost banks and merchants more than actual fraud losses.

RAVEL evaluates proposed interventions across a three-way Pareto trade-off space:

```
[Goal 1] MAXIMIZE: Financial Loss Prevented (USD)
[Goal 2] MINIMIZE: Cardholder Inconvenience (Friction)
[Goal 3] MINIMIZE: Regulatory and Compliance Risk
```

Only non-dominated, Pareto-optimal actions move forward to policy evaluation.

Under 31 U.S.C. 5318(g), United States financial institutions are required to document suspicious transactions above statutory thresholds. Drafting these filings manually is one of the most time-consuming parts of an investigator's day.

RAVEL synthesizes structured, audit-ready SAR narratives directly from the verified graph traversal:

```
*** SUSPICIOUS ACTIVITY REPORT (SAR) NARRATIVE ***
FILING INSTITUTION: RAVEL Autonomous Forensic Workstation
SUBJECT: Customer C07297 (Card: C07297-K1)
VIOLATION TYPOLOGY: Card-Not-Present New Device Fraud (Typology R6/R7)
TOTAL EXPOSURE: 1,906.07 USD

CHRONOLOGY & EVIDENCE:
Between 2016-11-21 and 2016-11-22, flagged account executed 5 high-velocity online 
transactions totaling 1,906.07 USD from unverified mobile device profile DEV-482a. 
Customer initiated denial on transaction 3476682 (482.12 USD). 

GRAPH TRAVERSAL AUDIT:
TigerGraph multi-hop neighborhood confirms device conflict: IP geo-location 
mismatches residential billing region 205.0. Prior account history showed 
no antecedent card-present activity within 72-hour observation window.

INTERVENTION & RESOLUTION:
Card C07297-K1 frozen under dual-control L2 authorization (Risk Manager APP-49D12A). 
Case archived to TigerGraph memory graph as vertex RAVEL-HHG-006.
```

Sai led the design and frontend engineering of the Forensic Analyst Workstation, built on an obsidian dark theme:

*Caption: The live RAVEL Workstation displaying case dossiers, interactive Cytoscape.js graph topology, and approval queues.*

Key interface capabilities include:

Click here to expand the interactive case walkthrough

Open the live workstation directly:

[https://ravel-u8sl.onrender.com/](https://ravel-u8sl.onrender.com/)

Or clone and run locally:

```
git clone https://github.com/nikhilkumarpanigrahi/Ravel.git
cd Ravel
uv sync --extra dev
uv run ravel serve --host 127.0.0.1 --port 8000
```

In the left sidebar, click on Case HHG-020 (Customer C12265).

Click "Re-run Investigation".

Watch the active learning progression:

We evaluated RAVEL against all 20 official challenge cases from the IEEE-CIS fraud dataset (case_pack.csv):

| Evaluation Dimension | Challenge Target | RAVEL Empirical Result | Status | 
|---|---|---|---|
| Policy Conformity Rate | >= 90% | 100.0% (20/20 cases aligned to R1-R8) | Complete | 
| Pattern Consistency Rate | >= 90% | 100.0% (Mathematical alignment) | Complete | 
| Evidence Citation Coverage | >= 80% | 100.0% (All findings cite graph paths) | Complete | 
| Total Exposure Protected | Baseline | 4,727.17 USD | Maximized | 
| Compiled GSQL Traversal | < 2.0s | 0.238 seconds | 100x Speedup | 
| Scorecard Replay Latency | < 1.0s | < 0.05 seconds (In-memory rollup) | Instant | 
| FinCEN SARs Filed | As needed | 6 Cases (Fully compliant narratives) | Complete | 
| Automated Test Suite | > 80% | 66 / 66 Passing (100% pytest suite) | Verified | 

*Caption: The RAVEL Executive Benchmark Matrix — full 20-case evaluation proving 100% policy conformity, 4,727.17 USD in fraud exposure protected, and zero hallucinations.*

| Contributor | Focus Area | Key Architectural Deliverables | 
|---|---|---|
| **Nikhil Kumar Panigrahi**[GitHub: nikhilkumarpanigrahi](https://github.com/nikhilkumarpanigrahi) | **Core Engine & Graph Architecture** | Active Learning (Shannon Entropy stop condition), GSQL Query Compilation, Bayesian Belief Updating, 3D Pareto Counterfactual Simulator, and Bank Policy Governance (Rules R1 through R8). | 
| **Sai Manohari Godavarty**[GitHub: saimanoharigodavarty](https://github.com/saimanoharigodavarty) | **Forensic UI & Systems Optimization** | Full-Stack Analyst Workstation, Cytoscape.js Interactive Graph Canvas with dynamic ring layouts, Cloud Latency Tuning, and LangGraph 14-State Machine Workflow. | 

A big thank you to the TigerGraph team for hosting the TigerGraph Hacker House Goa, providing access to TigerGraph Cloud and Savanna, and organizing a challenging, realistic fraud problem.

Tagging @TigerGraphDB on LinkedIn and X.

| Resource | Link | Description | 
|---|---|---|
| **Live Workstation** | [ravel-u8sl.onrender.com](https://ravel-u8sl.onrender.com/) | 24/7 cloud deployment connected to live TigerGraph Cloud | 
| **GitHub Repository** | [nikhilkumarpanigrahi/Ravel](https://github.com/nikhilkumarpanigrahi/Ravel) | Complete open-source codebase (MIT License) | 
| **Video Walkthrough** | [Watch on Google Drive](https://drive.google.com/file/d/1RPplFn7suYCryYVRs8_xCaBcBLqq7cZU/view?usp=sharing) | Full end-to-end investigation and dual-approval walkthrough | 

If you find this project interesting, please star the repository on GitHub and share your thoughts in the comments below!