Fraud Center

Every reward you pay out is only worth it if a real new customer is on the other end. The fastest way to bleed a referral budget is abuse — most often self-referral, where one person poses as both referrer and referee to claim both sides of the deal. The Fraud center watches for the patterns abuse leaves behind and surfaces only the orders that deserve a second look, instead of trusting every referred order or making you audit them all.

When a referred purchase trips a signal, Bloop flags it, holds the reward for 14 days, and opens a case for your decision. Genuine referrals flow through untouched.

Referred customers are unusually valuable: Wharton research on roughly 10,000 accounts found them about 18% less likely to churn and worth more in margin over their lifetime (Schmitt, Skiera & Van den Bulte, Journal of Marketing, 2011). Fraud detection protects the budget that acquires those customers — but it cuts both ways. Over-block, and you turn away the genuine advocate whose referred friends would have been your best buyers. The Fraud center's job is to stop the abuser without insulting the advocate.

Best practice: Treat detection as a budget control, not a wall. Leave the automatic signals on so abuse is caught before a reward leaves your account, but review each held case on its evidence rather than rejecting on sight — a power user on a shared office network looks a lot like collusion. Trust genuine referrers who keep tripping a signal, and ban only clear abusers. To understand the patterns behind the flags, read how to prevent referral fraud and what self-referral is and why it happens.

How Bloop flags a suspicious referral

When a referred order comes in, Bloop checks it against several heuristics. If any trigger, the referral is marked suspicious. Each signal targets a different abuse pattern and carries a different weight of evidence.

Signal	What Bloop looks for	What it usually means	Default action
Self-referral email	Referrer and referee emails look like the same person after normalizing aliases	Strong: one person claiming both sides	Hold 14 days, open case — lean toward reject
Same IP, repeated	Several referred purchases for one referrer share the same IP in a recent window	Mixed: self-dealing, or a shared home/office network	Hold 14 days, open case — review before deciding
High volume in a week	One referrer drives an unusually high number of referred purchases in a rolling 7-day window	Mixed: an abuser, or a genuinely viral advocate	Hold 14 days, open case — investigate, don't auto-reject

The email signal most often means real fraud; the IP and volume signals are the ones most likely to catch an innocent customer. Read each flag for what kind of evidence it is before you act.

Email heuristics

Bloop compares the referrer's and referee's email addresses only when they share the same domain, then normalizes each to catch disguised matches:

• It lowercases the address, removes any +tag (so [email protected] and [email protected] are treated as the same), and strips dots from the local part for Gmail-style aliases.
• After normalizing, an exact match flags as self-referral.
• It also catches near-matches: a local part differing only by trailing digits (linh vs linh03), or two local parts more than 50% similar (duc.work vs duc.play).

This is the highest-signal check because the tricks it catches — +tag aliases, dot insertion, a trailing number — are deliberate disguises. A normal friend referral almost never produces two near-identical local parts on the same domain.

The rare false positive: two genuine people can share a surname-based email pattern (smith.j and smith.k at a family domain), or a couple might use addresses that look more than 50% similar. The signal surfaces them; your review separates the family from the fraudster.

IP signals

Bloop records the buyer's IP on each referred purchase. If a single referrer accumulates several referred purchases from the same IP address within the recent lookback window, that pattern is flagged as likely self-dealing or collusion.

This signal is most prone to false positives: a household, dorm, small office, or café Wi-Fi all present the same address. Treat an IP flag as "look closer," not "guilty." Pair it with the email signal — same IP and near-identical emails is a far stronger case than same IP alone.

Volume signals

A referrer who suddenly drives an unusual number of conversions in a rolling 7-day window gets flagged. The honest version is the customer who went viral — they posted their link somewhere it caught fire. The dishonest version is someone churning out fake referees. Volume alone proves nothing; it tells you to check how the referrals came in, not to assume the worst of your most enthusiastic advocate.

Reading a flag: signal, meaning, action

What you see	How to read it	What to do
Email exact/alias match, same domain	Almost certainly one person on both sides	Reject the referral; consider a ban if repeated
Same IP only, different real-looking emails	Likely a shared network (home, office, café)	Approve unless something else corroborates fraud
Same IP and similar emails	Strong corroboration — two weak signals reinforcing	Reject; this is the classic self-referral shape
High volume, varied IPs and emails, real names	A genuine advocate who went viral	Approve, and consider featuring them
High volume, repeated IPs or alias emails	Manufactured referees	Reject the batch; ban the referrer
A known good customer tripping a signal again	A repeat false positive	Approve, then Trust them so it stops

What happens to a flagged referral

When a referral is flagged, Bloop acts automatically:

1. The referrer reward is placed on a 14-day hold instead of being issued.
2. The order is tagged in Shopify (BLOOP suspicious referral) so you can spot it there too.
3. A suspicious case is opened for that referrer with status Pending review, and the evidence is recorded.

If you do nothing, the hold expires and the reward follows your normal rules — so review flagged cases before the 14 days run out.

Review suspicious cases

The Fraud center lists referrers with pending cases, sorted by how soon their review window closes:

1. Open the Fraud center and review the list of flagged referrers and how many days are left to review each.
2. Open a referrer to see the flagged referrals, the reasons, and the matching evidence (the colliding emails or the orders that shared an IP).
3. Decide on each referral:

   • Approve if it is legitimate. The hold clears, the case is marked approved, and the reward proceeds.
   • Reject if it is fraud. The referral is disqualified, no reward is issued, and the case is confirmed as fraud.

Approving or rejecting from the Referral orders view closes the same case — the two views stay in sync.

A worked example

The values below are illustrative — they show how to reason about a flagged case, not measured Bloop results.

A case appears for a referrer, Tom, with two flagged referrals and seven days left on the hold. You open it:

1. Read the evidence. Both referees ordered from the same IP address as Tom, and one referee's email is [email protected] against Tom's own [email protected]. Two signals are firing: same IP, and an exact alias match after normalization.
2. Weigh the flags together. The IP alone you might forgive — but the +ref alias on the identical local part is the deliberate-disguise pattern the email heuristic exists to catch. Two corroborating signals turn a maybe into a near-certainty.
3. Reject and ban. You reject both referrals — no rewards are issued — and ban Tom so he cannot earn future rewards. The action is written to the history and to Tom's customer activity.

Now the false-positive version. A case appears for Priya, flagged on the IP signal alone: three of her referees ordered from the same address. But the emails are unrelated real names on different domains, and Priya is a long-standing customer. The likely truth is she shares a flat or an office. You approve all three referrals, then Trust Priya so her future referrals skip the heuristics — sparing her the indignity of repeated suspicion for living with people who like your store.

The two cases use the same tool to reach opposite, correct conclusions: the signals start the conversation; the evidence ends it.

Balancing fraud control against blocking real customers

The expensive failure mode is not paying out a fraudulent reward — that costs you one discount. The expensive failure mode is rejecting a genuine advocate's referrals and souring the relationship, because referred customers are precisely the high-value, low-churn buyers research describes (Schmitt et al., 2011). One angry advocate who stops sharing can cost you a stream of those customers, which dwarfs a single mistaken payout.

That asymmetry sets the default: when a flag is ambiguous, lean toward approving and use Trust to stop the nagging. Reserve rejection and bans for cases where the evidence is clear — an exact email alias, two corroborating signals, or a repeated pattern across many orders. Leave detection on for everyone (your only cheap window to catch abuse before money leaves), but treat each case as a judgement, not a verdict. The wider playbook lives in preventing referral fraud without blocking real customers.

Ban a referrer

If a referrer is clearly abusing the program, ban them. A banned referrer can no longer receive rewards. Banning records an action in the history and writes a Banned entry to the customer's activity. Reserve it for clear cases — an exact self-referral match, or a repeated pattern you have confirmed — rather than a single ambiguous flag.

Trust a referrer

For a referrer you know is genuine but who keeps tripping a signal (for example, a power user on a shared office network), you can turn off suspicious detection for just that referrer. Their future referrals skip the heuristics. Trust is the right tool for the repeat false positive: it spares a good customer from being flagged again without weakening detection for everyone else.

Action history

Every fraud decision is logged for an audit trail. The history records the action type — referral marked suspicious, approved, disqualified, referrer banned, or detection enabled/disabled — along with who took it (the system or an admin) and when. You can filter by action type or referrer email. This lets you review whether your team is rejecting too aggressively, and gives you a record to point to if a customer disputes a decision.

Common mistakes to avoid

• Rejecting on a single weak signal. A shared IP alone is usually a household or office, not collusion. Wait for a second corroborating signal before rejecting.
• Banning instead of trusting a good customer. A genuine advocate who keeps tripping the IP signal should be Trusted, not banned. Banning your best referrer is the most expensive mistake the Fraud center makes possible.
• Ignoring the 14-day window. A flag only protects you if you decide inside it. Let the window lapse and the reward follows your normal rules — abuse included.
• Turning detection off to reduce the queue. Switching off the signals does not make fraud go away; it just stops you seeing it until the budget is gone.
• Treating every flag as guilt. The signals are a triage tool. The email match is strong evidence; IP and volume are prompts to look closer, not convictions.

Next steps

• Decide individual orders in Referral orders.
• See the broader stance in preventing referral fraud without blocking real customers.
• Understand the broader topic in How to prevent referral fraud.
• Learn why self-referral is the most common abuse in What is self-referral.