Referral Fraud Detection: Real Spike or Coordinated Attack?

Referral fraud detection starts the moment a spike shows up in your dashboard and you have to decide, fast, whether it's a real win or a coordinated referral fraud attack. The signals that separate the two are concrete: IP velocity, device overlap, and disposable-email patterns. Read them in that order before you touch payouts.

Real spike or coordinated referral fraud attack: what's different

A real spike is messy: signups arrive from varied IPs, devices, and email domains, spread over hours, often after a specific trigger like a product launch or influencer mention. A coordinated referral fraud attack is uniform: accounts cluster in tight time windows, share infrastructure, and convert into the reward the moment they clear.

The pattern is closer to what researchers call a Sybil attack, where one operator manufactures many identities to look like many independent participants. Microsoft Research's original paper on the Sybil attack describes exactly this: without a trusted way to verify that each identity maps to a distinct real person, an attacker can create as many as their resources allow. A referral program with no identity friction is a soft target for the same trick.

Referral fraud detection starts with IP velocity

IP velocity measures how many referral signups originate from the same IP address, or a narrow subnet, within a short window. A legitimate viral moment spreads across residential ISPs nationwide; a coordinated attack often clusters on a handful of IPs, sometimes behind the same data-center or VPN exit node, arriving in minutes rather than hours.

Pull the raw event data before you conclude anything. ReferralFlo's referral tracker exports the cohort as CSV with timestamps and IP addresses attached to each click and signup, so you can group by subnet in a spreadsheet instead of eyeballing a dashboard total. Stripe's fraud engine relies on the same class of signal: its Radar documentation lists IP address and network reputation among the core inputs it scores on every transaction, because velocity from a small IP range is cheap to check and hard for an attacker to fully hide.

As an illustrative example: a program that normally gets one signup per unique IP suddenly showing five or more signups from that same IP within an hour is a ratio worth a manual check, independent of any other signal.

Device overlap catches what IP velocity misses

Device overlap shows up when accounts that claim no relationship share a browser fingerprint, screen resolution, or hardware signature. ReferralFlo's Growth Graph attribution engine captures device fingerprinting alongside each referral event, so a batch of new signups sharing one device profile is a stronger fraud signal than IP alone, since IPs rotate but hardware fingerprints don't.

This is the check that catches attackers who already know to rotate IPs or route through a VPN. An operator running twenty fake referrals from one laptop can spin up a new IP for each one; spinning up twenty genuinely distinct devices costs real money and real hardware, which is why device overlap tends to survive as evidence even after the IP trail gets scrubbed.

Disposable emails are a tiebreaker, not proof on their own

Disposable-email domains and sequential usernames rarely appear alone; they matter as corroboration. A signup from a temp-mail service is common even in real traffic, but stacked on top of shared IPs and overlapping devices, it stops looking like noise. ReferralFlo's anti-fraud detection flags disposable domains automatically, so you're checking a pre-filtered list, not raw signups.

Treat a disposable email on its own as a yellow flag, not a verdict. Plenty of privacy-conscious real users sign up with a masked address. The combination is what matters: a cluster of disposable addresses landing inside the same IP range or device group, within the same short window, is a different story than one disposable address scattered among a thousand normal ones.

Decide whether to pause payouts pending review

Pause payouts when two or more independent signals overlap on the same cohort: high IP velocity plus device overlap, or device overlap plus a cluster of disposable emails. One signal alone is usually not enough to freeze a legitimate spike. ReferralFlo's reward escrow can hold payouts pending conditions like KYC or a completed first order, buying time to review without blocking the whole cohort.

Scope the hold narrowly. Freezing the entire program because one cohort looks suspicious punishes the referrers who did nothing wrong and slows the program's real momentum. ReferralFlo's referral management approvals let you hold and review a specific batch of referrals while the rest of the program keeps paying out on schedule, with the action logged to the immutable audit trail for later reference.

For a broader baseline before you're mid-spike, the anti-fraud checklist for referral programs covers the prevention controls, like consent capture and reward rules, worth setting up in advance so fewer spikes reach this decision point at all.

Turn this into a repeatable playbook

Treat every unexplained spike as a rehearsal, not a one-off. Log the IP ranges, device fingerprints, and email domains that triggered review this time, and check new spikes against that history first. Programs that document past attacks catch repeat coordinated referral fraud faster, because the second wave usually reuses infrastructure from the first.

Build the check into your webhook flow rather than doing it by hand each time. ReferralFlo's documentation covers the webhook events and fields available for each referral, which is what you'd wire into an internal alert if a single IP or device crosses a threshold you set. That turns spike diagnosis from a scramble into a five-minute lookup the next time it happens.