Signup-bonus abuse: how it works and how to detect it

Signup-bonus abuse is when accounts are opened only to collect a welcome incentive and then leave. Each account on its own passes your checks. Linked by the wallets that fund them and receive their withdrawals, the same accounts form an obvious cluster, and that cluster is where bonus abuse detection has to look.

What is signup-bonus abuse?

Signup-bonus abuse is one actor claiming a new-account incentive many times through many accounts. The offer is meant for one new customer. The abuser opens several accounts, claims the bonus on each, does the minimum needed to unlock a withdrawal, takes the money out and stops.

It sits next to multi-accounting, where one actor runs many accounts for any purpose. Signup-bonus abuse is the version aimed at the welcome offer. Referral abuse is a close relative: the same accounts can also refer each other to collect referral rewards.

In a North America report published in March 2026, based on a survey of 993 online gaming industry decision-makers, LexisNexis Risk Solutions found that 78% of respondents cited bonus abuse as a top threat to their business, more than any other fraud type in the study.

Each account costs you one bonus. That looks small, which is the point. The real cost is the total across every account the same actor runs, and no single account's record shows it.

How does signup-bonus abuse work, step by step?

Signup-bonus abuse follows a short, repeatable script. The actor funds one wallet, spreads it across new accounts, claims the bonus on each, and pulls the money back out. Every step looks normal at the account level.

1. Fund a source wallet. The actor holds the starting funds in one wallet, or a small number of them.
2. Open accounts. Each account gets its own email, phone number and device setup, so signup checks see a new customer every time.
3. Pass verification. Each account clears onboarding on its own merits. Nothing in a single application looks wrong.
4. Deposit from the same source. Each account's deposit address receives a transfer from the source wallet, usually the minimum needed to unlock the bonus.
5. Claim and clear the conditions. The account claims the welcome bonus and does the least activity the terms require before a withdrawal is allowed.
6. Withdraw and exit. Funds go out to fresh addresses that often send onward to one wallet. The account goes quiet and is not used again.

Steps 1, 4 and 6 are where the accounts touch the chain. They are also the steps that account-level checks never connect.

Why do standard checks miss signup bonus abuse?

Standard checks look at one account at a time, and every account in a bonus abuse cluster is built to pass one at a time. The evidence that links them sits outside the account record, in the transfers that fund the deposits and the addresses that receive the withdrawals.

Verification answers whether an applicant's details are valid. It does not ask whether the same actor is funding five other accounts that week. Per-account rules have the same blind spot: a threshold on gain or deposit size is set for one account, and a single bonus claim sits well under it.

Device checks help, but they watch the session, not the money. An abuser who rotates devices, browsers and networks looks like a new visitor each time. More on that gap in why device fingerprinting misses crypto fraud. Chain analytics has the opposite problem: it watches wallets but never the actor behind the accounts.

Each of these tools sees part of the picture. Bonus abuse lives in the part none of them sees: the link between accounts, through the wallets behind them.

What wallet-level signals matter for bonus abuse detection?

The signals that give bonus abuse away are shared money flows and repeated timing, read across a group of accounts rather than one. On its own, any one signal can have an innocent cause. Together, they form a pattern worth reviewing.

• Shared funding. Several deposit addresses receive transfers from the same wallet, close together in time.
• Shared exit. Withdrawals go to addresses that send onward to the same wallet.
• Minimum-path activity. Each account deposits the minimum, does the minimum the bonus terms require, then withdraws.
• Short account life. Accounts go quiet after their first withdrawal.
• Activity elsewhere. When an actor is flagged anywhere in the Addressable network, their risk on your platform rises the same day, before they have done anything to you.

What turns signals into a finding is re-scoring. Once a candidate wallet is surfaced from public on-chain activity, the other wallets and sessions belonging to the same actor are pulled in, and every rule you already run re-runs across the whole group: total gain, deposit addresses, platforms hit. The pattern is then named, and independent signals have to agree before anything is flagged.

Illustrative example: six accounts, one funding wallet

Illustrative example: every number below is invented to show the pattern. It does not describe a real customer, platform or case.

A platform offers a 100% match welcome bonus up to $100. One of its own rules sends an account to review if its net gain in the first week is above $250. Over three days, six new accounts sign up. Each one passes verification, deposits $100, claims a $100 bonus, clears the terms and withdraws.

Account by account, nothing stands out. Now add the wallets. All six deposits were funded by transfers from the same wallet, each sent within two hours of that account's signup. All six withdrawals went to fresh addresses that later sent their funds on to one other wallet.

No single account crosses the $250 rule. The cluster does, at $360, and the shared funding wallet explains why the six belong together. The flag that comes back is named signup-bonus abuse, with the wallets and transfers attached.

What should you do when an account is flagged for signup-bonus abuse?

Treat the flag as a reason to review, never as a verdict on a person. Send it to your review queue, read the reason, check the evidence, then apply the action your own policy sets.

Every flag arrives with a named fraud type, a reason code (for example, R-14) and a reason a person can check, such as "matches a known referral-abuse signature" or "two transfers from a known-risky entity". An analyst can verify it in minutes and act, or clear it. A cleared flag becomes a label we learn from. A flag your team can't verify is a flag they won't use.

A simple review routine:

1. Read the reason. Start with the named pattern and the plain-language reason, not a number.
2. Check the links. Look at the transfers that tie the accounts together and the totals across the cluster.
3. Look for an innocent explanation. A shared funding source can sometimes be a household or a common service. Note what you find either way.
4. Apply your policy. Allow, monitor, hold or deny, as your team has configured for that band.

You set the thresholds, weights and bands, and you choose what each one triggers. Uncertain cases go to your review queue, not to an automatic decision. Before a change goes live, you can test it against the last thirty days in a dry run to see which accounts it would have caught. You can see how this works on the Addressable crypto fraud detection page.