Stripe Radar Rules: 5 Practical Tips

6 min readJul 29, 2020

If you have a one simple ecommerce website with a limited set of goods, then it could be meaningless to worry about Radar rules adjustment. Default ML engine works quite well. But in many other cases you need to pay attention to some common fraud cases and ways to mitigate them. Furthermore, any improvements around anti-fraud system help you to automate routine manual work and reduce operating expenses.

BTW Your manager can ask you what the level of fraud is acceptable for the company. At first glance it entirely depends on executives and acceptable risks. But in reality, there is other factor.

Dispute activity above 0.75% is generally considered excessive, although this varies by card network. Excessive dispute activity not only affects your ability to process with Stripe, but with other processors as well — and can even result in fines from the card networks.

From <https://stripe.com/docs/disputes/monitoring-programs>

Payment processors don’t like merchants whose don’t care about protection from fraud. In their view a merchant is primarily responsible for related risks. Beware of these monitoring programs!

Here the list of must have actions around Stripe Radar Rules.

1. Apply a consistent approach to the tuning

It’s mistake to think that you need just enable some rules and forget about it. Unfortunately, security is a process and it requires constant efforts. This simple workflow will save lots of your time during work on anti-fraud improvements.

Here the sample of such approach. I’ll explain these steps in details. Let’s imagine we have an ecommerce in the Canada with local customers mostly.

Plan — let’s assume that customers should use Mastercard or Visa but not American Express, JCB or UnionPay. Last three are not popular in that region. Customers’ cards should also be issued from CA banks. Customers’ IP addresses are likely to be Canadian.

Based on this assumptions we can create these two simple rules:

review if :card_country: != ‘CA’ and :card_brand: in (‘amex’, ‘unknown’, ‘jcb’, ‘cup’)

— put the payment for manual review if customer’s card has not been issued by an Canadian bank and card brand is American Express, JCB, UnionPay or not defined.

review if :card_country: != ‘CA’ and :ip_country: != ‘CA’

— put the payment for manual review if customer’s card has not been issued in Canada and the IP address from which the payment originates is not from Canada.

Test — Test them in “Matching payment attempts over the past six months” tool. Radar provides the ability to test a rule before implementation for last six months. It works based on history of payments and charge attempts. It doesn’t make sense to use it immediately after Stripe integration. Need to collect some live data about customers’ behaviour. But it definitely help you in avoiding false-positive triggers.

Implement & Review — if ratio fraud/valid payments is applicable for you, then run them in review mode (monitoring). Afterwards check them for false positive cases. It’s a good practice to create a dedicated workflow for your anti-fraud team to manual review of all suspicious payments under this rule.

If there are too many captured payments under one rule then use a BI tool, apply sampling or just make the rule more specific.

Improve — finally the rule should be switched to deny mode, 3DS check mode or just removed. It’s rare case when the rule remains in review mode for a long time. Cause it increases the burden on anti-fraud team.

Also don’t forget to minimize impact on legitimate users. This is the main idea of such improvements.

Keep in mind that people’s behavior is being changed constantly and the rules which works fine today may not do the same a few months later. Rules’ re-assessment is vital part of improvements.

2. Try the combination of rules

At-first glance it may make sense to just block all payments by obviously fraud criterias. For example by anonymous proxies, one-time email, etc. But in reality, there are plenty of valid customers behind these anonymizer tools. For example, office worker can use proxy to bypass corporate filters and shopping from workplace. It’s reasonable to think about it in advance and don’t block based on single criteria.

The rules creation approach which I applied to in my job.

Identify rules which show highest amount of disputes
Test them in various combinations
Minimize false-positive cases

I noted earlier that you can test rule before implementing. But unfortunately, Stripe doesn’t allow rule’s test automation. It’s supposed that you test it manually. As a result it’s huge amount of routine work. To reduce it I recommend to separate rule’s attributes by categories showed below. The result of tests should also being recorded. It will help you compare them and make the right choice.

Start test from the most probable triggers and go through all possible combinations.

Certainly fraud(1) and Likely fraud(1)
Certainly fraud(1) and Likely fraud(1) and Possible Fraud (1)
Certainly fraud(1) and Likely fraud(1) and Possible Fraud (2)
Certainly fraud(1) and Likely fraud(1) and Possible Fraud (3)
…
Certainly fraud(1) and Likely fraud(2) and Possible Fraud (1)
…

3. Send metadata to Radar

Stripe doesn’t know anything about sold items or customer account details. If you provide these associated metadata to Stripe then you can use it in Radar rules. Like this:

Request 3D Secure if ::item_category:: in (‘electronic’, ‘jewelry’) and :amount_in_usd: > 300

Here, you should be very careful and well aware of what data you can send to third parties. In some cases this can be interpreted as violating local laws and compliance rules.

4. Analyze disputed data

Extract all data from disputes and run it in some BI tool like QlikView for example. This will help you find anomalies or identify some common fraud pattern. Based on these data you can build the mitigation rules in Radar.

5. Push 3DS whenever possible

3DS (strong customer authentication) provides the liablity shift and in some regions it’s a compliance requirement. For merchant is better to provide a chance to sell through 3DS then just reject the suspicious payment. Also remember that rejected payments often doesn’t show the reason to visitor which drastically reduce customer experience. Rule example:

Request 3D Secure if payment has a risk score of 65 or higher

In general, it’s a good practice to keep track of some key indicators of anti-fraud efficiency.

High risks payments. Look at spikes and related events like large CHD data breach.
Do a monthly report which include dispute activity and relation won/lost disputes. The rules may be well chosen but human factor can loss all benefits from them.
Decline rate. Corresponding analysis can help you identify false-positive and false negative errors in anti-fraud system.
To get a big picture you can use Radar reports (Stripe Dashboard > Reports > Radar)

By the way, don’t forget an important rule — analytics brings results if it influences on your business. Otherwise it’s just fun.

In the end of this guidance I share the set of some efficient rules which provide low false-positive rate. Please use them at your own risk.

payment has a risk score of 65 or higher:risk_level: = ‘elevated’ or :risk_level: = ‘highest’:card_country: != :ip_country: and :is_anonymous_ip::card_country: != ‘US’ and :amount_in_usd: >= 300 and :is_anonymous_ip::card_3d_secure_support: = ‘not_supported’ and :is_anonymous_ip::cvc_check: in(‘fail’, ‘unchecked’, ‘unavailable’, ‘not_provided’) and :is_anonymous_ip::card_funding: = ‘prepaid’ and :is_anonymous_ip::card_3d_secure_support: = ‘optional’ and :charge_attempts_per_ip_address_hourly: > 3:charge_attempts_per_card_number_daily: > 5 and :charge_attempts_per_card_number_hourly: > 3:charge_attempts_per_ip_address_daily: > 5 and :charge_attempts_per_ip_address_hourly: > 3:charge_attempts_per_card_number_daily: > 5 and :charge_attempts_per_card_number_hourly: > 3:blocks_per_ip_address_daily: > 3 and :blocks_per_ip_address_hourly: > 2:blocks_per_card_number_daily: > 2 and :blocks_per_card_number_hourly: > 1

References