6.5. Order details: restriction list management

6.5.1. Overview

Starting from release 3.23.01 you can manage black, white and loyal clients lists from the Order Details screen. It allows quicker determining the reason why a filter was applied to the order and making the process of putting the transactions attributes to respective lists faster and easier.

The denial lists are divided into two groups:

• local - the lists are applied for the given Project of the Merchant
• global - the lists are applied globally to all Manager’s Projects

The local lists management is allowed for the user who have the role of Merchant or higher, global lists management - for the ones with role of Manager and higher. The full list of existing lists is shown on the picture. G affix designates the lists modified by Manager or higher role. In order to change the attribute status click the respective icon.

The access control lists are made as filters. The order in which filters a re applied is hardcoded into the system and defined in the following way:

• local black lists of the Merchant (black colored group on the Figure 1)
• white lists(white colored group on the Figure 1)
• recursive black lists of the Manager (red colored group on the Figure 1)
• predefined lists of the verified clients (green colored group on the Figure 1 )

The lists are being checked while processing the transaction when the respective filter gets applied.

6.5.2. Local black lists of the Merchant

The first filter that checks the transaction’s attributes is “Merchant black lists”. The Merchant can enter the following 5 types of attributes to the black list: the card number(source card number for money transfer), the target card number of the money transfer, BIN of the card issuing bank to deny the transactions from a particular bank’s cards, IP address and email address of the client. You can also manage these attributes(excluding BIN) from the Order details screen. The attributes could be in two statuses

• attribute is in black list
• attribute is not in black list

If any transaction attribute matches the attributes in the lists and respective filter is enabled at the Project’s level the transaction status is set to Filtered and the reason for filtering is saved to the transaction data. There exist six reasons:

• 1039: the card number of the incoming transaction is in the black list
• 1022: BIN of the incoming transaction is in the black list, you are not allowed to manage this list on the Order details screen
• 1079: the “purpose” field of the incoming transaction is in the black list
• 1083: BIN of the receiving party for Money Transfer is in black list
• 1040: IP address of the customer is in the black list
• 1041: The email address of the customer is in the black list
• 1077: the card number of the receiving party for Money Transfer is in black list

You should be careful to put client’s IP address to the black list because most clients have dynamic IP which can be assigned to a different client by the Internet provider. The mobile Internet users change their IP address each time the session is created. You should also be aware that the users who use traffic compression services(Opera Mobile etc) are coming via IP address of the proxy server that provides the service, most of them are located in Europe. According to statistics if you deny the IP address for more than 10 hours the filtering will be in 80% cases false positive. This is why it is not recommended to filter transactions by IP without proper control.

Before you put the IP address into the black list you should check with the Internet provider what maximal period of IP address denial you can apply. You should also check if the given IP address is in any third-party anti spam systems.

6.5.3. Local black lists of the Manager

• 1104: the card number of the incoming transaction is in the black list
• 1108: the “purpose” field of the incoming transaction is in the black list
• 1105: the card number of the receiving party for Money Transfer is in black list
• 1106: IP address of the customer is in the black list
• 1107: The email address of the customer is in the black list

6.5.4. White lists

If the filter finds the transaction attributes in the black list the subsequent filters will not be applied. To avoid that the white lists are being used. The only attribute you can add to the white list is a card number. There exist three types of white lists

• the list of cards which are charged manually by the Merchants
• the list of cards which receive the money in Money Transfer
• the list of cards which are charged manually by the Manager

The first two are used by the Merchant in case the client has any issues with the transaction. The third one is available to the Manager, usually in order to make a list of test cards. If the card number is found in any white list the other fraud control filters are not applied.

If the card number is found in any white list the third party fraud control systems’ checks are excluded either.

6.5.5. Recursive Manager’s black lists

For this kind of lists the Merchant must carefully define the transaction’s attributes which are available in the API. Before you enable this filter for the Merchant you should discuss with the Administrator if the filter can be activated for you and if the respective profile of the behavioral adaptive internal fraud control system exists. If the setup is not correct it is possible that you will experience cascading transactions denial for the Merchants who are using the profile, because the filter checks the client’s transactions available at the moment and recursively denies the transactions if the defined limits were reached. The filter uses the data available in the current system as well as the data coming form other systems for similar profiles. For the moment, you can manage three recursive lists

• the lists of the manually charged cards
• the lists of clients’ IP addresses
• the lists of clients’ email addresses

After checking all lists the filter generates the reason for filtering. It could be of two types:

• 1045: one of the transaction’s attributes is found in the group of recursive black lists or the evaluation of the client’s behavior exceeded the predefined limits. The other attributes will be automatically added to the recursive black lists as well as the attributes of the transactions related to this transaction
• 1049: the evaluation process has exceeded the internal fraud control system’s limits. The recursive black lists are not populated in this case

There exist recursive white lists in the system, they prevent the transaction denial. At the moment there’s no user interface to manage this kind of lists.

6.5.6. Predefined lists of verified clients(anti black lists)

In some cases Merchants have to work with the predefined set of clients and need to add new clients automatically if certain criteria are met. The clients database can be managed by the Merchant if it has PCI DSS certification or the Merchant can use MoneyNetint feature for this. The system allows to manage the following three types of predefined clients lists

• the lists of the cards manually charged be the Manager
• the lists of the clients’ names and email addresses
• the lists of the clients’ names and phone numbers

In the typical flow the filter distinguishes the credit cards transactions and the uncontested transactions. The credit cards transactions are initially disabled in the system(in case the list of predefined clients was not loaded). If the uncontested transaction was made, e.g. e-check transaction the client’s attributes like family name, email and phone number are automatically added to anti black lists. If the system gets the credit card transaction with the same attributes(at least two of them) the transaction is allowed and the card number is put under inspection. The inspection period is defined by the Manager and is 90 days by default. If there are no refunds or chargebacks for this card within the period of inspection all the attributes of the credit card transactions are added to anti black lists. If there are negatives for the credit card the client is marked unreliable and all subsequent transactions with similar attributes will be denied irregardless of what payment system was used. The elements of this list can have four statuses:

• data not available
• the attribute is in the anti black list: negative activity not present
• the attribute is in the anti black list: returns are present
• the attribute is in the anti black list: fraud is detected

The filter returns the code 1056.

The typical flow is described above, the flow may vary for particular Merchants.

The transaction is filtered erroneously, how can I accept the payment?

The easiest way is to add the card number to the white list. You should also check if other attributes of the transaction do not fall into local Merchant’s black lists, because the filter denies the transactions before white lists are checked. It is also possible that the transaction gets filtered by technical filters which are applied before white lists. The full list of enabled filters is available at the Endpoint details screen, within "Filters" tab.

I want to define different flow for the verified clients.

If your flow can use the data present in the system the flow can be developed by MoneyNetint development team. Please, create an enhancement request with the details.

I can see on the Order details screen that the email/IP/card number is in white/black/anti black list but it doesn’t work as expected.

Check if the filter is enabled at the Project level and at the Endpoint, because Endpoint setup overrules the Project level configuration.

The transaction attributes are not in the black list but the transactions are declined with the reason provided: Black List.

The black lists are also defined at Processor level. Check the Processor configuration, e.g. the country black list.

I try to add transaction’s attributes to recursive black list but it doesn’t work as expected.

It is possible that this attribute was added to recursive white list. It’s not possible to verify this attribute. Usually it happens due to incomplete integration of a Merchant or the client has used stop attribute, e.g. dummy email like example@email.com defined in the Merchant’s payment form by default.