How to stop bonus abuse

What it costs you

• trending_downThe bonus itself, paid in cash or credit to somebody who was never going to become a user.
• trending_downThe acquisition budget behind it, because the campaign that looks like it converted at $4 a user actually converted at nothing.
• trending_downYour offer economics with partners, since a network seeing farmed conversions will eventually claw them back or drop the campaign.
• trending_downAnalyst hours, which is the cost nobody budgets for: somebody has to sit and untangle which of last week's 900 signups were real.

How the attack runs

1. 01

   Find an offer worth farming

   The economics have to work for the farmer. A $5 signup bonus with a low completion bar is worth industrialising; a $5 bonus that requires a deposit and thirty days of activity is not. Abusers do this arithmetic before you do.

2. 02

   Solve identity supply

   They need email addresses, and sometimes phones. Disposable domains, catch-all domains they own, and plus-addressing on a single inbox are the cheap end. SMS-receive services are the paid end, and they are cheap too.

3. 03

   Solve network supply

   One address making forty signups is trivially caught, so traffic is spread across proxies. Datacenter ranges are the cheap option and the easy catch. Residential proxy networks route through real consumer connections and do not look like infrastructure, because they are not.

4. 04

   Run the accounts through the funnel

   Often manually at first, to learn the exact minimum that triggers the payout, then repeated. The behaviour is deliberately unremarkable: each account does the least work that qualifies, and nothing else.

5. 05

   Consolidate the payout

   This is the step that is hard to hide. Value has to end up somewhere the farmer controls, so many accounts converge on a small number of payout destinations, wallets, or withdrawal patterns.

The signals that do

These are the signals that carry weight on bonus abuse, and why each one is the signal rather than the obvious alternative. Not all of them are ours: the ones marked you build this genuinely work and Kaidn does not check them, so you would be wiring them up yourself. Listing those unlabelled would read as a claim we cannot support.

Bonus abuse is the fraud people underestimate because no single instance looks like fraud. Nobody stole a credit card. Nobody broke into an account. Somebody signed up, did the thing the offer asked for, and collected what you promised. Forty times.

That is what makes it hard: the individual account is genuinely unremarkable, and any rule strict enough to catch it in isolation will also catch a real user having a normal day.

The unit of detection is not the account#

The mistake almost everyone makes first is trying to decide whether this signup is legitimate, using only what this signup carries. Looked at alone, a farmed account has a working email, a plausible name, a real device, and an IP address belonging to somebody's house.

The abuse is not in the account. It is in the relationships between accounts, and those are only visible if you are holding the other ones. That is why a page of per-account validation rules never holds the line, and why the teams who beat this problem are the ones who started scoring the connections instead of the fields.

Detecting it, concretely#

Two calls, one at registration and one when value moves. The registration call is cheap insurance; the second is where a farm stops looking like forty independent people.

import { Kaidn } from "@kaidn/sdk";

const kaidn = new Kaidn({ apiKey: process.env.KAIDN_API_KEY });

const r = await kaidn.score({
  event: "signup",
  user_id: user.id,
  ip: req.ip,
  email: user.email,
  device_id: body.kaidn_device_id, // from @kaidn/fp in the browser
});

// Do not block a signup on this. Flag it, let them in, and hold the BONUS.
if (r.verdict !== "allow") await flagForBonusHold(user.id, r.reasons);

The reasons worth routing on for this pattern, and what each one is actually saying:

Hold the bonus, not the account#

The block that costs you least is the one on the payout rather than the registration, because a false positive at signup loses a real customer and a false positive on a bonus loses a bonus:

const r = await kaidn.score({
  event: "bonus_claim",
  user_id: user.id,
  ip: req.ip,
  email: user.email,
  device_id: body.kaidn_device_id,
});

// device reuse on ONE network is corroborated; across three it is a household
const corroborated =
  r.reasons.includes("device_reuse") && (r.device?.account_count_same_network ?? 0) > 1;

if (r.verdict === "block" || corroborated) return holdBonus(user.id, r.event_id);
if (r.verdict === "review") return queueForReview(user.id, r.reasons);

return payBonus(user.id);

When the outcome eventually resolves, send it back. A confirmed farm three weeks later is the only ground truth the engine ever gets:

await kaidn.label({ event_id, label: "confirmed_fraud" });

Score the payout, not just the signup#

If you take one thing from this page: the registration is the wrong place to catch reward fraud on its own, because at registration the farmer has told you almost nothing yet.

By the time value moves, they have told you a great deal. They have told you which accounts qualify in the same unusual way, in the same window, through the same networks, and above all where the money is going. Payout convergence is the point at which forty independent-looking accounts stop looking independent.

Scoring both ends costs you a second call and changes what you can see entirely.

Decide what you actually want to happen#

Blocking is not always the right outcome, and treating this as a binary is how good users get hurt.

A large share of these cases are ambiguous: a real user on a shared connection, a returning customer on a new device, a genuine signup that happens to arrive in a burst because you ran an ad. Those belong in review, not in a block, and the difference between a fraud tool you can live with and one you cannot is usually whether it lets you set that threshold yourself.

Ours returns allow, review or block with the checks that fired and their weights, so you can see which signal pushed a user over the line and move that line if it is wrong.

What we would tell you to do first, before buying anything#

Look at your last thirty days of payouts and group them by destination. If a small number of destinations account for a disproportionate share of accounts, you have bonus abuse and you now know its size. That costs nothing and takes an afternoon, and it is a better basis for deciding what to spend than any vendor's estimate, including ours.