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 that most fraud tooling was not 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, examined 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. Payout convergence, many accounts sending value to a small number of endpoints, is the single strongest signal in this vertical, and it does not exist at signup.

This is also the point 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#

The thing that makes reward fraud more expensive than it first appears is the reversal cycle.

A fraudulent 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 is worse in the partner's dashboard for the next negotiation.

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

Fraud you can afford, and fraud you cannot#

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

A user who games 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 are scoring the payout and linking on 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 state#

For this vertical specifically, review is often the correct default rather than block.

The population is full of genuinely ambiguous cases: shared devices in one household, students on a university network, users in markets where carrier-grade NAT puts thousands behind one address. Blocking those outright generates support load and public complaints, and reward audiences are vocal.

A queue where a human sees the twenty highest-risk cashouts a day, with the reasons attached, is usually a better fit than an automated block, and it is the configuration 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 builds 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 join Kaidn does not make for you#

Payout convergence is the strongest signal in this vertical and it is not a Kaidn check, because the API takes no payout-destination field. 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;

Combine that with the cashout verdict and you have both halves: Kaidn says this account looks like other accounts, and 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: email identity, device continuity, ASN reputation, velocity across the funnel, and a cross-operator graph that links entities seen at other operators. Verdicts come back with the checks that fired and their weights.

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.