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

TigerGraph Hacker House Goa — Agentic Fraud Investigation Challenge

Team / Co-Authors: Nikhil Kumar Panigrahi & Sai Manohari Godavarty

Live Workstation: https://ravel-u8sl.onrender.com/

GitHub Repository: https://github.com/nikhilkumarpanigrahi/Ravel

Video Walkthrough: 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

Quick Summary: What We Built

For the TigerGraph Hacker House Goa Challenge, my teammate Sai Manohari Godavarty 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:

1. TigerGraph Cloud (release 4.2.5) running compiled C++ GSQL queries for sub-second multi-hop graph traversals.
2. Shannon Entropy Active Learning so the agent mathematically knows when it has enough evidence to stop investigating instead of burning LLM tokens.
3. A 3D Pareto Counterfactual Simulator that balances loss prevention against customer friction.
4. An Automated FinCEN SAR Generator backed by dual-key human approval (L1 Fraud Lead and L2 Risk Manager).
5. An interactive Cytoscape.js graph canvas built directly into the analyst workstation.

Key Results Across 20 IEEE Benchmark Cases

The Investigation: Inside Case HHG-020 and the 125 Dollar Alert

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:

• The transaction amount is 125.08 USD (a standard everyday purchase).
• The real-time risk score is 0.52 (well below typical 0.70 automatic decline rules).
• The cardholder has not filed a dispute yet.

To a tabular system, this alert looks completely normal.

The Hidden Connection

When we ran a 4-hop graph traversal in TigerGraph on Customer C12265, the topology showed something completely different:

[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.

Comparing the Three Investigation Approaches

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  |
+------------------------------+---------------------------------------+--------------------------------------+

Pipeline 1: LLM-Only Baseline

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.

Pipeline 2: Basic Vector RAG

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.

Pipeline 3: RAVEL (TigerGraph GraphRAG)

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.

Performance Comparison Matrix

System Architecture: The Active Learning Loop

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

The 14-State Finite State Machine

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

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.

How TigerGraph is Used: The 100x Speedup Story

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   |
+-----------------------+-----------------------------+----------------------------------+

The Multi-Hop Latency Bottleneck

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

1. Call Customer endpoint to get connected transactions (~350ms).
2. Call Transaction endpoint for 15 individual transactions (~5,250ms).
3. Call Device endpoint to fetch hardware fingerprints (~4,500ms).
4. Query edges to find colluding accounts (~14,000ms).

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.

Compiling GSQL into Native C++

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.

Agentic Capabilities Implemented

1. Mathematical Uncertainty: Shannon Binary Entropy

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).

• When p = 0.50 (Complete Ambiguity): H(S) = 1.00 bit. The agent cannot decide and must collect more data.
• When p = 0.95 (Strong Evidence): H(S) = 0.28 bits. Confidence is high.
• When p >= 0.97 (Defensible Boundary): H(S) <= 0.22 bits. The hypothesis is sufficiently proven and the agent stops querying.

# 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.

2. 3D Pareto Counterfactual Decision Theory

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

• Decline the transaction?
• Block the card permanently?
• Trigger an SMS one-time verification?
• Freeze the account and file a SAR?

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.

3. Automated FinCEN Suspicious Activity Report (SAR) Generation

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.

The Forensic Analyst Workstation UI

Manohari 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:

1. Interactive Cytoscape.js Graph Canvas: Real-time physics layout rendering transactions, cards, devices, and shared collusion rings with one-click ring expansion.
2. Dual-View Navigation: Seamlessly toggle between individual case investigation dossiers and the executive benchmark matrix.
3. State Machine Replay Engine: Re-run investigations on demand with live state transitions and belief shifts.
4. Dual-Key Approval Drawer: Human-in-the-loop sign-off controls for L1 (Fraud Lead) and L2 (Risk Manager) approvals.

Interactive Walkthrough: Try Case HHG-020 Yourself

Click here to expand the interactive case walkthrough

Step 1: Open the Live Deployment or Run Locally

Open the live workstation directly:
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

Step 2: Open Case HHG-020

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

Step 3: Trigger the Investigation

Click "Re-run Investigation".
Watch the active learning progression:

• H(S) starts at 1.00 bit (complete ambiguity).
• The agent executes tigergraph:shared_devices(C12265).
• In 0.238 seconds, TigerGraph returns the 35 connected cards linked through device DEV-91024.
• H(S) drops to 0.18 bits, passing the 0.22 decision threshold.
• The policy engine fires Rule R6 (Block Card) and routes an L1 approval to the analyst drawer.
• The FinCEN SAR narrative is generated automatically with full graph citations.

Official Benchmark Evaluation Results

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

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.

What We Learned

1. Topology Matters More Than Model Parameter Count: A large language model cannot deduce that 35 credit cards share a single device if the database only returns flat rows. Relational graph topology in TigerGraph is what reveals collusion; the language model is best used for reasoning over structured subgraphs, synthesizing evidence, and drafting regulatory filings.
2. Compiled Queries are Essential for Production AI: In agentic workflows where models make sequential tool decisions, high database latency slows the whole pipeline down. Compiling GSQL queries into native C++ reduced multi-hop lookups from 24.4s to 0.238s, making real-time investigation viable.
3. Information Theory Prevents Uncontrolled Agent Loops: Giving an LLM open-ended tool access leads to token waste and circular reasoning. Formalizing stopping boundaries with Shannon Entropy (H(S) <= 0.22 bits) ensures the agent investigates thoroughly when uncertain, but stops immediately once the evidence is clear.
4. Human Oversight is Non-Negotiable in Banking: Financial institutions cannot deploy autonomous systems that block accounts with zero human governance. Gating high-impact interventions behind dual-key L1/L2 approval queues bridges the gap between agentic speed and regulatory accountability.

What We Would Build With More Time

1. Real-Time Kafka Streaming Ingestion: Connect TigerGraph's GSQL loading pipeline directly to an Apache Kafka transaction stream, triggering RAVEL investigations within milliseconds of an authorization request.
2. In-Database Graph Data Science Embeddings: Run TigerGraph Graph Data Science algorithms (such as FastRP, Louvain Community Detection, and Node2Vec) directly in-database to generate dynamic risk embeddings on topology.
3. Two-Way Cardholder Communication Webhooks: Integrate live Twilio webhooks so the agent can dispatch real-time SMS two-factor verification challenges directly to cardholders during active investigations.
4. Distributed Celery Worker Queues: Scale investigation workloads horizontally across a distributed Kubernetes cluster to handle peak transaction spikes during high-volume shopping events.

Team and Engineering Contributions

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.

Launchpad & Quick Links

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