> For the complete documentation index, see [llms.txt](https://docs.bloop.plus/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bloop.plus/referral-program/management/fraud-center.md). # Fraud Center Catch self-referral and reward abuse before a reward leaves your account. Every reward you pay is only worth it if a real new customer is on the other end. The most common abuse is self-referral — one person playing both referrer and referee. The **Fraud center** watches for the patterns abuse leaves behind and surfaces only the referrers worth a second look, so you don't audit every referral to catch the few that matter. When a referred purchase trips a signal, Bloop holds the reward for **14 days**, tags the order in Shopify as `BLOOP suspicious referral`, and opens a case. Genuine referrals flow through untouched. > **Best practice:** Leave detection on so abuse is caught before a reward leaves your account, but judge each case on its evidence rather than rejecting on sight — a power user on a shared office network looks a lot like collusion. Ban only clear abusers. See [how to prevent referral fraud](https://bloop.plus/blog/referral-fraud/). ### The signals Bloop looks for | Signal | Shown as | What it catches | | --------------------------------------------- | ------------- | ------------------------------------------------------------------------------------ | | Self-referral (email) | Self Referral | Referrer and purchaser emails match once `+tag` aliases and dots are normalized | | Self-referral (email alias, different domain) | Self Referral | The same name before the `@`, on two different providers | | Self-referral (matching last name) | Self Referral | Referrer and purchaser share a last name, or a near-identical one | | Self-referral (matching address) | Self Referral | The referrer's default Shopify address matches the order's shipping address | | Same IP as referrer | Shared IP | Five or more referred purchases from one referrer sharing a client IP within 30 days | | High referral volume (7 days) | High volume | Seven or more referred purchases completed in a rolling week | The four self-referral signals are the strong ones — an alias address or a matching shipping address is a deliberate disguise a normal referral never produces. Shared IP and high volume are weaker: a household, an office network, or a genuinely viral advocate produce all three symptoms honestly. The shared-IP and high-volume reasons list the related order numbers, so you can open them and see whether the pattern looks organized or coincidental. > A matching address is worth more than a matching last name on its own. Families do refer each other, and that's usually a referral you're happy to pay for — the same household *and* the same shipping address is the combination that isn't. ### Block abuse before it reaches the queue Two preventive checks live in **Referral → Settings → Fraud prevention**, and they work differently from the Fraud center: instead of flagging a purchase for review, they stop the discount being claimed at all. | Check | What it does | | -------------- | ----------------------------------------------------------------------------------------- | | **IP address** | If the referrer and the referee share an IP address, the referee doesn't get the discount | | **Browser** | Stops a referrer following their own link and claiming the discount in the same browser | These are blunt by design, and that's the trade-off: the browser check catches the laziest self-referral with almost no collateral damage, while the IP check will also block a genuine referral between two people on the same home or office network. Turn on the browser check as a matter of course; weigh the IP check against how much of your audience shares a connection. They're the front door, not a replacement for the Fraud center — an abuser using a second browser and a phone's data connection walks past both, which is what the signals below are for. ### Work the queue The Fraud center lists suspicious referrers with the activity that flagged them, the total incentives at stake, and **days left to review**. Sort your attention by that last column: a case at 1 day left is about to become a paid reward whether you look at it or not. Open a referrer to see their flagged purchases — purchase ID, purchaser, signal type, days left — each with a link straight to the order in Shopify. The panel on the right shows their contact details, whether they're **Active** or **Banned**, and whether detection is **Enabled** or **Excluded** for them. You approve or reject the referrals themselves in [Referral orders](/referral-program/management/orders.md). Either decision closes the case here: approving records it as legitimate, rejecting confirms it as fraud. ### Reading the evidence | What you see | What to do | | ---------------------------------------------- | ------------------------------------------------------ | | Email match, same domain | Reject. Consider a ban if it repeats | | Email alias on a different domain | Reject — this takes effort to set up | | Matching address | Reject. It's the hardest signal to produce by accident | | Matching last name only | Look closer. Family referrals are usually real | | Shared IP only, unrelated real emails | Approve. It's a household or an office | | Shared IP **and** a self-referral signal | Reject — two weak signals reinforcing each other | | High volume, varied IPs and emails, real names | Approve. This is what success looks like | | High volume with repeated IPs or alias emails | Reject the batch and ban the referrer | When the evidence is ambiguous, approving is the gentler default. A rejected genuine advocate usually stops sharing entirely — that costs more than one undeserved reward. ### Ban a referrer **Ban** ends a referrer's participation. It's irreversible, and the modal makes you acknowledge that, because it does all of this at once: * Their referral link and referral code stop working. * No new referrals can be attributed to them. * Pending referred purchases are disqualified. * Purchases still inside the review period stop counting as referred. * Rewards that were waiting are never sent. Reserve it for a confirmed pattern: an exact email match, an alias address, or a repeat offender you've already rejected once. ### Exclude a referrer from detection The opposite case: a genuine customer who keeps tripping the shared-IP signal because their whole family orders from one router. **Exclude suspicious referral detection** on their profile turns the checks off for that person only — their future referrals stop being flagged, and everyone else's detection is unaffected. **Enable detection** puts them back. Use it for the customer you've already cleared twice. It's a tuning dial, not a reward — and a banned referrer can't be excluded, since there's nothing left to detect. ### Fraud history Every decision is logged: the date, the referrer's email, the signal type, the action taken, and whether the system or an admin took it. Search it by email. Read it when you want to know whether your team is rejecting too aggressively, or when a customer disputes a decision and you need the record. ### Common mistakes to avoid * **Rejecting on a single weak signal.** A shared IP alone is a household. Wait for something to corroborate it. * **Banning a good customer instead of excluding them from detection.** Ban is irreversible; exclusion is the right tool for a false positive. * **Letting the 14-day window lapse.** The hold expires into an approval — a flag nobody reads protects nothing. * **Treating a family referral as fraud.** A matching last name on its own is usually a real referral. ### Next steps * Approve or reject the individual orders in [Referral orders](/referral-program/management/orders.md). * See the broader stance in [preventing referral fraud without blocking real customers](/best-practices/preventing-fraud.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.bloop.plus/referral-program/management/fraud-center.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.