Entities and Graphs

In one line: each account looks fine on its own, and the fifty of them sharing a device do not.

Why a per-transaction model is not enough

Organised fraud operates at scale, and scale means reuse. The same device, the same network, the same shipping address, the same payment instrument, the same behavioural template — because doing each attempt from genuinely independent infrastructure is expensive.

That reuse is the signal, and it is invisible to a model scoring one transaction at a time. Each account passes every individual check. Only the relationship between them is anomalous.

Entity resolution first

Before you can link anything you have to decide when two records are the same thing, and that is harder than it sounds.

The same person appears as j.smith@example.com and jsmith@example.com, at Flat 2, 14 High St and 14 High Street Apt 2, with a phone number written three ways. The same device appears with a rotated identifier after a browser update.

The standard approach is layered:

Deterministic matching on exact normalised keys — a canonicalised email, a validated phone number, a hashed card fingerprint. High precision, and it misses variants.

Probabilistic matching on fuzzy comparison across several fields, with a score threshold. Catches the variants, and it introduces false links.

And a false link is worse than a missed one. Merging two unrelated customers into one entity means one person's fraud contaminates a stranger's risk score. Precision matters more than recall here, which is the opposite of the usual instinct in retrieval.

The graph

Nodes are entities — accounts, devices, cards, addresses, phone numbers, IPs. Edges are shared attributes or transactions between them.

Then the useful questions are structural:

Connected components. Follow the shared-attribute edges and see what cluster this account belongs to. A component of three is a household. A component of four hundred is an operation.

Degree. A device with fifty accounts, a phone number on thirty applications, an address receiving orders for a hundred names. High degree on a node that should be low-degree is one of the strongest single signals available.

Density and synchrony. Rings are tightly connected and act together — signing up in the same hour, transacting in the same window, using the same template. A dense component that also moves in time is close to conclusive.

Distance to known fraud. How many hops from this account to a confirmed fraudulent one. Two hops through a shared device is meaningful; six hops through a shared internet provider is noise.

That last qualifier matters. Every account is a few hops from a fraudster through something, so the edge types must be weighted by how much sharing them actually implies. Sharing a device is strong. Sharing a mobile network operator is not an edge at all.

Online versus offline

The practical split, and it is the part most designs get wrong by proposing a full graph traversal inside a payment authorisation.

Offline, on a schedule: entity resolution across the whole population, connected components, cluster scoring, ring identification. Expensive, and it does not need to be fresh to the second.

Online, in the request: a lookup of precomputed graph features for the entities involved — this device's cluster id, that cluster's risk score, this account's degree. A key-value read, not a traversal.

The gap is the freshness problem: a ring formed in the last hour has no precomputed features. Two mitigations. Run incremental updates for the highest-value edge types — a new device-to-account link can be applied immediately rather than waiting for the batch. And keep a small set of online degree counters for the entities that matter most, which are velocity features by another name.

What graphs cost you

Three things worth being honest about.

Guilt by association. A legitimate customer sharing a household device with a fraudster inherits risk they did not earn. This is a real fairness problem, and it argues for treating graph features as inputs to a model rather than as rules — so the model can learn how much a shared device actually implies, in context, rather than a threshold declaring it disqualifying.

Privacy. Linking accounts through shared attributes builds a map of who is connected to whom, which is sensitive by construction and carries data protection obligations well beyond a transaction log.

Cost. Entity resolution and component detection over hundreds of millions of nodes is a substantial batch job, and it needs a genuine payoff to justify. On a small platform, or one where fraud is mostly individual rather than organised, it is over-engineering.

That last point is the judgement to show: graphs pay off when fraud is organised. Card testing rings, promo abuse farms and synthetic identity operations are graph problems. An individual with a stolen card is not, and no amount of graph infrastructure catches them.

Where it wins outright

One case worth naming because nothing else works: promo and incentive abuse. Every signup is a real person with a real email doing something the terms permit. There is no fraudulent transaction to detect. The only anomaly is that four hundred of them share a device fingerprint and signed up within an hour.

A per-account classifier cannot see that by construction, however good it is. This is the clearest example of a fraud problem that is only visible as structure.

Next: why the rules engine never goes away.