WL SIPS DOCS

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

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

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

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

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

There are 5 categories of NOGO-type rules:

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

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

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

• Positive result

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

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

• Negative result

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

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

• Neutral result

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

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

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

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

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

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

If you would like to use this rule you must:

• activate the rule in the profile. To do so, you must:
  • make a request to your account manager
  • or activate the rule through the fraud GUI
• and set the list of authorised or prohibited card countries. To do so, you must:
  • give your account manager the list of authorised or prohibited countries
  • or set the list of authorised or prohibited countries through the fraud GUI
  • or dynamically override the list of authorised or prohibited countries in your request

Simple configuration mode:

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

Advanced configuration mode:

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

____________________

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

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

There are 2 methods to override the rule parameters dynamically.

METHOD 1:

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

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

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

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

The parameters that apply to this rule are:

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

• POST example:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpCountryList,riskManagementDynamicValue=FRA,BEL,GBR}

• SOAP example:

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

• JSON example:

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

METHOD 2 (deprecated):

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

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

• POST example:

fraudData.allowedCardCountryList=FRA,BEL,GBR

• SOAP example:

<urn:fraudData>
     <urn:allowedCardCountryList>FRA,BEL,GBR</urn:allowedCardCountryList>
</urn:fraudData>

• JSON example:

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

For both methods, the list sent must contain:

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

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

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

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

• POST example:

fraudData.bypassCtrlList=ForeignBinCard

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>ForeignBinCard</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

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

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

If you would like to use this rule you must:

• activate the rule in the profile. To do so, you must:
  • make a request to your account manager
  • or activate the rule through the fraud GUI
• set the list of authorised or prohibited IP address countries. To do so, you must:
  • give your account manager the list of authorised or prohibited countries
  • or set the list of authorised or prohibited countries through the fraud GUI
  • or dynamically override the list of authorised or prohibited countries in your request

Simple configuration mode:

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

Advanced configuration mode:

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

____________________

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

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

There are 2 methods to override the rule parameters dynamically.

METHOD 1:

Choose the parameter to be overriden...

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

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

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

The parameters that apply to this rule are:

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

• POST example:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpCountryList,riskManagementDynamicValue=FRA,BEL,GBR}

• SOAP example:

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

• JSON example:

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

METHOD 2 (deprecated) :

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

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

• POST example:

fraudData.allowedIpCountryList=FRA,BEL,GBR

• SOAP example:

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

• JSON example:

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

For both methods, the list sent must contain:

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

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

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

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

• POST example:

fraudData.bypassCtrlList=IpCountry

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>IpCountry</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

This IP address comes from:

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

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

If you would like to use this rule you must:

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

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

Simple configuration mode:

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

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 Appendix 4: ISO 3166 alphabetical country codes)

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

Choose the parameter to be overriden...

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

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

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

The parameters that apply to this rule are:

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

• POST example:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpCardCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }

• SOAP example:

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

• JSON example:

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

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

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

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

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

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

• POST example:

fraudData.bypassCtrlList=SimilityIpCard

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>SimilityIpCard</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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 Appendix 4: ISO 3166 alphabetical country 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 SimilarityDeliveryBillingCountry instruction.

• POST example:

fraudData.bypassCtrlList=SimilarityDeliveryBillingCountry

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryBillingCountry</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

"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 Appendix 4: ISO 3166 alphabetical country codes)

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.

• POST example:

fraudData.bypassCtrlList=SimilarityDeliveryBillingPostalCode

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryBillingPostalCode</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

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

If you would like to use this rule you must:

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

• and provide the delivery country in the request (deliveryAddress.country field)

Simple configuration mode:

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

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 Appendix 4: ISO 3166 alphabetical country codes)

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

Choose the parameter to be overriden...

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

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

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

The parameters that apply to this rule are:

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

• POST example:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedDeliveryCardCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}

• SOAP example:

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

• JSON example:

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

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

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

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

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

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

• POST example:

fraudData.bypassCtrlList=SimilarityDeliveryCardCountry

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryCardCountry</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

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

If you would like to use this rule you must:

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

• and provide the billing and card country in the request (deliveryAddress.country field)

Simple configuration mode:

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

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 Appendix 4: ISO 3166 alphabetical country codes)

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

Choose the parameter to be overriden...

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

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

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

The parameters that apply to this rule are:

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

• POST example:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedBillingCardCountryCombiList,riskManagementDynamicValue=(FRA,#ZEURO),(#ZEURO,FRA)}

• SOAP example:

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

• JSON example:

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

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

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

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

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

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

• POST example:

fraudData.bypassCtrlList=SimilarityBillingCardCountry

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>SimilarityBillingCardCountry</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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 Appendix 4: ISO 3166 alphabetical country codes)

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

Choose the parameter to be overriden...

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

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

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

The parameters that apply to this rule are:

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

• POST example:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIbanCountryList,riskManagementDynamicValue=FRA,BEL,GBR}

• SOAP example:

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

• JSON example:

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

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

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

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

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

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

• POST example:

fraudData.bypassCtrlList=IbanCountry

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>IbanCountry</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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 Appendix 4: ISO 3166 alphabetical country codes)

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

Choose the parameter to be overriden...

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

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

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

The parameters that apply to this rule are:

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

• POST example:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedDeliveryIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }

• SOAP example:

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

• JSON example:

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

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

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

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

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

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

• POST example:

fraudData.bypassCtrlList=SimilarityDeliveryIbanCountry

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>SimilarityDeliveryIbanCountry</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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 Appendix 4: ISO 3166 alphabetical country codes)

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

Choose the parameter to be overriden...

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

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

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

The parameters that apply to this rule are:

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

• POST example:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedPhoneIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }

• SOAP example:

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

• JSON example:

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

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

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

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

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

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

• POST example:

fraudData.bypassCtrlList=SimilarityPhoneIbanCountry

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>SimilarityPhoneIbanCountry</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

This IP address comes from:

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

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

If you would like to use this rule you must:

• activate the rule in the profile. To do so, you must:
  • make a request to your account manager
  • or activate the rule through the fraud GUI

• set the combinations of authorised or prohibited IP address countries and IBAN countries. To do so, you must:
  • give your account manager the list of authorised or prohibited combinations
  • or set the authorised or prohibited combinations through the fraud GUI
  • or dynamically override the authorised or prohibited combinations in your request

• and provide the customer's IP address in the request, if you are on Sips Office

Simple configuration mode:

Advanced configuration mode:

This rule does not populate the complementaryInfo field.

____________________

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

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

Choose the parameter to be overriden...

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicParam

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

fraudData.
     riskManagementDynamicSettingList.
          riskManagementDynamicSetting.
               riskManagementDynamicValue

The parameters that apply to this rule are:

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

• POST example:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedIpIbanCountryCombiList,riskManagementDynamicValue=(FRA,FRA),(BEL,BEL),(FRA,BEL),(BEL,FRA) }

• SOAP example:

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

• JSON example:

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

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

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

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

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

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

• POST example:

fraudData.bypassCtrlList=SimilarityIpIbanCountry

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>SimilarityIpIbanCountry</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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.

• POST example:

fraudData.bypassCtrlList=VelocityCard

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>VelocityCard</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

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

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

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

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

Example

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

If you would like to use this rule you must:

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

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

• POST example:

fraudData.bypassCtrlList=VelocityIp

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>VelocityIp</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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 MEX
• set the number of transactions carried out and/or the cumulative amount and the cumulation time through the fraud tab in the MEX
• and provide the customer's customer ID in the request (customerId field)

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

• POST example:

fraudData.bypassCtrlList=VelocityCustomerId

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>VelocityCustomerId</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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 MEX
• set the maximum number of customers and the cumulation time through the fraud tab in the MEX
• and provide the customer's customer ID in the request (customerId field)

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

• POST example:

fraudData.bypassCtrlList=MaxCustomerIdPerCard

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>MaxCustomerIdPerCard</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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 MEX
• set the maximum number of cards and the cumulation time through the fraud tab in the MEX
• and provide the customer's customer ID in the request (customerId field)

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

• POST example:

fraudData.bypassCtrlList=MaxCardPerCustomerId

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>MaxCardPerCustomerId</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

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

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

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

Example

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

If you would like to use this rule you must:

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

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

• POST example:

fraudData.bypassCtrlList=MaxCardPerIp

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>MaxCardPerIp</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

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

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

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

Example

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

If you would like to use this rule you must:

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

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

• POST example:

fraudData.bypassCtrlList=MaxIbanPerIp

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>MaxIbanPerIp</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

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

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

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

Example

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

If you would like to use this rule you must:

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

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

• POST example:

fraudData.bypassCtrlList=MaxIpPerIban

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>MaxIpPerIban</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

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

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

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

Example

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

If you would like to use this rule you must:

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

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

• POST example:

fraudData.bypassCtrlList=MaxCustidPerIban

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>MaxCustidPerIban</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

"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 MEX
• set the maximum number of IBANs and the cumulation time through the fraud tab in the MEX
• and provide the customer's identifier in the request (customerId field)

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

• POST example:

fraudData.bypassCtrlList=MaxIbanPerCustid

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>MaxIbanPerCustid</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

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

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

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

Example

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

If you would like to use this rule you must:

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

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

• POST example:

fraudData.bypassCtrlList=MaxMandatePerIp

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>MaxMandatePerIp</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

"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 MEX
• and set the number of transactions made and/or the cumulative amount and the cumulation time through the fraud tab in the MEX

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

• POST example:

fraudData.bypassCtrlList=VelocityMandate

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>VelocityMandate</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

"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 MEX
• and set the number of transactions made and/or the cumulative amount and the cumulation time through the fraud tab in the MEX

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

• POST example:

fraudData.bypassCtrlList=VelocityIban

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>VelocityIban</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

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

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

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

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

If you would like to use this rule you must:

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

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

* XXX: IP address reputation (see Appendix 3: 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.

• POST example:

fraudData.bypassCtrlList=IpReputations

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>IpReputations</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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.

• POST example:

fraudData.bypassCtrlList=HotList

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>HotList</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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.

• POST example:

fraudData.bypassCtrlList=ECard

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>ECard</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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.

• POST example:

fraudData.bypassCtrlList=SystematicAuthorizationCard

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>SystematicAuthorizationCard</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

"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 MEX
• and set the list of authorised or prohibited commercial card issuing countries (if you want to intercept the commercial cards of certain countries). To this end, you must:
  • set the list through the fraud tab in the MEX
  • or dynamically override the list of authorised or prohibited countries in your request

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

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

• POST example:

fraudData.riskManagementDynamicSettingList={riskManagementDynamicParam=
AllowedCommercialCardCountryList,riskManagementDynamicValue=(FRA,BEL)}

• SOAP example:

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

• JSON example:

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

For both methods, the list sent must contain either:

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

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

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

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

• POST example:

fraudData.bypassCtrlList=CorporateCard

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>CorporateCard</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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 MEX
• and set the minimum and/or maximum amount(s) through the fraud tab in the MEX

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.

• POST example:

fraudData.bypassCtrlList=CapCollarAmount

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>CapCollarAmount</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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.

• POST example:

fraudData.bypassCtrlList=CBScheme

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>CBScheme</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

"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 MEX
• and send at least one of the customer's e-mail addresses in the request (billingContact.email, customerContact.email, deliveryContact.email, holderContact.email fields).

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.

• POST example:

fraudData.bypassCtrlList=FreeEmail

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>FreeEmail</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

"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 MEX
• and set the list of prohibited 3-D Secure authentication statuses through the fraud tab in the MEX.

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

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.

• POST example:

fraudData.bypassCtrlList=3DSStatus

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>3DSStatus</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

"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 MEX

• and send at least one of the customer's e-mail addresses in the request (billingContact.email, customerContact.email, deliveryContact.email, holderContact.email fields).

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.

• POST example:

fraudData.bypassCtrlList=EmailSyntax

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>EmailSyntax</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

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

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

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

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

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

• have subscribed to the InfoScore option
• activate the rule in the profile using the fraud tab in the MEX

• set the list of authorised/prohibited indicators through the fraud tab in the MEX

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

* XXX: indicator returned by InfoScore.

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

• POST example:

fraudData.bypassCtrlList=AddressVerification

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>AddressVerification</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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

This verification is only performed for ELV payments.

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

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

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

The verification will return a negative value if:

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

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

• have subscribed to the InfoScore option
• activate the rule in the profile using the fraud tab in the MEX

• and set the list of authorised/prohibited indicators through the fraud tab in the MEX

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

BBB: value of the NCA InfoScore indicator.

CCC: value of RppContentCode for InfoScore NCA KO.

DDD: value of the PAP InfoScore indicator.

EEE: value of RppContentCode for InfoScore PAP KO.

FFF: value of the InfoScore RPP indicator.

This rule does not populate the complementaryInfo field.

Dynamic override 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 AddressVerification instruction.

• POST example:

fraudData.bypassCtrlList=AccountVerification

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>AccountVerification</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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 MEX

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

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

• POST example:

fraudData.bypassCtrlList=ExpiryDate

• SOAP example:

<urn:fraudData>
     <urn:bypassCtrlList>ExpiryDate</urn:bypassCtrlList>
</urn:fraudData>

• JSON example:

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

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 MEX

• set the e-mail address black, grey and/or white list(s)

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

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

• POST example:

Blacklist:

fraudData.bypassCtrlList=BlackEmail

Greylist:

fraudData.bypassCtrlList=GreyEmail

Whitelist:

fraudData.bypassCtrlList=WhiteEmail

• SOAP example:

Blacklist:

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

Greylist:

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

Whitelist:

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

• JSON example:

Blacklist:

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

Greylist:

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

Whitelist:

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

This rule enables you:

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

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

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

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

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

• activate the rule in the profile using the fraud tab in the MEX,

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

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