WL SIPS DOCS

Release 24.6

go directly to content

Search by keywords

  1. Fraud
  2. Business Score solution
  3. Rules

Rules

To search in the page use Ctrl+F on your keyboard

This page lits the fraud rules available with our Business Score solution.

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 Negative V V V V V
IP address country CY Negative V V V V V
IP address and card country SI Negative V V V V V
Delivery and billing country SB Negative V V V
Delivery and billing postal codes ZC Negative V V V
Delivery and card country CS Negative V V V V V
Billing and card country CB Negative V V V V V
IBAN country AC Negative V V V V
Delivery and IBAN country DI Negative V V V V
Phone number and IBAN country PI Negative V V V V
IP address and IBAN country IS Negative V V V V
Card issuing country CP Negative V V V V V
Card issuing and billing country IB Negative V V V V V
Card issuing and delivery country ID Negative V V V V V
Card issuing and IP country IE Negative V 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 Negative V V V
IP address velocity VI Negative V V V
Customer ID velocity VC Negative V V V
Number of customers per card MD Negative V V V
Number of cards per customer MR Negative V V V
Number of cards per IP address CI Negative V V V
Number of IBANs per IP address II Negative V V
Number of IP addresses per IBAN IJ Negative V V
Number of customers per IBAN CJ Negative V V
Number of IBANs per customer IC Negative V V
Number of mandates per IP address MJ Negative V V
Mandate velocity EM Negative V V
IBAN velocity EI Negative 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 Negative V V V
Lost or stolen card OP Negative V V V
Virtual card EC Negative V V V
Systematic authorisation card SA Negative V V V
Commercial card (and card issuer country) CC Negative V V V V
Cap collar amount CA Negative V V V V
CB scheme card NC Negative V V V
Free e-mail address FE Negative V V V
3-D Secure authentication A3 Negative V V V
E-mail address syntax ES Negative V V V
Card expiry date PE Negative V V V
Commercial card (and card issuing country) KI Negative V 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 Negative V V V
Greylist GY Negative V V V
Whitelist WY Positive V V V
Postal codes per country Blacklist BZ Negative V V V
Greylist GZ Negative V V V
Whitelist WZ Positive V V V
E-mail addresses Blacklist BM Negative V V V
Greylist GM Negative V V V
Whitelist WM Positive V V V
Customer IDs Blacklist BI Negative V V V
Greylist GI Negative V V V
Whitelist WI Positive V V V
Customer names Blacklist BN Negative V V V
Greylist GN Negative V V V
Whitelist WN Positive V V V
Card numbers Blacklist BC Negative V V V
Greylist GC Negative V V V
Whitelist WC Positive V V V
Phone numbers Blacklist BP Negative V V V
Greylist GP Negative V V V
Whitelist WP Positive V V V
BIN ranges Blacklist BB Negative V V V
Greylist BR Negative V V V
Whitelist WB Positive V V V
BIC list Blacklist BE Negative V V
Greylist GE Negative V V
Whitelist WE Positive V V
IBAN list Blacklist BA Negative V V
Greylist GA Negative V V
Whitelist WA Positive V V
Mandate list Blacklist TB Negative V V
Greylist TG Negative V V
Whitelist TW Positive 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 Negative V V V
Risky product quantity PQ Negative V V V
Risky product ratio PR Negative V V V
Product quantity QP Negative V V V

Geolocation rules: address and country

Attention: 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 issuer country

Rule description

The card issuer country rule enables you to decide whether to accept or decline to provide a service depending on the issuer country (country of the bank that issued the card).

The rule queries a BIN range database to check whether the country 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 issuer 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 influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative 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 issuer card" rule.

Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CR;N;NOT_APPLICABLE NOT_APPLICABLE
The card country is unknown. 0 CR;N;
CARD_COUNTRY=XXX*
 CARD_COUNTRY=XXX*
The card country is on the list of prohibited countries, is not on the list of authorised countries, or is the same as the merchant's country. 0 to -4 depending on settings
The card country is on the list of authorised countries, is not on the list of prohibited countries, or differs from the merchant's country. 0

* XXX: ISO 3166 alphabetical country code (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CR;N;NOT_APPLICABLE NOT_APPLICABLE
The card country is unknown. 0 CR;N;
CARD_COUNTRY=XXX*
 CARD_COUNTRY=XXX*
The card country is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings
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 not on the list of “non-advantaged countries”. 0
The card country is on the list of “advantaged countries” or is not on the list of “non-advantaged countries” or is the same as the merchant's country. 0 to +4 depending on settings

* XXX: ISO 3166 alphabetical country code (see countryList field in the data dictionary)

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
fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=allowedCardCountryList,riskManagementDynamicValue=FRA,BEL,GBR}         
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedCardCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"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
fraudData.allowedCardCountryList=FRA,BEL,GBR
<urn:fraudData>
     <urn:allowedCardCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>
"fraudData": {
   "allowedCardCountryList": ["FRA", "BEL", "GBR"]
}

For both methods, the list sent must contain:

  • either the ISO 3166 alphabetic country codes (see field countryList in the data dictionary) separated by commas
  • or a list of preset country codes (see field areaList in the data dictionary).

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.

fraudData.bypassCtrlList=ForeignBinCard
<urn:fraudData>
     <urn:bypassCtrlList>ForeignBinCard</urn:bypassCtrlList>
</urn:fraudData>
"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 influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list. A same country can be found only in either list.
Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
The IP address country is unknown. 0 CY;N;IP_COUNTRY=XXX IP_COUNTRY=XXX
The IP address country is on the list of prohibited countries or is not on the list of authorised countries. 0 to -4 depending on settings CY;N;IP_COUNTRY=XXX* IP_COUNTRY=XXX*
The IP address country is on the list of authorised countries or is not on the list of prohibited countries. 0

* XXX: ISO 3166 alphabetical country code (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue Scoreinfo RuleDetailedInfo
The IP address country is unknown. 0 CY;N;IP_COUNTRY=XXX IP_COUNTRY=XXX
The IP address country is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings CY;N;IP_COUNTRY=XXX* 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 not on the list of “non-advantaged countries”. 0
The IP address country is on the list of “ advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

* XXX: ISO 3166 alphabetical country code (see countryList field in the data dictionary)

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

Examples:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedIpCountryList,riskManagementDynamicValue=FRA,BEL,GBR}            
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedIpCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"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

Examples:

fraudData.allowedIpCountryList=FRA,BEL,GBR
<urn:fraudData>
     <urn:allowedIpCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>
"fraudData": {
   "allowedIpCountryList": ["FRA", "BEL", "GBR"]
}

For both methods, the list sent must contain:

  • either the ISO 3166 alphabetic country codes (see countryList in the data dictionary) separated by commas
  • or a list of preset country codes (see field areaList in the data dictionary)

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.

Examples:

fraudData.bypassCtrlList=IpCountry
<urn:fraudData>
     <urn:bypassCtrlList>IpCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["IpCountry"]
}

IP and card issuer 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 issuer 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 issuer 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 issuer 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 influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list. A same pair of countries can be found only in either list.
Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 SI;N;NOT_APPLICABLE NOT_APPLICABLE
The card country and/or IP address country is/are unknown. 0 SI;N;
CARD_COUNTRY=XXX;
IP_COUNTRY=YYY*
 CARD_COUNTRY=XXX* ; IP_COUNTRY=YYY*
The “card country/IP address country” combination is prohibited. 0 to -4 depending on settings
The “card country/IP address country” combination is authorised. 0

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 SI;N;NOT_APPLICABLE NOT_APPLICABLE
The card country and/or IP address country is/are unknown. 0 SI;N;
CARD_COUNTRY=XXX;
IP_COUNTRY=YYY*
 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”. 0 to -4 depending on settings
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”. 0
The “card country/IP address country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

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 issuer country combinations
    • DeniedIpCardCountryCombiList for the prohibited IP and card issuer 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

Examples:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedIpCardCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }           
<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>
"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 countryList in the data dictionary)
  • or a list of preset country codes (see areaList in the data dictionary)

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.

Examples:

fraudData.bypassCtrlList=SimilityIpCard
<urn:fraudData>
     <urn:bypassCtrlList>SimilityIpCard</urn:bypassCtrlList>
</urn:fraudData>
"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 ScoreValue ScoreInfo RuleDetailedInfo
The delivery country does not match the billing country. 0 to -4 depending on settings SB;N;
SHIP_COUNTRY=XXX*;
BILL_COUNTRY=YYY*
 SHIP_COUNTRY=XXX*; BILL_COUNTRY=YYY*
The delivery country matches the billing country. 0
The countries are unknown. 0

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

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.

Examples:

fraudData.bypassCtrlList=SimilarityDeliveryBillingCountry          
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryBillingCountry</urn:bypassCtrlList>
</urn:fraudData>
"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 ScoreValue ScoreInfo RuleDetailedInfo
The delivery postal code does not match the billing postal code. 0 à -4 selon paramétrage ZC;N;
SHIP_COUNTRY=XXX;
BILL_COUNTRY=YYY;
SHIP_ZIP=A;
BILL_ZIP=B*
 SHIP_COUNTRY=XXX*; BILL_COUNTRY=YYY*;
SHIP_ZIP=A*;
BILL_ZIP=B*
The delivery postal code matches the billing postal code. 0
The postal codes are unknown. 0

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

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.

Examples:

fraudData.bypassCtrlList=SimilarityDeliveryBillingPostalCode
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryBillingPostalCode</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryBillingPostalCode"]
}

Delivery and card issuer country

Rule description

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

First, the rule queries the BIN range database to determine the card issuer country. Then, the rule checks whether the combination formed by the newly determined card issuer 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 issuer 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 issuer 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 influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list. A same pair of countries can be found only in either list.
Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CS;N;NOT_APPLICABLE NOT_APPLICABLE
The “Card country/Delivery country” combination is prohibited. 0 to -4 depending on settings CS;N;
SHIP_COUNTRY=XXX*;
CARD_COUNTRY=YYY*		 SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The “Card country/Delivery country” combination is authorised. 0
The card country or delivery country are unknown. 0

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CS;N;NOT_APPLICABLE NOT_APPLICABLE
The “card country/ delivery country” combination is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries” 0 to -4 depending on settings CS;N;
SHIP_COUNTRY=XXX*;
CARD_COUNTRY=YYY*		 SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The “card country/ delivery 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” 0
The card country or delivery country are unknown. 0
The “card country/ card country/ delivery country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries” 0 to +4 depending on settings

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

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

Examples:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedDeliveryCardCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}         
<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>
"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 countryList in the data dictionary)
  • or a list of preset country codes (see areaList in the data dictionary)

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.

Examples:

fraudData.bypassCtrlList=SimilarityDeliveryCardCountry
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryCardCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityDeliveryCardCountry"]
}

Billing and card issuer country

Rule description

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

First, this rule queries the BIN range database to determine the card issuer country. Then, the rule checks whether the combination formed by the newly determined card issuer 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 issuer 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 issuer country in the request (deliveryAddress.country field)

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

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CS;N;NOT_APPLICABLE NOT_APPLICABLE
The “Card country/Billing country” combination is prohibited. 0 to -4 depending on settings CS;N;
BILL_COUNTRY=XXX*;
CARD_COUNTRY=YYY*
 BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The “Card country/Billing country” combination is authorised. 0
The card country or billing country are unknown. 0

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CS;N;NOT_APPLICABLE NOT_APPLICABLE
The “card country/ billing country” combination is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings CS;N;
BILL_COUNTRY=XXX*;
CARD_COUNTRY=YYY*
 BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The “card country/ billing 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”. 0
The card country or billing country are unknown. 0
The “card country/ billing country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

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

Examples:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedBillingCardCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}          
<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>
"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 countryList in the data dictionary)
  • or a list of preset country codes (see areaList in the data dictionary)

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.

Examples:

fraudData.bypassCtrlList=SimilarityBillingCardCountry
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityBillingCardCountry</urn:bypassCtrlList>
</urn:fraudData>
"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 influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list. A same country can be found only in either list.
Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 AC;N;NOT_APPLICABLE NOT_APPLICABLE
The IBAN country is in the list of prohibited countries or is not on the list of authorised countries or is different from your country. 0 to -4 depending on settings AC;N;
IBAN_COUNTRY=XXX*
 IBAN_COUNTRY=XXX*
The IBAN country is on the list of authorised countries or is not on the list of prohibited countries or is equivalent to your country. 0

* XXX: ISO 3166 alphabetical country code (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 AC;N;NOT_APPLICABLE NOT_APPLICABLE
The IBAN country is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings AC;N;
IBAN_COUNTRY=XXX*
 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 not on the list of “non-advantaged countries”. 0
The IBAN country is on the list of “advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

* XXX: ISO 3166 alphabetical country code (see countryList field in the data dictionary)

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

Examples:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedIbanCountryList,riskManagementDynamicValue=FRA,BEL,GBR}         
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedIbanCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"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 countryList in the data dictionary)
  • or a list of preset country codes (see areaList in the data dictionary)

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.

Examples:

fraudData.bypassCtrlList=IbanCountry
<urn:fraudData>
     <urn:bypassCtrlList>IbanCountry</urn:bypassCtrlList>
</urn:fraudData>
"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 influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list. A same pair of countries can be found only in either list.
Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 DI;N;NOT_APPLICABLE NOT_APPLICABLE
The delivery country and IBAN country combination is prohibited. 0 to -4 depending on settings DI;N;
SHIP_COUNTRY=XXX*;
IBAN_COUNTRY=YYY*
 SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The delivery country and/or IBAN country is/are unknown. 0
Delivery country and IBAN country combination is authorised. 0

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 DI;N;NOT_APPLICABLE NOT_APPLICABLE
The “delivery country / IBAN country” combination is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings DI;N;
SHIP_COUNTRY=XXX*;
IBAN_COUNTRY=YYY*
 SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The delivery country and/or the IBAN country is/are unknown. 0
The “delivery 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”. 0
The “delivery country / IBAN country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

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

Examples:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedDeliveryIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }
<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>
"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 countryList in the data dictionary)
  • or a list of preset country codes (see areaList in the data dictionary)

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.

Examples:

fraudData.bypassCtrlList=SimilarityDeliveryIbanCountry
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
"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 influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list. A same pair of countries can be found only in either list.
Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 PI;N;NOT_APPLICABLE NOT_APPLICABLE
The customer's mobile phone number country and IBAN country combination is prohibited. 0 to -4 depending on settings PI;N;
PHONE_COUNTRY=XXX*;
IBAN_COUNTRY=YYY*
 PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The customer's mobile phone number country and/or IBAN country is/are unknown. 0
The customer's mobile phone number country and IBAN country combination is authorised. 0

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 PI;N;NOT_APPLICABLE 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”. 0 to -4 depending on settings PI;N;
PHONE_COUNTRY=XXX*;
IBAN_COUNTRY=YYY*
 PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The customer's mobile phone number country and/or IBAN country is/are unknown. 0
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”. 0
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”. 0 to +4 depending on settings

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

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

Example:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedPhoneIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }            
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedPhoneIbanCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"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 countryList in the data dictionary)
  • or a list of preset country codes (see areaList in the data dictionary)

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.

Example:

fraudData.bypassCtrlList=SimilarityPhoneIbanCountry
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityPhoneIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
"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 influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list. A same pair of countries can be found only in either list.
Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 IS;N;NOT_APPLICABLE NOT_APPLICABLE
The IP address country and IBAN country combination is prohibited. 0 to -4 depending on settings IS;N;
IP_COUNTRY=XXX*;
IBAN_COUNTRY=YYY*
 IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The IP address country and/or IBAN country is/are unknown. 0
The IP address country and IBAN country combination is authorised. 0

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 IS;N;NOT_APPLICABLE 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”. 0 to -4 depending on settings IS;N;
IP_COUNTRY=XXX*;
IBAN_COUNTRY=YYY*
 IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The IP address country and/or IBAN country is/are unknown. 0
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”. 0
The “IP address country / IBAN country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

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

Examples:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }
<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>
"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 countryList in the data dictionary)
  • or a list of preset country codes (see areaList in the data dictionary)

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.

Examples:

fraudData.bypassCtrlList=SimilarityIpIbanCountry
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityIpIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityIpIbanCountry"]
}

Card issuing country

Rule description

The card issuing country rule enables you to decide whether to accept or decline to provide a service depending on the card's issuing country (the country where the 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 issuing countries. To do so, you must:
    • give your account manager the list of authorised or prohibited issuing countries
    • or set the list of authorised or prohibited issuing countries through the fraud GUI
    • or dynamically override the list of authorised or prohibited issuing countries in your request
Attention: in advanced configuration mode, you can set two lists, one of them having a positive influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative 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 ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CR;N;NOT_APPLICABLE NOT_APPLICABLE
The card issuing country is unknown. 0 CR;N;
CARD_ISSUING_COUNTRY=XXX*
 CARD_ISSUING_COUNTRY=XXX*
The card issuing country is on the list of prohibited countries, is not on the list of authorised countries, or is the same as the merchant's country. 0 to -4 depending on settings
The card issuing country is on the list of authorised countries, is not on the list of prohibited countries, or differs from the merchant's country. 0

* XXX: ISO 3166 alphabetical country code (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CR;N;NOT_APPLICABLE NOT_APPLICABLE
The card issuing country is unknown. 0 CR;N;
CARD_ISSUING_COUNTRY=XXX*
 CARD_ISSUING_COUNTRY=XXX*
The card issuing country is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings
The card issuing 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 not on the list of “non-advantaged countries”. 0
The card issuing country is on the list of “advantaged countries” or is not on the list of “non-advantaged countries” or is the same as the merchant's country. 0 to +4 depending on settings

* XXX: ISO 3166 alphabetical country code (see countryList field in the data dictionary)

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):
    • AllowedCardIssuingCountryList for the list of authorised countries
    • DeniedCardIssuingCountryList for the list of prohibited countries
  • advanced configuration mode:
    • NDeniedCardIssuingCountryList for the list of disadvantaged countries
    • NDeniedExceptCardIssuingCountryList for the list of non-disadvantaged countries
    • PAllowedCardIssuingCountryList for the list of advantaged countries
    • PAllowedExceptCardIssuingCountryList for the list non-advantaged countries
fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedCardIssuingCountryList,riskManagementDynamicValue=FRA,BEL,GBR}         
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedCardIssuingCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>FRA,BEL,GBR</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
     “riskManagementDynamicSettingList”:[
          {
                    “riskManagementDynamicParam”:“AllowedCardIssuingCountryList”,
                    “riskManagementDynamicValue”:“FRA,BEL,GBR”
          }
     ]
}

METHOD 2 (deprecated):

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

  • fraudData.AllowedCardIssuingCountryList for the list of authorised countries
  • fraudData.DeniedCardIssuingCountryList for the list of prohibited countries
fraudData.AllowedCardIssuingCountryList=FRA,BEL,GBR
<urn:fraudData>
     <urn:AllowedCardIssuingCountryList>FRA,BEL,GBR</urn:AllowedCardIssuingCountryList>
</urn:fraudData>
"fraudData": {
   "AllowedCardIssuingCountryList": ["FRA", "BEL", "GBR"]
}

For both methods, the list sent must contain:

  • either the ISO 3166 alphabetic country codes (see field countryList in the data dictionary) separated by commas
  • or a list of preset country codes (see field areaList in the data dictionary).

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.

fraudData.bypassCtrlList=CardIssuingCountry
<urn:fraudData>
     <urn:bypassCtrlList>CardIssuingCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["CardIssuingCountry"]
}

Billing and card issuing country

Rule description

This rule enables you to decide whether to accept or decline to provide a service depending on the card issuing 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 issuer country in the request (deliveryAddress.country field)

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

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CS;N;NOT_APPLICABLE NOT_APPLICABLE
The “Card issuing country/Billing country” combination is prohibited. 0 to -4 depending on settings CS;N;
BILL_COUNTRY=XXX*;
CARD_ISSUING_COUNTRY=YYY*
 BILL_COUNTRY=XXX*; CARD_ISSUING_COUNTRY=YYY*
The “Card issuing country/Billing country” combination is authorised. 0
The card issuing country or billing country are unknown. 0

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CS;N;NOT_APPLICABLE NOT_APPLICABLE
The “card issuing country/ billing country” combination is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings CS;N;
BILL_COUNTRY=XXX*;
CARD_ISSUING_COUNTRY=YYY*
 BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The “card issuing country/ billing 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”. 0
The card issuing country or billing country are unknown. 0
The “card issuing country/ billing country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

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) :
    • AllowedBillingCardIssuingCountryCombiList for the authorised billing country and card country combinations
    • DeniedBillingCardIssuingCountryCombiList for the prohibited billing country and card country combinations
  • advanced configuration mode:
    • NDeniedBillingCardIssuingCountryCombiList for the list of disadvantaged countries
    • NDeniedExceptBillingCardIssuingCountryCombiList for the list of non-disadvantaged countries
    • PAllowedBillingCardIssuingCountryCombiList for the list of advantaged countries
    • PAllowedExceptBillingCardIssuingCountryCombiList for the list of non-advantaged countries

Examples:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedBillingCardIssuingCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}          
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedBillingCardIssuingCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,#ZEURO),(#ZEURO,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
     "riskManagementDynamicSettingList":[
          {
                    "riskManagementDynamicParam":"AllowedBillingCardIssuingCountryCombiList",
                    "riskManagementDynamicValue":"(FRA,#ZEURO),(#ZEURO,FRA)"
          }
     ]
}

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

  • either ISO 3166 alphabetic country codes (see countryList in the data dictionary)
  • or a list of preset country codes (see areaList in the data dictionary)

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 SimilarityBillingCardIssuingCountry instruction.

Examples:

fraudData.bypassCtrlList=SimilarityBillingCardIssuingCountry
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityBillingCardIssuingCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityBillingCardIssuingCountry"]
}

Delivery and card issuing country

Rule description

This rule enables you to decide whether to accept or decline to provide a service depending on the card issuing 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 issuing 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 issuing 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 influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list. A same pair of countries can be found only in either list.
Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CS;N;NOT_APPLICABLE NOT_APPLICABLE
The “Card issuing country/Delivery country” combination is prohibited. 0 to -4 depending on settings CS;N;
SHIP_COUNTRY=XXX*;
CARD_ISSUING_COUNTRY=YYY*		 SHIP_COUNTRY=XXX*; CARD_ISSUING_COUNTRY=YYY*
The “Card issuing country/Delivery country” combination is authorised. 0
The card issuing country or delivery country are unknown. 0

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CS;N;NOT_APPLICABLE NOT_APPLICABLE
The “card issuing country/ delivery country” combination is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries” 0 to -4 depending on settings CS;N;
SHIP_COUNTRY=XXX*;
CARD_ISSUING_COUNTRY=YYY*		 SHIP_COUNTRY=XXX*; CARD_ISSUING_COUNTRY=YYY*
The “card issuing country/ delivery 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” 0
The card issuing country or delivery country are unknown. 0
The “card issuing country/ card country/ delivery country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries” 0 to +4 depending on settings

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

Dynamic override

You can dynamically supply a list of authorised or prohibited delivery and card issuing 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):
    • AllowedDeliveryCardIssuingCountryCombiList for the authorised delivery and card issuing country combinations
    • DeniedDeliveryCardIssuingCountryCombiList for the prohibited delivery and card issuing country combinations
  • advanced configuration mode:
    • NDeniedDeliveryCardIssuingCountryCombiList for the list of disadvantaged countries
    • NDeniedExceptDeliveryCardIssuingCountryCombiList for the list of non-disadvantaged countries
    • PAllowedDeliveryCardIssuingCountryCombiList for the list of advantaged countries
    • PAllowedExceptDeliveryCardIssuingCountryCombiList for the list of non-advantaged countries

Examples:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedDeliveryCardIssuingCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}         
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedDeliveryCardIssuingCountryCombiList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,#ZEURO),(#ZEURO,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
     "riskManagementDynamicSettingList":[
          {
                    "riskManagementDynamicParam":"AllowedDeliveryCardIssuingCountryCombiList",
                    "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 countryList in the data dictionary)
  • or a list of preset country codes (see areaList in the data dictionary)

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 SimilarityShippingCardIssuingCountry instruction.

Examples:

fraudData.bypassCtrlList=SimilarityShippingCardIssuingCountry
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityShippingCardIssuingCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SimilarityShippingCardIssuingCountry"]
}

IP and card issuing 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 issuing 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 issuing 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 influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list. A same pair of countries can be found only in either list.
Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 SI;N;NOT_APPLICABLE NOT_APPLICABLE
The card issuing country and/or IP address country is/are unknown. 0 SI;N;
CARD_ISSUING_COUNTRY=XXX;
IP_COUNTRY=YYY*
 CARD_ISSUING_COUNTRY=XXX* ; IP_COUNTRY=YYY*
The “card issuing country/IP address country” combination is prohibited. 0 to -4 depending on settings
The “card issuing country/IP address country” combination is authorised. 0

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 SI;N;NOT_APPLICABLE NOT_APPLICABLE
The card issuing country and/or IP address country is/are unknown. 0 SI;N;
CARD_ISSUING_COUNTRY=XXX;
IP_COUNTRY=YYY*
 CARD_ISSUING_COUNTRY=XXX* ; IP_COUNTRY=YYY*
The “card issuing country/IP address country” combination is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings
The “card issuing 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”. 0
The “card issuing country/IP address country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

* XXX, YYY: ISO 3166 alphabetical country codes (see countryList field in the data dictionary)

Dynamic override

You can dynamically supply the list of IP address countries/card issuing 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):
    • AllowedIpCardIssuingCountryCombiList for the authorised IP and card country combinations
    • DeniedIpCardIssuingCountryCombiList for the prohibited IP and card country combinations
  • advanced configuration mode:
    • NDeniedIpCardIssuingCountryCombiList for the list of disadvantaged countries
    • NDeniedExceptIpCardIssuingCountryCombiList for the list of non-disadvantaged countries
    • PAllowedIpCardIssuingCountryCombiList for the list of advantaged countries
    • PAllowedExceptIpCardIssuingCountryCombiList for the list of non-advantaged countries

Examples:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedIpCardIssuingCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }           
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam> AllowedIpCardIssuingCountryCombiList </urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
     "riskManagementDynamicSettingList":[
          {
                    "riskManagementDynamicParam":"AllowedIpCardIssuingCountryCombiList",
                    "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 countryList in the data dictionary)
  • or a list of preset country codes (see areaList in the data dictionary)

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.

Examples:

fraudData.bypassCtrlList=SimilarityIpIbanCountry
<urn:fraudData>
     <urn:bypassCtrlList>SimilarityIpIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
"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: 2376 hours
In days: 99 days
In weeks: 14 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: 2376 hours
In days: 99 days
In weeks: 14 weeks
Maximum number of transactions 1 transaction over the period 9999
Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 SC;N;NOT_APPLICABLE 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). 0 to -4 depending on settings SC;N;TRANS=A:B;
CUMUL=C:D*
 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.. 0

*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 the cumulative amounts with this card over the period

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

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.

Examples:

fraudData.bypassCtrlList=VelocityCard
<urn:fraudData>
     <urn:bypassCtrlList>VelocityCard</urn:bypassCtrlList>
</urn:fraudData>
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 Merchant Extranet
  • set the number of transactions carried out and/or the cumulative amount and the cumulation time through the fraud tab in the Merchant Extranet
  • 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: 2376 hours
In days: 99 days
In weeks: 14 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 ScoreValue ScoreInfo 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). 0 to -4 depending on settings VI;N;TRANS=A:B;
CUMUL=C:D*
 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. 0 TRANS=A:B;
CUMUL=C:D*
The IP address is not specified (in Sips Office) 0

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

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

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

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

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.

Examples:

fraudData.bypassCtrlList=VelocityIp
<urn:fraudData>
     <urn:bypassCtrlList>VelocityIp</urn:bypassCtrlList>
</urn:fraudData>
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 Merchant Extranet
  • set the number of transactions carried out and/or the cumulative amount and the cumulation time through the fraud tab in the Merchant Extranet
  • 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: 2376 hours
In days: 99 days
In weeks: 14 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 ScoreValue ScoreInfo RuleDetailedInfo
The customer Id is not supplied. 0 VC;N;TRANS=A:B;
CUMUL=C:D*
 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). 0 to -4 depending on settings 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. 0

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

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

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

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

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.

Examples:

fraudData.bypassCtrlList=VelocityCustomerId
<urn:fraudData>
     <urn:bypassCtrlList>VelocityCustomerId</urn:bypassCtrlList>
</urn:fraudData>
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 Merchant Extranet
  • set the maximum number of customers and the cumulation time through the fraud tab in the Merchant Extranet
  • 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: 2376 hours
In days: 99 days
In weeks: 14 weeks
Maximum number of customers 1 customer over the period 9999
Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 MD;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different customers using the same card over the period is equal to or exceeds the authorised limit. 0 to -4 depending on settings MD;N;MAX=A:B* MAX=A:B*
The number of different customers using the same card over the period is lower than the authorised limit. 0
The customer ID is not specified. 0

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

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

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.

Examples:

fraudData.bypassCtrlList=MaxCustomerIdPerCard
<urn:fraudData>
     <urn:bypassCtrlList>MaxCustomerIdPerCard</urn:bypassCtrlList>
</urn:fraudData>
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 Merchant Extranet
  • set the maximum number of cards and the cumulation time through the fraud tab in the Merchant Extranet
  • 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: 2376 hours
In days: 99 days
In weeks: 14 weeks
Maximum number of cards 1 card over the period 9999
Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 MR;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different cards used by a given customer over the period is equal to or exceeds the authorised limit. 0 to -4 depending on settings MR;N;MAX=A:B* MAX=A:B*
The number of different cards used by a given customer over the period is lower than the authorised limit. 0
The customer ID is not supplied. 0

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

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

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.

Examples:

fraudData.bypassCtrlList=MaxCardPerCustomerId
<urn:fraudData>
     <urn:bypassCtrlList>MaxCardPerCustomerId</urn:bypassCtrlList>
</urn:fraudData>
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 Merchant Extranet
  • set the maximum number of cards and the cumulation time through the fraud tab in the Merchant Extranet
  • 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: 2376 hours
In days: 99 days
In weeks: 14 weeks
Maximum number of cards 1 card over the period 9999
Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CI;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different cards used from a given IP address over the period is equal to or exceeds the authorised limit. 0 to -4 depending on settings CI;N;MAX=A:B* MAX=A:B*
The number of different cards used from a given IP address over the period is lower than the authorised limit. 0
The IP address is not specified (in Sips Office). 0

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

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

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.

Examples:

fraudData.bypassCtrlList=MaxCardPerIp
<urn:fraudData>
     <urn:bypassCtrlList>MaxCardPerIp</urn:bypassCtrlList>
</urn:fraudData>
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 Merchant Extranet
  • set the maximum number of IBANs and the cumulation time through the fraud tab in the Merchant Extranet
  • 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: 2376 hours
In days: 99 days
In weeks: 14 weeks
Maximum number of IBANs 1 IBAN over the period 9999
Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 II;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different IBANs coming from the same IP address over the period exceeds the accepted limit. 0 to -4 depending on settings II;N;MAX=A:B* MAX=A:B*
The IP address is not specified (in Sips Office). 0
The number of different IBANs coming from the same IP address over the period is under the accepted limit. 0

*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.

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.

Examples:

fraudData.bypassCtrlList=MaxIbanPerIp
<urn:fraudData>
     <urn:bypassCtrlList>MaxIbanPerIp</urn:bypassCtrlList>
</urn:fraudData>
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 Merchant Extranet
  • set the maximum number of IP addresses and the cumulation time through the fraud tab in the Merchant Extranet
  • 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: 2376 hours
In days: 99 days
In weeks: 14 weeks
Maximum number of IP addresses 1 IP address over the period 9999
Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 IJ;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different IP addresses with the same IBAN over the period exceeds the accepted limit. 0 to -4 depending on settings IJ;N;MAX=A:B* MAX=A:B*
The IP address is not specified (in Sips Office). 0
The number of different IP addresses with the same IBAN over the period is lower than the accepted limit. 0

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

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

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.

Examples:

fraudData.bypassCtrlList=MaxIpPerIban
<urn:fraudData>
     <urn:bypassCtrlList>MaxIpPerIban</urn:bypassCtrlList>
</urn:fraudData>
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 Merchant Extranet
  • set the maximum number of customers and the cumulation time through the fraud tab in the Merchant Extranet
  • 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: 2376 hours
In days: 99 days
In weeks: 14 weeks
Maximum number of customers 1 customer over the period 9999
Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 CJ;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different customers using the same IBAN over the period exceeds the accepted limit. 0 to -4 depending on settings CJ;N;MAX=A:B* MAX=A:B*
The customer ID is not supplied. 0
The number of different customers using the same IBAN over the period is under the accepted limit. 0

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

B: the maximum number of customers accepted for a given IBAN.

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 MaxCustidPerIban instruction.

Examples:

fraudData.bypassCtrlList=MaxCustidPerIban
<urn:fraudData>
     <urn:bypassCtrlList>MaxCustidPerIban</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet
  • set the maximum number of IBANs and the cumulation time through the fraud tab in the Merchant Extranet
  • 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: 2376 hours
In days: 99 days
In weeks: 14 weeks
Maximum number of IBANs 1 IBAN over the period 9999
Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 IC;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different IBANs used by the same customer over the period exceeds the accepted limit. 0 to -4 depending on settings IC;N;MAX=A:B* MAX=A:B*
The customer ID is not specified. 0
The number of different IBANs used by the same customer over the period is under the accepted limit. 0

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

B: the maximum number of IBANs accepted for a given customer.

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.

Examples:

fraudData.bypassCtrlList=MaxIbanPerCustid
<urn:fraudData>
     <urn:bypassCtrlList>MaxIbanPerCustid</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet
  • set the maximum number of mandates and the cumulation time through the fraud tab in the Merchant Extranet
  • 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: 2376 hours
In days: 99 days
In weeks: 14 weeks
Maximum number of mandates 1 mandate over the period 9999
Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 MJ;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different mandates coming from the same IP address over the period exceeds the accepted limit. 0 to -4 depending on settings MJ;N;MAX=A:B* MAX=A:B*
The IP address is not specified. 0
The number of different mandates coming from the same IP address over the period is under the accepted limit. 0

*A: the number of mandates on the given IBAN over the period.

B: the maximum number of mandates accepted for a given IBAN.

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.

Examples:

fraudData.bypassCtrlList=MaxMandatePerIp
<urn:fraudData>
     <urn:bypassCtrlList>MaxMandatePerIp</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet
  • and set the number of transactions made and/or the cumulative amount and the cumulation time through the fraud tab in the Merchant Extranet
Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
 In hours: 2376 hours
In days: 99 days
In weeks: 14 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 ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 EM;N;NOT_APPLICABLE 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). 0 to -4 depending on settings EM;N;TRANS=A:B;
CUMUL=C:D*
 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. 0

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

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

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

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

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.

Examples:

fraudData.bypassCtrlList=VelocityMandate
<urn:fraudData>
     <urn:bypassCtrlList>VelocityMandate</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet
  • and set the number of transactions made and/or the cumulative amount and the cumulation time through the fraud tab in the Merchant Extranet
Setting Minimum value Maximum value
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
 In hours: 2376 hours
In days: 99 days
In weeks: 14 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 ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 EI;N;NOT_APPLICABLE 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). 0 to -4 depending on settings EI;N;TRANS=A:B;
CUMUL=C:D*
 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. 0

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

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

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

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

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.

Examples:

fraudData.bypassCtrlList=VelocityIban
<urn:fraudData>
     <urn:bypassCtrlList>VelocityIban</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet
  • set the list of unwanted IP address reputations through the fraud tab in the Merchant Extranet
  • and send the customer's IP address in the request (customerIpAddress field), if you use Sips Office.

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

Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
The information is unknown. 0 IR;N;U;IP_REP=XXX* IP_REP=XXX*
The IP address reputation is on the list of unwanted IP address reputations. 0 to -4 depending on settings IR;N;Y;IP_REP=XXX*
The IP address reputation is not on the list of unwanted IP address reputations. 0 IR;N;N;IP_REP=XXX*

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

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.

Examples:

fraudData.bypassCtrlList=IpReputations
<urn:fraudData>
     <urn:bypassCtrlList>IpReputations</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet.

Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 OP;N;NOT_APPLICABLE NOT_APPLICABLE
The oppotota server could not be accessed. 0 OP;N;U --
The card is blocked. 0 à -4 selon paramétrage OP;N;Y
The card is not blocked. 0 OP;N;N
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.

Examples:

fraudData.bypassCtrlList=HotList
<urn:fraudData>
     <urn:bypassCtrlList>HotList</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet.

Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 EC;N;NOT_APPLICABLE NOT_APPLICABLE
The information is unknown. 0 EC;N;U --
The card is a dynamic virtual card. 0 to -4 depending on settings EC;N;Y
The card is not a dynamic virtual card. 0 EC;N;N
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.

Examples:

fraudData.bypassCtrlList=ECard
<urn:fraudData>
     <urn:bypassCtrlList>ECard</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet.

Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 SA;N;NOT_APPLICABLE NOT_APPLICABLE
The information is unknown. 0 SA;N;U --
The card is a systematic authorisation card. 0 to -4 depending on settings SA;N;Y
The card is not a systematic authorisation card. 0 SA;N;N
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.

Examples:

fraudData.bypassCtrlList=SystematicAuthorizationCard
<urn:fraudData>
     <urn:bypassCtrlList>SystematicAuthorizationCard</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["SystematicAuthorizationCard"]
}

Commercial card (and card issuer 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 Merchant Extranet
  • 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 Merchant Extranet
    • or dynamically override the list of authorised or prohibited countries in your request
Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CC;N;NOT_APPLICABLE NOT_APPLICABLE
The information is unknown. 0 CC;N;U;
CARD_COUNTRY=XXX
 CARD_COUNTRY=XXX*
The card is a commercial card, and the list of authorised/prohibited commercial card countries has not been defined. 0 à -4 selon paramétrage CC;N;Y;
CARD_COUNTRY=XXX*
 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. 0 à -4 selon paramétrage CC;N;Y;
CARD_COUNTRY=XXX*
The card country is not on the list of prohibited commercial card countries or is on the list of authorised commercial card countries. 0 CC;N;N;
CARD_COUNTRY=XXX*
The card is not a commercial card. 0 CC;N;N;
CARD_COUNTRY=XXX*

* XXX: ISO 3166 alphabetical country code (see countryList field in the data dictionary)

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

Examples:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedCommercialCardCountryList,riskManagementDynamicValue=(FRA,BEL)}
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedCommercialCardCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,BEL)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
     "riskManagementDynamicSettingList":[
          {
                    "riskManagementDynamicParam":"AllowedCommercialCardCountryList",
                    "riskManagementDynamicValue":"(FRA,BEL)"
          }
     ]
}

For both methods, the list sent must contain either:

  • the ISO 3166 alphabetic country codes (see countryList in the data dictionary) separated by commas
  • or a pre-established country code list (see areaList in the data dictionary)

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.

Examples:

fraudData.bypassCtrlList=CorporateCard
<urn:fraudData>
     <urn:bypassCtrlList>CorporateCard</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet
  • and set the minimum and/or maximum amount(s) through the fraud tab in the Merchant Extranet
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 influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative amount range.
Expression of the result

Default mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
The transaction amount does not lie within the range of required amounts. 0 to -4 depending on settings CA;N;MIN=A:B;MAX=A:C* MIN=A:B;MAX=A:C*
The transaction amount lies within the range of required amounts. 0 CA;N;MIN=A:B;MAX=A:C*

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
The transaction amount lies within the range of disadvantaged amounts. 0 to -4 depending on settings CA;N;NEGATIVE_MIN=A:B;
NEGATIVE_MAX= A:C;
POSITIVE_MIN= A:D;
POSITIVE_MAX=A:E*
 NEGATIVE_MIN=A:B;
NEGATIVE_MAX=A:C;
POSITIVE_MIN=A:D;
POSITIVE_MAX=A:E
The transaction amount does not lie within the ranges of advantaged and disadvantaged amounts. 0 CA;N;NEGATIVE_MIN=A:B;
NEGATIVE_MAX=A:C;
POSITIVE_MIN=A:D;
POSITIVE_MAX=A:E*
The transaction amount lies within the range of advantaged amounts. 0 to +4 depending on settings CA;N;NEGATIVE_MIN=A:B;
NEGATIVE_MAX=A:C;
POSITIVE_MIN=A:D;
POSITIVE_MAX=A:E*

__________

* 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.

Examples:

fraudData.bypassCtrlList=CapCollarAmount
<urn:fraudData>
     <urn:bypassCtrlList>CapCollarAmount</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet.

Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 NC;N;NOT_APPLICABLE NOT_APPLICABLE
The card BIN is unknown. 0 NC;N;U --
The card is not part of the CB network. 0 to -4 depending on settings NC;N;Y
The card is part of the CB network. 0 NC;N;N
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.

Examples:

fraudData.bypassCtrlList=CBScheme
<urn:fraudData>
     <urn:bypassCtrlList>CBScheme</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet
  • 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 ScoreValue ScoreInfo RuleDetailedInfo
At least one of the e-mail addresses is on the list of free e-mail addresses. 0 to -4 depending on settings FE;N;Y --
None of the e-mail addresses are on the list of free e-mail addresses. 0 FE;N;U
No e-mail addresses were sent. 0 FE;N;N
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.

Examples:

fraudData.bypassCtrlList=FreeEmail
<urn:fraudData>
     <urn:bypassCtrlList>FreeEmail</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet
  • and set the list of prohibited 3-D Secure authentication statuses through the fraud tab in the Merchant Extranet.

Please refer to the holderAuthentStatus field in the data dictionary.

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

Default mode (simple configuration):

Use case ScoreValue ScoreInfo 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). 0 A3;N;NOT_APPLICABLE NOT_APPLICABLE
The 3-D Secure status is prohibited. 0 to -4 depending on settings A3;N;Y --
The 3-D Secure status is not prohibited. 0 A3;N;N

Advanced configuration mode:

Use case ScoreValue ScoreInfo 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). 0 A3;N;NOT_APPLICABLE NOT_APPLICABLE
The 3-D Secure status is on the list of “disadvantaged statuses”. 0 to -4 depending on settings A3;N;Y --
The 3-D Secure status is not on the lists of “disadvantaged statuses” and “advantaged statuses”. 0 A3;N;N
The 3-D Secure status is on the list of “advantaged statuses”. 0 to +4 depending on settings A3;N;Y
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.

Examples:

fraudData.bypassCtrlList=3DSStatus
<urn:fraudData>
     <urn:bypassCtrlList>3DSStatus</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • 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 ScoreValue ScoreInfo RuleDetailedInfo
The e-mail address is incorrectly formatted. 0 to -4 depending on settings ES;N --
The e-mail address is correctly formatted. 0
No e-mail addresses were sent. 0
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.

Examples:

fraudData.bypassCtrlList=EmailSyntax
<urn:fraudData>
     <urn:bypassCtrlList>EmailSyntax</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["EmailSyntax"]
}

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 Merchant Extranet

  • and set the minimum number of months before the card expires through the fraud tab in the Merchant Extranet

Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 PE;N;NOT_APPLICABLE NOT_APPLICABLE
The validity time of the means of payment is shorter than the required duration. 0 to -4 depending on settings PE;N;Y;EXPIRY=AAA:BBB* EXPIRY=AAA:BBB*
The validity time of the means of payment is longer than the required duration. 0 PE;N;N;EXPIRY=AAA:BBB*

* AAA: card expiry date in MMYY format.

BBB : deadline of the check in MMYY format.

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.

Examples:

fraudData.bypassCtrlList=ExpiryDate
<urn:fraudData>
     <urn:bypassCtrlList>ExpiryDate</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["ExpiryDate"]
}

Commercial card (and card issuing 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 Merchant Extranet
  • 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 Merchant Extranet
    • or dynamically override the list of authorised or prohibited countries in your request
Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CC;N;NOT_APPLICABLE NOT_APPLICABLE
The information is unknown. 0 CC;N;U;
CARD_ISSUING_COUNTRY=XXX
 CARD_ISSUING_COUNTRY=XXX*
The card is a commercial card, and the list of authorised/prohibited commercial card countries has not been defined. 0 à -4 selon paramétrage CC;N;Y;
CARD_ISSUING_COUNTRY=XXX*
 CARD_ISSUING_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. 0 à -4 selon paramétrage CC;N;Y;
CARD_ISSUING_COUNTRY=XXX*
The card country is not on the list of prohibited commercial card countries or is on the list of authorised commercial card countries. 0 CC;N;N;
CARD_ISSUING_COUNTRY=XXX*
The card is not a commercial card. 0 CC;N;N;
CARD_ISSUING_COUNTRY=XXX*

* XXX: ISO 3166 alphabetical country code (see countryList field in the data dictionary)

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:

  • AllowedCommercialCardIssuingCountryList for the authorised commercial card country combinations

  • DeniedCommercialCardIssuingCountryList for the denied commercial card country combinations

Examples:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=AllowedCommercialCardIssuingCountryList,riskManagementDynamicValue=(FRA,BEL)}
<urn:fraudData>
     <urn:riskManagementDynamicSettingList>
          <urn:riskManagementDynamicSetting>
               <urn:riskManagementDynamicParam>AllowedCommercialCardIssuingCountryList</urn:riskManagementDynamicParam>
               <urn:riskManagementDynamicValue>(FRA,BEL)</urn:riskManagementDynamicValue>
          </urn:riskManagementDynamicSetting>
     </urn:riskManagementDynamicSettingList>
</urn:fraudData>
"fraudData": {
     "riskManagementDynamicSettingList":[
          {
                    "riskManagementDynamicParam":"AllowedCommercialCardIssuingCountryList",
                    "riskManagementDynamicValue":"(FRA,BEL)"
          }
     ]
}

For both methods, the list sent must contain either:

  • the ISO 3166 alphabetic country codes (see countryList in the data dictionary) separated by commas
  • or a pre-established country code list (see areaList in the data dictionary)

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 CommercialCardIssuingCountry instruction.

Examples:

fraudData.bypassCtrlList=CommercialCardIssuingCountry
<urn:fraudData>
     <urn:bypassCtrlList>CommercialCardIssuingCountry</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["CommercialCardIssuingCountry"]
}

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 the list is managed:

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

Therefor, the possible results according to the type of rule are shown in the table below:

Data item is present Blacklist result
(NEGATIVE type)
 Greylist result
(NEGATIVE type)
 Whitelist result
(POSITIVE type)
NO Neutral Neutral Neutral
YES Negative Negative 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.

You can 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 Merchant Extranet

  • 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 ScoreValue ScoreInfo Rule DetailedInfo
At least one e-mail address is on the list. Black 0 to -4 depending on settings BM;N;Y --
Grey GM;N;Y
White 0 to +4 depending on settings WM;P;Y
None of the e-mail addresses are on the list. Black 0 BM;N;N
Grey GM;N;N
White WM;P;N
No e-mail addresses were sent. Black BM;N;U
Grey GM;N;N
White WM;P;U
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).

Example for whitelist:

fraudData.bypassCtrlList=WhiteEmail
<urn:fraudData>
     <urn:bypassCtrlList>WhiteEmail</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet,

  • 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 ScoreValue ScoreInfo Rule DetailedInfo
The IP address is not specified (in Sips Office) Black 0 BY;N;U --
Grey GY;N;U
White WY;P;U
The IP address is on the list. Black 0 to -4 depending on settings BY;N;Y
Grey GY;N;Y
White 0 to +4 depending on settings WY;P;Y
The IP address is not on the list. Black 0 BY;N;N
Grey GY;N;N
White WY;P;N
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).

Example for whitelist:

fraudData.bypassCtrlList=WhiteIp
<urn:fraudData>
     <urn:bypassCtrlList>WhiteIp</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • 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 ScoreValue ScoreInfo Rule DetailedInfo
No postal codes were sent. Black 0 BZ;N;U --
Grey GZ;N;U
White WZ;P;U
At least one postal code is on the list. Black 0 to -4 depending on settings BZ;N;Y
Grey GZ;N;Y
White 0 to +4 depending on settings WZ;P;Y
None of the postal codes are on the list. Black 0 BZ;N;N
Grey GZ;N;N
White WZ;P;N
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).

Example for whitelist:

fraudData.bypassCtrlList=WhitePostalCode
<urn:fraudData>
     <urn:bypassCtrlList>WhitePostalCode</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • 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 ScoreValue ScoreInfo Rule DetailedInfo
The customer ID is not supplied. White 0 BI;N;U --
Grey GI;N;U
White WI;P;U
At least one customer ID is on the list. Black 0 to -4 depending on settings BI;N;Y
Grey GI;N;Y
White 0 to +4 depending on settings WI;P;Y
The customer ID is not on the list. Black 0 BI;N;N
Grey GI;N;N
White WI;P;N
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).

Example for whitelist:

fraudData.bypassCtrlList=WhiteCustomerId
<urn:fraudData>
     <urn:bypassCtrlList>WhiteCustomerId</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • 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 ScoreValue ScoreInfo Rule DetailedInfo
No customer names were sent. Black 0 BN;N;U --
Grey GN;N;U
White WN;P;U
At least one customer name is on the blacklist. Black 0 to -4 depending on settings BN;N;Y
Grey GN;N;Y
White 0 to +4 depending on settings WN;P;Y
None of the customer names are on the blacklist. Black 0 BN;N;N
Grey GN;N;N
White WN;P;N
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).

Example for whitelist:

fraudData.bypassCtrlList=WhiteCustomerName
<urn:fraudData>
     <urn:bypassCtrlList>WhiteCustomerName</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • 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
Cas d'utilisation ScoreValue ScoreInfo Rule DetailedInfo
This rule cannot be executed (the means of payment is not a card). Noire 0 BC;N;U --
Grise GC;N;U
Blanche WC;P;U
The card number is on the list. Noire 0 to -4 depending on settings BC;N;Y
Grise GC;N;Y
Blanche 0 to +4 depending on settings WC;P;Y
The card number is not on the list. Noire 0 BC;N;N
Grise GC;N;N
Blanche WC;P;N
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).

Example for whitelist:

fraudData.bypassCtrlList=WhiteCard
<urn:fraudData>
     <urn:bypassCtrlList>WhiteCard</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • 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 ScoreValue ScoreInfo Rule DetailedInfo
No phone numbers were sent. Black 0 BP;N;U --
Grey GP;N;U
White WP;P;U
At least one phone number is on the list. Black 0 to -4 depending on settings BP;N;Y
Grey GP;N;Y
White 0 to +4 depending on settings WP;P;Y
None of the phone numbers are on the list. Black 0 BP;N;N
Grey GP;N;N
White WP;P;N
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).

Example for whitelist:

fraudData.bypassCtrlList=WhitePhoneNumber
<urn:fraudData>
     <urn:bypassCtrlList>WhitePhoneNumber</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • 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 ScoreValue ScoreInfo Rule DetailedInfo
This rule cannot be executed (the means of payment is not a card). Black 0 BB;N;U --
Grey BR;N;U
White WB;P;U
The card BIN is on the list. Black 0 to -4 depending on settings BB;N;Y
Grey BR;N;Y
White 0 to +4 depending on settings WB;P;Y
The card BIN is not on the list. Black 0 BB;N;N
Grey BR;N;N
White WB;P;N
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).

Example for whitelist:

fraudData.bypassCtrlList=WhiteBinCard
<urn:fraudData>
     <urn:bypassCtrlList>WhiteBinCard</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • and set the BIC black, grey and/or white list(s)

Expression of the result
Use case ScoreValue ScoreInfo Rule DetailedInfo
The BIC is on the list. Black 0 to -4 depending on settings BE;N;Y --
Grey GM;N;Y
White 0 to +4 depending on settings WE;P;Y
The BIC is not on the list. Black 0 BE;N;N
Grey GM;N;N
White WE;P;N
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).

Example for whitelist:

fraudData.bypassCtrlList=WhiteBic
<urn:fraudData>
     <urn:bypassCtrlList>WhiteBic</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • and set the IBAN black, grey and/or white list(s)

Expression of the result
Use case ScoreValue ScoreInfo Rule DetailedInfo
The IBAN is on the list. Black 0 to -4 depending on settings BA;N;Y --
Grey GA;N;Y
White 0 to +4 depending on settings WA;P;Y
The IBAN is not on the list. Black 0 BA;N;N
Grey GA;N;N
White WA;P;N
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).

Example for whitelist:

fraudData.bypassCtrlList=WhiteIban
<urn:fraudData>
     <urn:bypassCtrlList>WhiteIban</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • and set the mandate black, grey and/or white list(s)

Expression of the result
Use case ScoreValue ScoreInfo Rule DetailedInfo
The UMR of the mandate is on the list. Black 0 to -4 depending on settings TB;N;Y --
Grey TG;N;Y
White 0 to +4 depending on settings TW;P;Y
The UMR of the mandate is not on the list. Black 0 TB;N;N
Grey TG;N;N
White TW;P;N
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).

Example for whitelist:

fraudData.bypassCtrlList=WhiteMandate
<urn:fraudData>
     <urn:bypassCtrlList>WhiteMandate</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • set at least one risky product list via the fraud tab in the Merchant Extranet

  • and send the customer's basket content in the request, particularly the product code for each product in the basket (ShoppingCartDetail field).
Expression of the result
Use case ScoreValue ScoreInfo Rule DetailedInfo
At least one product in the basket is on a risky product list. 0 to -3 depending on settings RP;N;Y --
Information unknown. 0 RP;N;U;
No products in the basket are on a risky product list. 0 RP;N;N
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.

Examples:

fraudData.bypassCtrlList=RiskyProductList
<urn:fraudData>
     <urn:bypassCtrlList>RiskyProductList</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • set at least one risky product list via the fraud tab in the Merchant Extranet

  • and send the customer's basket content in the request, particularly the product code and quantity of each product in the basket (ShoppingCartDetail field).
Expression of the result
Use case ScoreValue ScoreInfo 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.
 0 to -4 depending on settings PQ;N;Y;
MAX_QUANTITY_PER_
RISKY_PRODUCT=L:A:B;
MAX_QUANTITY_PER_
LIST=L:C:D*
 MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B;
MAX_QUANTITY_PER_
LIST=L:C:D*
Information unknown 0 PQ;N;U --
No products in the basket are on a risky product list
or
No products in the basket included on a risky product list have a greater higher than the limit configured in the rule.
 0 PQ;N;N;
MAX_QUANTITY_PER_
RISKY_PRODUCT=L:A:B;
MAX_QUANTITY_PER_
LIST=L:C:D*		 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 can be configured for this rule. The MAX_QUANTITY_PER_RISKY_PRODUCT and MAX_QUANTITY_PER_LIST 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.

Example:

fraudData.bypassCtrlList=RiskyProductQuantity
<urn:fraudData>
     <urn:bypassCtrlList>RiskyProductQuantity</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet

  • set at least one risky product list via the fraud tab in the Merchant Extranet

  • and send the customer's basket content in the request, particularly the product code, unit price and quantity of each product in the basket (ShoppingCartDetail field).
Expression of the result
Use case ScoreValue ScoreInfo 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.		 0 to -4 depending on settings PQ;N;Y;
MAX_RATIO_PER_
RISKY_PRODUCT=L:A:B;
MAX_RATIO_PER_
LIST=L:C:D*		 MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*
Information unknown 0 PQ;N;U --
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.		 0 PQ;N;N;
MAX_RATIO_PER_
RISKY_PRODUCT=L:A:B;
MAX_RATIO_PER_
LIST=L:C:D*		 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 fields are returned to the scoreInfo field for each of these lists. It is therefore possible to have these values up to 3 times for this rule 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.

Example:

fraudData.bypassCtrlList=RiskyProductRatio
<urn:fraudData>
     <urn:bypassCtrlList>RiskyProductRatio</urn:bypassCtrlList>
</urn:fraudData>
"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 Merchant Extranet
  • and send the customer's basket content in the request, particularly the product code and quantity of each product in the basket (ShoppingCartDetail field).
Expression of the result
Use case ScoreValue ScoreInfo RuleDetailedInfo
At least one product in the basket is in a quantity greater than the limit configured in the rule. 0 to -4 depending on settings QP;N;Y;
PRODUCTQUANTITY=A:B*
 PRODUCTQUANTITY =A:B*
Information unknown. 0 QP;N;U;
PRODUCTQUANTITY=XXX:B*
 PRODUCTQUANTITY =XXX:B*
No product in the basket is in a quantity greater than the limit configured in the rule. 0 QP;N;N;
PRODUCTQUANTITY=A:B*
 PRODUCTQUANTITY =A:B*

* A: quantity of the first product found which quantity 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.

Examples:

fraudData.bypassCtrlList=MaxQuantityPerProduct
<urn:fraudData>
     <urn:bypassCtrlList>MaxQuantityPerProduct</urn:bypassCtrlList>
</urn:fraudData>
"fraudData": {
   "bypassCtrlList": ["MaxQuantityPerProduct"]
}

Appendices

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 (see data dictionary to know the values possible for each field).

fraudData.bypassCtrlList Disables standard rules
fraudData.bypassInfoList Deprecated

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

Correspondence between means of payment and antifraud rules

Pre-authorisation mode

Table legend:

1 asterisk (*) means that the application of the rule depends on the card repository provided by your acquirer.

2 asterisks (**) mean that the application of the rule depends on the information you submit in the request.

For combined rules such as IP and card issuer country, Delivery and card country and Billing and card issuer country, information depends on both the card repository and information you submit in the payment request.


Geolocalisation rules. Image too complexe to be described. Please contact the support


Velocity rules. Image too complexe to be described. Please contact the support


Miscellaneous rules. Image too complexe to be described. Please contact the support


Lists rules. Image too complexe to be described. Please contact the support


Basket rules. Image too complexe to be described. Please contact the support

Pre-authentication mode

The pre-authentication mode is only applicable to the transactions with a card (except for external wallets).

Table legend:

1 asterisk (*) means that the application of the rule depends on the card repository provided by your acquirer.

2 asterisks (**) mean that the application of the rule depends on the information you submit in the request.

For combined rules such as IP and card issuer country, Delivery and card issuer country and Billing and card issuer country, information depends on both the card repository and information you submit in the payment request.


Geolocalisation rules. Image too complex to be described, please contact the support


Velocity rules. Image too complex to be described, please contact the support


Miscellaneous rules. Image too complex to be described, please contact the support


Lists rules. Image too complex to be described, please contact the support


Baskets rules. Image too complex to be described, please contact the support

List export file format

Profile lists CSV file

The files which result of the export of a list configured in the rule in a profile are in the CSV format which uses the semi-column “;” as a separator;

The file name is by default formatted as follows: <list type>_list.csv (ex: country_list.csv).

The first line in the file is the column headers.

The subsequent lines stand for one item of the list.

Whatever the list type, the file format is the same.

Single country list

The file containing a country list (got from rules like “card issuer country”, “IP address country”, etc.) has 1 column:

  • COUNTRY: the ISO-3166 country code

Example:

Let’s take the list exported from the configuration of the rule “card issuer country” in a profile:

Country
FRA
DEU
BEL

Then the file will be as follows:

country_list.csv

COUNTRY;
FRA;
DEU;
BEL;
Country couple list

The file containing a country couple list (got from rules like “IP and card issuer country”, “commercial card”, etc.) has 2 columns:

  • COUNTRY1: the ISO-3166 country code
  • COUNTRY2 : the ISO-3166 country code

Example:

Let’s take the list from the configuration of the rule “IP and card issuer country” in a profile:

Country 1 Country 2
FRA FRA
DEU FRA
BEL FRA

Then the file will be as follows:

country_list.csv

COUNTRY1;COUNTRY2;
FRA;FRA;
DEU;FRA;
BEL;FRA;
E-mail domain list

The file containing an e-mail domain list (got from rule “free e-mail address”) has 1 column:

  • DOMAIN: the web domain of a free e-mail address.

Example:

Let’s take the list from the configuration of the rule “free e-mail address” in a profile:

Domain
freedomain1.com
freedomain2.com
freedomain3.com

Then the file will be as follows:

domain_list.csv

DOMAIN;
domaine1.com;
domaine2.com;
domaine3.com;
Black, grey or white list CSV file

The files which result of the export of a black, grey or white list are in the CSV format which uses the semi-column “;” as a separator;

The file name is by default formatted as follows:

<shop identifier>_<list colour>_<list type>.csv (ex : 200007755500002_GREY_PAN.csv).

The first line in the file is the column headers.

The subsequent lines stand for one item of the list.

Whatever the list type, the file format is the same, with the exception of the card numbers lists having a specific one.

Card number lists

The file containing card numbers lists has 5 columns:

  • TRANSACTION_REF or TRANSACTION_ID: transaction reference or identifier depending on shop’s mode
  • TRANSACTION_DATE: transaction date with AAAA-MM-JJ format
  • MASKED_PAN: masked card number
  • REASON: the code of the reason to the addition of the card to the list
  • SHOP_ID: identifier of the shop that added the card to the list

Example:

Let’s take the card number black list of the shop with identifier 201000770050003:

Transaction ref./ID Date Card number Reason Webshop ID
915 2016-12-21 6703##########15 fraud 201000770050003
1546 2016-12-21 6703##########46 fraud 201000770050003
2530 2016-12-21 6703##########30 fraud 201000770050003
2735 2016-12-21 6703##########35 fraud 201000770050003

Then the file will be as follows:

201000770050003_BLACK_PAN.csv

TRANSACTION_REF;TRANSACTION_DATE;MASKED_PAN;REASON;SHOP_ID;
915;2016-12-21;6703##########15;fraud;201000770050003;
1546;2016-12-21;6703##########46;fraud;201000770050003;
2530;2016-12-21;6703##########30;fraud;201000770050003;
2735;2016-12-21;6703##########35;fraud;201000770050003;
Other lists

Except the files containing card numbers, all the files containing lists are made of 3 columns:

  • ITEM: is list’s item value (e-mail, customer ID, IP address, etc.)
  • REASON: the code of the reason to the addition of the card to the list
  • SHOP_ID: identifier of the shop that added the card to the list

Example:

Let’s take the customer ID black list of the shop with identifier 201000770050003:

Item Reason Webshop
123456 fraudSuspicion 201000770050003
987654 negativeExperience 201000770050003
456789 notSpecified 201000770050003
654321 fraud 201000770050003

Then the file will be as follows:

201000770050003_BLACK_CUSTOMER.csv

ITEM;REASON;SHOP_ID;
123456;fraudSuspicion;201000770050003;
987654;negativeExperience;201000770050003;
456789;notSpecified;201000770050003;
654321;fraud;201000770050003;
Risky product CSV file

The files which result of the export of a risky product list are in the CSV format which uses the semi-column “;” as a separator

The file name is by default formatted as follows: <shop identifier>_<list name>.csv (ex: 200007755500002_My_product_list.csv).

Each line of the file corresponds to an item of the list and has three columns:

  • product code
  • product label
  • validity date

Example:

When a list contains the following items:

Product code Product label Validity date
A858F Produit 1 29/10/2016
F85F4 Produit 2 31/10/2016

The matching CSV file is:

A858F;Produit 1;29/10/2016
F85F4;Produit 2;31/10/2016
Back to top Need help?

This site uses trackers to improve your experience, perform analysis and researches on your use of WL Sips documentation website.
You have several options:
Closing this banner you refuse the use of trackers on your device.

Configuration