Standard risk rules

Use standard risk rules to influence the risk score of a payment.

RevenueProtect compares a transaction to the standard risk rules that you define, and increases the risk score if a transaction breaks these rules.

The standard risk rules are:

Velocity rules: Set thresholds on how often a shopper can attempt transactions.
Consistency rules: Analyze provided shopper data and behavior for inconsistencies and fraud.
ShopperDNA rules: Use shopper data and behavior to determine fraud. Requires RevenueProtect premium.

Turn on and configure standard risk rules

Log in to your Customer Area.
Go to Revenue & risk > Risk profiles.
Select a risk profile.
Select the Risk rules tab.
Select Standard rules.

From this page, you can turn checks on or off, and view or configure rule-specific settings.

Velocity rules

Velocity rules influence the risk score of transactions based on the number of transactions a shopper has attempted in a given time.

If a shopper abandons the transaction after they have been redirected to a payment method or 3D Secure, this counts as an attempt. These abandoned attempts are not listed in your payments. These transactions can be listed as offers in the Customer Area.

The average number of transactions from a good shopper varies depending on your business, so configure these checks to the behavior of your shoppers.

Velocity rules trigger per merchant account. The number of times a velocity rule triggers per merchant account is not aggregated for the company account.

By default, velocity rules do not trigger for recurring transactions such as subscriptions. You can turn on velocity rules for recurring transactions in the risk settings.

Rule	Triggers when	Description
Card/Bank account number already used by another shopper	The payment details for the transaction have already been used with a different `shopperReference` in the last three months.	Fraudsters create multiple accounts, and attempt to use the same compromised account with different techniques and attack vectors. This check is aimed at identifying when a payment method is being used across multiple accounts. We recommend that you enable this velocity check for all your merchant accounts to provide the most reliable results.
Shopper email used more than x times within a time period	The number of transactions associated with an email address exceeds a given number of transactions in a given time period.	Fraudsters use the same email for clusters of transactions because creating new emails is time intensive. This check lets you set velocity limits on any email address.
Shopper IP used more than x times within a time period	The number of transactions associated with an IP address exceeds a given number of transactions in a given time period.	Fraudsters often use the same IP address for consecutive fraudulent transactions. This could be while they are attempting different card details, or techniques. This check lets you set velocity limits on any particular IP address.

Consistency rules

Consistency rules are risk checks that analyze shopper data for fraud by comparing transaction data points with each other.

Rule

Triggers when

Description

Billing address does not match cardholder address (AVS)

There is a (partial) mismatch in address details.

Address Verification System (AVS) is a security feature that compares the billing address that the shopper entered with the cardholder address on file at the issuer.

Card Verification Code (CVC2/CVV2/CID) does not match

The Card Verification Code is provided but it does not match, is not provided, or the issuer cannot perform the check.

This check verifies if the Card Verification Code (CVC2/CVV2/CID) matches, and triggers only after an authorization by the issuing bank.

You can configure this check to trigger for either of the following two issuer responses:

The code does not match, is not provided, or the issuer cannot perform the check.

The code is provided but does not match.

This check does not trigger for recurring transactions because the check is done only on the initial transaction.

Liability shift status

A liability shift has or has not occurred with the transaction.

This rule has significant configuration implications.

A liability shift occurs when the liability of chargebacks passes from you to the issuing bank. This happens when the transaction has been verified through 3D Secure. You can configure the rule to trigger for 3D Secure transactions only, or for all ecommerce credit card transactions.

You can determine on which transactions to apply liability shift: all ecommerce credit card transactions, 3D Secure transactions, or 3D Secure transactions without technical errors.

Based on your settings, the rule checks if the liability shift took place. If it didn't, the risk score is increased. If it did, the risk score is decreased by the value you configured.

ShopperDNA rules

ShopperDNA links transactions in clusters to identify a profile of a shopper even as they change devices, networks, and identities. This profile is dynamic and changes based on real-time data.

ShopperDNA:

Determines all transactions that share identifiers such as email address, credit card number, or IP address with the parent transaction.
Tracks the strength of those identifiers based on uniqueness and other data.
Links transactions that meet a dynamic confidence threshold to the same shopper entity.

An identifier being shared between two shoppers might not link the two. For example, a shared IP address might indicate the same shopper, but could equally be two shoppers using the same office network.

You can view ShopperDNA visualizations. This can be useful, for example, when reviewing a payment in case management.

You can also manually configure ShopperDNA risk rules to flag fraudulent behavior or transaction velocity, even when fraudsters try to avoid detection. ShopperDNA provides another way to track users, in addition to methods like shopper reference, or name.

Each shopper identifier (also known as linkable attribute), such as an IP address, is continually assessed for its uniqueness, and this affects the weight it gives to any given transaction connection.

Rule	Triggers when	Description
Authorised transaction amount velocity	The total amount a shopper spends exceeds a limit in a given time period. By default, this rule does not trigger for recurring payments such as subscriptions. You can enable velocity checks for recurring payments in the risk settings.	You determine what you expect good customers to spend in a given period, and use this to spot fraudulent transactions, often of significantly higher value. You can set multiple amount limits with different scores.
Fraud refusals exceed X times within X days	The number of refused payments exceeds a limit in a given time period.	Many refusals in a row can indicate a fraud attack is being detected by RevenueProtect. This rule uses RevenueProtect data, but not issuer data. To include issuer data, see the rule Shopper consecutive refusals.
Shopper consecutive refusals exceeds X times within X minutes/hours/days	The number of refused payments exceeds a limit in a given time period.	Fraudsters attempt many payments, and many issuer refusals in a row can indicate the issuing bank detects a fraud attack.