> 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/best-practices/preventing-fraud.md). # Preventing Fraud Every reward you pay is only worth it if a real new customer is on the other end. The short answer: leave Bloop's automatic fraud 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 — and use your offer settings to remove the incentive to cheat in the first place. This article explains how to treat fraud control as a budget control, then links the Bloop settings involved. The most common abuse is self-referral: one person posing as both referrer and referee to claim both sides of the deal. Heavy-handed blocking stops that but also frustrates genuine power users; the goal is to catch the few abusers without taxing the many honest customers. ### Let detection do the watching, then judge on evidence Instead of auditing every referred order, let Bloop watch for the patterns abuse leaves behind (self-referral email matches, repeated IPs, high volume in a week) and surface only the orders that deserve a second look — keep these signals on, they're your cheapest line of defence. A flag is a prompt to look, not a verdict: a power user on a shared office network can look a lot like collusion. **Trust** genuine referrers who keep tripping a signal for innocent reasons, **ban** only clear abusers, and judge each held case on its own evidence rather than rejecting automatically. See the [Fraud center](/referral-program/management/fraud-center.md) for the full signal breakdown and how to review a case. ### Remove the incentive to cheat at the source The cheapest fraud to prevent is the kind your offer never invited. Several offer-level choices quietly reduce abuse: * **A minimum purchase requirement** makes self-referral unprofitable, because the abuser has to spend real money to claim a reward worth less. * **A reward review period** adds a short delay before approval, giving signals time to surface before money moves. Suspicious orders are held separately regardless. * **A tighter audience** — for example restricting referring to prior buyers or a customer tag — narrows the pool of people who can game the program. Open wide at launch to gather data, then tighten only if abuse appears. ### Match scrutiny to risk Not every program needs the same vigilance. A high-value cash reward on a wide-open audience deserves close review; a modest store-credit reward gated to past customers carries far less risk and rarely needs hands-on attention. Calibrate your review effort to what a successful abuse would actually cost you. ### Set it up in Bloop * Review and resolve flagged orders in the [Fraud center](/referral-program/management/fraud-center.md). * Add minimums and a review period in [Set up referrer and referee rewards](/referral-program/rewards.md). * Tighten who can refer in [Target audience](/referral-program/target-audience.md). * To understand the patterns behind the flags, read [how to prevent referral fraud](https://bloop.plus/blog/referral-fraud/) and [what self-referral is](https://bloop.plus/blog/self-referral/). ### Related * [Best practices: designing your referral offer](/best-practices/designing-your-offer.md) * [Fraud center](/referral-program/management/fraud-center.md) * [How to prevent referral fraud](https://bloop.plus/blog/referral-fraud/) --- # 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/best-practices/preventing-fraud.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.