> 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

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 posing as both referrer and referee. The Fraud center watches for the patterns abuse leaves behind and surfaces only the orders worth a second look, instead of making you audit every referral.

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.

> **Best practice:** Leave detection 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 can look a lot like collusion. **Trust** genuine referrers who keep tripping a signal, and **ban** only clear abusers. See [how to prevent referral fraud](https://bloop.plus/blog/referral-fraud/).

### How Bloop flags a suspicious referral

| Signal                | What it catches                                                                 | Default action                                |
| --------------------- | ------------------------------------------------------------------------------- | --------------------------------------------- |
| Self-referral email   | Referrer and referee emails look like the same person after normalizing aliases | Hold 14 days — lean toward reject             |
| Same IP, repeated     | Several referred purchases from one referrer share the same IP                  | Hold 14 days — review before deciding         |
| High volume in a week | One referrer drives an unusually high number of purchases in 7 days             | Hold 14 days — investigate, don't auto-reject |

The email signal most often means real fraud; IP and volume are more likely to catch an innocent customer (a shared household or office network, or a genuinely viral advocate).

#### Email heuristics

Bloop compares referrer and referee emails on the same domain, normalizing for `+tag` aliases and dot variations (`me+promo@gmail.com` = `me@gmail.com`), plus near-matches like trailing digits (`linh` vs `linh03`). An exact or near-match after normalizing flags as self-referral — this is the strongest signal, since these are deliberate disguises a normal referral wouldn't produce.

#### IP and volume signals

A shared IP across several of one referrer's purchases, or an unusual spike in volume within a week, both get flagged — but both are prone to false positives (a shared network, or a customer who genuinely went viral). Treat these as "look closer," not "guilty," especially alone.

### Reading a flag

| What you see                                  | What to do                                         |
| --------------------------------------------- | -------------------------------------------------- |
| Email match, same domain                      | Reject; consider a ban if repeated                 |
| Same IP only, real-looking emails             | Approve unless something else corroborates fraud   |
| Same IP **and** similar emails                | Reject — two weak signals reinforcing each other   |
| High volume, varied IPs/emails, real names    | Approve — likely a genuine advocate who went viral |
| High volume, repeated IPs or alias emails     | Reject the batch; ban the referrer                 |
| A known good customer tripping a signal again | Approve, then **Trust** them                       |

### What happens to a flagged referral

1. The reward goes on a **14-day hold** instead of issuing.
2. The order is tagged in Shopify (`BLOOP suspicious referral`).
3. A case opens with status **Pending review**.

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

### Review suspicious cases

1. Open the **Fraud center** — cases are sorted by how soon their review window closes.
2. Open a referrer to see the flagged referrals and the evidence (colliding emails, shared IPs).
3. **Approve** if legitimate, or **Reject** if it's fraud. Approving or rejecting from [Referral orders](/referral-program/management/orders.md) closes the same case.

**Example:** Tom's case shows two referees sharing his IP, and one with an email alias (`tom.smith+ref@gmail.com` vs `tom.smith@gmail.com`) — two corroborating signals, so you reject and ban him. Priya's case shows only a shared IP across real, unrelated emails — likely a shared flat or office, so you approve and **Trust** her so it stops recurring.

### Ban or trust a referrer

**Ban** a referrer who is clearly abusing the program — they can no longer receive rewards. Reserve it for clear cases: an exact email match, or a confirmed repeated pattern.

**Trust** a referrer you know is genuine but who keeps tripping a signal (like a shared office network) — their future referrals skip the heuristics, sparing them repeat suspicion without weakening detection for anyone else.

### Action history

Every fraud decision is logged — the action, who took it (system or admin), and when — filterable by type or referrer email. Use it to check whether your team is rejecting too aggressively, or as a record 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.
* **Banning instead of trusting a good customer.** A genuine advocate who keeps tripping the IP signal should be Trusted, not banned.
* **Ignoring the 14-day window.** Let it lapse and the reward follows your normal rules — abuse included.

### Next steps

* Decide 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=<question>&goal=<endgoal>
```

`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.