How the attack works
A welcome bonus with a clearable wagering requirement is a priced instrument. Professional bonus abuse is the business of buying it repeatedly at a discount, and at the top end it is genuinely industrialised: recruited document holders, funded cards, and a technical stack whose entire job is to make one operator look like forty customers.
- A fake-browser profile per account (an antidetect browser), each with its own canvas, WebGL, fonts, screen metrics and timezone, kept stable so the account can return and clear its wagering.
- A residential proxy exit per account, ideally in-region, so geolocation agrees with the documents.
- Real identity documents, either rented from willing participants for a cut or bought outright. This is the part that defeats KYC, and it defeats it completely — there is nothing wrong with the documents.
- Payment instruments that match the identity, so deposit-side checks agree too.
Every layer is designed against a control you are required by licence to operate. That is the uncomfortable part: a fully compliant onboarding process is not an obstacle to this attack, and treating KYC as a fraud control is the most common structural mistake in the sector.
Why KYC cannot stop it
KYC answers "is this a real person, and are they who they claim". Against a ring using rented real identities the answer is yes, truthfully, every time. The question that would separate them — "are these forty people actually one operator" — is not an identity question at all. It is a question about infrastructure: the connections and the browser environments the accounts arrive through.
Device fingerprinting would be the natural place to catch it, and fake browsers exist precisely to defeat device fingerprinting. A fresh profile per account is a genuinely new device by every attribute a fingerprint measures.
What the verdict returns
One server call to POST /v1/evaluate at registration and again at first deposit, with your own account ID sent as accountId. Example response for a ring account on a fresh fake-browser profile behind a residential proxy (excerpt):
{
"decision": "block",
"risk_score": 93,
"reasons": [
"proxy_detected",
"antidetect_browser"
],
"network": {
"vpn": false,
"proxy": true,
"datacenter": false,
"tor": false,
"residential": false,
"service": "<proxy service name when known>"
},
"device": {
"antidetect": true,
"automation": false,
"tampering_score": 0.8,
"linked_accounts": 1,
"multi_account": false
}
}There is no separate "residential proxy" reason: when Maskbreak's network intelligence knows the exit, it shows up as proxy_detected, with proxy: true and datacenter: false, and residential reads false whenever proxy is true. An exit it does not know reads residential: true, which means nothing fired on the network side, not that the visit is clean. The proxy and the fake browser are each a block by default on their own; a VPN alone would be review.
device.antidetect is the field KYC has no equivalent for. It does not ask whether the fingerprint has been seen before — it asks whether the browser environment is being managed by a tool built to lie about it, a question that does not depend on the profile's history. Account linking is the opposite case: device.linked_accounts counts how many of your accounts this device has been used with (hashed, never across customers), and multi_account_device joins the reasons only when that count passes one. If each account arrives on a device that looks new, linking has nothing to join and stays at 1, as above; if the ring reuses a profile, the count climbs. By default it is reported, not enforced. device.times_seen is a different number — sightings across all Maskbreak traffic — so do not read it as your account count. If the browser check did not complete, the device block may be absent: treat that as missing evidence, not a pass.
Where to screen, and where not to
Registration and first deposit are the two points worth spending a visitor check on (the bonus claim itself is a good third; see the bonus abuse playbook). Screening every page view of a logged-in session buys nothing and adds latency to a product where latency is a product feature.
On the middle band, hold the bonus rather than the account. A plain VPN returns review, and in this sector VPN use among entirely legitimate players is high enough that refusing on it is a self-inflicted commercial wound. An account that can play with its own money and cannot claim a promotion until a manual check clears is a proportionate answer, and it is also the one your regulator will find easiest to accept.
Start in watch mode: log each decision next to the account and let every registration and deposit continue, then enforce once the log matches what your bonus team already knows. If you change actions on the console's Rules tab, the strictest matching rule sets the decision, even over the engine's block: a multi_account rule set to review turns a ring account's proxy-and-fake-browser block into a review once its device is linked to a second account. Set such a rule to block, or hold the bonus in your own code from device.linked_accounts instead.
The arithmetic
A worked model. Replace the inputs with yours.
| Input | Model value | Yours |
|---|---|---|
| Welcome bonus value | €150 | — |
| Ring accounts cleared per month | 96 | — |
| Expected loss per cleared bonus after wagering | €45 | — |
| Manual review cost per flagged account | €6 | — |
96 × €45 = €4,320 a month in realised bonus loss, or roughly €52,000 a year, before the cost of reviewing them. The third input is the one worth arguing about internally: the headline bonus value overstates the loss, because wagering requirements mean the house edge recovers part of it even from an abuser. In this model the headline number (96 × €150 = €14,400) would make the problem look more than three times its real size, and any decision built on that will be wrong in a predictable direction.
The licensing angle
Bonus abuse is a commercial loss. Two things adjacent to it are not: an account whose real controller is not the person who passed KYC is a beneficial-ownership problem, and coordinated multi-accounting is a recognised money-laundering typology in gambling. That changes who cares about this internally — the evidence that a set of accounts shares infrastructure is a compliance artifact, not just a fraud one, and it is worth retaining as such.
Maskbreak does not replace KYC, AML monitoring or your payment checks. It scores the visit — network and browser — and adds the evidence those controls were never built to see. More on the sector in Maskbreak for gaming and iGaming bonus abuse detection.