Fraud Is a Relationship Problem, Not a Data Volume Problem

Get a demoGet started

Back to blog

Graph Tech

Fraud Is a Relationship Problem, Not a Data Volume Problem<br>By Sabika Tasneem<br>8 min readAugust 11, 2026

Fraud teams rarely fail because they cannot process enough data. They fail because the data is split into isolated events.

A payment can look ordinary on its own. The amount is normal. The customer has a history. The destination account is not brand new. The device fingerprint is not obviously risky. A transaction-level model may let it pass. That is exactly what the problem is.

Coordinated fraud rarely appears as one extreme transaction. For instance, in cases such as authorized push payment fraud, the payment itself can look legitimate even when the surrounding network is not. It appears as a pattern across entities that look harmless in isolation but suspicious in combination. Shared addresses. Reused devices. Accounts one or two hops away from known mule networks. Small transfers moving through the same intermediaries.

This is not a small edge case. In its Annual Fraud Report 2025, UK Finance reported £1.17 billion in total fraud losses in 2024. Authorized fraud alone accounted for £450.7 million in losses. Financial institutions already have plenty of data. The issue is that much of the fraud stack still treats detection as a row-level classification problem when the real signal often sits in the network.

Why Transaction-Level Fraud Detection Falls Short

Most production fraud models are built on tabular features. That makes sense for many tasks. You can score amount, velocity, merchant type, geography, time of day, device changes, chargeback history, customer tenure, and hundreds of other signals. Those features are useful. They just are not enough.

A tabular model asks a narrow question: what does this event look like based on the fields attached to it?

Fraud rings exploit that boundary. They spread activity across accounts, identities, devices, addresses, and time windows so that no single event looks extreme enough to trigger action. The structure carries the signal, not the single row.

That is why teams keep seeing the same painful pattern. A suspicious case gets confirmed. Investigators dig deeper. Then they discover the real issue was not one payment. It was a connected cluster they could only see after the fact. By then, the damage has already spread.

What Tabular Models Miss

Imagine a payment of $480 from a customer account that has been active for years.

Nothing about the transaction looks alarming. The amount is plausible. The transfer falls within the customer’s normal range. The destination account is domestic. The session was authenticated properly. A tabular model might score it as low risk.

Now add the missing context.

The sender shares a mailing address with three accounts flagged in the past month. The destination account received funds from a known mule account two days earlier. One of the sender’s devices has also appeared on an account tied to a prior fraud investigation. Two hops out from the destination account, the funds lead into a small cluster that keeps appearing in past scam cases.

The payment did not become risky because the transaction changed. It became risky because the surrounding network changed what the transaction meant.

That is the core limitation of row-by-row detection. It evaluates an event without enough knowledge of the neighborhood around it.

Coordinated Fraud is Relationship-Based

This is where many fraud strategies break down.

Fraud operations are not random collections of bad transactions. They behave more like adaptive systems. A scammer tests a path, rotates accounts, reuses a phone number, shifts to a fresh device, or inserts an intermediary account to create distance from known flags. One part of the pattern changes. The rest stays connected.

That is why the most important signals in fraud are often relationship-based. You are not just asking whether a payment is suspicious. You are asking questions like these:

Is this account connected to previously flagged entities through one or two intermediaries?

Are multiple identities converging on the same beneficiary?

Are small, low-risk-looking transfers forming a repeated route through the same network?

Is this device appearing across accounts that should not overlap?

Is a new account inheriting a suspicious neighborhood even if its own history looks clean?

Those are not volume questions. They are relationship questions. And relationship questions are hard to answer in systems designed to inspect one record at a time.

Why More Data Does Not Fix the Blind Spot

A common response to missed fraud is to add more features, more history, or more model complexity. That can help at the margin. It does not solve the structural issue. If the model still learns from flattened events, it still has to compress connected behavior into indirect proxies. You end up hoping enough engineered...