3.9. Routing & Balancing

3.9.1. General Information

The routing & balancing system allows to distribute traffic between payment gates flexibly depending on the defined criteria and customer’s transaction data. Traffic can be routed to a specific group of gates/processors and distributed between them in accordance with the specified balancing. The balancing is configured on the system Project level in the Routing & Balancing tab.

One of routing types must be selected to start the configuration:

New routing block will be created. Each routing block has it’s own ID for easier navigation in big projects. The Source Card Type routing type is taken as an example:

Hover the cursor over the name of this block to select one of the following actions:

- Add routing row - to add options for this block

- Delete node - to select another routing or balancing block instead of this one.

Hover the cursor over the any criterion of this block to select one of the following actions:

- Continue Routing - to select new routing block and continue the routing strategy.

- Add balancing - to stop the routing and add the balancing block.

- to enable, disable or delete the routing option.

The default option named OTHERS is always present, it applies for transactions which don’t match all other created options.

If the created routing options are enough, click the Add balancing button to add one of the balancing types with the payment gates.

The Balance by coefficient Based on Tx Amount is taken as an example:

Blocks are connected by arrows to improve the visual presentation. An arrow is directed from a certain routing option to the block created from it. If the transaction parameters match the specified routing option, it is forwarded further along the arrow.

Hover the cursor over the name of this block to select one of the following actions:

- Add balancing row - adds the row with active fields to specify the gate:

• Payment gate - the longest field is used to select one of the available payment gates.
• Probability percentage - far left field. This percentage determines how likely the transaction is to go to this gate. This field exists only for balancing types with a specified coefficient.
• Three empty fields at the bottom are used to redefine the payment rates.

- Delete node - to select another routing or balancing block instead of this one.

- Create group - to create a group of the balancing.

If the transaction meets the created route conditions, it will be forwarded to the balancing block with this payment gate. For more routing criteria, click the Add routing row of the required criterion, then create the subsequent transaction path from it. New block appears to the right of the selected criterion with a new number and routing type name.

The Source Card BIN routing type is taken as an example:

There is already an “OTHERS” default criterion below. As in the first case, click the Add routing row to add the appropriate criterion. Depending on the required routing strategy and the traffic separation level, go on building the routes or finish the route by adding one of the Balancing types and clicking Add balancing row to add the payment gate. After the Routing & Balancing configuration is set, enable it by going to the “Project” menu, clicking the “Edit” button and selecting the “Use new balancing” check box at the bottom of the page. To confirm the selection, click “Update”.

Now, the Routing & Balancing is applied and all the traffic will go through it.

3.9.2. Routing types

Several “routing types” are used in the Routing & Balancing to configure the transaction routes more flexibly.

Routing types are filters which allow to specify the traffic separation. Depending on the selected routing type, the transaction flow will be checked in relation to its parameters.

In the Routing & Balancing such routing types are represented as follows:

Source Card

1. The Source Card Type routing type allows to sort transactions by the sender’s card type. Select the appropriate payment methods of the sender and build a further route based on them.

2) The Card Range routing type allows to sort transactions by the sender’s card BIN value. Specify bin and choose the needed BIN range of the sender and build a further route based on it. Several BIN ranges can be found for the specified BIN value. Select the one with lower priority. There is an option to search cards by their BINs. System can search for up to 500 entered card BINs listed one after another and separated by commas. They can be chosen by pressing the “BINs -” button.

3) The Source Card Bank routing type allows to sort transactions by the sender’s Issuer Bank name. Select the needed names of sender’s Issuer Banks and build a further route based on them. There is an option to search Banks by their names. System can search for up to 500 entered Bank names listed one after another and separated by commas. They can be chosen by pressing the “By name -” button.

4. The Source Card Country routing type allows to sort transactions by the sender’s card Country. Select the needed countries of the sender and build a further route based on them.

5. The Source Card Credit Source routing type allows to sort transactions by the sender’s card type. Select the needed card types of the sender and build a further route based on them.

Destination Card

1. The Destination Card Type routing type allows to sort transactions by the receiver’s card type. Select the needed card types of the receiver and build a further route based on them.

2) The Card Range routing type allows to sort transactions by the receiver’s card BIN value. Specify bin and choose the needed BIN range of the receiver and build a further route based on it. Several BIN ranges can be found for the specified BIN value. Select the one with lower priority. There is an option to search cards by their BINs. System can search for up to 500 entered card BINs listed one after another and separated by commas. They can be chosen by pressing the “BINs -” button.

3) The Destination Card Bank routing type allows to sort transactions by the receiver’s Issuer Bank name. Select the needed Issuer Bank names of the receiver and build a further route based on them. There is an option to search Banks by their names. System can search for up to 500 entered Bank names listed one after another and separated by commas. They can be chosen by pressing the “By name -” button.

4. The Destination Card Country routing type allows to sort transactions by the receiver’s card country. Select the required card countries of the receiver and build a further route based on them.

5. The Destination Card Credit Source routing type allows to sort transactions by the receiver’s card type. Select the needed card types of the receiver and build a further route based on them.

Customer

1. The Customer Account Number Country routing type allows to sort transactions by connecting selected countries to one provider, and the remaining countries connecting to another. This routing type is used for payout transactions. Country and bank are determined by IBAN (International Bank Account Number), which has been generated in accordance with ISO 13616.

2. The Customer IP Country routing type allows to sort transactions by the IP address of the customer’s country. Select the countries, the IPs of which will be checked and build a further route based on them.

3. The Customer IP Range routing type allows to sort transactions which IP address values are within the specified range. Specify the appropriate IP range and build the further route from it. Both IPv4 and IPv6 are accepted.

4. Customer Billing Country routing type allows to sort transactions by the country from the customer’s billing address. Select the needed countries and build a further route based on them.

5. Customer Loyalty routing type is divided into endpoint, project, merchant, manager. Each of these levels has a Returning customer approve sessions count field that can be set for Managers by users with Superior role, while for Projects, Endpoints and Merchants - by users with Manager role.

This value sets the number of transactions after which the customer will be considered “RETURNING”. Select the loyalty types and build a further route based on them. Also, in an Endpoint settings, you can set the parameters by which the client will be defined. This option is called Client definition. Definition is possible by card number, email, card holder and email, card holder and purpose, card holder and phone. For RETURNING_FOR_MERCHANT, RETURNING_FOR_MANAGER and RETURNING_FOR_ENDPOINT the client definition is taken from Endpoint. For RETURNING_FOR_PROJECT the client definition is taken from Project.

6. by Recurring and Non_recurring routing types allows to sort transactions based on whether transaction type is recurrent or not.

7. by purpose routing type allows to sort transactions based on purpose parameter. It is possible to enter more than one purpose value to each routing row. New values are added using the Add button which is available when editing or creating. Purpose is limited to 128 symbols.

8. by Phone IMEI (IMEI or International Mobile Equipment Identity) routing type allows to sort transactions based on IMEI parameter. IMEI is the individual number of the mobile equipment. It is possible to enter more than one IMEI value to each routing row. IMEI is limited to 32 symbols.

Transaction

1. Transaction Amount routing type allows to sort transactions by their amounts. The number in the square bracket is included in the range and the number in the round bracket is not included in the range. For example, to specify amount from 0 to 100 (including 100), use [0, 100.01). Transactions, which amounts match the specified range, will pass through this routing criterion.

2. Transaction Type routing type allows to sort transactions by their type. Select the needed transaction types and build a further route based on them.

3. Amount Multiplicity routing type allows to sort transactions by their amounts matching with specified multipliers. Add amount multiplicity and transaction will route by the highest amount to which it is a multiple. Example: If transaction amount is 1000 and “Amount multiplicity” is settled as 1000 and 500, transaction will route to 1000, and if transaction amount is 1500 it will route to 500, and if transaction amount is 2000 it will route to 1000.

4. Transaction Time routing type allows to sort transactions by the time they are created in the system. Timezone GMT+3. This sort type can be used for processor technical breaks or for any other reason when time is necessary for any route. To set the time, for example, from 22:00 till 06:00, set the time the following way: [22:00:00, 23:59:59], [00:00:00, 06:00:00].

5. by Day of week routing type allows to sort transactions by day of the week. Select the needed day of the week and time zone for further route based on them.

Transfer

1. Transfer Direction routing type allows to sort transfer transactions by card types or Issuer banks of sender and receiver. Select the needed parameters and build a further route based on them.

IP Intelligence

1. Anonymous vpn routing type allows to check when Payer IP address is considered as anonymous vpn by MaxMind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.

2. Anonymous IP address routing type allows to check when Payer IP address is considered as anonymous by MaxMind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.

3. Hosting provider routing type allows to check when Payer IP address belongs to a hosting or VPN provider considered by MaxMind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.

4. Public proxy routing type allows to check when Payer IP address belongs to a public proxy considered by MaxMind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.

5. Residential proxy routing type allows to check when Payer IP address belongs to a hosting or VPN provider considered by MaxMind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.

6. Tor exit node routing type allows to check when Payer IP address a Tor exit node considered by MaxMind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.

7. Static IP score routing type allows to check when Payer IP address Static IP score which is considered by MaxMind service is lower or equal to the settled threshold value. Higher values meaning a greater static association. For example, many IP addresses with a user type of cellular have a score under one. Broadband IPs that don’t change very often typically have a score above thirty. This indicator can be useful for deciding whether an IP address represents the same user over time. The value ranges from 0 to 99.99. Select the needed parameters and build a further route based on them.

8. User count routing type allows to check when Payer IP address user count considered by MaxMind service is higher or equal to the settled threshold value. The estimated number of users sharing the IP/network during the past 24 hours. For IPv4, the count is for the individual IP. For IPv6, the count is for the /64 network. Select the needed parameters and build a further route based on them.

Warning

If Fraud Service - “MaxMind IP check service” is selected on project level, then regardless of whether “fraud filters” or “routing&balancing” are set up - all requests will be send to Max Mind.

3.9.3. Balancing types

Balancing type is a feature which allows to distribute transactions between payment gates in accordance with the configured parameters.

Note

The gate can also be specified directly on the endpoint. However, it will still be subject to the routing strategy, but will be selected for all transactions coming from this endpoint on this route.

The following balancing types are presented in the system:

Balance by Coefficient

1. Balance by coefficient Based on Tx Amount allows to sort transactions by the gates depending on the amount and the specified probability percentage.

For example, 3 gates have 20%, 30% and 50% coefficients set for them. In this case, 50% of the first several processed transactions will be forwarded to the gate with the probability of 50%, then the traffic will try to reach the distribution of the amount between the gates in accordance with the specified percentages. If the processed amount on a gate exceeds the amounts on the other gates, the transactions will not be forwarded to the gate with the exceeding amount until the amounts on all the gates become equal to the percentages set for the gates.

2. Balance by coefficient Based on Tx Count allows to sort transactions by gates depending on their quantity and the specified probability percentage.

For example, 3 gates have 20%, 30% and 50% coefficients set for them. In this case, 50% of the processed transactions will be forwarded to the gate with the probability of 50%. The transaction amounts are not considered, only their quantity is.

Balance Equally

1. Balance equally Based on Tx Amount allows to sort transactions by gates depending on the amount with equal probability percentage.

If there are e.g. 4 gates, “Balance equally on Tx Amount” will set an equal probability percentage of 25% for each gate. The first several transactions can be forwarded to any of them as the percentages are equal, then the traffic will try to reach the equal distribution of the amount between the gates. If the processed amount on a gate exceeds the amounts on the other gates, the transactions will not be forwarded to the gate with the exceeding amount until the amounts on all the gates become equal.

2. Balance equally Based on Tx Count allows to sort transactions by gates depending on the quantity with equal probability percentage.

If there are e.g. 4 gates, “Balance equally on Tx Count” will set an equal probability percentage of 25% for each gate. The first several transactions can be forwarded to any of them as the percentages are equal, then the traffic will try to reach the equal distribution between the gates based on the quantity of transactions.

Cascading Chain

1. Chain by Coefficient Based on Tx Count allows to sort transactions by gates using the specified probability percentage and the chain principle. If the incoming transaction is going to be filtered or exceed the limits on some gates, the balancing algorithm excludes these gates and then it forms the chain with the remaining ones according to their coefficients.

For example, 3 gates have 20%, 30% and 50% coefficients set for them. In this case, the gate with 50% coefficient has the 50% probability of becoming the first gate in the formed chain. If for some reason the first gate in chain was unable to process the transaction, it goes to the next gate in chain. If the second gate was not able to process the transaction as well, it moves on until one of the subsequent gates in chain processes it. The traffic will try to reach the distribution between the gates according to their coefficients based on the quantity of transactions.

2. Chain by Equivalently Based on Tx Count allows to sort transactions by gates using the chain principle and an equal probability percentage. If the incoming transaction is going to be filtered or exceed the limits on some gates, the balancing algorithm excludes these gates and then it forms the chain with the remaining ones based on equal probability percentage.

If there are e.g. 4 gates, “Chain by equivalently on Tx Count” will set an equal probability percentage of 25% for each gate. In this case, each gate has the 25% probability of becoming the first gate in the formed chain. If for some reason the first gate in chain was unable to process the transaction, it goes to the next gate in chain. If the second gate was not able to process the transaction as well, it moves on until one of the subsequent gates in chain processes it. The traffic will try to reach the equal distribution between the gates based on the quantity of transactions.

3. Chain by Sequence allows to sort transactions using the cascading chain principle.

Transactions will be processed by gates only in a priority order. If for some reason the first gate in the chain was not able to process the transaction, it moves further along the chain until one of the subsequent gates in chain processes it. The gate priority can be changed in “Chain by Sequence” using drag’n’drop.

4. Chain by Last Customer Tx Status on Acquirer allows to sort transactions by resulting transaction status and the chain principle.

All client transactions (defined by email) are checked within the exact processor (not among all of them) and the next transaction is routed to the gate with last successful transaction of this client. If attempt on this gate was declined, transaction moves further along the chain until one of the subsequent gates in chain processes it.

Others

1. First in Sequence allows to sort transactions by choosing the first appropriate gate for them.

If the incoming transaction is going to be filtered or exceed the limits on certain gates, the “First in Sequence” algorithm excludes these gates and then it sends the transaction to the highest gate of the remaining ones. The gate priority can be changed by dragging it up and down.

2. First in Sequence by Last Customer Tx Status on Acquirer allows to sort transactions by resulting transaction status.

All client(by e-mail) transactions for all projects are checked and the next transaction is routed to the gate with processor of the last successful transaction project-wide. If a transaction is in declined status, gate is moved to the bottom of the sequence and receives lowest priority. Also, all gates belonging to the same processor as the gate on which the rejection status occurred receive low priority. Gate with processor with last approved transaction will be first in sequence, a gate with processor with earlier approves or no approves will be last.

3. First in Sequence by Last Customer Tx Status on Gate allows to sort transactions by resulting transaction status.

All client(by e-mail) transactions are checked and the next transaction is routed to the gate of the last successful transaction project-wide. If a transaction is in declined status, gate is moved to the bottom of the sequence and receives lowest priority. Unlike First in Sequence by Last Customer Tx Status on Acquirer balancing type, the gates belonging to the same processor as the gate on which the declined status occurred do not lose priority and do not fall at the end of the sequence. Gate with last approved transaction will be first in sequence, a gate with earlier approves or no approves will be last.

3.9.4. Chain strategy details

Chain strategy details allows to select which Declines (negative processing results) will continue or stop the chain.

If the configured routing has such balancing types as: Chain by Sequence, Chain by Equivalently on Tx Count, Chain by Coefficient on Tx Count, it’s possible to go to the “Chain Strategy Details” tab on the gate level and select the criteria to continue or stop the chain.

The number and name of the gate is at the top of the page. The active line “Continue the chain” is located below and the choice of criteria is to the right of it. “Independently of the decline reason” is selected by default.

Two active columns – “Unavailable” and “Available” – are located below. The reasons for decline are located in the “Unavailable” field. The chain can continue:

• Independently of the decline reason - the chain will continue regardless of the received decline codes.
• Only for the selected decline reasons - the chain will continue only for the specified decline reasons. Select the reasons from the “Unavailable” column with the check boxes next to them, and add them to the “Available” column by clicking the “Add” button. Remove the unwanted reasons by selecting them with the check boxes and clicking the “Remove” button. Confirm the parameters with the “Save” button.
• For any decline reason except the selected ones - the chain will continue for all reasons, EXCEPT for the specified ones. Select the reasons from the “Unavailable” column with the check boxes next to them, and add them to the “Available” column by clicking the “Add” button. Remove the unwanted reasons by selecting them with the check boxes and clicking the “Remove” button. Confirm the parameters with the “Save” button.

3.9.5. Chain strategy skips

Chain strategy skips allows to skip a gate per PAN for a transaction if one of selected errors codes occur. After transaction is declined for a specific PAN on one gate, this gate will be skipped from cascading on next transactions with the same PAN for the specified time period (set in minutes).

This functionality is supported for the following options:

• Chain by Sequence
• Chain by Last Customer tx Status on Acquirer
• Chain by Coefficient Based on tx Count
• Chain by Equivalent Coefficient Based on tx Count
• First in Sequence
• First in Sequence by Last Customer tx Status on Acquirer
• First in Sequence by Last Customer tx Status on Gate

3.9.6. Rates

Rates is a system of payment fees for all stakeholders’ services.

The system supports such stakeholders as:

Merchant, Reseller, Manager, Dealer, Bank.

In the current model, the fees are incrementally increasing, from the Bank to the Merchant. The following rate plan will count the value of the previous one. Thus, the higher the participant’s level is, the greater his total fee is in the system. The Bank and Dealer rate plans can be set on the gate level. Manager, Reseller, and Merchant rate plans can be set on the project level, with the option to override them on the endpoint level. The presence of some participants in the payment rates model is optional.

In Routing & Balancing the Rates can be redefined directly on the gates configuration in balancing blocks. These Rates settings override the ones on project or endpoint level.

There are 3 active fields below at the gate’s name, which are responsible for redefining rate plans for Manager, Reseller and Merchant, from left to right respectively. All rate plans can be selected from the dropdown list of already created ones.

3.9.7. Filters and acquirer restrictions

Filters are the configurable sets of rules which allow to restrict the traffic by certain criteria (Gate and Processor levels).

Gate level

Filters, which are applied in the Routing & Balancing, can be configured on the gate level. To switch them on, go to the required gate and click on the “Acquirer restrictions” tab

Warning

If filter on the gate is triggered, this gate is removed from balancing block for the current transaction.

Information and reason codes about gates which were excluded from balancing due to triggered filters is displayed in transaction details on UI:

API response text for these filters can be found on Payneteasy internal errors

There are such filters as:

Filter Name	Comment	UI code
Whitelist check (WL)	Allows ignoring all other Acquirer restrictions for selected Source credit card numbers and Device fingerprints. Sometimes customer’s behavior can lead to the unfortunate situation where a shopper is completely unable to process transactions. You can whitelist a customer’s data so they can successfully process their transaction. White list could be specified for the exact Source card number by manager and the exact Device fingerprint by manager.
Predefined loyalty lists check	Allows processing for trusted customers only. Different acquirers have different definitions of a trusted customer, this filter allows processing for customers with emails, source/destination card or purpose in corresponding loyalty lists only. Transactions for customers that are not listed in any loyalty list will be filtered out.	15034,15035,15036,15037
Automatic loyalty lists check	This filter allows to specify a set of gates (group name) and create subsets of gates (financial instruments) within this set scope to allow processing of transactions with card numbers only on linked subsets of gates. Each card number which is processed by one of the gates within the set (group name) for the first time is linked to the subset (financial instrument) of the gate used for processing. All new transactions with the same card number will be allowed to process only on gates with the linked financial instrument and filtered on all other gates with different financial instruments within the same group name set. If the group name or financial instrument is not indicated on the gate, this filter will not be applied (even if it’s enabled).	15110
Destination Credit Card type check	This referral list allows to block transactions processing for selected Destination Credit Card types (Business, Corporate, etc.)	15170
Source Credit Card type check	This referral list allows to block transactions processing for selected Source Credit Card types (Business, Corporate, etc.)	15171
Source Credit Card Number usage frequency for last 24 hours (daily limit)	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	15004,15005
Source Credit Card Number usage frequency for last 7 days (weekly limit)	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	15002,15003
Source Credit Card Number usage frequency for last month (monthly limit)	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.	15000,15001
Source Credit Card Number usage frequency for last 3 months	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 3 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 3 months. Counts Sale, Preauth or Transfer transactions in the approved status.	15075,15076
Source Credit Card Number usage frequency for last 6 months	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 6 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 6 months. Counts Sale, Preauth or Transfer transactions in the approved status.	15077,15078
Source Credit Card Number usage frequency for last 12 months	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 12 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 12 months. Counts Sale, Preauth or Transfer transactions in the approved status.	15079,15080
Purpose usage frequency for last 24 hours (daily limit)	This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	15016,15017
Purpose usage frequency for last 7 days (weekly limit)	This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	15014,15015
Purpose usage frequency for last month (monthly limit)	This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.	15012,15013
Email usage frequency for last 24 hours (daily limit)	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	15010,15011
Email usage frequency for last 7 days (weekly limit)	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	15008,15009
Email usage frequency for last month (monthly limit)	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.	15006,15007
Visa Preauthorized Transaction Decline Response requirements	This check fires for recurring transactions only. Merchants that receive a decline response for a preauthorized transaction will only be allowed to resubmit it for authorization up to four times within 13 calendar days from the date of the original decline response for the same acquirer if the response code is one of the following: Response Code 05-Authorization Declined Response Code 51-Insufficient Funds Response Code 61-Exceeds Approval Amount Limit Response Code 65-Exceeds Withdrawal Frequency Limit If an approval response is not received within this time frame, merchants must not resubmit the transaction or their acquirers may be subject to non-compliance actions, as outlined in the Visa Rules, and may be subject to chargebacks. Visa Rules to prohibit acquirers and their recurring services merchants from resubmitting a declined transaction for authorization if it receives a pickup response: Response Code 04-Pick Up Card Response Code 07-Pick Up Card, Special Response Code 33-Expired Card, Capture Response Code 34-Suspected Fraud, Retain Card Response Code 35-Card Acceptor, Contact Acquirer, Retain Card Response Code 36-Restricted Card, Retain Card Response Code 37-Contact Acquirer Security Department, Retain Card Response Code 41-Lost Card Response Code 43-Stolen Card Response Code 67-Capture Card or a decline response of Response Code 14-Invalid Account Number (No Such Number) Response Code 54-Expired Card Response Code 57-Transaction Not Permitted. The time threshold is a moving window calculated backwards from the moment of the transaction. Counts Account verification, Sale, Preauth or Transfer transactions in Declined status for listed decline reasons. Correct decline reasons should be supported by a connected PSP. Limits are calculated separately per gate descriptor and not per gate.	15023,15024 - CANCEL,15025 - PICKUP,15026 - DELAY
Entire Email usage frequency for last 24 hours (entire daily limit)	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in any status.	15042,15043
Entire Email usage frequency for last 7 days (entire weekly limit)	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in any status.	15044,15045
Entire Email usage frequency for last month (entire monthly limit)	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in any status.	15046,15047
Entire Purpose usage frequency for last 24 hours (entire daily limit)	This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in any status.	15048,15049
Entire Purpose usage frequency for last 7 days (entire weekly limit)	This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in any status.	15050,15051
Entire Purpose usage frequency for last month (entire monthly limit)	This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in any status.	15052,15053
Entire Source Credit Card Number usage frequency for last 24 hours (entire daily limit)	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in any status.	15054,15055
Entire Source Credit Card Number usage frequency for last 7 days (entire weekly limit)	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in any status.	15056,15057
Entire Source Credit Card Number usage frequency for last month (entire monthly limit)	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in any status.	15058,15059
Entire Source Credit Card Number usage frequency for last 3 months (entire 3 months limit)	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 3 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 3 months. Counts Sale, Preauth or Transfer transactions in any status.	15081,15082
Entire Source Credit Card Number usage frequency for last 6 months (entire 6 months limit)	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 6 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 6 months. Counts Sale, Preauth or Transfer transactions in any status.	15083,15084
Entire Source Credit Card Number usage frequency for last 12 months (entire 12 months limit)	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 12 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 12 months. Counts Sale, Preauth or Transfer transactions in any status.	15085,15086
Source Credit Card Number usage frequency for Destination Credit Card Number	This check fires when the number of Source Credit Cards associated with exact Destination Credit Card number exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards in 6 hours, it fires on the 11th unique Credit Card in 6 hours. Counts unique Source Credit Card numbers for Transfer transactions in approved or declined status for the current Gate.	15072
Declined Email usage frequency for last 24 hours (decline daily limit)	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in declined status.	15066
Declined Email usage frequency for last 7 days (decline weekly limit)	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in declined status.	15068
Declined Email usage frequency for last month (decline monthly limit)	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in declined status.	15070
Source Credit Card Number declined transactions count per period	This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth, Payout or Transfer transactions in the approved status.	15125, 15126
Source Credit Card Number decline frequency for last 24 hours (daily decline limit)	This check fires when the number or amount of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined or Filtered status.
Source Credit Card Number decline frequency for last week (weekly decline limit)	This check fires when the number or amount of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 7 days. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.	15128, 15129
Source Credit Card Number decline frequency for last month (monthly decline limit)	This check fires when the number or amount of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.	15130, 15131
Destination Credit Card Number decline frequency for last 24 hours (daily decline limit)	This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Transfer transactions in the Declined status.	15132, 15133
Destination Credit Card Number decline frequency for last week (weekly decline limit)	This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Transfer transactions in the Declined status.	15134, 15135
Destination Credit Card Number decline frequency for last month (monthly decline limit)	This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Transfer transactions in the Declined status.	15136, 15137
Total Credit Card Number decline frequency for last 24 hours (daily decline limit)	This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.	15138, 15139, 15140, 15141
Total Credit Card Number decline frequency for last week (weekly decline limit)	This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.	15142, 15143, 15144, 15145
Total Credit Card Number decline frequency for last month (monthly decline limit)	This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.	15146, 15147, 15148, 15149
Source Credit Card Number usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	15150, 15151
Destination Credit Card Number usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Transfer transactions in the approved status.	15152, 15153
Total Credit Card Number usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	15154, 15155, 15156, 15157
Purpose usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	15158, 15159
Email usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	15160, 15161
IP address usage frequency for last N days	This check fires when the number or amount of transactions associated with exact IP address exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	15162, 15163
Fingerprint usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Fingerprint exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	15164, 15165
Account Number usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Account Number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	15166, 15167
Parameters available in this filter:
amount limit	Maximum total transactions amount for the last 24 hours for this credit card used as Source card for all gates with the same descriptor.	15073, 15074
quantity limit	Maximum total transactions count for the last 24 hours for this credit card used as Source card.	15073, 15074
BIN range usage frequency	This check fires when the number of transactions associated with the specific card BIN range exceeds the configured thresholds, also can specify a list of card BIN range exceptions for which checks will not be performed. The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 300 seconds. Counts Sale, Preauth, Payouts or Transfer transactions.	15119
Issuer country usage frequency	This check fires when the number of transactions associated with the same card issuer country exceeds the configured thresholds. The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 300 seconds. Counts Sale, Preauth, Payouts or Transfer transactions.	15114
Preventing transaction with the same amount	This check fires when more than one transaction is made with same amount in a time threshold (in seconds). The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the second transaction with the same amount during set time threshold. Counts Sale, Preauth, Payouts or Transfer transactions.	15113
Customer IP address Country differs from Issuing Country	This risk check fires when the customer IP country different from the issuing country of the card. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check. If parameter “apply for countries” is empty, filter will require strict customer country to issuer country matching for all the countries, otherwise this check will force country matching for listed countries only. For example if you setup “apply for countries” to US - check will be triggered for following country combinations US-anyNonUS or anyNonUS-US, but for combinations anyNonUS-anyNonUS and US-US the check will not fire. For card2card transactions issuer country of the source card should be equal to issuer country of the destination card, i.e. this check will be triggered for any cross-border transaction.	15116
Purpose usage frequency for last year (annual limit)	This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one year window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 100 transactions, it fires on the 101th transaction in one year. Calculation of the year can be started from the beginning of the calendar year or from the filter activation truncated to the month and -12 months. I.e. if you activated the filter on May 15, 2021, the filter will consider transactions from May 2020. Counts Sale, Preauth or Transfer transactions in the approved status.	15117,15118
Transaction number per period	This check fires when the number of transactions exceeds the configured thresholds. The maximum time threshold is a 600 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction during 600 seconds. Counts Sale, Preauth, Payouts or Transfer transactions.	15115
Minimum time between transactions in the acquirer	This check fires when more than one transaction is made with same card in the same financial instrument in a time threshold (in minutes). The maximum time threshold is a 120 minutes window, calculated backwards from the moment of the first transaction. The filter takes into consideration only approved transactions. The risk fires on the second transaction with the same card during set time threshold. Counts Sale and Transfer transactions.	15120
Account Number usage frequency for last 24 hours (daily limit)	This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth, Payout or Transfer transactions in the approved status.	15121, 15122
Account Number usage frequency for last 7 days (weekly limit)	This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth, Payout or Transfer transactions in the approved status.	15123, 15124
Account Number usage frequency for last month (monthly limit)	This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth, Payout or Transfer transactions in the approved status.	15125, 15126

Example of configuration “Email usage frequency for last month (monthly limit)” filter. To switch this filter on, click on the toggle button near it’s name:

This filter supports the following settings:

1. The Amount limit maximum total transactions amount for the last one month for this e-mail address. Value: total amount value.
2. For all gates with the same descriptor – current total transactions amount or count for the last one month for this e-mail address value would be calculated and converted to current gate currency to compare with amount or quantity limit. Specify the value “Y” (Yes) instead of “N” (No) to enable. Values: Y: for all gates with the same descriptor, N: for current gate only.
3. The quantity limit parameter specifies the transactions quantity limits. Value: total quantity value.
4. Use calendar month : Value: Y/N.

The choice of “Country Identifier” will be available in the “Deny” filter configurations.

Each country is assigned its own numerical identifier. The required country can be chosen from the list.

Processor level

Filters, can be configured on the processor level to affect all gates of this processor. To switch them on, go to the required processor and click on the “Acquirer restrictions” tab. Tab will be available only for manager account and linked superiors.

There are such restrictions as:

Filter Name	Comment	UI code and reason
Whitelist check (WL)	Allows ignoring all other Acquirer restrictions for selected Source credit card numbers and Device fingerprints. Sometimes customer’s behavior can lead to the unfortunate situation where a shopper is completely unable to process transactions. You can whitelist a customer’s data so they can successfully process their transaction. White list could be specified for: the exact Source card number by manager, the exact Device fingerprint by manager.
Predefined loyalty lists check	Allows processing for trusted customers only. Different acquirers have different definitions of a trusted customer, this filter allows processing for customers with emails, source/destination card or purpose in corresponding loyalty lists only. Transactions for customers that are not listed in any loyalty list will be filtered out..	18042 if Proccessor loyal source card number check failed, 18043 if Proccessor loyal destination card number check failed
Destination Credit Card type check	This referral list allows to block transactions processing for selected Destination Credit Card types (Business, Corporate, etc).	18112 if Proccessor unsupported destination product type
Source Credit Card type check	This referral list allows to block transactions processing for selected Source Credit Card types (Business, Corporate, etc).	18113 if Proccessor unsupported product type
Source Credit Card Number usage frequency for last 24 hours (daily limit)	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. Timeframe can be set to calendar day instead of 24 hours window.	18004 if Approved hourly amount limit reached, 18005 if Approved hourly quantity limit reached
Source Credit Card Number usage frequency for last 7 days (weekly limit)	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	18002 if Approved weekly amount limit reached, 18003 if Approved weekly quantity limit reached
Source Credit Card Number usage frequency for last month (monthly limit)	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.	18000 if Approved monthly amount limit reached, 18001 if Approved monthly quantity limit reached
Source Credit Card Number decline frequency for last 7 days (decline weekly limit)	This check fires when the number of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in declined status.	18058 if Weekly decline quantity limit exceeded for the same credit card number on processor, 18059 if Weekly decline amount limit exceeded for the same credit card number on processor
Source Credit Card Number decline frequency for last month (decline monthly limit)	This check fires when the number of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.	18060 if Monthly decline quantity limit exceeded for the same credit card number on processor, 18061 if Monthly decline amount limit exceeded for the same credit card number on processor
Destination Credit Card Number usage frequency for last 24 hours (daily limit)	This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Transfer transactions only in the approved status.	18032 if Destination approved hourly amount limit reached, 18033 if Destination approved hourly quantity limit reached
Destination Credit Card Number usage frequency for last 7 days (weekly limit)	This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Transfer transactions only in the approved status.	18030 if Destination approved weekly amount limit reached, 18031 if Destination approved weekly quantity limit reached
Destination Credit Card Number usage frequency for last month (monthly limit)	This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Transfer transactions only in the approved status.	18028 if Destination approved monthly amount limit reached, 18029 if Destination approved monthly quantity limit reached
Total Credit Card Number usage frequency for last 24 hours (daily limit)	This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	18038 if Total approved hourly amount limit reached, 18039 if Total approved hourly quantity limit reached
Total Credit Card Number usage frequency for last 7 days (weekly limit)	This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	18036 if Total approved weekly amount limit reached, 18037 if Total approved weekly quantity limit reached
Total Credit Card Number usage frequency for last month (monthly limit)	This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.	18034 if Total approved monthly amount limit reached, 18035 if Total approved monthly quantity limit reached
Email usage frequency for last 24 hours (daily limit)	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	18010 if E-mail approved hourly amount limit reached, 18011 if E-mail approved hourly quantity limit reached
Email usage frequency for last 7 days (weekly limit)	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	18008 if E-mail approved weekly amount limit reached, 18009 if E-mail approved weekly quantity limit reached
Email usage frequency for last month (monthly limit)	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.	18006 if E-mail approved monthly amount limit reached, 18007 if E-mail approved monthly quantity limit reached
Email usage lifetime	Allows to limit the number and amount of transactions available to an individual customer and set a limit on the processor for the ALL time of existence. Customer is determined by E-Mail. This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time period is lifetime. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction. Counts Sale, Preauth or Transfer transactions in the approved status.	18048 if E-mail approved lifetime amount limit reached, 18049 if E-mail approved lifetime quantity limit reached
Customer IP usage frequency for last 24 hours (daily limit)	This check fires when the number or amount of transactions associated with exact Customer IP address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	18022 if Customer IP approved hourly amount limit reached, 18023 if Customer IP approved hourly quantity limit reached
Customer IP usage frequency for last 7 days (weekly limit)	This check fires when the number or amount of transactions associated with exact Customer IP address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	18020 if Customer IP approved weekly amount limit reached, 18021 if Customer IP approved weekly quantity limit reached
Customer IP usage frequency for last month (monthly limit)	This check fires when the number or amount of transactions associated with exact Customer IP address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.	18018 if Customer IP approved monthly amount limit reached, 18019 if Customer IP approved monthly quantity limit reached
Purpose usage frequency for last 24 hours (daily limit)	This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	18016 if Purpose approved hourly amount limit reached, 18017 if Purpose approved hourly quantity limit reached
Purpose usage frequency for last 7 days (weekly limit)	This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.	18014 if Purpose approved weekly amount limit reached, 18015 if Purpose approved weekly quantity limit reached
Purpose usage frequency for last month (monthly limit)	This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.	18012 if Purpose approved monthly amount limit reached, 18013 if Purpose approved monthly quantity limit reached
BIN range usage frequency	This check fires when the number of transactions associated with the specific card BIN range exceeds the configured thresholds, also can specify a list of card BIN range exceptions for which checks will not be performed. The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 300 seconds. Counts Sale, Preauth, Payouts or Transfer transactions.	18056 if Transaction quantity limit exceeds by BIN range on processor
Issuer country usage frequency	This check fires when the number of transactions associated with the same card issuer country exceeds the configured thresholds. The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 300 seconds. Counts Sale, Preauth, Payouts or Transfer transactions.	18053 if Transactions quantity limit exceeds by country on processor
Preventing transaction with the same amount	This check fires when more than one transaction is made with same amount in a time threshold (in seconds). The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the second transaction with the same amount during set time threshold. Counts Sale, Preauth, Payouts or Transfer transactions.	18052 if Same amount request on processor
Transaction number per period	This check fires when the number of transactions exceeds the configured thresholds. The maximum time threshold is a 600 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction during 600 seconds. Counts Sale, Preauth, Payouts or Transfer transactions.	18057 if Detected transaction in the set threshold of time
Account Number usage frequency for last 24 hours (daily limit)	This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth, Payout or Transfer transactions in the approved status.	15121, 15122
Account Number usage frequency for last 7 days (weekly limit)	This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth, Payout or Transfer transactions in the approved status.	15123, 15124
Account Number usage frequency for last month (monthly limit)	This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth, Payout or Transfer transactions in the approved status.	15125, 15126
Destination Credit Card Number decline frequency for last 24 hours (daily decline limit)	This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Transfer transactions in the Declined status.	18068 if Daily decline amount limit exceeded for the recipient on processor, 18069 if Daily decline quantity limit exceeded for the recipient on processor
Destination Credit Card Number decline frequency for last week (weekly decline limit)	This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Transfer transactions in the Declined status.	18070 if Weekly decline amount limit exceeded for the recipient on processor, 18071 if Weekly decline quantity limit exceeded for the recipient on processor
Destination Credit Card Number decline frequency for last month (monthly decline limit)	This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Transfer transactions in the Declined status.	18072 if Monthly decline amount limit exceeded for the recipient on processor, 18073 if Monthly decline quantity limit exceeded for the recipient on processor
Total Credit Card Number decline frequency for last 24 hours (daily decline limit)	This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.	18074 if Daily decline total amount limit exceeded for the sender on processor, 18075 if Daily decline total quantity limit exceeded for the sender on processor, 18076 if Daily decline total amount limit exceeded for the recipient on processor, 18077 if Daily decline total quantity limit exceeded for the recipient on processor
Total Credit Card Number decline frequency for last week (weekly decline limit)	This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.	18078 if Weekly decline total amount limit exceeded for the sender on processor, 18079 if Weekly decline total quantity limit exceeded for the sender on processor, 18080 if Weekly decline total amount limit exceeded for the recipient on processor, 18081 if Weekly decline total quantity limit exceeded for the recipient on processor
Total Credit Card Number decline frequency for last month (monthly decline limit)	This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.	18082 if Monthly decline total amount limit exceeded for the sender on processor, 18083 if Monthly decline total quantity limit exceeded for the sender on processor, 18084 if Monthly decline total amount limit exceeded for the recipient on processor, 18085 if Monthly decline total quantity limit exceeded for the recipient on processor
Source Credit Card Number usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	18086 if Approved specified period amount limit reached, 18087 if Approved specified period quantity limit reached
Destination Credit Card Number usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Transfer transactions in the approved status.	18088 if Approved specified period amount limit reached, 18089 if Approved specified period quantity limit reached
Total Credit Card Number usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	18090 if Total specified period amount limit reached, 18091 if Total specified period quantity limit reached, 18092 if Total specified period amount limit reached for recipient, 18093 if Total specified period quantity limit reached for recipient
Purpose usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	18094 if Purpose approved specified period amount limit reached, 18095 if Purpose approved specified period quantity limit reached
Email usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	18096 if E-mail approved specified period amount limit reached, 18097 if E-mail approved specified period quantity limit reached
IP address usage frequency for last N days	This check fires when the number or amount of transactions associated with exact IP address exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	18098 if IP address approved specified period amount limit reached, 18099 if IP address approved specified period quantity limit reached
Fingerprint usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Fingerprint exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	18100 if Fingerprint approved specified period amount limit reached, 18101 if Fingerprint approved specified period quantity limit reached
Account Number usage frequency for last N days	This check fires when the number or amount of transactions associated with exact Account Number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.	18102 if Specified period amount limit exceeded for account number on processor, 18103 if Specified period quantity limit exceeded for account number on processor

3.9.8. Copy, paste, cut, delete

Routing & balancing nodes can be deleted, along with all children:

Each deletion requires confirmation:

Fragments of balancing tree can also be cut and pasted:

Choose where to paste the cut fragment:

Result:

Parts of a balancing tree can be copied in a similar way as well:

3.9.9. Import and export

You can import and export your balancing tree:

Balancing tree file is generated in xml and has the following structure:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<strategy>
    <projectId>4947</projectId>
    <projectDisplayName>Recur AUD</projectDisplayName>
    <routingNodes>
    <routingNode>
            <id>8572</id>
            <routingId>1</routingId>
            <enabled>true</enabled>
            <routes>
                <route>
                    <id>23277</id>
                    <enabled>true</enabled>
                    <nextRoutingNodeId>8573</nextRoutingNodeId>
                    <others>true</others>
                    <criteria>
                        <criterion>
                            <value>OTHERS</value>
                        </criterion>
                    </criteria>
                    <order>0</order>
                </route>
            </routes>
            <root>true</root>
        </routingNode>
        <routingNode>
            <id>8573</id>
            <routingId>2</routingId>
            <enabled>true</enabled>
            <routes>
                <route>
                    <id>23279</id>
                    <enabled>true</enabled>
                    <nextRoutingNodeId>8574</nextRoutingNodeId>
                    <others>false</others>
                    <criteria>
                        <criterion>
                            <entityId>8104</entityId>
                            <entityName>213100</entityName>
                        </criterion>
                    </criteria>
                    <order>0</order>
                </route>
                <route>
                    <id>23278</id>
                    <enabled>true</enabled>
                    <others>true</others>
                    <criteria>
                        <criterion>
                            <value>OTHERS</value>
                        </criterion>
                    </criteria>
                    <order>1</order>
                </route>
            </routes>
            <root>false</root>
        </routingNode>
        <routingNode>
            <id>8574</id>
            <routingId>3</routingId>
            <enabled>true</enabled>
            <routes>
                <route>
                    <id>23281</id>
                    <enabled>true</enabled>
                    <nextRoutingNodeId>8575</nextRoutingNodeId>
                    <others>false</others>
                    <criteria>
                        <criterion>
                            <entityId>1825</entityId>
                            <entityName>VTB BANK</entityName>
                        </criterion>
                    </criteria>
                    <order>0</order>
                </route>
                <route>
                    <id>23280</id>
                    <enabled>true</enabled>
                    <others>true</others>
                    <criteria>
                        <criterion>
                            <value>OTHERS</value>
                        </criterion>
                    </criteria>
                    <order>1</order>
                </route>
            </routes>
            <root>false</root>
        </routingNode>
        <routingNode>
            <id>8575</id>
            <routingId>4</routingId>
            <enabled>true</enabled>
            <routes>
                <route>
                    <id>23282</id>
                    <enabled>true</enabled>
                    <balancingNodeId>8750</balancingNodeId>
                    <others>true</others>
                    <criteria>
                        <criterion>
                            <value>OTHERS</value>
                        </criterion>
                    </criteria>
                    <order>0</order>
                </route>
            </routes>
            <root>false</root>
        </routingNode>
    </routingNodes>
    <balancingNodes>
        <balancingNode>
            <id>8750</id>
            <enabled>true</enabled>
            <balancingId>1</balancingId>
            <rows>
                <row>
                    <id>0</id>
                    <enabled>false</enabled>
                </row>
            </rows>
        </balancingNode>
    </balancingNodes>
</strategy>