Fraud scoring for rewards sites and offerwalls

What to score, and why these

Scoring everything is expensive and scoring the signup alone misses most of it. These are the events that carry the loss in rewards and offerwalls.

The patterns you will see

Rewards platforms have a structural problem most fraud tooling was never designed around.

The fraud is not a theft. It is a payout you agreed to make, to a user who did the thing you asked, who happens to be the same person as thirty other users.

Nobody used a stolen card. Nothing was broken into. Each account, looked at on its own, did exactly what the offer required.

Score the withdrawal#

The most useful change most reward operators can make is to move detection from the signup to the cashout.

At registration you have an email, an IP and a device, and a farmed account looks like a new user because it is a new user.

At withdrawal you have weeks of behaviour, a completion history, and above all a destination. Many accounts sending money to a small number of places is the single strongest signal in this vertical, and it does not exist at signup.

It is also where blocking is cheap and reversible. Refusing a suspicious cashout costs you a support ticket. Sending it costs you the money permanently.

The loss that arrives twice#

What makes reward fraud more expensive than it first looks is the reversal cycle.

A fake conversion pays you. You credit the user. The user cashes out. Weeks later the network reverses the conversion because the advertiser rejected it.

You have now lost the payout you already sent and the revenue that was funding it. And your reversal rate looks worse in the partner's dashboard for the next negotiation.

That second effect is the one to protect. A bad invalid-traffic rate is a commercial problem with your networks long after the individual money is gone, and it decides which offers you get access to next.

Fraud you can afford, and fraud you cannot#

Not all of this is worth chasing. The honest position is that some abuse is a cost of doing business.

Somebody gaming one offer for a few dollars is annoying and not worth an engineer's afternoon. A ring running forty accounts into one wallet is worth stopping today.

The difference is concentration, and concentration is only visible if you score the payout and link on shared entities rather than checking accounts one at a time. Set your threshold where the loss actually is, not where the volume is.

Manual review is not a failure#

In this vertical specifically, review is often the right default rather than block.

Your users include genuinely ambiguous cases: two people in one household sharing a laptop, students on a university network, whole markets where a mobile carrier puts thousands of people behind one address. Blocking those outright generates support load and public complaints, and reward audiences are vocal.

A queue where a human looks at the twenty highest-risk cashouts a day, with the reasons attached, is usually a better fit than an automatic block. It is the setup we would suggest starting with.

Scoring both ends#

Two calls with the same identity fields, on the two events that matter. The signup call is cheap and mostly exists to build the history the second one reads:

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,
  event_country: offer.country,        // where the offer expects the user to be
  ip_country: req.headers["cf-ipcountry"],
});

// let them in; hold what the account is WORTH
if (r.verdict !== "allow") await markBonusHold(user.id, r.event_id);

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

if (r.verdict === "block") return holdPayout(user.id, r.reason_text);
if (r.verdict === "review") return queueForReview(user.id, r.event_id);

return payout(user.id);

The query Kaidn cannot run for you#

Payout convergence is the strongest signal in this vertical and it is not a Kaidn check, because the API never takes a payout destination. It is a short query on your own side and it is worth writing:

SELECT payout_destination, count(DISTINCT user_id) AS accounts, sum(amount) AS total
FROM payouts
WHERE created_at > now() - interval '30 days'
GROUP BY payout_destination
HAVING count(DISTINCT user_id) > 3
ORDER BY total DESC;

Put that next to the cashout verdict and you have both halves. Kaidn says this account looks like other accounts. Your own data says here is where they all send the money.

Where we sit#

This is the vertical Kaidn was built around first, so the signals are tuned for it: what the email resolves to, whether the device has been here before, network reputation, how fast things repeat across the funnel, and a cross-operator graph that links entities seen at other operators. Verdicts come back with the checks that fired and what each one counted for.

We do not do KYC, we are not a payments processor, and we do not replace your relationship with your networks. We score events and explain the answer.