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:

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

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

Advanced configuration mode:

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

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

____________________

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

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:

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

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

Advanced configuration mode:

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

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

____________________

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

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:

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

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

Advanced configuration mode:

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

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

____________________

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

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

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

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

____________________

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

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

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

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

____________________

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

A, B: postal codes

Dynamic override 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:

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

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

Advanced configuration mode:

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

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

____________________

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

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:

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

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

Advanced configuration mode:

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

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

____________________

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

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:

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

Advanced configuration mode:

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

This rule does not populate the complementaryInfo field.

____________________

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

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:

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

Advanced configuration mode:

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

This rule does not populate the complementaryInfo field.

____________________

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

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:

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

Advanced configuration mode:

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

This rule does not populate the complementaryInfo field.

____________________

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

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:

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

Advanced configuration mode:

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

This rule does not populate the complementaryInfo field.

____________________

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

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

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

If you would like to use this rule you must:

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

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

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

If you would like to use this rule you must:

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

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

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

If you would like to use this rule you must:

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

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

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

If you would like to use this rule you must:

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

If you would like to use this rule you must:

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

If you would like to use this rule you must:

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

If you would like to use this rule you must:

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

If you would like to use this rule you must:

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

If you would like to use this rule you must:

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the 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:

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

If you would like to use this rule you must:

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

If you would like to use this rule you must:

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

If you would like to use this rule you must:

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

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

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

If you would like to use this rule you must:

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

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

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

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

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

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

This rule does not populate the complementaryInfo field.

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

• 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

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

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

This rule does not populate the complementaryInfo field.

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

Parameter	Minimum value	Maximum value
Minimum value	0.01 in your currency	9999999
Maximum value	0.01 in your currency	9999999

Default mode:

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

Advanced configuration mode:

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

This rule does not populate the complementaryInfo field.

__________

* A: transaction amount.

B: minimum amount accepted.

C: maximum amount accepted.

Dynamic override is not available for this rule.

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

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

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

This rule does not populate the complementaryInfo field.

Dynamic override is not available for this rule.

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

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

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

This rule does not populate the complementaryInfo field.