Why Vector RAG Isn't Enough for Fraud Detection

By Sabika Tasneem

6 min readAugust 26, 2026

A claim looks normal. The policy is active. The injury is plausible. The payout is within expected range. So why does it still feel wrong?

In fraud detection, the risk rarely sits inside a single document. It shows up in how entities connect across claims, accounts, devices, addresses, and payments. Vector RAG can retrieve similar case notes, but it does not naturally follow those connections.

This blog explains where vector-based retrieval falls short for fraud detection, why relationship-aware retrieval matters, and how graph-based approaches help uncover the evidence patterns that similarity search often misses.

Vector RAG Answers a Similarity Question

A standard vector RAG pipeline turns a query or document into an embedding, retrieves similar chunks, and passes them to an LLM.

This helps fraud teams search faster. For example, an analyst investigating a suspicious auto claim might ask:

“Show me prior claims that mention rear collisions, whiplash, and fast payouts.”

A vector system can retrieve relevant case notes, saving time. But similarity is not the same as evidence.

A claim can be risky because of its connections, not because it resembles past cases. A new claimant may appear ordinary until you examine related addresses, policies, vehicles, payment destinations, and prior claims.

Vector RAG answers:

“What cases look or sound like this?”
Fraud teams often need to answer:
“What is this connected to?”

Fraud Detection Requires Connected Context

Fraud patterns rarely appear in isolation. Consider an insurance claim that looks reasonable on its own. A vector system might retrieve similar cases, but that still leaves the analyst with disconnected text.

Now add context:

The claimant shares an address with other recent claimants.
A vehicle appears in multiple claims under different policies.
Payments route through accounts linked to related individuals.
Incidents occur within a short time window.

The risk comes from shared structure, not similar wording.

The same applies in banking. A payment may look normal until:

The destination account is linked to a known mule network.
The sender’s device connects to other suspicious identities.

Financial Entity Graph.png

The event becomes risky because of its network, not its description.

Graph Traversal Follows Evidence Paths

Graph-based retrieval treats investigations as movement through connected entities.

In this model:

Entities such as customers, accounts, claims, devices, and payments are nodes.
Relationships between them are edges.

This enables questions like:

Which claims share an address?
Which accounts receive payments from related claimants?
Which entities connect to known fraud cases within a few steps?

Instead of retrieving similar text, the system follows evidence paths.

This aligns with how analysts work: tracing connections, identifying patterns, and understanding how entities interact.

Why Multi-Step Reasoning Matters

Fraud rings adapt by rotating identities, accounts, and devices. Direct matches are often insufficient.

Stronger signals appear across multiple steps:

Claimant → shared address → another claimant → prior claim → same payment destination
Transaction → destination account → intermediary → known mule cluster

Multi-Hop Traversal for-Fraud Detection.png

Flat retrieval systems struggle to preserve these paths. Feature engineering can summarize connections, but it often hides the reasoning behind them.

Graph traversal keeps the full path visible, making it easier to understand and explain risk.

Vector RAG Is Not Built for Structural Reasoning

Vector retrieval works well for language-based tasks, such as retrieving case notes, policies, or investigator summaries.

However, it does not capture:

Explicit relationships between entities
Multi-step connections
Network structures like clusters or cycles

These limitations stem from how embeddings represent semantic similarity rather than relationships, as described in the original Transformer architecture paper.

A more effective approach separates roles:

Vector search retrieves semantic context.
Graph traversal retrieves connected context.
The LLM synthesizes both.

What GraphRAG Changes

GraphRAG grounds retrieval in a graph of entities and relationships. For fraud detection, this means retrieving connected evidence before generating an answer. For example, when asked:

“Why is this claim risky?”

A graph-aware system can trace:

Shared addresses across claimants
Overlapping vehicles and policies
Connected payment routes
Repeated patterns in incidents and timing

This produces explanations grounded in actual relationships, not just similar cases. It also supports governance by making the reasoning path transparent.

A Practical Architecture for Fraud AI

An effective fraud AI system combines both approaches:

Vector retrieval for documents and narratives
Graph traversal for structural relationships

The key question is not “vector or graph,” but which parts of the problem are semantic, and which are structural?

Examples:

Semantic: case notes, policies, summaries
Structural: accounts, claims, devices, addresses, payments

Graphrag Workflow.png

Fraud detection requires both, but they must be handled differently.

Real-World Example

In banking, authorized push payment fraud often appears legitimate at the transaction level. The signal emerges in the surrounding network:

Repeated destination accounts
Shared intermediaries
Common transaction routes

Capitec used graph-based features alongside tabular data in its fraud scoring pipeline, processing over 3.5 million records daily. The key insight was the need to preserve and query relationships at scale.

Where Vector RAG Falls Short

Vector RAG struggles when:

Risk depends on multi-step connections
The signal lies in network structure, not wording
The system must explain the reasoning path
Fraud patterns change surface details but reuse infrastructure

Using vector search alone is like analyzing case notes without seeing the link chart.

Wrapping Up

Fraud detection is a connected reasoning problem. Vector RAG helps retrieve relevant documents, but fraud often reveals itself through shared infrastructure, repeated routes, and indirect relationships.

Graph traversal captures these connections. Vector search retrieves what sounds similar, while graph traversal retrieves what is connected.

For fraud detection, the second is often where the real evidence lies.