Affiliate fraud detection using your own data

Start with your own data

Affiliate fraud detection is sold as a specialist product, and at high volume it is one. But the majority of what advertisers lose is caught by looking carefully at data already sitting in the tracking platform and the CRM.

The principle is simple: fraud has to produce a number somewhere that real behaviour would not produce. You are looking for distributions that are too clean, too fast, or too concentrated.

Six signals worth checking weekly

• Click-to-conversion time. Real buyers take a spread of seconds to hours. A partner whose conversions cluster in a two-second band is not sending buyers.
• Conversion rate outliers. A partner converting at several times the program average, sustained, is either exceptional or manufacturing conversions. Both deserve a conversation.
• Refund and chargeback concentration. Fraudulent volume frequently converts well and refunds badly. Always evaluate partners net of refunds, never on gross conversions.
• Repeated identifiers. The same device fingerprint, IP range, email pattern or card BIN appearing across many conversions from one partner.
• Geographic mismatch. Conversions from geographies the offer is not targeted at, or that do not match the billing details on the order.
• Sub-ID entropy. Real traffic produces messy, varied sub-ID values. Sequential or repeating sub-IDs mean the values are being generated rather than passed through.

Thresholds I actually use

These are starting points, not universal truths — calibrate them to your own offer within the first month.

Investigate any partner whose median click-to-conversion time is under ten seconds, whose conversion rate exceeds three times the program median for a full week, or whose refund rate is more than double the program average. Investigate immediately, without waiting for the payout cycle, when more than a small share of a partner's conversions share a single device fingerprint or IP.

Structural defences that prevent more than detection catches

• Pay on a terminal order status, after the refund window where your economics allow it, rather than on order creation.
• Use server-side postbacks exclusively for payable events, so a conversion cannot be triggered by loading a page.
• Cap every new partner during a soft launch and lift the cap only on clean data.
• Make deduplication real by enforcing unique order identifiers between environments.
• Write the pause and clawback rules into the partner agreement before you need to use them.

How to handle a suspect partner

Do not accuse. Cap the partner, gather a week of data, and open the conversation with specifics: the metric, the comparison to program median, and the window. Legitimate partners with unusual numbers usually have an explanation, and the good ones respect an advertiser who monitors properly.

Keep the evidence. A documented threshold, a dated dataset and a written rule turn a dispute into a short conversation. Without them, withholding payment is a reputational risk regardless of whether you were right.

When a fraud vendor is justified

Bring in a dedicated vendor when volume makes manual review impractical, when you are running broad open networks rather than direct partners, or when sophisticated device-level spoofing is defeating the checks above. Below that, a vendor mostly duplicates work your own data already supports — and it will not help at all if your tracking layer is unreliable to begin with.