---
title: "Use transaction rules"
description: "Evaluate transactions with predefined conditions and outcomes."
url: "https://docs.adyen.com/issuing/authorisation/transaction-rules"
source_url: "https://docs.adyen.com/issuing/authorisation/transaction-rules.md"
canonical: "https://docs.adyen.com/issuing/authorisation/transaction-rules"
last_modified: "2022-04-04T12:45:00+02:00"
language: "en"
---

# Use transaction rules

Evaluate transactions with predefined conditions and outcomes.

[View source](/issuing/authorisation/transaction-rules.md)

When your cardholders make payments to third-parties, you can protect your balance platform from risk by evaluating and declining suspicious authorization requests. You can use transaction rules to configure a logic that automatically declines an authorization that does not meet your business' requirements. Aside from payments, transaction rules can be applied to other activities of the cardholder, such as ATM withdrawals.

We recommend that you use transaction rules to make decisions based on transaction data and static conditions, such as a fixed list of countries/regions from which transactions must not be allowed.

## Transaction rule creation

When creating transaction rules, you must determine the following:

1. **Criteria**: The [criteria](#criteria) that determine when a transaction is evaluated with the rule. For example, if the transaction occurs in a specific time interval or if it applies to a specific resource in your balance platform. To define the rule criteria, you must consider the following:

   | Criterion                        | Description                                                                                                                                                                                                                                  |
   | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
   | [Request type](#request-type)    | Defines the `type` of transfer request to which you want to apply the rule. Possible values: **authorization** (default), **authentication**, **tokenization**.                                                                              |
   | [Rule type](#rule-types)         | Defines what data the rule must use to analyze the transaction and check whether it meets the conditions. The rule either uses only the data of the current transaction being analyzed, or uses accumulated data from previous transactions. |
   | [Time interval](#time-intervals) | Defines the time period in which a transaction must meet the rule conditions.                                                                                                                                                                |
   | [Entity](#entity)                | Defines the balance platform resource to which the rule applies.                                                                                                                                                                             |

2. **Conditions**: The [conditions](#conditions) that a transaction must meet for the rule's outcome to be applied. For example, if it contains certain request data.

3. **Outcome**: The [outcome](#outcome) to apply when the transaction is evaluated and meets the conditions of the rule, such as to decline the transaction or assign a risk score to it.

## How it works

1. You create a transaction rule by defining the criteria, conditions, and outcome.

2. Your cardholder initiates a transaction using their Adyen-issued card.

3. If the transaction meets the criteria of the transaction rule, Adyen evaluates the transaction using the rule.

4. If the transaction meets the conditions defined in the transaction rule, Adyen applies the outcome of the rule.

You can also combine transaction rules with [relayed authorisation](/issuing/authorisation/relayed-authorisation). When combined, Adyen evaluates transaction rules first before sending the relayed authorisation webhook to your server. This means that when a transaction is already declined by transaction rules, you will not get a relayed authorisation webhook.

## Criteria

### Request types

The request type defines the type of transfer requests to which you want to apply a rule. When you send a request to the POST [Transfers API](https://docs.adyen.com/api-explorer/transfers/latest/overview) endpoint, Adyen evaluates the request and categorizes it as one of the following request types:

1. **authorization**: a request to authorize a payment. For more information, see [Payment authorisation](/issuing/authorisation).
2. **authentication**: a request to authenticate your cardholder's identity. This is an authorisation request with SCA parameters included in the header. For more information, see [Out-of-band authentication](/issuing/3d-secure/oob-auth-sdk).
3. **tokenization**: a request to tokenize your cardholder's details for recurring payments. For more information, see [Network Tokens](/issuing/manage-network-tokens).

When you create a transaction rule, you can choose the request types to which the rule applies.

### Rule types

The rule type defines what data the rule uses to analyze and decide the outcome of a transfer request. Adyen can use the data of the current transfer, or use accumulated data from previous transfers.

The following rule types are available:

* Blocklist: decline a transfer if it meets the specified [conditions](#conditions).
* Maximum usage: add the total amount from each transaction or count the number of transactions for the lifetime of a payment instrument, and then decline a transaction when the specified limits are met.
* Velocity: decline a transaction if a set amount of accumulated previous transactions have met the specified [conditions](#conditions). Adyen only considers previous transactions within a specified [time interval](#time-intervals) and [aggregation level](#accumulate-data).

### Time intervals

The time interval defines the period when the rule conditions and outcome apply. When using a **velocity** [rule type](#rule-types) which looks at accumulated data, the time interval also determines when the accumulated count or value is reset.

The interval also determines when counters are reset if the rule is accumulating data.

The following types of time intervals are available:

| Type of time interval | Description                                                                                                                                                                                                                                                                                                                | Example                                                                                                                                                                                                                                                                                                                                        |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Lifetime**          | The rule uses data from the entire lifetime of the card.                                                                                                                                                                                                                                                                   | You can set a rule that allows a cardholder to transfer a maximum of EUR 5000 for the entire lifetime of their Adyen-issued card..                                                                                                                                                                                                             |
| **Per transaction**   | The rule only uses data from the current transfer to make a decision. The outcome also applies only to the current transfer request.                                                                                                                                                                                       | You can set a rule that allows a cardholder to transfer a maximum of EUR 5000 per transfer request.                                                                                                                                                                                                                                            |
| **Fixed interval**    | The rule uses data from transfers made within the specified time interval, such as the ongoing day, week, or month. The outcome applies to the current transfer and all following transfers until the end of the interval.                                                                                                 | You can set a rule that allows a cardholder to transfer a maximum of EUR 1000 from their account in a day. In this case, Adyen accumulates the data of all the outgoing transfers from that account within the current day. If the cardholder exceeds the EUR 1000 limit, all subsequent transfer request are declined until the next day.     |
| **Rolling interval**  | The rule uses conditions that are applied and counters are reset based on a start time, timezone, and duration that you define. The outcome applies to the current transfer and all following transfers until the end of the interval.                                                                                     | You can set a rule that allows a cardholder to transfer a maximum of EUR 5000 from their account within a week. You can specify a schedule for that week that starts every Monday, for a duration of seven days. If the cardholder exceeds the EUR 5000 limit, all subsequent transfer requests are declined until the start of the next week. |
| **Sliding interval**  | The rule uses data from transfers that occurred within a specified time interval previous to the current transfer. For example, Adyen can check transfers made in the previous minutes, hours, or days. The outcome applies to the current transfer and all following transfer requests until the specified interval ends. | You can set a rule that allows a cardholder to make a maximum of five transfer requests within an hour. If the cardholder makes five transfer requests in less than an hour, all subsequent transfers are declined until the next hour.                                                                                                        |

### Entity to which the rule applies

Each transaction rule must be applied to only one resource.

You can apply a transaction rule to any of the following resources:

* A balance account: the rule applies to all cards linked to the balance account.
* An account holder: the rule applies to all cards of the account holder.
* A payment instrument: the rule only applies to one card.
* A payment instrument group: the rule applies to all cards in the group.
* A balance platform: the rule applies to all cards in your balance platform.

If multiple rules apply to a card, Adyen prioritizes the rules according to the [hierarchy of transaction rules](#hierarchy-for-transaction-rules). The transaction is blocked if it meets the conditions of a rule with a hard-block outcome.

#### Aggregating total amount or number of transactions

When accumulating the amount or number of transactions, you can also specify at which level the data should be accumulated.

You can accumulate data based on different levels:

* The payment instrument level. This is the default.
* The payment instrument group level.
* The balance account level.
* The account holder level.
* The balance platform level.

You can only aggregate values at the same or below the level of the entity to which the rule applies. For example, if the transaction rule applies to a balance account, then you can only aggregate values for the balance account or for individual payment instruments but not at the account holder level.

When aggregating amounts, we convert all transaction amounts to the default currency of the account holder or balance platform.

## Conditions

Conditions define the data that a transaction must contain for the outcome to be applied. Transaction rules check whether the transaction meets all of the conditions before accepting or declining the transaction. We refer to these conditions as *rule restrictions*.

A rule restrictions consists of the following:

* `value`: one or more types of transaction data that a transaction must or must not contain, such as the total amount, the counterparty, the counterparty's bank IBAN number, or the source account type.

* `operation`: the operation type, which determines how a transaction's data must be evaluated against the values specified in the `value` array. For example:

  * The transaction's counterparty can *Match* the counterparty you specify in `value`.
  * The counterparty IBAN number in the transaction request *Does not match* the counterparty bank IBAN number you specify in `value`.
  * The total amount of the transaction *Equals*, is *greater than or equal to*, or is *less than* the total amount you specify in `value`.

See [allowed combinations](/issuing/authorisation/transaction-rules/create-and-manage#allowed-combinations) of values and operations.

## Outcome

The outcome determines what Adyen does when a transaction meets the conditions of a rule. Depending on your use case, you can configure the following types of outcomes:

* [Hard-block](#hard-block-outcome) outcome
* [Score-based](#score-based-outcome) outcome
* [Enforce SCA](#enforce-sca-outcome) outcome

### Hard-block outcome

The hard-block outcome declines a transaction when it meets the conditions of a rule.

### Score-based outcome

A score-based outcome assigns a score to a transaction. When configuring this outcome, you must specify a score between -100 and 100.

When evaluating transaction, Adyen adds up the scores of all the triggered score-based outcomes. If the total score is higher than 100, the transaction is declined.

To decide on the outcome, consider your [use cases](/issuing/authorisation/transaction-rules/examples). For example, if a payment does not have a CVC but comes from a known merchant, you may want to assign a score to the payment instead of blocking it.

### Enforce SCA outcome

When a transaction meets the conditions of a rule, the enforce SCA outcome prompts your cardholder to verify their identity using [Strong Customer Authentication (SCA)](/issuing/3d-secure/oob-auth-sdk/). If the authentication fails or times out, the transaction is declined.

You can only use this outcome type when the `requestType` is set to **authentication**.

## Hierarchy for transaction rules

You can create a rule with one or more conditions, and apply one or more rules to an entity. When your

cardholder makes a transaction, Adyen evaluates all of the applicable rules.

### Multiple conditions

If you have multiple conditions within one rule, Adyen applies the outcome if the transaction meets all the conditions within the rule.

### Multiple rules

If you have multiple rules tied to an entity, Adyen evaluates all the rules, and applies the outcome based on the hierarchy of the outcome type. The hierarchy we follow depends on the transaction's `requestType`:

### Tab: Authorization or Tokenization

1. Adyen checks if the transaction meets the conditions of at least one rule with a **hardBlock** outcome type.

   * If it meets the conditions, we decline the transaction, and stop evaluating the rules.
   * If it does not meet the conditions, we further evaluate the rules.

2. Adyen checks if the transaction meets the conditions of at least one rule with a **scoreBased** outcome type, and calculates the risk score as defined in the rule.

   * If the risk score is above 100, we decline the transaction, and stop evaluating the rules.
   * If the risk score is below 100, we process the transaction.

### Tab: Authentication

1. Adyen checks if the transaction meets the conditions of at least one rule with a **hardBlock** outcome type.

   * If it meets the conditions, we decline the transaction, and stop evaluating the rules.
   * If it does not meet the conditions, we further evaluate the rules.

2. Adyen checks if the transaction meets the conditions of at least one rule with a **enforceSCA** outcome type.

   * If it meets the conditions, the cardholder must verify their identity. If the verification fails, we decline the transaction and stop evaluating the rules. If the verification is successful, we process the transaction.
   * If it does not meet the conditions, we further evaluate the rules.

3. Adyen checks if Risk Based Analysis (RBA) and Transaction Risk Analysis (TRA) exemptions are allowed for your cardholder. For more information about these exemptions, reach out to your Adyen contact.

   * If the exemptions are *not* allowed, the cardholder must verify their identity. If the verification fails, we decline the transaction and stop evaluating the rules. If the verification is successful, we process the transaction.
   * If the exemptions are allowed, we further evaluate the rules.

4. Adyen checks if the transaction meets the conditions of at least one rule with a **scoreBased** outcome type, and calculates the risk score as defined in the rule.

   * If the risk score is above 100, the cardholder must verify their identity. If the verification fails, we decline the transaction and stop evaluating the rules. If the verification is successful, we process the transaction.
   * If the risk score is below 100, we process the transaction.

You can create transaction rules that override other transaction rules in specific circumstances, such as for a specific balance platform resource. For more information, see [Override a transaction rule](/issuing/authorisation/transaction-rules/create-and-manage#override-an-existing-transaction-rule).

## Get updates when a rule is triggered

To get updated about payouts that are declined because they triggered one or more transaction rules, you can use either webhook notifications or the Customer Area:

* Subscribe to the [Transfer webhooks](https://docs.adyen.com/api-explorer/transfer-webhooks/latest/overview). The [transactionRulesResult](https://docs.adyen.com/api-explorer/transfer-webhooks/latest/post/balancePlatform.transfer.created#request-data-transactionRulesResult) object contains the details of all the transactions rules that the payout triggered. The [reason](https://docs.adyen.com/api-explorer/transfer-webhooks/latest/post/balancePlatform.transfer.created#request-data-reason) field returns **declinedByTransactionRule**.
* In your [Customer Area](https://ca-test.adyen.com/), go to **Transactions** > **Transfers**, and click on a declined transaction. You can see all the transactions rules that the transaction triggered.

## Next steps

[required](/issuing/authorisation/transaction-rules/create-and-manage)

[Create transaction rules](/issuing/authorisation/transaction-rules/create-and-manage)

[Send an API request to create transaction rules.](/issuing/authorisation/transaction-rules/create-and-manage)

[Transaction rule examples](/issuing/authorisation/transaction-rules/examples)

[See examples of transaction rules applied to use cases.](/issuing/authorisation/transaction-rules/examples)
