Refund fraud and serial returners: a device-graph approach

Refund fraud is the category most retailers underinvest in, because it hides inside a metric they want to keep high — return acceptance — and because the losses arrive one claim at a time rather than in a single dramatic chargeback. A serial returner who costs a merchant a few hundred dollars a month doesn't trip any threshold. A thousand of them, coordinated or not, is a line item.

This piece is about detecting the coordinated and semi-coordinated end of that spectrum using a device graph: the structure that links the accounts, payment methods, and shipping addresses a single operator uses to industrialize returns. The audience is fraud and risk teams at e-commerce and marketplace platforms who already run payment fraud controls at checkout and are now looking downstream at the returns funnel.

What counts as refund fraud?

Refund fraud is any return or refund claim that recovers value the customer isn't entitled to, whether through deception or policy abuse. It's a spectrum, and separating the bands matters because the response differs at each.

At the benign end: honest returns. A customer bought the wrong size, the item didn't match the listing, it arrived damaged. This is the cost of doing business and the thing generous return policies are designed to absorb. You do not want to fight this.

In the middle: opportunistic abuse. Wardrobing — buying a dress, wearing it once, returning it. Fit-finder abuse — ordering five sizes intending to return four, at scale, on every order. Serial returning where the return rate is so high the customer is effectively renting inventory. This is individual behavior, usually not coordinated, and the right response is policy: return fees, restocking terms, tighter windows for flagged accounts.

At the organized end: fraud rings. Empty-box claims (report the package arrived empty), did-not-arrive (DNA) claims on delivered packages, false damage claims with recycled evidence, return-the-wrong-item swaps (return a rock, keep the phone), and refund-then-chargeback double dips. These operations run many accounts, cycle payment methods and addresses, and treat the refund flow as a revenue stream. This is where automated detection pays for itself.

The device graph is most valuable against the middle and organized bands, because both share a property the honest band lacks: one operator behind many identities.

Why account-level controls miss serial returners

Account-level controls miss serial returners because the abuse is defined at the person level, not the account level, and a determined abuser controls many accounts. Your return-rate flag on account A says nothing about the fact that accounts A, B, C, and D are the same person on the same laptop, each kept just under the flagging threshold.

This is the same blind spot that multi-accounting detection addresses on the signup side, applied to the returns side. The account is the wrong unit of analysis. An abuser who understands your return-rate threshold will simply distribute their returns across enough accounts to stay beneath it on each one. If your threshold is a 40% return rate, they run five accounts at 35% each. Every account looks acceptable; the operator is returning a third of everything they order.

Email and payment method don't close the gap either. Email is free and infinite. Payment methods are cheap — prepaid cards, virtual cards, and gift cards are abundant, and an organized operation treats a burned card the way a spammer treats a burned domain. Shipping address seems more durable, but reshipper services, package-forwarding addresses, and freight-forwarding warehouses let one operator present dozens of distinct-looking delivery points.

What survives across all of this is the hardware and network environment the operator actually works from. They can rotate the email, the card, and the address on every order, but they are still sitting at a finite set of devices on a finite set of networks. The device graph is the join key that the account data deliberately withholds.

How a device graph links the pattern

A device graph links refund abuse by resolving every account, order, and claim back to the device and network environment that produced it, then exposing the clusters where one hardware footprint fans out across many identities. It's the same underlying device graph analysis used for account linking, oriented at the returns problem.

The starting point is a stable device identifier that survives the operator's evasion attempts. Cookies won't do it — they're cleared between accounts by anyone doing this deliberately. A device fingerprint built from browser, hardware, network, and behavioral signals produces an identifier that persists across cleared storage, incognito sessions, and fresh account creation. (The mechanics of building that identifier are covered in how device fingerprinting works; the short version is that it's a probabilistic match across many signals, not a single stored token.)

With a persistent device identifier attached to every account and every claim, the graph edges that matter for refund fraud become visible:

One device, many accounts. A single device fingerprint associated with five, ten, or fifty accounts is the primary structural signal. A household sharing a family computer produces two or three linked accounts; a serial-return operation produces dozens, and the accounts have correlated return behavior.

Many payment methods, one device. The inverse edge. When ten different cards — different BINs, different names — all transact from the same device, the "different customers" story collapses. Legitimate shared devices see a small, stable set of payment methods; abuse operations churn through them.

Address clustering by device. Reshipper and forwarding addresses look unrelated in the address field but converge on the same device fingerprints. The graph reveals that "twelve customers shipping to twelve addresses" is one operator whose packages all route through the same forwarding warehouse, ordered from the same two laptops.

Behavioral correlation across the cluster. Accounts in a device cluster don't just share hardware — they share behavior. Similar order timing, similar product categories, similar return reasons entered in similar language. A cluster where every account files "item arrived damaged" claims at a 30% rate is not a coincidence.

The output isn't a single fraud score. It's a linked structure: this claim comes from an account that belongs to a cluster of eleven accounts on three devices that have collectively filed forty-two return claims worth a known dollar amount, with a return rate far above baseline. That structure is what makes a manual reviewer's decision fast and defensible.

Where to score: order time or claim time?

Score at claim time. Refund fraud reveals itself in the return, not the purchase, and scoring at claim time means you decide with the full context of the account's — and the cluster's — return history rather than guessing at checkout.

At order time you know very little that's predictive of refund abuse. The order looks normal; the payment authorizes; the item ships. Blocking at order time on device-cluster suspicion means blocking legitimate purchases from people who happen to share a device, which is a bad trade — you lose real revenue to prevent a return that might never come.

At claim time, the picture is complete. You know the account's return rate, the cluster's return rate, the specific claim type (a DNA claim on a delivered-and-signed package is categorically different from a wrong-size return), and whether this device cluster has a history of the same claim type. This is also where the abuse is expensive: an empty-box or DNA claim on an organized ring is a direct cash loss, and it's exactly the claim type that a device-linked history exposes.

Practically, that means running the smart signals and device-graph lookup as part of the returns and claims workflow, not only at checkout. The verdict feeds a graded response rather than a binary block:

• Low risk: auto-approve the refund. The vast majority of returns. Don't add friction to honest customers.
• Elevated risk (individual abuse pattern): move the account to a stricter policy tier — return fees, evidence requirements, shorter windows — without accusing anyone. Wardrobing and serial returning are policy problems, and policy is the proportionate tool.
• High risk (organized-ring signals): route to manual review with the full device-cluster context attached. Require proof of the claim (photos, carrier confirmation). Hold the refund pending review rather than auto-issuing.

The device graph doesn't make the final call on any single claim. It makes the reviewer's context complete, and it turns a stream of individually-innocent-looking claims into a legible pattern.

What device signals matter most for returns abuse

The signals that discriminate refund abuse are the ones that reveal one operator behind many identities and one environment behind many claims — device linkage, network context, and behavioral consistency across a cluster.

Device linkage is the foundation, as described above: the persistent identifier that connects accounts, cards, and addresses. Without it, nothing else in the graph is anchored.

Network context adds a second dimension. The IP intelligence layer distinguishes a residential connection from a data center, a VPN, or a residential proxy. Organized return operations frequently work from hosting infrastructure or rotate through proxies to make their accounts look geographically diverse — and that infrastructure is itself a signal. An account cluster that shares a device and also transacts from proxy IPs is a stronger pattern than device linkage alone.

Behavioral consistency is the third. Claims from a genuine returns operation carry linguistic and procedural fingerprints — the same phrasing in return-reason fields, the same claim types, the same timing relative to delivery. When a device cluster's claims are behaviorally uniform, that uniformity is evidence of a single hand.

The reason to combine these rather than rely on any one: each is independently evadable, but coherence across all of them is hard to fake. An operator can spoof a device signal, or route through a residential proxy, or vary their claim language — but doing all three consistently across dozens of accounts, on every order and every claim, is expensive enough that it stops being profitable. That's the same environmental-coherence principle that underlies device intelligence generally, applied to the specific economics of returns.

What this changes operationally

Adopting a device-graph view of returns changes three things. First, the unit of analysis shifts from the account to the operator, which is the only level at which serial returning is even visible. Second, refund decisions gain history — a first-time claim from an account in a long-lived abusive cluster is treated with the context the cluster provides, not as a blank slate. Third, the response becomes graded and defensible: policy tiers for individual abuse, manual review with evidence for organized rings, and no added friction for the honest majority.

None of this requires accusing customers or hard-blocking returns. It requires knowing which claims come from the same hands, and treating a coordinated pattern differently from an isolated one.

Tracio provides the persistent device identity and device-graph linkage this approach depends on — a stable visitor identifier that survives cleared cookies and fresh accounts, network context from IP intelligence, and the smart signals that surface account-to-device and payment-to-device clustering. The verdict and the underlying signals return in under 50ms at the point of the claim, with the linked cluster available for the reviewer.

Want to see how a device graph exposes serial returners in your own returns data?

Start your free trial — 2,500 verifications free, no credit card required. Book a demo to walk through refund-fraud detection against your specific returns funnel and policy model.