Affiliate fraud: how to detect and prevent it

Every affiliate program is a standing offer to pay a stranger for an outcome you cannot directly observe. That is not a flaw in the model, it is the model: you trade verification for reach. Affiliate fraud is what happens when somebody takes the offer literally and works out that producing the outcome is far cheaper than producing the customer.

What makes it hard to see is that nothing looks broken. The postback fires. The row lands in your database. The dashboard goes up. You find out weeks later, when the cohort that was supposed to become revenue turns out to have been a hundred accounts on one phone.

This page covers the six kinds, the seven signs, and one thing most guides on this subject get wrong, which we can be specific about because we measured it on our own traffic and publish the number.

How affiliate fraud actually works#

Three parties, one loop. You post an offer ("$4 per verified signup"). A network or a partner sends traffic. A conversion event fires. Money moves.

The fraudster is not attacking your product. They are attacking the event, and there are only three things they can ever want from it:

1. Get paid for traffic that cost nothing. Manufacture the conversion directly: scripted signups, emulator installs, purchased identities, a phone farm and an afternoon.
2. Get paid twice for the same person. One human, many accounts, many claimed first-time bonuses. This is the dominant form anywhere the payout is per-user rather than per-purchase.
3. Get paid for someone else's conversion. Do not create traffic at all, just make sure the attribution cookie says you did. Cookie stuffing, forced clicks, and brand-name bidding are all versions of standing in the doorway of a sale that was already happening.

Notice what is missing: none of the three requires beating your security. They require beating your accounting. That is why programs with good engineering still get taken, and why the fix is almost never a harder signup form.

The six kinds you will actually meet#

Farmed and scripted signups. Accounts created in bulk to trigger a per-signup payout. The tell is rarely the account itself, which is usually well-formed. It is the rate and the shape: forty accounts in nine minutes, or a hundred accounts whose email local parts are one name with a rotating digit. See fake signups.

Multi-accounting and self-referral. One person, many accounts, referring themselves through the program. The most common form in rewards, offerwall and fintech-bonus programs, because those pay per person and a person is the easiest thing in the world to fake. See multi-accounting and bonus abuse.

Cookie stuffing and attribution hijacking. Dropping tracking cookies on users who never clicked the affiliate's link, so the partner collects last-touch credit for organic and paid conversions you already paid for once. The signature is a partner with an enormous conversion rate and almost no measurable click volume.

Fabricated and resold leads. In lead generation the "conversion" is a form submission, which is the cheapest artefact on this list to manufacture. Leads are also frequently sold to several buyers at once, so the fraud is not that the person is fake but that you are the fourth company to call them today.

Emulator and device-farm installs. In app campaigns, installs generated by emulators, rooted devices with reset identifiers, or racks of real handsets. On Android the giveaway is often a hardware-backed integrity verdict that does not match a real retail device.

Promo and trial abuse. Not always filed under affiliate fraud, but it runs on the same economics and frequently the same operators: whatever you give away to a new user is the payout, and the referral link is just the delivery mechanism. See trial abuse.

The dedup key everyone uses is not an identity#

Here is the part most affiliate fraud guides skip, including the ones written by companies that sell fraud tools.

Almost every affiliate fraud defence in this market rests on one rule: same device, same person. Fingerprint the browser, hash the result, and treat two accounts with the same hash as one human. It is the first rule everybody writes and it is the rule most likely to be quietly wrong.

A raw browser fingerprint is a hash of settings, and identical settings produce identical hashes. A default iPhone really is identical to another default iPhone. So the hash is not an identifier for a person. It is an identifier for a configuration, and configurations are shared by strangers.

We publish what that costs, measured on real traffic rather than modelled:

Read the first row again in the context of an affiliate program. If your same-device rule blocks or claws back on a raw fingerprint, then on iOS Safari you are acting on an identity that covers more than two real people on average. Those false positives are not spread evenly across your users either. They land almost entirely on one platform, so the pattern you see in your dashboard is "iPhone users commit more fraud", and the pattern in reality is "iPhone users share more fingerprints".

The fix is not a better hash. It is corroboration, and the thing that corroborates is the network. Two people sharing a fingerprint are almost never also on the same ASN. Adding it takes iOS Safari from 2.30 people per identity to 1.27. We tested the obvious alternatives on the colliding identities and they do not work: JA4 separated almost none of them, because iOS Safari users genuinely share a TLS fingerprint, and timezone separated none at all.

What it costs you beyond the payout#

The commission is the visible loss and usually the smaller one.

• Your acquisition maths goes wrong in the optimistic direction. Fake conversions make a channel look cheap, so you spend more into it. The budget moves toward the fraud.
• Your good partners get punished. When a program tightens after being burned, it tightens on everyone. The honest affiliate whose conversion rate dropped because you added friction does not send you a note, they just move to a different advertiser.
• The cohort poisons every downstream number. Retention, LTV, activation and payback are all computed over a population that includes a few thousand people who do not exist.
• You pay the payment costs regardless. Chargebacks, payout fees and processing on a fraudulent conversion are real money leaving on top of the commission.

Are you being defrauded? Seven signs#

None of these is proof on its own. Two together is worth a look, and three is worth holding a payout.

1. The cohort never comes back. The strongest single signal, and the one you already have the data for. Real users acquired through a real channel have a retention curve. A farmed cohort has a cliff at day one, because the account existed to trigger one payout. It is useless for a real-time decision and close to conclusive for deciding whether to keep a partner.
2. A partner converts far better than everyone else. Not 20% better, multiples better, and consistently. Genuine outperformance exists but it usually comes with a story you can verify.
3. Conversions cluster in time. Real traffic arrives on a human distribution across a day. Twelve conversions inside four minutes is a script's distribution.
4. The identity shapes repeat. Emails that normalise to the same address once you strip dots and plus-tags, phone numbers from one narrow range, names from an obvious generator. See canonical email.
5. One device and one network sit behind many accounts. Both halves, for the reason above. Under CGNAT the network alone is weak too, so this is a signal that only works as a conjunction.
6. Geography does not match the offer. A US-only offer converting from datacenter IPs or from a country the campaign was never shown in.
7. A partner is always last touch and never first. The attribution-hijack pattern: they appear in the final step of journeys they did not start.

What does not work#

These are the defences almost every program reaches for first. They are listed here because trying them and watching them fail is the expensive way to learn this.

Deduplicating on a device fingerprint alone. Covered above, and first on the list because it is the one that feels most like real engineering. It produces false positives concentrated on a single platform, which is the worst shape a false positive can have: it looks like a finding.

Deduplicating on IP address. Under CGNAT, thousands of unrelated mobile users share one address, so IP dedup fails at scale in exactly the markets where mobile share is highest. It also fails in the other direction: rotating residential proxies give one operator a fresh IP per account for a few dollars a gigabyte.

Blocking VPNs and proxies wholesale. A meaningful share of ordinary, paying, entirely legitimate users are behind a VPN, on a corporate network, or on a privacy browser by default. Blanket-blocking that population costs more good conversions than it saves bad ones. A residential proxy is a weight, not a verdict.

Adding a CAPTCHA. CAPTCHA raises the cost of automation, which is useful, and does nothing about the dominant attack, which is a real human with real hands making real accounts. Solving services price a challenge in fractions of a cent, well below any payout worth farming.

Manual review of everything. It works briefly and does not survive volume. The failure mode is not that reviewers are bad at it, it is that a queue with everything in it gets skimmed, and a skimmed queue is a rubber stamp with a salary.

The signals that do#

The useful ones share a property: expensive for the attacker to fake, cheap for a real user to satisfy.

• Identity collapse. Not "is this email disposable" but "how many of these accounts are the same person once you normalise the email, the phone and the device". This is what catches self-referral, and most programs do not have it.
• Velocity on the right key. Events per hour per device, per ASN, per email root, per partner. Velocity on the wrong key finds nothing; on the right key it is the fastest signal you own.
• Network reputation rather than network type. The question is not "is this a datacenter" but "has this ASN been abusive in my own history". A first-party abuse rate per network beats a bought list.
• Device continuity, promoted. Treat the fingerprint as the probabilistic link it is, then promote it to a deterministic one with a first-party device token you issue and control. That is the difference between 2.30 people per identity and about 1.01.
• Cross-partner correlation. The same identity converting under three different affiliates in a week is not three customers, and no single partner's data can see it. This is the argument for a shared fraud graph.
• Post-conversion behaviour. The retention cliff. Slowest, most conclusive.

The boundary, stated plainly#

Every vendor page in this market implies completeness. Here is ours, from our own lab, published in full in the blocked-agent write-up.

An anti-detect browser profile that spoofs a different operating system than the one it runs on gets caught, because the claim and the machine contradict each other. A profile that runs a Windows persona on a Windows machine does not, and that is the realistic fraud configuration. It defeats our engine, and in the same head-to-head it defeated the best-funded engine in this market too. Same-OS spoofing is where the state of the art currently ends, for everyone.

There is a second boundary worth knowing about, and it cuts the other way. A hosted third-party fingerprinting script can be blocked by an ad blocker. In our head-to-head, the competing script did not run at all on 21 of 24 privacy and anti-detect sessions, because the common filter lists carry rules for its domains. A blocked collector does not return a weak verdict, it returns none. Whatever you use, the server-side path has to fail open: a blocked script should cost you a signal, never a signup.

Neither of these is a reason to skip fraud scoring. They are the reason to distrust a program that rests on one signal, and the reason we return the checks that fired instead of a number you have to take on faith.

Run the program so fraud is cheap to catch#

Detection is half of it. The other half is structural, and it is free.

• Put a hold period between the conversion and the payout. Even 72 hours turns "recover the money" into "do not send the money", which is a different and much easier problem.
• Pay on a downstream event, not the signup. If the commission triggers on the second session, the first purchase or a verified action rather than on account creation, most farmed volume stops being profitable to produce.
• Score per partner, not just per user. Keep a running flagged share for every affiliate. A partner is a distribution, and the distribution tells you whether you have a leaky source or a hostile one.
• Make the honest path fast. Every check you add taxes real conversions too. The reason for a three-way verdict is so the tax falls on the ambiguous minority rather than on everybody.
• Write the thresholds down and revisit them. A rule set nobody has looked at in six months is a rule set attackers have already mapped.

In short#

Affiliate fraud is an accounting attack dressed as a traffic problem. It works because a conversion is a claim, your database records claims, and the gap between "a row exists" and "a customer exists" is where the money goes.

The trap is that the obvious defence feels like the right one. Same device, same person is the first rule everybody writes, and on the platform where it matters most it is wrong about the person more than half the time. Corroborate it with the network, promote it to something you issue yourself, and know the collision risk of the identity you just acted on.

Then do the three unglamorous things. Pay on something harder to fake than a signup. Decide at the moment of the claim, not at the end of the month. Keep a middle option, so uncertain conversions get held rather than the whole program getting tightened until the good partners leave.

You do not need to catch everything. You need the fake conversion to cost more than it pays.