# Build and test risk strategies

Your [Fraud Detection](https://www.checkout.com/docs/business-operations/prevent-fraud.md) 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](https://www.checkout.com/docs/business-operations/prevent-fraud/create-risk-rules-and-lists.md#Rules) or [rule groups](#Manage_rule_groups) and [lists](https://www.checkout.com/docs/business-operations/prevent-fraud/create-risk-rules-and-lists.md#Lists), with specified [outcomes](#Define_outcomes).

---

## How it works

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 and test risk strategies, you need one of the following [user roles](https://www.checkout.com/docs/business-operations/use-the-dashboard/user-permissions.md):

- Admin
- Risk manager
- A custom role with the `Create, edit, or delete rules` permission

---

## Build test strategies

1. Sign in to the [Dashboard](https://dashboard.checkout.com).
2. Go to _Fraud_ > _Strategy_ > _Strategy Builder_.
3. Select the relevant tab: _Pre-auth_ or _Post-auth_. <br>
The default live strategy appears under _Live strategy_.
4. Under _Test strategy_, select _Copy live strategy_.
5. Add your rules, rule groups, and lists, and define your outcomes.
6. Select _Save and begin test_ > _Shadow testing_ > _Begin test_. This safely tests changes with no effect on your live payments.

> **Information**
>
> Ensure you create strategies for both pre-auth and post-auth to fully protect your payments.

### Manage rule groups

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 rules` and `Decline rules`
- Post-auth – `Flag rules` and `Void rules`

> **Note**
>
> You cannot edit rules shown as _locked_ or _compliance_ – these rules will be indicated by an icon next to the rule name. These rules are added by Checkout.com – for more detail on any of these rules, contact your account manager.

To manage rule groups:

1. Sign in to the [Dashboard](https://dashboard.checkout.com).
2. Go to _Fraud_ > _Strategy_ > _Strategy Builder_.
3. Select the relevant tab: _Pre-auth_ or _Post-auth_.
4. Under _Test strategy_, select _Copy live strategy_.
5. To add a rule to a rule group, select _Add rule_ in the group.
6. 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.

![Screenshot of rule groups and branches](https://www.checkout.com/docs/NAS/Resources/prism_branches.svg)

### Define outcomes

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:

**Pre-auth**

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](https://www.checkout.com/docs/payments/authenticate-payments/3d-secure.md#What_is_liability_shift,_and_when_does_it_occur?).
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 |

**Post-auth**

| Outcome | Recommended risk level |
| --- | --- |
| Void | High risk |
| Flag | Medium risk |
| Capture | Low risk |

---

## Perform shadow testing

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:

1. Sign in to the [Dashboard](https://dashboard.checkout.com).
2. Go to _Payments_ > _Fraud_ > _Strategy_.
3. On the _Strategy builder_ tab, go to the _Outcome comparison_ section.
4. 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.

You can download the results of your shadow testing with Fraud Detection as a CSV report. For more information, see [Shadow testing reports](https://www.checkout.com/docs/business-operations/prevent-fraud/retrieve-fraud-reports/shadow-testing-reports.md).

> **Information**
>
> You can unlock advanced backtesting with [Fraud Detection Pro](https://www.checkout.com/docs/business-operations/prevent-fraud/upgrade-to-pro.md).

---

## Replace live strategies

When you have finished testing your strategies, you can replace your live strategies:

1. Sign in to the [Dashboard](https://dashboard.checkout.com).
2. Go to _Fraud_ > _Strategy_ > _Strategy Builder_.
3. Select the relevant tab: _Pre-auth_ or _Post-auth_.
4. 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.

---

## Troubleshoot strategies

You can resolve the more common errors you may encounter when building your strategies as follows.

### Case insensitivity

The following are case insensitive:

- Matches within lists
- Metadata keys and values
- Property-to-property comparisons – For example:
    - `:shipping_address_line1: = :billing_address_line1:`
    - `:billing_address_city: = 'london'`
    -`:currency: IN ["EUR", "gbp", "UsD"]`

### Case sensitivity

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.

### Null values

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.

### Metadata

When performing a comparison with your [metadata](https://www.checkout.com/docs/business-operations/prevent-fraud/optimize-payment-request-data.md#Leverage_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`.

### Strings in arrays

Ensure you enclose each string in an array in quotation marks, rather than the entire array:

- Correct – `[“EUR”, “GBP”]`
- Incorrect – `[“EUR, GBP”]`

---

## Next steps

**[Integrate with Risk SDK](https://www.checkout.com/docs/business-operations/prevent-fraud/integrate-with-risk-sdk.md)**

Integrate with a Risk SDK to maximize the efficiency of the Fraud Detection solution.

**[Optimize payment request data](https://www.checkout.com/docs/business-operations/prevent-fraud/optimize-payment-request-data.md)**

Learn how to provide high quality data in your payment requests to improve the effectiveness of your integration.

**[Monitor risk performance](https://www.checkout.com/docs/business-operations/prevent-fraud/monitor-risk-performance.md)**

Monitor the performance of your Fraud Detection risk strategies.