Introduction
WL Sips is a secure multi-channel e-commerce payment solution that complies with the PCI DSS standard. It allows you to accept and manage payment transactions by taking into account business rules related to your activity (payment on despatch, deferred payment, recurring payment, payment in instalments, etc.).
The purpose of this document is to describe the fraud management rules in Go-No-Go mode and to explain how to implement and set them up.
The Go-No-Go terminology corresponds to the binary nature of these rules, which is to have a GO or a NOGO regarding transaction acceptance.
Who does this document target?
This document is intended for merchants who have subscribed to the Go-No-Go fraud risk management offer and wish to enjoy an anti-fraud tool administered by themselves on their management Extranet.
To get an overview of the WL Sips solution, we advise you to consult the following documents:
- Functional presentation
- Functionality set-up guide
- Glossary
Overview
Accessing the Merchant Extranet
All fraud management functions described in this documentation are administered in the Merchant Extranet.
You must have subscribed to the Go-No-Go Fraud risk management service to be able to access these functions.
The Merchant Extranet is accessible through the following URL:
https://mex.fr.worldline.com/portal/home
Access is secure and requires a login and a password.
After login, click on the 'Fraud' tab to administer antifraud functions for your offer.
For more information please refer to the 'Configuring antifraud profiles with the Merchant Extranet' section.
Understanding fraud risk management
Before you begin, it is absolutely essential you understand how fraudsters perform their attacks.
Fraudsters are very well organised and take advantage of most of the weaknesses in the security and legal aspects of e-commerce. In particular:
- they operate internationally
- they use honest locals to carry out their fraudulent activities
- they hide behind overseas proxies
- 3-D Secure is not an obstacle for them
- they renew their types of attacks on a regular basis
Therefore, it is essential you understand fraudulent behaviours at the merchant level when implementing antifraud rules. It is also very important you monitor the results regularly and maintain the correct settings accordingly. This is usually achieved through the creation of a fraud management team on your side.
The fraud risk management engine uses antifraud profiles to evaluate transactions. These profiles consist of rules that you configure.
Antifraud rule management is a virtuous circle beginning with the creation of an effective antifraud profile that suits your business. It continues with regular reviews of fraudulent activities and regular fine-tuning of this profile.
Antifraud rule definition
What is an antifraud rule?
An antifraud rule checks one of the transaction criteria. The controled criterion can be, for example, the card country, the amounts range, the card number, the IP adress, the client id, etc. The rules are sorted by category: geolocation, velocity, velocity, list, basket ans miscellaneous.
For example, the criterion checked can be the card country, the cap collar amounts, the card number, the IP address, the customer ID, etc. The rules are sorted by category: geolocation, velocity, list, basket and miscellaneous.
There are two types of rules: GO-type rules (detecting a favourable condition for the continuation of the transaction) and NOGO-type rules (detecting an unfavourable condition for the transaction).
To be executed, rules must be activated and configured in an antifraud profile. Please refer to the antifraud profile definition section to know how to define such a profile.
Rule types: GO or NOGO
GO-type rule
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.
NOGO-type rule
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
Decisive or informational mode
Rules can be configured in decisive or informational mode.
Decisive mode
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).
Informational mode
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.
Advanced configuration
Some rules do not have necessarily a positive or negative nature (for example geolocation rules: you may want to favour some countries or unfavour others) whereas some others do have necessarily a positive nature (whitelists) or a negative nature (blacklists).
By default, the proposed rules are configurable in simple configuration mode, in which a rule is defined as being positive (GO) or negative (NOGO).
Nevertheless, some rules have an advanced configuration mode. In this mode, the same rule can be both positive (GO) and negative (NOGO). The rule will have a positive, negative or neutral influence on the result of the transaction check depending on the rule setting and the transaction context.
The choice to activate the advanced configuration mode is done during the rule configuration in the profile. It is possible to activate this mode only for certain rules and to let the simple configuration mode for the others.
Rule advanced settings allow specifying the criteria that will have a positive or negative influence on the result.
Example with the cap collar amount rule configured as decisive:
Rule configuration (profile) | Transaction amount | Result | Consequences on pre-authentification mode | |
---|---|---|---|---|
Simple configuration mode |
|
45 | Negative | Trigger 3-D Secure |
150 | Neutral | Proceed to the next rules | ||
250 | Negative | Trigger 3-D Secure | ||
Advanced configuration mode | Positive range:
Negative range:
|
45 | Neutral | Proceed to the next rules |
100 | Positive | Trigger 3-D Secure | ||
200 | Neutral | Proceed to the next rules | ||
350 | Negative | Trigger 3-D Secure | ||
450 | Neutral | Proceed to the next rules |
Example with the 3-D Secure authentication rule configured as decisive:
Rule configuration (profile) | 3-D Secure status of the transaction | Result | Consequences on pre-authorisation mode | |
---|---|---|---|---|
Simple configuration mode | Negative statuses: ERROR |
SUCCESS | Neutral | Proceed to the next rules |
ERROR | Negative | Refuse the transaction before the authorisation request | ||
Advanced configuration mode | Negative statuses: ERROR Positive statuses: SUCCESS |
SUCCESS | Positive | Proceed to the authorisation request without doing the next rules |
ERROR | Negative | Refuse the transaction before the authorisation request |
Execution modes and consequences on acceptance
There are two execution modes for the WL Sips fraud risk management tool:
- pre-authorisation mode: makes it possible to stop fraudulent transactions prior to the authorisation request
- pre-authentication mode: makes it possible to bypass 3-D Secure for transactions considered as safe
Pre-authorisation mode
In pre-authorisation mode (default mode of the WL Sips fraud risk management tool), rules are executed prior to the authorisation request and following the 3-D Secure authentication (if the webshop is 3-D Secure enrolled). If the checking result is negative, the transaction will be declined prior to the authorisation request.
For means of payment with a redirection to a specific page for the related means of payment (Paypal for example), the pre-authorisation checking is trigerred prior to the redirection.
Depending on your needs, you define your pre-authorisation profile(s) by combining:
- GO and/or NOGO rules
- decisive and/or informational rules
A profile is informational when all of its rules are informational.
A profile is decisive when all of its rules are decisive.
A profile is mixed when it includes both informational and decisive rules.
Profile type | WL Sips / merchant | Consequences on acceptance |
---|---|---|
Informational profile | WL Sips | No consequences, WL Sips proceeds with the authorisation request. |
Merchant | The merchant must analyse the results of the rules and decide how the transaction should continue using the cancellation or validation operations. | |
Decisive profile | WL Sips | If the result is negative, WL Sips
denies the transaction and no authorisation request is
made. If the result is positive or neutral, WL Sips carries on the acceptance process by making an
authorisation request. |
Merchant | No consequences on the transaction acceptance since the
merchant appointed WL Sips to make decisions with
regard to fraud. However, the merchant can analyse the
reason. |
|
Mixed profile | WL Sips | Ditto decisive profile. |
Merchant | If the transaction is declined, there are no
consequences for the merchant. If the transaction is
accepted, the merchant must analyse the results of the
informational rules and decide what to do next. |
Pre-authentification mode
In pre-authentication mode, rules are executed prior to the 3-D Secure authentication. If the checking result is positive, the 3-D Secure authentication is bypassed and WL Sips carries on with the authorisation request.
This mode applies only to card transactions with 3-D Secure authentication.
Depending on your needs, you define your pre-authentication profile(s) by combining the GO and/or NOGO rules.
A profile is decisive when all of its rules are decisive.
Only decisive rules can be configured in a Go-No-Go profile for the pre-authentication step. Informative rules in such a profile are useless at this step.
Profile type | WL Sips / merchant | Consequences on acceptance |
---|---|---|
Decisive profile | WL Sips | If the result is positive, WL Sips
bypasses the 3-D Secure authentication and carries on with
pre-authorisation checking. If the result is negative ou
neutral, WL Sips carries on with 3-D Secure
authentication prior to doing the pre-authorisation
checking. |
Merchant | The merchant must analyse the results of the rules and decide how the transaction should continue using the cancellation or validation operations. |
Since the 3-D Secure authentication bypass takes place only in case of a positive result, it is important to configure at least one GO rule as decisive so as to bypass the 3-D Secure authentication for some customers.
Antifraud profile definition
What is an antifraud profile?
An antifraud profile is a set of rules that you configure after choosing them from the rules made available by the distributor of the ePayment solution. Rules are executed prior to the 3-D Secure authentication and to the authorisation request according to your configuration (to understand the pre-authentication and pre-authorisation modes, please refer to the execution modes and their consequences on acceptance).
There are three types of antifraud profiles:
- the distributor's "offering" profile
- profile templates
- merchant profiles
A distributor's "offering" profile is defined by the distributor and administered by Worldline. It defines the scope of the available rules and of the configurations that may be mandatory. If an webshop has no suitable profile for the means of payment used, then the distributor’s offering profile is used.
Profile templates are defined and administered by the distributor. They are used as templates for creating merchant profiles.
Merchant profiles are defined by you for your webshop and are administered by you and/or the distributor (depending on the distributor's choice). They can be created from profile templates. The terms "webshop profile" may be used in this document. They are equivalent to the merchant profile.
Throughout this document, the notion of "profile" will refer to merchant profiles.
Antifraud profiles are set up through the fraud GUI of your extranet.
Profiles per means of payment and default profile
In most cases, you define a single antifraud profile that is applied to all transactions regardless of the means of payment used. However, you can also define additional profiles the settings of which suit one or more specific means of payment.
When a transaction must be evaluated, the risk management system first searches the webshop configuration for an antifraud profile specific to the means of payment used.
If no such profile is found, the system looks for the webshop default profile. This profile makes it possible to analyse the transactions that were not processed by the profiles specific to the means of payment.
To create a default profile, simply create a profile without associating any means of payment with it.
Only one profile can be active for a given means of payment. Likewise, only one default profile can be active.
For example, there can be:
- a dedicated profile for CB, VISA and MASTERCARD
- a dedicated profile for AMEX
- a default profile that will check the transactions for which other means of payment are used.
Which means three active profiles at the same time.
You can create as many inactive profiles as required. This allows, for example, to keep profiles in reserve for particular periods of the year (sales, holidays, etc.).
Execution of an antifraud profile
The rules are executed sequentially according to the order defined in the profile settings.
The first decisive rule that produces a positive result for GO rules or a negative result for NOGO rules prevents the execution of the rest of the decisive rules.
Informational rules are systematically executed.
Please refer to the 'Expression of rule results' section for the restitution of rule results in informational or decisive mode. The diagram below shows how rules are trigerred.
Bypassing rules dynamically
You can bypass some rules of the profile dynamically in the transaction request. Please refer to the Appendix No. 1, 'Bypassing some files of the profile dynamically' for the list of bypassing instructions.
Overriding rules dynamically
You can override some rules of the profiles dynamically in the transaction request.
The methods for overriding rules dynamically are described in the 'Descriptions and implementation of rules' section.
Expression of rule results
Pre-authorisation mode
The executing result of the pre-authorisation profile is returned in the complementaryCode, complementaryInfo, preAuthorisationProfile, preAuthorisationProfileValue and preAuthorisationRuleResultList fields:
- complementaryCode contains the specific code of the decisive or informative rule which returned a negative result (for NOGO type rules) or a positive result (for GO type rules). If no decisive or informative rule returned a negatie or positive result, the field is set to 00.
- complementaryInfo* contains 3 types of information:
- the result of each rule (decisive or informative) executed in
the merchant profile, in the following format:
- <RULE_RESULT XX=Y XX=Y … XX=Y />, where:
- XX is a rule code. For rule codes, please refer to the list of rules
- Y is the executing result:
=> N: negative result
=> P: positive result
=> O: neutral result
=> U: rule not executed because of incomplete transaction data (i.e. data not specified)
=> X: rule not applicable to this transaction type
=> B: rule not executed because you bypassed it
=> E: rule not executed due to a technical error
=> D: rule not executed due to a dynamic overriding error
- <RULE_RESULT XX=Y XX=Y … XX=Y />, where:
- the complementary information produced by the executed rules. For detailed information, please refer to the 'Description and implementation of rules' section. Please note that only certain rules feed the complementaryInfo field.
- the information on the payment card in use, if any. For detailed information, please refer to the 'Card information' section.
- the result of each rule (decisive or informative) executed in
the merchant profile, in the following format:
- preAuthorisationProfile contains the name of the antifraud profile executed prior to the authorisation request.
- preAuthorisationProfileValue contains the unique identifier of the executed profile version. This information is useful to retrieve the profile in the same configuration as when the rules were executed.
- preAuthorisationRuleResultList contains a list of detailed results for each rule executed prior to the authorisation request.
Each object contained in the preAuthorisationRuleResultList field corresponds to a rule result and contains the following values:
- ruleCode, the rule code. For rule codes please refer to the 'List of rules' section.
- ruleType, the rule type. For the rule type of each rule please refer to the 'List of rules' section. If the advanced configuration mode is activated for a rule, the value of the ruleType field is set to "MI".
- ruleWeight:
- D: if the rule is configured as decisive in the profile
- I: if the rule is configured as informative in the profile
- ruleSetting, indicates the rule configuration type:
- D: dynamic in the transaction
- S: static in the merchant configuration
- I: static and imposed by the distributor offer
- N: no configuration (when the rule does not require any configuration),
- ruleResultIndicator, the executing result of the rule:
- N: negative result
- P: positive result
- O: neutral result
- U: rule not executed because of incomplete transaction data (i.e. data not specified)
- X: rule not applicable to this transaction type
- B: rule not executed because you bypassed it
- E: rule not executed due to a technical error
- D: rule not executed due to a dynamic overriding error
- ruleDetailedInfo, complementary information produced by the executed rule. Please refer to the 'Description and implementation of rules' section for detailed information about each rule.
You are returned these fields in the following interfaces:
- automatic and manual responses from Sips Paypage
- responses from Sips Office connectors (Checkout, CashManagement (duplication) and Diagnostic services)
- Extranet
- Transactions report except the preAuthorisationRuleResultList field
Informative profile
Field | Description |
---|---|
Neutral result | |
responseCode | Value set depending on the authorisation response |
acquirerResponseCode | Value set depending on the authorisation response |
complementaryCode | Value set depending on the executed informative rules, otherwise 00** |
complementaryInfo* | Value set depending on the executed rules |
preAuthorisationProfile | Name of the executed antifraud profile |
preAuthorisationProfileValue | Unique identifier of the executed profile |
preAuthorisationRuleResultList | List of detailed results for each executed rule |
Decisive or mixed profile
Field | Description |
---|---|
Neutral result | |
responseCode | Value set depending on the authorisation response |
acquirerResponseCode | Value set depending on the authorisation response |
complementaryCode | Value set depending on the executed informative rules, otherwise 00* |
complementaryInfo* | Value set depending on the executed rules |
preAuthorisationProfile | Name of the executed antifraud profile |
preAuthorisationProfileValue | Unique identifier of the executed profile |
preAuthorisationRuleResultList | List of detailed results for each executed rule |
Positive result | |
responseCode | Value set depending on the authorisation response |
acquirerResponseCode | Value set depending on the authorisation response |
complementaryCode | Value set depending on the GO rule that generated the acceptance |
complementaryInfo* | Value set depending on the executed rules |
preAuthorisationProfile | Name of the executed antifraud profile |
preAuthorisationProfileValue | Unique identifier of the executed profile |
preAuthorisationRuleResultList | List of detailed results for each executed rule |
Negative result | |
responseCode | Value set to 05 |
acquirerResponseCode | Not specified |
complementaryCode | Value set depending on the NOGO rule that generated the refusal |
complementaryInfo* | Value set depending on the executed rules |
preAuthorisationProfile | Name of the executed antifraud profile |
preAuthorisationProfileValue | Unique identifier of the executed profile |
preAuthorisationRuleResultList | List of detailed results for each executed rule |
* The complementaryInfo field is deprecated as of version 17R1. It will no longer evolve and will eventually stop being populated. The information it contains is available in an improved version, in the preAuthorisationRuleResultList field.
** See the list of rules
Pre-authentication mode
The executing result of the pre-authentication profile is returned in the preAuthenticationProfileValue, preAuthenticationProfile, preAuthenticationProfileValue and preAuthenticationRuleResultList fields:
- preAuthenticationValue specific code of the rule which returned a negative result (for NOGO type rules) or a positive result (for GO type rules). If no decisive rule returned a negative or positive result, the field is empty.
- preAuthenticationProfile contains the name of the antifraud profile executed prior to authentication.
- preAuthenticationProfileValue contains the unique identifier of the executed profile version. This information is useful to retrieve the profile in the same configuration as when the checkings were executed.
- preAuthenticationRuleResultList contains a list of detailed results for each rule executed prior to the authorisation request.
Each object contained in the preAuthenticationRuleResultList field corresponds to a rule result and contains the same values as those in the preAuthorisationRuleResultList field in pre-authorisation mode. Please refer to the 'Pre-authorisation mode' section to know the content of this field.
You are returned these fields in the following interfaces:
- automatic and manual responses from Sips Paypage
- responses from Sips Office connectors (CashManagement (duplication) and Diagnostic)
- Extranet
- Transactions report except the preAuthorisationRuleResultList field
Field | Description |
---|---|
Neutral result | |
preAuthenticationValue | Value set to empty* |
preAuthenticationProfile | Name of the executed antifraud profile |
preAuthenticationProfileValue | Unique identifier of the executed profile |
preAuthenticationRuleResultList | List of detailed results for each executed rule |
Positive result (3DS bypassed) | |
preAuthenticationValue | Value set depending on the GO rule that generated the acceptance* |
preAuthenticationProfile | Name of the executed antifraud profile |
preAuthenticationProfileValue | Unique identifier of the executed profile |
preAuthenticationRuleResultList | List of detailed results for each executed rule |
Negative result | |
preAuthenticationValue | Value set depending on the NOGO rule that generated the refusal* |
preAuthenticationProfile | Name of the executed antifraud profile |
preAuthenticationProfileValue | Unique identifier of the executed profile |
preAuthenticationRuleResultList | List of detailed results for each executed rule |
____________________
* See the various codes in the list of rules
Limitations of use
Means of payment
The global WL Sips offering supports many international means of payment such as Visa/Mastercard, the Paypal digital wallet, iDeal transfers, Sepa Direct Debits, etc.
The rules do note necessarily apply to all means of payment (e.g. InfoScore rules only apply to ELV transactions).
For single message** means of payment, defining informational profiles is technically feasible, but the checking result will have no consequences on the transaction acceptance.
Please refer to the 'Correspondences between means of payment and antifraud rules' section to know whether an antifraud rule applies to a means of payment or not.
____________________
** Single message means of payment: authorisation and capture are performed in a single step, e.g. transfers with Ideal, Sofort, Paybutton or Paypal in immediate mode. Dual message means of payment: authorisation and capture are performed in two steps.
Operations
Antifraud profiles apply to transactions and cash management operations that result in a new transaction being created (duplication).
Thus, standard cash management operations that deal with existing transactions (validation, cancellation, refund, etc.) and credit holder transactions are not subject to antifraud checkings.
Payment in n instalments
For payments in n instalments, only the first instalment is subject to antifraud checkings.
Data transfer in the request
For some rules, data must be sent in the request. The latter will not be executed if the data is missing.
For example, for the customer ID velocity rule, the customer ID must be sent in the request. Otherwise the rule will not be executed.
Execution mode and rules
The rules do not necessarily apply to both modes (pre-authentication et pre-authorisation).
For example the 3-D Secure authentication rule is not available in pre-authentication. Indeed, this rule is based on the 3-D Secure authentication result, but the pre-authentication antifraud profile is applied first. So this rule is of no use prior to authentication.
List of rules
Card information
In the case of a card payment, some card information is returned in the complementaryInfo field. The return information includes:
- card country
- card scheme name
- card issuer code and name
- card product code and name
- card product profile
information is returned in the following format: <CARD_INFOS BDOM=<card issuer name> COUNTRY=<card country> PRODUCTCODE=<card product code> NETWORK=<card scheme name> BANKCODE=<card issuer code> PRODUCTNAME=<card product name> PRODUCTPROFILE=<card product profile>/>$
For the list of country codes, please refer to Appendix 4: ISO 3166 alphabetical country codes.
For the list of card schemes, please refer to Appendix 8: list of card schemes.
For the list of product profiles, please refer to Appendix 9: list of product profiles.
Description and implementation of rules
Geolocation rules: address and country
Card country
Rule description
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.
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile. To do so, you must:
- make a request to your account manager
- or activate the rule through the fraud GUI
- and set the list of authorised or prohibited card 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
Our fraud module is based on the CIS (Card Info Service) database, which includes information on BIN ranges. However, this reference source does not include the nationality of American Express cards. It is therefore impossible for us, via the fraud module, to block American Express cards via the "Country card" rule.
Expression of the result
Simple configuration mode:
Use case | 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)
Dynamic override
You can dynamically supply a list of authorised or prohibited countries in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.
There are 2 methods to override the rule parameters dynamically.
METHOD 1:
Choose the parameter to be overriden in the field...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...and send the country list in the following field:
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
The parameters that apply to this rule are:
- default mode (simple configuration):
- AllowedCardCountryList for the list of authorised countries
- DeniedCardCountryList for the list of prohibited countries
- advanced configuration mode:
- NDeniedCardCountryList for the list of disadvantaged countries
- NDeniedExceptCardCountryList for the list of non-disadvantaged countries
- PAllowedCardCountryList for the list of advantaged countries
- PAllowedExceptCardCountryList for the list non-advantaged countries
- 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.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the ForeignBinCard instruction.
- POST example:
fraudData.bypassCtrlList=ForeignBinCard
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>ForeignBinCard</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["ForeignBinCard"]
}
IP address country
Rule description
This rule enables you to decide whether to accept or decline to provide a service depending on the country associated with the customer's IP address.
The rule checks whether the IP address country is on a list of authorised or prohibited countries. This IP address comes from:
- the automatic detection performed by the customer's browser in Sips Paypage. In this case, doubts may remain about the customer's country, mostly due to the dynamic allocation of IP addresses by some ISPs, or because of dynamic addresses.
- or from the data transfer you do in the request in Sips Office.
If there is no list of authorised or prohibited countries, the rule considers the merchant's country code as the only one authorised.
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile. To do so, you must:
- make a request to your account manager
- or activate the rule through the fraud GUI
- set the list of authorised or prohibited IP address countries. To do
so, you must:
- give your account manager the list of authorised or prohibited countries
- or set the list of authorised or prohibited countries through the fraud GUI
- or dynamically override the list of authorised or prohibited countries in your request
Expression of the result
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)
Dynamic override
You can dynamically supply a list of authorised or prohibited countries in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.
There are 2 methods to override the rule parameters dynamically.
METHOD 1:
Choose the parameter to be overriden...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...and send the country list in the following field:
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
The parameters that apply to this rule are:
- default mode (simple configuration) :
- AllowedIpCountryList for the list of authorised countries
- DeniedIpCountryList for the list of prohibited countries
- advanced configuration mode:
- NDeniedIpCountryList for the list of disadvantaged countries
- NDeniedExceptIpCountryList for the list of non-disadvantaged countries
- PAllowedIpCountryList for the list of advantaged countries
- PAllowedExceptIpCountryList for the list of non-advantaged countries
- 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.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the IpCountry instruction.
- POST example:
fraudData.bypassCtrlList=IpCountry
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>IpCountry</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["IpCountry"]
}
IP and card country
Rule description
This rule enables you to decide whether to accept or decline to provide a service depending on the combination of the card country and the customer’s IP address country.
The rule queries the BIN range and IP address range databases to check whether the combination of both countries is on a list of authorised or prohibited country combinations.
This IP address comes from:
- the automatic detection performed by the customer's browser in Sips Paypage. In this case, uncertainty may remain about the customer's country, due mainly to the dynamic allocation of IP addresses by some ISPs or to dynamic addresses.
- or from the data transfer you do in the request in Sips Office.
If there is no authorised or prohibited combination, the rule checks whether the card country matches the IP address country.
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile. To do so, you must:
- make a request to your account manager
- or activate the rule through the fraud GUI
- set the list of authorised or prohibited card 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.
Expression of the result
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)
Dynamic override
You can dynamically supply the list of IP address countries/card countries combinations in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.
Choose the parameter to be overriden...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...and set the country list in the following field:
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
The parameters that apply to this rule are:
- default mode (simple configuration):
- AllowedIpCardCountryCombiList for the authorised IP and card 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.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilityIpCard instruction.
- POST example:
fraudData.bypassCtrlList=SimilityIpCard
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>SimilityIpCard</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["SimilityIpCard"]
}
Delivery and billing country
Rule description
This rule enables you to decide whether to accept or decline to provide a service by checking whether the delivery country matches the billing country.
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile. To do so, you must:
- make a request to your account manager
- or activate the rule through the fraud GUI
and provide the delivery and billing country in the request (billingAddress.country and deliveryAddress.country fields).
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityDeliveryBillingCountry instruction.
- POST example:
fraudData.bypassCtrlList=SimilarityDeliveryBillingCountry
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>SimilarityDeliveryBillingCountry</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["SimilarityDeliveryBillingCountry"]
}
Delivery and billing postal codes
Rule description
This rule enables you to decide whether to accept or decline to provide a service by checking whether the delivery postal code matches the billing postal code.
This rule can only be activated if the rule that compares the delivery and billing countries also is. Indeed, comparing the postal codes is irrelevant if the countries are not the same.
Conditions of use
If you would like to use this rule you must:
- have the "Delivery and billing country" rule activated
- activate the rule in the profile. To do so, you must:
- make a request to your account manager
- or activate the rule through the fraud GUI
and provide the delivery and billing postal codes in the request (billingAddress.zipCode and deliveryAddress.zipCode fields).
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityDeliveryBillingPostalCode instruction.
- POST example:
fraudData.bypassCtrlList=SimilarityDeliveryBillingPostalCode
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>SimilarityDeliveryBillingPostalCode</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["SimilarityDeliveryBillingPostalCode"]
}
Delivery and card country
Rule description
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.
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile. To do so, you must:
- make a request to your account manager
- or activate the rule through the fraud GUI
- set the list of authorised or prohibited delivery and card 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)
Expression of the result
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)
Dynamic override
You can dynamically supply a list of authorised or prohibited delivery and card country combinations in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.
Choose the parameter to be overriden...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...and send the country list in the following field:
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
The parameters that apply to this rule are:
- default mode (simple configuration):
- AllowedDeliveryCardCountryCombiList for the authorised delivery and card country combinations
- DeniedDeliveryCardCountryCombiList for the prohibited delivery and card country combinations
- advanced configuration mode:
- NDeniedDeliveryCardCountryCombiList for the list of disadvantaged countries
- NDeniedExceptDeliveryCardCountryCombiList for the list of non-disadvantaged countries
- PAllowedDeliveryCardCountryCombiList for the list of advantaged countries
- PAllowedExceptDeliveryCardCountryCombiList for the list of non-advantaged countries
- 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.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityDeliveryCardCountry instruction.
- POST example:
fraudData.bypassCtrlList=SimilarityDeliveryCardCountry
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>SimilarityDeliveryCardCountry</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["SimilarityDeliveryCardCountry"]
}
Billing and card country
Rule description
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.
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile. To do so, you must:
- make a request to your account manager
- or activate the rule through the fraud GUI
- set the list of authorised or prohibited billing and card country
combinations. To do so, you must:
- give your account manager the list of authorised or prohibited combinations
- or set the authorised or prohibited combinations through the fraud GUI
- or dynamically override the authorised or prohibited combinations in your request
and provide the billing and card country in the request (deliveryAddress.country field)
Expression of the result
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)
Dynamic override
You can dynamically supply a list of authorised or prohibited billing and card country combinations in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.
Choose the parameter to be overriden...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...and send the country list in the following field:
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
The parameters that apply to this rule are:
- default mode (simple configuration) :
- AllowedBillingCardCountryCombiList for the authorised billing country and card country combinations
- DeniedBillingCardCountryCombiList for the prohibited billing country and card country combinations
- advanced configuration mode:
- NDeniedBillingCardCountryCombiList for the list of disadvantaged countries
- NDeniedExceptBillingCardCountryCombiList for the list of non-disadvantaged countries
- PAllowedBillingCardCountryCombiList for the list of advantaged countries
- PAllowedExceptBillingCardCountryCombiList for the list of non-advantaged countries
- 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.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityBillingCardCountry instruction.
- POST example:
fraudData.bypassCtrlList=SimilarityBillingCardCountry
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>SimilarityBillingCardCountry</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["SimilarityBillingCardCountry"]
}
IBAN country
Rule description
The IBAN country rule enables you to measure the risk of a purchase based on the issuing country of the customer's IBAN.
The rule is executed on all payment transactions made with a SDD means of payment, and will analyse the IBAN number to extract the country from it and check whether it is included in a list of authorised or prohibited countries.
If no list of authorised or prohibited countries has been defined, the rule considers your country as the only one authorised.
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile. To do so, you must:
- make a request to your account manager
- or activate the rule through the fraud GUI
- set the list of authorised or prohibited IBAN countries. To do so,
you must:
- give your account manager the list of authorised or prohibited countries
- or set the authorised or prohibited countries through the fraud GUI
- or dynamically override the authorised or prohibited countries in your request
Expression of the result
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)
Dynamic override
You can dynamically supply a list of authorised countries or a list of prohibited countries in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.
Choose the parameter to be overriden...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...and send the country list in the following field:
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
The parameters that apply to this rule are:
- default mode (simple configuration):
- AllowedIbanCountryList for the list of authorised countries
- DeniedIbanCountryList for the list of prohibited countries
- advanced configuration modfe:
- NDeniedIbanCountryList for the list of disadvantaged countries
- NDeniedExceptIbanCountryList for the list of non-disadvantaged countries
- PAllowedIbanCountryList for the list of advantaged countries
- PAllowedExceptIbanCountryList for the list of non-advantaged countries
- 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.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the IbanCountry instruction.
- POST example:
fraudData.bypassCtrlList=IbanCountry
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>IbanCountry</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["IbanCountry"]
}
Delivery and IBAN country
Rule description
This rule enables you to measure the risk of a purchase, based on the delivery country/customer's IBAN country combination.
The rule is executed on all payment transactions made with a SDD means of payment, and checks the presence of the delivery country/IBAN country combination in the list of authorised or prohibited combinations.
If no list of authorised or prohibited countries has been defined, the rule checks whether the delivery country matches the IBAN country.
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile. To do so, you must:
- make a request to your account manager
- or activate the rule through the fraud GUI
- set the combinations of authorised or prohibited delivery countries
and IBAN countries. To do so, you must:
- give your account manager the list of authorised or prohibited combinations
- or set the authorised or prohibited combinations through the fraud GUI
- or dynamically override the authorised or prohibited combinations in your request
and provide the delivery country in the request (deliveryAddress.country field).
Expression of the result
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)
Dynamic override
You can dynamically supply a list of delivery and IBAN country combinations in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.
Choose the parameter to be overriden...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...and send the country list in the following field:
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
The parameters that apply to this rule are:
- default mode (simple configuration):
- AllowedDeliveryIbanCountryCombiList for the authorised delivery country and IBAN country combinations
- DeniedDeliveryIbanCountryCombiList for the prohibited delivery country and IBAN country combinations
- advanced configuration mode:
- NDeniedDeliveryIbanCountryCombiList for the list of disadvantaged countries
- NDeniedExceptDeliveryIbanCountryCombiList for the list of non-disadvantaged countries
- PAllowedDeliveryIbanCountryCombiList for the list of advantaged countries
- PAllowedExceptDeliveryIbanCountryCombiList for the list of non-advantaged countries
- 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.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityDeliveryIbanCountry instruction.
- POST example:
fraudData.bypassCtrlList=SimilarityDeliveryIbanCountry
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>SimilarityDeliveryIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["SimilarityDeliveryIbanCountry"]
}
Phone and IBAN country
Rule description
This rule enables you to measure the risk of a purchase, based on the customer's mobile phone number country/customer's IBAN country combination.
The rule is executed on all payment transactions made with a SDD means of payment, and checks the presence of the customer's mobile phone number country/IBAN country combination in the list of authorised or prohibited combinations.
The phone number is obtained by analysing its dialling code. If the dialling code is not specified, the country cannot be retrieved.
If no list of authorised or prohibited combinations has been defined, the rule checks whether the customer's mobile phone number country matches the IBAN country.
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile. To do so, you must:
- make a request to your account manager
- or activate the rule through the fraud GUI
- set the combinations of authorised or prohibited phone number
countries and IBAN countries. To do so, you must:
- give your account manager the list of authorised or prohibited combinations
- or set the authorised or prohibited combinations through the fraud GUI
- or dynamically override the authorised or prohibited combinations in your request
and provide the customer's mobile phone number in the request (with dialling code; the mobile field in one or several contact information groups: billingContact, customerContact, deliveryContact, holderContact).
Expression of the result
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)
Dynamic override
You can dynamically supply a list of customer's mobile phone number country/IBAN country combinations in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.
Choose the parameter to be overriden...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...and send the country list in the following field:
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
The parameters that apply to this rule are:
- default mode (simple configuration):
- AllowedPhoneIbanCountryCombiList for the authorised customer's mobile phone number country and IBAN country combinations
- DeniedPhoneIbanCountryCombiList for the prohibited customer's mobile phone number country and IBAN country combinations
- advanced configuration mode:
- NDeniedPhoneIbanCountryCombiList for the list of disadvantaged countries
- NDeniedExceptPhoneIbanCountryCombiList for the list of non-disadvantaged countries
- PAllowedPhoneIbanCountryCombiList for the list of advantaged countries
- PAllowedExceptPhoneIbanCountryCombiList for the list of non-advantaged countries
- 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.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityPhoneIbanCountry instruction.
- POST example:
fraudData.bypassCtrlList=SimilarityPhoneIbanCountry
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>SimilarityPhoneIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["SimilarityPhoneIbanCountry"]
}
IP address and IBAN country
Rule description
This rule enables you to measure the risk of a purchase, based on the customer's IP address country/customer's IBAN country combination.
The rule is executed on all payment transactions made with a SDD means of payment, and checks whether the IP address country/IBAN country combination is on a list of authorised or prohibited country combinations.
This IP address comes from:
- the automatic detection via the customer's browser in Sips Paypage. In this case, uncertainty may remain regarding the customer's country, due mainly to the dynamic allocation of IP addresses by some ISPs or to dynamic IP addresses.
- or from the data transfer you do in the request in Sips Office.
If there is no authorised or prohibited combination, the rule checks whether the customer's IP address country matches the IBAN country.
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile. To do so, you must:
- make a request to your account manager
- or activate the rule through the fraud GUI
- set the combinations of authorised or prohibited IP address
countries and IBAN countries. To do so, you must:
- give your account manager the list of authorised or prohibited combinations
- or set the authorised or prohibited combinations through the fraud GUI
- or dynamically override the authorised or prohibited combinations in your request
and provide the customer's IP address in the request, if you are on Sips Office
Expression of the result
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)
Dynamic override
You can dynamically supply a list of IP address country/IBAN country combinations in the request. If a list is sent in the request, it takes precedence over any possible configuration except if it conflicts with the configuration imposed by the distributor.
Choose the parameter to be overriden...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...and send the country list in the following field:
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
The parameters that apply to this rule are:
- default mode (simple configuration):
- AllowedIpIbanCountryCombiList for the authorised IP address country and IBAN country combinations
- DeniedIpIbanCountryCombiList for the prohibited IP address country and IBAN country combinations
- advanced configuration mode:
- NDeniedIpIbanCountryCombiList for the list of disadvantaged countries
- NDeniedExceptIpIbanCountryCombiList for the list of non-disadvantaged countries
- PAllowedIpIbanCountryCombiList for the list of advantaged countries
- PAllowedExceptIpIbanCountryCombiList for the list of non-advantaged countries
- 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.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityIpIbanCountry instruction.
- POST example:
fraudData.bypassCtrlList=SimilarityIpIbanCountry
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>SimilarityIpIbanCountry</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["SimilarityIpIbanCountry"]
}
Velocity rules
The velocity rules calculate the cumulation of the amount or quantity for an aspect of the transaction over one given period (sometimes two) and compare the result to a threshold that should not be exceeded. They allow you to supervise the activities of a customer, an IP address, a card, etc.
For example, velocity rules can trigger a NOGO when the cumulated amount spent by a particular card exceeds 1,500 € over the last 24h or when a customer has made more than 10 transactions over the last week.
There are two ways to calculate the velocity:
- By default, the velocity is calculated for a particular webshop.
- You can also calculate the velocity by adding up the activities of several webshops. In this case, this velocity is known as a "shared velocity'" and allows widening the perimeter of the supervision.
To set up a shared velocity, you need to contact your account manager for the configuration. Two steps are to be followed:
- first, create a shared velocity by choosing its type (card velocity, IP address velocity, etc.)
- then associate the shared velocity to the concerned webshops
During the execution of an antifraud control, when the shared velocity rule is active in the applied merchant profile, activities will be caculated and added to the activities of other webshops sharing the same velocity.
5 shared velocities can be set up per type of velocity rule in a commercial group.
Card velocity
Rule description
This rule enables you to assess the risk of a purchase by checking the card activity (the cumulative number and/or amount of transactions).
The rule is executed on all payment transactions made with a card. The velocity calculation takes into account transactions that have been accepted beforehand over the given periods. It is also possible to add the refused transactions to this calculation.
The rule checks a card activity over two separate periods. You must specify the number and/or cumulative amount of transactions, as well as the respective periods, when setting up the profile.
Example
The following table describes the evolution of the payment card history in the event that you chose to limit purchases on your website to 2 times for the same card, for a total amount of €500 per month (30 days):
Transaction date | Payment details | Rule result | Card velocity (number of transactions) |
Card velocity (cumulative amount) |
History situation (last 30 days) |
---|---|---|---|---|---|
01/10/2018 | Transaction TR1 Amount: €100 Card:
CB1 |
OK | 1 | €100 | TR1 01/10/2018 CB1 €100 |
07/10/2018 | Transaction TR2 Amount: €400 Card:
CB2 |
OK | 1 | €400 | TR1 01/10/2018 CB1 €100 OK TR2 07/10/2018 CB2
€400 |
10/10/2018 | Transaction TR3 Amount: €400 Card:
CB2 |
KO | 2 | €800 (> 500) |
TR1 01/10/2018 CB1 €100 OK TR2 07/10/2018 CB2 €400
OK TR3 10/10/2018 CB2 €400 |
12/10/2018 | Transaction TR4 Amount: €200 Card:
CB1 |
OK | 2 | €300 | TR1 01/10/2018 CB1 €100 OK TR2 07/10/2018 CB2
€400 OK TR3 10/10/2018 CB2 €400 KO TR4
12/10/2018 CB1 €200 |
15/10/2018 | Transaction TR5 Amount: €100 Card:
CB1 |
KO | 3 (> 2) |
€400 | TR1 01/10/2018 CB1 €100 OK TR2 07/10/2018 CB2
€400 TR3 10/10/2018 CB2 €400 KO TR4
12/10/2018 CB1 €200 OK TR5 15/10/2018 CB1
€100 |
02/11/2018 (> 30 d) |
Transaction TR6 Amount: €300 Card:
CB1 |
OK | 1 | €300 | TR6 02/11/2018 CB1 €300 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile. To do so, you must:
- make a request to your account manager
- or activate the rule through the fraud GUI
- and set the number of transactions carried out and/or the cumulative
amount, as well as the respective periods. To do so, you must:
- specify these settings to your account manager
- or set them through the Fraud GUI
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days:
99 days In weeks: 14 weeks |
Maximum cumulative amount | 0.01 over the period, in your currency | 9999999 |
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum number of transactions | 1 transaction over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the VelocityCard instruction.
- POST example:
fraudData.bypassCtrlList=VelocityCard
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>VelocityCard</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
fraudData": {
"bypassCtrlList":["VelocityCard"]
}
Limitations of use
In the case of a payment in multiple instalments, only the first instalment is taken into account.
During the validation, cancellation and refund of the transaction, the amount that is not validated, cancelled or refunded is not substracted from the cumulative amount.
IP address velocity
Rule description
This rule enables you to assess the risk of a purchase by verifying the activity (number and/or cumulative amount of the transactions) of a customer from an IP address over a given period.
The rule is executed on all succeed transactions. The calculation of the velocity only takes in account the transactions previously accepted during the period.
The rule checks the activity of an IP address over given period. You must specify the number and/or cumulative amount of the transactions, and the duration of the period during the configuration of the profile. This IP address comes from:
- the automatic detection performed by the customer's browser on the Sips Paypage ;
- or from your transfer of data in the request in Sips Office.
Example
The table below describes the evolution of the IP address history if you have chosen to restrict purchases on your website to 2 times for the same IP, for a total amount of €500 and per month (30 days):
Transaction date | Payment details | Rule result | IP address velocity (number of
transactions) |
IP address velocity (cumulative amount) |
History situation (last 30 days) |
---|---|---|---|---|---|
01/10/2018 | Transaction TR1 Amount: €100 IP:
105.24.68.102 |
OK | 1 | €100 | TR1 01/10/2018 105.24.68.102 €100 |
07/10/2018 | Transaction TR2 Amount: €400 IP:
254.24.78.175 |
OK | 1 | €400 | TR1 01/10/2018 105.24.68.102 €100 OK TR2 07/10/2018
254.24.78.175 €400 |
10/10/2018 | Transaction TR3 Amount: €400 IP:
254.24.78.175 |
KO | 2 | €800 (> 500) |
TR1 01/10/2018 105.24.68.102 €100 OK TR2 07/10/2018
254.24.78.175 €400 OK TR3 10/10/2018
254.24.78.175 €400 |
12/10/2018 | Transaction TR4 Amount: €200 IP:
105.24.68.102 |
OK | 2 | €300 | TR1 01/10/2018 105.24.68.102 €100 OK TR2
07/10/2018 254.24.78.175 €400 OK TR3 10/10/2018
254.24.78.175 €400 KO TR4 12/10/2018 105.24.68.102
€200 |
15/10/2018 | Transaction TR5 Amount: €100 IP:
105.24.68.102 |
KO | 3 (> 2) |
€400 | TR1 01/10/2018 105.24.68.102 €100 OK TR2
07/10/2018 254.24.78.175 €400 OK TR3 10/10/2018
254.24.78.175 €400 KO TR4 12/10/2018 105.24.68.102
€200 OK TR5 15/10/2018 105.24.68.102
€100 |
02/11/2018 (> 30 d) |
Transaction TR6 Amount: €300 IP:
105.24.68.102 |
OK | 1 | €300 | TR6 02/11/2018 105.24.68.102 €300 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- set the number of transactions carried out and/or the cumulative amount and the cumulation time through the fraud tab in the Merchant Extranet
- and provide the customer's IP address in the request (customerIpAddress field), if you use Sips Office
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum cumulative amount | 0.01 over the period, in your currency | 9999999 |
Maximum number of transactions | 1 transaction over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the VelocityIp instruction.
- POST example:
fraudData.bypassCtrlList=VelocityIp
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>VelocityIp</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
fraudData": {
"bypassCtrlList":["VelocityIp"]
}
Limitations of use
The IP address history is not updated during refund, cancellation or validation operations, whether they are partial or complete.
Customer ID velocity
Rule description
This rule enables you to assess the risk of a purchase by verifying the activity (number and/or cumulative amount of the transactions) of a customer from their customer ID over a given period.
The rule is executed on all succeed transactions for which a customer ID is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.
The rule checks the activity of a customer ID over a given period. You must specify the number and/or cumulative amount of the transactions, and the duration of the period during the configuration of the profile.
Example
The table below describes the evolution of the customer ID history if you have chosen to restrict purchases on your website to a maximum of 2 times for the same customer, for a maximum amount of €500 and per month (30 days):
Transaction date | Payment details | Rule result | Customer ID velocity (number of
transactions) |
Customer velocity (Cumulative amount) |
History situation (last 30 days) |
---|---|---|---|---|---|
01/10/2018 | Transaction TR1 Amount:
€100 CustomerID: cust1 |
OK | 1 | €100 | TR1 01/10/2018 cust1 €100 |
07/10/2018 | Transaction TR2 Amount:
€400 CustomerID: cust2 |
OK | 1 | €400 | TR1 01/10/2018 cust1 €100 OK TR2 07/10/2018 cust2
€400 |
10/10/2018 | Transaction TR3 Amount:
€400 CustomerID: cust2 |
KO | 2 | €800 (> 500) |
TR1 01/10/2018 cust1 €100 OK TR2 07/10/2018 cust2
€400 OK TR3 10/10/2018 cust2
€400 |
12/10/2018 | Transaction TR4 Amount:
€200 CustomerID: cust1 |
OK | 2 | €300 | TR1 01/10/2018 cust1 €100 OK TR2 07/10/2018
cust2 €400 OK TR3 10/10/2018 cust2 €400
KO TR4 12/10/2018 cust1 €200 |
15/10/2018 | Transaction TR5 Amount:
€100 CustomerID: cust1 |
KO | 3 (> 2) |
€400 | TR1 01/10/2018 cust1 €100 OK TR2 07/10/2018
cust2 €400 OK TR3 10/10/2018 cust2 €400
KO TR4 12/10/2018 cust1 €200 OK TR5
15/10/2018 cust1 €100 |
02/11/2018 (> 30 d) |
Transaction TR6 Amount:
€300 CustomerID: cust1 |
OK | 1 | €300 | TR6 02/11/2018 cust1 €300 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- set the number of transactions carried out and/or the cumulative amount and the cumulation time through the fraud tab in the Merchant Extranet
- and provide the customer's customer ID in the request (customerId field)
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum cumulative amount | 0.01 over the period, in your currency | 9999999 |
Maximum number of transactions | 1 transaction over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the VelocityCustomerId instruction.
- POST example:
fraudData.bypassCtrlList=VelocityCustomerId
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>VelocityCustomerId</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
fraudData": {
"bypassCtrlList":["VelocityCustomerId"]
}
Limitations of use
In the case of a payment in multiple instalments, only the first instalment is taken into account.
During the validation, cancellation and refund of the transaction, the amount that is not validated, cancelled or refunded is not substracted from the cumulative amount.
Number of customers per card
Rule description
This rule enables you to make sure a given card is not used by too many different customers over a given period.
The rule is executed on all succeed card payment transactions for which a customer ID is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.
The rule checks the activity from the customer's card number and customer ID over a given period.
Example
The table below describes the evolution of the customer ID/Card history if you have chosen to restrict purchases on your website to 3 customers per month (30 days) with the same card:
Transaction date | Payment details | Rule result | Customers/card | History situation (last 30 days) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 CustomerID:
cust1 Card: CB1 |
OK | 1 | TR1 01/10/2018 cust1 CB1 |
07/10/2018 | Transaction TR2 CustomerID:
cust2 Card: CB2 |
OK | 2 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust2 CB1 |
12/10/2018 | Transaction TR3 CustomerID:
cust3 Card: CB1 |
OK | 3 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust2 CB1 OK TR3 12/10/2018 cust3
CB1 |
20/10/2018 | Transaction TR4 CustomerID:
cust4 Card: CB1 |
KO | 4 (> 3) |
TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust2 CB1 OK TR3 12/10/2018 cust3 CB1
OK TR4 20/10/2018 cust4 CB1 |
25/10/2018 | Transaction TR5 CustomerID:
cust4 Card: CB2 |
OK | 1 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust2 CB1
OK TR3 12/10/2018 cust3 CB1 OK TR4 20/10/2018
cust4 CB1 KO TR5 25/10/2018 cust4 CB2 |
27/10/2018 | Transaction TR6 CustomerID:
cust1 Card: CB1 |
OK | 3 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust2 CB1 OK TR3 12/10/2018 cust3 CB1
OK TR4 20/10/2018 cust4 CB1 KO TR5
25/10/2018 cust4 CB2 OK TR6 27/10/2018 cust1
CB1 |
02/03/2018 (> 30 d) |
Transaction TR7 CustomerID:
cust5 Card: CB1 |
OK | 1 | TR7 02/03/2018 cust5 CB1 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- set the maximum number of customers and the cumulation time through the fraud tab in the Merchant Extranet
- and provide the customer's customer ID in the request (customerId field)
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum number of customers | 1 customer over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxCustomerIdPerCard instruction.
- POST example:
fraudData.bypassCtrlList=MaxCustomerIdPerCard
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>MaxCustomerIdPerCard</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
fraudData": {
"bypassCtrlList":["MaxCustomerIdPerCard"]
}
Limitations of use
The CustomerID/Card history of a customer is not updated during refund, cancellation or validation operations, whether they are partial or complete.
Number of cards per customer
Rule description
This rule enables you to make sure that a given customer does not use too many different cards over a given period.
The rule is executed on all succeed card payment transactions for which a customer ID is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.
The rule checks the activity from the customer's card number and customer ID over a given period.
Example
The table below describes the evolution of the customer ID/Card history if you have chosen to restrict purchases on your website to 3 cards per month (30 days) for the same customer:
Transaction date | Payment details | Rule result | Cards/customer | History situation (last 30 days) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 Customer ID:
cust1 Card: CB1 |
OK | 1 | TR1 01/10/2018 cust1 CB1 |
07/10/2018 | Transaction TR2 Customer ID:
cust1 Card: CB2 |
OK | 2 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust1 CB2 |
12/10/2018 | Transaction TR3 Customer ID:
cust1 Card: CB3 |
OK | 3 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust1 CB2 OK TR3 12/10/2018 cust1
CB3 |
20/10/2018 | Transaction TR4 Customer ID: cust1
Card: CB4 |
KO | 4 (> 3) |
TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust1 CB2 OK TR3 12/10/2018 cust1 CB3
OK TR4 20/10/2018 cust1 CB4 |
25/10/2018 | Transaction TR5 Customer ID:
cust2 Card: CB4 |
OK | 1 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018 cust1 CB2
OK TR3 12/10/2018 cust1 CB3 OK TR4 20/10/2018
cust1 CB4 KO TR5 25/10/2018 cust2
CB4 |
27/10/2018 | Transaction TR6 Customer ID:
cust1 Card: CB1 |
OK | 3 | TR1 01/10/2018 cust1 CB1 OK TR2 07/10/2018
cust1 CB2 OK TR3 12/10/2018 cust1 CB3
OK TR4 20/10/2018 cust1 CB4 KO TR5
25/10/2018 cust2 CB4 OK TR6 27/10/2018 cust1
CB1 |
02/03/2018 (> 30 d) |
Transaction TR7 Customer ID:
cust1 Card: CB5 |
OK | 1 | TR7 02/03/2018 cust1 CB5 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- set the maximum number of cards and the cumulation time through the fraud tab in the Merchant Extranet
- and provide the customer's customer ID in the request (customerId field)
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum number of cards | 1 card over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxCardPerCustomerId instruction.
- POST example:
fraudData.bypassCtrlList=MaxCardPerCustomerId
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>MaxCardPerCustomerId</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
fraudData": {
"bypassCtrlList":["MaxCardPerCustomerId"]
}
Limitations of use
The CustomerID/Card history of a customer is not updated during refund, cancellation or validation operations, whether they are partial or complete.
Number of cards per IP address
Rule description
This rule enables you to make sure that the transactions coming from a given IP address do not use too many different cards over a given period.
The rule is executed on all succeed transactions for which an IP address is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.
The rule checks the activity from the customer's card number and IP address over a given period. This IP address comes from:
- the automatic detection performed by the customer's browser in Sips Paypage ;
- or your transfer of data in the request in Sips Office.
Example
The table below describes the evolution of the IP address/Card history if you have chosen to restrict purchases on your website to 3 cards per month (30 days) for the same customer:
Transaction date | Payment details | Rule result | Cards/IP | History situation (last 30 days) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 IP:
105.24.68.102 Card: CB1 |
OK | 1 | TR1 01/10/2018 105.24.68.102 CB1 |
07/10/2018 | Transaction TR2 IP:
105.24.68.102 Card: CB2 |
OK | 2 | TR1 01/10/2018 105.24.68.102 CB1 OK TR2
07/10/2018 105.24.68.102 CB2 |
12/10/2018 | Transaction TR3 IP:
105.24.68.102 Card: CB3 |
OK | 3 | TR1 01/10/2018 105.24.68.102 CB1 OK TR2
07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018
105.24.68.102 CB3 |
20/10/2018 | Transaction TR4 IP:
105.24.68.102 Card: CB4 |
KO | 4 (> 3) |
TR1 01/10/2018 105.24.68.102 CB1 OK TR2
07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018
105.24.68.102 CB3 OK TR4 20/10/2018 105.24.68.102
CB4 |
25/10/2018 | Transaction TR5 IP:
254.24.78.175 Card: CB4 |
OK | 1 | TR1 01/10/2018 105.24.68.102 CB1 OK TR2 07/10/2018
105.24.68.102 CB2 OK TR3 12/10/2018 105.24.68.102 CB3
OK TR4 20/10/2018 105.24.68.102 CB4 KO TR5
25/10/2018 254.24.78.175 CB4 |
27/10/2018 | Transaction TR6 IP:
105.24.68.102 Card: CB1 |
OK | 3 | TR1 01/10/2018 105.24.68.102 CB1 OK TR2
07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018
105.24.68.102 CB3 OK TR4 20/10/2018 105.24.68.102
CB4 KO TR5 25/10/2018 254.24.78.175 CB4
OK TR6 27/10/2018 105.24.68.102 CB1 |
02/03/2018 (> 30 d) |
Transaction TR7 IP:
105.24.68.102 Card: CB5 |
OK | 1 | TR7 02/03/2018 105.24.68.102 CB5 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- set the maximum number of cards and the cumulation time through the fraud tab in the Merchant Extranet
- and provide the customer's IP address in the request (customerIpAddress field), if you use Sips Office
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum number of cards | 1 card over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxCardPerIp instruction.
- POST example:
fraudData.bypassCtrlList=MaxCardPerIp
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>MaxCardPerIp</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
fraudData": {
"bypassCtrlList":["MaxCardPerIp"]
}
Limitations of use
The IP address/Card history is not updated during refund, cancellation or validation operations, whether they are partial or complete.
Number of IBANs per IP address
Rule description
This rule enables you to check that the transactions coming from a given IP address do not use too high a number of different IBANs over a period.
The rule is executed on all payment transactions made with a SDD payment method and in which the customer's IP address is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.
The rule checks the activity from the IBAN and the customer's IP address over a given period. This IP address comes from:
- the automatic detection performed by the customer's browser in Sips Paypage ;
- or your transfer of data in the request in Sips Office.
Example
The following table outlines the change in IBAN/IP address history, in the event that you decided to limit purchases on your website to 3 IBANs per month (30 days) for one IP address:
Transaction date | Payment details | Rule result | IBAN/IP | History situation (last 30 days) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 IP:
105.24.68.102 IBAN: IBAN1 |
OK | 1 | TR1 01/10/2018 105.24.68.102 IBAN1 |
07/10/2018 | Transaction TR2 IP:
105.24.68.102 IBAN: IBAN2 |
OK | 2 | TR1 01/10/2018 105.24.68.102 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN2 |
12/10/2018 | Transaction TR3 IP:
105.24.68.102 IBAN: IBAN3 |
OK | 3 | TR1 01/10/2018 105.24.68.102 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN2 OK TR3 12/10/2018
105.24.68.102 IBAN3 |
20/10/2018 | Transaction TR4 IP:
105.24.68.102 IBAN: IBAN4 |
KO | 4 (> 3) |
TR1 01/10/2018 105.24.68.102 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN2 OK TR3 12/10/2018
105.24.68.102 IBAN3 OK TR4 20/10/2018
105.24.68.102 IBAN4 |
25/10/2018 | Transaction TR5 IP:
254.24.78.175 IBAN: IBAN4 |
OK | 1 | TR1 01/10/2018 105.24.68.102 IBAN1 OK TR2 07/10/2018
105.24.68.102 IBAN2 OK TR3 12/10/2018 105.24.68.102
IBAN3 OK TR4 20/10/2018 105.24.68.102 IBAN4
KO TR5 25/10/2018 254.24.78.175
IBAN4 |
27/10/2018 | Transaction TR6 IP:
105.24.68.102 IBAN: IBAN1 |
OK | 3 | TR1 01/10/2018 105.24.68.102 CB1 OK TR2
07/10/2018 105.24.68.102 CB2 OK TR3 12/10/2018
105.24.68.102 CB3 OK TR4 20/10/2018 105.24.68.102
CB4 KO TR5 25/10/2018 254.24.78.175 CB4
OK TR6 27/10/2018 105.24.68.102 CB1 |
02/03/2018 (> 30 d) |
Transaction TR7 IP:
105.24.68.102 IBAN: IBAN5 |
OK | 1 | TR7 02/03/2018 105.24.68.102 IBAN5 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- set the maximum number of IBANs and the cumulation time through the fraud tab in the Merchant Extranet
- and provide the customer's IP address in the request (customerIpAddress field), if you use
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum number of IBANs | 1 IBAN over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxIbanPerIp instruction.
- POST example:
fraudData.bypassCtrlList=MaxIbanPerIp
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>MaxIbanPerIp</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
fraudData": {
"bypassCtrlList":["MaxIbanPerIp"]
}
Limitations of use
The IBAN/IP address history is not updated during partial or total refund, cancellation or validation operations.
Number of IP addresses per IBAN
Rule description
This rule enables you to check that an IBAN is not used by too high a number of different IP addresses over a period.
The rule is executed on all payment transactions made with a SDD payment method and in which the customer's IP address is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.
The rule checks the activity from the IBAN and the customer's IP address over a given period. This IP address comes from:
- the automatic detection performed by the customer's browser in Sips Paypage
- or your transfer of data in the request in Sips Office
Example
The following table outlines the change in IP address/IBAN history, in the event that you decided to limit purchases on your website to 3 IP addresses per month (30 days) for one IBAN:
Transaction date | Payment details | Rule result | IP/IBAN | History situation (last 30 days) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 IP:
105.24.68.101 IBAN: IBAN1 |
OK | 1 | TR1 01/10/2018 105.24.68.101 IBAN1 |
07/10/2018 | Transaction TR2 IP:
105.24.68.102 IBAN: IBAN1 |
OK | 2 | TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN1 |
12/10/2018 | Transaction TR3 IP:
105.24.68.103 IBAN: IBAN1 |
OK | 3 | TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN1 OK TR3 12/10/2018
105.24.68.103 IBAN1 |
20/10/2018 | Transaction TR4 IP:
105.24.68.104 IBAN: IBAN1 |
KO | 4 (> 3) |
TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN1 OK TR3 12/10/2018
105.24.68.103 IBAN1 OK TR4 20/10/2018
105.24.68.104 IBAN1 |
25/10/2018 | Transaction TR5 IP:
105.24.68.104 IBAN: IBAN2 |
OK | 1 | TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2 07/10/2018
105.24.68.102 IBAN1 OK TR3 12/10/2018 105.24.68.103
IBAN1 OK TR4 20/10/2018 105.24.68.104 IBAN1
KO TR5 25/10/2018 105.24.68.104
IBAN2 |
27/10/2018 | Transaction TR6 IP:
105.24.68.101 IBAN: IBAN1 |
OK | 3 | TR1 01/10/2018 105.24.68.101 IBAN1 OK TR2
07/10/2018 105.24.68.102 IBAN1 OK TR3 12/10/2018
105.24.68.103 IBAN1 OK TR4 20/10/2018 105.24.68.104
IBAN1 KO TR5 25/10/2018 105.24.68.104
IBAN2 TR6 27/10/2018 105.24.68.101
IBAN1 |
02/03/2018 (> 30 d) |
Transaction TR7 IP:
105.24.68.105 IBAN: IBAN1 |
OK | 1 | TR7 02/03/2018 105.24.68.105 IBAN1 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- set the maximum number of IP addresses and the cumulation time through the fraud tab in the Merchant Extranet
- and provide the customer's IP address in the request (customerIpAddress field), if you use Sips Office
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum number of IP addresses | 1 IP address over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxIpPerIban instruction.
- POST example:
fraudData.bypassCtrlList=MaxIpPerIban
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>MaxIpPerIban</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
fraudData": {
"bypassCtrlList":["MaxIpPerIban"]
}
Limitations of use
The IP address/IBAN history is not updated during partial or total refund, cancellation or validation operations.
Number of customers per IBAN
Rule description
This rule enables you to check that an IBAN is not used by too high a number of different customers over a period.
The rule is executed on all payment transactions made with a SDD means of payment and in which the customer's IP address and identifier (customerId) is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.
The rule checks the activity from the IBAN and the customer's IP address over a given period. This IP address comes from:
- the automatic detection performed by the customer's browser in Sips Paypage
- or your transfer of data in the request in Sips Office
Example
The following table outlines the change in customer ID/IBAN history, in the event that you decided to limit purchases on your website to 3 customers per month (30 days) with the same IBAN:
Transaction date | Payment details | Rule result | Customers/IBAN | History situation (last 30 days) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 Customer ID:
cust1 IBAN: IBAN1 |
OK | 1 | TR1 01/10/2018 cust1 IBAN1 |
07/10/2018 | Transaction TR2 Customer ID:
cust2 IBAN: IBAN1 |
OK | 2 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust2 IBAN1 |
12/10/2018 | Transaction TR3 Customer ID:
cust3 IBAN: IBAN1 |
OK | 3 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust2 IBAN1 OK TR3 12/10/2018 cust3
IBAN1 |
20/10/2018 | Transaction TR4 Customer ID:
cust4 IBAN: IBAN1 |
KO | 4 (> 3) |
TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust2 IBAN1 OK TR3 12/10/2018 cust3 IBAN1
OK TR4 20/10/2018 cust4 IBAN1 |
25/10/2018 | Transaction TR5 Customer ID:
cust4 IBAN: IBAN2 |
OK | 1 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust2
IBAN1 OK TR3 12/10/2018 cust3 IBAN1 OK TR4
20/10/2018 cust4 IBAN1 KO TR5 25/10/2018 cust4
IBAN2 |
27/10/2018 | Transaction TR6 Customer ID:
cust1 IBAN: IBAN1 |
OK | 3 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust2 IBAN1 OK TR3 12/10/2018 cust3 IBAN1
OK TR4 20/10/2018 cust4 IBAN1 KO TR5
25/10/2018 cust4 IBAN2 OK TR6 27/10/2018 cust1
IBAN1 |
02/03/2018 (> 30 d) |
Transaction TR7 Customer ID:
cust5 IBAN: IBAN1 |
OK | 1 | TR7 02/03/2018 cust5 IBAN1 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- set the maximum number of customers and the cumulation time through the fraud tab in the Merchant Extranet
- and provide the customer's identifier in the request (customerId field)
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum number of customers | 1 customer over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SimilarityDeliveryIbanCountry instruction.
- POST example:
fraudData.bypassCtrlList=MaxCustidPerIban
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>MaxCustidPerIban</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["MaxCustidPerIban"]
}
Limitations of use
The customer/IBAN history is not updated during partial or total refund, cancellation or validation operations.
Number of IBANs per customer
Rule description
This rule enables you to check that a customer does not use too high a number of different IBANs over a period.
The rule is executed on all payment transactions made with a SDD means of payment and in which the customer's identifier is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.
The rule checks the activity from the customer's identifier (customerId) and the IBAN over a given period.
Example
The following table outlines the change in customer ID/IBAN history, in the event that you decided to limit purchases on your website to 3 IBANs per month (30 days) for one customer:
Transaction date | Payment details | Rule result | IBAN/client | History situation (last 30 days) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 Customer ID:
cust1 IBAN: IBAN1 |
OK | 1 | TR1 01/10/2018 cust1 IBAN1 |
07/10/2018 | Transaction TR2 Customer ID:
cust1 IBAN: IBAN2 |
OK | 2 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust1 IBAN2 |
12/10/2018 | Transaction TR3 Customer ID:
cust1 IBAN: IBAN3 |
OK | 3 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust1 IBAN2 OK TR3 12/10/2018 cust1
IBAN3 |
20/10/2018 | Transaction TR4 Customer ID:
cust1 IBAN: IBAN4 |
KO | 4 (> 3) |
TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust1 IBAN2 OK TR3 12/10/2018 cust1 IBAN3
OK TR4 20/10/2018 cust1 IBAN4 |
25/10/2018 | Transaction TR5 Customer ID:
cust2 IBAN: IBAN4 |
OK | 1 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018 cust1
IBAN2 OK TR3 12/10/2018 cust1 IBAN3 OK TR4
20/10/2018 cust1 IBAN4 KO TR5 25/10/2018 cust2
IBAN4 |
27/10/2018 | Transaction TR6 Customer ID:
cust1 IBAN: IBAN1 |
OK | 3 | TR1 01/10/2018 cust1 IBAN1 OK TR2 07/10/2018
cust1 IBAN2 OK TR3 12/10/2018 cust1 IBAN3
OK TR4 20/10/2018 cust1 IBAN4 KO TR5
25/10/2018 cust2 IBAN4 OK TR6 27/10/2018 cust1
IBAN1 |
02/03/2018 (> 30 d) |
Transaction TR7 Customer ID:
cust1 IBAN: IBAN5 |
OK | 1 | TR7 02/03/2018 cust1 IBAN5 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- set the maximum number of IBANs and the cumulation time through the fraud tab in the Merchant Extranet
- and provide the customer's identifier in the request (customerId field)
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum number of IBANs | 1 IBAN over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxIbanPerCustid instruction.
- POST example:
fraudData.bypassCtrlList=MaxIbanPerCustid
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>MaxIbanPerCustid</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["MaxIbanPerCustid"]
}
Limitations of use
The customer/IBAN history is not updated during partial or total refund, cancellation or validation operations.
Number of mandates per IP address
Rule description
This rule enables you to check that an IP address does not use too high a number of different SDD mandates, indicated by their Unique Mandate Reference (UMR), over a period.
The rule is executed on all payment transactions made with a SDD means of payment and in which the IP address is transmitted. The calculation of the velocity only takes in account the transactions previously accepted during the period.
The rule checks the activity from the mandate and the customer's IP address over a given period. This IP address comes from:
- the automatic detection performed by the customer's browser in Sips Paypage
- or your transfer of data in the request in Sips Office
Example
The following table outlines the change in mandate/IP address history, in the event that you decided to limit purchases on your website to 3 mandates per month (30 days) for one IP address:
Transaction date | Payment details | Rule result | Mandates/IP | History situation (last 30 days) |
---|---|---|---|---|
01/10/2018 | Transaction TR1 IP:
105.24.68.102 Mandate: RUM1 |
OK | 1 | TR1 01/10/2018 105.24.68.102 RUM1 |
07/10/2018 | Transaction TR2 IP:
105.24.68.102 Mandate: RUM2 |
OK | 2 | TR1 01/10/2018 105.24.68.102 RUM1 OK TR2
07/10/2018 105.24.68.102 RUM2 |
12/10/2018 | Transaction TR3 IP:
105.24.68.102 Mandate: RUM3 |
OK | 3 | TR1 01/10/2018 105.24.68.102 RUM1 OK TR2
07/10/2018 105.24.68.102 RUM2 OK TR3 12/10/2018
105.24.68.102 RUM3 |
20/10/2018 | Transaction TR4 IP:
105.24.68.102 Mandate: RUM4 |
KO | 4 (> 3) |
TR1 01/10/2018 105.24.68.102 RUM1 OK TR2
07/10/2018 105.24.68.102 RUM2 OK TR3 12/10/2018
105.24.68.102 RUM3 OK TR4 20/10/2018
105.24.68.102 RUM4 |
25/10/2018 | Transaction TR5 IP:
254.24.78.175 Mandate: RUM4 |
OK | 1 | TR1 01/10/2018 105.24.68.102 RUM1 OK TR2 07/10/2018
105.24.68.102 RUM2 OK TR3 12/10/2018 105.24.68.102 RUM3
OK TR4 20/10/2018 105.24.68.102 RUM4 KO TR5
25/10/2018 254.24.78.175 RUM4 |
27/10/2018 | Transaction TR6 IP:
105.24.68.102 Mandate: RUM1 |
OK | 3 | TR1 01/10/2018 105.24.68.102 RUM1 OK TR2
07/10/2018 105.24.68.102 RUM2 OK TR3 12/10/2018
105.24.68.102 RUM3 OK TR4 20/10/2018 105.24.68.102
RUM4 KO TR5 25/10/2018 254.24.78.175 RUM4
OK TR6 27/10/2018 105.24.68.102
RUM1 |
02/03/2018 (> 30 d) |
Transaction TR7 IP:
105.24.68.102 Mandate: RUM5 |
OK | 1 | TR7 02/03/2018 105.24.68.102 RUM5 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- set the maximum number of mandates and the cumulation time through the fraud tab in the Merchant Extranet
- and provide the customer's IP address in the request (customerIpAddress field), if you use Sips Office
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum number of mandates | 1 mandate over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxMandatePerIp instruction.
- POST example:
fraudData.bypassCtrlList=MaxMandatePerIp
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>MaxMandatePerIp</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["MaxMandatePerIp"]
}
Limitations of use
The customer/IBAN history is not updated during partial or total refund, cancellation or validation operations.
Mandate velocity
Rule description
This rule enables you to assess the risk of a purchase by checking the activity (the number and/or accumulated amount of transactions) of the SDD mandate, indicated by its Unique Mandate Reference (UMR), over a period.
The rule is executed on all payment transactions made with a SDD means of payment. The calculation of the velocity only takes in account the transactions previously accepted during the period.
The rule checks the activity of a mandate over a given period. The number of transactions and/or accumulated amount of transactions and the duration of the period must be provided by you in your profile settings.
Example
The following table outlines the change in the mandate history, in the event that you decided to limit purchases on your website to 2 times for one mandate, for a total amount of €500 per month (30 days):
Transaction details | Payment details | Rule result | Mandate velocity (number of transactions) |
Mandate velocity (cumulative amount) |
History situation (last 30 days) |
---|---|---|---|---|---|
01/10/2018 | Transaction TR1 Amount: €100 Mandate:
RUM1 |
OK | 1 | €100 | TR1 01/10/2018 RUM1 €100 |
07/10/2018 | Transaction TR2 Amount: €400 Mandate:
RUM2 |
OK | 1 | €400 | TR1 01/10/2018 RUM1 €100 OK TR2 07/10/2018 RUM2
€400 |
10/10/2018 | Transaction TR3 Amount: €400 Mandate:
RUM2 |
KO | 2 | €800 (> 500) |
TR1 01/10/2018 RUM1 €100 OK TR2 07/10/2018 RUM2 €400
OK TR3 10/10/2018 RUM2 €400 |
12/10/2018 | Transaction TR4 Amount: €200 Mandate:
RUM1 |
OK | 2 | €300 | TR1 01/10/2018 RUM1 €100 OK TR2 07/10/2018 RUM2
€400 OK TR3 10/10/2018 RUM2 €400 KO TR4
12/10/2018 RUM1 €200 |
15/10/2018 | Transaction TR5 Amount: €100 Mandate:
RUM1 |
KO | 3 (> 2) |
€400 | TR1 01/10/2018 RUM1 €100 OK TR2 07/10/2018 RUM2
€400 OK TR3 10/10/2018 RUM2 €400 KO TR4
12/10/2018 RUM1 €200 OK TR5 15/10/2018 RUM1
€100 |
02/11/2018 (> 30) |
Transaction TR6 Amount: €300 Mandate:
RUM1 |
OK | 1 | €300 | TR6 02/11/2018 RUM1 €300 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- and set the number of transactions made and/or the cumulative amount and the cumulation time through the fraud tab in the Merchant Extranet
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum cumulative amount | 0.01 over the period, in your currency | 9999999 |
Maximum number of transactions | 1 transaction over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the VelocityMandate instruction.
- POST example:
fraudData.bypassCtrlList=VelocityMandate
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>VelocityMandate</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["VelocityMandate"]
}
Limitations of use
In the case of payment in N instalments, only the first instalment is taken into account.
During the validation, cancellation and refund of the transaction, the amount not validated, cancelled or refunded is not subtracted from the count.
IBAN velocity
Rule description
This rule enables you to assess the risk of a purchase by checking the activity (the number and/or accumulated amount of transactions) of the IBAN over a period.
The rule is executed on all payment transactions made with a SDD means of payment. The calculation of the velocity only takes in account the transactions previously accepted during the period.
The rule checks the activity of an IBAN over a given period. The number of transactions and/or accumulated amount of transactions and the duration of the period must be provided by you in your profile settings.
Example
The following table outlines the change in the mandate history, in the event that you decided to limit purchases on your website to 2 times for one IBAN, for a total amount of €500 per month (30 days):
Transaction date | Payment details | Rule result | IBAN velocity (number of transactions) |
IBAN velocity (cumulative amount) |
History situation (last 30 days) |
---|---|---|---|---|---|
01/10/2018 | Transaction TR1 Amount: €100 IBAN:
IBAN1 |
OK | 1 | €100 | TR1 01/10/2018 IBAN1 €100 |
07/10/2018 | Transaction TR2 Amount: €400 IBAN:
IBAN2 |
OK | 1 | €400 | TR1 01/10/2018 IBAN1 €100 OK TR2 07/10/2018 IBAN2
€400 |
10/10/2018 | Transaction TR3 Amount: €400 IBAN:
IBAN2 |
KO | 2 | €800 (> 500) |
TR1 01/10/2018 IBAN1 €100 OK TR2 07/10/2018 IBAN2
€400 OK TR3 10/10/2018 IBAN2
€400 |
12/10/2018 | Transaction TR4 Amount: €200 IBAN:
IBAN1 |
OK | 2 | €300 | TR1 01/10/2018 IBAN1 €100 OK TR2 07/10/2018
IBAN2 €400 OK TR3 10/10/2018 IBAN2 €400
KO TR4 12/10/2018 IBAN1 €200 |
15/10/2018 | Transaction TR5 Amount: €100 IBAN:
IBAN1 |
KO | 3 (> 2) |
€400 | TR1 01/10/2018 IBAN1 €100 OK TR2 07/10/2018
IBAN2 €400 OK TR3 10/10/2018 IBAN2 €400
KO TR4 12/10/2018 IBAN1 €200 OK TR5
15/10/2018 IBAN1 €100 |
02/11/2018 (> 30) |
Transaction TR6 Amount: €300 IBAN:
IBAN1 |
OK | 1 | €300 | TR6 02/11/2018 IBAN1 €300 |
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- and set the number of transactions made and/or the cumulative amount and the cumulation time through the fraud tab in the Merchant Extranet
Setting | Minimum value | Maximum value |
---|---|---|
Period | In hours: 1 hour In days: 1 day In weeks:
1 week |
In hours: 2376 hours In days: 99 days In
weeks: 14 weeks |
Maximum cumulative amount | 0.01 over the period, in your currency | 9999999 |
Maximum number of transactions | 1 transaction over the period | 9999 |
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the VelocityIban field.
- POST example:
fraudData.bypassCtrlList=VelocityIban
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>VelocityIban</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["VelocityIban"]
}
Limitations of use
In the case of payment in N instalments, only the first instalment is taken into account.
During the validation, cancellation and refund of the transaction, the amount not validated, cancelled or refunded is not subtracted from the count.
Miscellaneous rules
IP address reputation
Rule description
This rule enables you to decide whether to accept or refuse a purchase made from an IP address the reputation of which is dangerous.
The rule queries the IP address reputation database to know the reputation of the customer's IP address and check whether it is on the list of unwanted IP address reputations defined by you. This IP address comes from:
- the automatic detection performed by the customer's browser in Sips Paypage
- or your transfer of data in the request in Sips Office
If there is no list of unwanted IP address reputations, the rule returns a neutral result.
Conditions of use
If you would like to use this rule you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- set the list of unwanted IP address reputations through the fraud tab in the Merchant Extranet
- and send the customer's IP address in the request (customerIpAddress field), if you use Sips Office.
Please read Appendix 3: IP address reputations to find out more about configurable IP addresses.
Expression of the result
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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the IpReputations instruction.
- POST example:
fraudData.bypassCtrlList=IpReputations
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>IpReputations</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["IpReputations"]
}
Lost and stolen cards (CB scheme cards)
Rule description
This rule enables you to decide whether to accept or refuse a purchase made with a blocked card.
The rule is executed on all payment transactions carried out with CB, Visa and MasterCard cards.
The rule checks whether the card is present in the database of blocked cards.
The file of blocked cards is populated by the CB network's list of blocked cards. The file is updated several times a day.
Conditions of use
If you would like to use this rule, you must set the rule using the fraud tab in the Merchant Extranet.
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the HotList instruction.
- POST example:
fraudData.bypassCtrlList=HotList
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>HotList</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["HotList"]
}
Virtual card
Rule description
This rule enables you to decide whether to accept or refuse a purchase paid for by the holder of a virtual card issued by a French bank.
The rule is executed on all card payment transactions.
The rule checks the BIN range database to determine whether the card is a virtual card.
Conditions of use
If you would like to use this rule, you must set the rule using the fraud tab in the Merchant Extranet.
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the ECard instruction.
- POST example:
fraudData.bypassCtrlList=ECard
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>ECard</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["ECard"]
}
Card with mandatory authorisation
Rule description
This rule enables you to decide whether to accept or refuse a purchase paid for by the holder of a systematic authorisation card.
The rule is executed on all card payment transactions.
The rule checks the BIN range database to determine whether the card is a systematic authorisation card.
Conditions of use
If you would like to use this rule, you must set the rule using the fraud tab in the Merchant Extranet.
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the SystematicAuthorizationCard instruction.
- POST example:
fraudData.bypassCtrlList=SystematicAuthorizationCard
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>SystematicAuthorizationCard</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["SystematicAuthorizationCard"]
}
Commercial card (and card country)
Rule description
This rule enables you to decide whether to accept or refuse to provide a service based on the fact that the card is:
- a commercial card
- a commercial card present on a list of authorised or prohibited issuing countries
The rule is executed on all card payment transactions.
The rule first queries a card information database to check whether the card is part of a commercial card BIN range. This will determine whether the card is a commercial card. Depending on the required check, the server checks whether the country in which the commercial card was issued is on the list of the countries that you have authorised or prohibited.
If there is no list of authorised or prohibited commercial card issuing countries, the server simply checks whether the card is a commercial card.
Conditions of use
If you would like to use this rule, you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- and set the list of authorised or prohibited commercial card issuing
countries (if you want to intercept the commercial cards of certain
countries). To this end, you must:
- set the list through the fraud tab in the Merchant Extranet
- or dynamically override the list of authorised or prohibited countries in your request
Expression of the result
Use case | 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.
Dynamic override
You can supply dynamically a list of authorised or prohibited commercial card country in the request. If a list is sent in the request, it takes priority over the possible configuration except if it conflicts with the configuration imposed by the distributor.
Choose the parameter to be overridden in the field...
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicParam
...and send the country list in the field:
fraudData.
riskManagementDynamicSettingList.
riskManagementDynamicSetting.
riskManagementDynamicValue
The 2 parameters for this rule are:
AllowedCommercialCardCountryList for the authorised commercial card country combinations
- DeniedCommercialCardCountryList for the denied commercial card country combinations
- 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.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the CorporateCard instruction.
- POST example:
fraudData.bypassCtrlList=CorporateCard
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>CorporateCard</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["CorporateCard"]
}
Cap collar amounts
Rule description
This rule enables you to assess the risk of a purchase by verifying its amount.
The rule checks whether the transaction amount lies within the amount range required by the merchant.
If no minimum and maximum amounts have been defined for the amount, the rule returns a neutral result.
Conditions of use
If you would like to use this rule, you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- and set the minimum and/or maximum amount(s) through the fraud tab in the Merchant Extranet
Parameter | Minimum value | Maximum value |
---|---|---|
Minimum value | 0.01 in your currency | 9999999 |
Maximum value | 0.01 in your currency | 9999999 |
Expression of the result
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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the CapCollerAmount instruction.
- POST example:
fraudData.bypassCtrlList=CapCollarAmount
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>CapCollarAmount</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["CapCollarAmount"]
}
CB scheme card
Rule description
This rule enables the merchant to decide whether to accept or refuse a purchase made with a card of the CB network.
The rule is executed on all card payment transactions.
The rule checks the BIN range database to determine whether the card is a card of the Carte Bancaire network.
Conditions of use
If you would like to use this rule, you must set the rule using the fraud tab in the Merchant Extranet.
Expression of the result
Use case | 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
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the CBScheme instruction.
- POST example:
fraudData.bypassCtrlList=CBScheme
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>CBScheme</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["CBScheme"]
}
Free e-mail address
Rule description
This rule enables you to assess the fraud risk of a purchase made by a customer whose e-mail address is free.
The rule checks whether the customer's e-mail address is part of a free e-mail address domain.
The following e-mail addresses are checked:
- the customer's e-mail address
- the e-mail address of the holder of the means of a payment (the customer might be using the means of payment of a relative)
- the billing contact's e-mail address
- the delivery contact's e-mail address
If one of the available e-mail addresses is on the list, a negative result is returned.
Conditions of use
If you would like to use this rule, you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- and send at least one of the customer's e-mail addresses in the request (billingContact.email, customerContact.email, deliveryContact.email, holderContact.email fields).
Expression of the result
Use case | Complementary Code | Rule result | RuleDetailedInfo |
---|---|---|---|
At least one of the e-mail addresses is on the list of free e-mail addresses. | 27 | Negative | -- |
None of the e-mail addresses are on the list of free e-mail addresses. | -- | Neutral | |
No e-mail addresses were sent. | -- | Neutral |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the FreeEmail instruction.
- POST example:
fraudData.bypassCtrlList=FreeEmail
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>FreeEmail</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["FreeEmail"]
}
3-D Secure authentication
Rule description
This rule enables you to measure the risk related to a transaction with 3-D Secure authentication according to the 3-D Secure status. Here, 3-D Secure authentication includes the following authentication programmes: Visa's 3-D Secure, MasterCard's SecureCode, American Express's SafeKey, Bancontact/Mister Cash authentication, etc.
The rule is executed on all card payment transactions with 3-D Secure authentication.
The rule checks whether the cardholder's authentication status is on a list of refused statuses.
If there is no list of refused statuses, the rule returns a neutral result.
Conditions of use
If you would like to use this rule, you must:
- activate the rule in the proifle using the fraud tab in the Merchant Extranet
- and set the list of prohibited 3-D Secure authentication statuses through the fraud tab in the Merchant Extranet.
Please refer to Appendix 5: 3-D Secure authentication statuses.
Expression of the result
Default mode (simple configuration):
Use case | Complementary Code | Rule result | RuleDetailedInfo |
---|---|---|---|
This rule cannot be executed (the means of payment does not support 3-D Secure authentication or you do not participate to the 3-D Secure authentication programme). | -- | Neutral | NOT_APPLICABLE |
The 3-D Secure status is prohibited. | 17 | Negative | -- |
The 3-D Secure status is not prohibited. | -- | Neutral |
This rule does not populate the complementaryInfo field.
Advanced configuration mode:
Use case | Complementary Code | Rule result | RuleDetailedInfo |
---|---|---|---|
This rule cannot be executed (the means of payment does not support 3-D Secure authentication or the merchant does not participate to the 3-D Secure authentication programme). | -- | Neutral | NOT_APPLICABLE |
The 3-D Secure status is on the list of disadvantaged statuses. | 17 | Negative | -- |
The 3-D Secure status is not on the lists of disadvantaged statuses and advantaged statuses. | -- | Neutral | |
The 3-D Secure status is on the list of advantaged statuses. | 17 | Positive |
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the 3DSStatus instruction.
- POST example:
fraudData.bypassCtrlList=3DSStatus
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>3DSStatus</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["3DSStatus"]
}
E-mail address syntax
Rule description
This rule enables you to assess the risk of a purchase according to whether the e-mail addresses used as part of the transaction are correctly formatted.
The rule checks whether the e-mail addresses used as part of the transaction are correctly formatted.
The following e-mail addresses are checked:
- the customer's e-mail address
- the e-mail address of the holder of the means of a payment (the customer might be using the means of payment of a relative)
- the billling contact's e-mail address
- the delivery contact's e-mail address
If one of the e-mail addresses submitted is incorrectly formatted, the rule returns a negative result.
Conditions of use
If you would like to use this rule, you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
and send at least one of the customer's e-mail addresses in the request (billingContact.email, customerContact.email, deliveryContact.email, holderContact.email fields).
Expression of the result
Use case | Complementary Code | Rule result | RuleDetailedInfo |
---|---|---|---|
The e-mail address is incorrectly formatted. | 46 | Negative | -- |
The e-mail address is correctly formatted. | -- | Neutral | |
No e-mail addresses were sent. | -- | Neutral |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the EmailSyntax instruction.
- POST example:
fraudData.bypassCtrlList=EmailSyntax
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>EmailSyntax</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["EmailSyntax"]
}
Address verification (InfoScore)
Rule description
This operation, which is delegated to InfoScore, is used to verify the delivery address submitted during an ELV transaction. This additional verification is carried out using the AZ Direct GmbH database; therefore, it only works with German addresses.
The check is only performed for ELV payments and Delivery addresses in Germany (the value of countryCode is "DEU").
InfoScore returns the result of the address check as an indicator. Please refer to Appendix 6: InfoScore address verification indicator for the meanings of these indicators.
These settings will enable you to accept or refuse certain values.
For instance, you can choose to trust only addresses for which the PPB and PHB checks are positive.
Conditions of use
If you would like to use this rule, you must:
- have subscribed to the InfoScore option
- activate the rule in the profile using the fraud tab in the Merchant Extranet
set the list of authorised/prohibited indicators through the fraud tab in the Merchant Extranet
and send the customer's postal delivery address in the request.
Expression of the result
Use case | Complementary Code | Rule result | RuleDetailedInfo |
---|---|---|---|
This rule cannot be executed (the InfoScore ID is missing, or the delivery address is not located in Germany.). | -- | Neutral | NOT_APPLICABLE |
The information is unknown. | -- | Neutral | IS_INDIC=XXX* |
The type of address returned by InfoScore is on the list of prohibited types or is not on the list of authorised types. | 48 | Negative | IS_INDIC=XXX* |
The type of address returned by InfoScore is on the list of authorised types or is not on the list of prohibited types. | -- | Neutral |
* XXX: indicator returned by InfoScore.
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the AddressVerification instruction.
- POST example:
fraudData.bypassCtrlList=AddressVerification
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>AddressVerification</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["AddressVerification"]
}
Account verification (InfoScore)
Rule description
This operation, which is delegated to InfoScore, is used to verify the debit account used during an ELV transaction. This verification is carried out using the Rücklastschriften-Präventions-Pool (RPP) database of InfoScore Consumer Data GmbH (ICD).
This verification is only performed for ELV payments.
The RPP pool for the risk management of direct debit rejections is a cross-industry data pool that contains banking information pertaining to various activity sectors and industries. The aim of the RPP is to prevent connection problems when using the “direct debit” means of payment.
Besides, the RPP database contains information about "non-consumer" accounts whose references may be public (associations' accounts, government accounts, companies, etc.).
When an account is identified, the information is returned in InfoScore's response to WL Sips.
The verification will return a negative value if:
- the account is a "non-consumer" account
- the account is part of the PAP (Proprietary Account Protection) programme, a list of accounts which have been prohibited from Internet use by their owners
- the account is on the KUNO list (Kriminalitätsbekämpfung im unbaren Zahlungsverkehr unter Nutzung nichtpolizeilicher Organisationen), which is a list of accounts blocked in Germany for various reasons
Conditions of use
If you would like to use this rule, you must:
- have subscribed to the InfoScore option
- activate the rule in the profile using the fraud tab in the Merchant Extranet
and set the list of authorised/prohibited indicators through the fraud tab in the Merchant Extranet
Expression of the result
Use case | Complementary Code | Rule result | RuleDetailedInfo |
---|---|---|---|
This rule cannot be executed (the InfoScore ID is missing). | -- | Neutral | NOT_APPLICABLE |
The information is unknown. | -- | Neutral | VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF* |
The account is not a consumer account, or is on the PAP or KUNO lists. | 49 | Negative | VALID=AAA;BBB; NCA_INFO=CCC;DDD; PAP_INFO=EEE;FFF* |
The account is a consumer account. | -- | Neutral |
* AAA: InfoScore resultCode (00 = the bank account is valid).
BBB: value of the NCA InfoScore indicator.
CCC: value of RppContentCode for InfoScore NCA KO.
DDD: value of the PAP InfoScore indicator.
EEE: value of RppContentCode for InfoScore PAP KO.
FFF: value of the InfoScore RPP indicator.
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the AddressVerification instruction.
- POST example:
fraudData.bypassCtrlList=AccountVerification
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>AccountVerification</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["AccountVerification"]
}
Card expiry date
Rule description
This rule enables you to detect the payments made with a card that will expire in the next few months. It is notably useful with payments in multiple instalments, to make sure the card will still be valid for the next instalments.
The rule is executed on all card transactions.
The rule checks whether the number of months before the card expires is higher than the number of months you specified.
If the minimum number of months before expiry is not configured, the rule considers that this number is equal to zero.
Conditions of use
If you would like to use this rule, you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
and set the minimum number of months before the card expires through the fraud tab in the Merchant Extranet
Expression of the result
Use case | Complementary Code | Rule result | RuleDetailedInfo |
---|---|---|---|
This rule cannot be executed (the means of payment is not a card). | -- | Neutral | NOT_APPLICABLE |
The validity time of the means of payment is shorter than the required duration. | 23 | Negative | EXPIRY=AAA:BBB* |
The validity time of the means of payment is longer than the required duration. | -- | Neutral |
* AAA: card expiry date in MMYY format.
BBB: deadline of the check in MMYY format.
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the ExpiryDate instruction.
- POST example:
fraudData.bypassCtrlList=ExpiryDate
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>ExpiryDate</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["ExpiryDate"]
}
List rules
Overview
The fraud risk management engine makes it possible to manage several data lists. Three different types of rules can be applied to these lists, as described below:
- blacklist verification
- greylist verification
- whitelist verification
The difference between these rules depends on the result of the rule and the way you manage the list:
- A blacklist is a NOGO-type list used for severe actions and usually leads to transactions being rejected.
- A greylist is a NOGO-type list used for suspicious cases that require special attention.
- A whitelist is a GO-type list used to treat certain customers with special positive attention.
The possible results according to the type of rule are shown below:
Data item is present | Blacklist result (NOGO-type) |
Greylist result (NOGO-type) |
Whitelist result (GO-type) |
---|---|---|---|
NO | Neutral | Neutral | Neutral |
YES | Negative | Négative | Positive |
For you, Internet purchases present a higher risk of fraud than "card present" purchases. Mail /telephone/Internet orders are major vectors of fraud if you sell and ship products. If the card is not physically present, you must rely on the cardholder (or someone who claims to be them) to submit the information indirectly by mail, telephone or the Internet.
You may want to track the customers (or properties related to them) with whom you have had good or bad experiences during previous purchases. For instance, if you have shipped a product to an address but have not been paid because the card was used fraudulently for this payment, you can decide to blacklist this number so payment requests are rejected if this card is used again on the webshop.
Here is another example: you can add a special customer name to a list if you assume that this customer has solvency issues, e.g. if a financial authorisation attempt was rejected with a code indicating "insufficient credit" on the account. In this case, you may want not to reject the transaction immediately, but rather be alerted if this name is used again in a transaction.
The merchant can also manage this name on what is called a greylist. This way, you can be alerted if one of the properties is used again during a different transaction, and process the new transaction with special care, review it manually, etc. Greylists are also a way of managing properties that can be considered as related to fraud.
On the other hand, you may have had bad experiences with certain customers but also very positive ones with others. Therefore, you can treat certain customers as "VIPs". B2B customers may prove sufficiently trustworthy as well. Whitelists are the appropriate way of managing such customers.
E-mail addresses
Rule description
This rule enables you:
- to decide whether to accept or refuse a purchase related to an e-mail address that is on the e-mail address blacklist or greylist.
- and/or decide whether or not to honour a purchase linked to an e-mail address that belongs to the whitelist of e-mail addresses without having to comply with the other decisive rules, which allows you to define a list of VIP e-mail addresses.
If the rule is present in your profile, it will be executed on all the payment transactions for which you sent at least one e-mail address.
The rule checks whether all the available e-mail addresses are on the e-mail address blacklist, greylist and/or whitelist you defined. The following e-mail addresses are checked:
- the customer's e-mail address
- the e-mail address of the holder of the means of a payment (the customer/buyer might be using the means of payment of a relative)
- the billing contact's e-mail address
- the delivery contact's e-mail address
If one of the e-mail adresses is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.
Conditions of use
If you would like to use this rule, you must, for each list:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
set the e-mail address black, grey and/or white list(s)
- and send one or more of the above e-mail adresses in the request (billingContact.email, customerContact.email, deliveryContact.email, holderContact.email fields)
Expression of the result
Use case | Complementary Code | Rule result | Rule DetailedInfo | |
---|---|---|---|---|
At least one e-mail address is on the list. | Black | 31 | Negative | -- |
Grey | 32 | |||
White | AC | Positive | ||
None of the e-mail addresses are on the list. | Black | -- | Neutral | |
Grey | ||||
White | ||||
No e-mail addresses were sent. | Black | |||
Grey | ||||
White |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackEmail (blacklist), GreyEmail (greylist) and/or WhiteEmail (whitelist) instruction(s).
- POST example:
Blacklist:
fraudData.bypassCtrlList=BlackEmail
Greylist:
fraudData.bypassCtrlList=GreyEmail
Whitelist:
fraudData.bypassCtrlList=WhiteEmail
- SOAP example:
Blacklist:
<urn:fraudData>
<urn:bypassCtrlList>BlackEmail</urn:bypassCtrlList>
</urn:fraudData>
Greylist:
<urn:fraudData>
<urn:bypassCtrlList>GreyEmail</urn:bypassCtrlList>
</urn:fraudData>
Whitelist:
<urn:fraudData>
<urn:bypassCtrlList>WhiteEmail</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
Blacklist:
"fraudData": {
"bypassCtrlList": ["BlackEmail"]
}
Greylist:
"fraudData": {
"bypassCtrlList": ["GreyEmail"]
}
Whitelist:
"fraudData": {
"bypassCtrlList": ["WhiteEmail"]
}
IP addresses
Rule description
This rule enables you:
- to decide whether to accept or refuse a purchase related to an IP address that is on the IP address blacklist or greylist.
- and/or decide whether or not to honour a purchase linked to an IP address that belongs to the whitelist of IP addresses without having to comply with the other decisive rules, which allows you to define a list of VIP IP addresses.
The rule checks whether the IP address is on the IP address blacklist, greylist and/or whitelist you defined. This IP address comes from:
- the automatic detection performed by the customer's browser in Sips Paypage
- or your transfer of data in the request in Sips Office
If the IP address is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.
Conditions of use
If you would like to use this rule, you must, for each list:
- activate the rule in the profile using the fraud tab in the Merchant Extranet,
set the IP address black, grey and/or white list(s)
- and send the customer's IP address in the request (customerIpAddress field), if you use Sips Office
Expression of the result
Use case | Complementary Code | Rule result | Rule DetailedInfo | |
---|---|---|---|---|
The IP address is not specified (in Sips Office) | Black | -- | Neutral | -- |
Grey | ||||
White | ||||
The IP address is on the list. | Black | 37 | Négativ | |
grey | 38 | |||
White | AE | Positive | ||
The IP address is not on the list. | Black | -- | Neutral | |
Grey | ||||
White |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackIp (blacklist), GreyIp (greylist) and/or WhiteIp (white list) instruction(s).
- POST example:
Blacklist:
fraudData.bypassCtrlList=BlackIp
Greylist:
fraudData.bypassCtrlList=GreyIp
Whitelist:
fraudData.bypassCtrlList=WhiteIp
- SOAP example:
Blacklist:
<urn:fraudData>
<urn:bypassCtrlList>BlackIp</urn:bypassCtrlList>
</urn:fraudData>
Greylist:
<urn:fraudData>
<urn:bypassCtrlList>GreyIp</urn:bypassCtrlList>
</urn:fraudData>
Whitelist:
<urn:fraudData>
<urn:bypassCtrlList>WhiteIp</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
Blacklist:
"fraudData": {
"bypassCtrlList": ["BlackIp"]
}
Greylist:
"fraudData": {
"bypassCtrlList": ["GreyIp"]
}
Whitelist:
"fraudData": {
"bypassCtrlList": ["WhiteIp"]
}
Postal codes per country
Rule description
This rule enables you:
- to decide whether to accept or refuse a purchase related to a postal code that is on the postal codes per country blacklist or greylist.
- and/or decide whether or not to honour a purchase linked to a postal code that belongs to the whitelist of postal codes without having to comply with the other decisive rules, which allows you to define a list of VIP postal codes.
If the rule is present in your profile, it will be executed on all the payment transactions for which you sent at least one postal code.
The rule checks whether all the available postal codes are on the postal code blacklist, greylist and/or whitelist you defined. The following postal codes are checked:
- the billing contact's postal code
- the delivery contact's postal code
If one of the postal codes is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.
Conditions of use
If you would like to use this rule, you must, for each list:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
set the postal code black, grey and/or white list(s)
- and send one or more of the above postal codes in the request (billingAddress.zipCode, deliveryAddress.zipCode fields)
Expression of the result
Use case | Complementary Code | Rule result | Rule DetailedInfo | |
---|---|---|---|---|
No postal codes were sent. | Black | -- | Neutral | -- |
Grey | ||||
White | ||||
At least one postal code is on the list. | Black | 39 | Negative | |
Grey | 40 | |||
White | AG | Positive | ||
None of the postal codes are on the list. | Black | -- | Neutral | |
Grey | ||||
White |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackPostalCode (blacklist), GreyPostalCode (greylist) and/or WhitePostalCode (whitelist) instruction(s).
- POST examples:
Blacklist:
fraudData.bypassCtrlList=BlackPostalCode
Greylist:
fraudData.bypassCtrlList=GreyPostalCode
Whitelist:
fraudData.bypassCtrlList=WhitePostalCode
- SOAP examples:
Blacklist:
<urn:fraudData>
<urn:bypassCtrlList>BlackPostalCode</urn:bypassCtrlList>
</urn:fraudData>
Greylist:
<urn:fraudData>
<urn:bypassCtrlList>GreyPostalCode</urn:bypassCtrlList>
</urn:fraudData>
Whitelist:
<urn:fraudData>
<urn:bypassCtrlList>WhitePostalCode</urn:bypassCtrlList>
</urn:fraudData>
- JSON examples:
Blacklist:
"fraudData": {
"bypassCtrlList": ["BlackPostalCode"]
}
Greylist:
"fraudData": {
"bypassCtrlList": ["GreyPostalCode"]
}
Whitelist:
"fraudData": {
"bypassCtrlList": ["WhitePostalCode"]
}
Customer IDs
Rule description
This rule enables you:
- to decide whether to accept or refuse a purchase related to a customer ID that is on customer ID blacklist or greylist.
- and/or decide whether or not to honour a purchase linked to a customer ID that belongs to the whitelist of customer IDs without having to comply with the other decisive rules, which allows you to define a list of VIP customer IDs.
If the rule is present in your profile, it will be executed on all the payment transactions for which a customer ID was submitted in the request or sent by you.
The rule checks whether the customer Id is on the customer ID blacklist, greylist and/or whitelist you defined.
If one of the customer ID is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.
Conditions of use
If you would like to use this rule, you must, for each list:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
set the customer ID black, grey and/or white list(s)
- and send the customer's customer ID in the request (customerId field)
Expression of the result
Use case | Complementary Code | Rule result | Rule DetailedInfo | |
---|---|---|---|---|
The customer ID is not supplied. | Black | -- | Neutral | -- |
Grey | ||||
White | ||||
At least one customer ID is on the list. | Black | 28 | Negative | |
Grey | 29 | |||
White | AB | Positive | ||
The customer ID is not on the list. | Black | -- | Neutral | |
Grey | ||||
White |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackCustomerId (blacklist), GreyCustomerId (greylist) and/or WhiteCustomerId (whitelist) instruction(s).
- POST example:
Blacklist:
fraudData.bypassCtrlList=BlackCustomerId
Greylist:
fraudData.bypassCtrlList=GreyCustomerId
Whitelist:
fraudData.bypassCtrlList=WhiteCustomerId
- SOAP example:
Blacklist:
<urn:fraudData>
<urn:bypassCtrlList>BlackCustomerId</urn:bypassCtrlList>
</urn:fraudData>
Greylist:
<urn:fraudData>
<urn:bypassCtrlList>GreyCustomerId</urn:bypassCtrlList>
</urn:fraudData>
Whitelist:
<urn:fraudData>
<urn:bypassCtrlList>WhiteCustomerId</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
Blacklist:
"fraudData": {
"bypassCtrlList": ["BlackCustomerId"]
}
Greylist:
"fraudData": {
"bypassCtrlList": ["GreyCustomerId"]
}
Whitelist:
"fraudData": {
"bypassCtrlList": ["WhiteCustomerId"]
}
Customer names
Rule description
This rule enables you:
- to decide whether to accept or refuse a purchase related to a customer name that is on the customer name blacklist or greylist
- and/or decide whether or not to honour a purchase linked to a customer name that belongs to the whitelist of customer names without having to comply with the other decisive rules, which allows you to define a list of VIP customer names
If the rule is present in your profile, it will be executed on all the payment transactions for which you sent at least one customer name.
The rule checks whether all the available names are on the customer name blacklist, greylist and/or whitelist you defined. The following customer names are checked:
- the customer's name
- the name of the holder of the means of payment (the customer/buyer might be using the means of payment of a relative)
- the billing contact's name
- the delivery contact's name
If one of the available names is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.
Conditions of use
If you would like to use this rule, you must, for each list:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
set the customer name black, grey and/or white list(s)
- and send at least one customer name in the request (billingContact.lastName, customerContact.lastName, deliveryContact.lastName, holderContact.lastName fields)
Expression of the result
Use case | Complementary Code | Rule result | Rule DetailedInfo | |
---|---|---|---|---|
No customer names were sent. | Black | -- | Neutral | -- |
Grey | ||||
White | ||||
At least one customer name is on the list. | Black | 35 | Negative | |
Grey | 36 | |||
White | AF | Positive | ||
None of the customer names are on the list. | Black | -- | Neutral | |
Grey | ||||
White |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackCustomerName (blacklist), GreyCustomerName (greylist) and/or WhiteCustomerName (whitelist).
- POST example:
Blacklist:
fraudData.bypassCtrlList=BlackCustomerName
Greylist:
fraudData.bypassCtrlList=GreyCustomerName
Whitelist:
fraudData.bypassCtrlList=WhiteCustomerName
- SOAP example:
Blacklist:
<urn:fraudData>
<urn:bypassCtrlList>BlackCustomerName</urn:bypassCtrlList>
</urn:fraudData>
Greylist:
<urn:fraudData>
<urn:bypassCtrlList>GreyCustomerName</urn:bypassCtrlList>
</urn:fraudData>
Whitelist:
<urn:fraudData>
<urn:bypassCtrlList>WhiteCustomerName</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
Blacklist:
"fraudData": {
"bypassCtrlList": ["BlackCustomerName"]
}
Greylist:
"fraudData": {
"bypassCtrlList": ["GreyCustomerName"]
}
Whitelist:
"fraudData": {
"bypassCtrlList": ["WhiteCustomerName"]
}
Card numbers
Rule description
This rule enables you:
- to decide whether to accept or refuse a purchase made with a card that is on your blacklist or greylist
- and/or decide whether or not to honour a purchase made with a card that belongs to your whitelist without having to comply with the other decisive rules, which allows you to define a list of VIP cards
If the rule is present in your profile, it will be executed on all the payment transactions by card you sent.
The rule checks whether the number submitted for authorisation (if applicable) is on your card number blacklist, greylist and/or whitelist.
If the card number in question is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.
Conditions of use
If you would like to use this rule, you must, for each list:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
and set the card number black, grey and/or white list(s) (cardNumber)
The list can be configured:
- through the fraud tab and Sips Office Extranet. The data must be added through a transaction ID. In the latter case, the value of the data for the transaction associated with the transaction ID will be added to the list.
- and through the populating batch of Sips Office Batch.
Expression of the result
Use case | Complementary Code | Rule result | Rule DetailedInfo | |
---|---|---|---|---|
This rule cannot be executed (the means of payment is not a card). | Black | -- | Neutral | -- |
Grey | ||||
White | ||||
The card number is on the list. | Black | 50 | Negative | |
Grey | 03 | |||
White | AA | Positive | ||
The card number is not on the list. | Black | -- | Neutral | |
Grey | ||||
White |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackCard (blacklist), GreyCard (greylist) and/or WhiteCard (whitelist).
- POST example:
Blacklist:
fraudData.bypassCtrlList=BlackCard
Greylist:
fraudData.bypassCtrlList=GreyCard
Whitelist:
fraudData.bypassCtrlList=WhiteCard
- SOAP example:
Blacklist:
<urn:fraudData>
<urn:bypassCtrlList>BlackCard</urn:bypassCtrlList>
</urn:fraudData>
Greylist:
<urn:fraudData>
<urn:bypassCtrlList>GreyCard</urn:bypassCtrlList>
</urn:fraudData>
Whitelist:
<urn:fraudData>
<urn:bypassCtrlList>WhiteCard</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
Blacklist:
"fraudData": {
"bypassCtrlList": ["BlackCard"]
}
Greylist:
"fraudData": {
"bypassCtrlList": ["GreyCard"]
}
Whitelist:
"fraudData": {
"bypassCtrlList": ["WhiteCard"]
}
Phone numbers
Rule description
This rule enables you:
- to decide whether to accept or refuse a purchase related to a phone number that is on the phone number blacklist or greylist
- and/or decide whether or not to honour a purchase linked to a phone number that belongs to the whitelist of phone numbers without having to comply with the other decisive rules, which allows you to define a list of VIP phone numbers
If the rule is present in your profile, it will be executed on all the payment transactions for which you sent at least one phone number.
The rule checks whether all the available phone numbers are on the phone number blacklist, greylist and/or whitelist you defined. The following phone numbers are checked:
- the customer's landline/mobile phone numbers
- the landline/mobile phone numbers of the holder of the means of payment (the customer/buyer might be using the means of payment of a relative)
- the billing contact's landline/mobile phone numbers
- the delivery contact's landline/mobile phone numbers
If one of the available phone numbers is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.
Conditions of use
If you would like to use this rule, you must, for each list:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
set the phone number black, grey and/or white list(s)
- and send one or more of the above phone numbers in the request (billingContact.phone, customerContact.phone, deliveryContact.phone, holderContact.phone, billingContact.mobile, customerContact.mobile, deliveryContact.mobile, holderContact.mobile fields)
Expression of the result
Use case | Complementary Code | Rule result | Rule DetailedInfo | |
---|---|---|---|---|
No phone numbers were sent. | Black | -- | Neutral | -- |
Grey | ||||
White | ||||
At least one phone number is on the list. | Black | 33 | Negative | |
Grey | 34 | |||
White | AD | Positive | ||
None of the phone numbers are on the list. | Black | -- | Neutral | |
Grey | ||||
White |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackPhoneNumber (blacklist), GreyPhoneNumber (greylist) and/or WhitePhoneNumber (whitelist) instruction(s).
- POST example:
Blacklist:
fraudData.bypassCtrlList=BlackPhoneNumber
Greylist:
fraudData.bypassCtrlList=GreyPhoneNumber
Whitelist:
fraudData.bypassCtrlList=WhitePhoneNumber
- SOAP example:
Blacklist:
<urn:fraudData>
<urn:bypassCtrlList>BlackPhoneNumber</urn:bypassCtrlList>
</urn:fraudData>
Greylist:
<urn:fraudData>
<urn:bypassCtrlList>GreyPhoneNumber</urn:bypassCtrlList>
</urn:fraudData>
Whitelist:
<urn:fraudData>
<urn:bypassCtrlList>WhitePhoneNumber</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
Blacklist:
"fraudData": {
"bypassCtrlList": ["BlackPhoneNumber"]
}
Greylist:
"fraudData": {
"bypassCtrlList": ["GreyPhoneNumber"]
}
Whitelist:
"fraudData": {
"bypassCtrlList": ["WhitePhoneNumber"]
}
BIN ranges
Rule description
This rule enables you:
- to decide whether to accept or refuse a purchase made with a card the BIN of which is on your BIN blacklist or greylist
- and/or decide whether or not to honour a purchase made with a card the BIN of which is on the whitelist of BINs without having to comply with the other decisive rules, which allows you to define a list of VIP BINs
If the rule is present in your profile, it will be executed on all the card payment transactions you sent.
The rule checks whether the card BIN number is on your BIN range blacklist, greylist and/or whitelist.
If the BIN number of the card in question is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.
Conditions of use
If you would like to use this rule, you must, for each list:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
and set the BIN number black, grey and/or white list(s) (cardNumber)
Expression of the result
Use case | Complementary Code | Rule result | Rule DetailedInfo | |
---|---|---|---|---|
This rule cannot be executed (the means of payment is not a card). | Black | -- | Neutral | -- |
Grey | ||||
White | ||||
The card BIN is on the list. | Black | 41 | Negative | |
Grey | 08 | |||
White | AH | Positive | ||
The card BIN is not on the list. | Black | -- | Neutral | |
Grey | ||||
White |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackBinCard (blacklist), GreyBinCard (greylist) and/or WhiteBinCard (whitelist) instruction(s).
- POST example:
Blacklist:
fraudData.bypassCtrlList=BlackBinCard
Greylist:
fraudData.bypassCtrlList=GreyBinCard
Whitelist:
fraudData.bypassCtrlList=WhiteBinCard
- SOAP example:
Blacklist:
<urn:fraudData>
<urn:bypassCtrlList>BlackBinCard</urn:bypassCtrlList>
</urn:fraudData>
Greylist:
<urn:fraudData>
<urn:bypassCtrlList>GreyBinCard</urn:bypassCtrlList>
</urn:fraudData>
Whitelist:
<urn:fraudData>
<urn:bypassCtrlList>WhiteBinCard</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
Blacklist:
"fraudData": {
"bypassCtrlList": ["BlackBinCard"]
}
Greylist:
"fraudData": {
"bypassCtrlList": ["GreyBinCard"]
}
Whitelist:
"fraudData": {
"bypassCtrlList": ["WhiteBinCard"]
}
BIC (Bank Identifier Code)
Rule description
This rule enables you to assess the risk of a purchase associated with a BIC (Bank Identifier Code) which is on the BIC blacklist, greylist and/or whitelist, without having to comply with the other decisive rules in the case of the whitelist, which allows you to define a list of VIP BICs.
If the rule is present in your profile, it will be executed on all the payment transactions made with the SDD means of payment.
The rule will check whether the BIC is on the BIC blacklist, greylist and/or whitelist you defined.
If the BIC is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.
Conditions of use
If you would like to use this rule, you must, for each list:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
and set the BIC black, grey and/or white list(s)
Expression of the result
Use case | Complementary Code | Rule result | Rule DetailedInfo | |
---|---|---|---|---|
The BIC is on the list. | Black | 66 | Negative | -- |
Grey | 67 | |||
White | AI | Positive | ||
The BIC is not on the list. | Black | -- | Neutral | |
Grey | ||||
White |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackBic (blacklist), GreyBic (greylist) and/or WhiteBic (whitelist) instruction(s).
- POST example:
Blacklist:
fraudData.bypassCtrlList=BlackBic
Greylist:
fraudData.bypassCtrlList=GreyBic
Whitelist:
fraudData.bypassCtrlList=WhiteBic
- SOAP example:
Blacklist:
<urn:fraudData>
<urn:bypassCtrlList>BlackBic</urn:bypassCtrlList>
</urn:fraudData>
Greylist:
<urn:fraudData>
<urn:bypassCtrlList>GreyBic</urn:bypassCtrlList>
</urn:fraudData>
Whitelist:
<urn:fraudData>
<urn:bypassCtrlList>WhiteBic</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
Blacklist:
"fraudData": {
"bypassCtrlList": ["BlackBic"]
}
Greylist:
"fraudData": {
"bypassCtrlList": ["GreyBic"]
}
Whitelist:
"fraudData": {
"bypassCtrlList": ["WhiteBic"]
}
IBAN (International Bank Account Number)
Rule description
This rule enables you to assess the risk of a purchase associated with an IBAN (International Bank Account Number) which is on the IBAN blacklist, greylist and/or whitelist, without having to comply with the other decisive rules in the case of the whitelist, which allows you to define a list of VIP IBANs.
If the rule is present in your profile, it will be executed on all the payment transactions made with the SDD means of payment.
The rule will check whether the IBAN used for the SDD mandate is on the IBAN blacklist, greylist and/or whitelist you defined.
If the IBAN is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.
Conditions of use
If you would like to use this rule, you must, for each list:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
and set the IBAN black, grey and/or white list(s)
Expression of the result
Use case | Complementary Code | Rule result | Rule DetailedInfo | |
---|---|---|---|---|
The IBAN is on the list. | Black | 68 | Negative | -- |
Grey | 59 | |||
White | AJ | Positive | ||
The IBAN is not on the list. | Black | -- | Neutral | |
Grey | ||||
White |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackIban (blacklist), GreyIban (greylist) and/or WhiteIban (whitelist) instruction(s).
- POST example:
Blacklist:
fraudData.bypassCtrlList=BlackIban
Greylist:
fraudData.bypassCtrlList=GreyIban
Whitelist:
fraudData.bypassCtrlList=WhiteIban
- SOAP example:
Blacklist:
<urn:fraudData>
<urn:bypassCtrlList>BlackIban</urn:bypassCtrlList>
</urn:fraudData>
Greylist:
<urn:fraudData>
<urn:bypassCtrlList>GreyIban</urn:bypassCtrlList>
</urn:fraudData>
Whitelist:
<urn:fraudData>
<urn:bypassCtrlList>WhiteIban</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
Blacklist:
"fraudData": {
"bypassCtrlList": ["BlackIban"]
}
Greylist:
"fraudData": {
"bypassCtrlList": ["GreyIban"]
}
Whitelist:
"fraudData": {
"bypassCtrlList": ["WhiteIban"]
}
Mandates
Rule description
This rule enables you to assess the risk of a purchase associated with a SDD mandate which is on the mandate blacklist, greylist and/or whitelist, without having to comply with the other decisive rules in the case of the whitelist, which allows you to define a list of VIP mandates.
If the rule is present in your profile, it will be executed on all the payment transactions made with the SDD means of payment.
The rule will check whether the mandate is on the mandate blacklist, greylist and/or whitelist you defined, based on its Unique Mandate Reference (UMR).
If the mandate is on a list, a negative (black and grey lists) and/or positive result (whitelist) is returned.
Conditions of use
If you would like to use this rule, you must, for each list:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
and set the mandate black, grey and/or white list(s)
Expression of the result
Use case | Complementary Code | Rule result | Rule DetailedInfo | |
---|---|---|---|---|
The UMR is on the list. | Black | 70 | Negative | -- |
Grey | 71 | |||
White | AK | Positive | ||
The UMR is not on the list. | Black | -- | Neutral | |
Grey | ||||
White |
This rule does not populate the complementaryInfo field.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the BlackMandate (blacklist), GreyMandate (greylist) and/or WhiteMandate (whitelist) instruction(s).
- POST example:
Blacklist:
fraudData.bypassCtrlList=BlackMandate
Greylist:
fraudData.bypassCtrlList=GreyMandate
Whitelist:
fraudData.bypassCtrlList=WhiteMandate
- SOAP example:
Blacklist:
<urn:fraudData>
<urn:bypassCtrlList>BlackMandate</urn:bypassCtrlList>
</urn:fraudData>
Greylist:
<urn:fraudData>
<urn:bypassCtrlList>GreyMandate</urn:bypassCtrlList>
</urn:fraudData>
Whitelist:
<urn:fraudData>
<urn:bypassCtrlList>WhiteMandate</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
Blacklist:
"fraudData": {
"bypassCtrlList": ["BlackMandate"]
}
Greylist:
"fraudData": {
"bypassCtrlList": ["GreyMandate"]
}
Whitelist:
"fraudData": {
"bypassCtrlList": ["WhiteMandate"]
}
Basket rules
Overview
The anti-fraud management engine takes basket contents into account for the purpose of risk assessment. To do this, it uses lists of risky products that you define yourself.
A risky product is a product that you sell and consider to be potentially associated with risky transactions, based on certain product criteria: category or type of product, price of product, frequent use of a product in fraudulent transactions, etc.
You have the option to define up to 3 lists of risky products for your webshop. You can also add some or all of the products that you sell to one or more lists, depending on the risk status of the product.
For exemple, you may choose to create 3 risky product lists as follows:
- one for low-risk products
- one for moderate-risk products
- and one for high-risk products
The risky product lists are used by the risk detection rules for the basket content of customers making a purchase on your website. If these rules are activated, they will analyse the basket content and compare it to the risky product list(s) you define to assess the risk of the transaction. You may then restrict the purchase of certain products to a certain quantity or a certain ratio of the total amount.
Risky product list
Rule description
This rule allows you to check whether there are risky products in the customer's basket.
The rule searches the risky product lists you defined, and configured in the rule, to check whether the customer's basket contains a product you consider to be potentially risky.
In the absence of a risky product list for the webshop or basket content for the request you send, the rule will return a neutral result.
Conditions of use
If you would like to use this rule, you must:
- activate the rule in the profile and select the list to be used via the fraud tab in the Merchant Extranet
set at least one risky product list via the fraud tab in the Merchant Extranet
- and send the customer's basket content in the request, particularly the product code for each product in the basket (ShoppingCartDetails field).
Expression of the result
Use case | Complementary Code | Rule result | Rule DetailedInfo |
---|---|---|---|
At least one product in the basket is on a risky product list. | 51 | Negative | -- |
Information unknown. | -- | Neutral | |
No products in the basket are on a risky product list. | -- | Neutral |
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the RiskyProductList instruction.
- POST example:
fraudData.bypassCtrlList=RiskyProductList
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>RiskyProductList</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["RiskyProductList"]
}
Risky product quantity
Rule description
This rule allows you to restrict the quantity of products in the basket which are on one of your risky product lists.
The rule will analyse the basket contents and check that:
- the quantity of a single product in the customer's basket included on one of these lists does not exceed the authorised limit configured in the rule
- the total quantity of all the products in the customer's basket included on a single list of risky products does not exceed the authorised limit configured in the rule
In the absence of basket content in the request you send, the rule will return a neutral result.
Conditions of use
If you would like to use this rule, you must:
- activate the rule in the profile and select the list to be used via the fraud tab in the Merchant Extranet
set at least one risky product list via the fraud tab in the Merchant Extranet
- and send the customer's basket content in the request, particularly the product code and quantity of each product in the basket (ShoppingCartDetails field).
Expression of the result
Use case | Complementary Code | Rule result | RuleDetailedInfo |
---|---|---|---|
At least one product in the basket is on a risky product
list, in a quantity greater than the limit configured in the rule
and/or the total quantity of products in the basket
included on a risky product list is greater than the limit
configured in the rule. |
52 | Negative | MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY _PER_LIST=L:C:D* |
Information unknown. | -- | Neutral | -- |
Aucun produit du panier n’appartient à une liste de
produits à risque ou Aucun produit du panier
appartenant à une liste de produits à risque n’a une quantité
supérieure au seuil paramétré dans la règle. |
-- | Neutral | MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B; MAX_QUANTITY _PER_LIST=L:C:D* |
*L: concerned risky product list name
A: biggest quantity of a product in the basket, belonging to that risky product list
B: maximum allowed quantity of a single product in the basket, belonging to that risky product list
C : sum of the quantities of all the products in the basket, belonging to that risky product list
D: maximum allowed cumulative quantity of all products in the basket, belonging to that risky product list
MAX_QUANTITY_PER_RISKY_PRODUCT=L1:A1:B1;MAX_QUANTITY_PER_LIST=L1:C1:D1; MAX_QUANTITY_PER_RISKY_PRODUCT=L2:A2:B2;MAX_QUANTITY_PER_LIST=L2:C2:D2; MAX_QUANTITY_PER_RISKY_PRODUCT=L3:A3:B3;MAX_QUANTITY_PER_LIST=L3:C3:D3
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the RiskyProductQuantity instruction.
- POST example:
fraudData.bypassCtrlList=RiskyProductQuantity
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>RiskyProductQuantity</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["RiskyProductQuantity"]
}
Risky product ratio
Rule description
This rule enables you to detect abnormal behaviour regarding the ratio between the amount of one or all of the products on a risky product list and the total amount of the customer's basket.
The rule will analyse the basket contents and check that:
- the ratio between the total amount of a single product (quantity x unit price) in the basket included on a risky product list and the total basket amount does not exceed the authorised limit configured in the rule
- the ratio between the total amount of all the products (quantity x unit price) in the basket included on a single risky product list and the total basket amount does not exceed the authorised limit configured in the rule
In the absence of basket content in the request you send, the rule will return a neutral result.
Conditions of use
If you would like to use this rule, you must:
- activate the rule in the profile and select the list to be used via the fraud tab in the Merchant Extranet
set at least one risky product list via the fraud tab in the Merchant Extranet
- and send the customer's basket content in the request, particularly the product code, unit price and quantity of each product in the basket (ShoppingCartDetails field).
Expression of the result
Use case | Complementary Code | Rule result | RuleDetailedInfo |
---|---|---|---|
The highest ratio between the total amount for at least one
product on a risky product list and the total basket amount is
higher than the limit configured in the
rule and/or the ratio between the total amount for
all the products on a risky product list and the total basket
amount is higher than the limit configured in the
rule. |
53 | Negative | MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D* |
Information unknown. | -- | Neutral | -- |
No products in the basket are on a risky product
list or the ratio between the total amount for
products on a risky product list and the total basket amount is
not higher than the limit configured in the rule and the ratio
between the total amount of all the products included in this
risky product list and the total basket amount does not exceed the
limit configured in the rule |
-- | Neutral | MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D* |
*L: concerned risky product list name.
A: biggest ratio between the total amount of a product in the basket, belonging to that risky product list, and the total amount of the basket.
B: maximum allowed ratio between the total amount of a product in the basket, belonging to that risky product list, and the total amount of the basket.
C: biggest ratio between the total amount of the quantities of all the products in the basket, belonging to that risky product list, and the total amount of the basket.
D: maximum allowed ratio between the total amount of the quantities of all the products in the basket, belonging to that risky product list, and the total amount of the basket.
MAX_RATIO_PER_RISKY_PRODUCT=L1:A1:B1;MAX_RATIO_PER_LIST=L1:C1:D1; MAX_RATIO_PER_RISKY_PRODUCT=L2:A2:B2;MAX_RATIO_PER_LIST=L2:C2:D2; MAX_RATIO_PER_RISKY_PRODUCT=L3:A3:B3;MAX_RATIO_PER_LIST=L3:C3:D3
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the RiskyProductRatio instruction.
- POST example:
fraudData.bypassCtrlList=RiskyProductRatio
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>RiskyProductRatio</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["RiskyProductRatio"]
}
Product quantity
Rule description
This rule enables you to restrict the quantity of a single product in a customer's basket.
The rule will analyse the basket contents and check that the quantity of each product does not exceed the limit configured in the rule. This rule does not use risky product lists.
In the absence of basket content in the request you send, the rule will return a neutral result.
Conditions of use
If you would like to use this rule, you must:
- activate the rule in the profile using the fraud tab in the Merchant Extranet
- and send the customer's basket content in the request, particularly the product code and quantity of each product in the basket (ShoppingCartDetails field).
Expression of the result
Use case | Complementary Code | Rule result | RuleDetailedInfo |
---|---|---|---|
At least one product in the basket is in a quantity greater than the limit configured in the rule. | 54 | Negative | PRODUCTQUANTITY =A:B* |
Information unknown. | -- | Neutral | PRODUCTQUANTITY =XXX:B* |
No product in the basket is in a quantity greater than the limit configured in the rule. | -- | Neutral | PRODUCTQUANTITY =A:B* |
* A: quantity of the first product found the quantity of which is above the threshold set in the rule.
B: maximum allowed quantity for all products in the basket.
Dynamic override
Dynamic override is not available for this rule.
Dynamic bypass
You can deactivate this rule for a given transaction except if the rule is imposed by the distributor. For this rule to be bypassed for this transaction, the request must contain the MaxQuantityPerProduct instruction.
- POST example:
fraudData.bypassCtrlList=MaxQuantityPerProduct
- SOAP example:
<urn:fraudData>
<urn:bypassCtrlList>MaxQuantityPerProduct</urn:bypassCtrlList>
</urn:fraudData>
- JSON example:
"fraudData": {
"bypassCtrlList": ["MaxQuantityPerProduct"]
}
Configuring antifraud profiles with the Merchant Extranet
This chapter describes the steps to follow to configure fraud risk management profiles on your portal.
Using the Fraud tab
Click on the Fraud tab to get access to the antifraud profile management tool homepage.
You can select the language of your choice (EN, FR) in the top-right corner.
Webshop list
The top-hand part of this page contains the list of webshops you have access to.
You can extend this section to select another webshop by clicking on the
icon.A data entry field at the top of this area makes it possible to filter webshops using all or part of their names or ID.
Click on one of the webshops to select it and display its profiles.
Main part
The menu at the top of this part enables you to access the features for administering the profiles and lists of the selected webshop.
The actions you can take depend on the role(s) assigned to your Merchant Extranet profile.
Pagination and multiple selection
Pagination
At several places of the interface, you may find tables the elements of which are shown across several pages when the content requires it. Buttons for navigating through the pages are then displayed.
Multiple selection
When list elements can be selected, a checkbox in the header of the list enables you to select or deselect all of them with a single click, including those that may be on other pages.
When multiple elements are selected, some buttons displayed at the bottom of the table make it possible to perform actions on the whole selection.
Administering antifraud profiles
Click on Manage shop profiles in the menu bar to access this section.
Profile list
The homepage of this section provides an overview of the webshop profiles in the form of a list.
If you have subscribed to the option to use the antifraud controls before the authentication, then a tab bar allows you to switch between the before authentication profile list and before authorisation profile list:
profile is inactive | profile is active |
The live status of a profile is inactive:
- if the profile has never been published
- if the profile has been deactivated manually
- or if the profile has been automatically deactivated by the activation of another profile that conflicts with the associated means of payment.
For the distributor's profile not to be used, it is preferable to always have an active default profile.
Status | Publication status |
---|---|
The profile has been created but never published. | |
The profile has been published and is used to evaluate transactions if it is active (see above). | |
The profile has been modified since it was last
published. It must be republished for the changes to be taken
into account for transaction evaluation. Important :
this does not affect the functioning of the published version of
the profile, which continues working the same way as
before. |
A profile consists of two entities: a working version and a published version.
The work version is one that you can modify and save as much as you like without any effects on the webshop transactions. It can be considered as a profile draft. When a new profile is created, it is actually a working version.
Once you are satisfied with the changes made to the working version, you can publish it to create the published version. This version of the profile is used to evaluate transactions.
The Payment means column shows the means of payment associated with a profile.
Profiles can be customised for specific means of payment. This column summarises them.
The means of payment over a coloured background are those associated with the published version of the profile.
The means of payment over a grey background are those that are only present in the working version, and which are thus inactive for transaction evaluation.
In the following example, Mastercard and Visa are associated with the published profile and CB is only in the working version:
You can click on the blue column header to sort the list according to the criterion.
Clicking on a profile of the list enables you to view and edit the details of its configuration.
Profile life cycle
Example of a profile life cycle:
Creating a profile
Click on the
button to create a new profile. The creation options are as follows:- Go-No-Go profile
If this option is authorised by the distributor, select the Go-No-Go profile option in the Create profile menu-button list. You will be given access to the new profile creation page.
or
- Select Copy existing to create a new profile from a profile
already existing in the webshop. A new window will pop up and let you
choose the profile to be copied.
Having chosen the profile to be copied, you will get access to the profile creation page.
or
- From a profile template
As with copying an existing profile, a popup window allows you to choose, from a list of available profile templates, the one that will serve as the basis for the new profile created.
You will then be taken to the profile creation page:
- Profile name:
The profile name must be unique for a given webshop and can consist of a maximum of 30 characters among the following: A-Z, a-z, 0-9, _ (underscore) and space.
- Means of payment:
You can choose whether the profile must apply to one or more specific means of payment. Check the boxes of the required means of payment. The list of the available means of payment depends on the contracts that are active on the webshop and configured in the Merchant Extranet.
Tip: default profilesIf the profile must apply to all means of payment, it is a default profile; therefore, there is no need to check anything.
The fact that a means of payment of the list is greyed out and tagged
indicates that it is already selected in another profile. You can still check it if you wish. It will then be removed from the other profile. A warning message is displayed to remind you of this when you check the means of payment:Attention: only one profile for a given means of paymentOnly one active profile can be associated with a given means of payment. The configuration interface guarantees this by automatically deleting the means of payment from the other profiles if there is a conflict with a newly edited profile. At the time of its publication, this profile will be fully associated with the means of payment concerned.
- Count refused transactions in velocity rules
Check this option to account for refused transactions in the counters (in addition to accepted transactions).
- Parameters currency
If a webshop has contracts that involve means of payment in multiple currencies, you can choose, in the details of a rule, the currency that is used to set amounts.
IMPORTANT: all transactions can be evaluated by a profile regardless of their respective currencies. Indeed, this parameter does not mean in any way that the profile only applies to the transactions the amounts of which are given in the chosen currency.If the transaction uses a currency other than the one configured in the profile, currency conversion is performed.
- Profile rules
The Manage rules section in the creation profile page enables you to choose the rules that must be applied as part of the profile. See the 'Administering rules in profiles' section for further details.
The profile is saved when the user clicks on the
button. At this moment, the profile is not active yet. It will have to be published (see the 'Editing and publishing a profile' section).The
button makes it possible to cancel the creation of the profile and to go back to the webshop profile list.Editing and publishing a profile
The profile editing page is almost identical to the creation page. In editing mode, the name of the profile cannot be modified.
- Profile status
A section on the right-hand side of the page provides details about the status of the profile:
This section includes the status (see the 'Profile list' section), the publication date and the settings currency. The modification date corresponds to the date on which the work version was saved for the last time.
- Actions available in editing mode
Action Description Saves the changes made to the working version. This operation does not publish the changes. For this purpose, you will have to use the "Publish" button. Restore a profile the working version of which has been modified, in the state it was in the last time it was published. This action is only available if the profile has been published and has been modified ever since (its status is then "To be republished".).Deletes an unpublished profile. This action can no longer be accessed from this page if the profile has been published. You will have to view the published version of the profile to delete it.Publishes the working version of the profile, which is then in effect for transaction evaluation. The orange colour indicates that this action may have consequences on the webshop transactions. Click on
to be taken back to the profile list.Click on
to view the published version of the profile if need be.
Viewing a published profile
From the profile editing page, you can view the published version using the
button.The following page displays:
This screen lets you view the details of the published profile and its rules.
- Actions that can be performed on a published profile
Action Description Activates the inactive published profile. This profile will then be in effect for transaction evaluation.Deactivates the inactive published profile. This profile will then no longer be in effect for transaction evaluation.Deletes a published profile. The orange colour indicates that this action may have consequences on the webshop transactions.
The
button takes you back to the working version of the profile.
Activating/deactivating a profile
To activate or deactivate a published profile, you must go to the page where you can view its published version:
- choose the profile to activate or deactivate in the webshop's profile list
- then click on in the profile details
- you will then have access to the or button depending on the profile's activation status.
To activate an unpublished profile, you only need to publish it.
Deleting a profile
To delete a published profile, like for activation and deactivation, you must go to the page where you can view the published version of the profile (see the 'Activating/deactivating a profile' section).
You will then be able to delete it using the
button.To delete an unpublished profile, access its working version (see the 'Editing and publishing a profile' section) then click on the
button.Administering rules in profiles
Adding or deleting a rule
The
button on the profile working version screen (see the 'Editing and publishing a profile' section), displays a pop-up window that makes it possible to activate rules in decisive or informational mode, or to deactivate them:When you are done with the selection, click on Ok to validate your choices.
Ordering and configuring rules
When clicking on the profile rules, you will see buttons that make it possible to perform actions on them.
- Available actions:
Action Description These buttons make it possible to order the execution of rules. This button makes it possible to modify the content of configurable rules if need be. Click on this button to delete a rule from the profile without using the rule selection pop-up window. This button makes it possible to convert an informational rule into a decisive one. This button makes it possible to convert a decisive rule into a informational one.
Please refer to the next sections for detailed rule configuration.
Filtering rules per means of payment
Some rules are related to a given means of payment (ex: SDD) or means of payment type (ex: cards). For instance, the card velocity can only be applied for payment cards (CB, VISA, MASTERCARD, AMEX) and the IBAN velocity can only be applied to a SDD payment.
When configuring the profile, the displayed rules are filtered according to the means of payment to which you subscribed. So if you did not subscribe to a given means of payment or means of payment type, you will not be able to use the rules restricted to it.
When a rule only applies to a means of payment (type), a label is dispayed next to it:
Configuring geolocation rules: addresses and countries
Card country
This section makes it possible to configure the list of the countries that the rule authorises or prohibits. This list can be displayed across several pages. The Result field corresponds to the result of the rule for the concerned country.
The Status radio buttons make it possible to specify whether the list that follows is a list of authorised or prohibited countries.
The Card country field makes it possible to add a country to the list by manually entering its name into the field (autocompletion is possible).
The
button displays a pop-up window that makes it possible to select one or more countries from a list:When manual data entry is in progress, the list is filtered accordingly, which makes it possible to see whether the country being entered is already on the list:
allows switching the rule to the advanced configuration mode. This mode gives the possibility to encourage or discourage countries involving respectively a positive or negative result:
You can export the list into a CSV file by clicking on the
button. This creates a file which contains all the items of the list and is automatically downloaded via browser.For more details on the CSV file contents, please refer to the following section: 'Appendix 11: list export file format'.
IP and card country
This section makes it possible to configure the list of the country combinations that the rule authorises or prohibits. The Result fied corresponds to the result of the rule for the concerned country.
The Status radio buttons make it possible to specify whether the list that follows is a list of authorised or prohibited country combinations.
The IP address country field makes it possible to manually enter the IP address country of the combination to add to the list.
You can specify a list of IP addresses right away using the selection pop-up window. This window is accessible through the
button on the right-hand side of the data entry area. In this case, once the list is selected, "country list" is displayed in the data entry area.The Card country field makes it possible to specify the card country of the combination to add to the list; it works in the same way as the IP address country field.
After entering the data either manually or through the pop-up window, you must click on the
button to add the selected country combinations to the list.Alternatively, clicking on the
button makes it possible to add the combinations and their reverse orders to the list. For instance, for the IP address country = France and Card country = Belgium, this button will add France/Belgium and Belgium/France to the combination list.When manual data entry is in progress, the list is filtered accordingly, which makes it possible to see whether the combination being entered is already on the list. This list can be displayed across several pages.
The Activate advanced mode button allows switching the rule to the advanced configuration mode. This mode gives the possibility to encourage or discourage countries involving respectively a positive or negative result.
You can export the list into a CSV file by clicking on the
button. This creates a file which contains all the items of the list and is automatically downloaded via your browser.For more details on the CSV file contents, please refer to the following section: 'Appendix 11: list export file format'.
Other rules
The configuration is done in the same way for many rules:
You would like to configure the following rule: | Please refer to the settings of the following rule: |
---|---|
|
IP and card country |
|
Card country |
|
This rule requires no specific configuration. |
|
This rule requires no specific configuration, but you cannot add it without (or position it before) the rule for checking the delivery and billing countries. |
Configuring velocity rules
Card velocity
The Period fields make it possible to specify the periods over which the number of transactions and the amount of transactions are added up for the card concerned. You can specify these times in hours, days or weeks using the
buttons.The Maximum number of transactions field makes it possible to specify the maximum number of transactions authorised over the period.
The Maximum cumulated amount field makes it possible to specify the maximum cumulative amount of the transactions over the period. The currency in which the cumulative amount is given is indicated in front of this field.
It is not mandatory to specify both a maximum cumulative amount and a maximum number of transactions. One of the two is enough.
Similarly, it is not mandatory to set the maximum number of transactions and the maximum cumulative amount. The setting of one of the two is enough.
Number of customers per card
The Period field makes it possible to specify the period over which customers are counted for the card concerned. This time can be specified in hours, days or weeks using the
button.Other rules
The configuration is done in the same way for many rules:
You would like to configure the following rule: | Please refer to the settings of the following rule: |
---|---|
|
Card velocity |
|
Number of customers per card |
Configuring miscellaneous rules
IP address reputations
You can update the Non-allowed statuses list using:
- to add the selected element from the Allowed statuses list to the Non-allowed statuses list
- or to remove the selected element from the Non-allowed statuses list.
For further details about IP reputations please refer to the 'Appendix 3: IP address reputations' section.
Cap collar amounts
The Minimum amount field makes it possible to specify the authorised minimum amount for a transaction. The currency in which the minimum amount is given is indicated in front of this field.
The Maximum amount field makes it possible to specify the authorised maximum amount for a transaction.
The Activate advanced mode field allows to switch the rule to the advanced configuration mode. This mode gives the possibility to encourage or discourage amount ranges involving respectively a positive or negative result. The result is neutral if the amount is not in one of both ranges.
Free E-mail address
The Domain name field allows typing a web domain name to add it to the forbidden web domain name list.
In the example above, hotmail.com is added to the list, which means that the E-mail addresses ending by @hotmail.com will be forbidden.
It’s possible to use an asterisk for the last part of the domain name to take into account all the possibilities. For example, adding hotmail.* to the list will refuse all the addresses ending by @hotmail.com, @hotmail.fr, @hotmail.be, etc.
3-D Secure authentication
The Non-allowed status list is updated in the same manner as for the IP address reputation list.
This list only shows the 3-D Secure statuses that risk evaluation functions can filter. Notably, the CANCEL or BYPASS statuses are not on it. The distributor may impose 3-D Secure status acceptance rules upstream of fraud risk management checks. Therefore, some transactions having certain statuses of this list might be interrupted even before a fraud risk management check can be performed. For further details about 3-D Secure statuses, please refer to 'Appendix 5: 3-D Secure authentication statuses'.
The Activate advanced mode button allows to switch the rule to the advanced configuration mode. This mode gives the possibility to encourage or discourage 3-D Secure status involving respectively a positive or negative result. It is possible to have a neutral result if the status is in the Allowed status list.
Card expiry date
The Period field makes it possible to specify the number of months before the card expires and below which the transaction will be refused.
Other rules
The configuration is done in the same way for many rules:
You would like to configure the following rule: | Please refer to the settings of the following rule: |
---|---|
|
Card country However, please keep in mind that the
Commercial card (and card country) rule is not eligible for
the advanced configuration mode. |
|
3-D Secure authentication |
|
These rules require no specific configuration. |
Configuring list rules
Populating lists
List rules require no specific configuration.
However, activating a list rule in a profile is not sufficient; you must also manage the list itself. To do so, three options exist:
- adding elements in the list using Sips Office Batch or
- adding elements in the list using Sips Office SOAP or JSON or
- using the Lists feeding tab.
Follow the procedure below to populate lists using the Merchant Extranet:
Click on the Lists feeding tab.
By accessing this section you gain access to the lists at your disposal: they vary according to the offer you have subscribed to. Please consult the list of rules for a complete list of existing list rules.
After choosing the relevant tab, you can choose to manage the greylist, blacklist or whitelist by clicking on the corresponding arrow on the right-hand side.:
When editing a list, you can:
- add a value to the list and specify a reason for the addition
- delete an entry from the list
- or move an entry from a greylist to a blacklist
Adding a value to a list
You must enter the value you want to add to a list into the appropriate data field.
A click on the
button displays a contextual window that makes it possible to select a reason for adding the value.Adding a value to the card numbers list
The management of card numbers on blacklists, greylists or whitelists is different from the management of other lists.
You can add a card number:
- using the transaction reference linked to the card number
- using the card number
- using the card's token
After selecting the entry mode using a combobox, you will be able to enter a token, a card number or a transaction reference on the screen.
Adding card numbers by transaction reference can be done by using either transaction references (WL Sips 2.0 primary key) or transaction identifiers and dates (WL Sips 1.0 primary key).
Adding card numbers by token can only be done if you have the "Merchant Token" option.
Selecting a reason to add an item to a list
Having clicked on the
button, select the reason in the popup window then click on OK, and the item will be added to the list.Adding a reason may prove handy later (for example to add a given customer ID to a whitelist). The reasons can be chosen from predefined sets that suit each type of list. But you may also decide to keep the "Not specified" default version.
The reasons are displayed next to the items:
They are identical for greylists and blacklists. Here is a summary of these reasons:
List type | Reasons for whitelists | Reasons for blacklists and greylists |
---|---|---|
E-mail addresses | Unspecified VIP Trusted e-mail
address B2B customer |
Unspecified Fraud
suspicion Negative experience Is on an
external blacklist General suspicion Unknown
e-mail address Non-payment Failed
debit Chargeback Multiple payment attempts
|
IP addresses | Unspecified VIP B2B customer Trusted
IP address |
Unspecified Fraud
suspicion Negative experience Is on an
external blacklist General suspicion Unknown
IP address Non-payment Failed
debit Chargeback Multiple payment attempts
|
Postal codes | Unspecified Positive
experience |
Unspecified Fraud
suspicion Negative experience Is on an
external blacklist Unknown postal code General
suspicion |
Customer IDs | Unspecified VIP B2B customer Trusted
customer ID Is part of a special action |
Unspecified Fraud
suspicion Negative experience Is on an
external blacklist General
suspicion Non-payment Failed
debit Chargeback Multiple payment attempts
|
Names | Unspecified VIP B2B customer Trusted
name |
Unspecified Fraud
suspicion Negative experience Is on an
external blacklist General
suspicion Non-payment Failed
debit Chargeback Multiple payment attempts
|
Card numbers | Unspecified VIP B2B customer Trusted
card Travel key card |
Unspecified Fraud
suspicion Negative experience Is on an
external blacklist Lost card Stolen
card Unknown card Prohibited
card Non-payment Failed
debit Chargeback Multiple payment attempts
|
Phone numbers | Unspecified VIP B2B customer Trusted
phone number |
Unspecified Fraud
suspicion Negative experience Is on an
external blacklist General suspicion Unknown
phone number Non-payment Failed
debit Chargeback Multiple payment attempts
|
BIN ranges | Unspecified Trusted BIN range |
Unspecified Fraud
suspicion Negative experience Is on an
external blacklist General suspicion |
BIC | Unspecified |
Unspecified Fraud
suspicion Negative experience Is on an
external blacklist General suspicion |
IBAN | Unspecified VIP B2B customer Trusted
IBAN |
Unspecified Fraud
suspicion Negative experience Is on an
external blacklist General suspicion Failed
debit Multiple payment attempts |
Mandates | Unspecified VIP B2B customer Trusted
mandate ID |
Unspecified Fraud
suspicion Negative experience Is on an
external blacklist General suspicion Failed
debit Multiple payment attempts |
Exporting a list
You can export a list into a CSV file by clicking on the
button. This creates a file which contains all the items of the list and is automatically downloaded via browser.This creates a file which contains all the items of the list and is automatically downloaded via your browser.For more details on the CSV file contents, please refer to 'Appendix 11: list export file format'.
Deleting a value from the list
It is also possible to delete items from the list, e.g. if they are not valid any more or were added by mistake:
- select one or more values to delete from the list by checking the boxes next to the appropriate items
- then click on the Delete selected entries button.
To avoid deleting an item by mistake, you must click on Confirm in the confirmation window.
Moving a value
Every greylist offers the possibility to move a selected entry to the appropriate blacklist e.g. if the severity of a case increases. This spares you the effort to delete an appropriate entry from the greylist and to re-enter it on the blacklist. The procedure is as follows:
- select one or more values to move from the greylist to the appropriate blacklist by checking the boxes next to the required items
- then move them using the Move selected item to the blacklist button.
To avoid deleting an item by mistake, you must click on Yes in the confirmation window.
Sizeable lists
When a white, grey or black list becomes too large, the list items displayed in the interface are limited to the first 600 items found.
In this case, an warning message is displayed above the list and a search feature is activated to allow you to find items in the list that are not displayed in the interface:
If you select Add item, the form allows you to add new items to the list (please refer to the 'Adding a value to a list' and 'Adding a value to the card numbers list' sections).
If you select Search item(s), the form allows searching using a given value (specific search) or using a partial one (filter). When clicking on the
button, the list is refreshed according to the result of the search:Specific item search
Filtering of the list
After one or several successive searches, the
button allows restoring the list to its initial state, displaying the first 600 items.Configuring basket rules
Managing risky product lists
Risky product lists are managed from the Risky product lists tab.
You are taken to the risky product list management page:
This page includes all the risky product lists already created.
Click on
to edit a list or on to delete it.Creating a list
Click on
to create a new risky product list.After clicking on this button, you have two options:
- Create a new list
Enter the name of the new list then click on OK.
or
- Use a shared list
To use a shared list, just choose the list you want from the drop-down menu.
The lists chosen and/or created will then be visible on the risky product management page, where each list can be edited, as well as the profile configuration page, so that you can select them.
Exporting/importing a list
You can export the list in Excel (.CSV) format by clicking on the
button. The generated file contains all the products of the list and is automatically downloaded by your browser.You can also import a list (in .CSV format) by clicking on the
button. Once the import has been completed, the list contains all of the products included in the imported file. The items previously in the list and not in the imported file are deleted.For more details on the CSV file contents, please read the following section: Appendix 11: list export file format.
Adding/updating/deleting a product
You can manually add a product to a list, using the
button.To add a product to a list, you must complete three fields:
- product code
- product label
- validity date
Once these fields have been completed and validated, the product is added directly to the list of risky products.
Click on the
icon to update a product, or on the icon to delete it.Risky product list
This section enables the risky product list being used to be configured. The various lists shown in this section were created previously from the List feeding -> Risky product lists tab.
Tick the risky product lists you wish to use. Several lists can be used at the same time.
indicates that the list is shared.
indicates that the list is private.
Product quantity
You can set the maximum quantity of products in a basket by manually entering the desired quantity in the field below:
Risky product quantity
The various lists shown in this section were created previously from the Lists feeding -> Risky product lists tab.
Tick the lists to be used. Several lists can be used at the same time.
For each product list, you can define the maximum quantity per product and the maximum quantity of all products by manually entering these quantities in the two numeric fields displayed under each list:
indicates that the list is shared.
indicates that the list is private.
Risky product ratio
This rule is configured in the same way as the 'Risky product quantity' rule, with the exception of values entered as ratios and not quantities.
History of actions on the interface
A log of the modifications made through the interface is displayed in the History tab.
This section lists all the changes on your profiles and also the ones having an impact on your fraud configuration: publication of a template profile or the association to a shared group/list. Changes on the webshop’s lists (e-mail lists, name lists, etc.) are not logged.
Table of modifications
When you arrive on the modifications page, the table is not filtered and contains all the changes related to the webshop, from the most recent to the oldest.
On the top of the page, different criteria are displayed to filter the modification logs: a minimum date, a maximum date, a user name or a log type (merchant profile, template profile or association).
After clicking on the
button, the application reloads the table with the filtered data.Each line in the table shows the date on which the action was performed, the user who performed the action, the modified entity and a brief description of the action.
icon to compare the object state before and after the modification.
Details of the modifications
Merchant profile and profile template
After clicking on the
icon, a popup displays, showing a comparison between the profile before and after the changes. By default, only the modifications are displayed, but it is possible to show the unchanged values also by clicking the Show unchanged values (entire profile details) checkbox.The comparison is made up of three parts:
- general information about the profile: name, means of payment, currency
- list of decisive rules
- list of informative rules
Modification on a rule
A colour code is used for rule modification:
Colour | Meaning |
---|---|
The rule name is in red and is preceded by the | symbol.The rule was removed from the profile. |
The rule name is in green and is preceded by the | symbol.The rule was added to the profile. |
The rule name is in orange and is preceded by the | symbol.The rule was moved in the profile, which means its mode has changed (from decisive to informative and vice versa) or that it is decisive and its execution rank has changed. |
The rule name is in black. | The rule content has changed. |
The rule name is in grey. | The rule has not changed (only visible when the proper checkbox is ticked). |
For example:
Rule name and colour | Meaning |
---|---|
The rule was not changed. | |
The rule was added in third position in the execution order. | |
The rule mode has changed from decisive to informative. | |
The rule has moved in the execution order from 2nd position to 1st position. | |
The rule mode has changed from decisive to informative with an execution order of 2. | |
The rule was removed. | |
The rule was not moved but its settings were changed. |
Modification on a value
Colour codes are also applied on value modification:
Value | Meaning |
---|---|
Value in green. | New value. |
Value in red and strikethrough text. | Former value. |
Value in black. | Value unchanged. |
In the case of a modification, the former value in red strikethrough text is followed by the new value in green.
Group/list association
After clicking on the
icon, a popup displays, showing the changes between the new group/list to which the eShop belongs and the former. So you will see the former in red strikethrough text and the new group in green :Appendices
Appendix 1: disabling some rules of the profile dynamically
If you wants to prevent the execution of a rule of your profile for a transaction, you can do so by sending the element that corresponds to the rule in the fraudData element of the payment request.
fraudData.bypass3DS | Disables 3D authentication |
fraudData.bypassCtrlList | Disables standard rules |
fraudData.bypassInfoList | Deprecated |
fraudData.bypass3DS
Value | Description |
---|---|
ALL | Bypasses the 3DS procedure (for CB, VISA, MASTERCARD and AMEX payments) |
MERCHANTWALLET | Bypasses the 3DS procedure during "1 Click" payment (for CB, VISA, MASTERCARD and AMEX payments) |
fraudData.bypassCtrlList
Value | Description |
---|---|
AccountVerification | Disable the Account verification (InfoScore) rule |
AddressVerification | Disable the Address verification (InfoScore) rule |
BlackBic | Disable the BIC blacklist rule |
BlackBinCard | Disable the BIN range blacklist rule |
BlackCard | Disable the Card number blacklist rule |
BlackCustomerId | Disable the Customer ID blacklist rule |
BlackCustomerName | Disable the Customer name blacklist rule |
BlackEmail | Disable the E-mail address blackslit rule |
BlackIban | Disable the IBAN blacklist rule |
BlackIp | Disable the IP address blacklist rule |
BlackMandate | Disable the Mandate blacklist rule |
BlackPhoneNumber | Disable the Phone number blacklist rule |
BlackPostalCode | Disable the Postal code blacklist rule |
CapCollarAmount | Disable the Amount range rule |
CardCountry ForeignBinCard (deprecated) |
Disable the Card country rule |
CBScheme | Disable the CB scheme card rule |
CommercialCard CorporateCard (deprecated) |
Disable the Commercial card (and card country) rule |
EmailSyntax | Disable the E-mail address syntax rule |
ECard | Disable the Virtual card rule |
ExpiryDate | Disable the Card expiry date rule |
FreeEmail | Disable the Free e-mail address rule |
GreyBic | Disable the BIC greylist rule |
GreyBinCard | Disable the BIN range greylist rule |
GreyCard | Disable the Card number greylist rule |
GreyCustomerId | Disable the Customer ID greylist rule |
GreyCustomerName | Disable the Customer name greylist rule |
GreyEmail | Disable the E-mail address greylist rule |
GreyIban | Disable the IBAN greylist rule |
GreyIp | Disable the IP address greylist rule |
GreyMandate | Disable the Mandate greylist rule |
GreyPhoneNumber | Disable the Phone number greylist rule |
GreyPostalCode | Disable the postal code greylist rule |
HotList | Disable the Lost and stolen card rule |
IbanCountry | Disable the IBAN country rule |
IpCountry | Disable the IP address country rule |
IpReputations | Disable the IP address reputation rule |
MaxCardPerCustomerId | Disable the Number of cards per customer rule |
MaxCardPerIp | Disable the Number of cards per IP address rule |
MaxCustidPerIban | Disable the Number of customers per IBAN rule |
MaxCustomerIdPerCard | Disable the Number of customers per card rule |
MaxIbanPerCustid | Disable the Number of IBAN per customer rule |
MaxIbanPerIp | Disable the Number of IBAN per IP address rule |
MaxCardPerIp | Disable the Number of cards per IP address rule |
MaxIpPerIban | Disable the Number of IP address per IBAN rule |
MaxMandatePerIp | Disable the Number of mandates per IP address rule |
MaxQuantityPerProduct | Disable the Product quantity rule |
RiskyProductList | Disable the Risky product list rule |
RiskyProductQuantity | Disable the Risky product quantity rule |
RiskyProductRatio | Disable the Risky product ratio rule |
SimilarityBillingCardCountry | Disable the Delivery and card country rule |
SimilarityDeliveryBillingCountry | Disable the Delivery and billing country rule |
SimilarityDeliveryBillingPostalCode | Disable the delivery and billing postal code rule |
SimilarityDeliveryCardCountry | Disable the Delivery and card country rule |
SimilarityDeliveryIbanCountry | Disable the Delivery and IBAN country rule |
SimilarityIpCardCountry SimilityIpCard
(deprecated) |
Disable the IP and card country rule |
SimilarityIpIbanCountry | Disable the IBAN country rule |
SimilarityPhoneIbanCountry | Disable the Phone and IBAN country rule |
SystematicAuthorizationCard | Disable the Systematic authorisation card rule |
VelocityCard | Disable the Card velocity rule |
VelocityCustomerId | Disable the Customer ID velocity rule |
VelocityIban | Disable the IBAN velocity rule |
VelocityIp | Disable the IP address velocity rule |
VelocityMandate | Disable the Mandate velocity rule |
WhiteBic | Disable the BIC whitelist rule |
WhiteBinCard | Disable the BIN range whitelist rule |
WhiteCard | Disable the Card number whitelist rule |
WhiteCustomerId | Disable the Customer ID whitelist rule |
WhiteCustomerName | Disable the Customer name whitelist rule |
WhiteEmail | Disable the E-mail address whitelist rule |
WhiteIban | Disable the IBAN whitelist rule |
WhiteBinCard | Disable the BIN range whitelist rule |
WhiteIp | Disable the IP address whitelist rule |
WhiteMandate | Disable the Mandate whitelist rule |
WhitePhoneNumber | Disable the Phone number whitelist rule |
WhitePostalCode | Disable the Postal code whitelist rule |
3DSStatus | Disable the 3-D Secure authentication rule |
All | Disable all rules |
Appendix 2: complementary codes
Values | Rule | Description |
---|---|---|
Empty | No check performed. | |
00 | All | All the checks you have opted for have been performed successfully. |
02 | Card velocity | Too many transactions/Excessive amount spent for the card used |
03 | Card number greylist | The card used is on your "greylist". |
06 | Card country | Simple mode: the country card associated with the
card number is not in your list of authorised
countries. Advanced mode: the country card associated
with the card number is on the list of disadvantaged countries or
is on the list of advantaged countries. |
07 | Virtual card | e-Card detected. |
08 | BIN range greylist | The BIN of the card used is part of a range defined on your "greylist". |
10 | IP address country | Simple mode: prohibited IP address
country. Advanced mode: advantaged or disadvantaged
IP address country. |
11 | Lost and stolen card | Lost and stolen card. |
12 | IP address and card country | Simple mode: prohibited “Card country/IP address
country” combination. Advanced mode: disadvantaged or
advantaged “Card country/IP address country”
combination. |
14 | Systematic authorisation card | Card with systematic authorisation. |
16 | IP address velocity | Too many transactions from the IP address. |
17 | 3-D Secure authentication | Simple mode: transaction blocked due to the
3-D Secure authentication. Advanced mode: transaction
disadvantaged or advantaged due to the 3-D Secure authentication
status. |
18 | Commercial card (and card country) | The card number corresponds to a corporate card number. |
19 | CB scheme card | The card number is not that of a card of the CB network. |
20 | Customer ID velocity | Too many transactions from this customer |
21 | Number of customers per card | Too many customers per card. |
22 | Number of cards per customer | Too many cards per customer. |
23 | Card expiry date | The card will expire soon. |
25 | Cap collar amounts | Simple mode: the amount is outside of the set
range. Advanced mode: The amount is inside of the set
range advantaged or inside of the set range
disadvantaged. |
26 | Delivery and billing postal codes | Prohibited “Delivery country/Billing country” combination. |
27 | Free e-mail address | At least one of the e-mail addresses supplied is from a free e-mail address provider. |
28 | Customer ID blacklist | The customer ID is on your "blacklist". |
29 | Customer ID greylist | The customer ID is on your "greylist". |
30 | Delivery and billing country | Prohibited “Delivery country/Billing country” combination. |
31 | E-mail address blacklist | At least one of the e-mail addresses supplied is on your "blacklist". |
32 | E-mail address greylist | At least one of the e-mail addresses supplied is on your "greylist". |
33 | Phone number blacklist | At least one of the phone numbers supplied is on your "blacklist". |
34 | Phone number greylist | At least one of the phone numbers supplied is on your "greylist". |
35 | Customer name blacklist | At least one of the contact names supplied is on your "blacklist". |
36 | Customer name greylist | At least one of the contact names supplied is on the merchant's "greylist". |
37 | IP address blacklist | The buyer's IP address is on your "blacklist". |
38 | IP address greylist | The buyer's IP address is on your "greylist". |
39 | Postal codes per country blacklist | The "Country/Postal code" combination is on your "blacklist". |
3L | Authentication guarantee | Transaction refused because it it not guaranteed by an entity (acquirer, wallet provider, etc.). |
40 | Postal codes per country greylist | The "Country/Postal code" combination is on your "greylist". |
41 | BIN range greylist | The BIN of the card used is part of a range defined on your "greylist". |
42 | Delivery and card country | Simple mode: prohibited “Card country/Delivery
country" combination. Advanced mode: disadvantaged or
advanted “Card country/Delivery country"
combination. |
43 | Commercial card (and card country) | The card number corresponds to a corporate card number, but the card issuing country does not correspond to a corporate card issuing country. |
44 | IP address reputations | The customer's IP address is prohibited. |
45 | Number of cards per IP address | The number of different cards for the same IP address has been exceeded. |
46 | E-mail address syntax | The e-mail address supplied is formatted incorrectly. |
47 | Billing and card country | Simple mode: prohibited “Card country/Billing
country” combination. Advanced mode: disadvantaged or
advanted “Card country/Billing country" combination. |
48 | Address verification (InfoScore) | Verification of the delivery address supplied. To date, address verifications only apply to ELV payments (InfoScore checks). |
49 | Account verification (InfoScore) | Validation of the bank account supplied. To date, bank account verifications only apply to ELV payments (InfoScore checks). |
50 | Card number blacklist | The card used is on your "blacklist". |
51 | Risky product list | At least one product in the basket is on a risky product list. |
52 | Risky product quantity | The quantity of risky products in the basket exceeds the allowed quantity. |
53 | Risky product ratio | The ration of risky products/total amount of the basket exceeds the allowed ratio. |
54 | Product quantity | The quantity of products in the basket exceeds the allowed quantity. |
55 | IBAN country | Simple mode: the IBAN country code is not
allowed. Advanced mode: the IBAN country is
disadvantaged or advantaged. |
56 | Delivery and IBAN country | Simple mode: the delivery country and IBAN country
combination is not allowed. Advanced mode: the delivery
country and IBAN country combination is disadvantaged or
advantaged. |
57 | Phone number and IBAN country | Simple mode: the phone number country and
IBAN country combination is not allowed. Advanced mode:
the phone number country and IBAN country combination is
disadvantaged or advantaged. |
58 | IP address and IBAN country | Simple mode: the IP country and IBAN country
combination is not allowed. Advanced mode: the
IP country and IBAN country combination is disadvantaged or
advantaged. |
59 | Number of IBANs per IP address | The number of IBANs per IP address exceeds the allowed threshold. |
60 | Number of IP addresses per IBAN | The number of IP addresses per IBAN exceeds the allowed threshold. |
61 | Number of customers per IBAN | The number of different customers per IBAN exceeds the allowed threshold. |
62 | Number of IBANs per customer | The number of different IBANs per customer exceeds the allowed threshold. |
63 | Number of mandates per IP address | The number of mandates per IP address exceeds the allowed threshold. |
64 | Mandate velocity | Too many transactions/Excessive amount spent for the mandate used. |
65 | IBAN velocity | Too many transactions/Excessive amount spent for the IBAN used. |
66 | BIC blacklist | The BIC is in your "blacklist". |
67 | BIC greylist | The BIC is in the your "greylist". |
68 | IBAN blacklist | The IBAN is in your "blacklist". |
69 | IBAN greylist | The IBAN is in your "greylist". |
70 | Mandate blacklist | The mandate is in your "blacklist". |
71 | Mandate greylist | The mandate is in your "greylist". |
99 | All | the WL Sips server encountered an issue when processing one of the additional local checks. |
AA | Card number whitelist | The card number is on your "whitelist". |
AB | Customer ID whitelist | The customer ID is on your "whitelist". |
AC | E-mail address whitelist | At least one of the e-mail addresses supplied is on your "whitelist". |
AD | Phone number whitelist | At least one of the phone numbers supplied is on your "whitelist". |
AE | IP address whitelist | The customer's IP address is on your "whitelist". |
AF | Customer name whitelist | At least one of the contact names supplied is on your "whitelist". |
AG | Postal codes per country whitelist | The "Country/Postal code" combination is on your "whitelist". |
AH | BIN range whitelist | The BIN of the card used is part of a range defined on your "whitelist". |
AI | BIC whitelist | The BIC is on your "whitelist". |
AJ | IBAN whitelist | The customer's BIC is on your "whitelist". |
AK | Mandate whitelist | The customer's SDD mandate is on your "whitelist". |
Appendix 3: IP address reputations
An IP address can have one or more of these reputations if it has been recently involved in one of the following situations:
IP address used for: | Description |
---|---|
Botnets | Botnets are viruses that infect a large number of machines
to:
|
Denial of service | A “Denial of service” attack aims to make a service
unavailable and prevent legitimate users from using it. It can
consist in:
|
Phishing | For fraudsters, phishing consists in obtaining confidential information (financial information, credentials for logging in to your company's system) through spam based on a fraudulent, malicious copy of a legitimate web page. |
Anonymous proxies | An anonymous proxy makes it possible to navigate anonymously. In general, it is a server that hides personal information (IP address, OS, browser) from the visited sites. |
Scanners | Scanners make it possible to know whether several machines have the same IP address because they are part of the same network. |
Spam source | Generally, it refers to the sending of massive quantities of e-mails for advertising purposes. |
Web attacks | Web application vulnerabilities can be classified as
follows:
|
Infected sources | IP addresses that send HTTP requests with a low reputation index or that are known malicious sites. |
Windows exploits | IP addresses that have exploited security holes against Windows resources using browsers, programmes, downloaded files, scripts or operating system vulnerabilities |
Appendix 4: ISO 3166 alphabetical country codes
ABW | Aruba | AFG | Afghanistan | AGO | Angola |
AIA | Anguilla | ALB | Albania | AND | Andorra |
ANT | Netherlands Antilles | ARE | United Arab Emirates | ARG | Argentina |
ARM | Armenia | ASM | American Samoa | ATA | Antarctica |
ATF | The French Southern and Antarctic Lands | ATG | Antigua and Barbuda | AUS | Australia |
AUT | Austria | AZE | Azerbaijan | BDI | Burundi |
BEL | Belgium | BEN | Benin | BFA | Burkina Faso |
BGD | Bangladesh | BGR | Bulgaria | BHR | Bahrain |
BHS | The Bahamas | BIH | Bosnia and Herzegovina | BLR | Belarus |
BLZ | Belize | BMU | Bermuda | BOL | Bolivia |
BRA | Brazil | BRB | Barbados | BRN | Brunei Darussalam |
BTN | Bhutan | BVT | Bouvet Island | BWA | Botswana |
CAF | The Central African Republic | CAN | Canada | CCK | Cocos (Keeling) Islands |
CHE | Switzerland | CHL | Chile | CHN | China |
CIV | Ivory Coast | CMR | Cameroon | COG | Congo |
COK | Cook Islands | COL | Colombia | COM | Comoros |
CPV | Cape Verde | CRI | Costa Rica | CUB | Cuba |
CXR | Christmas Island | CYM | Cayman Islands | CYP | Cyprus |
CZE | Czech Republic | DEU | Germany | DJI | Djibouti |
DMA | Dominica | DNK | Denmark | DOM | Dominican Republic |
DZA | Algeria | ECU | Ecuador | EGY | Egypt |
ERI | Eritrea | ESH | Western Sahara | ESP | Spain |
EST | Estonia | ETH | Ethiopia | FIN | Finland |
FJI | Fiji | FLK | Falkland Islands | FRA | France |
FRO | Faroe Islands | FSM | The Federated States of Micronesia | ATM | Gabon |
GBR | United Kingdom | GEO | Georgia | GHA | Ghana |
GIB | Gibraltar | GIN | Guinea | GLP | Guadeloupe |
GMB | Gambia | GNB | Guinea-Bissau | GNQ | Equatorial Guinea |
GRC | Greece | GRD | Grenada | GRL | Greenland |
GTM | Guatemala | GUF | French Guiana | GUM | Guam |
GUY | Guyana | HKG | Hong-Kong | HMD | Heard Island and McDonald Islands |
HND | Honduras | HRV | Croatia (local name: Hrvatska) | HTI | Haiti |
HUN | Hungary | IDN | Indonesia | IND | India |
IOT | British Indian Ocean Territory | IRL | Ireland | IRN | Iran (Islamic Republic of) |
IRQ | Iraq | ISL | Iceland | ISR | Israel |
ITA | Italy | JAM | Jamaica | JOR | Jordan |
JPN | Japan | KAZ | Kazakhstan | KEN | Kenya |
KGZ | Kyrgystan | KHM | Cambodia | KIR | Kiribati |
KNA | Saint Kitts and Nevis | KOR | Korea (the Republic of) | KWT | Kuwait |
LAO | Lao People's Democratic Republic (the) | LBN | Lebanon | LBR | Liberia |
LBY | Libya | LCA | Saint Lucia | LIE | Liechtenstein |
LKA | Sri Lanka | LSO | Lesotho | LTU | Lithuania |
LUX | Luxembourg | LVA | Latvia | MAC | Macao |
MAR | Maroc | MCO | Monaco | MDA | Moldova (the Republic of) |
MDG | Madagascar | MDV | Maldives | MEX | Mexico |
MHL | Marshall Islands (the) | MKD | Macedonia (the former Yugoslav Republic of) | MLI | Mali |
MLT | Malta | MMR | Myanmar | MNG | Mongolia |
MNP | Northern Mariana Islands (the) | MOZ | Mozambique | MRT | Mauritania |
MSR | Montserrat | MTQ | Martinique | MUS | Mauritius |
MWI | Malawi | MYS | Malaysia | MYT | Mayotte |
NAM | Namibia | NCL | New Caledonia | NER | Niger |
NFK | Norfolk Island | NGA | Nigeria | NIC | Nicaragua |
NIU | Niue | NLD | Netherlands (the) | NOR | Norway |
NPL | Nepal | NRU | Nauru | NZL | New Zealand |
OMN | Oman | PAK | Pakistan | PAN | Panama |
PCN | Pitcairn | PER | Peru | PHL | Philippines (the) |
PLW | Palau | PNG | Papua New Guinea | POL | Poland |
PRI | Puerto Rico | PRK | Korea (the Democratic People's Republic of) | PRT | Portugal |
PRY | Paraguay | PYF | French Polynesia | QAT | Qatar |
REU | Réunion | ROM | Romania | RUS | Russian Federation (the) |
RWA | Rwanda | SAU | Saudi Arabia | SDN | Sudan (the) |
SEN | Senegal | SGP | Singapore | SGS | South Georgia and the South Sandwich Islands |
SHN | Saint Helena | SJM | Svalbard and Jan Mayen | SLB | Solomon Islands |
SLE | Sierra Leone | SLV | El Salvador | SMR | San Marino |
SOM | Somalia | SPM | Saint Pierre and Miquelon | STP | Sao Tome and Principe |
SUR | Suriname | SVK | Slovakia | SVN | Slovenia |
SWE | Sweden | SWZ | Eswatini (former Swaziland) | SYC | Seychelles |
SYR | Syrian Arab Republic (the) | TCA | Turks and Caicos Islands (the) | TCD | Chad |
TGO | Togo | THA | Thailand | TJK | Tajikistan |
TKL | Tokelau | TKM | Turkmenistan | TLS | Timor-Leste |
TON | Tonga | TTO | Trinidad and Tobago | TUN | Tunisia |
TUR | Turkey | TUV | Tuvalu | TWN | Taïwan (Province of China) |
TZA | Tanzania (the United Republic of) | UGA | Uganda | UKR | Ukraine |
UMI | United States Minor Outlying Islands (the) | URY | Uruguay | USA | United States of America (the) |
UZB | Uzbekistan | VAT | Holy See (the) | VCT | Saint Vincent and the Grenadines |
VEN | Venezuela | VGB | Virgin Islands (British) | VIR | Virgin Islands (U.S.) |
VNM | Viet Nam | VUT | Vanuatu | WLF | Wallis and Futuna |
WSM | Samoa | YEM | Yémen | YUG | Yougoslavia |
ZAF | South Africa | ZAR | Zaire | ZMB | Zambia |
ZWE | Zimbabwe |
Appendix 5: 3-D Secure authentication statuses
Value | Description |
---|---|
ATTEMPT | You and the cardholder are enrolled in the authentication programme, but the customer did not have to authenticate themselves (the access control server of the bank that issued the card only implements the generation of proof of an authentication attempt). |
BYPASS | Because of certain criteria defined you defined, the verification of the authentication programme was not performed. |
ERROR | You are enrolled in the authentication programme, but the WL Sips server encountered a technical issue during the authentication process (while verifying whether the card was enrolled in the 3-D Secure programme or while authenticating the cardholder). |
FAILURE | You and the cardholder are enrolled in the authentication programme, but the customer could not authenticate themselves (wrong password). |
NO_AUTHENT | You are not enrolled in the authentication programme. |
NOT_ENROLLED | You are enrolled in the authentication programme, but the cardholder's card is not. |
NOT_PARTICIPATING | The customer did not authenticate themselves for one of the
following reasons:
|
SUCCESS | You and the cardholder are enrolled in the authentication programme, and the cardholder authenticated themselves correctly. |
Appendix 6: InfoScore address verification indicator
Value | Description |
---|---|
PPB | The person is known at the specified address. |
PHB | The person cannot be confirmed at the specified address, but the household is known there. |
PAB | The address is correctly formatted, and AZ knows the building, but AZ knows neither the person nor the household at the specified address. |
PUZ | The person is known but can no longer receive mail at the specified address, since they have moved to a new address that AZ knows. |
PNZ | The person is known but probably cannot receive mail at the specified address. |
PPV | The person is known at the specified address but is deceased. |
PUG | The address is correctly formatted but does not correspond to a person, household or building. |
PPF | The postal address is incorrect and cannot be checked any further. |
PXX | Technical error. |
Appendix 7: pre-established country code lists
Key | Comment Values |
---|---|
#EEA | The member States of the European Economic Area (European Economic Area) |
AUT, BEL, BGR, CYP, CZE, DEU, DNK, ESP, EST, FIN, FRA, GBR, GRC, HRV, HUN, IRL, ISL, ITA, LIE, LTU, LUX, LVA, MLT, NLD, NOR, POL, PRT, ROM, SVK, SVN, SWE | |
#EFTA | The member States of the free trade area (European Free Trade Association) |
ISL, LIE, NOR, CHE | |
#FRJEL | List of authorized countries for French games online |
AUT, BEL, BGR, CYP, CZE, DEU, DNK, ESP, EST, FIN, FRA, GBR, GRC, HRV, HUN, IRL, ISL, ITA, LTU, LUX, LVA, MLT, NLD, NOR, POL, PRT, ROM, SVK, SVN, SWE | |
#UE | The 28 States of the European Union |
DEU, AUT, BEL, BGR, CYP, CZE, DNK, ESP, EST, FIN, FRA, GBR, GRC, HRV, HUN, IRL, ITA, LTU, LUX, LVA, MLT, NLD, POL, PRT, ROM, SVK, SVN, SWE | |
#ZEURO | The member States of the Eurozone (EMU: Economic and Monetary Union) |
AUT, BEL, CYP, DEU, ESP, EST, FIN, FRA, GRC, IRL, ITA, LVA, LTU, LUX, MLT, NLD, PRT, SVK, SVN |
Appendix 8: card scheme list
CB - VISA - MASTERCARD - AMEX - JCB - BCMC - ACCORD - AURORE
Appendix 9: card product profiles
Value | Description |
---|---|
P | Prepaid |
D | Pay now |
C | Pay after |
H | Charge |
“ ” | Unknown |
Appendix 10: correspondences between means of payment and antifraud rules
Paylib and Masterpass are wallets of means of payment. So one should refer to the types of means of payment contained in the wallet to know if they are elligible to WL Sips antifraud controls.
Pre-authorisation mode
Table legend:
1 asterisk (*) means that the application of the rule depends on the card repository provided by your acquirer.
2 asterisks (**) mean that the application of the rule depends on the information you submit in the request.
For combined rules such as IP and card country, Delivery and card country and Billing and card country, information depends on both the card repository and information you submit in the payment request.
Geolocation rules |
---|
Velocity rules |
---|
Miscellaneous rules |
---|
List rules |
---|
Basket rules |
---|
Pre-authentication mode
The pre-authentication mode is only applicable to the transactions with a card (except for Paylib and Masterpass).
Table legend:
1 asterisk (*) means that the application of the rule depends on the card repository provided by your acquirer.
2 asterisks (**) mean that the application of the rule depends on the information you submit in the request.
For combined rules such as IP and card country, Delivery and card country and Billing and card country, information depends on both the card repository and information you submit in the payment request.
Geolocation rules |
---|
Velocity rules |
---|
Miscellaneous rules |
---|
List rules |
---|
Basket rules |
---|
Appendix 11: list export file format
Profile lists CSV file
The files which result of the export of a list configured in the rule in a profile are in the CSV format which uses the semi-column “;” as a separator;
The file name is by default formatted as follows: <list type>_list.csv (ex: country_list.csv).
The first line in the file is the column headers.
The subsequent lines stand for one item of the list.
Whatever the list type, the file format is the same.
Single country list
The file containing a country list (got from rules like “card country”, “IP address country”, etc.) has 1 column:
- COUNTRY: the ISO-3166 country code
Example:
Let’s take the list exported from the configuration of the rule “card country” in a profile:
Country |
---|
FRA |
DEU |
BEL |
Then the file will be as follows:
country_list.csv
COUNTRY;
FRA;
DEU;
BEL;
Country couple list
The file containing a country couple list (got from rules like “IP and card country”, “commercial card”, etc.) has 2 columns:
- COUNTRY1: the ISO-3166 country code
- COUNTRY2 : the ISO-3166 country code
Example:
Let’s take the list from the configuration of the rule “IP and card country” in a profile:
Country 1 | Country 2 |
---|---|
FRA | FRA |
DEU | FRA |
BEL | FRA |
Then the file will be as follows:
country_list.csv
COUNTRY1;COUNTRY2;
FRA;FRA;
DEU;FRA;
BEL;FRA;
E-mail domain list
The file containing an e-mail domain list (got from rule “free e-mail address”) has 1 column:
- DOMAIN: the web domain of a free e-mail address.
Example:
Let’s take the list from the configuration of the rule “free e-mail address” in a profile:
Domain |
---|
freedomain1.com |
freedomain2.com |
freedomain3.com |
Then the file will be as follows:
domain_list.csv
DOMAIN;
domaine1.com;
domaine2.com;
domaine3.com;
Black, grey or white list CSV file
The files which result of the export of a black, grey or white list are in the CSV format which uses the semi-column “;” as a separator;
The file name is by default formatted as follows:
<shop identifier>_<list colour>_<list type>.csv (ex : 200007755500002_GREY_PAN.csv).
The first line in the file is the column headers.
The subsequent lines stand for one item of the list.
Whatever the list type, the file format is the same, with the exception of the card numbers lists having a specific one.
Card number lists
The file containing card numbers lists has 5 columns:
- TRANSACTION_REF or TRANSACTION_ID: transaction reference or identifier depending on shop’s mode
- TRANSACTION_DATE: transaction date with AAAA-MM-JJ format
- MASKED_PAN: masked card number
- REASON: the code of the reason to the addition of the card to the list
- SHOP_ID: identifier of the shop that added the card to the list
Example:
Let’s take the card number black list of the shop with identifier 201000770050003:
Transaction ref./ID | Date | Card number | Reason | Webshop ID |
---|---|---|---|---|
915 | 2016-12-21 | 6703##########15 | fraud | 201000770050003 |
1546 | 2016-12-21 | 6703##########46 | fraud | 201000770050003 |
2530 | 2016-12-21 | 6703##########30 | fraud | 201000770050003 |
2735 | 2016-12-21 | 6703##########35 | fraud | 201000770050003 |
Then the file will be as follows:
201000770050003_BLACK_PAN.csv
TRANSACTION_REF;TRANSACTION_DATE;MASKED_PAN;REASON;SHOP_ID;
915;2016-12-21;6703##########15;fraud;201000770050003;
1546;2016-12-21;6703##########46;fraud;201000770050003;
2530;2016-12-21;6703##########30;fraud;201000770050003;
2735;2016-12-21;6703##########35;fraud;201000770050003;
Other lists
Except the files containing card numbers, all the files containing lists are made of 3 columns:
- ITEM: is list’s item value (e-mail, customer ID, IP address, etc.)
- REASON: the code of the reason to the addition of the card to the list
- SHOP_ID: identifier of the shop that added the card to the list
Example:
Let’s take the customer ID black list of the shop with identifier 201000770050003:
Item | Reason | Webshop |
---|---|---|
123456 | fraudSuspicion | 201000770050003 |
987654 | negativeExperience | 201000770050003 |
456789 | notSpecified | 201000770050003 |
654321 | fraud | 201000770050003 |
Then the file will be as follows:
201000770050003_BLACK_CUSTOMER.csv
ITEM;REASON;SHOP_ID;
123456;fraudSuspicion;201000770050003;
987654;negativeExperience;201000770050003;
456789;notSpecified;201000770050003;
654321;fraud;201000770050003;
Risky product CSV file
The files which result of the export of a risky product list are in the CSV format which uses the semi-column “;” as a separator
The file name is by default formatted as follows: <shop identifier>_<list name>.csv (ex: 200007755500002_My_product_list.csv).
Each line of the file corresponds to an item of the list and has three columns:
- product code
- product label
- validity date
Example:
When a list contains the following items:
Product code | Product label | Validity date |
---|---|---|
A858F | Produit 1 | 29/10/2016 |
F85F4 | Produit 2 | 31/10/2016 |
The matching CSV file is:
A858F;Produit 1;29/10/2016
F85F4;Produit 2;31/10/2016