Introduction

WL Sips is a secure multi-channel e-commerce payment solution that complies with the PCI DSS standard. It allows you to accept and manage payment transactions by taking into account business rules related to your activity (payment on despatch, deferred payment, recurring payment, payment in instalments, etc.).

The purpose of this document is to describe the fraud management rules in Go-No-Go mode and to explain how to implement and set them up.

The Go-No-Go terminology corresponds to the binary nature of these rules, which is to have a GO or a NOGO regarding transaction acceptance.

Who does this document target?

This document is intended for merchants who have subscribed to the Go-No-Go fraud risk management offer and wish to enjoy an anti-fraud tool administered by themselves on their management Extranet.

To get an overview of the WL Sips solution, we advise you to consult the following documents:

  • Functional presentation
  • Functionality set-up guide
  • Glossary

Overview

Accessing the MEX

All fraud management functions described in this documentation are administered in the MEX .

You must have subscribed to the Go-No-Go Fraud risk management service to be able to access these functions.

The MEX is accessible through the following URL:

https://mex.fr.worldline.com/portal/home

Access is secure and requires a login and a password.

After login, click on the 'Fraud' tab to administer antifraud functions for your offer.

For more information please refer to the ' Configuring antifraud profiles with the MEX ' section.

Understanding fraud risk management

Before you begin, it is absolutely essential you understand how fraudsters perform their attacks.

Fraudsters are very well organised and take advantage of most of the weaknesses in the security and legal aspects of e-commerce. In particular:

  • they operate internationally
  • they use honest locals to carry out their fraudulent activities
  • they hide behind overseas proxies
  • 3-D Secure is not an obstacle for them
  • they renew their types of attacks on a regular basis

Therefore, it is essential you understand fraudulent behaviours at the merchant level when implementing antifraud rules. It is also very important you monitor the results regularly and maintain the correct settings accordingly. This is usually achieved through the creation of a fraud management team on your side.

The fraud risk management engine uses antifraud profiles to evaluate transactions. These profiles consist of rules that you configure.

Antifraud rule management is a virtuous circle beginning with the creation of an effective antifraud profile that suits your business. It continues with regular reviews of fraudulent activities and regular fine-tuning of this profile.

Note: the existing fraud management extranet and reporting tools are designed so you can manage the antifraud solution independently.

Antifraud rule definition

What is an antifraud rule?

An antifraud rule checks one of the transaction criteria. Le critère contrôlé peut être par exemple le pays de la carte, la plage de montants, le numéro de la carte, l’adresse IP, l’identifiant du client, etc. Les règles sont classées par catégorie : géolocalisation, vélocité, liste, panier et divers.

For example, the criterion checked can be the card country, the cap collar amounts, the card number, the IP address, the customer ID, etc. The rules are sorted by category: geolocation, velocity, list, basket and miscellaneous.

There are two types of rules: GO-type rules (detecting a favourable condition for the continuation of the transaction) and NOGO-type rules (detecting an unfavourable condition for the transaction).

To be executed, rules must be activated and configured in an antifraud profile. Please refer to the antifraud profile definition section to know how to define such a profile.

Rule types: GO or NOGO

GO-type rule

A GO-type rule aims to detect a favourable condition on the transaction, which results in a GO i.e. the transaction being accepted (e.g. the customer ID is on the customer ID whitelist).

The rule returns a positive result if the condition is met and a neutral result otherwise.

For now, GO-type rules are based on the presence of a transaction element on whitelists, which are also called positive lists.

NOGO-type rule

A NOGO-type rule aims to detect an unfavourable condition on the transaction, which results in a NOGO i.e. the transaction being refused (e.g. the customer ID is on the customer ID blacklist).

The rule returns a negative result if the condition is met an a neutral result otherwise.

There are 5 categories of NOGO-type rules:

  • geolocation rules
  • velocity rules
  • list rules
  • basket rules
  • miscellaneous rules

Decisive or informational mode

Rules can be configured in decisive or informational mode.

Decisive mode

A rule set as decisive has consequences on the execution of the transaction.

Decisive rules can produce 3 types of results that have consequences on the acceptance of the transaction:

  • Positive result

    A positive result indicates that the criterion checked is favourable for the acceptance of the transaction.

    Par example, if the customer ID is on the list of VIP customers ("customer ID whitelist" rule), there is no need to check other criteria.

  • Negative result

    A negative result indicates that the criterion verified is unfavourable for the acceptance of the transaction.

    For example, in pre-authorisation mode, the transaction is denied if the card in on the card greylist or blacklist.

  • Neutral result

    A neutral result indicates that the criterion checked is neither favourable nor unfavourable for the acceptance of the transaction.

    For example, the customer ID is not on the list of VIP customers ("customer ID whitelist" rule).

Informational mode

A rule set as informational has no consequences on the execution of the transaction. You are returned the result of the rule for analysis. For example, if the "IP address country" rule is set as informational, the rule simply returns the IP address country but will have no consequences on the acceptance of the transaction.

Advanced configuration

Some rules do not have necessarily a positive or negative nature (for example geolocation rules: you may want to favour some countries or unfavour others) whereas some others do have necessarily a positive nature (whitelists) or a negative nature (blacklists).

By default, the proposed rules are configurable in simple configuration mode, in which a rule is defined as being  positive (GO) or  negative (NOGO) .

Nevertheless, some rules have an advanced configuration mode. In this mode, the same rule can be both  positive (GO) and  negative (NOGO) . The rule will have a positive, negative or neutral influence on the result of the transaction check depending on the rule setting and the transaction context.

The choice to activate the advanced configuration mode is done during the rule configuration in the profile. It is possible to activate this mode only for certain rules and to let the simple configuration mode for the others.

Rule advanced settings allow specifying the criteria that will have a positive or negative influence on the result.

Example with the cap collar amount rule configured as decisive:

Rule configuration (profile) Transaction amount Result Consequences on pre-authentification mode
Simple configuration mode
  • Min = 50
  • Max = 200
45 Negative Trigger 3-D Secure
150 Neutral Proceed to the next rules
250 Negative Trigger 3-D Secure
Advanced configuration mode Positive range:
  • Min = 50
  • Max = 150

Negative range:

  • Min = 300
  • MAx = 400
45 Neutral Proceed to the next rules
100 Positive Trigger 3-D Secure
200 Neutral Proceed to the next rules
350 Negative Trigger 3-D Secure
450 Neutral Proceed to the next rules

Example with the 3-D Secure authentication rule configured as decisive:

Rule configuration (profile) 3-D Secure status of the transaction Result Consequences on pre-authorisation mode
Simple configuration mode Negative statuses:

ERROR

SUCCESS Neutral Proceed to the next rules
ERROR Negative Refuse the transaction before the authorisation request
Advanced configuration mode Negative statuses:

ERROR

Positive statuses:

SUCCESS

SUCCESS Positive Proceed to the authorisation request without doing the next rules
ERROR Negative Refuse the transaction before the authorisation request

Execution modes and consequences on acceptance

There are two execution modes for the WL Sips fraud risk management tool:

  • pre-authorisation mode: makes it possible to stop fraudulent transactions prior to the authorisation request
  • pre-authentication mode: makes it possible to bypass 3-D Secure for transactions considered as safe
Figure 1. processing progress during a payment transaction

Pre-authorisation mode

In pre-authorisation mode (default mode of the WL Sips fraud risk management tool), rules are executed prior to the authorisation request and following the 3-D Secure authentication (if the webshop is 3-D Secure enrolled). If the checking result is negative, the transaction will be declined prior to the authorisation request.

For means of payment with a redirection to a specific page for the related means of payment (Paypal for example), the pre-authorisation checking is trigerred prior to the redirection.

Depending on your needs, you define your pre-authorisation profile(s) by combining:

  • GO and/or NOGO rules
  • decisive and/or informational rules

A profile is informational when all of its rules are informational.

A profile is decisive when all of its rules are decisive.

A profile is mixed when it includes both informational and decisive rules.

Profile type WL Sips  / merchant Consequences on acceptance
Informational profile WL Sips No consequences, WL Sips proceeds with the authorisation request.
Merchant The merchant must analyse the results of the rules and decide how the transaction should continue using the cancellation or validation operations.
Decisive profile WL Sips If the result is negative , WL Sips denies the transaction and no authorisation request is made.
If the result is positive or neutral , WL Sips carries on the acceptance process by making an authorisation request.
Merchant No consequences on the transaction acceptance since the merchant appointed WL Sips to make decisions with regard to fraud.
However, the merchant can analyse the reason.
Mixed profile WL Sips Ditto decisive profile.
Merchant If the transaction is declined , there are no consequences for the merchant.
If the transaction is accepted , the merchant must analyse the results of the informational rules and decide what to do next.

Pre-authentification mode

In pre-authentication mode, rules are executed prior to the 3-D Secure authentication. If the checking result is positive, the 3-D Secure authentication is bypassed and WL Sips carries on with the authorisation request.

This mode applies only to card transactions with 3-D Secure authentication.

Depending on your needs, you define your pre-authentication profile(s) by combining the GO and/or NOGO rules.

A profile is decisive when all of its rules are decisive.

Only decisive rules can be configured in a Go-No-Go profile for the pre-authentication step. Informative rules in such a profile are useless at this step.

Profile type WL Sips  / merchant Consequences on acceptance
Decisive profile WL Sips If the result is positive , WL Sips bypasses the 3-D Secure authentication and carries on with pre-authorisation checking.
If the result is negative ou neutral , WL Sips carries on with 3-D Secure authentication prior to doing the pre-authorisation checking.
Merchant The merchant must analyse the results of the rules and decide how the transaction should continue using the cancellation or validation operations.
IMPORTANT: clarification on rules available in pre-authentication

Since the 3-D Secure authentication bypass takes place only in case of a positive result, it is important to configure at least one GO rule as decisive so as to bypass the 3-D Secure authentication for some customers.

Antifraud profile definition

What is an antifraud profile?

An antifraud profile is a set of rules that you configure after choosing them from the rules made available by the distributor of the ePayment solution. Rules are executed prior to the 3-D Secure authentication and to the authorisation request according to your configuration (to understand the pre-authentication and pre-authorisation modes, please refer to the execution modes and their consequences on acceptance).

There are three types of antifraud profiles:

  • the distributor's "offering" profile
  • profile templates
  • merchant profiles

A distributor's "offering" profile is defined by the distributor and administered by Worldline . It defines the scope of the available rules and of the configurations that may be mandatory. If an webshop has no suitable profile for the means of payment used, then the distributor’s offering profile is used.

Profile templates are defined and administered by the distributor. They are used as templates for creating merchant profiles.

Merchant profiles are defined by you for your webshop and are administered by you and/or the distributor (depending on the distributor's choice). They can be created from profile templates. The terms "webshop profile" may be used in this document. They are equivalent to the merchant profile.

IMPORTANT: profile templates and merchant profiles are separated in pre-authentication and pre-authorisation. For example, a profile template in pre-authorisation cannot be used to create merchant profiles in pre-authentication. A merchant profile in pre-authentication cannot apply to the pre-authorisation step during payment.

Throughout this document, the notion of "profile" will refer to merchant profiles.

Antifraud profiles are set up through the fraud GUI of your extranet.

Profiles per means of payment and default profile

In most cases, you define a single antifraud profile that is applied to all transactions regardless of the means of payment used. However, you can also define additional profiles the settings of which suit one or more specific means of payment.

When a transaction must be evaluated, the risk management system first searches the webshop configuration for an antifraud profile specific to the means of payment used.

If no such profile is found, the system looks for the webshop default profile. This profile makes it possible to analyse the transactions that were not processed by the profiles specific to the means of payment.

To create a default profile, simply create a profile without associating any means of payment with it.

Attention: if no active profiles are available on the webshop, the distributor's offering profile will be used.

Only one profile can be active for a given means of payment. Likewise, only one default profile can be active.

For example, there can be:

  • a dedicated profile for CB, VISA and MASTERCARD
  • a dedicated profile for AMEX
  • a default profile that will check the transactions for which other means of payment are used.

Which means three active profiles at the same time.

You can create as many inactive profiles as required. This allows, for example, to keep profiles in reserve for particular periods of the year (sales, holidays, etc.).

Execution of an antifraud profile

The rules are executed sequentially according to the order defined in the profile settings.

The first decisive rule that produces a positive result for GO rules or a negative result for NOGO rules prevents the execution of the rest of the decisive rules.

Informational rules are systematically executed.

Please refer to the 'Expression of rule results' section for the restitution of rule results in informational or decisive mode. The diagram below shows how rules are trigerred.

Figure 2. procedure for trigerring an antifraud profile

Bypassing rules dynamically

You can bypass some rules of the profile dynamically in the transaction request. Please refer to the Appendix No. 1, 'Bypassing some files of the profile dynamically' for the list of bypassing instructions.

IMPORTANT: you cannot bypass the rules imposed by the distributor.
Note: dynamic bypass applies to the active rules inside pre-authentication and pre-authorisation profiles (please refer to the 'execution modes (pre-authentication & pre-authorisation) and consequences on acceptance' section to understand the pre-authentication and pre-authorisation modes).

Overriding rules dynamically

You can override some rules of the profiles dynamically in the transaction request.

The methods for overriding rules dynamically are described in the 'Descriptions and implementation of rules' section.

IMPORTANT: you cannot override the rules imposed by the distributor.
Note: dynamic overriding applies to the active rules inside pre-authentication and pre-authorisation profiles (please refer to the 'execution modes (pre-authentication & pre-authorisation) and consequences on acceptance' section to understand the pre-authentication and pre-authorisation modes).

Expression of rule results

Pre-authorisation mode

The executing result of the pre-authorisation profile is returned in the complementaryCode, complementaryInfo , preAuthorisationProfile, preAuthorisationProfileValue and preAuthorisationRuleResultList fields:

  • complementaryCode contains the specific code of the decisive or informative rule which returned a negative result (for NOGO type rules) or a positive result (for GO type rules). If no decisive or informative rule returned a negatie or positive result, the field is set to 00.
  • complementaryInfo* contains 3 types of information:
    • the result of each rule (decisive or informative) executed in the merchant profile, in the following format:
      • <RULE_RESULT XX=Y XX=Y … XX=Y />, where:
        • XX is a rule code. For rule codes, please refer to the list of rules
        • Y is the executing result:

          => N: negative result

          => P: positive result

          => O: neutral result

          => U: rule not executed because of incomplete transaction data (i.e. data not specified)

          => X: rule not applicable to this transaction type

          => B: rule not executed because you bypassed it

          => E: rule not executed due to a technical error

          => D: rule not executed due to a dynamic overriding error

    • the complementary information produced by the executed rules. For detailed information, please refer to the 'Description and implementation of rules' section. Please note that only certain rules feed the complementaryInfo field.
    • the information on the payment card in use, if any. For detailed information, please refer to the 'Card information' section.
  • preAuthorisationProfile contains the name of the antifraud profile executed prior to the authorisation request.
  • preAuthorisationProfileValue contains the unique identifier of the executed profile version. This information is useful to retrieve the profile in the same configuration as when the rules were executed.
  • preAuthorisationRuleResultList contains a list of detailed results for each rule executed prior to the authorisation request.

Each object contained in the preAuthorisationRuleResultList field corresponds to a rule result and contains the following values:

  • ruleCode, the rule code. For rule codes please refer to the 'List of rules' section.
  • ruleType, the rule type. For the rule type of each rule please refer to the 'List of rules' section. If the advanced configuration mode is activated for a rule, the value of the ruleType field is set to "MI".
  • ruleWeight:
    • D: if the rule is configured as decisive in the profile
    • I: if the rule is configured as informative in the profile
  • ruleSetting, indicates the rule configuration type:
    • D: dynamic in the transaction
    • S: static in the merchant configuration
    • I: static and imposed by the distributor offer
    • N: no configuration (when the rule does not require any configuration),
  • ruleResultIndicator, the executing result of the rule:
    • N: negative result
    • P: positive result
    • O: neutral result
    • U: rule not executed because of incomplete transaction data (i.e. data not specified)
    • X: rule not applicable to this transaction type
    • B: rule not executed because you bypassed it
    • E: rule not executed due to a technical error
    • D: rule not executed due to a dynamic overriding error
  • ruleDetailedInfo, complementary information produced by the executed rule. Please refer to the 'Description and implementation of rules' section for detailed information about each rule.

You are returned these fields in the following interfaces:

  • automatic and manual responses from Sips Paypage
  • responses from Sips Office connectors (Checkout, CashManagement (duplication) and Diagnostic services)
  • Extranet
  • Transactions report except the preAuthorisationRuleResultList field

Informative profile

Field Description
Neutral result
responseCode Value set depending on the authorisation response
acquirerResponseCode Value set depending on the authorisation response
complementaryCode Value set depending on the executed informative rules, otherwise 00**
complementaryInfo* Value set depending on the executed rules
preAuthorisationProfile Name of the executed antifraud profile
preAuthorisationProfileValue Unique identifier of the executed profile
preAuthorisationRuleResultList List of detailed results for each executed rule

Decisive or mixed profile

Field Description
Neutral result
responseCode Value set depending on the authorisation response
acquirerResponseCode Value set depending on the authorisation response
complementaryCode Value set depending on the executed informative rules, otherwise 00*
complementaryInfo* Value set depending on the executed rules
preAuthorisationProfile Name of the executed antifraud profile
preAuthorisationProfileValue Unique identifier of the executed profile
preAuthorisationRuleResultList List of detailed results for each executed rule
Positive result
responseCode Value set depending on the authorisation response
acquirerResponseCode Value set depending on the authorisation response
complementaryCode Value set depending on the GO rule that generated the acceptance
complementaryInfo* Value set depending on the executed rules
preAuthorisationProfile Name of the executed antifraud profile
preAuthorisationProfileValue Unique identifier of the executed profile
preAuthorisationRuleResultList List of detailed results for each executed rule
Negative result
responseCode Value set to 05
acquirerResponseCode Not specified
complementaryCode Value set depending on the NOGO rule that generated the refusal
complementaryInfo* Value set depending on the executed rules
preAuthorisationProfile Name of the executed antifraud profile
preAuthorisationProfileValue Unique identifier of the executed profile
preAuthorisationRuleResultList List of detailed results for each executed rule

* The complementaryInfo field is deprecated as of version 17R1. It will no longer evolve and will eventually stop being populated. The information it contains is available in an improved version, in the preAuthorisationRuleResultList field.

** See the list of rules

Pre-authentication mode

The executing result of the pre-authentication profile is returned in the preAuthenticationProfileValue, preAuthenticationProfile, preAuthenticationProfileValue and preAuthenticationRuleResultList fields:

  • preAuthenticationValue specific code of the rule which returned a negative result (for NOGO type rules) or a positive result (for GO type rules). If no decisive rule returned a negative or positive result, the field is empty.
  • preAuthenticationProfile contains the name of the antifraud profile executed prior to authentication.
  • preAuthenticationProfileValue contains the unique identifier of the executed profile version. This information is useful to retrieve the profile in the same configuration as when the checkings were executed.
  • preAuthenticationRuleResultList contains a list of detailed results for each rule executed prior to the authorisation request.

Each object contained in the preAuthenticationRuleResultList field corresponds to a rule result and contains the same values as those in the preAuthorisationRuleResultList field in pre-authorisation mode. Please refer to the 'Pre-authorisation mode' section to know the content of this field.

You are returned these fields in the following interfaces:

  • automatic and manual responses from Sips Paypage
  • responses from Sips Office connectors (CashManagement (duplication) and Diagnostic)
  • Extranet
  • Transactions report except the preAuthorisationRuleResultList field

Field Description
Neutral result
preAuthenticationValue Value set to empty*
preAuthenticationProfile Name of the executed antifraud profile
preAuthenticationProfileValue Unique identifier of the executed profile
preAuthenticationRuleResultList List of detailed results for each executed rule
Positive result (3DS bypassed)
preAuthenticationValue Value set depending on the GO rule that generated the acceptance*
preAuthenticationProfile Name of the executed antifraud profile
preAuthenticationProfileValue Unique identifier of the executed profile
preAuthenticationRuleResultList List of detailed results for each executed rule
Negative result
preAuthenticationValue Value set depending on the NOGO rule that generated the refusal*
preAuthenticationProfile Name of the executed antifraud profile
preAuthenticationProfileValue Unique identifier of the executed profile
preAuthenticationRuleResultList List of detailed results for each executed rule

____________________

* See the various codes in the list of rules

Limitations of use

Means of payment

The global WL Sips offering supports many international means of payment such as Visa/Mastercard, the Paypal digital wallet, iDeal transfers, Sepa Direct Debits, etc.

The rules do note necessarily apply to all means of payment (e.g. InfoScore rules only apply to ELV transactions).

For single message** means of payment, defining informational profiles is technically feasible, but the checking result will have no consequences on the transaction acceptance.

Please refer to the 'Correspondences between means of payment and antifraud rules' section to know whether an antifraud rule applies to a means of payment or not.

____________________

** Single message means of payment: authorisation and capture are performed in a single step, e.g. transfers with Ideal, Sofort, Paybutton or Paypal in immediate mode. Dual message means of payment: authorisation and capture are performed in two steps.

Operations

Antifraud profiles apply to transactions and cash management operations that result in a new transaction being created (duplication).

Thus, standard cash management operations that deal with existing transactions (validation, cancellation, refund, etc.) and credit holder transactions are not subject to antifraud checkings.

Payment in n instalments

For payments in n instalments, only the first instalment is subject to antifraud checkings.

Data transfer in the request

For some rules, data must be sent in the request. The latter will not be executed if the data is missing.

For example, for the customer ID velocity rule, the customer ID must be sent in the request. Otherwise the rule will not be executed.

Execution mode and rules

The rules do not necessarily apply to both modes (pre-authentication et pre-authorisation).

For example the 3-D Secure authentication rule is not available in pre-authentication. Indeed, this rule is based on the 3-D Secure authentication result, but the pre-authentication antifraud profile is applied first. So this rule is of no use prior to authentication.

List of rules

Table 1. Geolocation rules
Rule name Rule code Type Advanced config. Overriding Bypass Pre-authen. Pre-author. More info
Card country CR NOGO V V V V V
IP address country CY NOGO V V V V V
IP address and card country SI NOGO V V V V V
Delivery and billing country SB NOGO V V V
Delivery and billing postal codes ZC NOGO V V V
Delivery and card country CS NOGO V V V V V
Billing and card country CB NOGO V V V V V
IBAN country AC NOGO V V V V
Delivery and IBAN country DI NOGO V V V V
Phone number and IBAN country PI NOGO V V V V
IP address and IBAN country IS NOGO V V V V
Table 2. Velocity rules
Rule name Rule code Type Advanced config. Overriding Bypass Pre-authen. Pre-author. More info
Card velocity SC NOGO V V V
IP address velocity VI NOGO V V V
Customer ID velocity VC NOGO V V V
Number of customers per card MD NOGO V V V
Number of cards per customer MR NOGO V V V
Number of cards per IP address CI NOGO V V V
Number of IBANs per IP address II NOGO V V
Number of IP addresses per IBAN IJ NOGO V V
Number of customers per IBAN CJ NOGO V V
Number of IBANs per customer IC NOGO V V
Number of mandates per IP address MJ NOGO V V
Mandate velocity EM NOGO V V
IBAN velocity EI NOGO V V
Table 3. Miscellaneous rules
Rule name Rule code Type Advanced config. Overriding Bypass Pre-authen. Pre-author. More info
IP address reputation IR NOGO V V V
Lost or stolen card OP NOGO V V V
Virtual card EC NOGO V V V
Systematic authorisation card SA NOGO V V V
Commercial card (and card country) CC NOGO V V V V
Cap collar amount CA NOGO V V V V
CB scheme card NC NOGO V V V
Free e-mail address FE NOGO V V V
3-D Secure authentication A3 NOGO V V V
E-mail address syntax ES NOGO V V V
Address checking (InfoScore) AV NOGO V V
Account checking (InfoScore) BV NOGO V V
Card expiry date PE NOGO V V V
Table 4. List rules
Rule name Rule code Type Advanced config. Overriding Bypass Pre-authen. Pre-author. More info
IP addresses Blacklist BY NOGO V V V
Greylist GY NOGO V V V
Whitelist WY GO V V V
Postal codes per country Blacklist BZ NOGO V V V
Greylist GZ NOGO V V V
Whitelist WZ GO V V V
E-mail addresses Blacklist BM NOGO V V V
Greylist GM NOGO V V V
Whitelist WM GO V V V
Customer IDs Blacklist BI NOGO V V V
Greylist GI NOGO V V V
Whitelist WI GO V V V
Customer names Blacklist BN NOGO V V V
Greylist GN NOGO V V V
Whitelist WN GO V V V
Card numbers Blacklist BC NOGO V V V
Greylist GC NOGO V V V
Whitelist WC GO V V V
Phone numbers Blacklist BP NOGO V V V
Greylist GP NOGO V V V
Whitelist WP GO V V V
BIN ranges Blacklist BB NOGO V V V
Greylist BR NOGO V V V
Whitelist WB GO V V V
BIC list Blacklist BE NOGO V V
Greylist GE NOGO V V
Whitelist WE GO V V
IBAN list Blacklist BA NOGO V V
Greylist GA NOGO V V
Whitelist WA GO V V
Mandate list Blacklist TB NOGO V V
Greylist TG NOGO V V
Whitelist TW GO V V
Table 5. Basket rules
Rule name Rule code Type Advanced config. Overriding Bypass Pre-authen. Pre-author. More info
Risky product list RP NOGO V V V
Risky product quantity PQ NOGO V V V
Risky product ratio PR NOGO V V V
Product quantity QP NOGO V V V

Card information

In the case of a card payment, some card information is returned in the complementaryInfo field. The return information includes:

  • card country
  • card scheme name
  • card issuer code and name
  • card product code and name
  • card product profile

information is returned in the following format: <CARD_INFOS BDOM=<card issuer name> COUNTRY=<card country> PRODUCTCODE=<card product code> NETWORK=<card scheme name> BANKCODE=<card issuer code> PRODUCTNAME=<card product name> PRODUCTPROFILE=<card product profile>/>$

For the list of country codes, please refer to Appendix 4: ISO 3166 alphabetical country codes.

For the list of card schemes, please refer to Appendix 8: list of card schemes.

For the list of product profiles, please refer to Appendix 9: list of product profiles.

Description and implementation of rules

Geolocation rules: address and country

Note: the lists mentioned in the geolocation rules below are limited to 400 items, i.e. 400 countries or 400 country pairs (depending on the rule concerned).

Card country

Rule description

The card country rule enables you to decide whether to accept or decline to provide a service depending on the country the holder's card was issued in.

The rule queries a BIN range database to check whether the country of origin of the card is on a list of authorised or prohibited countries.

If there is no list of authorised or prohibited countries, the rule considers your country code as the only one authorised.

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile. To do so, you must:
    • make a request to your account manager
    • or activate the rule through the fraud GUI
  • and set the list of authorised or prohibited card countries. To do so, you must:
    • give your account manager the list of authorised or prohibited countries
    • or set the list of authorised or prohibited countries through the fraud GUI
    • or dynamically override the list of authorised or prohibited countries in your request
Attention: in advanced configuration mode, you can set two lists, one of them having a positive (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list. A same country can be found only in either list.
IMPORTANT: information about American Express cards

Our fraud module is based on the CIS (Card Info Service) database, which includes information on BIN ranges. However, this reference source does not include the nationality of American Express cards. It is therefore impossible for us, via the fraud module, to block American Express cards via the "Country card" rule.

Expression of the result

Simple configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The card country is unknown. -- Neutral CARD_COUNTRY=XXX*
The card country is on the list of prohibited countries, or is not on the list of authorised countries, or is not the same as the merchant's country. 06 Negative
The card country is on the list of authorised countries, or is not on the list of prohibited countries, or differs from the merchant's country. -- Neutral

* XXX: ISO 3166 alphabetical country code (see Appendix 4: ISO 3166 alphabetical country codes)

Advanced configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The card country is unknown. -- Neutral CARD_COUNTRY=XXX*
The card country is on the list of "disadvantaged countries" or is not on the list of "non-disadvantaged countries". 06 Negative
The card country is on the list of "non-disadvantaged countries" or is not on the list of "disadvantaged countries" or is not on the list of "advantaged countries" or is on the list of "non-advantaged countries". -- Neutral
The card country is on the list of "advantaged countries" or is not on the list of "non-disadvantaged countries". 06 Positive

This rule populates the complementaryInfo field with pattern CARD_COUNTRY=XXX*.

____________________

* XXX: ISO 3166 alphabetical country code (see Appendix 4: ISO 3166 alphabetical country codes)

Dynamic override

You can dynamically supply a list of authorised or prohibited countries in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.

There are 2 methods to override the rule parameters dynamically.

METHOD 1:

Choose the parameter to be overriden in the field...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...and send the country list in the following field:

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

The parameters that apply to this rule are:

  • default mode (simple configuration):
    • AllowedCardCountryList for the list of authorised countries
    • DeniedCardCountryList for the list of prohibited countries
  • advanced configuration mode:
    • NDeniedCardCountryList for the list of disadvantaged countries
    • NDeniedExceptCardCountryList for the list of non-disadvantaged countries
    • PAllowedCardCountryList for the list of advantaged countries
    • PAllowedExceptCardCountryList for the list non-advantaged countries

  • POST example:
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpCountryList,riskManagementDynamicValue=FRA,BEL,GBR}
    

  • SOAP example:
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedCardCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedCardCountryList”,
                    “riskManagementDynamicValue”:“FRA,BEL,GBR”
          }
     ]
}
    

METHOD 2 (deprecated):

The card country list is sent in one of the following connector fields:

  • fraudData.allowedCardCountryList for the list of authorised countries
  • fraudData.deniedCardCountryList for the list of prohibited countries

  • POST example:
      fraudData.allowedCardCountryList=FRA,BEL,GBR
    

  • SOAP example:
      <urn:fraudData>
     <urn:allowedCardCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "allowedCardCountryList": ["FRA", "BEL", "GBR"]
}
    

For both methods, the list sent must contain:

  • either the ISO 3166 alphabetic country codes (see Appendix 4 : ISO 3166 alphabetical country codes) separated by commas
  • or a list of preset country codes (see Appendix 7: list of preset country codes).

In default mode, sending 2 lists (authorised and prohibited) in the same request is considered as an error, in which case the rule will not be executed.

In advanced configuration mode, sending 2 negative lists (disadvantaged and non-disadvantaged) or 2 positive lists (advantaged and non-advantaged) in the same request is considered as an error, in which case the rule will not be executed.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the ForeignBinCard instruction.

  • POST example:
      fraudData.bypassCtrlList=ForeignBinCard
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>ForeignBinCard</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["ForeignBinCard"]
}
    

IP address country

Rule description

This rule enables you to decide whether to accept or decline to provide a service depending on the country associated with the customer's IP address.

The rule checks whether the IP address country is on a list of authorised or prohibited countries. This IP address comes from:

  • the automatic detection performed by the customer's browser in Sips Paypage . In this case, doubts may remain about the customer's country, mostly due to the dynamic allocation of IP addresses by some ISPs, or because of dynamic addresses.
  • or from the data transfer you do in the request in Sips Office .

If there is no list of authorised or prohibited countries, the rule considers the merchant's country code as the only one authorised.

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile. To do so, you must:
    • make a request to your account manager
    • or activate the rule through the fraud GUI
  • set the list of authorised or prohibited IP address countries. To do so, you must:
    • give your account manager the list of authorised or prohibited countries
    • or set the list of authorised or prohibited countries through the fraud GUI
    • or dynamically override the list of authorised or prohibited countries in your request
Attention: in advanced configuration mode, you can set two lists, one of them having a positive (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list. A same country can be found only in either list.

Expression of the result

Simple configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
The IP address country is unknown. -- Neutral IP_COUNTRY=XXX
The IP address country is on the list of prohibited countries or is not on the list of authorised countries. 10 Negative IP_COUNTRY=XXX*
The IP address country is on the list of authorised countries or is not on the list of prohibited countries. -- Neutral

* XXX: ISO 3166 alphabetical country code (see Appendix 4: ISO 3166 alphabetical country codes)

Advanced configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
The IP address country is unknown. -- Neutral IP_COUNTRY=XXX
The IP address country is on the list of "disadvantaged countries" or is not on the list of "non-disadvantaged countries". 10 Negative IP_COUNTRY=XXX*
The IP address country is on the list of "non-disadvantaged countries" or is not on the list of "disadvantaged countries" or is not on the list of "advantaged countries" or is on the list of "non-disadvantaged countries". -- Neutral
The IP address country is on the list of "advantaged countries" or is not on the list of "non-disadvantaged countries". 10 Positive

This rule populates the complementaryInfo field with pattern <COUNTRY_IP IP_COUNTRY=XXX*/>.

____________________

* XXX : ISO 3166 alphabetical country code (see Appendix 4: ISO 3166 alphabetical country codes)

Dynamic override

You can dynamically supply a list of authorised or prohibited countries in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.

There are 2 methods to override the rule parameters dynamically.

METHOD 1:

Choose the parameter to be overriden...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...and send the country list in the following field:

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

The parameters that apply to this rule are:

  • default mode (simple configuration) :
    • AllowedIpCountryList for the list of authorised countries
    • DeniedIpCountryList for the list of prohibited countries
  • advanced configuration mode:
    • NDeniedIpCountryList for the list of disadvantaged countries
    • NDeniedExceptIpCountryList for the list of non-disadvantaged countries
    • PAllowedIpCountryList for the list of advantaged countries
    • PAllowedExceptIpCountryList for the list of non-advantaged countries

  • POST example:
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpCountryList,riskManagementDynamicValue=FRA,BEL,GBR}
    

  • SOAP example:
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedIpCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedIpCountryList”,
                    “riskManagementDynamicValue”:“FRA,BEL,GBR”
          }
     ]
}
    

METHOD 2 (deprecated) :

The IP address country list is sent in one of the following connector fields:

  • fraudData.allowedIpCountryList for the list of authorised countries
  • fraudData.deniedIpCountryList for the list of prohibited countries

  • POST example:
      fraudData.allowedIpCountryList=FRA,BEL,GBR
    

  • SOAP example:
      <urn:fraudData>
     <urn:allowedIpCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "allowedIpCountryList": ["FRA", "BEL", "GBR"]
}
    

For both methods, the list sent must contain:

  • either the ISO 3166 alphabetic country codes (see Appendix 4: ISO 3166 alphabetical country codes) separated by commas
  • or a list of preset country codes (see Appendix 7: list of preset country codes)

In default mode, sending 2 lists (authorised and prohibited) in the same request is considered as an error, in which case the rule will not be executed.

In advanced configuration mode, sending 2 negative lists (disadvantaged and non-disadvantaged) or 2 positive lists (advantaged and non-advantaged) in the same request is considered as an error, in which case the rule will not be executed.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the IpCountry instruction.

  • POST example:
      fraudData.bypassCtrlList=IpCountry
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>IpCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["IpCountry"]
}
    

IP and card country

Rule description

This rule enables you to decide whether to accept or decline to provide a service depending on the combination of the card country and the customer’s IP address country.

The rule queries the BIN range and IP address range databases to check whether the combination of both countries is on a list of authorised or prohibited country combinations.

This IP address comes from:

  • the automatic detection performed by the customer's browser in Sips Paypage . In this case, uncertainty may remain about the customer's country, due mainly to the dynamic allocation of IP addresses by some ISPs or to dynamic addresses.
  • or from the data transfer you do in the request in Sips Office .

If there is no authorised or prohibited combination, the rule checks whether the card country matches the IP address country.

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile. To do so, you must:
    • make a request to your account manager
    • or activate the rule through the fraud GUI
  • set the list of authorised or prohibited card country and IP adress country combinations. To do so, you must:
    • give your account manager the list of authorised or prohibited combinations
    • or set the authorised or prohibited combinations through the fraud GUI
    • or dynamically override the authorised or prohibited combinations in your request
  • and provide the customer's IP address in the request ( customerIpAddress field), if you use Sips Office .

Attention: in advanced configuration mode, you can set two lists, one of them having a positive (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list. A same pair of countries can be found only in either list.

Expression of the result

Simple configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The card country and/or the IP address country is/are unknown. -- Neutral CARD_COUNTRY=XXX* ; IP_COUNTRY=YYY*
The card country/IP address country combination is prohibited. 12 Negative
The card country/IP address country combination is authorised. -- Neutral

* XXX, YYY: ISO 3166 alphabetical country codes (see Appendix 4: ISO 3166 alphabetical country codes)

Advanced configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The card country and/or the IP address country is/are unknown. -- Neutral CARD_COUNTRY=XXX* ; IP_COUNTRY=YYY*
The card country/IP address country combination is on the list of "disadvantaged countries" or is not on the list of "non-disadvantaged countries". 12 Negative
The card country/IP address country combination is on the list of "non-disadvantaged countries" or is not on the list of "disadvantaged countries" or is not on the list of "advantaged countries" or is on the list of "non-advantaged countries". -- Neutral
The card country/IP address country combination is on the list of "advantaged countries" or is not on the list of "non-disadvantaged countries". 12 Positive

This rule populates the complementaryInfo field with pattern <COUNTRY_COMBINATION CARD_COUNTRY=XXX* IP_COUNTRY=YYY*/>.

____________________

* XXX, YYY: ISO 3166 alphabetical country codes (see Appendix 4: ISO 3166 alphabetical country codes)

Dynamic override

You can dynamically supply the list of IP address countries/card countries combinations in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.

Choose the parameter to be overriden...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...and set the country list in the following field:

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

The parameters that apply to this rule are:

  • default mode (simple configuration):
    • AllowedIpCardCountryCombiList for the authorised IP and card country combinations
    • DeniedIpCardCountryCombiList for the prohibited IP and card country combinations
  • advanced configuration mode:
    • NDeniedIpCardCountryCombiList for the list of disadvantaged countries
    • NDeniedExceptIpCardCountryCombiList for the list of non-disadvantaged countries
    • PAllowedIpCardCountryCombiList for the list of advantaged countries
    • PAllowedExceptIpCardCountryCombiList for the list of non-advantaged countries

  • POST example:
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpCardCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }
    

  • SOAP example:
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam> AllowedIpCardCountryCombiList </urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedIpCardCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)”
          }
     ]
}
    

The list sent must contain pairs separated by commas and consisting of:

  • either ISO 3166 alphabetic country codes (see Appendix 4: ISO 3166 alphabetical country codes)
  • or a list of preset country codes (see Appendix 7: list of preset country codes)

In default mode, sending 2 lists (authorised and prohibited) in the same request is considered as an error, in which case the rule will not be executed.

In advanced configuration mode, sending 2 negative lists (disadvantaged and non-disadvantaged) or 2 positive lists (advantaged and non-advantaged) in the same request is considered as an error, in which case the rule will not be executed.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilityIpCard instruction.

  • POST example:
      fraudData.bypassCtrlList=SimilityIpCard
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>SimilityIpCard</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["SimilityIpCard"]
}
    

Delivery and billing country

Rule description

This rule enables you to decide whether to accept or decline to provide a service by checking whether the delivery country matches the billing country.

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile. To do so, you must:
    • make a request to your account manager
    • or activate the rule through the fraud GUI
  • and provide the delivery and billing country in the request ( billingAddress.country and deliveryAddress.country fields).

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
The delivery country does not match the billing country 30 Negative SHIP_COUNTRY=XXX*; BILL_COUNTRY=YYY*
The delivery country matches the billing country -- Neutral
The countries are unknown -- Neutral

This rule populates the complementaryInfo field with pattern <COUNTRY_COMBINATION SHIP_COUNTRY=XXX* BILL_COUNTRY=YYY*/>.

____________________

* XXX, YYY: ISO 3166 alphabetical country codes (see Appendix 4: ISO 3166 alphabetical country codes)

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityDeliveryBillingCountry instruction.

  • POST example:
      fraudData.bypassCtrlList=SimilarityDeliveryBillingCountry
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryBillingCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryBillingCountry"]
}
    

Delivery and billing postal codes

Rule description

This rule enables you to decide whether to accept or decline to provide a service by checking whether the delivery postal code matches the billing postal code.

This rule can only be activated if the rule that compares the delivery and billing countries also is. Indeed, comparing the postal codes is irrelevant if the countries are not the same.

Conditions of use

If you would like to use this rule you must:

  • have the "Delivery and billing country" rule activated
  • activate the rule in the profile. To do so, you must:
    • make a request to your account manager
    • or activate the rule through the fraud GUI
  • and provide the delivery and billing postal codes in the request ( billingAddress.zipCode and deliveryAddress.zipCode fields).

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
The delivery postal code does not match the billing postal code. 26 Negative SHIP_COUNTRY=XXX*; BILL_COUNTRY=YYY*; SHIP_ZIP=A*; BILL_ZIP=B*
The delivery postal code matches the billing postal code. -- Neutral
The postal codes are unknown. -- Neutral

This rule populates the complementaryInfo field with pattern <COUNTRY_ZIP_COMBINATION SHIP_COUNTRY=XXX* BILL_COUNTRY=XXX* SHIP_ZIP=A* BILL_ZIP=B*/>.

____________________

* XXX, YYY: ISO 3166 alphabetical country codes (see Appendix 4: ISO 3166 alphabetical country codes)

A, B: postal codes

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityDeliveryBillingPostalCode instruction.

  • POST example:
      fraudData.bypassCtrlList=SimilarityDeliveryBillingPostalCode
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryBillingPostalCode</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryBillingPostalCode"]
}
    

Delivery and card country

Rule description

This rule enables you to decide whether to accept or decline to provide a service depending on the card country/delivery country combination.

First, the rule queries the BIN range database to determine the card country. Then, the rule checks whether the combination formed by the newly determined card country and the delivery country is on the list of authorised or prohibited combinations.

If no list of authorised or prohibited combinations has been defined, the rule checks whether the card country matches the delivery country.

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile. To do so, you must:
    • make a request to your account manager
    • or activate the rule through the fraud GUI
  • set the list of authorised or prohibited delivery and card country combinations. To do so, you must:
    • give your account manager the list of authorised or prohibited combinations
    • or set the authorised or prohibited combinations through the fraud GUI
    • or dynamically override the authorised or prohibited combinations in your request
  • and provide the delivery country in the request ( deliveryAddress.country field)

Attention: in advanced configuration mode, you can set two lists, one of them having a positive (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list. A same pair of countries can be found only in either list.

Expression of the result

Simple configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The delivery country/card country combination is prohibited. 42 Negative SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The delivery country/card country combination is authorised. -- Negative
The delivery country or card country is unknown. -- Neutral

* XXX, YYY: ISO 3166 alphabetical country codes (see Appendix 4: ISO 3166 alphabetical country codes)

Advanced configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The delivery country/card country combination is on the list of "disadvantaged countries" or is not on the list of "non-disadvantaged countries". 42 Negative SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The delivery country/card country combination is on the list of "non-disadvantaged countries" or is not on the list of "disadvantaged countries" or is not on the list of "advantaged countries" or is on the list of "non-advantaged countries". -- Neutral
The card country or delivery country is unknown. -- Neutral
The delivery country/card country combination is on the list of "advantaged countries" or is not on the list of non-advantaged countries". 42 Positive

This rule populates the complementaryInfo field with pattern <COUNTRY_COMBINATION SHIP_COUNTRY=XXX* CARD_COUNTRY=YYY*/>.

____________________

* XXX, YYY: ISO 3166 alphabetical country codes (see Appendix 4: ISO 3166 alphabetical country codes)

Dynamic override

You can dynamically supply a list of authorised or prohibited delivery and card country combinations in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.

Choose the parameter to be overriden...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...and send the country list in the following field:

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

The parameters that apply to this rule are:

  • default mode (simple configuration):
    • AllowedDeliveryCardCountryCombiList for the authorised delivery and card country combinations
    • DeniedDeliveryCardCountryCombiList for the prohibited delivery and card country combinations
  • advanced configuration mode:
    • NDeniedDeliveryCardCountryCombiList for the list of disadvantaged countries
    • NDeniedExceptDeliveryCardCountryCombiList for the list of non-disadvantaged countries
    • PAllowedDeliveryCardCountryCombiList for the list of advantaged countries
    • PAllowedExceptDeliveryCardCountryCombiList for the list of non-advantaged countries

  • POST example:
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedDeliveryCardCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}
    

  • SOAP example:
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedDeliveryCardCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,#ZEURO),(#ZEURO,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedDeliveryCardCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,#ZEURO),(#ZEURO,FRA)”
          }
     ]
}
    

For both methods, the list sent must contain pairs separated by commas and consisting of:

  • either ISO 3166 alphabetic country codes (see Appendix 4: ISO 3166 alphabetical country codes)
  • or a list of preset country codes (see Appendix 7: list of preset country codes)

In default mode, sending 2 lists (authorised and prohibited) in the same request is considered as an error, in which case the rule will not be executed.

In advanced configuration mode, sending 2 negative lists (disadvantaged and non-disadvantaged) or 2 positive lists (advantaged and non-advantaged) in the same request is considered as an error, in which case the rule will not be executed.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityDeliveryCardCountry instruction.

  • POST example:
      fraudData.bypassCtrlList=SimilarityDeliveryCardCountry
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryCardCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryCardCountry"]
}
    

Billing and card country

Rule description

This rule enables you to decide whether to accept or decline to provide a service depending on the card country/billing country combination.

First, this rule queries the BIN range database to determine the card country. Then, the rule checks whether the combination formed by the newly determined card country and the billing country is on the list of authorised or prohibited combinations.

If no list of authorised or prohibited combinations has been defined, the rule checks whether the card country matches the billing country.

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile. To do so, you must:
    • make a request to your account manager
    • or activate the rule through the fraud GUI
  • set the list of authorised or prohibited billing and card country combinations. To do so, you must:
    • give your account manager the list of authorised or prohibited combinations
    • or set the authorised or prohibited combinations through the fraud GUI
    • or dynamically override the authorised or prohibited combinations in your request
  • and provide the billing and card country in the request ( deliveryAddress.country field)

Attention: in advanced configuration mode, you can set two lists, one of them having a positive (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list. A same pair of countries can be found only in either list.

Expression of the result

Simple configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The billing country/card country combination is prohibited. 47 Negative BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The billing country/card country combination is authorised. -- Neutral
The billing country or card country is unknown. -- Neutral

* XXX, YYY: ISO 3166 alphabetical country codes (see Appendix 4: ISO 3166 alphabetical country codes)

Advanced configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The billing country/card country combination is on the list of "disadvantaged countries" or is not on the list of "non-disadvantaged countries". 47 Negative BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The billing country/card country combination is on the list of "non-disadvantaged countries" or is not on the list of "disadvantaged countries" or is not on the list of "advantaged countries" or is on the list of "non-advantaged countries". -- Neutral
The billing country or card country is unknown. -- Neutral
The billing country/card country combination is on the list of "advantaged countries" or is not on the list of non-advantaged countries". 47 Positive

This rule populates the complementaryInfo field with pattern <COUNTRY_COMBINATION BILL_COUNTRY=XXX* CARD_COUNTRY=YYY*/>.

____________________

* XXX, YYY: ISO 3166 alphabetical country codes (see Appendix 4: ISO 3166 alphabetical country codes)

Dynamic override

You can dynamically supply a list of authorised or prohibited billing and card country combinations in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.

Choose the parameter to be overriden...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...and send the country list in the following field:

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

The parameters that apply to this rule are:

  • default mode (simple configuration) :
    • AllowedBillingCardCountryCombiList for the authorised billing country and card country combinations
    • DeniedBillingCardCountryCombiList for the prohibited billing country and card country combinations
  • advanced configuration mode:
    • NDeniedBillingCardCountryCombiList for the list of disadvantaged countries
    • NDeniedExceptBillingCardCountryCombiList for the list of non-disadvantaged countries
    • PAllowedBillingCardCountryCombiList for the list of advantaged countries
    • PAllowedExceptBillingCardCountryCombiList for the list of non-advantaged countries

  • POST example:
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedBillingCardCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}
    

  • SOAP example:
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedBillingCardCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,#ZEURO),(#ZEURO,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedBillingCardCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,#ZEURO),(#ZEURO,FRA)”
          }
     ]
}
    

The list sent must contain pairs separated by commas and consisting of:

  • either ISO 3166 alphabetic country codes (see Appendix 4: ISO 3166 alphabetical country codes)
  • or a list of preset country codes (see Appendix 7: list of preset country codes)

In default mode, sending 2 lists (authorised and prohibited) in the same request is considered as an error, in which case the rule will not be executed.

In advanced configuration mode, sending 2 negative lists (disadvantaged and non-disadvantaged) or 2 positive lists (advantaged and non-advantaged) in the same request is considered as an error, in which case the rule will not be executed.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityBillingCardCountry instruction.

  • POST example:
      fraudData.bypassCtrlList=SimilarityBillingCardCountry
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityBillingCardCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["SimilarityBillingCardCountry"]
}
    

IBAN country

Rule description

The IBAN country rule enables you to measure the risk of a purchase based on the issuing country of the customer's IBAN.

The rule is executed on all payment transactions made with a SDD means of payment, and will analyse the IBAN number to extract the country from it and check whether it is included in a list of authorised or prohibited countries.

If no list of authorised or prohibited countries has been defined, the rule considers your country as the only one authorised.

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile. To do so, you must:
    • make a request to your account manager
    • or activate the rule through the fraud GUI
  • set the list of authorised or prohibited IBAN countries. To do so, you must:
    • give your account manager the list of authorised or prohibited countries
    • or set the authorised or prohibited countries through the fraud GUI
    • or dynamically override the authorised or prohibited countries in your request
Attention: in advanced configuration mode, you can set two lists, one of them having a positive (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list. A same country can be found only in either list.

Expression of the result

Simple configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). -- Neutral NOT_APPLICABLE
The IBAN country is on the list of prohibited countries or is not on the list of authorised countries or differs from your country. 55 Negative IBAN_COUNTRY=XXX*
The IBAN country is on the list of authorised countries or is not on the list of prohibited countries or matches your country. -- Neutral

Advanced configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). -- Neutral NOT_APPLICABLE
The IBAN country is on the list of "disadvantaged countries" or is not on the list of "non-disadvantaged countries". 55 Negative IBAN_COUNTRY=XXX*
The IBAN country is on the list of "non-disadvantaged countries" or is not on the list of "disadvantaged countries" or is not on the list of "advantaged countries" or is on the list of "non-advantaged countries". -- Neutral
The IBAN country is on the list of "advantaged countries" or is not on the list of "non-advantaged countries". 55 Positive

This rule does not populate the complementaryInfo field.

____________________

* XXX: ISO 3166 alphabetical country code (see Appendix 4: ISO 3166 alphabetical country codes)

Dynamic override

You can dynamically supply a list of authorised countries or a list of prohibited countries in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.

Choose the parameter to be overriden...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...and send the country list in the following field:

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

The parameters that apply to this rule are:

  • default mode (simple configuration):
    • AllowedIbanCountryList for the list of authorised countries
    • DeniedIbanCountryList for the list of prohibited countries
  • advanced configuration modfe:
    • NDeniedIbanCountryList for the list of disadvantaged countries
    • NDeniedExceptIbanCountryList for the list of non-disadvantaged countries
    • PAllowedIbanCountryList for the list of advantaged countries
    • PAllowedExceptIbanCountryList for the list of non-advantaged countries

  • POST example:
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIbanCountryList,riskManagementDynamicValue=FRA,BEL,GBR}
    

  • SOAP example:
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedIbanCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedIbanCountryList”,
                    “riskManagementDynamicValue”:“FRA,BEL,GBR”
          }
     ]
}
    

The list sent must contain pairs separated by commas and consisting of:

  • either ISO 3166 alphabetic country codes (see Appendix 4: ISO 3166 alphabetical country codes)
  • or a list of preset country codes (see Appendix 7: list of preset country codes)

In default mode, sending 2 lists (authorised and prohibited) in the same request is considered as an error, in which case the rule will not be executed.

In advanced configuration mode, sending 2 negative lists (disadvantaged and non-disadvantaged) or 2 positive lists (advantaged and non-advantaged) in the same request is considered as an error, in which case the rule will not be executed.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the IbanCountry instruction.

  • POST example:
      fraudData.bypassCtrlList=IbanCountry
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>IbanCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["IbanCountry"]
}
    

Delivery and IBAN country

Rule description

This rule enables you to measure the risk of a purchase, based on the delivery country/customer's IBAN country combination.

The rule is executed on all payment transactions made with a SDD means of payment, and checks the presence of the delivery country/IBAN country combination in the list of authorised or prohibited combinations.

If no list of authorised or prohibited countries has been defined, the rule checks whether the delivery country matches the IBAN country.

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile. To do so, you must:
    • make a request to your account manager
    • or activate the rule through the fraud GUI
  • set the combinations of authorised or prohibited delivery countries and IBAN countries. To do so, you must:
    • give your account manager the list of authorised or prohibited combinations
    • or set the authorised or prohibited combinations through the fraud GUI
    • or dynamically override the authorised or prohibited combinations in your request
  • and provide the delivery country in the request ( deliveryAddress.country field).

Attention: in advanced configuration mode, you can set two lists, one of them having a positive (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list. A same pair of countries can be found only in either list.

Expression of the result

Simple configuration mode:

Use case ComplementaryCode Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). -- Neutral NOT_APPLICABLE
The delivery country/IBAN country combination is prohibited. 56 Negative SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The delivery country or/and the IBAN country is/are unknown. -- Neutral
The delivery country/IBAN country combination is authorised. -- Neutral

Advanced configuration mode:

Use case ComplementaryCode Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). -- Neutral NOT_APPLICABLE
The delivery country/IBAN country combination is on the list of "disadvantaged countries" oor is not on the list of "non-disadvantaged countries". 56 Negative SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The delivery country or/and the IBAN country is/are unknown. -- Neutral
The delivery country/IBAN country combination is on the list of "non-disadvantaged countries" or is not on the list of "disadvantaged countries" oor is not on the list of "advantaged countries" or is on the list of "non-advantaged countries". -- Neutral
The delivery country/IBAN country combination is on the list of "advantaged countries" or is not on the list of "non-advantaged countries". 55 Positive

This rule does not populate the complementaryInfo field.

____________________

* XXX, YYY: ISO 3166 alphabetical country codes (see Appendix 4: ISO 3166 alphabetical country codes)

Dynamic override

You can dynamically supply a list of delivery and IBAN country combinations in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.

Choose the parameter to be overriden...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...and send the country list in the following field:

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

The parameters that apply to this rule are:

  • default mode (simple configuration):
    • AllowedDeliveryIbanCountryCombiList for the authorised delivery country and IBAN country combinations
    • DeniedDeliveryIbanCountryCombiList for the prohibited delivery country and IBAN country combinations
  • advanced configuration mode:
    • NDeniedDeliveryIbanCountryCombiList for the list of disadvantaged countries
    • NDeniedExceptDeliveryIbanCountryCombiList for the list of non-disadvantaged countries
    • PAllowedDeliveryIbanCountryCombiList for the list of advantaged countries
    • PAllowedExceptDeliveryIbanCountryCombiList for the list of non-advantaged countries

  • POST example:
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedDeliveryIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }
    

  • SOAP example:
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedDeliveryIbanCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedDeliveryIbanCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)”
          }
     ]
}
    

The list sent must contain pairs separated by commas and consisting of:

  • either ISO 3166 alphabetic country codes (see Appendix 4: ISO 3166 alphabetical country codes)
  • or a list of preset country codes (see Appendix 7: list of preset country codes)

In default mode, sending 2 lists (authorised and prohibited) in the same request is considered as an error, in which case the rule will not be executed.

In advanced configuration mode, sending 2 negative lists (disadvantaged and non-disadvantaged) or 2 positive lists (advantaged and non-advantaged) in the same request is considered as an error, in which case the rule will not be executed.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityDeliveryIbanCountry instruction.

  • POST example:
      fraudData.bypassCtrlList=SimilarityDeliveryIbanCountry
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryIbanCountry"]
}
    

Phone and IBAN country

Rule description

This rule enables you to measure the risk of a purchase, based on the customer's mobile phone number country/customer's IBAN country combination.

The rule is executed on all payment transactions made with a SDD means of payment, and checks the presence of the customer's mobile phone number country/IBAN country combination in the list of authorised or prohibited combinations.

The phone number is obtained by analysing its dialling code. If the dialling code is not specified, the country cannot be retrieved.

If no list of authorised or prohibited combinations has been defined, the rule checks whether the customer's mobile phone number country matches the IBAN country.

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile. To do so, you must:
    • make a request to your account manager
    • or activate the rule through the fraud GUI
  • set the combinations of authorised or prohibited phone number countries and IBAN countries. To do so, you must:
    • give your account manager the list of authorised or prohibited combinations
    • or set the authorised or prohibited combinations through the fraud GUI
    • or dynamically override the authorised or prohibited combinations in your request
  • and provide the customer's mobile phone number in the request (with dialling code; the mobile field in one or several contact information groups: billingContact, customerContact, deliveryContact, holderContact ).

Attention: in advanced configuration mode, you can set two lists, one of them having a positive (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list. A same pair of countries can be found only in either list.

Expression of the result

Simple configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). -- Neutral NOT_APPLICABLE
The customer's mobile phone number country/IBAN country combination is prohibited. 57 Negative PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The customer's mobile phone number country or/and the IBAN country is/are unknown. -- Neutral
The customer's mobile phone number country/IBAN country combination is authorised. -- Neutral

Advanced configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). -- Neutral NOT_APPLICABLE
The customer's mobile phone number country/IBAN country combination is on the list of "disadvantaged countries" or is not on the list of "non-disadvantaged countries". 57 Negative PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The customer's mobile phone number country or/and the IBAN country is/are unknown. -- Neutral
The customer's mobile phone number country/IBAN country combination is on the list of "non-disadvantaged countries" or is not on the list of "disadvantaged countries" or is not on the list of "advantaged countries" or is on the list of "non-advantaged countries". -- Neutral
The customer's mobile phone number country/IBAN country combination is on the list of "advantaged countries" or is not on the list of "non-advantaged countries". 57 Positive

This rule does not populate the complementaryInfo field.

____________________

* XXX, YYY: ISO 3166 alphabetical country codes (see Appendix 4: ISO 3166 alphabetical country codes)

Dynamic override

You can dynamically supply a list of customer's mobile phone number country/IBAN country combinations in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.

Choose the parameter to be overriden...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...and send the country list in the following field:

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

The parameters that apply to this rule are:

  • default mode (simple configuration):
    • AllowedPhoneIbanCountryCombiList for the authorised customer's mobile phone number country and IBAN country combinations
    • DeniedPhoneIbanCountryCombiList for the prohibited customer's mobile phone number country and IBAN country combinations
  • advanced configuration mode:
    • NDeniedPhoneIbanCountryCombiList for the list of disadvantaged countries
    • NDeniedExceptPhoneIbanCountryCombiList for the list of non-disadvantaged countries
    • PAllowedPhoneIbanCountryCombiList for the list of advantaged countries
    • PAllowedExceptPhoneIbanCountryCombiList for the list of non-advantaged countries

  • POST example:
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedPhoneIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }
    

  • SOAP example:
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>llowedPhoneIbanCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedPhoneIbanCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)”
          }
     ]
}
    

The list sent must contain pairs separated by commas and consisting of:

  • either ISO 3166 alphabetic country codes (see Appendix 4: ISO 3166 alphabetical country codes)
  • or a list of preset country codes (see Appendix 7: list of preset country codes)

In default mode, sending 2 lists (authorised and prohibited) in the same request is considered as an error, in which case the rule will not be executed.

In advanced configuration mode, sending 2 negative lists (disadvantaged and non-disadvantaged) or 2 positive lists (advantaged and non-advantaged) in the same request is considered as an error, in which case the rule will not be executed.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityPhoneIbanCountry instruction.

  • POST example:
      fraudData.bypassCtrlList=SimilarityPhoneIbanCountry
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityPhoneIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["SimilarityPhoneIbanCountry"]
}
    

IP address and IBAN country

Rule description

This rule enables you to measure the risk of a purchase, based on the customer's IP address country/customer's IBAN country combination.

The rule is executed on all payment transactions made with a SDD means of payment, and checks whether the IP address country/IBAN country combination is on a list of authorised or prohibited country combinations.

This IP address comes from:

  • the automatic detection via the customer's browser in Sips Paypage . In this case, uncertainty may remain regarding the customer's country, due mainly to the dynamic allocation of IP addresses by some ISPs or to dynamic IP addresses.
  • or from the data transfer you do in the request in Sips Office .

If there is no authorised or prohibited combination, the rule checks whether the customer's IP address country matches the IBAN country.

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile. To do so, you must:
    • make a request to your account manager
    • or activate the rule through the fraud GUI
  • set the combinations of authorised or prohibited IP address countries and IBAN countries. To do so, you must:
    • give your account manager the list of authorised or prohibited combinations
    • or set the authorised or prohibited combinations through the fraud GUI
    • or dynamically override the authorised or prohibited combinations in your request
  • and provide the customer's IP address in the request, if you are on Sips Office

Attention: in advanced configuration mode, you can set two lists, one of them having a positive (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list. A same pair of countries can be found only in either list.

Expression of the result

Simple configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). -- Neutral NOT_APPLICABLE
The IP address country/IBAN country combination is prohibited. 58 Negative IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The IP address country or/and the IBAN country is/are unknown. -- Neutral
The IP address country/IBAN country combination is authorised. -- Neutral

Advanced configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). -- Neutral NOT_APPLICABLE
The IP address country/IBAN country combination is on the list of "disadvantaged countries" or is not on the list of "non-disadvantaged countries". 58 Negative IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The IP address country or/and the IBAN country is/are unknown. -- Neutral
The IP address country/IBAN country combination is on the list of "non-disadvantaged countries" or is not on the list of "disadvantaged countries" or is not on the list of "advantaged countries" or is on the list of "non-advantaged countries". -- Neutral
The IP address country/IBAN country combination is on the list of "advantaged countries" or is not on the list of "non-advantaged countries". 58 Positive

This rule does not populate the complementaryInfo field.

____________________

* XXX, YYY: ISO 3166 alphabetical country codes (see Appendix 4: ISO 3166 alphabetical country codes)

Dynamic override

You can dynamically supply a list of IP address country/IBAN country combinations in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.

Choose the parameter to be overriden...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...and send the country list in the following field:

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

The parameters that apply to this rule are:

  • default mode (simple configuration):
    • AllowedIpIbanCountryCombiList for the authorised IP address country and IBAN country combinations
    • DeniedIpIbanCountryCombiList for the prohibited IP address country and IBAN country combinations
  • advanced configuration mode:
    • NDeniedIpIbanCountryCombiList for the list of disadvantaged countries
    • NDeniedExceptIpIbanCountryCombiList for the list of non-disadvantaged countries
    • PAllowedIpIbanCountryCombiList for the list of advantaged countries
    • PAllowedExceptIpIbanCountryCombiList for the list of non-advantaged countries

  • POST example:
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }
    

  • SOAP example:
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedIpIbanCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>>>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedIpIbanCountryCombiList”,
                    “riskManagementDynamicValue”:“(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)”
          }
     ]
}
    

The list sent must contain pairs separated by commas and consisting of:

  • either ISO 3166 alphabetic country codes (see Appendix 4: ISO 3166 alphabetical country codes)
  • or a list of preset country codes (see Appendix 7: list of preset country codes)

In default mode, sending 2 lists (authorised and prohibited) in the same request is considered as an error, in which case the rule will not be executed.

In advanced configuration mode, sending 2 negative lists (disadvantaged and non-disadvantaged) or 2 positive lists (advantaged and non-advantaged) in the same request is considered as an error, in which case the rule will not be executed.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityIpIbanCountry instruction.

  • POST example:
      fraudData.bypassCtrlList=SimilarityIpIbanCountry
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>SimilarityIpIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["SimilarityIpIbanCountry"]
}
    

Velocity rules

The velocity rules calculate the cumulation of the amount or quantity for an aspect of the transaction over one given period (sometimes two) and compare the result to a threshold that should not be exceeded. They allow you to supervise the activities of a customer, an IP address, a card, etc.

For example, velocity rules can trigger a NOGO when the cumulated amount spent by a particular card exceeds 1,500 € over the last 24h or when a customer has made more than 10 transactions over the last week.

There are two ways to calculate the velocity:

  • By default, the velocity is calculated for a particular webshop.
  • You can also calculate the velocity by adding up the activities of several webshops. In this case, this velocity is known as a "shared velocity'" and allows widening the perimeter of the supervision.
Tip: when setting up a profile, you can take into account the refused transactions (in addition to the accepted transactions) in the calculations.

To set up a shared velocity, you need to contact your account manager for the configuration. Two steps are to be followed:

  • first, create a shared velocity by choosing its type (card velocity, IP address velocity, etc.)
  • then associate the shared velocity to the concerned webshops

During the execution of an antifraud control, when the shared velocity rule is active in the applied merchant profile, activities will be caculated and added to the activities of other webshops sharing the same velocity.

5 shared velocities can be set up per type of velocity rule in a commercial group.

Card velocity

Rule description

This rule enables you to assess the risk of a purchase by checking the card activity (the cumulative number and/or amount of transactions).

The rule is executed on all payment transactions made with a card. The velocity calculation takes into account transactions that have been accepted beforehand over the given periods. It is also possible to add the refused transactions to this calculation.

The rule checks a card activity over two separate periods. You must specify the number and/or cumulative amount of transactions, as well as the respective periods, when setting up the profile.

Example

The following table describes the evolution of the payment card history in the event that you chose to limit purchases on your website to 2 times for the same card, for a total amount of €500 per month (30 days):

Transaction date Payment details Rule result Card velocity
(number of transactions)
Card velocity
(cumulative amount)
History situation
(last 30 days)
01/10/2018 Transaction TR1
Amount: €100
Card: CB1
OK 1 €100 TR1 01/10/2018 CB1 €100
07/10/2018 Transaction TR2
Amount: €400
Card: CB2
OK 1 €400 TR1 01/10/2018 CB1 €100 OK
TR2 07/10/2018 CB2 €400
10/10/2018 Transaction TR3
Amount: €400
Card: CB2
KO 2 €800
(> 500)
TR1 01/10/2018 CB1 €100 OK
TR2 07/10/2018 CB2 €400 OK
TR3 10/10/2018 CB2 €400
12/10/2018 Transaction TR4
Amount: €200
Card: CB1
OK 2 €300 TR1 01/10/2018 CB1 €100 OK
TR2 07/10/2018 CB2 €400 OK
TR3 10/10/2018 CB2 €400 KO
TR4 12/10/2018 CB1 €200
15/10/2018 Transaction TR5
Amount: €100
Card: CB1
KO 3
(> 2)
€400 TR1 01/10/2018 CB1 €100 OK
TR2 07/10/2018 CB2 €400
TR3 10/10/2018 CB2 €400 KO
TR4 12/10/2018 CB1 €200 OK
TR5 15/10/2018 CB1 €100
02/11/2018
(> 30 d)
Transaction TR6
Amount: €300
Card: CB1
OK 1 €300 TR6 02/11/2018 CB1 €300

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile. To do so, you must:
    • make a request to your account manager
    • or activate the rule through the fraud GUI
  • and set the number of transactions carried out and/or the cumulative amount, as well as the respective periods. To do so, you must:
    • specify these settings to your account manager
    • or set them through the Fraud GUI

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum cumulative amount 0.01 over the period, in your currency 9999999
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum number of transactions 1 transaction over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The number of transactions carried out and/or the sum of the cumulative amounts with this card over the period exceed(s) the authorised limit(s). 02 Negative TRANS=A:B;

CUMUL=C:D*

The number of transactions carried out and the sum of the cumulative amounts with this card over the period are lower than the authorised limits. -- Neutral

*A: number of transactions carried out with this card over the period.

B: maximum number of accepted transactions with this card over the period.

C: sum of cumulative amounts with this card over the period.

D: maximum sum of cumulative amounts accepted with a card over the period.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the VelocityCard instruction.

  • POST example:
      fraudData.bypassCtrlList=VelocityCard
    
  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>VelocityCard</urn:bypassCtrlList>
</urn:fraudData>
    
  • JSON example:
      fraudData": {
   "bypassCtrlList":["VelocityCard"]
}
    

Limitations of use

In the case of a payment in multiple instalments, only the first instalment is taken into account.

During the validation, cancellation and refund of the transaction, the amount that is not validated, cancelled or refunded is not substracted from the cumulative amount.

IP address velocity

Rule description

This rule enables you to assess the risk of a purchase by verifying the activity (number and/or cumulative amount of the transactions) of a customer from an IP address over a given period.

The rule is executed on all succeed transactions. The calculation of the velocity only takes in account the transactions previously accepted during the period.

The rule checks the activity of an IP address over given period. You must specify the number and/or cumulative amount of the transactions, and the duration of the period during the configuration of the profile. This IP address comes from:

  • the automatic detection performed by the customer's browser on the Sips Paypage  ;
  • or from your transfer of data in the request in Sips Office .

Example

The table below describes the evolution of the IP address history if you have chosen to restrict purchases on your website to 2 times for the same IP, for a total amount of €500 and per month (30 days):

Transaction date Payment details Rule result IP address velocity
(number of transactions)
IP address velocity
(cumulative amount)
History situation
(last 30 days)
01/10/2018 Transaction TR1
Amount: €100
IP: 105.24.68.102
OK 1 €100 TR1 01/10/2018 105.24.68.102 €100
07/10/2018 Transaction TR2
Amount: €400
IP: 254.24.78.175
OK 1 €400 TR1 01/10/2018 105.24.68.102 €100 OK
TR2 07/10/2018 254.24.78.175 €400
10/10/2018 Transaction TR3
Amount: €400
IP: 254.24.78.175
KO 2 €800
(> 500)
TR1 01/10/2018 105.24.68.102 €100 OK
TR2 07/10/2018 254.24.78.175 €400 OK
TR3 10/10/2018 254.24.78.175 €400
12/10/2018 Transaction TR4
Amount: €200
IP: 105.24.68.102
OK 2 €300 TR1 01/10/2018 105.24.68.102 €100 OK
TR2 07/10/2018 254.24.78.175 €400 OK
TR3 10/10/2018 254.24.78.175 €400 KO
TR4 12/10/2018 105.24.68.102 €200
15/10/2018 Transaction TR5
Amount: €100
IP: 105.24.68.102
KO 3
(> 2)
€400 TR1 01/10/2018 105.24.68.102 €100 OK
TR2 07/10/2018 254.24.78.175 €400 OK
TR3 10/10/2018 254.24.78.175 €400 KO
TR4 12/10/2018 105.24.68.102 €200 OK
TR5 15/10/2018 105.24.68.102 €100
02/11/2018
(> 30 d)
Transaction TR6
Amount: €300
IP: 105.24.68.102
OK 1 €300 TR6 02/11/2018 105.24.68.102 €300

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the number of transactions carried out and/or the cumulative amount and the cumulation time through the fraud tab in the MEX
  • and provide the customer's IP address in the request ( customerIpAddress field), if you use Sips Office

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum cumulative amount 0.01 over the period, in your currency 9999999
Maximum number of transactions 1 transaction over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
The number of transactions carried out and/or the sum of the cumulative amounts with this IP address over the period exceed(s) the authorised limit(s). 16 Negative NOT_APPLICABLE
The number of transactions carried out and the sum of the cumulative amounts with this IP address over the period are lower than the authorised limits. -- Neutral TRANS=A:B;
CUMUL=C:D*
The IP address is not specified (in Sips Office ) -- Neutral

*A: number of transactions carried out with this IP address over the period.

B: maximum number of accepted transactions with this IP address over the period.

C: sum of cumulative amounts with this IP address over the period.

D: maximum sum of cumulative amounts accepted with an IP address over the period.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the VelocityIp instruction.

  • POST example:
      fraudData.bypassCtrlList=VelocityIp
    
  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>VelocityIp</urn:bypassCtrlList>
</urn:fraudData>
    
  • JSON example:
      fraudData": {
   "bypassCtrlList":["VelocityIp"]
}
    

Limitations of use

The IP address history is not updated during refund, cancellation or validation operations, whether they are partial or complete.

Customer ID velocity

Rule description

This rule enables you to assess the risk of a purchase by verifying the activity (number and/or cumulative amount of the transactions) of a customer from their customer ID over a given period.

The rule is executed on all succeed transactions for which a customer ID is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.

The rule checks the activity of a customer ID over a given period. You must specify the number and/or cumulative amount of the transactions, and the duration of the period during the configuration of the profile.

Example

The table below describes the evolution of the customer ID history if you have chosen to restrict purchases on your website to a maximum of 2 times for the same customer, for a maximum amount of €500 and per month (30 days):

Transaction date Payment details Rule result Customer ID velocity
(number of transactions)
Customer velocity
(Cumulative amount)
History situation
(last 30 days)
01/10/2018 Transaction TR1
Amount: €100
CustomerID: cust1
OK 1 €100 TR1 01/10/2018 cust1 €100
07/10/2018 Transaction TR2
Amount: €400
CustomerID: cust2
OK 1 €400 TR1 01/10/2018 cust1 €100 OK
TR2 07/10/2018 cust2 €400
10/10/2018 Transaction TR3
Amount: €400
CustomerID: cust2
KO 2 €800
(> 500)
TR1 01/10/2018 cust1 €100 OK
TR2 07/10/2018 cust2 €400 OK
TR3 10/10/2018 cust2 €400
12/10/2018 Transaction TR4
Amount: €200
CustomerID: cust1
OK 2 €300 TR1 01/10/2018 cust1 €100 OK
TR2 07/10/2018 cust2 €400 OK
TR3 10/10/2018 cust2 €400 KO
TR4 12/10/2018 cust1 €200
15/10/2018 Transaction TR5
Amount: €100
CustomerID: cust1
KO 3
(> 2)
€400 TR1 01/10/2018 cust1 €100 OK
TR2 07/10/2018 cust2 €400 OK
TR3 10/10/2018 cust2 €400 KO
TR4 12/10/2018 cust1 €200 OK
TR5 15/10/2018 cust1 €100
02/11/2018
(> 30 d)
Transaction TR6
Amount: €300
CustomerID: cust1
OK 1 €300 TR6 02/11/2018 cust1 €300

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the number of transactions carried out and/or the cumulative amount and the cumulation time through the fraud tab in the MEX
  • and provide the customer's customer ID in the request ( customerId field)

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum cumulative amount 0.01 over the period, in your currency 9999999
Maximum number of transactions 1 transaction over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
The customer ID is not specified. -- Neutral NOT_APPLICABLE
The number of transactions carried out and/or the sum of the cumulative amounts with this customer ID over the period exceed(s) the authorised limit(s). 20 Negative TRANS=A:B;
CUMUL=C:D
The number of transactions carried out and the sum of the cumulative amounts with this customer ID over the period are lower than the authorised limits. -- Neutral

*A: number of transactions carried out with this customer ID over the period.

B: maximum number of accepted transactions with this customer ID over the period.

C: sum of cumulative amounts with this customer ID over the period.

D: maximum sum of cumulative amounts accepted with customer ID over the period.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the VelocityCustomerId instruction.

  • POST example:
      fraudData.bypassCtrlList=VelocityCustomerId
    
  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>VelocityCustomerId</urn:bypassCtrlList>
</urn:fraudData>
    
  • JSON example:
      fraudData": {
   "bypassCtrlList":["VelocityCustomerId"]
}
    

Limitations of use

In the case of a payment in multiple instalments, only the first instalment is taken into account.

During the validation, cancellation and refund of the transaction, the amount that is not validated, cancelled or refunded is not substracted from the cumulative amount.

Number of customers per card

Rule description

This rule enables you to make sure a given card is not used by too many different customers over a given period.

The rule is executed on all succeed card payment transactions for which a customer ID is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.

The rule checks the activity from the customer's card number and customer ID over a given period.

Example

The table below describes the evolution of the customer ID/Card history if you have chosen to restrict purchases on your website to 3 customers per month (30 days) with the same card:

Transaction date Payment details Rule result Customers/card History situation
(last 30 days)
01/10/2018 Transaction TR1
CustomerID: cust1
Card: CB1
OK 1 TR1 01/10/2018 cust1 CB1
07/10/2018 Transaction TR2
CustomerID: cust2
Card: CB2
OK 2 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust2 CB1
12/10/2018 Transaction TR3
CustomerID: cust3
Card: CB1
OK 3 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust2 CB1 OK
TR3 12/10/2018 cust3 CB1
20/10/2018 Transaction TR4
CustomerID: cust4
Card: CB1
KO 4
(> 3)
TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust2 CB1 OK
TR3 12/10/2018 cust3 CB1 OK
TR4 20/10/2018 cust4 CB1
25/10/2018 Transaction TR5
CustomerID: cust4
Card: CB2
OK 1 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust2 CB1 OK
TR3 12/10/2018 cust3 CB1 OK
TR4 20/10/2018 cust4 CB1 KO
TR5 25/10/2018 cust4 CB2
27/10/2018 Transaction TR6
CustomerID: cust1
Card: CB1
OK 3 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust2 CB1 OK
TR3 12/10/2018 cust3 CB1 OK
TR4 20/10/2018 cust4 CB1 KO
TR5 25/10/2018 cust4 CB2 OK
TR6 27/10/2018 cust1 CB1
02/03/2018
(> 30 d)
Transaction TR7
CustomerID: cust5
Card: CB1
OK 1 TR7 02/03/2018 cust5 CB1

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the maximum number of customers and the cumulation time through the fraud tab in the MEX
  • and provide the customer's customer ID in the request ( customerId field)

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum number of customers 1 customer over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card.). -- Neutral NOT_APPLICABLE
The number of different customers using the same card over the period is equal to or exceeds the authorised limit. 21 Negative MAX=A:B*
The number of different customers using the same card over the period is lower than the authorised limit. -- Neutral
The customer ID is not specified. -- Neutral

*A: number of customers who used the same card over the period.

B: maximum number of customers accepted for the same card.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxCustomerIdPerCard instruction.

  • POST example:
      fraudData.bypassCtrlList=MaxCustomerIdPerCard
    
  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>MaxCustomerIdPerCard</urn:bypassCtrlList>
</urn:fraudData>
    
  • JSON example:
      fraudData": {
   "bypassCtrlList":["MaxCustomerIdPerCard"]
}
    

Limitations of use

The CustomerID/Card history of a customer is not updated during refund, cancellation or validation operations, whether they are partial or complete.

Number of cards per customer

Rule description

This rule enables you to make sure that a given customer does not use too many different cards over a given period.

The rule is executed on all succeed card payment transactions for which a customer ID is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.

The rule checks the activity from the customer's card number and customer ID over a given period.

Example

The table below describes the evolution of the customer ID/Card history if you have chosen to restrict purchases on your website to 3 cards per month (30 days) for the same customer:

Transaction date Payment details Rule result Cards/customer History situation
(last 30 days)
01/10/2018 Transaction TR1
Customer ID: cust1
Card: CB1
OK 1 TR1 01/10/2018 cust1 CB1
07/10/2018 Transaction TR2
Customer ID: cust1
Card: CB2
OK 2 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust1 CB2
12/10/2018 Transaction TR3
Customer ID: cust1
Card: CB3
OK 3 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust1 CB2 OK
TR3 12/10/2018 cust1 CB3
20/10/2018 Transaction TR4
Customer ID: cust1
Card: CB4
KO 4
(> 3)
TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust1 CB2 OK
TR3 12/10/2018 cust1 CB3 OK
TR4 20/10/2018 cust1 CB4
25/10/2018 Transaction TR5
Customer ID: cust2
Card: CB4
OK 1 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust1 CB2 OK
TR3 12/10/2018 cust1 CB3 OK
TR4 20/10/2018 cust1 CB4 KO
TR5 25/10/2018 cust2 CB4
27/10/2018 Transaction TR6
Customer ID: cust1
Card: CB1
OK 3 TR1 01/10/2018 cust1 CB1 OK
TR2 07/10/2018 cust1 CB2 OK
TR3 12/10/2018 cust1 CB3 OK
TR4 20/10/2018 cust1 CB4 KO
TR5 25/10/2018 cust2 CB4 OK
TR6 27/10/2018 cust1 CB1
02/03/2018
(> 30 d)
Transaction TR7
Customer ID: cust1
Card: CB5
OK 1 TR7 02/03/2018 cust1 CB5

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the maximum number of cards and the cumulation time through the fraud tab in the MEX
  • and provide the customer's customer ID in the request ( customerId field)

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum number of cards 1 card over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card.). -- Neutral NOT_APPLICABLE
The number of different cards used by a given customer over the period is equal to or exceeds the authorised limit. 22 Negative MAX=A:B*
The number of different cards used by a given customer over the period is lower than the authorised limit. -- Neutral
The customer ID is not specified. -- Neutral

*A: number of cards used by the same customer over the period.

B: maximum number of cards accepted for the same customer.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxCardPerCustomerId instruction.

  • POST example:
      fraudData.bypassCtrlList=MaxCardPerCustomerId
    
  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>MaxCardPerCustomerId</urn:bypassCtrlList>
</urn:fraudData>
    
  • JSON example:
      fraudData": {
   "bypassCtrlList":["MaxCardPerCustomerId"]
}
    

Limitations of use

The CustomerID/Card history of a customer is not updated during refund, cancellation or validation operations, whether they are partial or complete.

Number of cards per IP address

Rule description

This rule enables you to make sure that the transactions coming from a given IP address do not use too many different cards over a given period.

The rule is executed on all succeed transactions for which an IP address is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.

The rule checks the activity from the customer's card number and IP address over a given period. This IP address comes from:

  • the automatic detection performed by the customer's browser in Sips Paypage  ;
  • or your transfer of data in the request in Sips Office .

Example

The table below describes the evolution of the IP address/Card history if you have chosen to restrict purchases on your website to 3 cards per month (30 days) for the same customer:

Transaction date Payment details Rule result Cards/IP History situation
(last 30 days)
01/10/2018 Transaction TR1
IP: 105.24.68.102
Card: CB1
OK 1 TR1 01/10/2018 105.24.68.102 CB1
07/10/2018 Transaction TR2
IP: 105.24.68.102
Card: CB2
OK 2 TR1 01/10/2018 105.24.68.102 CB1 OK
TR2 07/10/2018 105.24.68.102 CB2
12/10/2018 Transaction TR3
IP: 105.24.68.102
Card: CB3
OK 3 TR1 01/10/2018 105.24.68.102 CB1 OK
TR2 07/10/2018 105.24.68.102 CB2 OK
TR3 12/10/2018 105.24.68.102 CB3
20/10/2018 Transaction TR4
IP: 105.24.68.102
Card: CB4
KO 4
(> 3)
TR1 01/10/2018 105.24.68.102 CB1 OK
TR2 07/10/2018 105.24.68.102 CB2 OK
TR3 12/10/2018 105.24.68.102 CB3 OK
TR4 20/10/2018 105.24.68.102 CB4
25/10/2018 Transaction TR5
IP: 254.24.78.175
Card: CB4
OK 1 TR1 01/10/2018 105.24.68.102 CB1 OK
TR2 07/10/2018 105.24.68.102 CB2 OK
TR3 12/10/2018 105.24.68.102 CB3 OK
TR4 20/10/2018 105.24.68.102 CB4 KO
TR5 25/10/2018 254.24.78.175 CB4
27/10/2018 Transaction TR6
IP: 105.24.68.102
Card: CB1
OK 3 TR1 01/10/2018 105.24.68.102 CB1 OK
TR2 07/10/2018 105.24.68.102 CB2 OK
TR3 12/10/2018 105.24.68.102 CB3 OK
TR4 20/10/2018 105.24.68.102 CB4 KO
TR5 25/10/2018 254.24.78.175 CB4 OK
TR6 27/10/2018 105.24.68.102 CB1
02/03/2018
(> 30 d)
Transaction TR7
IP: 105.24.68.102
Card: CB5
OK 1 TR7 02/03/2018 105.24.68.102 CB5

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the maximum number of cards and the cumulation time through the fraud tab in the MEX
  • and provide the customer's IP address in the request ( customerIpAddress field), if you use Sips Office

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum number of cards 1 card over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card.). -- Neutral NOT_APPLICABLE
The number of different cards used from a given IP address over the period is equal to or exceeds the authorised limit. 45 Negative MAX=A:B*
The number of different cards used from a given IP address over the period is lower than the authorised limit. -- Neutral
The IP address is not specified (in Sips Office ) -- Neutral

*A: number of cards used by the same IP address over the period.

B: maximum number of cards accepted for the same IP address.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxCardPerIp instruction.

  • POST example:
      fraudData.bypassCtrlList=MaxCardPerIp
    
  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>MaxCardPerIp</urn:bypassCtrlList>
</urn:fraudData>
    
  • JSON example:
      fraudData": {
   "bypassCtrlList":["MaxCardPerIp"]
}
    

Limitations of use

The IP address/Card history is not updated during refund, cancellation or validation operations, whether they are partial or complete.

Number of IBANs per IP address

Rule description

This rule enables you to check that the transactions coming from a given IP address do not use too high a number of different IBANs over a period.

The rule is executed on all payment transactions made with a SDD payment method and in which the customer's IP address is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.

The rule checks the activity from the IBAN and the customer's IP address over a given period. This IP address comes from:

  • the automatic detection performed by the customer's browser in Sips Paypage  ;
  • or your transfer of data in the request in Sips Office .

Example

The following table outlines the change in IBAN/IP address history, in the event that you decided to limit purchases on your website to 3 IBANs per month (30 days) for one IP address:

Transaction date Payment details Rule result IBAN/IP History situation
(last 30 days)
01/10/2018 Transaction TR1
IP: 105.24.68.102
IBAN: IBAN1
OK 1 TR1 01/10/2018 105.24.68.102 IBAN1
07/10/2018 Transaction TR2
IP: 105.24.68.102
IBAN: IBAN2
OK 2 TR1 01/10/2018 105.24.68.102 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN2
12/10/2018 Transaction TR3
IP: 105.24.68.102
IBAN: IBAN3
OK 3 TR1 01/10/2018 105.24.68.102 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN2 OK
TR3 12/10/2018 105.24.68.102 IBAN3
20/10/2018 Transaction TR4
IP: 105.24.68.102
IBAN: IBAN4
KO 4
(> 3)
TR1 01/10/2018 105.24.68.102 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN2 OK
TR3 12/10/2018 105.24.68.102 IBAN3 OK
TR4 20/10/2018 105.24.68.102 IBAN4
25/10/2018 Transaction TR5
IP: 254.24.78.175
IBAN: IBAN4
OK 1 TR1 01/10/2018 105.24.68.102 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN2 OK
TR3 12/10/2018 105.24.68.102 IBAN3 OK
TR4 20/10/2018 105.24.68.102 IBAN4 KO
TR5 25/10/2018 254.24.78.175 IBAN4
27/10/2018 Transaction TR6
IP: 105.24.68.102
IBAN: IBAN1
OK 3 TR1 01/10/2018 105.24.68.102 CB1 OK
TR2 07/10/2018 105.24.68.102 CB2 OK
TR3 12/10/2018 105.24.68.102 CB3 OK
TR4 20/10/2018 105.24.68.102 CB4 KO
TR5 25/10/2018 254.24.78.175 CB4 OK
TR6 27/10/2018 105.24.68.102 CB1
02/03/2018
(> 30 d)
Transaction TR7
IP: 105.24.68.102
IBAN: IBAN5
OK 1 TR7 02/03/2018 105.24.68.102 IBAN5

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the maximum number of IBANs and the cumulation time through the fraud tab in the MEX
  • and provide the customer's IP address in the request ( customerIpAddress field), if you use

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum number of IBANs 1 IBAN over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD) -- Neutral NOT_APPLICABLE
The number of different IBANs coming from the same IP address over the period exceeds the accepted limit 59 Negative MAX=A:B*
The IP address is not provided (in Sips Office ) -- Neutral
The number of different IBANs coming from the same IP address over the period is under the accepted limit. -- Neutral

*A: the number of IBANs used by the same IP address over the period.

B: the maximum number of IBANs accepted for the same IP address.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxIbanPerIp instruction.

  • POST example:
      fraudData.bypassCtrlList=MaxIbanPerIp
    
  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>MaxIbanPerIp</urn:bypassCtrlList>
</urn:fraudData>
    
  • JSON example:
      fraudData": {
   "bypassCtrlList":["MaxIbanPerIp"]
}
    

Limitations of use

The IBAN/IP address history is not updated during partial or total refund, cancellation or validation operations.

Number of IP addresses per IBAN

Rule description

This rule enables you to check that an IBAN is not used by too high a number of different IP addresses over a period.

The rule is executed on all payment transactions made with a SDD payment method and in which the customer's IP address is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.

The rule checks the activity from the IBAN and the customer's IP address over a given period. This IP address comes from:

  • the automatic detection performed by the customer's browser in Sips Paypage  
  • or your transfer of data in the request in Sips Office

Example

The following table outlines the change in IP address/IBAN history, in the event that you decided to limit purchases on your website to 3 IP addresses per month (30 days) for one IBAN:

Transaction date Payment details Rule result IP/IBAN History situation
(last 30 days)
01/10/2018 Transaction TR1
IP: 105.24.68.101
IBAN: IBAN1
OK 1 TR1 01/10/2018 105.24.68.101 IBAN1
07/10/2018 Transaction TR2
IP: 105.24.68.102
IBAN: IBAN1
OK 2 TR1 01/10/2018 105.24.68.101 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN1
12/10/2018 Transaction TR3
IP: 105.24.68.103
IBAN: IBAN1
OK 3 TR1 01/10/2018 105.24.68.101 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN1 OK
TR3 12/10/2018 105.24.68.103 IBAN1
20/10/2018 Transaction TR4
IP: 105.24.68.104
IBAN: IBAN1
KO 4
(> 3)
TR1 01/10/2018 105.24.68.101 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN1 OK
TR3 12/10/2018 105.24.68.103 IBAN1 OK
TR4 20/10/2018 105.24.68.104 IBAN1
25/10/2018 Transaction TR5
IP: 105.24.68.104
IBAN: IBAN2
OK 1 TR1 01/10/2018 105.24.68.101 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN1 OK
TR3 12/10/2018 105.24.68.103 IBAN1 OK
TR4 20/10/2018 105.24.68.104 IBAN1 KO
TR5 25/10/2018 105.24.68.104 IBAN2
27/10/2018 Transaction TR6
IP: 105.24.68.101
IBAN: IBAN1
OK 3 TR1 01/10/2018 105.24.68.101 IBAN1 OK
TR2 07/10/2018 105.24.68.102 IBAN1 OK
TR3 12/10/2018 105.24.68.103 IBAN1 OK
TR4 20/10/2018 105.24.68.104 IBAN1 KO
TR5 25/10/2018 105.24.68.104 IBAN2
TR6 27/10/2018 105.24.68.101 IBAN1
02/03/2018
(> 30 d)
Transaction TR7
IP: 105.24.68.105
IBAN: IBAN1
OK 1 TR7 02/03/2018 105.24.68.105 IBAN1

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the maximum number of IP addresses and the cumulation time through the fraud tab in the MEX
  • and provide the customer's IP address in the request ( customerIpAddress field), if you use Sips Office

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum number of IP addresses 1 IP address over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). -- Neutral NOT_APPLICABLE
The number of different IP addresses with the same IBAN over the period exceeds the accepted limit. 60 Negative MAX=A:B*
The IP address is not provided (in Sips Office ). -- Neutral
The number of different IP addresses with the same IBAN over the period is lower than the accepted limit. -- Neutral

*A: number of IP addresses used by the same IBAN over the period.

B: maximum number of IP addresses accepted for a given IBAN.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxIpPerIban instruction.

  • POST example:
      fraudData.bypassCtrlList=MaxIpPerIban
    
  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>MaxIpPerIban</urn:bypassCtrlList>
</urn:fraudData>
    
  • JSON example:
      fraudData": {
   "bypassCtrlList":["MaxIpPerIban"]
}
    

Limitations of use

The IP address/IBAN history is not updated during partial or total refund, cancellation or validation operations.

Number of customers per IBAN

Rule description

This rule enables you to check that an IBAN is not used by too high a number of different customers over a period.

The rule is executed on all payment transactions made with a SDD means of payment and in which the customer's IP address and identifier (customerId) is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.

The rule checks the activity from the IBAN and the customer's IP address over a given period. This IP address comes from:

  • the automatic detection performed by the customer's browser in Sips Paypage  
  • or your transfer of data in the request in Sips Office

Example

The following table outlines the change in customer ID/IBAN history, in the event that you decided to limit purchases on your website to 3 customers per month (30 days) with the same IBAN:

Transaction date Payment details Rule result Customers/IBAN History situation
(last 30 days)
01/10/2018 Transaction TR1
Customer ID: cust1
IBAN: IBAN1
OK 1 TR1 01/10/2018 cust1 IBAN1
07/10/2018 Transaction TR2
Customer ID: cust2
IBAN: IBAN1
OK 2 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust2 IBAN1
12/10/2018 Transaction TR3
Customer ID: cust3
IBAN: IBAN1
OK 3 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust2 IBAN1 OK
TR3 12/10/2018 cust3 IBAN1
20/10/2018 Transaction TR4
Customer ID: cust4
IBAN: IBAN1
KO 4
(> 3)
TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust2 IBAN1 OK
TR3 12/10/2018 cust3 IBAN1 OK
TR4 20/10/2018 cust4 IBAN1
25/10/2018 Transaction TR5
Customer ID: cust4
IBAN: IBAN2
OK 1 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust2 IBAN1 OK
TR3 12/10/2018 cust3 IBAN1 OK
TR4 20/10/2018 cust4 IBAN1 KO
TR5 25/10/2018 cust4 IBAN2
27/10/2018 Transaction TR6
Customer ID: cust1
IBAN: IBAN1
OK 3 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust2 IBAN1 OK
TR3 12/10/2018 cust3 IBAN1 OK
TR4 20/10/2018 cust4 IBAN1 KO
TR5 25/10/2018 cust4 IBAN2 OK
TR6 27/10/2018 cust1 IBAN1
02/03/2018
(> 30 d)
Transaction TR7
Customer ID: cust5
IBAN: IBAN1
OK 1 TR7 02/03/2018 cust5 IBAN1

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the maximum number of customers and the cumulation time through the fraud tab in the MEX
  • and provide the customer's identifier in the request ( customerId field)

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum number of customers 1 customer over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD) -- Neutral NOT_APPLICABLE
The number of different customers using the same IBAN over the period exceeds the accepted limit 61 Negative MAX=A:B*
The customer identifier is not provided -- Neutral
The number of different customers using the same IBAN over the period is under the accepted limit -- Neutral

*A: number of customers using the same IBAN over the period.

B: maximum number of customers accepted for a same IBAN.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityDeliveryIbanCountry instruction.

  • POST example:
      fraudData.bypassCtrlList=MaxCustidPerIban
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>MaxCustidPerIban</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["MaxCustidPerIban"]
}
    

Limitations of use

The customer/IBAN history is not updated during partial or total refund, cancellation or validation operations.

Number of IBANs per customer

Rule description

This rule enables you to check that a customer does not use too high a number of different IBANs over a period.

The rule is executed on all payment transactions made with a SDD means of payment and in which the customer's identifier is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.

The rule checks the activity from the customer's identifier (customerId) and the IBAN over a given period.

Example

The following table outlines the change in customer ID/IBAN history, in the event that you decided to limit purchases on your website to 3 IBANs per month (30 days) for one customer:

Transaction date Payment details Rule result IBAN/client History situation
(last 30 days)
01/10/2018 Transaction TR1
Customer ID: cust1
IBAN: IBAN1
OK 1 TR1 01/10/2018 cust1 IBAN1
07/10/2018 Transaction TR2
Customer ID: cust1
IBAN: IBAN2
OK 2 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust1 IBAN2
12/10/2018 Transaction TR3
Customer ID: cust1
IBAN: IBAN3
OK 3 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust1 IBAN2 OK
TR3 12/10/2018 cust1 IBAN3
20/10/2018 Transaction TR4
Customer ID: cust1
IBAN: IBAN4
KO 4
(> 3)
TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust1 IBAN2 OK
TR3 12/10/2018 cust1 IBAN3 OK
TR4 20/10/2018 cust1 IBAN4
25/10/2018 Transaction TR5
Customer ID: cust2
IBAN: IBAN4
OK 1 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust1 IBAN2 OK
TR3 12/10/2018 cust1 IBAN3 OK
TR4 20/10/2018 cust1 IBAN4 KO
TR5 25/10/2018 cust2 IBAN4
27/10/2018 Transaction TR6
Customer ID: cust1
IBAN: IBAN1
OK 3 TR1 01/10/2018 cust1 IBAN1 OK
TR2 07/10/2018 cust1 IBAN2 OK
TR3 12/10/2018 cust1 IBAN3 OK
TR4 20/10/2018 cust1 IBAN4 KO
TR5 25/10/2018 cust2 IBAN4 OK
TR6 27/10/2018 cust1 IBAN1
02/03/2018
(> 30 d)
Transaction TR7
Customer ID: cust1
IBAN: IBAN5
OK 1 TR7 02/03/2018 cust1 IBAN5

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the maximum number of IBANs and the cumulation time through the fraud tab in the MEX
  • and provide the customer's identifier in the request ( customerId field)

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum number of IBANs 1 IBAN over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). -- Neutral NOT_APPLICABLE
The number of different IBANs used by the same customer over the period exceeds the accepted limit. 62 Negative MAX=A:B*
The customer's identifier is not provided. -- Neutral
The number of different IBANs used by the same customer over the period is under the accepted limit. -- Neutral

*A: number of IBANs used by a same customer over the period.

B: maximum number of IBANs accepted for the same customer.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxIbanPerCustid instruction.

  • POST example:
      fraudData.bypassCtrlList=MaxIbanPerCustid
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>MaxIbanPerCustid</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["MaxIbanPerCustid"]
}
    

Limitations of use

The customer/IBAN history is not updated during partial or total refund, cancellation or validation operations.

Number of mandates per IP address

Rule description

This rule enables you to check that an IP address does not use too high a number of different SDD mandates, indicated by their Unique Mandate Reference (UMR), over a period.

The rule is executed on all payment transactions made with a SDD means of payment and in which the IP address is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.

The rule checks the activity from the mandate and the customer's IP address over a given period. This IP address comes from:

  • the automatic detection performed by the customer's browser in Sips Paypage
  • or your transfer of data in the request in Sips Office

Example

The following table outlines the change in mandate/IP address history, in the event that you decided to limit purchases on your website to 3 mandates per month (30 days) for one IP address:

Transaction date Payment details Rule result Mandates/IP History situation
(last 30 days)
01/10/2018 Transaction TR1
IP: 105.24.68.102
Mandate: RUM1
OK 1 TR1 01/10/2018 105.24.68.102 RUM1
07/10/2018 Transaction TR2
IP: 105.24.68.102
Mandate: RUM2
OK 2 TR1 01/10/2018 105.24.68.102 RUM1 OK
TR2 07/10/2018 105.24.68.102 RUM2
12/10/2018 Transaction TR3
IP: 105.24.68.102
Mandate: RUM3
OK 3 TR1 01/10/2018 105.24.68.102 RUM1 OK
TR2 07/10/2018 105.24.68.102 RUM2 OK
TR3 12/10/2018 105.24.68.102 RUM3
20/10/2018 Transaction TR4
IP: 105.24.68.102
Mandate: RUM4
KO 4
(> 3)
TR1 01/10/2018 105.24.68.102 RUM1 OK
TR2 07/10/2018 105.24.68.102 RUM2 OK
TR3 12/10/2018 105.24.68.102 RUM3 OK
TR4 20/10/2018 105.24.68.102 RUM4
25/10/2018 Transaction TR5
IP: 254.24.78.175
Mandate: RUM4
OK 1 TR1 01/10/2018 105.24.68.102 RUM1 OK
TR2 07/10/2018 105.24.68.102 RUM2 OK
TR3 12/10/2018 105.24.68.102 RUM3 OK
TR4 20/10/2018 105.24.68.102 RUM4 KO
TR5 25/10/2018 254.24.78.175 RUM4
27/10/2018 Transaction TR6
IP: 105.24.68.102
Mandate: RUM1
OK 3 TR1 01/10/2018 105.24.68.102 RUM1 OK
TR2 07/10/2018 105.24.68.102 RUM2 OK
TR3 12/10/2018 105.24.68.102 RUM3 OK
TR4 20/10/2018 105.24.68.102 RUM4 KO
TR5 25/10/2018 254.24.78.175 RUM4 OK
TR6 27/10/2018 105.24.68.102 RUM1
02/03/2018
(> 30 d)
Transaction TR7
IP: 105.24.68.102
Mandate: RUM5
OK 1 TR7 02/03/2018 105.24.68.102 RUM5

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the maximum number of mandates and the cumulation time through the fraud tab in the MEX
  • and provide the customer's IP address in the request ( customerIpAddress field), if you use Sips Office

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum number of mandates 1 mandate over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). -- Neutral NOT_APPLICABLE
The number of different mandates coming from the same IP address over the period exceeds the accepted limit. 63 Negative MAX=A:B*
The IP address is not provided -- Neutral
The number of different mandates coming from the same IP address over the period is under the accepted limit. -- Neutral

*A: number of mandates for a same IP address over the period.

B: maximum number of mandates accepted for a same IP address.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxMandatePerIp instruction.

  • POST example:
      fraudData.bypassCtrlList=MaxMandatePerIp
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>MaxMandatePerIp</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["MaxMandatePerIp"]
}
    

Limitations of use

The customer/IBAN history is not updated during partial or total refund, cancellation or validation operations.

Mandate velocity

Rule description

This rule enables you to assess the risk of a purchase by checking the activity (the number and/or accumulated amount of transactions) of the SDD mandate, indicated by its Unique Mandate Reference (UMR), over a period.

The rule is executed on all payment transactions made with a SDD means of payment. The calculation of the velocity only takes in account the transactions previously accepted during the period.

The rule checks the activity of a mandate over a given period. The number of transactions and/or accumulated amount of transactions and the duration of the period must be provided by you in your profile settings.

Example

The following table outlines the change in the mandate history, in the event that you decided to limit purchases on your website to 2 times for one mandate, for a total amount of €500 per month (30 days):

Transaction details Payment details Rule result Mandate velocity
(number of transactions)
Mandate velocity
(cumulative amount)
History situation
(last 30 days)
01/10/2018 Transaction TR1
Amount: €100
Mandate: RUM1
OK 1 €100 TR1 01/10/2018 RUM1 €100
07/10/2018 Transaction TR2
Amount: €400
Mandate: RUM2
OK 1 €400 TR1 01/10/2018 RUM1 €100 OK
TR2 07/10/2018 RUM2 €400
10/10/2018 Transaction TR3
Amount: €400
Mandate: RUM2
KO 2 €800
(> 500)
TR1 01/10/2018 RUM1 €100 OK
TR2 07/10/2018 RUM2 €400 OK
TR3 10/10/2018 RUM2 €400
12/10/2018 Transaction TR4
Amount: €200
Mandate: RUM1
OK 2 €300 TR1 01/10/2018 RUM1 €100 OK
TR2 07/10/2018 RUM2 €400 OK
TR3 10/10/2018 RUM2 €400 KO
TR4 12/10/2018 RUM1 €200
15/10/2018 Transaction TR5
Amount: €100
Mandate: RUM1
KO 3
(> 2)
€400 TR1 01/10/2018 RUM1 €100 OK
TR2 07/10/2018 RUM2 €400 OK
TR3 10/10/2018 RUM2 €400 KO
TR4 12/10/2018 RUM1 €200 OK
TR5 15/10/2018 RUM1 €100
02/11/2018
(> 30)
Transaction TR6
Amount: €300
Mandate: RUM1
OK 1 €300 TR6 02/11/2018 RUM1 €300

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • and set the number of transactions made and/or the cumulative amount and the cumulation time through the fraud tab in the MEX

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum cumulative amount 0.01 over the period, in your currency 9999999
Maximum number of transactions 1 transaction over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). -- Neutral NOT_APPLICABLE
The number of transactions made and/or the total of the accumulated amounts with this mandate over the period exceed(s) the accepted limit(s). 64 Negative TRANS=A:B;
CUMUL=C:D*
The number of transactions made and the total of the accumulated amounts with this mandate over the period are lower than the accepted limits. -- Neutral

*A: number of transactions carried out with this mandate over the period.

B: maximum number of transactions accepted with a given mandate over the period.

C: sum of the cumulative amounts with this mandate over the period.

D: maximum sum of cumulative amounts accepted with a given mandate over the period.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the VelocityMandate instruction.

  • POST example:
      fraudData.bypassCtrlList=VelocityMandate
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>VelocityMandate</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["VelocityMandate"]
}
    

Limitations of use

In the case of payment in N instalments, only the first instalment is taken into account.

During the validation, cancellation and refund of the transaction, the amount not validated, cancelled or refunded is not subtracted from the count.

IBAN velocity

Rule description

This rule enables you to assess the risk of a purchase by checking the activity (the number and/or accumulated amount of transactions) of the IBAN over a period.

The rule is executed on all payment transactions made with a SDD means of payment. The calculation of the velocity only takes in account the transactions previously accepted during the period.

The rule checks the activity of an IBAN over a given period. The number of transactions and/or accumulated amount of transactions and the duration of the period must be provided by you in your profile settings.

Example

The following table outlines the change in the mandate history, in the event that you decided to limit purchases on your website to 2 times for one IBAN, for a total amount of €500 per month (30 days):

Transaction date Payment details Rule result IBAN velocity
(number of transactions)
IBAN velocity
(cumulative amount)
History situation
(last 30 days)
01/10/2018 Transaction TR1
Amount: €100
IBAN: IBAN1
OK 1 €100 TR1 01/10/2018 IBAN1 €100
07/10/2018 Transaction TR2
Amount: €400
IBAN: IBAN2
OK 1 €400 TR1 01/10/2018 IBAN1 €100 OK
TR2 07/10/2018 IBAN2 €400
10/10/2018 Transaction TR3
Amount: €400
IBAN: IBAN2
KO 2 €800
(> 500)
TR1 01/10/2018 IBAN1 €100 OK
TR2 07/10/2018 IBAN2 €400 OK
TR3 10/10/2018 IBAN2 €400
12/10/2018 Transaction TR4
Amount: €200
IBAN: IBAN1
OK 2 €300 TR1 01/10/2018 IBAN1 €100 OK
TR2 07/10/2018 IBAN2 €400 OK
TR3 10/10/2018 IBAN2 €400 KO
TR4 12/10/2018 IBAN1 €200
15/10/2018 Transaction TR5
Amount: €100
IBAN: IBAN1
KO 3
(> 2)
€400 TR1 01/10/2018 IBAN1 €100 OK
TR2 07/10/2018 IBAN2 €400 OK
TR3 10/10/2018 IBAN2 €400 KO
TR4 12/10/2018 IBAN1 €200 OK
TR5 15/10/2018 IBAN1 €100
02/11/2018
(> 30)
Transaction TR6
Amount: €300
IBAN: IBAN1
OK 1 €300 TR6 02/11/2018 IBAN1 €300

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • and set the number of transactions made and/or the cumulative amount and the cumulation time through the fraud tab in the MEX

Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum cumulative amount 0.01 over the period, in your currency 9999999
Maximum number of transactions 1 transaction over the period 9999

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD) -- Neutral NOT_APPLICABLE
The number of transactions made and/or the total of the accumulated amounts with this IBAN over the period exceed(s) the accepted limit(s) 65 Negative TRANS=A:B;
CUMUL=C:D*
The number of transactions made and the total of the accumulated amounts with this IBAN over the period are lower than the accepted limits -- Neutral

*A: number of transactions carried out with this IBAN over the period.

B: maximum number of transactions accepted with a given IBAN over the period.

C: sum of cumulative amoumnts with this IBAN over the period.

D: maximum sum of cumulative amounts accepted with a given IBAN over the period.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the VelocityIban field.

  • POST example:
      fraudData.bypassCtrlList=VelocityIban
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>VelocityIban</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["VelocityIban"]
}
    

Limitations of use

In the case of payment in N instalments, only the first instalment is taken into account.

During the validation, cancellation and refund of the transaction, the amount not validated, cancelled or refunded is not subtracted from the count.

Miscellaneous rules

IP address reputation

Rule description

This rule enables you to decide whether to accept or refuse a purchase made from an IP address the reputation of which is dangerous.

The rule queries the IP address reputation database to know the reputation of the customer's IP address and check whether it is on the list of unwanted IP address reputations defined by you. This IP address comes from:

  • the automatic detection performed by the customer's browser in Sips Paypage
  • or your transfer of data in the request in Sips Office

If there is no list of unwanted IP address reputations, the rule returns a neutral result.

Conditions of use

If you would like to use this rule you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the list of unwanted IP address reputations through the fraud tab in the MEX
  • and send the customer's IP address in the request ( customerIpAddress field), if you use Sips Office .

Please read Appendix 3: IP address reputations to find out more about configurable IP addresses.

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
The information is not known. -- Neutral IP_REP=XXX*
The IP address reputation is on the list of unwanted IP address reputations. 44 Negative
The IP address reputation is not on the list of unwanted IP address reputations. -- Neutral

* XXX: IP address reputation (see Appendix 3: IP address reputations)

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the IpReputations instruction.

  • POST example:
      fraudData.bypassCtrlList=IpReputations
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>IpReputations</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["IpReputations"]
}
    

Lost and stolen cards (CB scheme cards)

Rule description

This rule enables you to decide whether to accept or refuse a purchase made with a blocked card.

The rule is executed on all payment transactions carried out with CB, Visa and MasterCard cards.

The rule checks whether the card is present in the database of blocked cards.

The file of blocked cards is populated by the CB network's list of blocked cards. The file is updated several times a day.

Conditions of use

If you would like to use this rule, you must set the rule using the fraud tab in the MEX .

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The oppotota server could not be accessed. -- Neutral --
The card is blocked. 11 Negative
The card is not blocked. -- Neutral

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the HotList instruction.

  • POST example:
      fraudData.bypassCtrlList=HotList
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>HotList</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["HotList"]
}
    

Virtual card

Rule description

This rule enables you to decide whether to accept or refuse a purchase paid for by the holder of a virtual card issued by a French bank.

The rule is executed on all card payment transactions.

The rule checks the BIN range database to determine whether the card is a virtual card.

Conditions of use

If you would like to use this rule, you must set the rule using the fraud tab in the MEX .

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card.). -- Neutral NOT_APPLICABLE
The information is not known. -- Neutral --
The card is a dynamic virtual card. 07 Negative
The card is not a dynamic virtual card. -- Neutral

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the ECard instruction.

  • POST example:
      fraudData.bypassCtrlList=ECard
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>ECard</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["ECard"]
}
    

Card with mandatory authorisation

Rule description

This rule enables you to decide whether to accept or refuse a purchase paid for by the holder of a systematic authorisation card.

The rule is executed on all card payment transactions.

The rule checks the BIN range database to determine whether the card is a systematic authorisation card.

Conditions of use

If you would like to use this rule, you must set the rule using the fraud tab in the MEX .

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card.). -- Neutral NOT_APPLICABLE
The information is not known. -- Neutral --
The card is a systematic authorisation card. 14 Negative
The card is not a systematic authorisation card. -- Neutral

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SystematicAuthorizationCard instruction.

  • POST example:
      fraudData.bypassCtrlList=SystematicAuthorizationCard
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>SystematicAuthorizationCard</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["SystematicAuthorizationCard"]
}
    

Commercial card (and card country)

Rule description

This rule enables you to decide whether to accept or refuse to provide a service based on the fact that the card is:

  • a commercial card
  • a commercial card present on a list of authorised or prohibited issuing countries

The rule is executed on all card payment transactions.

The rule first queries a card information database to check whether the card is part of a commercial card BIN range. This will determine whether the card is a commercial card. Depending on the required check, the server checks whether the country in which the commercial card was issued is on the list of the countries that you have authorised or prohibited.

If there is no list of authorised or prohibited commercial card issuing countries, the server simply checks whether the card is a commercial card.

Conditions of use

If you would like to use this rule, you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • and set the list of authorised or prohibited commercial card issuing countries (if you want to intercept the commercial cards of certain countries). To this end, you must:
    • set the list through the fraud tab in the MEX
    • or dynamically override the list of authorised or prohibited countries in your request

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The information is not known. -- Neutral CARD_COUNTRY=XXX*
The card is a commercial card, and the list of authorised/prohibited commercial card countries has not been defined. 18 Negative CARD_COUNTRY=XXX*
The card country is on the list of prohibited commercial card countries or is not the list of of authorised commercial card countries. 43 Negative
The card country is not on the list of prohibited commercial card countries or is on the list of authorised commercial card countries. -- Neutral
The card is not a commercial card. -- Neutral

* XXX: ISO 3166 alphabetical country codes (see Appendix 4: ISO 3166 alphabetical country codes)

This rule does not populate the complementaryInfo field.

Dynamic override

You can supply dynamically a list of authorised or prohibited commercial card country in the request. If a list is sent in the request, it takes priority over the possible configuration except if it conflicts with the configuration imposed by the distributor.

Choose the parameter to be overridden in the field...

      
        fraudData.
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam      
    

...and send the country list in the field:

      fraudData      .
     
riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue
    

The 2 parameters for this rule are:

  • AllowedCommercialCardCountryList for the authorised commercial card country combinations

  • DeniedCommercialCardCountryList for the denied commercial card country combinations

  • POST example:
      fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedCommercialCardCountryList,riskManagementDynamicValue=(FRA,BEL)}
    

  • SOAP example:
      <urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedCommercialCardCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,BEL)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedCommercialCardCountryList”,
                    “riskManagementDynamicValue”:“(FRA,BEL)”
          }
     ]
}
    

For both methods, the list sent must contain either:

  • the ISO 3166 alphabetic country codes (see Appendix 4: ISO 3166 alphabetical country codes) separated by commas
  • or a pre-established country code list (see Appendix 7: pre-established country code lists)

For simple configuration mode, the sending of 2 lists (allowed and denied) in the same request is considered as an error, in which case the rule is not executed.

For advanced configuration mode, the sending of 2 negative lists (disavantaged and no disavantaged) or 2 positive lists (advantaged and no advantaged) in the same request is considered as an error, in which case the rule is not executed.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the CorporateCard instruction.

  • POST example:
      fraudData.bypassCtrlList=CorporateCard
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>CorporateCard</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["CorporateCard"]
}
    

Cap collar amounts

Rule description

This rule enables you to assess the risk of a purchase by verifying its amount.

The rule checks whether the transaction amount lies within the amount range required by the merchant.

If no minimum and maximum amounts have been defined for the amount, the rule returns a neutral result.

Conditions of use

If you would like to use this rule, you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • and set the minimum and/or maximum amount(s) through the fraud tab in the MEX

Parameter Minimum value Maximum value
Minimum value 0.01 in your currency 9999999
Maximum value 0.01 in your currency 9999999
Attention: in advanced configuration mode, you can set two amount ranges, one of them having a positive (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) amount range.

Expression of the result

Default mode:

Use case Complementary Code Rule result RuleDetailedInfo
The transaction amount does not lie within the required amount range. 25 Negative MIN=A:B;MAX=A:C*
The transaction amount lies within the required amount range. -- Neutral

Advanced configuration mode:

Cas d'utilisation Complementary Code Rule result RuleDetailedInfo
The transaction amount lies within the disadvantaged amount range. 25 Negative MIN=A:B;MAX=A:C*
The transaction amount does not lie within the advantaged and disadvantaged amount ranges. -- Neutral
The transaction amount lies within the advantaged amount range. 25 Positive

This rule does not populate the complementaryInfo field.

__________

* A: transaction amount.

B: minimum amount accepted.

C: maximum amount accepted.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the CapCollerAmount instruction.

  • POST example:
      fraudData.bypassCtrlList=CapCollarAmount
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>CapCollarAmount</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["CapCollarAmount"]
}
    

CB scheme card

Rule description

This rule enables the merchant to decide whether to accept or refuse a purchase made with a card of the CB network.

The rule is executed on all card payment transactions.

The rule checks the BIN range database to determine whether the card is a card of the Carte Bancaire network.

Conditions of use

If you would like to use this rule, you must set the rule using the fraud tab in the MEX .

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The card BIN is unknown. -- Neutral --
The card is not part of the CB network. 19 Negative
The card is part of the CB network. -- Neutral

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the CBScheme instruction.

  • POST example:
      fraudData.bypassCtrlList=CBScheme
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>CBScheme</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["CBScheme"]
}
    

Free e-mail address

Rule description

This rule enables you to assess the fraud risk of a purchase made by a customer whose e-mail address is free.

The rule checks whether the customer's e-mail address is part of a free e-mail address domain.

The following e-mail addresses are checked:

  • the customer's e-mail address
  • the e-mail address of the holder of the means of a payment (the customer might be using the means of payment of a relative)
  • the billing contact's e-mail address
  • the delivery contact's e-mail address

If one of the available e-mail addresses is on the list, a negative result is returned.

Conditions of use

If you would like to use this rule, you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • and send at least one of the customer's e-mail addresses in the request ( billingContact.email, customerContact.email, deliveryContact.email, holderContact.email fields).

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
At least one of the e-mail addresses is on the list of free e-mail addresses. 27 Negative --
None of the e-mail addresses are on the list of free e-mail addresses. -- Neutral
No e-mail addresses were sent. -- Neutral

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the FreeEmail instruction.

  • POST example:
      fraudData.bypassCtrlList=FreeEmail
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>FreeEmail</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["FreeEmail"]
}
    

3-D Secure authentication

Rule description

This rule enables you to measure the risk related to a transaction with 3-D Secure authentication according to the 3-D Secure status. Here, 3-D Secure authentication includes the following authentication programmes: Visa's 3-D Secure, MasterCard's SecureCode, American Express's SafeKey, Bancontact/Mister Cash authentication, etc.

The rule is executed on all card payment transactions with 3-D Secure authentication.

The rule checks whether the cardholder's authentication status is on a list of refused statuses.

If there is no list of refused statuses, the rule returns a neutral result.

Conditions of use

If you would like to use this rule, you must:

  • activate the rule in the proifle using the fraud tab in the MEX
  • and set the list of prohibited 3-D Secure authentication statuses through the fraud tab in the MEX .

Please refer to Appendix 5: 3-D Secure authentication statuses.

Attention: in advanced configuration mode, you can set two lists, one of them having a positive (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list.

Expression of the result

Default mode (simple configuration):

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment does not support 3-D Secure authentication or you do not participate to the 3-D Secure authentication programme). -- Neutral NOT_APPLICABLE
The 3-D Secure status is prohibited. 17 Negative --
The 3-D Secure status is not prohibited. -- Neutral

This rule does not populate the complementaryInfo field.

Advanced configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment does not support 3-D Secure authentication or the merchant does not participate to the 3-D Secure authentication programme). -- Neutral NOT_APPLICABLE
The 3-D Secure status is on the list of disadvantaged statuses. 17 Negative --
The 3-D Secure status is not on the lists of disadvantaged statuses and advantaged statuses. -- Neutral
The 3-D Secure status is on the list of advantaged statuses. 17 Positive

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the 3DSStatus instruction.

  • POST example:
      fraudData.bypassCtrlList=3DSStatus
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>3DSStatus</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["3DSStatus"]
}
    

E-mail address syntax

Rule description

This rule enables you to assess the risk of a purchase according to whether the e-mail addresses used as part of the transaction are correctly formatted.

The rule checks whether the e-mail addresses used as part of the transaction are correctly formatted.

The following e-mail addresses are checked:

  • the customer's e-mail address
  • the e-mail address of the holder of the means of a payment (the customer might be using the means of payment of a relative)
  • the billling contact's e-mail address
  • the delivery contact's e-mail address

If one of the e-mail addresses submitted is incorrectly formatted, the rule returns a negative result.

Conditions of use

If you would like to use this rule, you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • and send at least one of the customer's e-mail addresses in the request ( billingContact.email, customerContact.email, deliveryContact.email, holderContact.email fields).

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
The e-mail address is incorrectly formatted. 46 Negative --
The e-mail address is correctly formatted. -- Neutral
No e-mail addresses were sent. -- Neutral

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the EmailSyntax instruction.

  • POST example:
      fraudData.bypassCtrlList=EmailSyntax
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>EmailSyntax</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["EmailSyntax"]
}
    

Address verification (InfoScore)

Rule description

This operation, which is delegated to InfoScore, is used to verify the delivery address submitted during an ELV transaction. This additional verification is carried out using the AZ Direct GmbH database; therefore, it only works with German addresses.

The check is only performed for ELV payments and Delivery addresses in Germany (the value of countryCode is "DEU").

InfoScore returns the result of the address check as an indicator. Please refer to Appendix 6: InfoScore address verification indicator for the meanings of these indicators.

These settings will enable you to accept or refuse certain values.

For instance, you can choose to trust only addresses for which the PPB and PHB checks are positive.

Conditions of use

If you would like to use this rule, you must:

  • have subscribed to the InfoScore option
  • activate the rule in the profile using the fraud tab in the MEX
  • set the list of authorised/prohibited indicators through the fraud tab in the MEX

  • and send the customer's postal delivery address in the request.

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the InfoScore ID is missing, or the delivery address is not located in Germany.). -- Neutral NOT_APPLICABLE
The information is unknown. -- Neutral IS_INDIC=XXX*
The type of address returned by InfoScore is on the list of prohibited types or is not on the list of authorised types. 48 Negative IS_INDIC=XXX*
The type of address returned by InfoScore is on the list of authorised types or is not on the list of prohibited types. -- Neutral

* XXX: indicator returned by InfoScore.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the AddressVerification instruction.

  • POST example:
      fraudData.bypassCtrlList=AddressVerification
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>AddressVerification</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["AddressVerification"]
}
    

Account verification (InfoScore)

Rule description

This operation, which is delegated to InfoScore, is used to verify the debit account used during an ELV transaction. This verification is carried out using the Rücklastschriften-Präventions-Pool (RPP) database of InfoScore Consumer Data GmbH (ICD).

This verification is only performed for ELV payments.

The RPP pool for the risk management of direct debit rejections is a cross-industry data pool that contains banking information pertaining to various activity sectors and industries. The aim of the RPP is to prevent connection problems when using the “direct debit” means of payment.

Besides, the RPP database contains information about "non-consumer" accounts whose references may be public (associations' accounts, government accounts, companies, etc.).

When an account is identified, the information is returned in InfoScore's response to WL Sips .

The verification will return a negative value if:

  • the account is a "non-consumer" account
  • the account is part of the PAP (Proprietary Account Protection) programme, a list of accounts which have been prohibited from Internet use by their owners
  • the account is on the KUNO list (Kriminalitätsbekämpfung im unbaren Zahlungsverkehr unter Nutzung nichtpolizeilicher Organisationen), which is a list of accounts blocked in Germany for various reasons

Conditions of use

If you would like to use this rule, you must:

  • have subscribed to the InfoScore option
  • activate the rule in the profile using the fraud tab in the MEX
  • and set the list of authorised/prohibited indicators through the fraud tab in the MEX

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the InfoScore ID is missing). -- Neutral NOT_APPLICABLE
The information is unknown. -- Neutral VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF*
The account is not a consumer account, or is on the PAP or KUNO lists. 49 Negative VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF*
The account is a consumer account. -- Neutral

* AAA: InfoScore resultCode (00 = the bank account is valid).

BBB: value of the NCA InfoScore indicator.

CCC: value of RppContentCode for InfoScore NCA KO.

DDD: value of the PAP InfoScore indicator.

EEE: value of RppContentCode for InfoScore PAP KO.

FFF: value of the InfoScore RPP indicator.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the AddressVerification instruction.

  • POST example:
      fraudData.bypassCtrlList=AccountVerification
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>AccountVerification</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["AccountVerification"]
}
    

Card expiry date

Rule description

This rule enables you to detect the payments made with a card that will expire in the next few months. It is notably useful with payments in multiple instalments, to make sure the card will still be valid for the next instalments.

The rule is executed on all card transactions.

The rule checks whether the number of months before the card expires is higher than the number of months you specified.

If the minimum number of months before expiry is not configured, the rule considers that this number is equal to zero.

Conditions of use

If you would like to use this rule, you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • and set the minimum number of months before the card expires through the fraud tab in the MEX

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The validity time of the means of payment is shorter than the required duration. 23 Negative EXPIRY=AAA:BBB*
The validity time of the means of payment is longer than the required duration. -- Neutral

* AAA: card expiry date in MMYY format.

BBB: deadline of the check in MMYY format.

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the ExpiryDate instruction.

  • POST example:
      fraudData.bypassCtrlList=ExpiryDate
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>ExpiryDate</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["ExpiryDate"]
}
    

List rules

Overview

The fraud risk management engine makes it possible to manage several data lists. Three different types of rules can be applied to these lists, as described below:

  • blacklist verification
  • greylist verification
  • whitelist verification

The difference between these rules depends on the result of the rule and the way you manage the list:

  • A blacklist is a NOGO-type list used for severe actions and usually leads to transactions being rejected.
  • A greylist is a NOGO-type list used for suspicious cases that require special attention.
  • A whitelist is a GO-type list used to treat certain customers with special positive attention.

The possible results according to the type of rule are shown below:

Data item is present Blacklist result
(NOGO-type)
Greylist result
(NOGO-type)
Whitelist result
(GO-type)
NO Neutral Neutral Neutral
YES Negative Négative Positive

For you, Internet purchases present a higher risk of fraud than "card present" purchases. Mail /telephone/Internet orders are major vectors of fraud if you sell and ship products. If the card is not physically present, you must rely on the cardholder (or someone who claims to be them) to submit the information indirectly by mail, telephone or the Internet.

You may want to track the customers (or properties related to them) with whom you have had good or bad experiences during previous purchases. For instance, if you have shipped a product to an address but have not been paid because the card was used fraudulently for this payment, you can decide to blacklist this number so payment requests are rejected if this card is used again on the webshop.

Here is another example: you can add a special customer name to a list if you assume that this customer has solvency issues, e.g. if a financial authorisation attempt was rejected with a code indicating "insufficient credit" on the account. In this case, you may want not to reject the transaction immediately, but rather be alerted if this name is used again in a transaction.

The merchant can also manage this name on what is called a greylist. This way, you can be alerted if one of the properties is used again during a different transaction, and process the new transaction with special care, review it manually, etc. Greylists are also a way of managing properties that can be considered as related to fraud.

On the other hand, you may have had bad experiences with certain customers but also very positive ones with others. Therefore, you can treat certain customers as "VIPs". B2B customers may prove sufficiently trustworthy as well. Whitelists are the appropriate way of managing such customers.

Shared lists

By default, a webshop has its own list for each list-type rule. It is called a private list. It is also possible to share a list among several webshops. A list is shared in the same commercial group. 5 shared lists can be created for a type of list. All the webshops attached on a shared list can modify the elements in the list. The element added by a webshop can only be modified or deleted by a user of this webshop or an administrator, but not by another webshop. The elements in the lists are used for all these webshops.

To set up a shared list, you need to contact your account manager for the configuration. This is done in two steps:

  • First, create a shared list by combining its type (e-mail address list, card number list, etc.) and its color (black, grey or white)
  • then associate the shared list to the webshops

During the execution of the antifraud control, when the list-type rule is active in the applied merchant profile, the shared list will be used instead of the default private list.

E-mail addresses

Rule description

This rule enables you:

  • to decide whether to accept or refuse a purchase related to an e-mail address that is on the e-mail address blacklist or greylist .
  • and/or decide whether or not to honour a purchase linked to an e-mail address that belongs to the whitelist of e-mail addresses without having to comply with the other decisive rules, which allows you to define a list of VIP e-mail addresses.

If the rule is present in your profile, it will be executed on all the payment transactions for which you sent at least one e-mail address.

The rule checks whether all the available e-mail addresses are on the e-mail address blacklist, greylist and/or whitelist you defined. The following e-mail addresses are checked:

  • the customer's e-mail address
  • the e-mail address of the holder of the means of a payment (the customer/buyer might be using the means of payment of a relative)
  • the billing contact's e-mail address
  • the delivery contact's e-mail address

If one of the e-mail adresses is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.

Conditions of use

If you would like to use this rule, you must, for each list:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the e-mail address black, grey and/or white list(s)

  • and send one or more of the above e-mail adresses in the request ( billingContact.email, customerContact.email, deliveryContact.email, holderContact.email fields)

Expression of the result

Use case Complementary Code Rule result Rule DetailedInfo
At least one e-mail address is on the list. Black 31 Negative --
Grey 32
White AC Positive
None of the e-mail addresses are on the list. Black -- Neutral
Grey
White
No e-mail addresses were sent. Black
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackEmail (blacklist), GreyEmail (greylist) and/or WhiteEmail (whitelist) instruction(s).

  • POST example:

Blacklist:

      fraudData.bypassCtrlList=BlackEmail
    

Greylist:

      fraudData.bypassCtrlList=GreyEmail
    

Whitelist:

      fraudData.bypassCtrlList=WhiteEmail
    

  • SOAP example:

Blacklist:

      <urn:fraudData>
     <urn:bypassCtrlList>BlackEmail</urn:bypassCtrlList>
</urn:fraudData>
    

Greylist:

      <urn:fraudData>
     <urn:bypassCtrlList>GreyEmail</urn:bypassCtrlList>
</urn:fraudData>
    

Whitelist:

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteEmail</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:

Blacklist:

      "fraudData": {
   "bypassCtrlList": ["BlackEmail"]
}
    

Greylist:

      "fraudData": {
   "bypassCtrlList": ["GreyEmail"]
}
    

Whitelist:

      "fraudData": {
   "bypassCtrlList": ["WhiteEmail"]
}
    

IP addresses

Rule description

This rule enables you:

  • to decide whether to accept or refuse a purchase related to an IP address that is on the IP address blacklist or greylist .
  • and/or decide whether or not to honour a purchase linked to an IP address that belongs to the whitelist of IP addresses without having to comply with the other decisive rules, which allows you to define a list of VIP IP addresses.

The rule checks whether the IP address is on the IP address blacklist, greylist and/or whitelist you defined. This IP address comes from:

  • the automatic detection performed by the customer's browser in Sips Paypage
  • or your transfer of data in the request in Sips Office

If the IP address is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.

Conditions of use

If you would like to use this rule, you must, for each list:

  • activate the rule in the profile using the fraud tab in the MEX ,
  • set the IP address black, grey and/or white list(s)

  • and send the customer's IP address in the request ( customerIpAddress field), if you use Sips Office

Expression of the result

Use case Complementary Code Rule result Rule DetailedInfo
The IP address is not specified (in Sips Office ) Black -- Neutral --
Grey
White
The IP address is on the list. Black 37 Négativ
grey 38
White AE Positive
The IP address is not on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackIp (blacklist), GreyIp (greylist) and/or WhiteIp (white list) instruction(s).

  • POST example:

Blacklist:

      fraudData.bypassCtrlList=BlackIp
    

Greylist:

      fraudData.bypassCtrlList=GreyIp
    

Whitelist:

      fraudData.bypassCtrlList=WhiteIp
    

  • SOAP example:

Blacklist:

      <urn:fraudData>
     <urn:bypassCtrlList>BlackIp</urn:bypassCtrlList>
</urn:fraudData>
    

Greylist:

      <urn:fraudData>
     <urn:bypassCtrlList>GreyIp</urn:bypassCtrlList>
</urn:fraudData>
    

Whitelist:

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteIp</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:

Blacklist:

      "fraudData": {
   "bypassCtrlList": ["BlackIp"]
}
    

Greylist:

      "fraudData": {
   "bypassCtrlList": ["GreyIp"]
}
    

Whitelist:

      "fraudData": {
   "bypassCtrlList": ["WhiteIp"]
}
    

Postal codes per country

Rule description

This rule enables you:

  • to decide whether to accept or refuse a purchase related to a postal code that is on the postal codes per country blacklist or greylist .
  • and/or decide whether or not to honour a purchase linked to a postal code that belongs to the whitelist of postal codes without having to comply with the other decisive rules, which allows you to define a list of VIP postal codes.

If the rule is present in your profile, it will be executed on all the payment transactions for which you sent at least one postal code.

The rule checks whether all the available postal codes are on the postal code blacklist, greylist and/or whitelist you defined. The following postal codes are checked:

  • the billing contact's postal code
  • the delivery contact's postal code

If one of the postal codes is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.

Conditions of use

If you would like to use this rule, you must, for each list:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the postal code black, grey and/or white list(s)

  • and send one or more of the above postal codes in the request ( billingAddress.zipCode, deliveryAddress.zipCode fields)

Expression of the result

Use case Complementary Code Rule result Rule DetailedInfo
No postal codes were sent. Black -- Neutral --
Grey
White
At least one postal code is on the list. Black 39 Negative
Grey 40
White AG Positive
None of the postal codes are on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackPostalCode (blacklist), GreyPostalCode (greylist) and/or WhitePostalCode (whitelist) instruction(s).

  • POST examples:

Blacklist:

      fraudData.bypassCtrlList=BlackPostalCode
    

Greylist:

      fraudData.bypassCtrlList=GreyPostalCode
    

Whitelist:

      fraudData.bypassCtrlList=WhitePostalCode
    

  • SOAP examples:

Blacklist:

      <urn:fraudData>
     <urn:bypassCtrlList>BlackPostalCode</urn:bypassCtrlList>
</urn:fraudData>
    

Greylist:

      <urn:fraudData>
     <urn:bypassCtrlList>GreyPostalCode</urn:bypassCtrlList>
</urn:fraudData>
    

Whitelist:

      <urn:fraudData>
     <urn:bypassCtrlList>WhitePostalCode</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON examples:

Blacklist:

      "fraudData": {
   "bypassCtrlList": ["BlackPostalCode"]
}
    

Greylist:

      "fraudData": {
   "bypassCtrlList": ["GreyPostalCode"]
}
    

Whitelist:

      "fraudData": {
   "bypassCtrlList": ["WhitePostalCode"]
}
    

Customer IDs

Rule description

This rule enables you:

  • to decide whether to accept or refuse a purchase related to a customer ID that is on customer ID blacklist or greylist .
  • and/or decide whether or not to honour a purchase linked to a customer ID that belongs to the whitelist of customer IDs without having to comply with the other decisive rules, which allows you to define a list of VIP customer IDs.

If the rule is present in your profile, it will be executed on all the payment transactions for which a customer ID was submitted in the request or sent by you.

The rule checks whether the customer Id is on the customer ID blacklist, greylist and/or whitelist you defined.

If one of the customer ID is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.

Conditions of use

If you would like to use this rule, you must, for each list:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the customer ID black, grey and/or white list(s)

  • and send the customer's customer ID in the request ( customerId field)

Expression of the result

Use case Complementary Code Rule result Rule DetailedInfo
The customer ID is not supplied. Black -- Neutral --
Grey
White
At least one customer ID is on the list. Black 28 Negative
Grey 29
White AB Positive
The customer ID is not on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackCustomerId (blacklist), GreyCustomerId (greylist) and/or WhiteCustomerId (whitelist) instruction(s).

  • POST example:

Blacklist:

      fraudData.bypassCtrlList=BlackCustomerId
    

Greylist:

      fraudData.bypassCtrlList=GreyCustomerId
    

Whitelist:

      fraudData.bypassCtrlList=WhiteCustomerId
    

  • SOAP example:

Blacklist:

      <urn:fraudData>
     <urn:bypassCtrlList>BlackCustomerId</urn:bypassCtrlList>
</urn:fraudData>
    

Greylist:

      <urn:fraudData>
     <urn:bypassCtrlList>GreyCustomerId</urn:bypassCtrlList>
</urn:fraudData>
    

Whitelist:

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteCustomerId</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:

Blacklist:

      "fraudData": {
   "bypassCtrlList": ["BlackCustomerId"]
}
    

Greylist:

      "fraudData": {
   "bypassCtrlList": ["GreyCustomerId"]
}
    

Whitelist:

      "fraudData": {
   "bypassCtrlList": ["WhiteCustomerId"]
}
    

Customer names

Rule description

This rule enables you:

  • to decide whether to accept or refuse a purchase related to a customer name that is on the customer name blacklist or greylist
  • and/or decide whether or not to honour a purchase linked to a customer name that belongs to the whitelist of customer names without having to comply with the other decisive rules, which allows you to define a list of VIP customer names

If the rule is present in your profile, it will be executed on all the payment transactions for which you sent at least one customer name.

The rule checks whether all the available names are on the customer name blacklist, greylist and/or whitelist you defined. The following customer names are checked:

  • the customer's name
  • the name of the holder of the means of payment (the customer/buyer might be using the means of payment of a relative)
  • the billing contact's name
  • the delivery contact's name

If one of the available names is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.

Conditions of use

If you would like to use this rule, you must, for each list:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the customer name black, grey and/or white list(s)

  • and send at least one customer name in the request ( billingContact.lastName, customerContact.lastName, deliveryContact.lastName, holderContact.lastName fields)

Expression of the result

Use case Complementary Code Rule result Rule DetailedInfo
No customer names were sent. Black -- Neutral --
Grey
White
At least one customer name is on the list. Black 35 Negative
Grey 36
White AF Positive
None of the customer names are on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackCustomerName (blacklist), GreyCustomerName (greylist) and/or WhiteCustomerName (whitelist).

  • POST example:

Blacklist:

      fraudData.bypassCtrlList=BlackCustomerName
    

Greylist:

      fraudData.bypassCtrlList=GreyCustomerName
    

Whitelist:

      fraudData.bypassCtrlList=WhiteCustomerName
    

  • SOAP example:

Blacklist:

      <urn:fraudData>
     <urn:bypassCtrlList>BlackCustomerName</urn:bypassCtrlList>
</urn:fraudData>
    

Greylist:

      <urn:fraudData>
     <urn:bypassCtrlList>GreyCustomerName</urn:bypassCtrlList>
</urn:fraudData>
    

Whitelist:

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteCustomerName</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:

Blacklist:

      "fraudData": {
   "bypassCtrlList": ["BlackCustomerName"]
}
    

Greylist:

      "fraudData": {
   "bypassCtrlList": ["GreyCustomerName"]
}
    

Whitelist:

      "fraudData": {
   "bypassCtrlList": ["WhiteCustomerName"]
}
    

Card numbers

Rule description

This rule enables you:

  • to decide whether to accept or refuse a purchase made with a card that is on your blacklist or greylist
  • and/or decide whether or not to honour a purchase made with a card that belongs to your whitelist without having to comply with the other decisive rules, which allows you to define a list of VIP cards

If the rule is present in your profile, it will be executed on all the payment transactions by card you sent.

The rule checks whether the number submitted for authorisation (if applicable) is on your card number blacklist, greylist and/or whitelist.

If the card number in question is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.

Conditions of use

If you would like to use this rule, you must, for each list:

  • activate the rule in the profile using the fraud tab in the MEX
  • and set the card number black, grey and/or white list(s) ( cardNumber )

The list can be configured:

  • through the fraud tab and Sips Office Extranet . The data must be added through a transaction ID. In the latter case, the value of the data for the transaction associated with the transaction ID will be added to the list.
  • and through the populating batch of Sips Office Batch .

Expression of the result

Use case Complementary Code Rule result Rule DetailedInfo
This rule cannot be executed (the means of payment is not a card). Black -- Neutral --
Grey
White
The card number is on the list. Black 50 Negative
Grey 03
White AA Positive
The card number is not on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackCard (blacklist), GreyCard (greylist) and/or WhiteCard (whitelist).

  • POST example:

Blacklist:

      fraudData.bypassCtrlList=BlackCard
    

Greylist:

      fraudData.bypassCtrlList=GreyCard
    

Whitelist:

      fraudData.bypassCtrlList=WhiteCard
    

  • SOAP example:

Blacklist:

      <urn:fraudData>
     <urn:bypassCtrlList>BlackCard</urn:bypassCtrlList>
</urn:fraudData>
    

Greylist:

      <urn:fraudData>
     <urn:bypassCtrlList>GreyCard</urn:bypassCtrlList>
</urn:fraudData>
    

Whitelist:

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteCard</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:

Blacklist:

      "fraudData": {
   "bypassCtrlList": ["BlackCard"]
}
    

Greylist:

      "fraudData": {
   "bypassCtrlList": ["GreyCard"]
}
    

Whitelist:

      "fraudData": {
   "bypassCtrlList": ["WhiteCard"]
}
    

Phone numbers

Rule description

This rule enables you:

  • to decide whether to accept or refuse a purchase related to a phone number that is on the phone number blacklist or greylist
  • and/or decide whether or not to honour a purchase linked to a phone number that belongs to the whitelist of phone numbers without having to comply with the other decisive rules, which allows you to define a list of VIP phone numbers

If the rule is present in your profile, it will be executed on all the payment transactions for which you sent at least one phone number.

The rule checks whether all the available phone numbers are on the phone number blacklist, greylist and/or whitelist you defined. The following phone numbers are checked:

  • the customer's landline/mobile phone numbers
  • the landline/mobile phone numbers of the holder of the means of payment (the customer/buyer might be using the means of payment of a relative)
  • the billing contact's landline/mobile phone numbers
  • the delivery contact's landline/mobile phone numbers

If one of the available phone numbers is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.

Conditions of use

If you would like to use this rule, you must, for each list:

  • activate the rule in the profile using the fraud tab in the MEX
  • set the phone number black, grey and/or white list(s)

  • and send one or more of the above phone numbers in the request ( billingContact.phone, customerContact.phone, deliveryContact.phone, holderContact.phone, billingContact.mobile, customerContact.mobile, deliveryContact.mobile, holderContact.mobile fields)

Expression of the result

Use case Complementary Code Rule result Rule DetailedInfo
No phone numbers were sent. Black -- Neutral --
Grey
White
At least one phone number is on the list. Black 33 Negative
Grey 34
White AD Positive
None of the phone numbers are on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackPhoneNumber (blacklist), GreyPhoneNumber (greylist) and/or WhitePhoneNumber (whitelist) instruction(s).

  • POST example:

Blacklist:

      fraudData.bypassCtrlList=BlackPhoneNumber
    

Greylist:

      fraudData.bypassCtrlList=GreyPhoneNumber
    

Whitelist:

      fraudData.bypassCtrlList=WhitePhoneNumber
    

  • SOAP example:

Blacklist:

      <urn:fraudData>
     <urn:bypassCtrlList>BlackPhoneNumber</urn:bypassCtrlList>
</urn:fraudData>
    

Greylist:

      <urn:fraudData>
     <urn:bypassCtrlList>GreyPhoneNumber</urn:bypassCtrlList>
</urn:fraudData>
    

Whitelist:

      <urn:fraudData>
     <urn:bypassCtrlList>WhitePhoneNumber</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:

Blacklist:

      "fraudData": {
   "bypassCtrlList": ["BlackPhoneNumber"]
}
    

Greylist:

      "fraudData": {
   "bypassCtrlList": ["GreyPhoneNumber"]
}
    

Whitelist:

      "fraudData": {
   "bypassCtrlList": ["WhitePhoneNumber"]
}
    

BIN ranges

Rule description

This rule enables you:

  • to decide whether to accept or refuse a purchase made with a card the BIN of which is on your BIN blacklist or greylist
  • and/or decide whether or not to honour a purchase made with a card the BIN of which is on the whitelist of BINs without having to comply with the other decisive rules, which allows you to define a list of VIP BINs

If the rule is present in your profile, it will be executed on all the card payment transactions you sent.

The rule checks whether the card BIN number is on your BIN range blacklist, greylist and/or whitelist.

If the BIN number of the card in question is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.

Conditions of use

If you would like to use this rule, you must, for each list:

  • activate the rule in the profile using the fraud tab in the MEX
  • and set the BIN number black, grey and/or white list(s) ( cardNumber )

Note: please read the glossary for more information on BINs.

Expression of the result

Use case Complementary Code Rule result Rule DetailedInfo
This rule cannot be executed (the means of payment is not a card). Black -- Neutral --
Grey
White
The card BIN is on the list. Black 41 Negative
Grey 08
White AH Positive
The card BIN is not on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackBinCard (blacklist), GreyBinCard (greylist) and/or WhiteBinCard (whitelist) instruction(s).

  • POST example:

Blacklist:

      fraudData.bypassCtrlList=BlackBinCard
    

Greylist:

      fraudData.bypassCtrlList=GreyBinCard
    

Whitelist:

      fraudData.bypassCtrlList=WhiteBinCard
    

  • SOAP example:

Blacklist:

      <urn:fraudData>
     <urn:bypassCtrlList>BlackBinCard</urn:bypassCtrlList>
</urn:fraudData>
    

Greylist:

      <urn:fraudData>
     <urn:bypassCtrlList>GreyBinCard</urn:bypassCtrlList>
</urn:fraudData>
    

Whitelist:

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteBinCard</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:

Blacklist:

      "fraudData": {
   "bypassCtrlList": ["BlackBinCard"]
}
    

Greylist:

      "fraudData": {
   "bypassCtrlList": ["GreyBinCard"]
}
    

Whitelist:

      "fraudData": {
   "bypassCtrlList": ["WhiteBinCard"]
}
    

BIC (Bank Identifier Code)

Rule description

This rule enables you to assess the risk of a purchase associated with a BIC (Bank Identifier Code) which is on the BIC blacklist, greylist and/or whitelist , without having to comply with the other decisive rules in the case of the whitelist, which allows you to define a list of VIP BICs.

If the rule is present in your profile, it will be executed on all the payment transactions made with the SDD means of payment.

The rule will check whether the BIC is on the BIC blacklist, greylist and/or whitelist you defined.

If the BIC is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.

Tip: you can send the BIC in the request. Alternatively, it will automatically be found from the IBAN that you must send.

Conditions of use

If you would like to use this rule, you must, for each list:

  • activate the rule in the profile using the fraud tab in the MEX
  • and set the BIC black, grey and/or white list(s)

Expression of the result

Use case Complementary Code Rule result Rule DetailedInfo
The BIC is on the list. Black 66 Negative --
Grey 67
White AI Positive
The BIC is not on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackBic (blacklist), GreyBic (greylist) and/or WhiteBic (whitelist) instruction(s).

  • POST example:

Blacklist:

      fraudData.bypassCtrlList=BlackBic
    

Greylist:

      fraudData.bypassCtrlList=GreyBic
    

Whitelist:

      fraudData.bypassCtrlList=WhiteBic
    

  • SOAP example:

Blacklist:

      <urn:fraudData>
     <urn:bypassCtrlList>BlackBic</urn:bypassCtrlList>
</urn:fraudData>
    

Greylist:

      <urn:fraudData>
     <urn:bypassCtrlList>GreyBic</urn:bypassCtrlList>
</urn:fraudData>
    

Whitelist:

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteBic</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:

Blacklist:

      "fraudData": {
   "bypassCtrlList": ["BlackBic"]
}
    

Greylist:

      "fraudData": {
   "bypassCtrlList": ["GreyBic"]
}
    

Whitelist:

      "fraudData": {
   "bypassCtrlList": ["WhiteBic"]
}
    

IBAN (International Bank Account Number)

Rule description

This rule enables you to assess the risk of a purchase associated with an IBAN (International Bank Account Number) which is on the IBAN blacklist, greylist and/or whitelist , without having to comply with the other decisive rules in the case of the whitelist, which allows you to define a list of VIP IBANs.

If the rule is present in your profile, it will be executed on all the payment transactions made with the SDD means of payment.

The rule will check whether the IBAN used for the SDD mandate is on the IBAN blacklist, greylist and/or whitelist you defined.

If the IBAN is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.

Conditions of use

If you would like to use this rule, you must, for each list:

  • activate the rule in the profile using the fraud tab in the MEX
  • and set the IBAN black, grey and/or white list(s)

Expression of the result

Use case Complementary Code Rule result Rule DetailedInfo
The IBAN is on the list. Black 68 Negative --
Grey 59
White AJ Positive
The IBAN is not on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackIban (blacklist), GreyIban (greylist) and/or WhiteIban (whitelist) instruction(s).

  • POST example:

Blacklist:

      fraudData.bypassCtrlList=BlackIban
    

Greylist:

      fraudData.bypassCtrlList=GreyIban
    

Whitelist:

      fraudData.bypassCtrlList=WhiteIban
    

  • SOAP example:

Blacklist:

      <urn:fraudData>
     <urn:bypassCtrlList>BlackIban</urn:bypassCtrlList>
</urn:fraudData>
    

Greylist:

      <urn:fraudData>
     <urn:bypassCtrlList>GreyIban</urn:bypassCtrlList>
</urn:fraudData>
    

Whitelist:

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteIban</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:

Blacklist:

      "fraudData": {
   "bypassCtrlList": ["BlackIban"]
}
    

Greylist:

      "fraudData": {
   "bypassCtrlList": ["GreyIban"]
}
    

Whitelist:

      "fraudData": {
   "bypassCtrlList": ["WhiteIban"]
}
    

Mandates

Rule description

This rule enables you to assess the risk of a purchase associated with a SDD mandate which is on the mandate blacklist, greylist and/or whitelist , without having to comply with the other decisive rules in the case of the whitelist, which allows you to define a list of VIP mandates.

If the rule is present in your profile, it will be executed on all the payment transactions made with the SDD means of payment.

The rule will check whether the mandate is on the mandate blacklist, greylist and/or whitelist you defined, based on its Unique Mandate Reference (UMR).

If the mandate is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.

Conditions of use

If you would like to use this rule, you must, for each list:

  • activate the rule in the profile using the fraud tab in the MEX
  • and set the mandate black, grey and/or white list(s)

Expression of the result

Use case Complementary Code Rule result Rule DetailedInfo
The UMR is on the list. Black 70 Negative --
Grey 71
White AK Positive
The UMR is not on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackMandate (blacklist), GreyMandate (greylist) and/or WhiteMandate (whitelist) instruction(s).

  • POST example:

Blacklist:

      fraudData.bypassCtrlList=BlackMandate
    

Greylist:

      fraudData.bypassCtrlList=GreyMandate
    

Whitelist:

      fraudData.bypassCtrlList=WhiteMandate
    

  • SOAP example:

Blacklist:

      <urn:fraudData>
     <urn:bypassCtrlList>BlackMandate</urn:bypassCtrlList>
</urn:fraudData>
    

Greylist:

      <urn:fraudData>
     <urn:bypassCtrlList>GreyMandate</urn:bypassCtrlList>
</urn:fraudData>
    

Whitelist:

      <urn:fraudData>
     <urn:bypassCtrlList>WhiteMandate</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:

Blacklist:

      "fraudData": {
   "bypassCtrlList": ["BlackMandate"]
}
    

Greylist:

      "fraudData": {
   "bypassCtrlList": ["GreyMandate"]
}
    

Whitelist:

      "fraudData": {
   "bypassCtrlList": ["WhiteMandate"]
}
    

Basket rules

Overview

The anti-fraud management engine takes basket contents into account for the purpose of risk assessment. To do this, it uses lists of risky products that you define yourself.

A risky product is a product that you sell and consider to be potentially associated with risky transactions, based on certain product criteria: category or type of product, price of product, frequent use of a product in fraudulent transactions, etc.

You have the option to define up to 3 lists of risky products for your webshop. You can also add some or all of the products that you sell to one or more lists, depending on the risk status of the product.

For exemple, you may choose to create 3 risky product lists as follows:

  • one for low-risk products
  • one for moderate-risk products
  • and one for high-risk products

The risky product lists are used by the risk detection rules for the basket content of customers making a purchase on your website. If these rules are activated, they will analyse the basket content and compare it to the risky product list(s) you define to assess the risk of the transaction. You may then restrict the purchase of certain products to a certain quantity or a certain ratio of the total amount.

IMPORTANT: the products are identified by the anti-fraud engine based on their product codes, which should be present both on the risky product list and in the transaction basket data. Concordance between the codes for these lists and for the basket is essential.

Shared lists

By default, a webshop has its own risky product lists (3 lists only). These lists are also called "private lists".

It is also possible to create lists shared by several webshops in order to manage a single set of risky products for the webshops in question. These are known as "shared lists".

A list can be shared at the commercial group level. 5 shared lists of risky products can be created then associated with the webshops. All the webshops associated with a given shared list can edit the items on the list. The items on the list are used for all the webshops that share it.

To set up a shared list, you should contact your account manager for configuration. This is done in two phases:

  • first create a shared list by selecting the type (e-mail address list, card number list, etc.) and colour (black, white or grey)
  • then link the shared list to the webshops

Webshops are linked to the shared list by using an existing shared list at the commercial group level in the setup screen for webshop product lists.

When the anti-fraud measures are executed, if the appropriate rule has been activated and it is configured to use the shared list, then the list will be used.

Risky product list

Rule description

This rule allows you to check whether there are risky products in the customer's basket.

The rule searches the risky product lists you defined, and configured in the rule, to check whether the customer's basket contains a product you consider to be potentially risky.

In the absence of a risky product list for the webshop or basket content for the request you send, the rule will return a neutral result.

Attention: this rule cannot be decisive, so that it does not block all the transactions of a webshop. The products included in the risky product list must be products you sell. This also applies to the products in the basket.

Conditions of use

If you would like to use this rule, you must:

  • activate the rule in the profile and select the list to be used via the fraud tab in the MEX
  • set at least one risky product list via the fraud tab in the MEX

  • and send the customer's basket content in the request, particularly the product code for each product in the basket ( ShoppingCartDetails field).

Expression of the result

Use case Complementary Code Rule result Rule DetailedInfo
At least one product in the basket is on a risky product list. 51 Negative --
Information unknown. -- Neutral
No products in the basket are on a risky product list. -- Neutral

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the RiskyProductList instruction.

  • POST example:
      fraudData.bypassCtrlList=RiskyProductList
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>RiskyProductList</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["RiskyProductList"]
}
    

Risky product quantity

Rule description

This rule allows you to restrict the quantity of products in the basket which are on one of your risky product lists.

The rule will analyse the basket contents and check that:

  • the quantity of a single product in the customer's basket included on one of these lists does not exceed the authorised limit configured in the rule
  • the total quantity of all the products in the customer's basket included on a single list of risky products does not exceed the authorised limit configured in the rule

In the absence of basket content in the request you send, the rule will return a neutral result.

Conditions of use

If you would like to use this rule, you must:

  • activate the rule in the profile and select the list to be used via the fraud tab in the MEX
  • set at least one risky product list via the fraud tab in the MEX

  • and send the customer's basket content in the request, particularly the product code and quantity of each product in the basket ( ShoppingCartDetails field).

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
At least one product in the basket is on a risky product list, in a quantity greater than the limit configured in the rule
and/or
the total quantity of products in the basket included on a risky product list is greater than the limit configured in the rule.
52 Negative MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY _PER_LIST=L:C:D*
Information unknown. -- Neutral --
Aucun produit du panier n’appartient à une liste de produits à risque
ou
Aucun produit du panier appartenant à une liste de produits à risque n’a une quantité supérieure au seuil paramétré dans la règle.
-- Neutral MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY _PER_LIST=L:C:D*

*L: concerned risky product list name

A: biggest quantity of a product in the basket, belonging to that risky product list

B: maximum allowed quantity of a single product in the basket, belonging to that risky product list

C : sum of the quantities of all the products in the basket, belonging to that risky product list

D: maximum allowed cumulative quantity of all products in the basket, belonging to that risky product list

Note: up to 3 risky product lists ca be configured for this rule. The MAX_QUANTITY_PER_RISKY_PRODUCT and MAX_QUANTITY_PER_LIST values are returned in the complementaryInfo field for each of these lists. It is therefore possible to have these values up to 3 times for this rule in the complementaryInfo field.

MAX_QUANTITY_PER_RISKY_PRODUCT=L1:A1:B1;MAX_QUANTITY_PER_LIST=L1:C1:D1; MAX_QUANTITY_PER_RISKY_PRODUCT=L2:A2:B2;MAX_QUANTITY_PER_LIST=L2:C2:D2; MAX_QUANTITY_PER_RISKY_PRODUCT=L3:A3:B3;MAX_QUANTITY_PER_LIST=L3:C3:D3

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the RiskyProductQuantity instruction.

  • POST example:
      fraudData.bypassCtrlList=RiskyProductQuantity
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>RiskyProductQuantity</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["RiskyProductQuantity"]
}
    

Risky product ratio

Rule description

This rule enables you to detect abnormal behaviour regarding the ratio between the amount of one or all of the products on a risky product list and the total amount of the customer's basket.

The rule will analyse the basket contents and check that:

  • the ratio between the total amount of a single product (quantity x unit price) in the basket included on a risky product list and the total basket amount does not exceed the authorised limit configured in the rule
  • the ratio between the total amount of all the products (quantity x unit price) in the basket included on a single risky product list and the total basket amount does not exceed the authorised limit configured in the rule

In the absence of basket content in the request you send, the rule will return a neutral result.

Conditions of use

If you would like to use this rule, you must:

  • activate the rule in the profile and select the list to be used via the fraud tab in the MEX
  • set at least one risky product list via the fraud tab in the MEX

  • and send the customer's basket content in the request, particularly the product code, unit price and quantity of each product in the basket ( ShoppingCartDetails field).

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
The highest ratio between the total amount for at least one product on a risky product list and the total basket amount is higher than the limit configured in the rule
and/or
the ratio between the total amount for all the products on a risky product list and the total basket amount is higher than the limit configured in the rule.
53 Negative MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*
Information unknown. -- Neutral --
No products in the basket are on a risky product list
or
the ratio between the total amount for products on a risky product list and the total basket amount is not higher than the limit configured in the rule and the ratio between the total amount of all the products included in this risky product list and the total basket amount does not exceed the limit configured in the rule
-- Neutral MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*

*L: concerned risky product list name.

A: biggest ratio between the total amount of a product in the basket, belonging to that risky product list, and the total amount of the basket.

B: maximum allowed ratio between the total amount of a product in the basket, belonging to that risky product list, and the total amount of the basket.

C: biggest ratio between the total amount of the quantities of all the products in the basket, belonging to that risky product list, and the total amount of the basket.

D: maximum allowed ratio between the total amount of the quantities of all the products in the basket, belonging to that risky product list, and the total amount of the basket.

Note: up to 3 risky product lists can be used for this rule. The MAX_RATIO_PER_RISKY_PRODUCT and MAX_QUANTITY_PER_LIST values are returned to the scoreInfo field for each of these lists. It is therefore possible to have these values up to 3 times in the scoreInfo field.

MAX_RATIO_PER_RISKY_PRODUCT=L1:A1:B1;MAX_RATIO_PER_LIST=L1:C1:D1; MAX_RATIO_PER_RISKY_PRODUCT=L2:A2:B2;MAX_RATIO_PER_LIST=L2:C2:D2; MAX_RATIO_PER_RISKY_PRODUCT=L3:A3:B3;MAX_RATIO_PER_LIST=L3:C3:D3

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the RiskyProductRatio instruction.

  • POST example:
      fraudData.bypassCtrlList=RiskyProductRatio
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>RiskyProductRatio</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["RiskyProductRatio"]
}
    

Product quantity

Rule description

This rule enables you to restrict the quantity of a single product in a customer's basket.

The rule will analyse the basket contents and check that the quantity of each product does not exceed the limit configured in the rule. This rule does not use risky product lists.

In the absence of basket content in the request you send, the rule will return a neutral result.

Conditions of use

If you would like to use this rule, you must:

  • activate the rule in the profile using the fraud tab in the MEX
  • and send the customer's basket content in the request, particularly the product code and quantity of each product in the basket ( ShoppingCartDetails field).

Expression of the result

Use case Complementary Code Rule result RuleDetailedInfo
At least one product in the basket is in a quantity greater than the limit configured in the rule. 54 Negative PRODUCTQUANTITY =A:B*
Information unknown. -- Neutral PRODUCTQUANTITY =XXX:B*
No product in the basket is in a quantity greater than the limit configured in the rule. -- Neutral PRODUCTQUANTITY =A:B*

* A: quantity of the first product found the quantity of which is above the threshold set in the rule.

B: maximum allowed quantity for all products in the basket.

Dynamic override

Dynamic override is not available for this rule.

Dynamic bypass

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxQuantityPerProduct instruction.

  • POST example:
      fraudData.bypassCtrlList=MaxQuantityPerProduct
    

  • SOAP example:
      <urn:fraudData>
     <urn:bypassCtrlList>MaxQuantityPerProduct</urn:bypassCtrlList>
</urn:fraudData>
    

  • JSON example:
      "fraudData": {
   "bypassCtrlList": ["MaxQuantityPerProduct"]
}
    

Configuring antifraud profiles with the MEX

This chapter describes the steps to follow to configure fraud risk management profiles on your portal.

Using the Fraud tab

Click on the Fraud tab to get access to the antifraud profile management tool homepage.

Attention: if a message indicates access rights issues, contact the support team to have the fraud risk management option activated on your webshop.

You can select the language of your choice (EN, FR) in the top-right corner.

Webshop list

The top-hand part of this page contains the list of webshops you have access to.

You can extend this section to select another webshop by clicking on the  icon.

Note: when a shop is selected, this part is automatically collapsed.

A data entry field at the top of this area makes it possible to filter webshops using all or part of their names or ID.

Click on one of the webshops to select it and display its profiles.

Main part

The menu at the top of this part enables you to access the features for administering the profiles and lists of the selected webshop.

Tip: at various places in the interface, you will be able to click on  buttons that will give you access to detailed information about the elements located next to them.
Attention: rights management

The actions you can take depend on the role(s) assigned to your MEX profile.

Pagination and multiple selection

Pagination

At several places of the interface, you may find tables the elements of which are shown across several pages when the content requires it. Buttons for navigating through the pages are then displayed.

Multiple selection

When list elements can be selected, a checkbox in the header of the list enables you to select or deselect all of them with a single click, including those that may be on other pages.

When multiple elements are selected, some buttons displayed at the bottom of the table make it possible to perform actions on the whole selection.

Administering antifraud profiles

Click on Manage shop profiles in the menu bar to access this section.

Profile list

The homepage of this section provides an overview of the webshop profiles in the form of a list.

If you have subscribed to the option to use the antifraud controls before the authentication, then a tab bar allows you to switch between the before authentication profile list and before authorisation profile list:

The Live status column shows whether the profile is active or not.
profile is inactive profile is active

The live status of a profile is inactive:

  • if the profile has never been published
  • if the profile has been deactivated manually
  • or if the profile has been automatically deactivated by the activation of another profile that conflicts with the associated means of payment.
Tip: active default profile

For the distributor's profile not to be used, it is preferable to always have an active default profile.

The Draft status column shows whether the profile is active or not:
Status Publication status
The profile has been created but never published.
The profile has been published and is used to evaluate transactions if it is active (see above).
The profile has been modified since it was last published. It must be republished for the changes to be taken into account for transaction evaluation.
Important : this does not affect the functioning of the published version of the profile, which continues working the same way as before.
Attention: working version and published version

A profile consists of two entities: a working version and a published version.

The work version is one that you can modify and save as much as you like without any effects on the webshop transactions. It can be considered as a profile draft. When a new profile is created, it is actually a working version.

Once you are satisfied with the changes made to the working version, you can publish it to create the published version. This version of the profile is used to evaluate transactions.

A profile must therefore be both active and published in order to be applied. An active profile with a status "To be republished" status will not apply.

The Payment means column shows the means of payment associated with a profile.

Profiles can be customised for specific means of payment. This column summarises them.

The means of payment over a coloured background are those associated with the published version of the profile.

The means of payment over a grey background are those that are only present in the working version, and which are thus inactive for transaction evaluation.

In the following example, Mastercard and Visa are associated with the published profile and  CB is only in the working version:

You can click on the blue column header to sort the list according to the criterion.

Clicking on a profile of the list enables you to view and edit the details of its configuration.

Profile life cycle

Example of a profile life cycle:

Creating a profile

Click on the button to create a new profile. The creation options are as follows:

  • Go-No-Go profile

    If this option is authorised by the distributor, select the Go-No-Go profile option in the Create profile menu-button list. You will be given access to the new profile creation page.

or

  • Select Copy existing to create a new profile from a profile already existing in the webshop. A new window will pop up and let you choose the profile to be copied.

    Having chosen the profile to be copied, you will get access to the profile creation page.

or

  • From a profile template

    As with copying an existing profile, a popup window allows you to choose, from a list of available profile templates, the one that will serve as the basis for the new profile created.

You will then be taken to the profile creation page:

  • Profile name:

    The profile name must be unique for a given webshop and can consist of a maximum of 30 characters among the following: A-Z, a-z, 0-9, _ (underscore) and space.

  • Means of payment:

    You can choose whether the profile must apply to one or more specific means of payment. Check the boxes of the required means of payment. The list of the available means of payment depends on the contracts that are active on the webshop and configured in the MEX .

    Tip: default profiles

    If the profile must apply to all means of payment, it is a default profile; therefore, there is no need to check anything.

    The fact that a means of payment of the list is greyed out and tagged indicates that it is already selected in another profile. You can still check it if you wish. It will then be removed from the other profile. A warning message is displayed to remind you of this when you check the means of payment:

    Attention: only one profile for a given means of payment

    Only one active profile can be associated with a given means of payment. The configuration interface guarantees this by automatically deleting the means of payment from the other profiles if there is a conflict with a newly edited profile. At the time of its publication, this profile will be fully associated with the means of payment concerned.

  • Count refused transactions in velocity rules

    Check this option to account for refused transactions in the counters (in addition to accepted transactions).

  • Parameters currency

    If a webshop has contracts that involve means of payment in multiple currencies, you can choose, in the details of a rule, the currency that is used to set amounts.

    IMPORTANT: all transactions can be evaluated by a profile regardless of their respective currencies. Indeed, this parameter does not mean in any way that the profile only applies to the transactions the amounts of which are given in the chosen currency.

    If the transaction uses a currency other than the one configured in the profile, currency conversion is performed.

  • Profile rules

    The Manage rules section in the creation profile page enables you to choose the rules that must be applied as part of the profile. See the 'Administering rules in profiles' section for further details.

The profile is saved when the user clicks on the button. At this moment, the profile is not active yet. It will have to be published (see the 'Editing and publishing a profile' section).

The button makes it possible to cancel the creation of the profile and to go back to the webshop profile list.

Editing and publishing a profile

The profile editing page is almost identical to the creation page. In editing mode, the name of the profile cannot be modified.

  • Profile status

    A section on the right-hand side of the page provides details about the status of the profile:

    This section includes the status (see the 'Profile list' section), the publication date and the settings currency. The modification date corresponds to the date on which the work version was saved for the last time.

  • Actions available in editing mode
    Action Description
    Saves the changes made to the working version. This operation does not publish the changes. For this purpose, you will have to use the "Publish" button.
    Restore a profile the working version of which has been modified, in the state it was in the last time it was published.
    This action is only available if the profile has been published and has been modified ever since (its status is then "To be republished" .).
    Deletes an unpublished profile.
    This action can no longer be accessed from this page if the profile has been published. You will have to view the published version of the profile to delete it.
    Publishes the working version of the profile, which is then in effect for transaction evaluation. The orange colour indicates that this action may have consequences on the webshop transactions.

    Click on to be taken back to the profile list.

    Click on to view the published version of the profile if need be.

Viewing a published profile

From the profile editing page, you can view the published version using the button.

The following page displays:

This screen lets you view the details of the published profile and its rules.

  • Actions that can be performed on a published profile
    Action Description
    Activates the inactive published profile.
    This profile will then be in effect for transaction evaluation.
    Deactivates the inactive published profile.
    This profile will then no longer be in effect for transaction evaluation.
    Deletes a published profile.

    The orange colour indicates that this action may have consequences on the webshop transactions.

    The button takes you back to the working version of the profile.

Activating/deactivating a profile

To activate or deactivate a published profile , you must go to the page where you can view its published version:

  • choose the profile to activate or deactivate in the webshop's profile list
  • then click on in the profile details
  • you will then have access to the or button depending on the profile's activation status.

To activate an unpublished profile , you only need to publish it.

Deleting a profile

To delete a published profile, like for activation and deactivation, you must go to the page where you can view the published version of the profile (see the 'Activating/deactivating a profile' section).

You will then be able to delete it using the  button.

To delete an unpublished profile, access its working version (see the 'Editing and publishing a profile' section) then click on the  button.

Administering rules in profiles

Adding or deleting a rule

The button on the profile working version screen (see the 'Editing and publishing a profile' section), displays a pop-up window that makes it possible to activate rules in decisive or informational mode, or to deactivate them:

When you are done with the selection, click on Ok to validate your choices.

Note: please refer to the 'List of rules' section for further details.

Ordering and configuring rules

When clicking on the profile rules, you will see buttons that make it possible to perform actions on them.

  • Available actions:
    Action Description
    These buttons make it possible to order the execution of rules.
    This button makes it possible to modify the content of configurable rules if need be.
    Click on this button to delete a rule from the profile without using the rule selection pop-up window.
    This button makes it possible to convert an informational rule into a decisive one.
    This button makes it possible to convert a decisive rule into a informational one.

Please refer to the next sections for detailed rule configuration.

Filtering rules per means of payment

Some rules are related to a given means of payment (ex: SDD) or means of payment type (ex: cards). For instance, the card velocity can only be applied for payment cards (CB, VISA, MASTERCARD, AMEX) and the IBAN velocity can only be applied to a SDD payment.

When configuring the profile, the displayed rules are filtered according to the means of payment to which you subscribed. So if you did not subscribe to a given means of payment or means of payment type, you will not be able to use the rules restricted to it.

When a rule only applies to a means of payment (type), a label is dispayed next to it:

Configuring geolocation rules: addresses and countries

Card country

This section makes it possible to configure the list of the countries that the rule authorises or prohibits. This list can be displayed across several pages. The Result field corresponds to the result of the rule for the concerned country.

The Status radio buttons make it possible to specify whether the list that follows is a list of authorised or prohibited countries.

The Card country field makes it possible to add a country to the list by manually entering its name into the field (autocompletion is possible).

The button displays a pop-up window that makes it possible to select one or more countries from a list:

When manual data entry is in progress, the list is filtered accordingly, which makes it possible to see whether the country being entered is already on the list:

The allows switching the rule to the advanced configuration mode. This mode gives the possibility to encourage or discourage countries involving respectively a positive or negative result:

You can export the list into a CSV file by clicking on the button. This creates a file which contains all the items of the list and is automatically downloaded via browser.

For more details on the CSV file contents, please refer to the following section: 'Appendix 11: list export file format'.

IP and card country

This section makes it possible to configure the list of the country combinations that the rule authorises or prohibits. The Result fied corresponds to the result of the rule for the concerned country.

The Status radio buttons make it possible to specify whether the list that follows is a list of authorised or prohibited country combinations.

The IP address country field makes it possible to manually enter the IP address country of the combination to add to the list.

You can specify a list of IP addresses right away using the selection pop-up window. This window is accessible through the  button on the right-hand side of the data entry area. In this case, once the list is selected, "country list" is displayed in the data entry area.

The Card country field makes it possible to specify the card country of the combination to add to the list; it works in the same way as the IP address country field.

After entering the data either manually or through the pop-up window, you must click on the  button to add the selected country combinations to the list.

Alternatively, clicking on the  button makes it possible to add the combinations and their reverse orders to the list. For instance, for the IP address country = France and Card country = Belgium, this button will add France/Belgium and Belgium/France to the combination list.

When manual data entry is in progress, the list is filtered accordingly, which makes it possible to see whether the combination being entered is already on the list. This list can be displayed across several pages.

The Activate advanced mode button allows switching the rule to the advanced configuration mode. This mode gives the possibility to encourage or discourage countries involving respectively a positive or negative result.

You can export the list into a CSV file by clicking on the  button. This creates a file which contains all the items of the list and is automatically downloaded via your browser.

For more details on the CSV file contents, please refer to the following section: 'Appendix 11: list export file format'.

Other rules

The configuration is done in the same way for many rules:

You would like to configure the following rule: Please refer to the settings of the following rule:
  • Delivery and card country
  • Billing and card country
  • Delivery and IBAN country
  • Phone number and IBAN country
  • IP address and IBAN country
IP and card country
  • IP address country
  • IBAN country
Card country
  • Delivery and billing country
This rule requires no specific configuration.
  • Delivery and billing postal code
This rule requires no specific configuration, but you cannot add it without (or position it before) the rule for checking the delivery and billing countries.

Configuring velocity rules

Card velocity

The Period fields make it possible to specify the periods over which the number of transactions and the amount of transactions are added up for the card concerned. You can specify these times in hours, days or weeks using the  buttons.

The Maximum number of transactions field makes it possible to specify the maximum number of transactions authorised over the period.

The Maximum cumulated amount field makes it possible to specify the maximum cumulative amount of the transactions over the period. The currency in which the cumulative amount is given is indicated in front of this field.

It is not mandatory to specify both a maximum cumulative amount and a maximum number of transactions. One of the two is enough.

Similarly, it is not mandatory to set the maximum number of transactions and the maximum cumulative amount. The setting of one of the two is enough.

Number of customers per card

The Period field makes it possible to specify the period over which customers are counted for the card concerned. This time can be specified in hours, days or weeks using the  button.

Shared velocity

If the distributor's offering supports shared velocity, an icon on the right of the velocity rule name informs whether the velocity is shared with other webshops or is private:

shows that the velocity is shared.

shows that the velocity is private.

Move the cursor over an icon to get more information:

Other rules

The configuration is done in the same way for many rules:

You would like to configure the following rule: Please refer to the settings of the following rule:
  • IP address velocity
  • Customer ID velocity
  • Mandate velocity
  • IBAN velocity
Card velocity
  • Number of cards per customer
  • Number of cards per IP address
  • Number of IBANs per IP address
  • Number of IP addresses per IBAN
  • Number of customers per IBAN
  • Number of IBANs per customer
  • Number of mandates per IP address
Number of customers per card

Configuring miscellaneous rules

IP address reputations

You can update the Non-allowed statuses list using:

  • to add the selected element from the Allowed statuses list to the Non-allowed statuses list
  • or to remove the selected element from the Non-allowed statuses list.

For further details about IP reputations please refer to the 'Appendix 3: IP address reputations' section.

Cap collar amounts

The Minimum amount field makes it possible to specify the authorised minimum amount for a transaction. The currency in which the minimum amount is given is indicated in front of this field.

The Maximum amount field makes it possible to specify the authorised maximum amount for a transaction.

The Activate advanced mode field allows to switch the rule to the advanced configuration mode. This mode gives the possibility to encourage or discourage amount ranges involving respectively a positive or negative result. The result is neutral if the amount is not in one of both ranges.

Free E-mail address

The Domain name field allows typing a web domain name to add it to the forbidden web domain name list.

In the example above, hotmail.com is added to the list, which means that the E-mail addresses ending by @hotmail.com will be forbidden.

It’s possible to use an asterisk for the last part of the domain name to take into account all the possibilities. For example, adding hotmail.* to the list will refuse all the addresses ending by @hotmail.com, @hotmail.fr, @hotmail.be , etc.

3-D Secure authentication

The Non-allowed status list is updated in the same manner as for the IP address reputation list.

This list only shows the 3-D Secure statuses that risk evaluation functions can filter. Notably, the CANCEL or BYPASS statuses are not on it. The distributor may impose 3-D Secure status acceptance rules upstream of fraud risk management checks. Therefore, some transactions having certain statuses of this list might be interrupted even before a fraud risk management check can be performed. For further details about 3-D Secure statuses, please refer to 'Appendix 5: 3-D Secure authentication statuses'.

The Activate advanced mode button allows to switch the rule to the advanced configuration mode. This mode gives the possibility to encourage or discourage 3-D Secure status involving respectively a positive or negative result. It is possible to have a neutral result if the status is in the Allowed status list.

Card expiry date

The Period field makes it possible to specify the number of months before the card expires and below which the transaction will be refused.

Other rules

The configuration is done in the same way for many rules:

You would like to configure the following rule: Please refer to the settings of the following rule:
  • Commercial card (and card country)
Card country
However, please keep in mind that the Commercial card (and card country) rule is not eligible for the advanced configuration mode.
  • Address verification (InfoScore)
3-D Secure authentication
  • Lost and stolen cards (CB scheme cards)
  • Virtual card
  • Systematic authorisation card
  • CB scheme card
  • E-mail address syntax
  • Vérification de compte (InfoScore)
These rules require no specific configuration.

Configuring list rules

Populating lists

List rules require no specific configuration.

However, activating a list rule in a profile is not sufficient; you must also manage the list itself. To do so, three options exist:

  • adding elements in the list using Sips Office Batch   or
  • adding elements in the list using Sips Office SOAP or JSON  or
  • using the Lists feeding tab.

Note: the options using Sips Office SOAP, Sips Office JSON or Sips Office Batch are described in their respective user guides. This guide only exlpains the option using the fraud risk management interface.

Follow the procedure below to populate lists using the MEX :

Click on the Lists feeding tab.

By accessing this section you gain access to the lists at your disposal: they vary according to the offer you have subscribed to. Please consult the list of rules for a complete list of existing list rules.

After choosing the relevant tab, you can choose to manage the greylist, blacklist or whitelist by clicking on the corresponding arrow on the right-hand side.:

When editing a list, you can:

  • add a value to the list and specify a reason for the addition
  • delete an entry from the list
  • or move an entry from a greylist to a blacklist

Adding a value to a list

You must enter the value you want to add to a list into the appropriate data field.

A click on the  button displays a contextual window that makes it possible to select a reason for adding the value.

Adding a value to the card numbers list

The management of card numbers on blacklists, greylists or whitelists is different from the management of other lists.

You can add a card number:

  • using the transaction reference linked to the card number
  • using the card number
  • using the card's token

After selecting the entry mode using a combobox, you will be able to enter a token, a card number or a transaction reference on the screen.

Adding card numbers by transaction reference can be done by using either transaction references ( WL Sips  2.0 primary key) or transaction identifiers and dates ( WL Sips  1.0 primary key).

Adding card numbers by token can only be done if you have the "Merchant Token" option.

Selecting a reason to add an item to a list

Having clicked on the  button, select the reason in the popup window then click on  OK , and the item will be added to the list.

Adding a reason may prove handy later (for example to add a given customer ID to a whitelist). The reasons can be chosen from predefined sets that suit each type of list. But you may also decide to keep the "Not specified" default version.

The reasons are displayed next to the items:

They are identical for greylists and blacklists. Here is a summary of these reasons:

List type Reasons for whitelists Reasons for blacklists and greylists
E-mail addresses
Unspecified
VIP
Trusted e-mail address
B2B customer
Unspecified
Fraud suspicion
Negative experience
Is on an external blacklist
General suspicion
Unknown e-mail address
Non-payment
Failed debit
Chargeback
Multiple payment attempts
IP addresses
Unspecified
VIP
B2B customer
Trusted IP address
Unspecified
Fraud suspicion
Negative experience
Is on an external blacklist
General suspicion
Unknown IP address
Non-payment
Failed debit
Chargeback
Multiple payment attempts
Postal codes
Unspecified
Positive experience
Unspecified
Fraud suspicion
Negative experience
Is on an external blacklist
Unknown postal code
General suspicion
Customer IDs
Unspecified
VIP
B2B customer
Trusted customer ID
Is part of a special action
Unspecified
Fraud suspicion
Negative experience
Is on an external blacklist
General suspicion
Non-payment
Failed debit
Chargeback
Multiple payment attempts
Names
Unspecified
VIP
B2B customer
Trusted name
Unspecified
Fraud suspicion
Negative experience
Is on an external blacklist
General suspicion
Non-payment
Failed debit
Chargeback
Multiple payment attempts
Card numbers
Unspecified
VIP
B2B customer
Trusted card
Travel key card
Unspecified
Fraud suspicion
Negative experience
Is on an external blacklist
Lost card
Stolen card
Unknown card
Prohibited card
Non-payment
Failed debit
Chargeback
Multiple payment attempts
Phone numbers
Unspecified
VIP
B2B customer
Trusted phone number
Unspecified
Fraud suspicion
Negative experience
Is on an external blacklist
General suspicion
Unknown phone number
Non-payment
Failed debit
Chargeback
Multiple payment attempts
BIN ranges
Unspecified
Trusted BIN range
Unspecified
Fraud suspicion
Negative experience
Is on an external blacklist
General suspicion
BIC
Unspecified
Unspecified
Fraud suspicion
Negative experience
Is on an external blacklist
General suspicion
IBAN
Unspecified
VIP
B2B customer
Trusted IBAN
Unspecified
Fraud suspicion
Negative experience
Is on an external blacklist
General suspicion
Failed debit
Multiple payment attempts
Mandates
Unspecified
VIP
B2B customer
Trusted mandate ID
Unspecified
Fraud suspicion
Negative experience
Is on an external blacklist
General suspicion
Failed debit
Multiple payment attempts

Exporting a list

You can export a list into a CSV file by clicking on the  button. This creates a file which contains all the items of the list and is automatically downloaded via browser.This creates a file which contains all the items of the list and is automatically downloaded via your browser.

For more details on the CSV file contents, please refer to 'Appendix 11: list export file format'.

Deleting a value from the list

It is also possible to delete items from the list, e.g. if they are not valid any more or were added by mistake:

  • select one or more values to delete from the list by checking the boxes next to the appropriate items
  • then click on the Delete selected entries button.

To avoid deleting an item by mistake, you must click on Confirm in the confirmation window.

Moving a value

Every greylist offers the possibility to move a selected entry to the appropriate blacklist e.g. if the severity of a case increases. This spares you the effort to delete an appropriate entry from the greylist and to re-enter it on the blacklist. The procedure is as follows:

  • select one or more values to move from the greylist to the appropriate blacklist by checking the boxes next to the required items
  • then move them using the Move selected item to the blacklist button.

To avoid deleting an item by mistake, you must click on Yes in the confirmation window.

Attention: a value can only be on one list. For instance, the same item cannot be added to a greylist and a blacklist.

Shared lists

If the distributor's offering supports shared lists then a webshop can share a list with other webshops belonging to the same commercial group. It is still possible to have a private list used by only one webshop.

  • Configuring the profiles

When you configure a profile, icons to the right of the rule names tell you if the list is shared with other webshops or if it is private:

indicates that the list is shared.

indicates that the list is private.

Move your cursor above an icon to get additional information:

  • The lists themselves

A webshop can share its elements with other webshops belonging to the same commercial group. It is still possible to have a private list only used by one webshop.

You can check, above the form used to add a new item to the list, if a list is private or shared:

indicates that the list is shared.

indicates that the list is private.

When the selected webshop shares a list, the list management is the same as explained in the previous sections of this chapter. The only difference is that a webshop can only remove an item it has added itself before. It is not possible to delete an item added by another webshop.

The webshop that has added the element in the Shop ID column. This column is visible only if the list is shared:

A system of “lock” allows many webshops to add the same item in the list. Each webshop adding an item adds a lock on this item. If at least one lock exists on this item, it is in the list. The item is considered to be out of the list when each lock on the same item is removed by the webshops that have added them.

Sizeable lists

When a white, grey or black list becomes too large, the list items displayed in the interface are limited to the first 600 items found.

In this case, an warning message is displayed above the list and a search feature is activated to allow you to find items in the list that are not displayed in the interface:

If you select Add item , the form allows you to add new items to the list (please refer to the 'Adding a value to a list' and 'Adding a value to the card numbers list' sections).

If you select Search item(s) , the form allows searching using a given value (specific search) or using a partial one (filter). When clicking on the  button, the list is refreshed according to the result of the search:

Specific item search

Filtering of the list

After one or several successive searches, the  button allows restoring the list to its initial state, displaying the first 600 items.

Configuring basket rules

Managing risky product lists

Risky product lists are managed from the Risky product lists tab.

You are taken to the risky product list management page:

This page includes all the risky product lists already created.

Click on to edit a list or on to delete it.

Creating a list

Click on to create a new risky product list.

After clicking on this button, you have two options:

  • Create a new list

Enter the name of the new list then click on  OK .

or

  • Use a shared list

To use a shared list, just choose the list you want from the drop-down menu.

The lists chosen and/or created will then be visible on the risky product management page, where each list can be edited, as well as the profile configuration page, so that you can select them.

Exporting/importing a list

You can export the list in Excel (.CSV) format by clicking on the  button. The generated file contains all the products of the list and is automatically downloaded by your browser.

You can also import a list (in .CSV format) by clicking on the  button. Once the import has been completed, the list contains all of the products included in the imported file. The items previously in the list and not in the imported file are deleted.

For more details on the CSV file contents, please read the following section: Appendix 11: list export file format.

Adding/updating/deleting a product

You can manually add a product to a list, using the button.

To add a product to a list, you must complete three fields:

  • product code
  • product label
  • validity date

IMPORTANT: the product code is the information used to find products in the basket. It is therefore very important to have concordance of codes between the product lists and the baskets of transactions.

Once these fields have been completed and validated, the product is added directly to the list of risky products.

Click on the  icon to update a product, or on the  icon to delete it.

Risky product list

This section enables the risky product list being used to be configured. The various lists shown in this section were created previously from the List feeding -> Risky product lists tab.

Tick the risky product lists you wish to use. Several lists can be used at the same time.

indicates that the list is shared.

indicates that the list is private.

Product quantity

You can set the maximum quantity of products in a basket by manually entering the desired quantity in the field below:

Risky product quantity

The various lists shown in this section were created previously from the Lists feeding -> Risky product lists tab.

Tick the lists to be used. Several lists can be used at the same time.

For each product list, you can define the maximum quantity per product and the maximum quantity of all products by manually entering these quantities in the two numeric fields displayed under each list:

indicates that the list is shared.

indicates that the list is private.

Risky product ratio

This rule is configured in the same way as the 'Risky product quantity' rule, with the exception of values entered as ratios and not quantities.

Sharing lists

The management page for shared risky product lists is as follows:

It contains the same functionalities as those presented in the 'Managing risky product lists' section: you can then use the lists created from this page by going to the risky product list management page.

History of actions on the interface

A log of the modifications made through the interface is displayed in the Histor y tab.

This section lists all the changes on your profiles and also the ones having an impact on your fraud configuration: publication of a template profile or the association to a shared group/list. Changes on the webshop’s lists (e-mail lists, name lists, etc.) are not logged.

Table of modifications

When you arrive on the modifications page, the table is not filtered and contains all the changes related to the webshop, from the most recent to the oldest.

On the top of the page, different criteria are displayed to filter the modification logs: a minimum date, a maximum date, a user name or a log type (merchant profile, template profile or association).

After clicking on the  button, the application reloads the table with the filtered data.

Each line in the table shows the date on which the action was performed, the user who performed the action, the modified entity and a brief description of the action.

Click on the  icon to compare the object state before and after the modification.

Details of the modifications

Merchant profile and profile template

After clicking on the  icon, a popup displays, showing a comparison between the profile before and after the changes. By default, only the modifications are displayed, but it is possible to show the unchanged values also by clicking the Show unchanged values (entire profile details) checkbox.

The comparison is made up of three parts:

  • general information about the profile: name, means of payment, currency
  • list of decisive rules
  • list of informative rules

Modification on a rule

A colour code is used for rule modification:

Colour Meaning
The rule name is in red and is preceded by the  symbol. The rule was removed from the profile.
The rule name is in green and is preceded by the  symbol. The rule was added to the profile.
The rule name is in orange and is preceded by the  symbol. The rule was moved in the profile, which means its mode has changed (from decisive to informative and vice versa) or that it is decisive and its execution rank has changed.
The rule name is in black . The rule content has changed.
The rule name is in grey . The rule has not changed (only visible when the proper checkbox is ticked).

For example:

Rule name and colour Meaning
The rule was not changed.
The rule was added in third position in the execution order.
The rule mode has changed from decisive to informative.
The rule has moved in the execution order from 2nd position to 1st position.
The rule mode has changed from decisive to informative with an execution order of 2.
The rule was removed.
The rule was not moved but its settings were changed.

Modification on a value

Colour codes are also applied on value modification:

Value Meaning
Value in green . New value.
Value in red and strikethrough text. Former value.
Value in black . Value unchanged.

In the case of a modification, the former value in red strikethrough text is followed by the new value in green.

Group/list association

After clicking on the  icon, a popup displays, showing the changes between the new group/list to which the eShop belongs and the former. So you will see the former in red strikethrough text and the new group in green  :

Appendices

Appendix 1: disabling some rules of the profile dynamically

If you wants to prevent the execution of a rule of your profile for a transaction, you can do so by sending the element that corresponds to the rule in the fraudData element of the payment request.

fraudData.bypass3DS Disables 3D authentication
fraudData.bypassCtrlList Disables standard rules
fraudData.bypassInfoList Deprecated

fraudData.bypass3DS

Value Description
ALL Bypasses the 3DS procedure (for CB, VISA, MASTERCARD and AMEX payments)
MERCHANTWALLET Bypasses the 3DS procedure during "1 Click" payment (for CB, VISA, MASTERCARD and AMEX payments)

fraudData.bypassCtrlList

Value Description
AccountVerification Disable the Account verification (InfoScore) rule
AddressVerification Disable the Address verification (InfoScore) rule
BlackBic Disable the BIC blacklist rule
BlackBinCard Disable the BIN range blacklist rule
BlackCard Disable the Card number blacklist rule
BlackCustomerId Disable the Customer ID blacklist rule
BlackCustomerName Disable the Customer name blacklist rule
BlackEmail Disable the E-mail address blackslit rule
BlackIban Disable the IBAN blacklist rule
BlackIp Disable the IP address blacklist rule
BlackMandate Disable the Mandate blacklist rule
BlackPhoneNumber Disable the Phone number blacklist rule
BlackPostalCode Disable the Postal code blacklist rule
CapCollarAmount Disable the Amount range rule
CardCountry
ForeignBinCard (deprecated)
Disable the Card country rule
CBScheme Disable the CB scheme card rule
CommercialCard
CorporateCard (deprecated)
Disable the Commercial card (and card country) rule
EmailSyntax Disable the E-mail address syntax rule
ECard Disable the Virtual card rule
ExpiryDate Disable the Card expiry date rule
FreeEmail Disable the Free e-mail address rule
GreyBic Disable the BIC greylist rule
GreyBinCard Disable the BIN range greylist rule
GreyCard Disable the Card number greylist rule
GreyCustomerId Disable the Customer ID greylist rule
GreyCustomerName Disable the Customer name greylist rule
GreyEmail Disable the E-mail address greylist rule
GreyIban Disable the IBAN greylist rule
GreyIp Disable the IP address greylist rule
GreyMandate Disable the Mandate greylist rule
GreyPhoneNumber Disable the Phone number greylist rule
GreyPostalCode Disable the postal code greylist rule
HotList Disable the Lost and stolen card rule
IbanCountry Disable the IBAN country rule
IpCountry Disable the IP address country rule
IpReputations Disable the IP address reputation rule
MaxCardPerCustomerId Disable the Number of cards per customer rule
MaxCardPerIp Disable the Number of cards per IP address rule
MaxCustidPerIban Disable the Number of customers per IBAN rule
MaxCustomerIdPerCard Disable the Number of customers per card rule
MaxIbanPerCustid Disable the Number of IBAN per customer rule
MaxIbanPerIp Disable the Number of IBAN per IP address rule
MaxCardPerIp Disable the Number of cards per IP address rule
MaxIpPerIban Disable the Number of IP address per IBAN rule
MaxMandatePerIp Disable the Number of mandates per IP address rule
MaxQuantityPerProduct Disable the Product quantity rule
RiskyProductList Disable the Risky product list rule
RiskyProductQuantity Disable the Risky product quantity rule
RiskyProductRatio Disable the Risky product ratio rule
SimilarityBillingCardCountry Disable the Delivery and card country rule
SimilarityDeliveryBillingCountry Disable the Delivery and billing country rule
SimilarityDeliveryBillingPostalCode Disable the delivery and billing postal code rule
SimilarityDeliveryCardCountry Disable the Delivery and card country rule
SimilarityDeliveryIbanCountry Disable the Delivery and IBAN country rule
SimilarityIpCardCountry
SimilityIpCard (deprecated)
Disable the IP and card country rule
SimilarityIpIbanCountry Disable the IBAN country rule
SimilarityPhoneIbanCountry Disable the Phone and IBAN country rule
SystematicAuthorizationCard Disable the Systematic authorisation card rule
VelocityCard Disable the Card velocity rule
VelocityCustomerId Disable the Customer ID velocity rule
VelocityIban Disable the IBAN velocity rule
VelocityIp Disable the IP address velocity rule
VelocityMandate Disable the Mandate velocity rule
WhiteBic Disable the BIC whitelist rule
WhiteBinCard Disable the BIN range whitelist rule
WhiteCard Disable the Card number whitelist rule
WhiteCustomerId Disable the Customer ID whitelist rule
WhiteCustomerName Disable the Customer name whitelist rule
WhiteEmail Disable the E-mail address whitelist rule
WhiteIban Disable the IBAN whitelist rule
WhiteBinCard Disable the BIN range whitelist rule
WhiteIp Disable the IP address whitelist rule
WhiteMandate Disable the Mandate whitelist rule
WhitePhoneNumber Disable the Phone number whitelist rule
WhitePostalCode Disable the Postal code whitelist rule
3DSStatus Disable the 3-D Secure authentication rule
All Disable all rules

Appendix 2: complementary codes

Values Rule Description
Empty No check performed.
00 All All the checks you have opted for have been performed successfully.
02 Card velocity Too many transactions/Excessive amount spent for the card used
03 Card number greylist The card used is on your "greylist".
06 Card country Simple mode: the country card associated with the card number is not in your list of authorised countries.
Advanced mode: the country card associated with the card number is on the list of disadvantaged countries or is on the list of advantaged countries.
07 Virtual card e-Card detected.
08 BIN range greylist The BIN of the card used is part of a range defined on your "greylist".
10 IP address country Simple mode: prohibited IP address country.
Advanced mode: advantaged or disadvantaged IP address country.
11 Lost and stolen card Lost and stolen card.
12 IP address and card country Simple mode: prohibited “Card country/IP address country” combination.
Advanced mode: disadvantaged or advantaged “Card country/IP address country” combination.
14 Systematic authorisation card Card with systematic authorisation.
16 IP address velocity Too many transactions from the IP address.
17 3-D Secure authentication Simple mode: transaction blocked due to the 3-D Secure authentication.
Advanced mode: transaction disadvantaged or advantaged due to the 3-D Secure authentication status.
18 Commercial card (and card country) The card number corresponds to a corporate card number.
19 CB scheme card The card number is not that of a card of the CB network.
20 Customer ID velocity Too many transactions from this customer
21 Number of customers per card Too many customers per card.
22 Number of cards per customer Too many cards per customer.
23 Card expiry date The card will expire soon.
25 Cap collar amounts Simple mode: the amount is outside of the set range.
Advanced mode: The amount is inside of the set range advantaged or inside of the set range disadvantaged.
26 Delivery and billing postal codes Prohibited “Delivery country/Billing country” combination.
27 Free e-mail address At least one of the e-mail addresses supplied is from a free e-mail address provider.
28 Customer ID blacklist The customer ID is on your "blacklist".
29 Customer ID greylist The customer ID is on your "greylist".
30 Delivery and billing country Prohibited “Delivery country/Billing country” combination.
31 E-mail address blacklist At least one of the e-mail addresses supplied is on your "blacklist".
32 E-mail address greylist At least one of the e-mail addresses supplied is on your "greylist".
33 Phone number blacklist At least one of the phone numbers supplied is on your "blacklist".
34 Phone number greylist At least one of the phone numbers supplied is on your "greylist".
35 Customer name blacklist At least one of the contact names supplied is on your "blacklist".
36 Customer name greylist At least one of the contact names supplied is on the merchant's "greylist".
37 IP address blacklist The buyer's IP address is on your "blacklist".
38 IP address greylist The buyer's IP address is on your "greylist".
39 Postal codes per country blacklist The "Country/Postal code" combination is on your "blacklist".
3L Authentication guarantee Transaction refused because it it not guaranteed by an entity (acquirer, wallet provider, etc.).
40 Postal codes per country greylist The "Country/Postal code" combination is on your "greylist".
41 BIN range greylist The BIN of the card used is part of a range defined on your "greylist".
42 Delivery and card country Simple mode: prohibited “Card country/Delivery country" combination.
Advanced mode: disadvantaged or advanted “Card country/Delivery country" combination.
43 Commercial card (and card country) The card number corresponds to a corporate card number, but the card issuing country does not correspond to a corporate card issuing country.
44 IP address reputations The customer's IP address is prohibited.
45 Number of cards per IP address The number of different cards for the same IP address has been exceeded.
46 E-mail address syntax The e-mail address supplied is formatted incorrectly.
47 Billing and card country Simple mode: prohibited “Card country/Billing country” combination.
Advanced mode: disadvantaged or advanted “Card country/Billing country" combination.
48 Address verification (InfoScore) Verification of the delivery address supplied. To date, address verifications only apply to ELV payments (InfoScore checks).
49 Account verification (InfoScore) Validation of the bank account supplied. To date, bank account verifications only apply to ELV payments (InfoScore checks).
50 Card number blacklist The card used is on your "blacklist".
51 Risky product list At least one product in the basket is on a risky product list.
52 Risky product quantity The quantity of risky products in the basket exceeds the allowed quantity.
53 Risky product ratio The ration of risky products/total amount of the basket exceeds the allowed ratio.
54 Product quantity The quantity of products in the basket exceeds the allowed quantity.
55 IBAN country Simple mode: the IBAN country code is not allowed.
Advanced mode: the IBAN country is disadvantaged or advantaged.
56 Delivery and IBAN country Simple mode: the delivery country and IBAN country combination is not allowed.
Advanced mode: the delivery country and IBAN country combination is disadvantaged or advantaged.
57 Phone number and IBAN country Simple mode: the phone number country and IBAN country combination is not allowed.
Advanced mode: the phone number country and IBAN country combination is disadvantaged or advantaged.
58 IP address and IBAN country Simple mode: the IP country and IBAN country combination is not allowed.
Advanced mode: the IP country and IBAN country combination is disadvantaged or advantaged.
59 Number of IBANs per IP address The number of IBANs per IP address exceeds the allowed threshold.
60 Number of IP addresses per IBAN The number of IP addresses per IBAN exceeds the allowed threshold.
61 Number of customers per IBAN The number of different customers per IBAN exceeds the allowed threshold.
62 Number of IBANs per customer The number of different IBANs per customer exceeds the allowed threshold.
63 Number of mandates per IP address The number of mandates per IP address exceeds the allowed threshold.
64 Mandate velocity Too many transactions/Excessive amount spent for the mandate used.
65 IBAN velocity Too many transactions/Excessive amount spent for the IBAN used.
66 BIC blacklist The BIC is in your "blacklist".
67 BIC greylist The BIC is in the your "greylist".
68 IBAN blacklist The IBAN is in your "blacklist".
69 IBAN greylist The IBAN is in your "greylist".
70 Mandate blacklist The mandate is in your "blacklist".
71 Mandate greylist The mandate is in your "greylist".
99 All the WL Sips server encountered an issue when processing one of the additional local checks.
AA Card number whitelist The card number is on your "whitelist".
AB Customer ID whitelist The customer ID is on your "whitelist".
AC E-mail address whitelist At least one of the e-mail addresses supplied is on your "whitelist".
AD Phone number whitelist At least one of the phone numbers supplied is on your "whitelist".
AE IP address whitelist The customer's IP address is on your "whitelist".
AF Customer name whitelist At least one of the contact names supplied is on your "whitelist".
AG Postal codes per country whitelist The "Country/Postal code" combination is on your "whitelist".
AH BIN range whitelist The BIN of the card used is part of a range defined on your "whitelist".
AI BIC whitelist The BIC is on your "whitelist".
AJ IBAN whitelist The customer's BIC is on your "whitelist".
AK Mandate whitelist The customer's SDD mandate is on your "whitelist".

Appendix 3: IP address reputations

An IP address can have one or more of these reputations if it has been recently involved in one of the following situations:

IP address used for: Description
Botnets Botnets are viruses that infect a large number of machines to:
  • relay spam for illegal trade or information manipulation (e.g. stock exchange rates)
  • carry out phishing operations
  • identify and infect other machines by spreading viruses and malware
  • take part in DDoS attacks
  • abusively generate false clicks on an ad link on a web page
  • capture information on compromised machines (i.e. stealing then reselling information)
  • exploit the calculation power of machines or perform distributed calculation operations, notably to break passwords
  • carry out out illegal trade operations by managing the access to sites that sell prohibited or counterfeit products, through fast-flux, simple or double-flux or RockPhish techniques.
Denial of service A “Denial of service” attack aims to make a service unavailable and prevent legitimate users from using it. It can consist in:
  • flooding a network to prevent it from working
  • disrupting connections between two machines, thus preventing access to a particular service
  • blocking access to a service for a person in particular
  • sending billions of bytes to an Internet set-top box
Phishing For fraudsters, phishing consists in obtaining confidential information (financial information, credentials for logging in to your company's system) through spam based on a fraudulent, malicious copy of a legitimate web page.
Anonymous proxies An anonymous proxy makes it possible to navigate anonymously. In general, it is a server that hides personal information (IP address, OS, browser) from the visited sites.
Scanners Scanners make it possible to know whether several machines have the same IP address because they are part of the same network.
Spam source Generally, it refers to the sending of massive quantities of e-mails for advertising purposes.
Web attacks Web application vulnerabilities can be classified as follows:
  • web server vulnerabilities. These are getting rarer and rarer because web server developers have reinforced security measures through the years
  • URL manipulation. This consists in manually modifying the parameters of URLs to modify the expected behaviour of web servers
  • exploting the weaknesses of session IDs and authentication mechanisms
  • injection of HTML code and Cross-Site Scripting
  • injection of SQL commands
Infected sources IP addresses that send HTTP requests with a low reputation index or that are known malicious sites.
Windows exploits IP addresses that have exploited security holes against Windows resources using browsers, programmes, downloaded files, scripts or operating system vulnerabilities

Appendix 4: ISO 3166 alphabetical country codes

ABW Aruba AFG Afghanistan AGO Angola
AIA Anguilla ALB Albania AND Andorra
ANT Netherlands Antilles ARE United Arab Emirates ARG Argentina
ARM Armenia ASM American Samoa ATA Antarctica
ATF The French Southern and Antarctic Lands ATG Antigua and Barbuda AUS Australia
AUT Austria AZE Azerbaijan BDI