RevenueProtect engine rules

The engine has numerous rules available for configuration. There are several classes of rules that are assessed at the time of a transaction.

Rule Class Description Example Rule
ShopperDNA Rules These rules are calculated over the ShopperDNA network associated with a transaction. ShopperDNA allows merchants to track fraudsters across devices and networks and created rules on that entire network of transactions. Shopper Has a Previous Chargeback
Referral Lists These are lists of known good and bad shopper attributes (e.g. card numbers). Merchants can use these lists to ensure that loyal customers are unaffected and that known fraudsters are no longer able to attempt transactions. Shopper Email Referral List
Consistency Rules These are rules that look for known fraudulent trends in the customer behavior or data. Shopper Using Anonymous Proxy
Velocity Rules Velocity rules allow merchants to set specific thresholds on how often a shopper can attempt transactions in a given time period. Shopper Email Usage Frequency
External Risk Checks Plugins to various third-party risk mitigation systems that allow them to be used in coordination with RevenueProtect. Perseuss Airline Check

Each of these rules is highly customizable. This section of the manual will break down a description of each rule and the various configuration options therein. 

Configuring Rules

The engine rules are configured at the merchant account level. Depending on a merchant's fraud exposure, they may configure significantly different risk mitigation rules for each account. Generally speaking, merchants tend to isolate low-risk transactions from high-risk, enabling differentiated risk configurations for each profile.

Remember that transactions are blocked when their score reaches 100.

Note the following about the risk configuration setup:

  • Each rule has a score threshold associated with it. This is the score that adds to the aggregate transaction score if the rule triggers.

  • Many rules need additional configuration. Click the pencil icon to configure the rule-specific settings for that rule. 
  • Inactive checks are not displayed by default. Click Show inactive checks to see rules that have been de-activated. 

Risk Engine Rule Management


One of the biggest risks for a risk manager is making significant changes to fraud settings and possibly introducing large numbers of false positives or negatives into their screening. The Optimiser allows merchants to experiment with risk settings in a what-if manner, so they can understand the effect that a set of changes will make on their action rates.

Based on a subset of past transactions and historical data, the risk optimiser can breakdown which check has been triggered most often and what the effect of each check's score has been on the total score. Further, it can provide predictive statistics on pending changes and give suggested risk profiles to improve action rate.

The risk optimiser is accessible through Customer Area in the Reports section, and via the risk configuration page. Note that only Risk Admins can access the Optimiser, so Risk Manager should check with their Adyen admin user if they don't have the necessary role.

The Optimiser uses chargeback data to calculate its results. If your acquiring configuration does not result in chargebacks being displayed in the Customer Area, you should not utilize the Risk Engine Optimiser until you have uploaded your chargebacks with the Chargeback Uploader.


The image below shows an example of a simulated scenario that the Risk Engine Optimiser determined. In this visualization, merchants can review a simulation of the expected outcome in chargebacks and false positives after the proposed change. In this example, 127 chargeback transactions could have been rejected, saving more than 96,000 Euros to the merchant. Also, the proposed settings could have resulted in 9 less false positives, preventing over 1,900 Euros in lost revenue. Thus, this set of changes is very positive, resulting in over 98,000 Euros in additional revenue.

There are two ways to use the Optimiser:

  1. Manual configuration: The Merchant proposes specific changes to various rules and the Risk Engine Optimiser computes the expected results.

  2. Automatic configuration: The merchant indicates a preference of lower chargeback rate vs. allowing fewer false positives and the Optimiser computes a set of risk configurations and displays the expected performance.

Manual Configuration

Manual Configuration is for merchants who wish to test tweaks to their settings and predict the expected outcome of the selected settings. The outcome display shown below is a table of the active risk checks on the account. Each column gives important information about the sample being used to calculate the outcome:

  • Triggered: The percentage of transactions in the sample that this risk check triggered on. 

  • Chargebacks: The percentage of chargebacks of the total number of accepted transactions that triggered the risk check.

  • Refusals: The percentage of transactions that were refused of the total number of transactions that triggered the risk check.

After the merchant has finished adjusting the risk scores of the risk checks by filling out the New Score column, they can request the Optimiser to simulate these new values on past transactions. To perform this action click Calculate Expected Results, the final results are displayed in the panel show above.

Automatic Configuration

Manual configuration can be time-consuming for the merchant, in particular when complex calculations are required to predict the expected outcome of changes. For this reason, Adyen has developed machine-learning algorithms that can decide which risk checks should changed and what their new risk scores should be.

To be presented with an automatic configuration, select a position on the Proposed Risk Configurations scale. Based on these preferences, ranging in aggressiveness, the table is populated with a set of risk settings. Note that the numbers of options on the configuration slider are dynamic, based on the number of configurations the model is able to produce. The number of available configurations can very from none to many.