Skip to content
Back to Growth & Acquisition

Referral Fraud Prevention

Detect and block self-referrals, referral farms, and velocity abuse before they drain the reward budget.

Why

Referral fraud is the single fastest way to make a program unprofitable — a single attacker with a disposable-email service can collect 100 rewards in a weekend, and the program is 'unprofitable' in every future report because the fraud cost is baked into the baseline. The fraud patterns are well-known (self-referral via disposable emails, referral farms via VPN + headless browsers, velocity abuse via one code shared in a coupon group) and detectable with simple signals: same-IP clusters, disposable-email domains, velocity per code, device-fingerprint reuse. Prevention is 10x cheaper than recovery — a $5/email fraud-detection check saves $10/reward in fraudulent payouts. The discipline is to auto-pause suspicious codes (not auto-ban, which creates false positives) and human-review the flagged cases within 24h.

When

Before launch, and continuously after. Add a new detection rule whenever a novel fraud pattern appears in the review queue.

How

1. Block self-referral: the recipient's email, device fingerprint, and IP must differ from the inviter's; check all three
2. Block disposable emails: maintain a list of 500+ disposable domains (e.g. mailinator, guerrillamail); reject at signup
3. Velocity check: if a single code generates >5 signups/hour or >20/day, auto-pause the code and flag for review
4. IP cluster check: if 3+ signups from the same IP within 24h attribute to the same inviter, flag and withhold rewards
5. Device fingerprint: if the same fingerprint (canvas + WebGL + UA) appears on 2+ signups, flag all associated rewards
6. VPN/proxy detection: cross-check IP against a VPN database; VPN signups get the reward only after manual review
7. Auto-pause (not auto-ban) codes that trip 2+ signals; the inviter gets an email 'rewards paused, review in 24h'
8. Weekly review: classify flagged cases as fraud (ban, claw back rewards) or legitimate (release rewards, whitelist code)

Example

# Fraud signals and auto-actions
Signal 1: recipient_email == inviter_email           → block signup
Signal 2: email domain in disposable_list (500+ doms) → block signup
Signal 3: code velocity > 5/hour or >20/day           → auto-pause code
Signal 4: 3+ signups from same IP → same inviter      → flag, withhold reward
Signal 5: device fingerprint seen on 2+ signups       → flag all rewards
Signal 6: IP in VPN database                          → manual review before reward

# Auto-pause rule (2+ signals)
if (signals >= 2) {
  pauseCode(code);
  emailInviter(inviter, "rewards paused, review in 24h");
  addToReviewQueue(inviter, signals);
}

# Weekly review (this week)
42 codes flagged → 28 fraud (ban + claw back $340) + 14 legit (release $180)
Fraud rate: 28 / (28 + 1400 legit) = 1.9%  (under 3% threshold) ✓

Common Problems

  • ⚠Auto-banning on a single signal, which creates false positives that alienate legitimate power users who invite from an office IP.
  • ⚠No velocity check, so a fraudster shares one code in a coupon group and 200 'signups' arrive in an hour.
  • ⚠Checking only email (not device fingerprint or IP), so a fraudster with 50 email addresses and one device collects 50 rewards.
  • ⚠No weekly review queue, so flagged cases pile up and legitimate inviters wait weeks for their rewards, then complain publicly.

Best Practices

  • ✓Require 2+ signals before auto-pausing; a single signal (office IP, VPN) creates false positives that alienate good users.
  • ✓Auto-pause (not auto-ban) and human-review within 24h; the pause stops the bleeding while the review prevents false positives.
  • ✓Check email, device fingerprint, AND IP — checking only one leaves a trivial bypass for any motivated fraudster.
  • ✓Maintain the disposable-email domain list weekly; new domains appear constantly and a stale list is no list.