WL SIPS DOCS

Release 24.5

go directly to content

Search by keywords

Rules

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

This page lists the fraud rules available with our Go-No-Go solution.

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

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.

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 (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list. A same country can be found only in either list.
IMPORTANT: information about American Express cards

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

Simple configuration mode:

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

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

Advanced configuration mode:

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

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

____________________

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

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.

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"]
}

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.

If you would like to use this rule you must:

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

Simple configuration mode:

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

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

Advanced configuration mode:

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

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

____________________

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

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.

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"]
}    

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.

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

Simple configuration mode:

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

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

Advanced configuration mode:

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

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

____________________

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

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.

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"]
}

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.

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

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

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

____________________

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

Dynamic override is not available for this rule.

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"]
}

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.

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

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

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

____________________

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

A, B: postal codes

Dynamic override is not available for this rule.

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"]
}

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.

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

Simple configuration mode:

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

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

Advanced configuration mode:

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

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

____________________

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

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.

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"]
}

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.

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

Simple configuration mode:

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

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

Advanced configuration mode:

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

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

____________________

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

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.

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"]
}

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.

If you would like to use this rule you must:

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

Simple configuration mode:

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

Advanced configuration mode:

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

This rule does not populate the complementaryInfo field.

____________________

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

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.

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"]
}

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.

If you would like to use this rule you must:

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

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

Simple configuration mode:

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

Advanced configuration mode:

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

This rule does not populate the complementaryInfo field.

____________________

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

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.

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"]
}

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.

If you would like to use this rule you must:

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

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

Simple configuration mode:

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

Advanced configuration mode:

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

This rule does not populate the complementaryInfo field.

____________________

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

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.

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"]
}

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.

If you would like to use this rule you must:

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

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

Simple configuration mode:

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

Advanced configuration mode:

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

This rule does not populate the complementaryInfo field.

____________________

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

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.

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"]
}

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.

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 (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list. A same country can be found only in either list.
IMPORTANT: information about American Express cards

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

Simple configuration mode:

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

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

Advanced configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The card issuing country is unknown. -- Neutral 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". 73 Negative
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 on the list of "non-advantaged countries". -- Neutral
The card issuing country is on the list of "advantaged countries" or is not on the list of "non-disadvantaged countries". 73 Positive

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

____________________

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

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.

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"]
}

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.

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 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 billing and card issuing country in the request (deliveryAddress.country field)

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

Simple configuration mode:

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

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

Advanced configuration mode:

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

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

____________________

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

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.

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"]
}

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.

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

Simple configuration mode:

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

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

Advanced configuration mode:

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

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

____________________

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

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.

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"]
}

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.

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

Simple configuration mode:

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

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

Advanced configuration mode:

Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The card issuing country and/or the IP address country is/are unknown. -- Neutral 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". 76 Negative
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". -- Neutral
The card issuing country/IP address country combination is on the list of "advantaged countries" or is not on the list of "non-disadvantaged countries". 76 Positive

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

____________________

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

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.

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

Examples:

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

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.

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

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

CUMUL=C:D*

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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

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

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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

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

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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.

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.

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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

The rule is executed on all card payment transactions.

The rule checks whether the card is a virtual card.

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

Examples:

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

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.

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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

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

This rule does not populate the complementaryInfo field.

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.

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"]
}

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.

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 (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) amount range.

Default mode:

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

Advanced configuration mode:

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

This rule does not populate the complementaryInfo field.

__________

* A: transaction amount.

B: minimum amount accepted.

C: maximum amount accepted.

Dynamic override is not available for this rule.

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"]
}

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.

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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).
Use case Complementary Code Rule result RuleDetailedInfo
At least one of the e-mail addresses is on the list of free e-mail addresses. 27 Negative --
None of the e-mail addresses are on the list of free e-mail addresses. -- Neutral
No e-mail addresses were sent. -- Neutral

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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 (GO) influence and the other one a negative (NOGO) influence, as opposed to the simple configuration mode where there is a single negative (NOGO) list.

Default mode (simple configuration):

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

This rule does not populate the complementaryInfo field.

Advanced configuration mode:

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

Dynamic override is not available for this rule.

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"]
}

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.

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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

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

* AAA: card expiry date in MMYY format.

BBB: deadline of the check in MMYY format.

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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
Use case Complementary Code Rule result RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). -- Neutral NOT_APPLICABLE
The information is not known. -- Neutral CARD_ISSUING_COUNTRY=XXX*
The card is a commercial card, and the list of authorised/prohibited commercial card countries has not been defined. 77 Negative CARD_ISSUING_COUNTRY=XXX*
The card issuer country is on the list of prohibited commercial card countries or is not the list of of authorised commercial card countries. 77 Negative
The card issuer country is not on the list of prohibited commercial card countries or is on the list of authorised commercial card countries. -- Neutral
The card is not a commercial card. -- Neutral

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

This rule does not populate the complementaryInfo field.

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.

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"]
}

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

  • blacklist verification
  • greylist verification
  • whitelist verification

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

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

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

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

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

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

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

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

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

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.

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.

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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)
Use case Complementary Code Rule result Rule DetailedInfo
The customer ID is not supplied. Black -- Neutral --
Grey
White
At least one customer ID is on the list. Black 28 Negative
Grey 29
White AB Positive
The customer ID is not on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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)
Use case Complementary Code Rule result Rule DetailedInfo
No phone numbers were sent. Black -- Neutral --
Grey
White
At least one phone number is on the list. Black 33 Negative
Grey 34
White AD Positive
None of the phone numbers are on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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.
Use case Complementary Code Rule result Rule DetailedInfo
This rule cannot be executed (the means of payment is not a card). Black -- Neutral --
Grey
White
The card BIN is on the list. Black 41 Negative
Grey 08
White AH Positive
The card BIN is not on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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)

Use case Complementary Code Rule result Rule DetailedInfo
The BIC is on the list. Black 66 Negative --
Grey 67
White AI Positive
The BIC is not on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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)

Use case Complementary Code Rule result Rule DetailedInfo
The IBAN is on the list. Black 68 Negative --
Grey 59
White AJ Positive
The IBAN is not on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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)

Use case Complementary Code Rule result Rule DetailedInfo
The UMR is on the list. Black 70 Negative --
Grey 71
White AK Positive
The UMR is not on the list. Black -- Neutral
Grey
White

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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"]
}

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.

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.

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.

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).
Use case Complementary Code Rule result Rule DetailedInfo
At least one product in the basket is on a risky product list. 51 Negative --
Information unknown. -- Neutral
No products in the basket are on a risky product list. -- Neutral

Dynamic override is not available for this rule.

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"]
}

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.

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).
Use case Complementary Code Rule result RuleDetailedInfo
At least one product in the basket is on a risky product list, in a quantity greater than the limit configured in the rule
and/or
the total quantity of products in the basket included on a risky product list is greater than the limit configured in the rule.
52 Negative MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY _PER_LIST=L:C:D*
Information unknown. -- Neutral --
Aucun produit du panier n’appartient à une liste de produits à risque
ou
Aucun produit du panier appartenant à une liste de produits à risque n’a une quantité supérieure au seuil paramétré dans la règle.
-- Neutral MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY _PER_LIST=L:C:D*

*L: concerned risky product list name

A: biggest quantity of a product in the basket, belonging to that risky product list

B: maximum allowed quantity of a single product in the basket, belonging to that risky product list

C : sum of the quantities of all the products in the basket, belonging to that risky product list

D: maximum allowed cumulative quantity of all products in the basket, belonging to that risky product list

Note: up to 3 risky product lists ca be configured for this rule. The MAX_QUANTITY_PER_RISKY_PRODUCT and MAX_QUANTITY_PER_LIST values are returned in the complementaryInfo field for each of these lists. It is therefore possible to have these values up to 3 times for this rule in the complementaryInfo field.

MAX_QUANTITY_PER_RISKY_PRODUCT=L1:A1:B1;MAX_QUANTITY_PER_LIST=L1:C1:D1; MAX_QUANTITY_PER_RISKY_PRODUCT=L2:A2:B2;MAX_QUANTITY_PER_LIST=L2:C2:D2; MAX_QUANTITY_PER_RISKY_PRODUCT=L3:A3:B3;MAX_QUANTITY_PER_LIST=L3:C3:D3

Dynamic override is not available for this rule.

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"]
}

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.

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).
Use case Complementary Code Rule result RuleDetailedInfo
The highest ratio between the total amount for at least one product on a risky product list and the total basket amount is higher than the limit configured in the rule
and/or
the ratio between the total amount for all the products on a risky product list and the total basket amount is higher than the limit configured in the rule.
53 Negative MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*
Information unknown. -- Neutral --
No products in the basket are on a risky product list
or
the ratio between the total amount for products on a risky product list and the total basket amount is not higher than the limit configured in the rule and the ratio between the total amount of all the products included in this risky product list and the total basket amount does not exceed the limit configured in the rule
-- Neutral MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*

*L: concerned risky product list name.

A: biggest ratio between the total amount of a product in the basket, belonging to that risky product list, and the total amount of the basket.

B: maximum allowed ratio between the total amount of a product in the basket, belonging to that risky product list, and the total amount of the basket.

C: biggest ratio between the total amount of the quantities of all the products in the basket, belonging to that risky product list, and the total amount of the basket.

D: maximum allowed ratio between the total amount of the quantities of all the products in the basket, belonging to that risky product list, and the total amount of the basket.

Note: up to 3 risky product lists can be used for this rule. The MAX_RATIO_PER_RISKY_PRODUCT and MAX_QUANTITY_PER_LIST values are returned to the scoreInfo field for each of these lists. It is therefore possible to have these values up to 3 times in the scoreInfo field.

MAX_RATIO_PER_RISKY_PRODUCT=L1:A1:B1;MAX_RATIO_PER_LIST=L1:C1:D1; MAX_RATIO_PER_RISKY_PRODUCT=L2:A2:B2;MAX_RATIO_PER_LIST=L2:C2:D2; MAX_RATIO_PER_RISKY_PRODUCT=L3:A3:B3;MAX_RATIO_PER_LIST=L3:C3:D3

Dynamic override is not available for this rule.

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"]
}

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.

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).
Use case Complementary Code Rule result RuleDetailedInfo
At least one product in the basket is in a quantity greater than the limit configured in the rule. 54 Negative PRODUCTQUANTITY =A:B*
Information unknown. -- Neutral PRODUCTQUANTITY =XXX:B*
No product in the basket is in a quantity greater than the limit configured in the rule. -- Neutral PRODUCTQUANTITY =A:B*

* A: quantity of the first product found the quantity of which is above the threshold set in the rule.

B: maximum allowed quantity for all products in the basket.

Dynamic override is not available for this rule.

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"]
}

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

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

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

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

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.

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;

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;

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;

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.

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;

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;

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

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