The Anti-Fraud Handbook

Why referral programs get abused

Because they pay real money for an action that is cheap to fake. Every program creates a gap between the action it can observe — a signup, a click, an order — and the thing it actually wants, which is a new customer who stays. Fraud lives in that gap.

This framing matters because it points at the fix. You cannot close the gap by watching harder; you close it by paying for something further along, where faking it costs more than the reward is worth.

Self-referral: the most common attack by far

One person creates a second account and refers themselves. It needs no technical skill, and it accounts for most abuse in most programs. It is also the attack that best rewards prevention over detection, because the tell-tale signals are all things honest customers sometimes share.

Payment instrument is the signal worth building on, because it is expensive for the attacker to vary and rare for honest customers to share. IP address is the signal worth being careful with — see below.

• Same payment instrument on both accounts — the strongest single signal
• Referral completed within minutes of the account being created
• Delivery address matching the referrer's exactly
• Email addresses differing only by a plus-tag or a dot
• The referred account transacts once, at exactly the qualifying threshold, then never returns

Why IP matching causes more problems than it solves

Because shared IPs are normal. Families, flatmates, offices, universities, mobile carriers and VPNs all put unrelated people behind one address. Blocking on IP collision alone reliably rejects genuine referrals between people who live or work together — exactly the people most likely to refer each other.

Use it as one weak input among several, never as a rule on its own. A referral that shares an IP and a payment method and completed in ninety seconds is worth holding. A referral that only shares an IP is probably two people in the same house.

Refund cycling

The referred customer places a qualifying order, the reward is released, and the order is then refunded or charged back. The business pays for the acquisition and keeps none of the revenue. It is entirely preventable and still extremely common, because most programs pay too early.

1. 01Set the qualifying event past the refund windowIf your refund window is 30 days, release the reward on day 31. This single change removes the entire attack class.
2. 02Reverse rewards on refundWhere an early payout is unavoidable, make the reversal automatic and say so in the terms. A clawback that is not documented in advance will be disputed.
3. 03Treat chargebacks as a separate triggerChargebacks arrive long after refunds. Reverse on both, and monitor the rate — a rising chargeback rate on referred orders specifically is a signal worth acting on.

Bulk distribution and coupon aggregators

A referral code posted to a deals site stops being a personal recommendation and becomes a public discount. Volume rises sharply, referred-customer quality collapses, and you end up paying a referral reward for customers who would have found the discount anyway.

The control is a per-advocate cap over a rolling period, plus terms that name paid placement and aggregator posting as voiding behaviour. Caps are unpopular with genuinely enthusiastic advocates, so set them well above normal behaviour rather than close to it.

• A single advocate producing an order of magnitude more referrals than any other
• Referred customers arriving with no prior touchpoint and converting immediately at a discount
• The code appearing in search results for "[your brand] discount code"
• Referral volume spiking with no matching change in your own activity

Partner and collusion fraud

Two or more people refer each other in a ring, so every participant collects. It is rarer than self-referral and harder to see, because each individual relationship looks legitimate — the pattern only appears when you look at the graph rather than at single referrals.

Look for closed loops: A refers B, B refers C, C refers A. In a genuine program the referral graph is overwhelmingly a tree, and cycles are worth a manual look even at small volumes.

The controls that actually work, in order of effect

Almost all of the benefit comes from three decisions made before launch, and almost none from detection built afterwards. Order matters — the first item alone removes more fraud than every detection rule combined.

1. 01Pay lateMove the qualifying event to a first completed purchase past the refund window. This is the highest-leverage control that exists.
2. 02Define 'new customer' precisely in the termsNo prior account, no shared payment instrument, no shared delivery address. If it is not written down you cannot enforce it consistently.
3. 03Cap rewards per advocate per periodSet it above what an enthusiastic real customer does, so it catches distribution rather than enthusiasm.
4. 04Hold, don't blockRoute suspicious referrals to manual review rather than auto-rejecting. False positives on honest customers are more expensive than the fraud you prevent.
5. 05Reconcile monthlyCompare rewards paid against referred revenue that survived the refund window. A widening gap is the earliest reliable signal that something is being worked.

What to do when you find it

Apply the terms you published, and only those. Void the reward, document which clause it breached, and tell the customer which one. Enforcement that cannot point to a written clause reads as arbitrary, and honest customers who get caught in it leave and say why.

How much fraud is acceptable?

Some, and chasing zero is usually a mistake. The controls needed to eliminate the last portion — aggressive blocking, identity checks, manual approval of everything — cost more in lost genuine referrals than the fraud does. Reconcile monthly, decide a tolerance, and spend your attention on the payout timing instead.