Fraud rules that do not destroy good customers

Ask any fraud team about their worst week of the year, and most will describe a major sales event: Black Friday, a flash sale, a viral product moment. These are exactly the periods when naive fraud rules do the most damage, because the same behavioural spikes that indicate fraud — rapid repeat purchases, new devices, unusual order values — also describe completely legitimate, high-intent customers responding to a promotion.

Why naive velocity rules backfire at peak

A simple velocity rule ("block if more than N transactions from this customer in M minutes") cannot distinguish between a fraud ring testing stolen cards and a genuine customer buying gifts for several family members during a sale. Applied bluntly, it blocks both, and the false-positive damage is concentrated exactly when your most valuable, highest-intent traffic is arriving. The revenue and reputational cost of blocking good customers during a peak sale event is often larger than the fraud loss the rule was designed to prevent.

Building a layered signal approach

Behavioural signals

Purchase history, browsing behaviour prior to checkout, and typing or navigation patterns provide much richer signal than transaction velocity alone. A returning customer with two years of consistent purchase history behaves very differently, even during an anomalous spike, from a brand-new account making its first purchase.

Device intelligence

Device fingerprinting, reputation scoring for the device and network, and detection of emulators or known fraud tooling add a layer of signal that is much harder for fraudsters to fake convincingly than transaction metadata alone.

Graduated step-ups

Rather than a binary approve-or-block decision, graduated step-up authentication — an additional verification step for genuinely ambiguous cases — lets legitimate customers continue with modest extra friction, while still meaningfully raising the cost of fraud for actual bad actors.

Allow-lists and analyst queues for grey cases

Not every ambiguous transaction should be resolved purely algorithmically. Allow-lists for known trusted customers or corporate accounts prevent recurring false positives on relationships you already trust. For the genuinely grey cases that remain, human analyst review queues — resolved quickly, with clear service-level targets — catch nuance that any rule set alone will miss, particularly around emerging fraud patterns that historical models have not yet learned.

Versioning and measuring rule sets properly

Fraud rules that are never versioned or measured tend to accumulate indefinitely, with nobody able to say confidently which rules are still earning their keep and which are quietly generating false positives with no corresponding fraud prevention benefit. Effective programmes version every rule set change, measure false positive rates by customer segment (not just in aggregate), and retire or retune rules that are underperforming.

Giving operations real tools

• Give fraud operations staff the ability to release incorrectly held transactions without filing an engineering ticket.
• Segment false-positive measurement by customer tenure, order value and channel, not just an overall rate.
• Maintain allow-lists for verified trusted customers and review them periodically for staleness.
• Version every rule set change and retain the ability to roll back quickly if false positives spike.
• Set clear service-level targets for analyst review queues, especially during known peak sales periods.

Fraud as an operations product

The organisations that manage this trade-off best treat fraud prevention as an operations product with its own roadmap, metrics and dedicated ownership — not as a static rule engine configured once at launch and left alone. Fraud patterns evolve constantly, and a rule set frozen in time degrades in both directions: missing new fraud patterns while continuing to falsely flag legitimate behaviour that has simply become more common.

The goal of fraud prevention is not zero fraud. It is the lowest total cost of fraud and false positives combined.

Preparing specifically for known peak events

Sales peaks are, by definition, predictable in advance — a retailer knows when Black Friday is coming — which means fraud teams have no excuse for treating peak-period false positives as an unavoidable surprise. Ahead of any known peak, review and temporarily adjust rule thresholds that are most prone to false positives under high-intent conditions, pre-stage additional analyst review capacity, and communicate expected volume patterns to the fraud team so anomaly detection baselines are not thrown off by legitimate demand spikes.

After each peak event, run a structured retrospective specifically on false positive cases, not just fraud losses, since the false positive cost is often invisible in a standard fraud-loss report but very visible in customer complaints and abandoned carts. This retrospective discipline is what turns each peak into an improvement cycle for the next one, rather than a repeated, unexamined pain point.

Key takeaways

• Naive velocity rules cause the most damage exactly during high-intent sales peaks.
• Behavioural and device signals distinguish fraud from legitimate spikes far better than velocity alone.
• Graduated step-ups and analyst queues handle ambiguous cases better than binary block decisions.
• Version and measure false positives by segment; retire rules that no longer earn their keep.
• Treat fraud prevention as an operations product with dedicated ownership, not a static configuration.