How the attack works
A creator funding platform has a property that attracts laundering specifically: money goes in from many small payers and comes out to a nominated payee, with a delay in between and a plausible reason for the flow. If the ring controls the campaign, it controls both ends.
- A campaign the ring controls, or a real creator recruited or impersonated.
- Backer accounts at volume, each with its own email, name and residential proxy exit.
- Stolen cards spread thin — many small pledges rather than a few large ones, sized under the thresholds that trigger review.
- A payout that clears before the disputes do, which is the whole point. The dispute window is measured in weeks; the payout schedule usually is not.
Each pledge scores as low risk on its own, and it is genuinely low risk on its own. The risk lives in the coordination, which per-transaction scoring is not built to see.
Why per-transaction scoring misses it
A transaction risk model asks whether this payment looks wrong: amount, velocity for the card, geography, past behaviour of the instrument. A ring is careful about exactly those, and the amounts are small by design.
What would give it away is the answer to a different question — do these two hundred unconnected backers share anything? Not card, not email, not address, all deliberately distinct. What they do share is how they arrived: the proxy networks, the browser environments, the device population. That is one layer below where payment scoring looks.
What the verdict returns
Screened at pledge with POST /v1/evaluate, passing your own account id as accountId so the linkage stays scoped to you. Example response (excerpt) for a backer on a residential proxy exit in a fake browser, on a device already seen with other backer accounts:
{
"decision": "block",
"risk_score": 93,
"reasons": [
"proxy_detected",
"antidetect_browser",
"multi_account_device"
],
"network": {
"vpn": false,
"proxy": true,
"datacenter": false,
"tor": false,
"residential": false,
"service": null
},
"device": {
"antidetect": true,
"automation": false,
"tampering_score": 0.8,
"linked_accounts": 17,
"multi_account": true
}
}A residential proxy shows up as proxy_detected with network.proxy true; residential is false whenever a proxy is detected, and service names the operator when known. The proxy and the fake browser are what make this a block by default.
linked_accounts is the field that can turn two hundred strangers back into one operator, when the ring reuses devices. It counts how many of your accounts a device has been seen with — stored as one-way hashes and never linked across customers — and it is on the pledge request rather than weeks later in a dispute report. multi_account_device does not change the decision on its own. To act on it, set a multi_account action on the console’s Rules tab. A rule changes the decision only for the signal it names, so “Multi-accounting = Review” sends an otherwise clean linked device to review and leaves this proxy and fake-browser visit blocked.
Where to put the decision
At pledge, and again at payout. The pledge check stops the money going in; the payout check is the one that saves you, because it is the last moment before an irreversible transfer.
Hold rather than refuse on review, and be careful how it is communicated. The person on the other end of a false positive is frequently the creator, not the fraudster, and a creator whose campaign is frozen with a generic message is a public-relations event as well as a support ticket. Tell them what is held, why, and when it clears.
The arithmetic
A worked model. Replace the inputs with yours.
| Input | Model value | Yours |
|---|---|---|
| Quarterly pledge volume | €1.6M | — |
| Dispute rate during the ring's activity | 4.1% | — |
| Share already paid out before disputes landed | 80% | — |
| Dispute fee per case | €18 | — |
€65,600 disputed in the quarter, of which €52,480 had already left as payouts and is unrecoverable from the creator in practice. Fees add on top of that.
The compounding term is the ratio again: at a dispute rate in this range a processor's monitoring programme applies, bringing per-dispute fees, reserve requirements and in the worst case account termination. For a platform that cannot process payments at all without that relationship, the ratio is an existential number and the loss is merely an expensive one.
Why coordinated rings are a different problem
Opportunistic fraud is a distribution of unrelated individuals, and per-transaction scoring handles it reasonably. A ring is one actor wearing many costumes, and it is characterised by things no single transaction contains: shared infrastructure, timing structure, and a lifecycle — ramp up, harvest, disappear before the disputes arrive.
Detecting it therefore means asking what a set of sessions has in common, not what one payment looks like. Network and device signals are the layer where the commonality survives, because it is the layer the ring has to reuse in order to operate at all.