Stripe Radar Rule Drift: How to Detect and Fix Declining Fraud Rule Performance

Fraudsters constantly adapt their tactics, which means the Stripe Radar rules you set up six months ago might not be catching the same threats today. This gradual decline in rule effectiveness is called rule drift, and it silently erodes your fraud protection while increasing false declines and missed fraud. Understanding how to detect Stripe Radar rule drift is essential for any business processing payments online.

How Stripe Radar Evaluates Rules

Stripe Radar uses a priority-based system to evaluate each payment against your custom rules. The evaluation follows a clear sequence: Radar first processes rules requesting 3D Secure authentication, then evaluates any block or review rules, and finally applies allow rules. Critically, when a payment matches the criteria for a rule, Radar takes the appropriate action and discontinues evaluation¹. This means the order and specificity of your rules directly impacts which threats get caught.

Block rules advise Stripe to always block a payment. If a payment matches the criteria in a block rule, Stripe rejects it and it's not subject to further rules evaluation². By contrast, allow rules permit payments to be processed, and payments that fall under allow rules aren't evaluated against any block or review rules³. Understanding this flow is foundational to detecting when something goes wrong.

Understanding the Signs of Rule Drift

Rule drift typically manifests through three warning signals. First, you might notice an increase in fraud rates despite stable transaction volumes. Second, false decline rates climb as legitimate customers get rejected. Third, your rules begin matching patterns they weren't designed for, either becoming too broad or missing entirely new attack vectors.

Worldwide, fraud costs businesses more than an estimated $20 billion annually⁴, making the stakes of neglected rule maintenance significant. But equally damaging is the customer experience impact: in a recent survey, 33% of consumers said they wouldn't shop again at a business after a false decline⁵. This means rule drift doesn't just let fraud through—it actively drives away good customers.

Monitoring Risk Score Distribution

Stripe Radar assigns each payment a numerical risk score between 0 and 99, where 0 is the lowest risk and 99 is the highest⁶. If you notice your blocked payments clustering at the same risk levels month after month while fraud is slipping through at different score ranges, your rules haven't adapted to new fraud patterns. The distribution of risk scores across your transaction portfolio should shift as fraud tactics evolve.

Stripe Radar also assigns each payment a numerical fraudulent dispute score between 0 and 99⁷ and a numerical early fraud warning score between 0 and 99⁸. Comparing these scores across disputed transactions reveals whether your rules are catching the same risk patterns that lead to actual fraud losses. When these scores diverge from your rule thresholds, drift has occurred.

Using Historical Payment Data

Before you add or update a rule, Stripe searches for historical live mode payments that match the rule criteria⁹. This feature is invaluable for drift detection: if your existing rules would have matched different payments six months ago versus today, that pattern shift signals drift. You can use this historical matching to understand how your rule coverage has narrowed or shifted over time.

Stripe also provides filtered views of key payment categories. You can examine disputed payments and early fraud warnings separately from standard transaction data. Analyzing these filtered views reveals whether fraud is increasingly falling outside your rule criteria. Payments that were refunded¹⁰ also offer insight: some refunds stem from fraud that slipped past rules, indicating coverage gaps.

Analyzing Blocked and Allowed Payment Patterns

Stripe categorizes payments that were either blocked by Radar, blocked by Stripe, or declined by issuers¹¹ differently from those blocked by your custom rules. When your custom rules stop matching the fraud you're seeing, you'll notice transactions appearing in these broader categories instead of being caught by your specific rule logic.

Meanwhile, succeeded payments that are successfully processed but haven't yet been identified as fraudulent or refunded represent your rule effectiveness baseline. A growing number of these payments eventually becoming fraudulent indicates your rules are losing their predictive power. Radar evaluates each payment against the rules you create according to their action type¹², so monitoring which category transactions fall into reveals exactly where your rules are failing.

Testing Rule Effectiveness Regularly

Stripe Radar for Platforms uses machine learning from millions of processed payments¹³ to generate risk scores for individual transactions and connected accounts as a whole. This massive data foundation means fraud patterns can shift faster than manual rule updates. It's uncommon to find a perfect rule that only blocks fraudulent payments or only allows good payments¹⁴, which is why regular testing matters.

Your rules should leverage this data by checking whether cards have been seen before, whether shipping and billing addresses align with card history, and whether transaction amounts match typical behavior patterns for each customer segment.

Common Fraud Patterns Indicating Drift

When fraud patterns shift, you'll often see new attack vectors emerge that your existing rules don't address. These include small repeated transactions in the 0 USD to 5 USD range from stolen credit cards, which suggest card testing activity. You might also see processing patterns suggesting several stolen credit cards being used in a short amount of time with the intent of cashing out¹⁵. Additionally, businesses might attempt to scam legitimate cardholders by tricking them into making purchases with no intention to fulfill or with low quality goods.

If your rules were built to catch the first pattern but fraud has shifted to the second, your protection has effectively drifted. Effective December 17, 2024, Stripe began showing certain rules to new customers and existing customers who haven't used the legacy CVC or AVS rules¹⁶, reflecting how Stripe continuously updates its default protections as threats evolve.

Best Practices for Drift Detection

Schedule monthly reviews of your rule performance metrics. Compare current fraud rates, false decline rates, and rule match rates against historical baselines. When any metric shifts significantly without a corresponding business change, investigate whether rule drift is the cause.

Risk score thresholds that worked last quarter may not align with current fraud distribution. Elevated risk, or a score of 50-89, indicates a probability of 50% to 89%¹⁷ for certain outcomes, but the underlying fraud population may have changed. Your thresholds should evolve with these distributions.

Radar is deprecating the high risk block rule that uses risk score to block payments¹⁸, with existing Radar for Fraud Teams users able to change blocking preferences using risk settings¹⁹ instead of the default risk thresholds beginning March 1, 2026. This transition itself will introduce drift if you rely solely on default thresholds without adjusting your custom rules accordingly.

Conclusion

Stripe Radar rule drift is a silent threat that accumulates over time until your fraud protection becomes either too aggressive or full of gaps. By monitoring risk score distributions, analyzing historical payment pattern matches, tracking which payment categories grow or shrink, and regularly testing rule effectiveness against current fraud patterns, you can detect drift before it significantly impacts your business. The combination of Stripe's machine learning foundation and your custom rule logic requires ongoing attention to maintain the balance between blocking fraud and welcoming legitimate customers.

Sources

1. “If a payment matches the criteria for a rule, Radar takes the appropriate action and discontinues evaluation.” — https://docs.stripe.com/radar/rules/reference  ·  archive
2. “Block rules advise Stripe to always block a payment. If a payment matches the criteria in a block rule, Stripe rejects it and it's not subject to further rules evaluation.” — https://docs.stripe.com/radar/rules/reference  ·  archive
3. “Allow: Rules that allow a payment to be processed. Payments that fall under allow rules aren't evaluated against any block or review rules.” — https://docs.stripe.com/radar/rules/reference  ·  archive
4. “Worldwide, fraud costs businesses more than an estimated $20 billion annually.” — https://stripe.com/guides/primer-on-machine-learning-for-fraud-protection  ·  archive
5. “In fact, in a recent survey, 33% of consumers said they wouldn't shop again at a business after a false decline.” — https://stripe.com/guides/primer-on-machine-learning-for-fraud-protection  ·  archive
6. “Stripe Radar gives each payment a numerical risk score between 0 and 99, where 0 is the lowest risk and 99 is the highest.” — https://docs.stripe.com/radar/risk-settings  ·  archive
7. “Stripe Radar assigns each payment a numerical fraudulent dispute score between 0 and 99.” — https://docs.stripe.com/radar/risk-settings  ·  archive
8. “Stripe Radar assigns each payment a numerical early fraud warning score between 0 and 99.” — https://docs.stripe.com/radar/risk-settings  ·  archive
9. “Before you add or update a rule, we'll search for historical live mode payments that match the rule criteria.” — https://docs.stripe.com/radar/testing  ·  archive
10. “Refunded payments: Payments that were refunded.” — https://docs.stripe.com/radar/testing  ·  archive
11. “Blocked and failed payments: Payments that were either blocked by Radar, blocked by Stripe, or declined by issuers.” — https://docs.stripe.com/radar/testing  ·  archive
12. “If a payment matches the criteria for a rule, Radar takes the appropriate action and discontinues evaluation.” — https://docs.stripe.com/radar/rules/reference  ·  archive
13. “Radar for Platforms uses machine learning from millions of processed payments to generate risk scores for individual transactions and connected accounts as a whole.” — https://docs.stripe.com/radar/radar-for-platforms  ·  archive
14. “It's uncommon to find a perfect rule that only blocks fraudulent payments or only allows good payments.” — https://docs.stripe.com/radar/testing  ·  archive
15. “fraud_card_casher: The business's behavior suggests they're processing several stolen credit cards in a short amount of time with the intent of cashing out.” — https://docs.stripe.com/radar/radar-for-platforms  ·  archive
16. “Effective December 17, 2024, the Dashboard shows these rules to new customers and existing customers who haven't used the legacy CVC or AVS rules.” — https://docs.stripe.com/radar/rules  ·  archive
17. “elevated risk, or a score of 50-89, indicates a probability of 50% to 89%.” — https://docs.stripe.com/radar/radar-for-platforms  ·  archive
18. “Radar is deprecating the high risk block rule that uses risk score to block payments.” — https://docs.stripe.com/radar/risk-settings  ·  archive
19. “Beginning March 1, 2026, existing Radar for Fraud Teams users can change blocking preferences using risk settings, instead of the default risk thresholds.” — https://docs.stripe.com/radar/risk-settings  ·  archive