Understand the Fraud Detection solution

Use our Fraud Detection solution to control what type of payments you accept and reduce the risk of fraud.

'Pre-auth' and 'post-auth' are the stages in the payment lifecycle at which you can use our solution to decide what happens to a transaction. The process the transaction goes through before reaching that outcome is called routing.

Each stage within routing has its own route. Routes have several data points that a transaction passes through. These data points can be rules, outcomes, or decline lists.

The decision groups you see under Live strategy are affecting your live transactions. It is view only, so you will not be able to directly edit and affect live transactions.

Safely test changes to your decision points under the Test strategy section. It has no effect on your live transactions, but you will be able to see the hypothetical outcome of these changes.

Once you are happy with the results of your test, you can select Replace live strategy to affect your live transactions. This cannot be undone.

Rules are the building blocks of your risk strategy. They are set by Checkout.com and take the form of an expression.

When a transaction is compared against a rule, it returns either true or false. This determines how it will be routed and the ultimate outcome, such as decline or whether additional 3D Secure (3DS) is required. Each true and false option is referred to as a branch.

Examples of rules:

• information within a transaction payload, for example, ‘Transaction amount over 100 USD’.
• additional contextual information, for example, ‘Billing address is valid’.
• statistical data derived from your traffic, for example, ‘Same card used more than 3 times in the last 1 hour’.

Rule groups are sets of individual rules that are grouped by different outcomes. At pre-auth, there are decline and 3DS rule groups. At post-auth, there are void and flag rule groups.

For example, if a transaction returns true for any rule in the decline rule group, the outcome of that transaction will be to decline it.

To add rules to groups, select Add rule at the bottom of each group. To remove a rule, select the three dots in the corner of the rule card and select Remove rule.

Transaction count checks the occurrence of a single attribute over a time period. For example, velocity (billing_address, 24h, _attempted_) > 10 will trigger when the number of approved requests for a particular billing address goes above 10 in a 24-hour period.

Pro only

1. Cumulative spend USD checks the total amount spent in US dollars (USD) on a specific attribute over a time period. For example, spend_usd (card_number, 24h, _attempted_) > 1000 will trigger when attempted payments on a specific card number exceed 1,000 USD over a 24-hour period.
2. Relative checks the occurrence of one attribute in relation to another. For example, relative_velocity (email_per_cardholder_name, 30d, _attempted_) > 10 will trigger when the number of email addresses for a single cardholder goes above 10 in any 30-day period of attempted transactions.

Pro only

The custom rules feature allows you to combine conditions to create specific triggers, which better target fraud patterns. When you select Create new rule, choose from a list of pre-defined properties, operators and functions, and velocities (frequency). These are the building blocks that allow you to create specific fraud rules for your risk strategy.

Custom rule examples:

• metadata, for example, ‘Product code is 14569’.
• same user attempting to pay with three different cards in one hour.
• same user receiving more than three insufficient funds declines in 24 hours.
• IP address contains the range '98.195' AND email domain is either gmail.com or hotmail.com.

Lists are sets of custom values that can be referenced in the rules. By default, you have access to a list of high-risk countries that are referenced in verified information rules. For example, the payment IP country is in a list of high-risk countries.

To add a list entry, go to the Lists tab and select Add entry. Here you will be able to enter a new value.

Pro only

Create custom lists based on your risk strategy.

To see all the different properties you can use to build rules:

1. Go to the Rules page.
2. Select Create a rule.
3. Go to the Properties section.

Different to decline rules, which are formulas that determine an outcome, decline lists are specific attributes that are not allowed.

For example, a decline rule may be amount > 1000 and card_country = Italy. An attribute in a decline list may be a specific card number or IP address.

If a transaction being routed through your strategy matches an item on a decline list, the transaction will be immediately declined. You can create a decline list for six fields:

• card number – the card’s 16-digit long number.
• BIN – the first six to eight digits of the card number, used to identify which issuer the card belongs to.
• email address – a customer’s full email address.
• phone – a customer’s phone number.
• payment IP – a customer’s IP address.
• email domain – the domain of a customer’s email, which comes after the @ symbol.

You can add to a decline list in two ways:

• select a transaction from the Payment details view in the Dashboard, and use the Decline list button.
• add to a decline list from the Decline list tab within the fraud solution.

Outcomes define what will happen to the transaction. The following tables specify the recommended outcomes for each transaction risk level. We’ve split them by routing type – pre-auth and post-auth. See the full description of each step in the payment lifecycle.

Pro only

Risk profiles are a collection of rules used for scoring-based decision-making. They are made up of two sections – scoring rules and decision thresholds.

Each rule has a score between 0% and 100% – 0% being low risk, and 100% the highest. Transactions are compared against each rule in a risk profile, and if a transaction meets the rule criteria, the transaction will receive the points associated with it.

Scores can be a negative or positive number, and the ultimate risk score of a transaction is the sum of all the rules the transaction met the criteria for.

You can select as many rules as you want to be evaluated. The order the rules are defined in is not important, because a transaction will be evaluated against each rule.

A transaction risk score must always be a number from 0% to 100%. If the sum of scores is less than 0%, the transaction risk score will be 0%. If the sum is greater than 100%, the transaction risk score will be 100%.

After specifying scores for each rule, you can decide the outcome of the transaction. The set of outcomes available to choose from will depend on whether the risk profile is applied at the pre-auth or post-auth stage.

Once you've decided on your outcomes, you can define the risk score bands that correspond to them. For example, you may decide to Decline all transactions with risk scores above 90%, and to Force challenge all transactions with risk scores between 70% and 90%.

Our fraud and risk solution uses machine learning to score a transaction between 0% and 100%. Our machine learning model is trained on every single transaction that goes through the Checkout.com network. To use our solution in your own risk strategy, add the Checkout Risk - Scoring Rule Threshold rule to one of your lists.

The default threshold for our machine learning is 15%. This means if a transaction is scored 15% or above, the rule will return true. What happens then depends on the rules and outcomes you already have in place. In some cases, the payment may be declined or flagged as fraudulent.

Pro only

Set a custom threshold for your machine learning rule. To direct transactions to different outcomes, you can use the scores automatically applied to every transaction. This works similarly to a risk profile. To use it, select the Checkout CC Model component in the rule selector.

Improve your Fraud Detection integration

Find out how to strengthen your solution integration.

Troubleshoot our Fraud Detection solution

Understand why certain errors happen, and how to fix them.

Rule categories

Learn about the risk management categories that can be used when setting up rules.