Referral fraud and reward abuse prevention.

Referral fraud is the abuse of a refer-a-friend or rewards programme by people who refer themselves, or by scripts that invent friends. The fix is to pay a reward only when the referred person is a distinct, real new customer, and the cheapest reliable way to test that is to compare the device that claims the reward with the device of the person who referred them. When the devices match, the friend is not a friend.

This guide covers the common patterns of referral abuse and incentive abuse, where to check, and a policy that pays honest customers promptly and holds back the rest.

#How does referral fraud work?

There are three common shapes, and they escalate.

• Self-referral. One person creates a second account with another email address and uses their own referral link, so they collect the reward for both sides.
• Referral rings. A group refers each other in circles, or one person runs many accounts that feed rewards to a single account that cashes out.
• Scripted farms. Bots or device farms create accounts in bulk through one referral link, each one just real enough to trigger the payout.

The same logic covers other reward abuse: loyalty programme points, welcome bonuses and affiliate payouts. Anywhere a reward is paid for creating a new customer, someone will try to create the customer themselves.

#Why does an email or phone check fall short?

Because the abuser controls both ends of the referral. Email addresses and usernames cost nothing to create, and phone numbers are available cheaply, so checks that look only at those accept the self-referral happily. The two accounts look unrelated on paper while the device behind them is the same.

A device-level check changes the economics. A person has one phone and one laptop, and getting more takes real money and effort. When each reward requires a genuinely different device, the abuse stops paying for itself.

#How does a device check catch self-referral?

Identify the device at signup and again at the moment of the claim, and store the visitor ID with each account. With Fingerly, every identification returns a visitor ID that stays the same across visits, even after cookies are cleared or a private window is opened, plus whether the device is new to your organisation and a suspect score with a level of low, medium or high.

Then compare. If the claiming account’s visitor ID matches the referrer’s, or matches any other account in the same referral chain, do not pay. A visitor ID names a device, not a person, so treat the match as evidence that two accounts are the same operator rather than proof of fraud, and send ambiguous cases to review. On mobile, identity is a random ID created for the app installation, never read from hardware, so the comparison works at the app level and can be combined with your other data.

#Where should you check in the referral flow?

At each step where a reward changes hands, tagging every identification with the action it protects.

• Signup through a referral link, so you can record whether the new device matches the referrer or any prior account.
• First qualifying action, such as a first purchase or a first deposit, to confirm the same device completes it.
• Reward claim, so a request ID from a harmless page cannot be spent on a payout.
• Payout or withdrawal, where a cluster of linked accounts turns into a loss.

#What policy pays honest customers and holds the rest?

Pay on evidence, in proportion, and make the strongest check the last one before money moves. A starting policy:

• The referred device matches the referrer’s: no reward, and an explanation if the referrer asks.
• The device has claimed a reward before: no second reward for the same device.
• Automation, emulator, cloned app or tampering findings, or a high suspect level: hold the reward and send it for review.
• New device, low suspect level, and a qualifying action completed: pay the reward.
• Many referrals from one referrer in a short window: pause payouts and look at the cluster.
• The device could not be identified: delay the reward until a verification step passes.

Add friction to the reward, not to the join. Letting the referred friend sign up and use the product is harmless. It is the payout that needs the check, so verify at the claim and hold the reward for a few days while the first purchase settles.

#How do you enforce it in your own systems?

Read the event on your server with a secret key and enforce the limit in your own database, because Fingerly does not keep your counters and does not block anyone. Store the visitor ID with every account and reward, and add a unique index on the reward and the visitor ID, so two claims racing each other cannot both succeed.

Use webhooks if you want your own record of events beyond the 30 days the API keeps them. And tell people in the programme terms that rewards are limited to one per device, so a real customer who is refused knows why and can appeal.

Design the reward itself to resist abuse, too. A reward paid on signup alone invites farms, while a reward paid after the friend completes something that costs real effort, such as a first order or a verified payment method, raises the price of faking it. Cap the total a single referrer can earn in a period, and make the cap visible in your terms so honest advocates are not surprised by it.

#How do you stay fair to genuine referrals?

Real friends and family do sometimes share a device, a flat, or a phone. Two accounts on one device is a reason to look, not a conviction. Prefer a verification step or a manual review to an outright refusal, keep an appeal route, and run the policy in monitoring mode for a week or two to see how many genuine claims it would touch before enforcing it.