A referral programme is the one place in your product where the fraud has a published price list. You have written down, on a marketing page, exactly what you will pay for a new account. Someone will read that as an offer.
The mechanic is old and the defences most teams ship are older: block duplicate emails, block duplicate IPs, cap rewards per account. Every one of those was defeated years ago by tooling that now costs less per month than the reward you are protecting.
Three shapes, one root cause
Self-referral. One person, their own link, a second account. Collects both the referrer bonus and the new-user credit. The overwhelming majority of what you will see, and the cheapest to run.
Farming. The same attack, industrialised. Hundreds of accounts through an antidetect browser with a fresh profile and a fresh residential exit per identity, often against a programme that pays in a withdrawable currency rather than in-product credit.
Affiliate collusion. A partner who sends traffic they manufactured. Harder to see because the volume looks like success, and it usually gets discovered by an analyst wondering why one channel converts at four times the rate of every other and retains at none of it.
All three reduce to the same problem: you cannot tell whether two accounts are two people. Everything else is detail.
Why the usual checks fail
Email. Masked-relay addresses ship by default on iPhones and in Firefox. An attacker does not even need a burner domain, and if you block relays you refuse the privacy-conscious customer who was going to pay you. We wrote about that trade in disposable email detection and reached the same conclusion there: useful input, terrible gate.
IP address. A residential proxy subscription is a consumer product. For a few dollars a month the second account arrives from a genuine home connection in a city you would never question. Meanwhile deduplicating on IP punishes university halls, offices behind one NAT and entire mobile carriers doing CGNAT.
Browser fingerprint alone. Antidetect browsers exist precisely to defeat this. Each profile gets its own canvas, WebGL, fonts, timezone and user agent, and to a naive fingerprinting library those profiles are simply different computers.
The pattern: every one of these checks tests something the attacker controls and can change for a few dollars.
What actually separates the cases
Two things survive the tooling, and they work because of how they are collected rather than what they measure.
Network truth. Not “is this IP on a blocklist” but what the connection actually is: a residential proxy exit, a VPN, a datacenter range, a Tor node. A referral arriving through a residential proxy is not proof of fraud — but a referral pair where both sides arrive through different exits of the same proxy network, minutes apart, is not a coincidence anyone needs to argue about.
Device linking that survives profile switching. The signal that matters is not the fingerprint hash, which spoofs, but whether the same device has been here before under other identities. Antidetect browsers change what the browser reports; they are markedly worse at changing what the machine underneath is. Tampering detection catches the act of lying itself — a profile whose declared platform, timezone and rendering behaviour do not agree with each other is a stronger signal than any of those values individually.
In our pipeline the linking is deliberately narrow: device-to-account links are stored per customer and hash-only, so linking answers “has this device held other accounts on your platform” and nothing wider. That is the question a referral programme needs, and it is also the only version of it we are willing to build.
Check at payout, not at signup
The instinct is to evaluate the new account when it registers. It is the wrong moment for two reasons.
First, signup is when you know least. The account has no history, no second session, no behaviour. Wait until the reward qualifies — first purchase, day-seven retention, whatever your terms say — and you are judging a richer record.
Second, refusing at signup hands the attacker a debugging tool. Fail them at registration and they learn within seconds which profile tripped, adjust, and retry. Approve the signup, evaluate at qualification, and the feedback loop breaks: they cannot tell which of the last fifty accounts is going to be paid until the payout window closes.
Both changes are free, and the second one is worth more than most detection improvements.
In practice
Evaluate the claiming session against the referrer’s account, and let the reason codes drive the decision rather than a single score:
// Runs when the referral QUALIFIES, not when the account is created.
const v = await sentinel.evaluate({
token, // network token from the client SDK
fingerprintEventId, // device event id, same call
accountId: referredUser.id,
});
const linkedToReferrer = v.device?.visitor_id
&& await hasAccount(v.device.visitor_id, referrer.id);
if (linkedToReferrer) return reject('self_referral');
if (v.decision === 'block') return reject('network_or_device');
if (v.decision === 'review') return hold(v.risk_score); // pay after review
return payout();The hold branch is the one that pays for itself. Referral rewards are almost never time-critical — a 48-hour delay on a flagged claim costs a legitimate user nothing they will notice, and it removes the fast feedback that makes farming worth automating in the first place.
Write the delay into the terms
A detection stack you cannot act on is decoration. Before any of this helps, your programme terms need to permit a hold and a refusal:
- A stated qualification window before a reward becomes payable at all.
- An explicit right to withhold on suspected abuse, with a human appeal route.
- Self-referral named as a violation, in plain words rather than by implication.
- A cap on rewards per account and per payment instrument.
None of that is fraud detection. All of it determines whether your fraud detection is allowed to do anything, and it is the part teams discover too late — usually in the week they first try to refuse a payout.
What this cannot do
Two friends, two phones, two networks, one agreement to split the reward: that is indistinguishable from the referral you were trying to buy, because structurally it is that referral. No signal separates them, and a programme tuned to catch that pair will refuse far more real customers than fraudsters.
Aim somewhere more useful. The money is not lost to careful pairs, it is lost to the hundred accounts one person mints in an afternoon. Kill the cheap automated volume, add a delay before payout, and the arithmetic stops working for the farmer long before it starts inconveniencing anyone real.
Frequently Asked Questions
What is referral fraud?
Claiming referral rewards for invitations that were never real. The common shape is self-referral: one person creates a second account through their own link and collects both sides. At scale it becomes farming, where hundreds of accounts are minted to harvest signup credit, and in affiliate programmes it becomes collusion, where a partner sends traffic they generated themselves.
Why do email and IP checks miss it?
Because both are trivially cheap to change and the tooling is consumer-grade now. A masked-email relay ships by default on every iPhone, and a residential proxy subscription costs a few dollars a month and hands out a clean home IP in whatever city you like. Blocking on burner domains or duplicate IPs catches the laziest attempt and nothing above it, while quietly refusing real customers who use a relay or share an office NAT.
Where in the funnel should the check run?
On the event that costs money, which is qualification or payout, not signup. Checking at signup measures the wrong moment and hands the attacker feedback: refuse them there and they learn immediately which profile tripped, then retry. Evaluate when the reward becomes claimable and you get a fuller history to judge and no free debugging loop.
Will this flag genuine referrals between family members?
Same household, same network, different devices is normal and should pass. Same device, two accounts, minutes apart, through a proxy is not. The distinction is device linking rather than IP: a shared home connection produces one network and several distinct devices, while self-referral usually produces one device wearing several identities. Judge the combination, never a single signal.
Can referral fraud be eliminated entirely?
No, and a programme that tried would be worse than the fraud. Two friends on separate phones on separate networks who agree to split a reward are indistinguishable from the referral you wanted, because that is exactly what a referral is. The goal is to make farming uneconomic, which is achieved by killing the cheap automated volume and adding a delay before payout, not by chasing the last honest-looking pair.
Check the referral, not just the signup
Device linking, network truth and account history in one call, on the event that actually costs you money.
Try Maskbreak free →