Build and test risk strategies
Last updated: August 20, 2025
Your Fraud Detection risk strategies assess payments and determine what happens to them at each stage of their lifecycle, before authentication (pre-auth) and after authorization (post-auth). This enables you to control what type of payments you accept to reduce the risk of fraud.
The process a payment goes through is called routing. Each lifecycle stage has its own route. Routes have multiple decision points in the form of rules or rule groups and lists, with specified outcomes.
When the solution is enabled, default live pre-auth and post-auth strategies are applied. For security reasons, you cannot edit the live strategies directly.
You must first build test strategies and perform shadow testing. Once you are satisfied with the test strategies, they replace the live strategies.
To build your test pre-auth and post-auth strategies, you need the Admin user role, or a custom role with the Create, edit, or delete rules permission.
- Sign in to the Dashboard.
- Go to Fraud > Strategy > Strategy Builder.
- Select the relevant tab: Pre-auth or Post-auth.
The default live strategy appears under Live strategy. - Under Test strategy, select Copy live strategy.
- Add your rules, rule groups, and lists, and define your outcomes.
- Select Save and begin test > Shadow testing > Begin test. This safely tests changes with no effect on your live payments.
You can add multiple rules to a group for a specific outcome.
If any rule in the group is assessed as true, the outcome is applied to the payment.
For example, if any rule in a decline group is assessed as true, the payment is declined.
You can add rules to the following groups:
- Pre-auth –
3DS rulesandDecline rules - Post-auth –
Flag rulesandVoid rules
To manage rule groups:
- Sign in to the Dashboard.
- Go to Fraud > Strategy > Strategy Builder.
- Select the relevant tab: Pre-auth or Post-auth.
- Under Test strategy, select Copy live strategy.
- To add a rule to a rule group, select Add rule in the group.
- To remove a rule from a group, select the three dots in the corner of the rule card within the group, and then select Remove rule.
- To add a rule to a rule group, select Add rule in the group.
- To remove a rule from a group, select the three dots in the corner of the rule card within the group, and then select Remove rule.
- To update the outcome of a rule group, select the outcome > Switch outcome, and then select the relevant outcome.
- You can also change a rule group to a rule, a risk profile, or a machine learning model.
Outcomes define what happens to payments at each branch in your pre-auth and post-auth strategies.
We recommend the following outcomes for each payment risk level:
A 3DS check means that your customer has to prove their identity. For example, using a one-time pass code. This helps reduce fraud, but also may impact your conversion rate.
3DS payments may be subject to a liability shift. This occurs when the liability for fraudulent chargebacks (for example, using stolen or counterfeit cards) shifts from you to the issuer. Use the Liability shift column to determine what outcomes the shift applies to.
| Outcome | Recommended risk level | Liability shift |
|---|---|---|
Accept | Low risk | No |
Decline | High risk | N/A |
3DS Frictionless | Medium risk | Yes |
3DS Challenge | High risk | Yes |
Testing is a critical part of building, maintaining, and improving your risk strategies. Regular testing can help with the following:
- Combat evolving techniques fraudsters continually develop to exploit vulnerabilities in payment systems.
- Remain compliant with payment security regulations and compliance standards for your industry and avoid potential penalties or legal consequences.
- Optimize your revenue by balancing the need to minimize fraud losses and reduce the number of false positives that can disrupt legitimate payments.
- Manage the number of payments flagged for your operations team to manually review by updating your flag rules.
Shadow testing involves running the test strategy at the same time as your live strategy, but you do not take any action based on the results.
You can implement and iterate shadow tests regularly, which enables you to:
- Observe a strategy's performance in real time.
- Identify any potential issues.
- Fine-tune rules.
- Assess the strategy's effectiveness before going live.
Shadow tests rely on real transactional data, so it can take between 24 hours and three months for patterns to become clear. For example, if you had extra sales in April, bear this in mind when analyzing the test results because they may not be representative of future traffic.
Information
You can only start shadow testing from your client-level account. Only the live strategy assesses entity-level strategies.
To see the difference between the test and live outcomes for each strategy branch:
- Sign in to the Dashboard.
- Go to Payments > Fraud > Strategy.
- On the Strategy builder tab, go to the Outcome comparison section.
- Select the Shadow testing tab and specify the time frame in the date picker.
The change in reported fraudulent payments is displayed for each outcome. You can also hover your cursor over each half of the Test bar to see a breakdown of payments and amounts.
Information
You can unlock advanced backtesting with Fraud Detection Pro.
When you have finished testing your strategies, you can replace your live strategies:
- Sign in to the Dashboard.
- Go to Fraud > Strategy > Strategy Builder.
- Select the relevant tab: Pre-auth or Post-auth.
- Under Test strategy, select Replace live strategy.
Note
You cannot undo replacing your live strategy. You must re-copy your live strategy, adjust it, and then re-replace the live strategy.
To gain insight into your integration's performance:
- Sign in to the Dashboard.
- Go to Payments > Fraud > Performance.
The Risk analytics page provides an overview of metrics, payment journeys, and rule performance. You can also generate a report for a specific time frame.
You can resolve the more common errors you may encounter when building your strategies as follows.
Property-to-property comparisons are case insensitive, such as:
:shipping_address_line1: = :billing_address_line1::billing_address_city: = 'london'-:currency: IN ["EUR", "gbp", "UsD"]
Metadata keys and values are case insensitive.
Property-to-custom list comparisons are case sensitive, such as:
$product_code IN @high_risk_product_list
In case-sensitive comparisons, currency and country properties expect codes in upper case.
Be mindful when setting rules that may lead to NULL values. If you set a rule such as :billing_address_country: = :shipping_address_country:, but do not provide either address in your payment request, the values being compared are NULL = NULL, which is equal to true. Conversely, if you only provide one of the addresses, this rule is equal to false.
The EXISTS and IS_MISSING operators assess whether a value is NULL. A value is only treated as NULL if you do not provide specified information.
Empty values and white spaces are treated differently. So when comparing two values that have different white spaces, they are assessed as different even if the text is the same.
When performing a comparison with your metadata, be aware of the following behaviors:
Metadata keys and values are case insensitive. For example, given a metadata key/value pair of "CouponCode": "NEW12", both $couponcode = "NEW12" and $couponcode = "New12" are assessed as true.
If you use the =, !=, in, or contains operators to compare a number or boolean with a string, the number or boolean is coerced to a string.
If you use the >, <, >=, or <= operators to compare a number with a non-numeric value, the comparison is always assessed as false.
Ensure you enclose each string in an array in quotation marks, rather than the entire array:
- Correct –
[“EUR”, “GBP”] - Incorrect –
[“EUR, GBP”]
To view how a specific payment was routed through your rules:
- Sign in to the Dashboard.
- Go to Payments > Processing > All payments.
- Select the relevant payment to open the Transaction details page.
- Under Payment timeline, select View full assessment.