How return fraud rings link accounts (and how to spot them)
Per-account return scoring catches the lone abuser. It misses the ring, because the ring entire strategy is to never look like one account. A dozen accounts each returning twice a month stays under every per-account threshold while moving serious volume. The defense is entity resolution: linking accounts into rings and scoring the ring.
The good news is that rings are lazy in predictable ways. Shared infrastructure leaves traces, and the traces are the same ones fraud teams have used for years. The work is connecting them at return time, not after the money is gone.
Why rings evade per-account scoring
Every per-account control has a threshold: return rate above X, refund value above Y, claims above Z. A ring operator knows this, either from experience or from testing, and distributes activity to stay under each line. Ten accounts at 15 percent return rates look like ten slightly enthusiastic customers. One account at 150 percent gets banned on day one.
The economics favor the ring as long as accounts are cheap. Guest checkout, disposable emails, and prepaid cards make new identities nearly free. Any defense that treats each account as an independent customer is playing the wrong game. The unit of analysis has to be the cluster, not the account.
The linking signals that matter
Shipping addresses are the richest signal. Rings reuse addresses, use slight variations of the same address, or cluster in the same buildings and neighborhoods. Fuzzy address matching, normalization, unit-number stripping, catches what exact matching misses. An address that receives returns for eight "different" customers is not eight customers.
Devices and payment instruments come next. Shared device fingerprints across accounts, the same card funding multiple accounts, the same phone number on different names: each is a thread, and rings pull several at once. No single signal is conclusive, which is why the graph matters more than any one edge.
Building the account graph
Entity resolution is a graph problem. Accounts are nodes; shared addresses, devices, cards, emails, and phone numbers are edges. Connected components are candidate rings. This does not require exotic tooling: a nightly job over the returns database finds most of it, and real-time checks at return-request time catch the rest.
Weight the edges. A shared apartment building is weak evidence; a shared device fingerprint is strong. Score clusters by edge strength and return behavior together: a tight cluster with high combined return value is the priority. Review the top clusters weekly, and let confirmed rings train the automated rules.
Timing patterns that give rings away
Rings operate in campaigns. Look for bursts: multiple linked accounts requesting returns within hours, identical items returned across accounts in the same week, or return requests that follow the same diurnal pattern. Honest customers are uncorrelated; rings are synchronized.
Seasonality amplifies this. Holiday return windows are ring season, because high legitimate volume provides cover. Tighten cluster review cadence in January, and treat sudden new-account clusters with shared attributes as guilty until proven innocent during peak. The cost of a false positive review is far lower than the cost of a missed ring.
Return fraud rings beat per-account controls by design, so the defense has to think in clusters. Build the account graph from addresses, devices, and payment instruments, weight the edges, and score the ring instead of the account. The signals are all in data you already have. The work is connecting them before the refunds go out, not after.