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 Business Score mode and to explain how to implement and set them up.

The Business Score terminology refers to the calculation of the overall risk score of the transaction through the aggregation of the weight of each antifraud rule. You have complete autonomy to determine the profile of the transactions that you consider as "high-risk" transactions.

Who does this document target?

This document is intended for merchants who have subscribed to the " Business Score fraud risk management" offer and wish to enjoy an anti-fraud tool administered by themselves on the MEX .

To get an overview of the WL Sips solution, we advise you to consult the following documents:

  • Functional presentation
  • Functionality set-up guide
  • Glossary

Contacting the support

For any technical question or request for assistance, our services are available:

  • by telephone at: +33 (0) 811 10 70 33
  • by e-mail: sips@worldline.com

In order to facilitate the processing of your requests, please provide your merchantId (15-digit number).

Overview

Accessing the MEX

All fraud management functions described in this documentation are administered in the MEX .

You must have subscribed to the Business Score offer to be able to access these functions.

The MEX 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 MEX ' 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.

Note: the existing fraud management extranet and reporting tools are designed so you can manage the antifraud solution independently.

Antifraud rule definition

What is an antifraud rule?

An antifraud rule verifies one of the transaction's criteria. The criterion verified can be the card country, cap collar amounts, card number, IP address, customer ID, etc. Rules are classified into categories: geolocation, velocity, list, basket and miscellaneous.

To be executed, rules must be configured in an antifraud profile. Please refer to the 'Antifraud profile definition' section to know how to define such a profile.

Positive and negative rules

Positive rule

A positive rule aims to detect a favourable condition for the acceptance of the transaction (e.g. the customer ID is on the customer ID whitelist.).

If the condition is met, the rule returns a score that is higher than or equal to zero depending on the configuration of the rule. Otherwise, it does not return any score.

Currently, positive rules are based on the presence of an element of the transaction on whitelists, which are also called positive lists.

Negative rule

A negative rule aims to detect an unfavourable condition for the acceptance of the transaction (e.g. the customer ID is on the customer ID blacklist).

If the condition is met, the rule returns a score that is lower than or equal to zero depending on the configuration of the rule. Otherwise, it does not return any score.

There are five categories of negative rules:

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

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

Nevertheless, some rules have an advanced configuration mode. In this mode, the same rule can be both  positive and  negative . 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
  • Min = 50
  • Max = 200
45 Negative Trigger 3-D Secure
150 Neutral Proceed to the next rules
250 Negative Trigger 3-D Secure
Advanced configuration mode Positive range:
  • Min = 50
  • Max = 150

Negative range:

  • Min = 300
  • MAx = 400
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 of the WL Sips antifraud tool:

  • pre-authorisation mode: allows stopping the fraudulent transaction before the authorisation request.
  • pre-authentication mode: allows bypassing 3-D Secure for transactions considered as safe.
Figure 1. execution of processes during a payment transaction

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.
IMPORTANT: clarification on rules available in pre-authentication

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.

IMPORTANT: profile templates and merchant profiles are separated in pre-authentication and pre-authorisation. For example, a profile template in pre-authorisation cannot be used to create merchant profiles in pre-authentication. A merchant profile in pre-authentication cannot apply to the pre-authorisation step during payment.

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.

Attention: if no active profiles are available on the webshop, the distributor's offering profile will be used.

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

Setting rules as weighted or decisive

Illustration of the weight of the settings:

Weighted rules

When defining a profile, you must choose, activate and order the rules among those that are available in your offering.

When activating a rule, you must set its weight according to its importance:

  • the weight of positive rules ranges from 0 (neutral) to +3 (very important)
  • the weight of negative rules ranges from 0 (neutral) to -3 (very important).

If the condition of the rule is met, the score obtained is the weight that the merchant defined when they activated the rule in the profile. Otherwise, a score of 0 is obtained.

For example, a negative rule of average importance (-2) will produce a score of -2 if its condition is met.

The rules that you deem particularly important can be configured in decisive mode (see below).

Decisive rules

If a rule is crucial for you, you can set it as decisive, which makes it possible to decide whether to accept the transaction or not while disregarding the other rules:

  • the weight of positive rules is +4
  • the weight of negative rules is -4

If the condition of the decisive rule is met, the result of antifraud checks is only determined by this rule, regardless of the results of the others. Otherwise, the result of antifraud checks is determined by the overall score.

Note: warning

You can set several rules as decisive. In this case, the favourable or unfavourable result of the first decisive rule prevails. Therefore, it is very important that decisive rules be ordered in decreasing order of importance.

Definition of the red, orange and green ranges

In Business Score mode, each active rule of the profile evaluates an aspect of the transaction and can produce a score.

The rule scores are then added up to produce an overall score (please refer to the calculation of the overall score subsection to know how it is calculated). This overall score is then compared to the orange and green thresholds set in the profile so a decision can be made as to the continuation of the transaction.

The overall score is comprised between two limits:

  • the min bound, which is the value obtained if all negative rules and no positive rules are triggered (i.e. sum of negative rules' scores)
  • the max bound, which is the value obtained if all positive rules and no negative rules are triggered (i.e. sum of positive rules' scores)

Therefore, when you define the profile, you must define the orange and green thresholds between the min and max bounds, which will delimit 3 possible ranges for scores. Each of these ranges is associated with a colour: green, orange and red (please refer to the execution modes (pre-authentication & pre-authorisation) and their consequences on acceptance for further details about colours and their effects on transactions):

  • The orange threshold defines the limit between the orange area and red area. The value is included in the orange area.
  • The green threshold defines the limit between the orange area and green area. The value is included in the green area.

In the following example, orange threshold -8 is included in the orange area, and green threshold -4 is included in the green area.

If both the orange and green thresholds have the same value, then there is no orange area.

In the following example, the orange threshold and the green one both have the same score of -6. Score -6 is included in the green area.

Example: an antifraud profile contains 3 rules:

  • rule 1, negative rule, associated score -3
  • rule 2, negative, associated score -2
  • rule 3, positive rule, associated core +3

Therefore, you must set the orange and green thresholds between -5 (min bound) and +3 (max bound).

In this case:

  • the orange threshold is -2
  • the green threshold is +1
  • the red area is between score -5 (included) and -3 (included)
  • the orange area is between score -2 (included) and 0 (included)
  • the green area is between score +1 (included) and +3 (included)

Execution and result of an antifraud profile

When a transaction must be evaluated, the fraud risk management system first looks for the antifraud profile associated with the means of payment in the webshop configuration. If no such profile is found, the system uses the webshop's default profile.

The antifraud profile is executed before the authorisation request.

The profile's rules are executed simultaneously except for the rules set as decisive, which are executed in the order you defined. You can still disable or change the configuration of one or more rules for a given transaction.

Bypassing rules dynamically

You can bypass certain rules of the profile dynamically in the transaction request. For a list of directives to be used to bypass rules, please refer to the following section: 'Appendix 1: disabling some rules in the profile dynamically'.

Note: warning

You cannot bypass the rules imposed by the distributor.

Note: The dynamic override is applicable to the active rules in both pre-authentication profiles and pre-authorisation profiles (to understand the pre-authentication and pre-authorisation modes, please refer to the following section: 'Execution modes and consequences on acceptance' ).

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.

IMPORTANT: you cannot override the rules imposed by the distributor.
Note: dynamic overriding applies to the active rules inside pre-authentication and pre-authorisation profiles (please refer to the 'execution modes (pre-authentication & pre-authorisation) and consequences on acceptance' section to understand the pre-authentication and pre-authorisation modes).

Calculation of the overall score

The overall score is the sum of all rules' scores and determines the result of the antifraud checks.

For a given profile containing n individual checks:

  • let Rk be the result of the individual check indexed by k in the profile:
    • 0 if not checked
    • 1 if checked
  • let Pk be the weight associated with the individual check indexed by k:
    • 0 for neutral
    • 1 for low
    • 2 for medium
    • 3 for high
    • 4 for decisive
  • let Tk be the nature of the individual check indexed by k:
    • +1 when positive
    • -1 when negative

The overall score (S) of the transaction verified with this profile will be obtained through the following formula:

Note: the overall score is the mathematical sum of all rules including those set as decisive.

Overall result

The final result of the antifraud checks of the Business Score offering is represented by one of five colours.

Three colours represent the result obtained from the overall score:

  • green: the overall score is higher than or equal to the profile's green threshold. The green result means that the transaction poses no risk.
  • orange: the overall score is higher than or equal to the profile's orange threshold, and lower than the green threshold. The orange result means that the transaction poses an average risk.
  • red: the overall score is lower than the profile's orange threshold. The red result means that the transaction poses a high risk.

Two colours represent a result that was obtained because a decisive rule was triggered:

  • white: the condition of a positive rule set as decisive is met; the rule produced a positive result. The white result means that the transaction poses no risk.
  • black: the condition of a negative rule set as decisive is met; the rule produced a negative result. The black result means that the transaction poses a high risk.
Note: order in which decisive rules are defined

If several decisive rules give positive and/or negative results, the first rule with the highest priority prevails. This means that the order in which decisive rules are defined in the profile is important.

Note: the decision is made on the basis of the colour

It is important to understand that it is the colour which decides whether the transaction must be processed or not:

  • black or white: the decision is made without taking into account the overall score, which only has an informational value.
  • red, orange or green: the decision is made from the transaction’s overall score, which is compared to the set orange and green thresholds.

Therefore, the colour is not necessarily consistent with the overall score. It is thus possible to obtain a white result with an overall score that is lower than the orange threshold, or to obtain a black result with a score that is higher than the green threshold.

Example : profile set with 5 rules:

  • rule 1: customer ID whitelist set as decisive (weight: +4)
  • rule 2: card number blacklist set as decisive (weight: -4)
  • rule 3: IP address velocity (weight: -3)
  • rule 4: card country (weight: -2)
  • rule 5: IP address country (weight: -2)

Orange threshold = 0, green threshold = +2

Managing orange results

The CHALLENGE option enables you to put ORANGE transactions on hold (TO_CHALLENGE status) so you can assess the risk thereof before proceeding with the other steps of the acceptance process: validation, reauthorisation or capture.

If you do not have the CHALLENGE option, the transaction is accepted.

You have X days to assess the risk of fraud, and validate or refuse the transaction. X is the maximum value between the validity of the authorisation and the capture day (captureDay ) you defined during the payment (please see the example below).

To assess the risk of the transaction, you can use the scoreInfo field, which contains the breakdown of the execution of the rules. This field is returned by WL Sips in the payment response ( Sips Paypage , Sips Office ).

You can use two transaction management operations:

  • acceptChallenge , to accept the transaction
  • refuseChallenge , to refuse the transaction (REFUSED status)

These two operations are available in the following interfaces:

  • Sips Office (please refer to the following documents: Sips Office  SOAP, Sips Office  JSON et Sips Office Batch )
  • Sips Office Extranet
  • MEX

The main management rules of the challenge operations are as follows:

  • If the transaction is created in VALIDATION mode, the acceptance of the challenge can be combined with the validation of the transaction in a single step.
  • The life cycle of a transaction continues if the challenge is accepted (capture, refund, etc.).
  • The life cycle of a transaction ends if the challenge is refused (REFUSED status).
  • A transaction whose status is TO_CHALLENGE can be cancelled. If no operations are executed on the transaction within the allotted time, the transaction expires.
  • The management of the orange result only applies to CB, Visa, Mastercard and Amex transactions.

Below is the life cycle of a transaction with the management of the orange result.

Depending on when the challenge is accepted, on captureDay, on captureMode and on the maximum validity period of an authorisation, the day of the remittance varies.

A distinction is made between use cases in AUTHOR_CAPTURE mode and in VALIDATION mode.

AUTHOR_CAPTURE mode

  • Use case 1:
    • The captureDay is lower than the maximum period of validity of an authorisation.
    • The challenge is accepted before the end of the captureDay period.
    • The remittance is done as planned at the end of the captureDay period.

Example: captureDay at 3, authorisation period at 6. The challenge is accepted at D+2:

  • Use case 2:
    • The captureDay is lower than the maximum period of validity of an authorisation.
    • The challenge is accepted after the end of the captureDay period.
    • The remittance is done the evening of the acceptance of the challenge.

Example: captureDay at 3, authorisation period at 6. The challenge is accepted at D+4:

  • Use case 3:
    • The captureDay is higher than the maximum period of validity of an authorization.
    • The challenge is accepted after the end of the validity of the authorisation request.
    • A new request for authorization is made and the bank remittance is made in accordance with the captureDay.

Example: authorisation period at 6. Challenge is accepted at D+7, captureDay at 10:

VALIDATION mode

  • Use case 1:
    • The captureDay is lower than the maximum period of validity of an authorisation.
    • The challenge is accepted before the end of the captureDay period.
    • The validation is done after acceptance of the challenge and before or on the same day as the captureDay.
    • The bank remittance is done the evening of the validation.

Example: captureDay at 3, authorisation period at 6. The challenge is accepted at D+2, the validation at D+3:

  • Use case 2:
    • The captureDay is higher than the maximum period of validity of an authorisation.
    • The challenge is accepted before the end of the captureDay period.
    • The authorisation is executed during the validation operation.
    • The bank remittance is done the evening of the acceptance of the challenge.

Example: captureDay at 7, authorisation period at 6. The challenge is accepted at D+2, the validation at D+3:

Note: in validation mode, once the challenge has been accepted, you must validate your transaction before the end of the captureDay period, otherwise the transaction cannot be validated and therefore remitted to bank.

We advise you to do the validation at the same time as the acceptance of the challenge by populating the validationIndicator field in the acceptChallenge request with « Y ».

Expression of rule results

Pre-authorisation mode

The result of the execution of the pre-authorisation profile is returned in the fields below:

  • scoreColor , rule results represented in the form of a colour
  • scoreValue , value of the overall score
  • scoreProfile , antifraud profile executed
  • 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 checks were performed
  • scoreThreshold , thresholds set for this profile
  • scoreInfo , breakdown of the executed rules
  • preAuthorisationRuleResultList , a list of detailed results of each rule executed before the authorisation

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 .
  • ruleType , the rule type. For rule types, please refer to the list of rules .
  • ruleWeight , the rule weight defined in the profile:
    • 0: neutral
    • 1: low importance
    • 2: medium importance
    • 3: high importance
    • 4: decisive
  • ruleSetting , indicates the configuration type of the rule:
    • D: dynamic in the transaction
    • S: static in the merchant profile
    • I: static and imposed by the distributor offer
    • N: no configuration (when the rule cannot be configured)
  • ruleResultIndicator , the execution result of the rule:
    • N: negative result
    • P: positive result
    • O: neutral result
    • U: rule not executed due to an incomplete transaction (e.g. data not filled in)
    • X: rule not applicable to this kind of transaction
    • B: rule not executed because bypassed by the merchant
    • E: rule not executed due to a technical error
    • D: rule not executed due to a dynamic override 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 WL Sips connectors (Checkout, CashManagement (duplication) and Diagnosis services)
  • the MEX
  • the transactions report except the scoreInfo and preAuthorisationRuleResultList fields.
Field Description
Green / white result
responseCode Value set according to the authorisation response
acquirerResponseCode Value set according to the authorisation response
scoreColor WHITE/GREEN
scoreValue Value of the overall score
scoreProfile Name of the antifraud profile executed
preAuthorisationProfileValue Unique identifier of the antifraud profile executed
scoreThreshold Thresholds set for this profile
scoreInfo Value set according to the rules executed
transactionStatus Value set according to the authorisation response and capture mode
preAuthorisationRuleResultList A list of detailed result for each rule executed
Orange result
responseCode Value set according to the authorisation response
acquirerResponseCode Value set according to the authorisation response
scoreColor ORANGE
scoreValue Value of the overall score
scoreProfile Name of the antifraud profile executed
preAuthorisationProfileValue Unique identifier of the antifraud profile executed
scoreThreshold Thresholds set for this profile
scoreInfo Value set according to the rules executed
transactionStatus Value set according to the authorisation response and the merchant's challenge option
preAuthorisationRuleResultList A list of detailed result for each rule executed
Red / black result
responseCode Value set to 05
acquirerReponseCode Not specified
scoreColor BLACK/RED
scoreValue Value of the overall score
scoreProfile Name of the antifraud profile executed
preAuthorisationProfileValue Unique identifier of the antifraud profile executed
scoreThreshold Thresholds set for this profile
scoreInfo Value set according to the rules executed
TransactionStatus REFUSED
preAuthorisationRuleResultList A list of detailed result for each rule executed

Pre-authentication mode

The result of the execution of the pre-authentication profile is returned in the fields below:

  • preAuthenticationColor , rule results represented in the form of a colour
  • preAuthenticationValue , value of the overall score
  • preAuthenticationThreshold , thresholds set for this profile
  • preAuthenticationInfo , breakdown of the executed rules
  • preAuthenticationProfile , the name of the antifraud profile executed before the authentication
  • 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 checks were performed.
  • preAuthenticationRuleResultList , a list of detailed result of each rule executed before the authentication.

Each object contained in the preAuthenticationRuleResultList field corresponds to a rule result and contains the same values as the preAuthorisationRuleResultList field in pre-authorisation mode. For the content, please refer to the pre-authorisation mode .

You are returned these fields in the following interfaces:

  • automatic and manual responses from Sips Paypage
  • response from the Sips Office connectors (services Checkout, CashManagement (duplication) et diagnosis services)
  • the MEX
  • the transactions report except the preAuthenticationInfo and preAuthenticationRuleResultList fields.
Field Description
Green / white result
preAuthenticationColor WHITE/GREEN
preAuthenticationValue Value of the overall score
preAuthenticationThreshold Thresholds set for this profile
preAuthenticationInfo Breakdown of the rules executed
preAuthenticationProfile Name of the antifraud profile executed
preAuthenticationProfileValue Unique identifier of the antifraud profile executed
preAuthenticationRuleResultList A list of detailed result for each rule executed
Orange / red / black result
preAuthenticationColor BLACK/RED/ORANGE
preAuthenticationValue Value of the overall score
preAuthenticationThreshold Thresholds set for this profile
preAuthenticationInfo Breakdown of the rules executed
preAuthenticationProfile Name of the antifraud profile executed
preAuthenticationProfileValue Unique identifier of the antifraud profile executed
preAuthenticationRuleResultList A list of detailed result for each rule executed

Limitations of use

Means of payment

The overall WL Sips offering supports many international means of payment such as Visa/Mastercard cards, the Paypal digital wallet, iDeal transfers, Sepa Direct Debits, etc.

The rules do not necessarily apply to all means of payment (e.g. InfoScore rules only apply to ELV transactions).

For single message** means of payment, means of payment, defining informational profiles is technically feasible, but the result of the check will have no consequences on the acceptance of the transaction.

To know if an antifraud rule is applicable to a means of payment, please refer to the following section: 'Correspondences between means of payment and antifraud rules' .

____________________

** “Single-message” refers to a means of payment for which the authorisation and capture are performed in a single step e.g. transfers with Ideal, Sofort, Paybutton, or Paypal in immediate mode. Dual-message refers to a means of payment for which 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

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

Description and implementation of rules

Geolocation rules: address and country

Note: the lists mentioned in the geolocation rules below are limited to 400 items, i.e. 400 countries or 400 country pairs (depending on the rule concerned).

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
Attention: in advanced configuration mode, you can set two lists, one of them having a positive influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list. A same country can be found only in either list.
IMPORTANT: information about American Express cards

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

Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CR;N;NOT_APPLICABLE NOT_APPLICABLE
The card country is unknown. 0 CR;N;
CARD_COUNTRY=XXX*
CARD_COUNTRY=XXX*
The card country is on the list of prohibited countries, is not on the list of authorised countries, or is the same as the merchant's country. 0 to -4 depending on settings
The card country is on the list of authorised countries, is not on the list of prohibited countries, or differs from the merchant's country. 0

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

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CR;N;NOT_APPLICABLE NOT_APPLICABLE
The card country is unknown. 0 CR;N;
CARD_COUNTRY=XXX*
CARD_COUNTRY=XXX*
The card country is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings
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 not on the list of “non-advantaged countries”. 0
The card country is on the list of “advantaged countries” or is not on the list of “non-advantaged countries” or is the same as the merchant's country. 0 to +4 depending on settings

* 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
Attention: in advanced configuration mode, you can set two lists, one of them having a positive influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list. A same country can be found only in either list.

Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
The IP address country is unknown. 0 CY;N;IP_COUNTRY=XXX IP_COUNTRY=XXX
The IP address country is on the list of prohibited countries or is not on the list of authorised countries. 0 to -4 depending on settings CY;N;IP_COUNTRY=XXX* IP_COUNTRY=XXX*
The IP address country is on the list of authorised countries or is not on the list of prohibited countries. 0

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

Advanced configuration mode:

Use case ScoreValue Scoreinfo RuleDetailedInfo
The IP address country is unknown. 0 CY;N;IP_COUNTRY=XXX IP_COUNTRY=XXX
The IP address country is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings CY;N;IP_COUNTRY=XXX* 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 not on the list of “non-advantaged countries”. 0
The IP address country is on the list of “ advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

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

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

Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 SI;N;NOT_APPLICABLE NOT_APPLICABLE
The card country and/or IP address country is/are unknown. 0 SI;N;
CARD_COUNTRY=XXX;
IP_COUNTRY=YYY*
CARD_COUNTRY=XXX* ; IP_COUNTRY=YYY*
The “card country/IP address country” combination is prohibited. 0 to -4 depending on settings
The “card country/IP address country” combination is authorised. 0

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

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 SI;N;NOT_APPLICABLE NOT_APPLICABLE
The card country and/or IP address country is/are unknown. 0 SI;N;
CARD_COUNTRY=XXX;
IP_COUNTRY=YYY*
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”. 0 to -4 depending on settings
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”. 0
The “card country/IP address country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

* 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 ScoreValue ScoreInfo RuleDetailedInfo
The delivery country does not match the billing country. 0 to -4 depending on settings SB;N;
SHIP_COUNTRY=XXX*;
BILL_COUNTRY=YYY*
SHIP_COUNTRY=XXX*; BILL_COUNTRY=YYY*
The delivery country matches the billing country. 0
The countries are unknown. 0

* 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 ScoreValue ScoreInfo RuleDetailedInfo
The delivery postal code does not match the billing postal code. 0 à -4 selon paramétrage ZC;N;
SHIP_COUNTRY=XXX;
BILL_COUNTRY=YYY;
SHIP_ZIP=A;
BILL_ZIP=B*
SHIP_COUNTRY=XXX*; BILL_COUNTRY=YYY*;
SHIP_ZIP=A*;
BILL_ZIP=B*
The delivery postal code matches the billing postal code. 0
The postal codes are unknown. 0

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

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

Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CS;N;NOT_APPLICABLE NOT_APPLICABLE
The “Card country/Delivery country” combination is prohibited. 0 to -4 depending on settings CS;N;
SHIP_COUNTRY=XXX*;
CARD_COUNTRY=YYY*
SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The “Card country/Delivery country” combination is authorised. 0
The card country or delivery country are unknown. 0

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

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CS;N;NOT_APPLICABLE NOT_APPLICABLE
The “card country/ delivery country” combination is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries” 0 to -4 depending on settings CS;N;
SHIP_COUNTRY=XXX*;
CARD_COUNTRY=YYY*
SHIP_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The “card country/ delivery 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” 0
The card country or delivery country are unknown. 0
The “card country/ card country/ delivery country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries” 0 to +4 depending on settings

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

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

Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CS;N;NOT_APPLICABLE NOT_APPLICABLE
The “Card country/Billing country” combination is prohibited. 0 to -4 depending on settings CS;N;
BILL_COUNTRY=XXX*;
CARD_COUNTRY=YYY*
BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The “Card country/Billing country” combination is authorised. 0
The card country or billing country are unknown. 0

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

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CS;N;NOT_APPLICABLE NOT_APPLICABLE
The “card country/ billing country” combination is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings CS;N;
BILL_COUNTRY=XXX*;
CARD_COUNTRY=YYY*
BILL_COUNTRY=XXX*; CARD_COUNTRY=YYY*
The “card country/ billing 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”. 0
The card country or billing country are unknown. 0
The “card country/ billing country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

* 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
Attention: in advanced configuration mode, you can set two lists, one of them having a positive influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list. A same country can be found only in either list.

Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 AC;N;NOT_APPLICABLE NOT_APPLICABLE
The IBAN country is in the list of prohibited countries or is not on the list of authorised countries or is different from your country. 0 to -4 depending on settings AC;N;
IBAN_COUNTRY=XXX*
IBAN_COUNTRY=XXX*
The IBAN country is on the list of authorised countries or is not on the list of prohibited countries or is equivalent to your country. 0

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

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 AC;N;NOT_APPLICABLE NOT_APPLICABLE
The IBAN country is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings AC;N;
IBAN_COUNTRY=XXX*
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 not on the list of “non-advantaged countries”. 0
The IBAN country is on the list of “advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

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

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

Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 DI;N;NOT_APPLICABLE NOT_APPLICABLE
The delivery country and IBAN country combination is prohibited. 0 to -4 depending on settings DI;N;
SHIP_COUNTRY=XXX*;
IBAN_COUNTRY=YYY*
SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The delivery country and/or IBAN country is/are unknown. 0
Delivery country and IBAN country combination is authorised. 0

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

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 DI;N;NOT_APPLICABLE NOT_APPLICABLE
The “delivery country / IBAN country” combination is on the list of “disadvantaged countries” or is not on the list of “non-disadvantaged countries”. 0 to -4 depending on settings DI;N;
SHIP_COUNTRY=XXX*;
IBAN_COUNTRY=YYY*
SHIP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The delivery country and/or the IBAN country is/are unknown. 0
The “delivery 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”. 0
The “delivery country / IBAN country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

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

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

Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 PI;N;NOT_APPLICABLE NOT_APPLICABLE
The customer's mobile phone number country and IBAN country combination is prohibited. 0 to -4 depending on settings PI;N;
PHONE_COUNTRY=XXX*;
IBAN_COUNTRY=YYY*
PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The customer's mobile phone number country and/or IBAN country is/are unknown. 0
The customer's mobile phone number country and IBAN country combination is authorised. 0

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

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 PI;N;NOT_APPLICABLE 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”. 0 to -4 depending on settings PI;N;
PHONE_COUNTRY=XXX*;
IBAN_COUNTRY=YYY*
PHONE_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The customer's mobile phone number country and/or IBAN country is/are unknown. 0
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”. 0
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”. 0 to +4 depending on settings

* 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

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

Expression of the result

Simple configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 IS;N;NOT_APPLICABLE NOT_APPLICABLE
The IP address country and IBAN country combination is prohibited. 0 to -4 depending on settings IS;N;
IP_COUNTRY=XXX*;
IBAN_COUNTRY=YYY*
IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The IP address country and/or IBAN country is/are unknown. 0
The IP address country and IBAN country combination is authorised. 0

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

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 IS;N;NOT_APPLICABLE 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”. 0 to -4 depending on settings IS;N;
IP_COUNTRY=XXX*;
IBAN_COUNTRY=YYY*
IP_COUNTRY=XXX*; IBAN_COUNTRY=YYY*
The IP address country and/or IBAN country is/are unknown. 0
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”. 0
The “IP address country / IBAN country” combination is on the list of “advantaged countries” or is not on the list of “non-advantaged countries”. 0 to +4 depending on settings

* 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.
Tip: when setting up a profile, you can take into account the refused transactions (in addition to the accepted transactions) in the calculations.

To set up a shared velocity, you need to contact your account manager for the configuration. Two steps are to be followed:

  • first, create a shared velocity by choosing its type (card velocity, IP address velocity, etc.)
  • then associate the shared velocity to the concerned webshops

During the execution of an antifraud control, when the shared velocity rule is active in the applied merchant profile, activities will be caculated and added to the activities of other webshops sharing the same velocity.

5 shared velocities can be set up per type of velocity rule in a commercial group.

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: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum cumulative amount 0.01 over the period, in your currency 9999999
Period In hours: 1 hour
In days: 1 day
In weeks: 1 week
In hours: 720 hours
In days: 30 days
In weeks: 4 weeks
Maximum number of transactions 1 transaction over the period 9999

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 SC;N;NOT_APPLICABLE 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). 0 to -4 depending on settings SC;N;TRANS=A:B;
CUMUL=C:D*
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.. 0

*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 the cumulative amounts with this card over the period

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

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 MEX
  • set the number of transactions carried out and/or the cumulative amount and the cumulation time through the fraud tab in the MEX
  • and provide the customer's IP address in the request ( customerIpAddress field), if you use Sips Office

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

Expression of the result

Use case ScoreValue ScoreInfo 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). 0 to -4 depending on settings VI;N;TRANS=A:B;
CUMUL=C:D*
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. 0 TRANS=A:B;
CUMUL=C:D*
The IP address is not specified (in Sips Office ) 0

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

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

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

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

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

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
The customer Id is not supplied. 0 VC;N;TRANS=A:B;
CUMUL=C:D*
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). 0 to -4 depending on settings 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. 0

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

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

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

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

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

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 MD;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different customers using the same card over the period is equal to or exceeds the authorised limit. 0 to -4 depending on settings MD;N;MAX=A:B* MAX=A:B*
The number of different customers using the same card over the period is lower than the authorised limit. 0
The customer ID is not specified. 0

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

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

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

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 MR;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different cards used by a given customer over the period is equal to or exceeds the authorised limit. 0 to -4 depending on settings MR;N;MAX=A:B* MAX=A:B*
The number of different cards used by a given customer over the period is lower than the authorised limit. 0
The customer ID is not supplied. 0

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

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

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 MEX
  • set the maximum number of cards and the cumulation time through the fraud tab in the MEX
  • and provide the customer's IP address in the request ( customerIpAddress field), if you use Sips Office

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CI;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different cards used from a given IP address over the period is equal to or exceeds the authorised limit. 0 to -4 depending on settings CI;N;MAX=A:B* MAX=A:B*
The number of different cards used from a given IP address over the period is lower than the authorised limit. 0
The IP address is not specified (in Sips Office ). 0

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

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

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 MEX
  • set the maximum number of IBANs and the cumulation time through the fraud tab in the MEX
  • and provide the customer's IP address in the request ( customerIpAddress field), if you use

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 II;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different IBANs coming from the same IP address over the period exceeds the accepted limit. 0 to -4 depending on settings II;N;MAX=A:B* MAX=A:B*
The IP address is not specified (in Sips Office ). 0
The number of different IBANs coming from the same IP address over the period is under the accepted limit. 0

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

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 MEX
  • set the maximum number of IP addresses and the cumulation time through the fraud tab in the MEX
  • and provide the customer's IP address in the request ( customerIpAddress field), if you use Sips Office

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 IJ;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different IP addresses with the same IBAN over the period exceeds the accepted limit. 0 to -4 depending on settings IJ;N;MAX=A:B* MAX=A:B*
The IP address is not specified (in Sips Office ). 0
The number of different IP addresses with the same IBAN over the period is lower than the accepted limit. 0

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

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

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

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 CJ;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different customers using the same IBAN over the period exceeds the accepted limit. 0 to -4 depending on settings CJ;N;MAX=A:B* MAX=A:B*
The customer ID is not supplied. 0
The number of different customers using the same IBAN over the period is under the accepted limit. 0

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

B: the maximum number of customers accepted for a given IBAN.

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

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 IC;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different IBANs used by the same customer over the period exceeds the accepted limit. 0 to -4 depending on settings IC;N;MAX=A:B* MAX=A:B*
The customer ID is not specified. 0
The number of different IBANs used by the same customer over the period is under the accepted limit. 0

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

B: the maximum number of IBANs accepted for a given customer.

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 MEX
  • set the maximum number of mandates and the cumulation time through the fraud tab in the MEX
  • and provide the customer's IP address in the request ( customerIpAddress field), if you use Sips Office

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 MJ;N;NOT_APPLICABLE NOT_APPLICABLE
The number of different mandates coming from the same IP address over the period exceeds the accepted limit. 0 to -4 depending on settings MJ;N;MAX=A:B* MAX=A:B*
The IP address is not specified. 0
The number of different mandates coming from the same IP address over the period is under the accepted limit. 0

*A: the number of mandates on the given IBAN over the period.

B: the maximum number of mandates accepted for a given IBAN.

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

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 EM;N;NOT_APPLICABLE 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). 0 to -4 depending on settings EM;N;TRANS=A:B;
CUMUL=C:D*
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. 0

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

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

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

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

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

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not SDD). 0 EI;N;NOT_APPLICABLE 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). 0 to -4 depending on settings EI;N;TRANS=A:B;
CUMUL=C:D*
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. 0

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

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

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

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

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 MEX
  • set the list of unwanted IP address reputations through the fraud tab in the MEX
  • and send the customer's IP address in the request ( customerIpAddress field), if you use Sips Office .

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
The information is unknown. 0 IR;N;U;IP_REP=XXX* IP_REP=XXX*
The IP address reputation is on the list of unwanted IP address reputations. 0 to -4 depending on settings IR;N;Y;IP_REP=XXX*
The IP address reputation is not on the list of unwanted IP address reputations. 0 IR;N;N;IP_REP=XXX*

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

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 OP;N;NOT_APPLICABLE NOT_APPLICABLE
The oppotota server could not be accessed. 0 OP;N;U --
The card is blocked. 0 à -4 selon paramétrage OP;N;Y
The card is not blocked. 0 OP;N;N

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 EC;N;NOT_APPLICABLE NOT_APPLICABLE
The information is unknown. 0 EC;N;U --
The card is a dynamic virtual card. 0 to -4 depending on settings EC;N;Y
The card is not a dynamic virtual card. 0 EC;N;N

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 SA;N;NOT_APPLICABLE NOT_APPLICABLE
The information is unknown. 0 SA;N;U --
The card is a systematic authorisation card. 0 to -4 depending on settings SA;N;Y
The card is not a systematic authorisation card. 0 SA;N;N

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 CC;N;NOT_APPLICABLE NOT_APPLICABLE
The information is unknown. 0 CC;N;U;
CARD_COUNTRY=XXX
CARD_COUNTRY=XXX*
The card is a commercial card, and the list of authorised/prohibited commercial card countries has not been defined. 0 à -4 selon paramétrage CC;N;Y;
CARD_COUNTRY=XXX*
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. 0 à -4 selon paramétrage CC;N;Y;
CARD_COUNTRY=XXX*
The card country is not on the list of prohibited commercial card countries or is on the list of authorised commercial card countries. 0 CC;N;N;
CARD_COUNTRY=XXX*
The card is not a commercial card. 0 CC;N;N;
CARD_COUNTRY=XXX*

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

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

Parameter Minimum value Maximum value
Minimum value 0.01 in your currency 9999999
Maximum value 0.01 in your currency 9999999
Attention: in advanced configuration mode, you can set two amount ranges, one of them having a positive influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative amount range.

Expression of the result

Default mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
The transaction amount does not lie within the range of required amounts. 0 to -4 depending on settings CA;N;MIN=A:B;MAX=A:C* MIN=A:B;MAX=A:C*
The transaction amount lies within the range of required amounts. 0 CA;N;MIN=A:B;MAX=A:C*

Advanced configuration mode:

Use case ScoreValue ScoreInfo RuleDetailedInfo
The transaction amount lies within the range of disadvantaged amounts. 0 to -4 depending on settings CA;N;NEGATIVE_MIN=A:B;
NEGATIVE_MAX= A:C;
POSITIVE_MIN= A:D;
POSITIVE_MAX=A:E*
NEGATIVE_MIN=A:B;
NEGATIVE_MAX=A:C;
POSITIVE_MIN=A:D;
POSITIVE_MAX=A:E
The transaction amount does not lie within the ranges of advantaged and disadvantaged amounts. 0 CA;N;NEGATIVE_MIN=A:B;
NEGATIVE_MAX=A:C;
POSITIVE_MIN=A:D;
POSITIVE_MAX=A:E*
The transaction amount lies within the range of advantaged amounts. 0 to +4 depending on settings CA;N;NEGATIVE_MIN=A:B;
NEGATIVE_MAX=A:C;
POSITIVE_MIN=A:D;
POSITIVE_MAX=A:E*

__________

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 NC;N;NOT_APPLICABLE NOT_APPLICABLE
The card BIN is unknown. 0 NC;N;U --
The card is not part of the CB network. 0 to -4 depending on settings NC;N;Y
The card is part of the CB network. 0 NC;N;N

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
At least one of the e-mail addresses is on the list of free e-mail addresses. 0 to -4 depending on settings FE;N;Y --
None of the e-mail addresses are on the list of free e-mail addresses. 0 FE;N;U
No e-mail addresses were sent. 0 FE;N;N

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

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

Attention: in advanced configuration mode, you can set two lists, one of them having a positive influence and the other one a negative influence, as opposed to the simple configuration mode where there is a single negative list.

Expression of the result

Default mode (simple configuration):

Use case ScoreValue ScoreInfo 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). 0 A3;N;NOT_APPLICABLE NOT_APPLICABLE
The 3-D Secure status is prohibited. 0 to -4 depending on settings A3;N;Y --
The 3-D Secure status is not prohibited. 0 A3;N;N

Advanced configuration mode:

Use case ScoreValue ScoreInfo 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). 0 A3;N;NOT_APPLICABLE NOT_APPLICABLE
The 3-D Secure status is on the list of “disadvantaged statuses”. 0 to -4 depending on settings A3;N;Y --
The 3-D Secure status is not on the lists of “disadvantaged statuses” and “advantaged statuses”. 0 A3;N;N
The 3-D Secure status is on the list of “advantaged statuses”. 0 to +4 depending on settings A3;N;Y

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
The e-mail address is incorrectly formatted. 0 to -4 depending on settings ES;N --
The e-mail address is correctly formatted. 0
No e-mail addresses were sent. 0

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 MEX
  • set the list of authorised/prohibited indicators through the fraud tab in the MEX

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

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the InfoScore ID is missing), or the delivery address is not located in Germany). 0 AV;N;NOT_APPLICABLE NOT_APPLICABLE
The information is unknown. 0 AV;N;U;IS_INDIC=XXX* 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. 0 to -4 depending on settings AV;N;Y;IS_INDIC=XXX* 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. 0 AV;N;N;IS_INDIC=XXX*

* XXX: indicator returned by InfoScore.

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 MEX
  • and set the list of authorised/prohibited indicators through the fraud tab in the MEX

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the InfoScore ID is missing) 0 BV;N;NOT_APPLICABLE NOT_APPLICABLE
The information is unknown. 0 BV;N;U;VALID=AAA;BBB;
NCA_INFO=CCC;DDD;
PAP_INFO=EEE;FFF*
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. 0 to -4 depending on settings BV;N;Y;VALID=AAA;BBB;
NCA_INFO=CCC;DDD;
PAP_INFO=EEE;FFF*
VALID=AAA;BBB;
NCA_INFO=CCC;DDD;
PAP_INFO=EEE;FFF*
The account is a consumer account. 0 BV;N;N;VALID=AAA;BBB;
NCA_INFO=CCC;DDD;
PAP_INFO=EEE;FFF*

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

BBB: value of the InfoScore NCA indicator.

CCC: value of RppContentCode for InfoScore NCA KO.

DDD: value of the InfoScore PAP indicator.

EEE: value of RppContentCode for InfoScore PAP KO.

FFF: value of the InfoScore RPP indicator.

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 MEX
  • and set the minimum number of months before the card expires through the fraud tab in the MEX

Expression of the result

Use case ScoreValue ScoreInfo RuleDetailedInfo
This rule cannot be executed (the means of payment is not a card). 0 PE;N;NOT_APPLICABLE NOT_APPLICABLE
The validity time of the means of payment is shorter than the required duration. 0 to -4 depending on settings PE;N;Y;EXPIRY=AAA:BBB* EXPIRY=AAA:BBB*
The validity time of the means of payment is longer than the required duration. 0 PE;N;N;EXPIRY=AAA:BBB*

* AAA: card expiry date in MMYY format.

BBB : deadline of the check in MMYY format.

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 the list is managed:

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

Therefor, the possible results according to the type of rule are shown in the table below:

Data item is present Blacklist result
(NEGATIVE type)
Greylist result
(NEGATIVE type)
Whitelist result
(POSITIVE type)
NO Neutral Neutral Neutral
YES Negative Negative 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.

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

Shared lists

By default, a webshop has its own list for each list-type rule. It is called a private list. It is also possible to share a list among several webshops. A list is shared in the same commercial group. 5 shared lists can be created for a type of list. All the webshops attached on a shared list can modify the elements in the list. The element added by a webshop can only be modified or deleted by a user of this webshop or an administrator, but not by another webshop. The elements in the lists are used for all these webshops.

To set up a shared list, you need to contact your account manager for the configuration. This is done in two steps:

  • First, create a shared list by combining its type (e-mail address list, card number list, etc.) and its color (black, grey or white)
  • then associate the shared list to the webshops

During the execution of the antifraud control, when the list-type rule is active in the applied merchant profile, the shared list will be used instead of the default private list.

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 MEX
  • set the e-mail address black, grey and/or white list(s)

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

Expression of the result

Use case ScoreValue ScoreInfo Rule DetailedInfo
At least one e-mail address is on the list. Black 0 to -4 depending on settings BM;N;Y --
Grey GM;N;Y
White 0 to +4 depending on settings WM;P;Y
None of the e-mail addresses are on the list. Black 0 BM;N;N
Grey GM;N;N
White WM;P;N
No e-mail addresses were sent. Black BM;N;U
Grey GM;N;N
White WM;P;U

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 MEX ,
  • set the IP address black, grey and/or white list(s)

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

Expression of the result

Use case ScoreValue ScoreInfo Rule DetailedInfo
The IP address is not specified (in Sips Office ) Black 0 BY;N;U --
Grey GY;N;U
White WY;P;U
The IP address is on the list. Black 0 to -4 depending on settings BY;N;Y
Grey GY;N;Y
White 0 to +4 depending on settings WY;P;Y
The IP address is not on the list. Black 0 BY;N;N
Grey GY;N;N
White WY;P;N

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 MEX
  • 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 ScoreValue ScoreInfo Rule DetailedInfo
No postal codes were sent. Black 0 BZ;N;U --
Grey GZ;N;U
White WZ;P;U
At least one postal code is on the list. Black 0 to -4 depending on settings BZ;N;Y
Grey GZ;N;Y
White 0 to +4 depending on settings WZ;P;Y
None of the postal codes are on the list. Black 0 BZ;N;N
Grey GZ;N;N
White WZ;P;N

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 MEX
  • 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 ScoreValue ScoreInfo Rule DetailedInfo
The customer ID is not supplied. White 0 BI;N;U --
Grey GI;N;U
White WI;P;U
At least one customer ID is on the list. Black 0 to -4 depending on settings BI;N;Y
Grey GI;N;Y
White 0 to +4 depending on settings WI;P;Y
The customer ID is not on the list. Black 0 BI;N;N
Grey GI;N;N
White WI;P;N

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 MEX
  • 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 ScoreValue ScoreInfo Rule DetailedInfo
No customer names were sent. Black 0 BN;N;U --
Grey GN;N;U
White WN;P;U
At least one customer name is on the blacklist. Black 0 to -4 depending on settings BN;N;Y
Grey GN;N;Y
White 0 to +4 depending on settings WN;P;Y
None of the customer names are on the blacklist. Black 0 BN;N;N
Grey GN;N;N
White WN;P;N

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

Cas d'utilisation ScoreValue ScoreInfo Rule DetailedInfo
This rule cannot be executed (the means of payment is not a card). Noire 0 BC;N;U --
Grise GC;N;U
Blanche WC;P;U
The card number is on the list. Noire 0 to -4 depending on settings BC;N;Y
Grise GC;N;Y
Blanche 0 to +4 depending on settings WC;P;Y
The card number is not on the list. Noire 0 BC;N;N
Grise GC;N;N
Blanche WC;P;N

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 MEX
  • 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 ScoreValue ScoreInfo Rule DetailedInfo
No phone numbers were sent. Black 0 BP;N;U --
Grey GP;N;U
White WP;P;U
At least one phone number is on the list. Black 0 to -4 depending on settings BP;N;Y
Grey GP;N;Y
White 0 to +4 depending on settings WP;P;Y
None of the phone numbers are on the list. Black 0 BP;N;N
Grey GP;N;N
White WP;P;N

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 MEX
  • and set the BIN number black, grey and/or white list(s) ( cardNumber )

Note: please read the glossary for more information on BINs.

Expression of the result

Use case ScoreValue ScoreInfo Rule DetailedInfo
This rule cannot be executed (the means of payment is not a card). Black 0 BB;N;U --
Grey BR;N;U
White WB;P;U
The card BIN is on the list. Black 0 to -4 depending on settings BB;N;Y
Grey BR;N;Y
White 0 to +4 depending on settings WB;P;Y
The card BIN is not on the list. Black 0 BB;N;N
Grey BR;N;N
White WB;P;N

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.

Tip: you can send the BIC in the request. Alternatively, it will automatically be found from the IBAN that you must send.

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 MEX
  • and set the BIC black, grey and/or white list(s)

Expression of the result

Use case ScoreValue ScoreInfo Rule DetailedInfo
The BIC is on the list. Black 0 to -4 depending on settings BE;N;Y --
Grey GM;N;Y
White 0 to +4 depending on settings WE;P;Y
The BIC is not on the list. Black 0 BE;N;N
Grey GM;N;N
White WE;P;N

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 MEX
  • and set the IBAN black, grey and/or white list(s)

Expression of the result

Use case ScoreValue ScoreInfo Rule DetailedInfo
The IBAN is on the list. Black 0 to -4 depending on settings BA;N;Y --
Grey GA;N;Y
White 0 to +4 depending on settings WA;P;Y
The IBAN is not on the list. Black 0 BA;N;N
Grey GA;N;N
White WA;P;N

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 MEX
  • and set the mandate black, grey and/or white list(s)

Expression of the result

Use case ScoreValue ScoreInfo Rule DetailedInfo
The UMR of the mandate is on the list. Black 0 to -4 depending on settings TB;N;Y --
Grey TG;N;Y
White 0 to +4 depending on settings TW;P;Y
The UMR of the mandate is not on the list. Black 0 TB;N;N
Grey TG;N;N
White TW;P;N

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.

IMPORTANT: the products are identified by the anti-fraud engine based on their product codes, which should be present both on the risky product list and in the transaction basket data. Concordance between the codes for these lists and for the basket is essential.

Shared lists

By default, a webshop has its own risky product lists (3 lists only). These lists are also called "private lists".

It is also possible to create lists shared by several webshops in order to manage a single set of risky products for the webshops in question. These are known as "shared lists".

A list can be shared at the commercial group level. 5 shared lists of risky products can be created then associated with the webshops. All the webshops associated with a given shared list can edit the items on the list. The items on the list are used for all the webshops that share it.

To set up a shared list, you should contact your account manager for configuration. This is done in two phases:

  • first create a shared list by selecting the type (e-mail address list, card number list, etc.) and colour (black, white or grey)
  • then link the shared list to the webshops

Webshops are linked to the shared list by using an existing shared list at the commercial group level in the setup screen for webshop product lists.

When the anti-fraud measures are executed, if the appropriate rule has been activated and it is configured to use the shared list, then the list will be used.

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.

Attention: this rule cannot be decisive, so that it does not block all the transactions of a webshop. The products included in the risky product list must be products you sell. This also applies to the products in the basket.

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 MEX
  • set at least one risky product list via the fraud tab in the MEX

  • 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 ScoreValue ScoreInfo Rule DetailedInfo
At least one product in the basket is on a risky product list. 0 to -3 depending on settings RP;N;Y --
Information unknown. 0 RP;N;U;
No products in the basket are on a risky product list. 0 RP;N;N

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 MEX
  • set at least one risky product list via the fraud tab in the MEX

  • 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 ScoreValue ScoreInfo 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.
0 to -4 depending on settings PQ;N;Y;
MAX_QUANTITY_PER_
RISKY_PRODUCT=L:A:B;
MAX_QUANTITY_PER_
LIST=L:C:D*
MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B;
MAX_QUANTITY_PER_
LIST=L:C:D*
Information unknown 0 PQ;N;U --
No products in the basket are on a risky product list
or
No products in the basket included on a risky product list have a greater higher than the limit configured in the rule.
0 PQ;N;N;
MAX_QUANTITY_PER_
RISKY_PRODUCT=L:A:B;
MAX_QUANTITY_PER_
LIST=L:C:D*
MAX_QUANTITY _PER_RISKY _PRODUCT=L:A:B;
MAX_QUANTITY _PER_LIST=L:C:D*

*L: concerned risky product list name.

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

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

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

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

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

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

Dynamic override

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 MEX
  • set at least one risky product list via the fraud tab in the MEX

  • 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 ScoreValue ScoreInfo 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.
0 to -4 depending on settings PQ;N;Y;
MAX_RATIO_PER_
RISKY_PRODUCT=L:A:B;
MAX_RATIO_PER_
LIST=L:C:D*
MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*
Information unknown 0 PQ;N;U --
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.
0 PQ;N;N;
MAX_RATIO_PER_
RISKY_PRODUCT=L:A:B;
MAX_RATIO_PER_
LIST=L:C:D*
MAX_RATIO _PER_RISKY _PRODUCT=L:A:B; MAX_RATIO _PER_LIST=L:C:D*

*L: concerned risky product list name.

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

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

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

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

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

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

Dynamic override

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 MEX
  • 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 ScoreValue ScoreInfo RuleDetailedInfo
At least one product in the basket is in a quantity greater than the limit configured in the rule. 0 to -4 depending on settings QP;N;Y;
PRODUCTQUANTITY=A:B*
PRODUCTQUANTITY =A:B*
Information unknown. 0 QP;N;U;
PRODUCTQUANTITY=XXX:B*
PRODUCTQUANTITY =XXX:B*
No product in the basket is in a quantity greater than the limit configured in the rule. 0 QP;N;N;
PRODUCTQUANTITY=A:B*
PRODUCTQUANTITY =A:B*

* A: quantity of the first product found which quantity 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 MEX

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.

Attention: if a message indicates access rights issues, contact the support team to have the fraud risk management option activated on your webshop.

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.

Note: when a shop is selected, this part is automatically collapsed.

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.

Tip: at various places in the interface, you will be able to click on  buttons that will give you access to detailed information about the elements located next to them.
Attention: rights management

The actions you can take depend on the role(s) assigned to your MEX 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:

The Live status column shows whether the profile is active or not.
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.
Tip: active default profile

For the distributor's profile not to be used, it is preferable to always have an active default profile.

The Draft status column shows whether the profile is active or not:
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.
Attention: working version and published version

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.

A profile must therefore be both active and published in order to be applied. An active profile with a status "To be republished" status will not apply.

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:

  • Business Score profile

    If this option is authorised by the distributor, select Business Score profile in the list of the Create profile menu button. You will then access the page for creating a new profile.

or

  • Select Copy from previous to create a new profile from an existing profile on the webshop. A new window will pop-up, allowing you to choose the profile to be copied.

    Once you have chosen the profile to be copied, you will be taken to the profile creation page.

or

  • From a profile template

    As is the case when you copy an existing profile, a pop-up window will let you select a profile from a list of available standard profiles, which will be used as the basis for the new one.

You will then reach 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.

  • Thresholds:

    You can configure the size of the red, orange and green areas using the two threshold cursors. Threshold values are displayed under these cursors.

    The latter’s colours act as a reminder of the colour of risk evaluation if the calculated score reaches the value of the threshold. In the example above, a score of -1 will give the green colour and a score of -2 the orange colour.

    The lower (min) and upper (max) bounds of the score are recalculated dynamically according to the changes made to the activation and weights of rules. For instance, activating a rule with a weight of -3 will adjust the value of the lower bound by -3. Activating a rule with a weight of +2 will adjust the value of the upper bound by +2.

    If a threshold value falls outside of the recalculated limits after a change has been made to the rules, this value is automatically adjusted to the closer bound, and an alert message is displayed:

    For instance, if the orange threshold is set to -15, and the lower bound becomes -10 after a change has been made to the rules, the value of the orange threshold will automatically be adjusted to -10.

    Note: verifying thresholds after rule changes

    When a rule is activated or deactivated, or when its importance is modified, the maximum and minimum values of the score change accordingly. Therefore, once changes have been made to the rules, it is necessary to review the thresholds that define the red, orange and green areas to adjust the proportions if need be.

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

    Note: default profiles

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

    Note: only one profile for a given means of payment

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

    Note: warning

    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 whose amounts 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 your rules section in the profile creation page enables you to choose the rules that must be applied as part of the profile. See 'Administering rules in profiles' 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 subsection 'Editing and publishing a profile').

The  button maket it possible to cancel the creation of the profile and to go back to the webshop's 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 will appear:

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
    Activate 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's future 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

Activating and configuring a rule

Rules are grouped into categories. Click on the title of a category to expand it and view its rules.

The  icon indicates that the rule is inactive for this profile and thus has no influence over transactions. Click on it to activate the rule.

The  icon indicates that the rule is active for this profile and will thus be used to evaluate transactions when the profile itself is published and active. Click on it to deactivate the rule.

The  icon makes it possible to view the rule details.

A dropdown menu next to each rule makes it possible to specify its importance.

Some rules are configurable. Click on the  icon to display their details (see the next sections for further information about rule configuration).

A rule might not be activable, deactivable or configurable because of the distributor's choices or other constraints.

Ordering decisive rules

If the profile contains several decisive rules, you can specify the order in which they must be executed by clicking on the  icon. The decisive rules you have activated will then appear in a pop-up window :

You can use the  and  icons to reorder the list.

Filtering rules per means of payment

Some rules are related to a means of payment (ex: SDD) or a type of means of payment (ex: card). For instance, the card velocity can only be applied for payment card (CB, Visa, Mastercard) 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. This means you will not be able to activate rules that depend on certain means of payment or types of means of payment if you have not subscribed to them.

When a rule only applies to a means of payment or to a type of means of payment, a label is displayed next to it:

Configuring geolocation rules: addresses and countries

Card country

This section makes it possible to configure the list of 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:

The 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 9: 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 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 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.

If you wish to specify from the outset a list of IP address countries, click on the  button: a popup window appears allowing you to select the desired countries. Once the list has been selected, the words Country list appear in the entry field.

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, 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 combination, 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 may appear on 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 9: 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:
  • Delivery and card country
  • Billing and card country
  • Delivery and IBAN country
  • Phone number and IBAN country
  • IP address and IBAN country
IP and card country
  • IP address country
  • IBAN country
Card country
  • Delivery and billing country
This rule requires no specific configuration.
  • Delivery and billing postal code
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.

Shared velocity

If the distributor's offering supports shared velocity, an icon on the right of the velocity rule name informs whether the velocity is shared with other webshops or is private:

shows that the velocity is shared.

shows that the velocity is private.

Move the cursor over an icon to get more information:

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 address velocity
  • Customer ID velocity
  • Mandate velocity
  • IBAN velocity
Card velocity
  • Number of cards per customer
  • Number of cards per IP address
  • Number of IBANs per IP address
  • Number of IP addresses per IBAN
  • Number of customers per IBAN
  • Number of IBANs per customer
  • Number of mandates per IP address
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:
  • Commercial card (and card country)
Card country
However, please keep in mind that the Commercial card (and card country) rule is not eligible for the advanced configuration mode.
  • Address verification (InfoScore)
3-D Secure authentication
  • Lost and stolen cards (CB scheme cards)
  • Virtual card
  • Systematic authorisation card
  • CB scheme card
  • E-mail address syntax
  • Vérification de compte (InfoScore)
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.

Note: the options using Sips Office SOAP, Sips Office JSON or Sips Office Batch are described in their respective user guides. This guide only exlpains the option using the fraud risk management interface.

Follow the procedure below to populate lists using the MEX :

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 by your browser.

For more details on the CSV file contents, please refer to ' Appendix 9: 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.

Attention: a value can only be on one list. For instance, the same item cannot be added to a greylist and a blacklist.

Shared lists

If the distributor's offering supports shared lists then a webshop can share a list with other webshops belonging to the same commercial group. It is still possible to have a private list used by only one webshop.

  • Configuring the profiles

When you configure a profile, icons to the right of the rule names tell you if the list is shared with other webshops or if it is private:

indicates that the list is shared.

indicates that the list is private.

Move your cursor above an icon to get additional information:

  • The lists themselves

A webshop can share its elements with other webshops belonging to the same commercial group. It is still possible to have a private list only used by one webshop.

You can check, above the form used to add a new item to the list, if a list is private or shared:

indicates that the list is shared.

indicates that the list is private.

When the selected webshop shares a list, the list management is the same as explained in the previous sections of this chapter. The only difference is that a webshop can only remove an item it has added itself before. It is not possible to delete an item added by another webshop.

The webshop that has added the element in the Shop ID column. This column is visible only if the list is shared:

A system of “lock” allows many webshops to add the same item in the list. Each webshop adding an item adds a lock on this item. If at least one lock exists on this item, it is in the list. The item is considered to be out of the list when each lock on the same item is removed by the webshops that have added them.

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

The list can be exported 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.

Lists can also be imported (in .CSV format) using 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 refer to ' Appendix 9: 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

IMPORTANT: the product code is the information used to find products in the basket. It is therefore very important to have concordance of codes between the product lists and the baskets of transactions.

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.

Sharing lists

The management page for shared risky product lists is as follows:

It contains the same functionalities as those presented in the 'Managing risky product lists' section: you can then use the lists created from this page by going to the risky product list management page.

History of actions on the interface

A log of the modifications made through the interface is displayed in the Histor y 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.

Click on the  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: score colours

Values Description
Empty No check.
BLACK Score colour: black.
GREEN Score colour: green.
ORANGE Score colour: orange.
RED Score colour: red.
WHITE Score colour: white.

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:
  • relay spam for illegal trade or information manipulation (e.g. stock exchange rates)
  • carry out phishing operations
  • identify and infect other machines by spreading viruses and malware
  • take part in DDoS attacks
  • abusively generate false clicks on an ad link on a web page
  • capture information on compromised machines (i.e. stealing then reselling information)
  • exploit the calculation power of machines or perform distributed calculation operations, notably to break passwords
  • carry out out illegal trade operations by managing the access to sites that sell prohibited or counterfeit products, through fast-flux, simple or double-flux or RockPhish techniques.
Denial of service A “Denial of service” attack aims to make a service unavailable and prevent legitimate users from using it. It can consist in:
  • flooding a network to prevent it from working
  • disrupting connections between two machines, thus preventing access to a particular service
  • blocking access to a service for a person in particular
  • sending billions of bytes to an Internet set-top box
Phishing For fraudsters, phishing consists in obtaining confidential information (financial information, credentials for logging in to your company's system) through spam based on a fraudulent, malicious copy of a legitimate web page.
Anonymous proxies An anonymous proxy makes it possible to navigate anonymously. In general, it is a server that hides personal information (IP address, OS, browser) from the visited sites.
Scanners Scanners make it possible to know whether several machines have the same IP address because they are part of the same network.
Spam source Generally, it refers to the sending of massive quantities of e-mails for advertising purposes.
Web attacks Web application vulnerabilities can be classified as follows:
  • web server vulnerabilities. These are getting rarer and rarer because web server developers have reinforced security measures through the years
  • URL manipulation. This consists in manually modifying the parameters of URLs to modify the expected behaviour of web servers
  • exploting the weaknesses of session IDs and authentication mechanisms
  • injection of HTML code and Cross-Site Scripting
  • injection of SQL commands
Infected sources IP addresses that send HTTP requests with a low reputation index or that are known malicious sites.
Windows exploits IP addresses that have exploited security holes against Windows resources using browsers, programmes, downloaded files, scripts or operating system vulnerabilities

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