How we built Shadow Network Intelligence — a GraphRAG-powered fraud investigation platform that proved why topology-aware retrieval outperforms traditional RAG for financial crime investigations.

Introduction

Most retrieval systems are built around documents.

Financial crime investigations are not.

Fraud networks, laundering chains, shell company ecosystems, mule accounts, and intermediary ownership structures do not exist as clean paragraphs inside a single document. They exist across:

• transactions
• shared devices
• addresses
• shell corporations
• account transfers
• ownership chains
• hidden intermediaries
• multi-hop relationships

Traditional retrieval systems can retrieve text.

But financial investigations are fundamentally about reconstructing relationships.

That realization became the foundation for our TigerGraph GraphRAG Inference Hackathon project:

Shadow Network Intelligence

A topology-native intelligence platform built to prove one thing:

Traditional retrieval preserves documents.

GraphRAG preserves relationships.

Or more simply:

The answer is an edge, not a sentence.

The Problem with Traditional Retrieval

Most modern AI retrieval systems rely on semantic similarity.

That works well when:

• the answer exists inside a chunk
• semantic similarity is enough
• relationships are shallow
• the retrieval target is local

But financial crime investigations behave very differently.

The answer often emerges only after reconstructing:

• multi-hop ownership chains
• indirect transaction flows
• hidden intermediary entities
• shell-company cascades
• device-sharing patterns
• ring structures
• laundering topology

In these situations:

semantic similarity alone breaks down.

A chunk may contain a clue.

But the relationship continuity between clues disappears.

That is the core limitation of VectorRAG.

Our Hypothesis

We hypothesized that:

• PureLLM systems would hallucinate or miss hidden structural relationships
• VectorRAG systems would retrieve partial clues but fail to reconstruct topology
• GraphRAG systems would recover hidden investigative structure through graph traversal

To test this properly, we needed:

• adversarial datasets
• relationship-dense ecosystems
• hidden rings
• multi-hop structures
• topology-aware benchmarks

Not simple Q&A datasets.

Building the Dataset

We built a synthetic financial crime ecosystem specifically designed to stress retrieval systems.

The generated graph included:

• 6,000 people
• 5,000 companies
• 10,000 accounts
• 150,000+ transactions
• shared devices
• shared addresses
• ownership structures
• hidden fraud rings
• intermediary laundering chains

Final graph scale:

The important part was not scale alone.

It was:

Structural density.

We intentionally designed adversarial investigation scenarios where:

• topology mattered
• intermediary entities mattered
• chunk retrieval failed structurally
• graph traversal became necessary

Architecture Overview

The platform evolved into a full operational intelligence environment.

1_data_engine/
├── synthetic fraud generation
├── topology-aware ecosystems
├── adversarial benchmark generation
└── ingestion pipelines

2_baseline_systems/
├── PureLLM baseline
├── VectorRAG baseline
└── benchmark orchestration

3_graph_intelligence_core/
├── TigerGraph integration
├── GraphRAG traversal
├── topology-aware retrieval
└── structural expansion

4_orchestrator_api/
├── FastAPI orchestration
├── SSE investigation streaming
├── benchmark APIs
└── cognitive orchestration

5_agent_swarm/
├── retrieval analyst
├── topology investigator
├── sanctions tracer
└── fraud ring analyst

6_reasoning_engine/
├── grounded claims
├── contradiction detection
├── confidence scoring
└── explainability

7_reporting_engine/
├── operational reports
├── markdown exports
└── benchmark summaries

8_dashboard_ui/
├── operational workspace
├── graph investigation UI
├── benchmark comparison
└── cognitive reasoning surfaces

Why We Chose TigerGraph

This project required:

• high-performance traversal
• multi-hop exploration
• topology-native reasoning
• relationship continuity
• structural neighborhood expansion

TigerGraph became the backbone of the entire intelligence system.

We used TigerGraph to:

• reconstruct hidden ownership chains
• detect fraud rings
• traverse laundering paths
• surface intermediary entities
• expand graph neighborhoods
• support topology-aware retrieval

The graph became:

not just storage,

but the reasoning substrate itself.

Building the Benchmark

One of the biggest goals of the project was to avoid fake benchmark theater.

We wanted:

real adversarial evaluation.

So instead of asking simplistic questions, we built investigation tasks such as:

• tracing hidden ownership cascades
• reconstructing laundering paths
• identifying hidden ring members
• detecting intermediary shell structures
• recovering topology continuity

Each investigation was executed across:

1. PureLLM
2. VectorRAG
3. GraphRAG

inside the same operational environment.

The Results

The benchmark results became the strongest validation of the project thesis.

Structural Recall

GraphRAG successfully reconstructed:

• hidden rings
• intermediary chains
• ownership topology
• laundering paths
• multi-hop relationships

while the other systems failed structurally.

And importantly:

this was not a tuning failure.

Vector retrieval fundamentally lacks topology.

A chunk cannot retrieve an edge that no longer exists.

The Most Important Realization

During development, one insight became impossible to ignore:

The answer was never hidden in a document.

It was hidden in the relationships.

That single realization completely shaped the rest of the platform.

Building the Cognitive Layer

We wanted the system to do more than retrieve graph neighborhoods.

We wanted:

grounded investigative reasoning.

So we added a cognitive reasoning layer capable of:

• structural claim synthesis
• contradiction detection
• confidence scoring
• evidence grounding
• entity explanation
• topology-based justification

Most importantly:

we intentionally prevented fake AI theater.

The reasoning system:

• validates real graph IDs
• rejects hallucinated entities
• lowers confidence when evidence is weak
• grounds every structural claim in topology

One of the most satisfying moments was watching the sanctions tracer correctly return:

low confidence.

Not because the system failed.

But because:

there genuinely was no sanctions evidence in the graph.

That honesty made the platform feel operationally credible.

Real-Time Investigation Streaming

To make investigations feel operational, we built a real SSE-driven orchestration flow.

Investigations stream live events such as:

• entity discovered
• ring reconstructed
• hidden relationship surfaced
• neighborhood expanded
• reasoning synthesized
• report finalized

Importantly:

these were not fake loading animations.

The events reflected:

real graph state transitions.

The Frontend Philosophy

At first, we built a conventional dashboard.

It quickly felt wrong.

Financial investigations are not spreadsheet experiences.

So the frontend evolved into:

an operational intelligence environment.

We built:

• Worldspace continuity
• TacticalRail navigation
• investigation-first layouts
• graph-native interaction flows
• cognitive reasoning surfaces
• operational benchmark visualization

The UI was intentionally designed to feel:

calm,
focused,
and structurally investigative.

Not flashy.

The Biggest Engineering Challenge

Ironically, the hardest problem was not graph traversal.

It was:

credibility.

Late in development, we realized something important:

A visually impressive system is meaningless if judges cannot trust the metrics.

So we performed a full credibility hardening pass.

We:

• removed fake benchmark routes
• eliminated synthesized frontend metrics
• surfaced real TigerGraph counts
• exposed reproducible benchmark artifacts
• clearly labeled synthetic vs live surfaces
• ensured every visible benchmark number traced back to real JSON artifacts

This completely changed the maturity of the platform.

The system stopped feeling like:

“a cool hackathon UI”

and started feeling like:

an actual reviewable intelligence platform.

The Final Platform

By the end of the project, Shadow Network Intelligence supported:

• live TigerGraph integration
• GraphRAG retrieval
• adversarial benchmarking
• cognitive reasoning
• topology-aware investigation
• multi-agent analysis
• grounded structural claims
• operational reporting
• live SSE investigation streaming
• graph-native UI workflows
• real benchmark reproducibility

The platform evolved far beyond what we originally planned.

What We Learned

The biggest lesson was surprisingly simple:

AI retrieval systems fail when relationships matter more than text.

That is exactly where graphs become essential.

We learned that:

• semantic similarity is not structural intelligence
• topology changes retrieval fundamentally
• graph traversal enables hidden relationship recovery
• operational credibility matters more than visual complexity
• grounded reasoning is more valuable than theatrical confidence

Most importantly:

we learned that:

GraphRAG is not just “RAG with a graph.”

It is a fundamentally different retrieval philosophy.

Final Thought

Traditional retrieval systems search for relevant documents.

Graph-native systems reconstruct hidden structure.

And in fraud investigations:

structure is the investigation.

That became the foundation of Shadow Network Intelligence.

And ultimately:

the answer was never a sentence.

It was an edge.

Tech Stack

• TigerGraph
• FastAPI
• React + TypeScript
• LangGraph
• Ollama
• ChromaDB
• Docker
• SSE Streaming

Join the Discussion

• Have you found semantic similarity to become a bottleneck in relationship-heavy RAG systems?
• How are you handling multi-hop topology reconstruction in your own GraphRAG pipelines?

We will use the Azure Portal (GUI) to launch an Ubuntu Linux Virtual Machine (VM).

Note: Azure charges by the minute while your VM is running. Don’t forget to delete everything at the end so you pay nothing (or just pennies).

Step 1: Create Your Resource Group
Think of a Resource Group as a folder that will hold your VM and all its related parts. Creating it first keeps things organized.

Sign In: Log into the Azure Portal.

Create a Resource Group:

Click + Create a resource in the top left corner.

Type “Resource Group” in the search bar and select it.

Click Create.

Name it MyLinuxLab_RG

Select a Region close to you (e.g., East/West US)

Click Review + create → Create

Quick Definition: A Region is the physical location of the data center where your cloud resources will live.

Step 2: Create the Ubuntu Linux VM
Now that your folder (Resource Group) is ready, let’s build the actual Linux computer.

Basics Tab:

Resource Group: Select MyLinuxLab_RG from the dropdown

Virtual Machine Name: Ubuntu-Lab-01

Region: Choose the same region you used for your Resource Group

Availability Options: Leave as “No infrastructure redundancy required” (fine for learning)

Image: Confirm it says Ubuntu Server 22.04 LTS (or newer)

Size: Choose Standard_B2s — it’s cost-effective and perfect for learning or the default.

Administrator Account:

Authentication type: Select password

Username: azadmin (or a name you’ll remember)

Quick Definition: SSH (Secure Shell) is the secure “door” that lets you type commands into your Linux VM from your own terminal. The key pair is like a digital lock and key.

Inbound Port Rules: Under “Public inbound ports,” ensure Allow selected ports is checked Http Port 80 and SSH (22) is selected as we move forward we will learn more together.

Click Review + create → wait for the green “Validation passed” message → Click Create

Note: Don’t worry if you see yellow warnings — those are usually fine. Look for the green checkmark.

To ensure that your terminal section does not go off. Click the IP address ensure you extend the time under networking.

Step 3:
Click Connect which would enable you remotely login to the Linux VM:

For windows you would need to open/launch Powershell and For Mac you would open/launch Terminal and run the ID and Ip given.
Now you see my powershell on my windows prompting for Password.

Next: We would login in as a root user which is the same as an administrator in Windows.
“sudo su” and run “apt update” which is to ensure that the latest update is installed.

Step 4: We would install the ntp package – also know as the package manager. “ntp install nginx”

This shows we did login in successfully and we can also remotely login using other options.

Step 5:
Remember to delete.

If this help you in any way kindly share. If you did like to spice up this beginner guide in the comment section I did love that.

The Aha Moment

During Epoch 1 of #100DaysOfSolana, I hit a wall. I’d built wallets, sent transactions, decoded data — but nothing clicked until I stopped thinking about Solana like traditional programming and started thinking about it as a system where everything is an account.

When I started learning Solana, I kept hearing this phrase: “everything is an account.” It sounded like philosophy. But then it hit me: there are literally no users, no wallets, no programs in Solana — only accounts. Your wallet is an account. The Token Program is an account. The system clock is an account. Even your SOL balance is just data in an account.

This single concept unlocks everything else on Solana.

What Is an Account? The Five-Field Structure

Every account on Solana has exactly five fields:

{
  lamports: 5000000,           // Balance (1 SOL = 1 billion lamports)
  data: [0x00, 0x01, ...],     // Binary data (up to 10 MB)
  owner: "11111111111...",     // Program that can modify this account
  executable: false,            // Is this a program (true) or data (false)?
  rent_epoch: 18446744073709... // Rent exemption status
}

That’s it. Five fields. Everything on Solana fits into this model.
This is a real account (System Program) showing all five fields. You’ll see this exact structure for every account on Solana.

Understanding Each Field

lamports – The account’s balance in the smallest unit. Accounts must hold enough SOL (lamports) to be “rent-exempt” (roughly $0.02-$2 depending on data size). This prevents network spam. I built a rent calculator and went deeper on storage costs in my Week 2 post if you want the full breakdown.

data – Where the actual information lives. For a wallet, this is empty (0 bytes). For a program, this is bytecode. For a token mint, this is token metadata (supply, decimals, authorities). For a sysvar, this is cluster state.

owner – The program that has permission to modify this account’s data. Your wallet is owned by the System Program (11111111111...), so only the System Program can transfer your SOL. A token mint is owned by the Token Program, so only it can mint new tokens.

executable – A boolean flag. If true, this account contains program code and can execute instructions. If false, it’s just a data account.

rent_epoch – A legacy field from when Solana charged rent monthly. Now mostly ignored, but technically tracks when rent was last collected.

Three Account Types: Wallets, Programs, and Sysvars

Let me show you how the same five-field structure represents completely different things:
Same five fields, three completely different meanings. This is the power of the account model.

Type 1: Your Wallet (A Data Account)

Owner:      11111111111111111111111111111111  ← System Program
Executable: false                              ← Stores data, not code
Data:       (empty, 0 bytes)
Lamports:   5000000000                         ← Your SOL balance
Rent Epoch: 18446744073709551615 (max)         ← Rent exempt

This is what your wallet looks like on-chain: owned by System Program, no data, just lamports.

Your wallet is a System Program-owned account with empty data. The “balance” is just the lamports field. That’s it.

Your wallet is a System Program-owned account with empty data. The “balance” is just the lamports field. That’s it.

Key insight: You don’t own your wallet — the System Program does. The System Program enforces the rules that only the private key owner can transfer SOL. Your keypair is the authorization mechanism, not the owner — if this distinction feels fuzzy, I covered how Solana identity and keypairs actually work in my Week 1 post. This is what “custody” means on Solana: the program is the enforcer.

Type 2: The Token Program (An Executable Account)

Owner:      BPFLoaderUpgradeab1e...          ← BPF Loader (manages programs)
Executable: true                              ← Contains program code
Data:       (36 bytes of bytecode)            ← The actual program logic
Lamports:   ~11 SOL                           ← Program's retained SOL
Rent Epoch: 18446744073709551615              ← Rent exempt

Address: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
👆 Notice: executable=true, balance is 11+ SOL, owned by BPF Loader. This is a program account.

The Token Program is an executable account. Its data field contains the program bytecode that defines how tokens work. When you interact with a token (mint, transfer, burn), you’re actually calling instructions in this program.

Key insight: Programs are just data stored in accounts. The Solana runtime reads the executable: true flag and knows to execute that account’s code. This is why upgrading programs is so clean on Solana — you’re just swapping the data in an account.

Type 3: Clock Sysvar (A System Data Account)

Owner: Sysvar1111111111111… ← Sysvar program
Executable: false ← Stores data, not code
Data: (40 bytes of binary time data) ← Current slot, epoch, timestamp
Lamports: ~1 SOL ← Enough for rent exemption
Rent Epoch: 18446744073709551615 ← Rent exempt
Address: SysvarC1ock11111111111111111111111111111111

This sysvar is readable by every program but not executable. It contains cluster time state.

Why This Matters: Three Real-World Scenarios

The Clock sysvar is a read-only data account containing cluster-wide state. Every program can read the current slot, epoch, and Unix timestamp from this account. It’s like /proc/uptime in Linux — a public system file anyone can read.

Key insight: Sysvars are how programs access external state without making RPC calls. The Solana runtime updates them every slot.

Scenario 1: Sending SOL to a Friend

When you send 1 SOL to a friend:

1. Your wallet account (owned by System Program) loses 1 billion lamports
2. Your friend’s account gains 1 billion lamports
3. The System Program enforces that only your keypair can authorize this

Both accounts follow the same five-field structure. The only difference is the keypair that can sign for them.

Scenario 2: Creating a Token

When someone creates a USDC token:

1. They invoke the Token Program (an executable account)
2. The Token Program creates a new account for the token mint
3. That new account has the Token Program as its owner
4. The Token Program stores token metadata in the mint account’s data field

Same five-field structure. Different owner (Token Program instead of System Program).

Scenario 3: Reading the Network Time

Inside a program, you might read the current slot:

const clockSysvar = await connection.getAccountInfo(CLOCK_ADDRESS);
const decodedClock = parseClockData(clockSysvar.data);
console.log(`Current slot: ${decodedClock.slot}`);

You’re just reading the data field of an account. Solana’s runtime automatically updates that account every slot.

The Permission Model: Who Can Modify What?

Here’s the crucial rule: Only the account’s owner program can modify its data.

• If owner === SystemProgram, only the System Program can change this account
• If owner === TokenProgram, only the Token Program can change this account
• If owner === YourProgram, only your program can change this account

This is Solana’s security model. You can’t hack someone else’s account because you don’t own it. You can’t create tokens because you don’t own the token program. You can only modify accounts your program owns.

Exception: Anyone can send SOL to any wallet. The System Program allows this because receiving SOL doesn’t modify the wallet’s data field — it only changes lamports. Specifically, the System Program says: “Any keypair can increase another account’s lamports, but only the keypair owning an account can decrease it.”

That’s a Solana transaction at its core — accounts changing state, programs enforcing the rules. If you want to understand how that transaction lifecycle actually works and how it differs from a REST API call, I went deep on it in my Week 3 post.

The Account Model in Action: Building an Explorer

To prove this, I built a simple account explorer that queries any address and shows all five fields:

// solana-account-explorer/explorer.mjs
import { createSolanaRpc, address } from "@solana/kit";

const rpc = createSolanaRpc("https://api.devnet.solana.com");

async function inspectAccount(addressString) {
  const acct = address(addressString);

  const [balance, accountInfo] = await Promise.all([
    rpc.getBalance(acct).send(),
    rpc.getAccountInfo(acct).send()
  ]);

  console.log(`Address: ${addressString}`);
  console.log(`Lamports (Balance): ${Number(balance.value)}`);
  console.log(`Owner: ${accountInfo.value?.owner}`);
  console.log(`Executable: ${accountInfo.value?.executable}`);
  console.log(`Data Length: ${accountInfo.value?.data.length} bytes`);
  console.log(`Rent Epoch: ${accountInfo.value?.rentEpoch}`);
}

// Try it:
// node explorer.mjs 11111111111111111111111111111111

This tool runs the exact same query on System Program, Token Program, and a wallet. Same structure, different values.

Run this on any Solana address, and you’ll see those five fields. Every account. Always the same structure.

Common Misconceptions

❌ “Wallets are real objects”

✅ Wallets are just accounts with the System Program as owner and empty data. The “wallet” concept is a UI abstraction.

❌ “I own my wallet”

✅ The System Program owns your wallet. Your keypair is the authorization mechanism, not the owner. This is actually safer — you can’t accidentally delete your wallet.

❌ “Programs can access any account”

✅ Programs can read any account (it’s all public data), but they can only modify accounts they own. This is enforced by the Solana runtime.

❌ “The blockchain stores all your data”

✅ The blockchain stores account states. Your actual data lives in those accounts. Different mental model!

Everything Else Is Just Accounts (Seriously)

Once the five-field structure clicks, everything else becomes obvious:

• Transactions – Signed instructions that modify accounts. A transaction is just a request to change the lamports or data field.
• Programs – Executable accounts that enforce the rules for modification. They’re the gatekeepers.
• Tokens – Just accounts owned by the Token Program. The token’s supply, decimals, authorities? All in the account’s data field.
• NFTs – Same structure. Metadata lives in the account’s data. The blockchain isn’t storing the image; it’s storing a pointer in an account.
• Wallets – Accounts owned by System Program with no data.
• DeFi – Programs managing accounts representing liquidity pools, positions, swaps. Every protocol is just accounts + programs enforcing rules.
• AMMs – Programs that maintain accounts for token reserves and user positions.

All of it. Accounts and the programs that manage them.

What to Do Next

1. Explore it yourself

   • Go to Solana Explorer
   • Search for any address
   • Look for those five fields

2. Try the inspector

   solana account 11111111111111111111111111111111

This shows you a real System Program account.

1. Build your own reader

   const connection = new Connection("https://api.devnet.solana.com");
   const accountInfo = await connection.getAccountInfo(publicKey);
   // Now you have: lamports, data, owner, executable, rentEpoch

1. Understand ownership
   When building a program, remember: you own accounts your program creates. You can modify them. Users’ wallets you can’t modify (only System Program can). This shapes how you architect everything.

## The Takeaway

The Solana Account Model is deceptively simple: five fields, one permission rule. That’s the entire foundation.

Everything on Solana — wallets, programs, tokens, NFTs, liquidity pools, governance, system clocks, rent — fits perfectly into this structure. There’s no special case for “smart contracts” or “user accounts.” No complexity hidden in different data structures. Just five fields, repeated across millions of accounts, with one rule controlling who can modify them.

Master this concept, and you’ve unlocked the mental model for understanding not just Solana, but why Solana is architecturally different from every other blockchain.

Next time someone says “everything is an account,” you’ll understand exactly why they’re right — and why that matters.

Series: The Account Model Foundation

• Part 1: The Account Model Explained (this post)
• Part 2: Building an Account Explorer (coming May 17)
• Part 3: Decoding Account Data (coming May 19)
• Part 4: System Program Deep Dive (coming May 21)

What aspect of the account model confused you most? Let me know in the comments — I’ll update this post with clarifications!

Part of the 100 Days of Solana Epoch 1 challenge.