Understand Fraud Detection
Last updated: March 20, 2024
Use our Fraud Detection solution to control what type of payments you accept and reduce the risk of fraud.
Information
If you're an Administrator or Administrator Owner, you will be able to add, edit, and delete rules.
'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.
Note
Access to certain rule properties is restricted to the Pro plan.
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 100USD’.
- 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’.
Information
You can inspect a payment in the Dashboard to view how it transitioned through your Fraud Detection rules. Select the payment in the Payments > Processing > All payments section to view its details, then select View full assessment in the payment's timeline view.
When you set up a rule, you can make use of the following risk management categories:
| Rule | Summary |
|---|---|
Address verification service (AVS) | AVS is widely used in the US, Canada, and UK to verify the billing address provided by the cardholder with the address on file at the issuing bank. Only applicable to US and EU credit cards. AVS rules are only applied to charges that include the cardholder's billing address. |
Decline list management | A decline list is also known as a blocklist. It rejects transactions based on four attributes: card, IP address, email, and phone number. We manage a global blocklist of cards that have been blocklisted by other Checkout.com merchants, and we block any card that has been blocklisted by at least 3 other merchants. |
High-risk countries | A custom list of high-risk countries that helps to prevent transactions to and from more fraud-prone locations. If you have several businesses associated with your account, you can have a different set of high-risk countries for each of them. |
Machine learning (ML) score | A machine learning model trained on all of Checkout.com's data. This model gives a score between 0 and 100 to indicate how risky the payment is – where |
Mismatch | Mismatch rules can be configured to trigger when the details of a transaction do not correspond with one another. For example, the difference in geolocation between the BIN country and the IP address of the cardholder. |
Threshold | Threshold amounts can be set to trigger a defined action based on the value and currency of a transaction, typically to manage exposure to fraudulent high-value orders. |
Velocity | Velocity rules allow you to automatically trigger actions based on the frequency of transactions with matching attributes over a specific period. These can be set up for a range of frequencies, including daily, weekly and monthly. |
Verified information | Information such as email, billing address, shipping address, etc. can be checked against the Dashboard's built-in tools to verify whether the information provided is valid or is potentially fraudulent, depending on the rules and actions set. |
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 attempted requests for a particular billing address goes above 10 in a 24-hour period.
Pro only
- 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) > 1000will trigger when attempted payments on a specific card number exceed 1,000 USD over a 24-hour period. - Relative checks the occurrence of 1 attribute in relation to another. For example,
relative_velocity (email_per_cardholder_name, 30d, attempted) > 10will trigger when the number of email addresses for a single cardholder goes above 10 in any 30-day period of attempted transactions.
Information
To learn more about the different features offered by Fraud Detection and Fraud Detection Pro, see Payment Fraud Detection.
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.
You can add an entry to your trust list so that any transaction that matches a listed attribute bypasses any rules you've set as part of your risk strategy.
Note
Entries in your trust list may still be declined due to global Checkout.com policies.
You can add the following types of entries to your trust list:
- email addresses
- email domains
- payment IPs
Pro only
Create custom lists based on your risk strategy.
To see all the different properties you can use to build rules:
- Go to the Rules page.
- Select Create a rule.
- 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 Payments > Processing > All Payments > 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.
Information
You can only add card numbers to a decline list from the Dashboard.
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.
3DS transactions are subject to a liability shift. The shift occurs when the liability for fraudulent chargebacks (stolen or counterfeit cards) shifts from you to the card issuer. Use the Liability shift column to determine what outcomes it applies to.
| Outcome | Recommended transaction risk level | Liability shift |
|---|---|---|
Accept | Low risk | No |
Decline | High risk | N/A |
3DS Frictionless | Medium risk | Yes |
3DS Challenge | High risk | Yes |
A 3DS check means that your customer will have to prove their identity, such as through the use of a one-time pass code. This will reduce fraud, but also may impact your conversion rate.
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. The closer to 100 a score is, the greater the probability of fraud.
Our machine learning model is trained on every single transaction that goes through the Checkout.com network. To use it in your own risk strategy, add the Checkout Risk - Scoring Rule Threshold rule to one of your lists.
The threshold for our machine learning is 70, so if a transaction is scored 70 or above, the rule will return true. This threshold has been selected so only very high risk payments will trigger it.
Information
The more data you send to us, the more accurate the machine learning algorithms will be. To get the best use out of this rule, you should send IP address data, billing or shipping address data, card data, and the customer email address.
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.
In the following section, we cover solutions for some of the more common errors you may encounter when setting up your Fraud Detection integration.
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 will be equal to true. Conversely, if you only provide one of the addresses, this rule will be equal to false.
The EXISTS and IS_MISSING operators evaluate whether a value is NULL. A value will only be considered as NULL if specified information is not provided.
Empty values and white spaces are considered different. So when comparing 2 values that have different white spacing, it will be evaluated as different even if the text is the same.
The rules for case sensitivity depend on the type of comparison performed.
Property-to-property comparisons are not case-sensitive. For example:
:shipping_address_line1: = :billing_address_line1::billing_address_city: = 'london'-:currency: IN ["EUR", "gbp", "UsD"]
Property-to-custom list comparisons are case-sensitive. For example:
$product_code IN @high_risk_product_list
In case-sensitive comparisons, currency and country properties expect codes in upper case.
When you perform a payment request, you can supply custom string, number, or boolean fields within the metadata object. For example:
You can reference these metadata fields to create advanced rules for your risk strategy. For example, if you want to pass your own fraud score or account age rule.
To reference a metadata field in a rule, prefix the key with $. For example, with the previous payment request example, the following rule would evaluate to true:
You can also pass the metadata as an argument to any function that takes in a string, number, or boolean. For example, you can evaluate the boolean value of a metadata property:
You can also use metadata values in calculations:
When performing a comparison with your metadata, be aware of the following behaviors:
- metadata keys and values are not case-sensitive – for example, given a metadata key/value pair of
"CouponCode": "NEW12", both$couponcode = "NEW12"and$couponcode = "New12"would evaluate totrue - if you use the
=,!=,in, orcontainsoperators to compare anumberorbooleanwith astring, thenumberorbooleanwill be coerced to astring - if you use the
>,<,>=, or<=operators to compare anumberwith a non-numeric value, the comparison will always evaluate tofalse
The :avs_code: property is only available at the post-auth stage of the payment lifecycle, because address verification service (AVS) checks are only available from the issuer. The :avs_code: property checks that the billing address provided matches the one that the issuer has on file.