Best Stripe Radar Fraud Strategy

The following post will review strategies for Radar as an overall product and then for Stripe users on managing fraud efficiently. Throughout the years, Stripe Radar has grown to become a comprehensive product with improved risk scores and continues to add features. While the latest one with AI rule assistance is more of a letdown for advanced users in day-to-day usage ((1) Stripe on X: "We're building a new feature for Stripe Radar. 📡 You'll soon be able to use natural language to create complex fraud prevention rules. https://t.co/JRqgSqAfkG" / X) they continue to add more attributes listed here which are critical to stopping evolving fraud Supported attributes | Stripe Documentation. If you understand fraud well, you know which attributes are vital in creating rules and which are more or less worthless. Instead of making it easier to generate rules for Radar, which sometimes leads to more false blocks, it's better to thoroughly understand all the logic and use a cascading system of 3DS -> Review -> Block when developing and releasing rules. That way, you specifically target fraud and know if it will cause unnecessary revenue loss. There is a delicate balance between fraud prevention and allowing more payments, but we tend to see the scale tip towards more revenue, which makes perfect business sense. For example, if you read this thread: Stripe is PayPal circa 2010 | Hacker News (ycombinator.com) you will see many people complain about fraud from a few years back. Still, people must realize that Stripe Radar for teams is critical if you sell over a few thousand USD daily. Unfortunately, we have seen too many businesses growing quickly but receiving no alerts from Stripe that it is probably a good idea to turn on Radar, or else they are in for many disputes. Also, hiring a professional or spending at least one week or more tuning and optimizing your rules is necessary. It isn't a feature you turn on and forget since fraud is dynamic and requires constant attention. You eventually will get into a rhythm where it becomes easier than playing whack-a-mole with less than 1 hour a week dedicated to monitoring.

One idea we hope for their product is to allow using more rule references that use the Stripe network-level fraud signals. Unfortunately, very few signals are available for all Stripe customers, and we expect this to be part of some privacy restrictions. Another critical signal missing is related customers and payment counts from rules. Bots commit a lot of fraud, so it is necessary to be able to act against automated behavior that is already related to other fraud types. As every company wants to integrate LLMs into their products nowadays, we see actual value if prompts could be used against specific customer data. i.e. (Radar, tell me if this cardholder's name is gibberish or real, respond with true or false. / Radar, tell me if this billing address exists and if it is a business or residential address.). This logic could be part of a Radar rule when bots start showing specific patterns. This type of logic could be done earlier in a payment flow, but for merchants using low code integrations, the card name is first seen on Stripe's servers. Lastly, having better intelligence on specific card Bins is critical to understanding what might happen with a particular bank. Using bin lookup services is inconvenient, and getting a risk score from the bank would be an interesting statistic. A sudden surge of charges from a certain card bin should be met with skepticism, but there are no easy ways to understand the risk across Stripe's platform. There is plenty of room for improvement with Stripe, but it is gradually changing to meet enterprise needs and small startups. Also, no matter how much Stripe trains its models, it is impossible to trust all the scoring and decisions. There will always be outliers and fraudsters who find sneaky ways around the algorithms to commit fraud. The hope is that Radar can be a trustworthy leading fraud protection service, and ancillary providers like Sift and Seon can be used for more extreme fraud scenarios.

Now that we've explored some strategies for Radar as a Stripe product let's delve into different fraud management strategies. We'll cover these strategies at a high level and then discuss some new methods that haven't been widely discussed online. Unfortunately, we can't share all the latest recommended radar rules, even though it's fascinating to see fraudsters work around them. In one scenario, we actively monitored a fraud ring and, in real-time, added rules that were discussed in their chat about being 'patched'. It took almost 100 new Radar rules to go from thousands of disputes to less than 100, avoiding penalty fees and keeping the account open. Like weeds found on your lawn, novel threats must be kept in check and maintained, as they will randomly appear. Envision your house as the gameboard that encompasses your Stripe account and business. For more security, you can have multiple layers to prevent an intruder from getting past your defenses. First is the fence; this can be friction at signup or checkout. Next, your security cameras identify nearby threats, which can be AI models or other 3rd party intelligence tools like ipapi.is. Ensure you have an excellent integration status. Send complete fraud signals | Stripe Documentation and include additional metadata with each customer and payment so they can be used later during actual payment screening. Metadata is a little talked about feature but can provide critical insight such as mouse usage behavior, number of clicks, time to check out, or original signup country IP. Now that a user has made it through the front gate and walked through your yard, they are knocking at your door. Here, Radar applies all the analyses of their behavior monitored earlier, provides a risk score, and checks their information to see if it's on any lists. You might have a rule that blocks high-risk scores combined with high-risk countries and bins. Otherwise, your bouncer, Radar, will redirect them to further screening, 3DS, or put them in for human manual review. You usually accept payment and allow users access to your service. However, for added security, you might have cameras inside your house when you are away and be alerted about suspicious future behavior. A similar user might return 10x in a day with ten different credit cards, but Radar thinks they are safe. Logically, it is an outlier event and should be investigated.

What do you do if you find out about a rat or roach infestation? Don't let your house be condemned and auctioned off due to your inability to maintain it. Higher levels up Visa / MC, Wells Fargo, and Stripe all make money off your business and are responsible for ensuring the entire ecosystem is playing by the rules and doing its best to keep fraud at bay. If you get an alert that your account is being monitored or are identified as high risk, it is critical to do everything possible to clean up your house. If you fail to act, you can face fees greater than $25,000. First, ensure the Radar for teams is enabled, and proper signals are sent. Next, go through all your past payments that are high-risk scores and patterns to start proactively refunding.

Do not wait for payments to turn on disputes, as you incur extra fees and create a worse experience for the people who had their card information stolen. Many businesses fail to realize they are also part of the fraud scheme if they keep the funds they know are likely stolen. For this, it is critical to use Stripe Sigma (Stripe Sigma: Get Business & Revenue Data Using SQL). Sigma is a fantastic tool for digging deep into Stripe data and payments to find fraud and help remediate any issues. If you know basic SQL or can manage using the AI assistant, for starters, you will efficiently rectify issues 10x faster than manually going through payments and refunding. Even if you have no developer help or capacity from engineering, a single fraud analyst can clean up hundreds of thousands in fraud by themselves. The Sigma automated queries are decent, but you must understand SQL to write the best possible queries. Combining knowledge of fraud and patterns, you can create queries encompassing large fraud swathes, speeding up reviews. One current caveat about Sigma is the data is not up to date and sometimes delayed 8+ hours, which can be a critical gap if you overly rely on it to identify fraud. If you do not know how to code, you can use AI tools to create scripts using Excel data or other sources exported from Stripe, creating low-code workflows. For example, by extracting a list of a few hundred almost certainly fraudulent payments, you can have a simple bash script to go through the charge IDs and refund them. It would help if you were careful when doing this, as we have seen simple errors by tools like ChatGPT where they use the wrong endpoints.

Going through this process, you typically encounter many different types of fraud groups depending on how much volume and velocity you can get through. You might find termites, bats, raccoons, gophers, and a sleuth of bad actors that may damage your home. You should analyze each scenario and determine the best solution for pest control. Some cases include adding a country or region to a Stripe list and putting that entire group through high-security screening. For example, suppose your business has little legitimate business with certain countries like Russia or an African country combined with a bank type. There is no reason to accept higher risk score payments in that case. We have seen many instances in which certain banks and countries commit the overwhelming majority of fraud, and until they clean up their act, they need to be blocked or undergo additional screening. Using Sigma, you can get a list of those countries and banks with higher fraud rates and then incorporate the data into Radar rules. Using Radar lists makes it easy to keep rules up to date and not have to generate entirely new rules for each fraud. Each business is different, so we can not provide a starter list, but the patterns are easily identifiable by using Insights found here: https://dashboard.stripe.com/radar/insights?configuration=ALL_FRAUD or through other metric reports on Stripe. When on that page, make sure to add all the filters available to see if any obvious signals mean fraud, and change the date ranges to see different identifiers as new fraud comes through.

One feature promoted actively in the past year is chargeback prevention services through Visa, MC, and Amex alert services. These have been around for a while but are now being pushed further on businesses as a way to get fraud under control. Typically, they are not necessary and helpful if you have a high margin or are facing monitoring by Stripe. Once you control the fraud, you can usually wean yourself off these as the costs do not outweigh the benefits in the long run. While we typically recommend them, there are some downsides they will not tell you about. One is that the alerts often come, but the refund cannot prevent a dispute. Some banks, especially international ones, are even worse at successful dispute prevention, and the RDR or alerts become worthless. Their incentives are favored to have more disputes as that is the only way they make money, so they have little motive to help you prevent and remediate fraud. Refunding a potential dispute is fine, but what about analyzing the fraud and developing a plan to avoid future and related disputes? These companies won't tell you that when one dispute comes in and is refunded, it also shares data with 30 others from a similar customer profile, which should be refunded, saving you any dispute alert fees. Instead, they could wait for all 30 to turn into alerts and then refund them. Looking at disputes and related payments is the best method to avoid fraud that slips through earlier defenses proactively. Another issue we have seen is they will sometimes refund payments that are 3D secure when they have an alert. Not all these will turn into disputes that you would lose, and in some cases, it is better to have the banks have skin in the game and cover liability. However, 3D secure payments are not entirely safe, and we are seeing many cases where payments have a risk score of 0, while 3D secure payments are still 100% fraudulent. Similar to how malicious telcos participate in toll fraud, there are likely identical scenarios with certain banks or ones that have misconfigured 3ds setups and breached data, making it do little to prevent fraud. Using Sigma, you can find cases where a cardholder made a dispute but has other non-refunded payments that will typically turn into disputes. There is a short window to be proactive in these cases, so come up with a game plan within a day.

Lastly, we have provided some Sigma SQL queries that should help you get started on your fraud strategy journey. Many reports can be generated to identify fraud and keep your rules running well. If you feel overwhelmed by the entire process, add more professional tools and consulting, such as Trust Swiftly, to automate friction. In many cases, all this fraud can be stopped by using only Radar with proper configuration. Radar also doesn't do well against persistent bot attacks, and doing more complex custom integrations with Stripe and their SDKs can make the entire process harder to bot. Stripe Checkout links are shared pervasively on Telegram. At this point, too many bots can automate against it, as we detailed in Fraud Attacks on AI SaaS Companies the coming waves of chargebacks | Trust Swiftly. If you look at OpenAI's set up with Stripe, they put Arkose in front of the checkout and were able to remove most of their friction, such as verifying a phone number for users. Using captchas and firewalls like Cloudflare can siphon off a lot of bad traffic, but other threats will adapt and make it through Radar, which is why weekly cleaning is critical. Other complex setups can also be configured when your application backend communicates with Stripe to make the botting process difficult. For example, if a user has 8 blocked or failed payments, you can be notified via webhook; they should complete some friction before being allowed another checkout link. Involving a payments engineer can make the entire process of fraud easier to manage. At each step of the checkout experience, there are opportunities to apply basic security measures such as rate limiting and user analysis.

In review, we have explored multiple aspects of Radar and fraud management strategies to keep your Stripe account safe. Fraud management should not be a stressful experience, and if you methodically review it, the entire process can be mostly automated and efficiently run. Most companies searching for articles like this have been struck by fraud and need help as they want to focus on growth. Unless you are a large account with enterprise support by Stripe, you are left with self-service and will need to solve the fraud problem yourself. The documentation by Stripe is extensive and can also help get you started on recovery, but it does not provide business-specific fraud. As always, taking these steps becomes the first action in your fraud prevention journey, and results will take at least a few months to realize fully.