allanninal.dev/build

Part 5 of 7 · Referral tracker series ~8 min read

How referral fraud gets caught

Any programme that pays people to bring friends will be tested by people bringing themselves. This post is about the screen that sits in front of every payout: how a self-referral is spotted, how repeat conversions are deduped, how a code behaving like a bot is held rather than paid, and why the honest majority never feel it.

Key takeaways

  • Every referral that could pay out passes a fraud screen first — deterministic checks, run before any money moves.
  • Self-referrals are caught by matching the referred person’s identity — account, payment fingerprint, device — against the referrer.
  • The same person converting twice is collapsed to one reward by keying the referral on the referred identity, not the sign-up.
  • A code that suddenly sprays clicks or sign-ups trips a velocity check and is held for a human rather than paid.
  • Clear abuse is blocked outright; anything merely suspicious is held and escalated — the honest majority never feel it.

Anyone you pay, you’ll be tested by

The moment a business offers £10 for bringing a friend, some people will try to bring themselves. It’s not always malicious — plenty is just a customer who figures a second account and a spare email is a harmless way to get their own discount — but it’s money going out for customers who were never really referred, and left unchecked it’s the thing that quietly kills a referral programme’s economics. So a fraud screen sits in front of every payout, and its whole job is to answer one question before a reward is issued: is this a real friend, brought by a real recommendation, being credited for the first time? Only a clean yes gets paid automatically.

The screen is deliberately deterministic. It would be easy to imagine handing a model the case and asking “does this look fraudulent?” — and that’s exactly what the design avoids, because a fraud decision has to be explainable, consistent, and defensible if a customer asks why they weren’t paid. Every check here is a plain rule over facts the system already holds. The model writes invites and thank-yous; it gets nowhere near the question of who is or isn’t cheating.

Three things it looks for

The screen runs three families of check. The first is self-referral: is the referred person actually the referrer wearing a different hat? At sign-up and again at conversion, the system compares the friend’s identity against the referrer’s across several axes — the account and email, the payment fingerprint (the same card or PayPal behind two “different” people is the strongest tell), the device and the delivery address. No single match is proof, but the combination is: same card and same device as the referrer is a self-referral, full stop, and it’s blocked outright.

The second is duplicates: has this friend already earned someone a reward? This is defended at the data model, not by a check that might be skipped — the referral is keyed on the referred person’s durable identity, so the same human signing up three times under three emails still resolves to one referral record, and only the first conversion can ever pay. Farming the same friend through repeated sign-ups earns exactly one reward, or none. The third is velocity: is a code behaving like a script rather than a person? A real customer’s link gets a handful of clicks and the odd sign-up; a code that suddenly logs two hundred clicks in an hour, or a burst of sign-ups all from one IP range or one device, is almost certainly being sprayed by a bot or gamed in a loop. That code is held — not deleted — and its pending referrals wait for a person, rather than paying out into the noise.

The fraud screen: a candidate reward run through self-referral, duplicate, and velocity checks before payout On the left, a box “Candidate reward” — a referral about to be paid — sends an arrow into a stacked column of three deterministic checks inside a dotted AWS account container. The first check, “Self-referral?”, compares the referred identity against the referrer across account, payment fingerprint, device, and address, reading a DynamoDB identity view; a match exits right to a box “Block, no reward”. The second check, “Duplicate?”, resolves the referred person to one durable identity so repeat sign-ups collapse to one referral; a repeat exits to a box “Collapse to one”. The third check, “Velocity?”, aggregates recent clicks and sign-ups per code and per source; over threshold it exits to a box “Hold for a person” that emails your team via SES. If all three pass, an arrow goes down to a box “Clean → pay” that returns to the reward step. A note reads: clear abuse is blocked, the suspicious is held for a human, and the honest majority pass straight through — the model is never asked to judge fraud. Candidate reward about to pay AWS account Self-referral? card, device, address match DynamoDB identity view Block, no reward match Duplicate? one durable identity pass Collapse to one repeat Velocity? clicks/sign-ups per code pass Hold for a person over limit → SES Clean → pay back to reward step pass Clear abuse is blocked, the suspicious is held for a human, the honest majority pass straight through — the model never judges fraud.
Fig 5. The fraud screen. A candidate reward runs three deterministic checks in turn — self-referral by identity match, duplicates collapsed to one durable identity, and velocity per code. Clear abuse is blocked, suspicious cases are held and emailed to a person, and clean referrals pass through to be paid.

Block, hold, or pass

Each check resolves to one of three outcomes, and the difference between them is the whole design. A block is for the unambiguous: same payment fingerprint and device as the referrer is a self-referral, and it’s declined without ceremony — no reward, a note on the record of exactly why, and no accusatory message to the customer. A hold is for the suspicious-but-not-certain: a velocity spike, a partial identity match, an address that’s close but not identical. The referral is parked, and an email goes to your team — the referrer, the referred customer, the specific rule that fired, and the numbers behind it — so a person can approve it (and release the payout) or reject it in one click. A pass is the overwhelming majority: a real friend, a clean identity, ordinary volume, paid automatically within seconds.

Holding rather than blocking the grey cases is what keeps the screen fair. Fraud checks always catch some innocents — a couple who share a card and both genuinely love the meal-prep service will trip the payment-fingerprint rule — and the cost of wrongly blocking a real advocate is high: you’ve insulted your best kind of customer. Routing the ambiguous to a person, with the evidence laid out, means the system can be strict without being unjust. The rules are tuned to block only what’s certain and hold everything else, and the thresholds live in the settings doc so a business can loosen them if it’s turning away honest referrals or tighten them if it’s being farmed.

The codes shared into the void

Not every disappointing referral is fraud. A great many codes are simply shared into the void: minted, pasted into a group chat, and never clicked — or clicked once and never signed up. These cost nothing and mean nothing, and the system treats them as exactly that: no reward, no alarm, no action beyond letting the click log expire on its TTL and the pending referral lapse when its window closes. It’s worth naming the difference, because it’s the difference between the screen’s two failure modes. A code that does nothing is a non-event and is ignored. A code that does too much, too fast is a red flag and is held. The screen spends its attention on the second and wastes none on the first, which is exactly why it stays cheap to run and quiet to live with.

Design rules that shaped the fraud screen

  • Screen before you pay. Every candidate reward passes the checks first; nothing is credited on trust.
  • Deterministic, explainable rules. Fraud is decided by plain checks over known facts — never handed to a model to judge.
  • Identity beats email. Self-referral is caught on payment fingerprint, device, and address, not on a throwaway address.
  • Dedup at the data model. The referral is keyed on the referred person’s durable identity, so repeat sign-ups can only pay once.
  • Block the certain, hold the rest. Clear abuse is declined outright; the ambiguous is parked for a person with the evidence attached.
  • A quiet code is not a crime. Codes shared into the void just expire; only codes behaving like scripts raise a flag.
All posts