An antifraud rule checks one of the transaction criteria. The controlled criterion can be, for example, the card issuer country, the amounts range, the card number, the IP address, the client id, etc. The rules are sorted by category: geolocation, velocity, velocity, list, basket ans miscellaneous.

For example, the criterion checked can be the card country, the cap collar amounts, the card number, the IP address, the customer ID, etc. The rules are sorted by category: geolocation, velocity, list, basket and miscellaneous.

There are two types of rules: GO-type rules (detecting a favourable condition for the continuation of the transaction) and NOGO-type rules (detecting an unfavourable condition for the transaction).

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

Rules can be configured in decisive or informational mode.

Some rules do not have necessarily a positive or negative nature (for example geolocation rules: you may want to favour some countries or unfavour others) whereas some others do have necessarily a positive nature (whitelists) or a negative nature (blacklists).

By default, the proposed rules are configurable in simple configuration mode, in which a rule is defined as being positive (GO) or negative (NOGO).

Nevertheless, some rules have an advanced configuration mode. In this mode, the same rule can be both positive (GO) and negative (NOGO). The rule will have a positive, negative or neutral influence on the result of the transaction check depending on the rule setting and the transaction context.

The choice to activate the advanced configuration mode is done during the rule configuration in the profile. It is possible to activate this mode only for certain rules and to let the simple configuration mode for the others.

Rule advanced settings allow specifying the criteria that will have a positive or negative influence on the result.

Example with the cap collar amount rule configured as decisive:

Example with the 3-D Secure authentication rule configured as decisive:

In pre-authorisation mode (default mode of the Sherlock's 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.

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 Sherlock's 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.

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 LCL. It defines the scope of the available rules and of the configurations that may be mandatory. If an webshop has no suitable profile for the means of payment used, then the distributor’s offering profile is used.

Profile templates are defined and administered by the distributor. They are used as templates for creating merchant profiles.

Merchant profiles are defined by you for your webshop and are administered by you and/or the distributor (depending on the distributor's choice). They can be created from profile templates. The terms "webshop profile" may be used in this document. They are equivalent to the merchant profile.

Throughout this document, the notion of "profile" will refer to merchant profiles.

Antifraud profiles are set up through the fraud GUI of your extranet.

In most cases, you define a single antifraud profile that is applied to all transactions regardless of the means of payment used. However, you can also define additional profiles the settings of which suit one or more specific means of payment.

When a transaction must be evaluated, the risk management system first searches the webshop configuration for an antifraud profile specific to the means of payment used.

If no such profile is found, the system looks for the webshop default profile. This profile makes it possible to analyse the transactions that were not processed by the profiles specific to the means of payment.

To create a default profile, simply create a profile without associating any means of payment with it.

Only one profile can be active for a given means of payment. Likewise, only one default profile can be active.

For example, there can be:

• a dedicated profile for CB, VISA and MASTERCARD
• a dedicated profile for AMEX
• a default profile that will check the transactions for which other means of payment are used.

Which means three active profiles at the same time.

You can create as many inactive profiles as required. This allows, for example, to keep profiles in reserve for particular periods of the year (sales, holidays, etc.).

The rules are executed sequentially according to the order defined in the profile settings.

The first decisive rule that produces a positive result for GO rules or a negative result for NOGO rules prevents the execution of the rest of the decisive rules.

Informational rules are systematically executed.

Please refer to the 'Expression of rule results' section for the restitution of rule results in informational or decisive mode. The diagram below shows how rules are trigerred.

You can bypass some rules of the profile dynamically in the transaction request. Please refer to the data cardProductProfil in the data dictionnary.

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.

The executing result of the pre-authorisation profile is returned in the complementaryCode, complementaryInfo, preAuthorisationProfile, preAuthorisationProfileValue and preAuthorisationRuleResultList fields:

• complementaryCode contains the specific code of the decisive or informative rule which returned a negative result (for NOGO type rules) or a positive result (for GO type rules). If no decisive or informative rule returned a negatie or positive result, the field is set to 00.
• complementaryInfo* contains 3 types of information:
  • the result of each rule (decisive or informative) executed in the merchant profile, in the following format: <RULE_RESULT XX=Y XX=Y … XX=Y />, where:

    Letter(s)	Description	Value
    XX	Rule code	For rule codes, please refer to the list of rules.
    Y	Executing result	N: negative result
    		P: positive result
    		O: neutral result
    		U: rule not executed because of incomplete transaction data (i.e. data not specified).
    		X: rule not applicable to this transaction type.
    		B: rule not executed because you bypassed it
    		E: rule not executed due to a technical error
    		D: rule not executed due to a dynamic overriding error.

  • the complementary information produced by the executed rules. For detailed information, please refer to the 'Description and implementation of rules' section. Please note that only certain rules feed the complementaryInfo field.
  • the information on the payment card in use, if any. For detailed information, please refer to the 'Card information' section.
• preAuthorisationProfile contains the name of the antifraud profile executed prior to the authorisation request.
• preAuthorisationProfileValue contains the unique identifier of the executed profile version. This information is useful to retrieve the profile in the same configuration as when the rules were executed.
• preAuthorisationRuleResultList contains a list of detailed results for each rule executed prior to the authorisation request.

Each object contained in the preAuthorisationRuleResultList field corresponds to a rule result and contains the following values:

• ruleCode, the rule code. For rule codes please refer to the 'List of rules' section.
• ruleType, the rule type. For the rule type of each rule please refer to the 'List of rules' section. If the advanced configuration mode is activated for a rule, the value of the ruleType field is set to "MI".
• ruleWeight:
  • D: if the rule is configured as decisive in the profile
  • I: if the rule is configured as informative in the profile
• ruleSetting, indicates the rule configuration type:
  • D: dynamic in the transaction
  • S: static in the merchant configuration
  • I: static and imposed by the distributor offer
  • N: no configuration (when the rule does not require any configuration),
• ruleResultIndicator, the executing result of the rule:
  • N: negative result
  • P: positive result
  • O: neutral result
  • U: rule not executed because of incomplete transaction data (i.e. data not specified)
  • X: rule not applicable to this transaction type
  • B: rule not executed because you bypassed it
  • E: rule not executed due to a technical error
  • D: rule not executed due to a dynamic overriding error
• ruleDetailedInfo, complementary information produced by the executed rule. Please refer to the 'Description and implementation of rules' section for detailed information about each rule.

You are returned these fields in the following interfaces:

• automatic and manual responses from Sherlock’s Paypage
• responses from Sherlock’s Office connectors (Checkout, CashManagement (duplication) and Diagnostic services)
• Extranet
• Transactions report except the preAuthorisationRuleResultList field

Informative profile

Decisive or mixed profile

* The complementaryInfo field is deprecated as of version 17R1. It will no longer evolve and will eventually stop being populated. The information it contains is available in an improved version, in the preAuthorisationRuleResultList field.

** See the list of rules

The executing result of the pre-authentication profile is returned in the preAuthenticationProfileValue, preAuthenticationProfile, preAuthenticationProfileValue and preAuthenticationRuleResultList fields:

• preAuthenticationValue specific code of the rule which returned a negative result (for NOGO type rules) or a positive result (for GO type rules). If no decisive rule returned a negative or positive result, the field is empty.
• preAuthenticationProfile contains the name of the antifraud profile executed prior to authentication.
• preAuthenticationProfileValue contains the unique identifier of the executed profile version. This information is useful to retrieve the profile in the same configuration as when the checkings were executed.
• preAuthenticationRuleResultList contains a list of detailed results for each rule executed prior to the authorisation request.

Each object contained in the preAuthenticationRuleResultList field corresponds to a rule result and contains the same values as those in the preAuthorisationRuleResultList field in pre-authorisation mode. Please refer to the 'Pre-authorisation mode' section to know the content of this field.

You are returned these fields in the following interfaces:

• automatic and manual responses from Sherlock’s Paypage
• responses from Sherlock’s Office connectors (CashManagement (duplication) and Diagnostic)
• Extranet
• Transactions report except the preAuthorisationRuleResultList field

____________________

* See the various codes in the list of rules

The global Sherlock's offering supports many international means of payment such as Visa/Mastercard, the Paypal digital wallet, iDeal transfers, Sepa Direct Debits, etc.

The rules do note necessarily apply to all means of payment.

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

Please refer to the 'Correspondences between means of payment and antifraud rules' section to know whether an antifraud rule applies to a means of payment or not.

** Single message means of payment: authorisation and capture are performed in a single step, e.g. transfers with Ideal, Paybutton or Paypal in immediate mode. Dual message means of payment: authorisation and capture are performed in two steps.

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.

For payments in n instalments, only the first instalment is subject to antifraud checkings.

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.

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.