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

Simple configuration mode:

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

Advanced configuration mode:

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 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 Office (M2M).

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

Simple configuration mode:

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

Advanced configuration mode:

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 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 Office (M2M).

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 Office (M2M).

Simple configuration mode:

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

Advanced configuration mode:

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

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

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)

Simple configuration mode:

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

Advanced configuration mode:

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)

Simple configuration mode:

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

Advanced configuration mode:

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

Simple configuration mode:

Advanced configuration mode:

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

Simple configuration mode:

Advanced configuration mode:

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

Simple configuration mode:

Advanced configuration mode:

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 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 Office (M2M).

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 Office (M2M)

Simple configuration mode:

Advanced configuration mode:

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

Simple configuration mode:

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

Advanced configuration mode:

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)

Simple configuration mode:

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

Advanced configuration mode:

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)

Simple configuration mode:

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

Advanced configuration mode:

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 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 Office (M2M).

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 Office (M2M).

Simple configuration mode:

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

Advanced configuration mode:

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

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

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

*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 Paypage ;
• or from your transfer of data in the request in Office (M2M).

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

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 Office (M2M)

*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):

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)

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

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)

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

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)

*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 Paypage ;
• or your transfer of data in the request in Office (M2M).

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:

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 Office (M2M)

*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 Paypage ;
• or your transfer of data in the request in Office (M2M).

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:

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

*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 Paypage 
• or your transfer of data in the request in Office (M2M)

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:

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 Office (M2M)

*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 Paypage 
• or your transfer of data in the request in Office (M2M)

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:

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)

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

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)

*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 Paypage
• or your transfer of data in the request in Office (M2M)

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:

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 Office (M2M)

*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):

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

*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):

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

*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 Paypage
• or your transfer of data in the request in Office (M2M)

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 Office (M2M).

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

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

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.

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

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

* 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

Default mode:

Advanced configuration mode:

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.

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

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.

Default mode (simple configuration):

This rule does not populate the complementaryInfo field.

Advanced configuration mode:

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

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

* 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

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

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)

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: