Merchant White Listing (Strong Consumer Authentication) for EMV 3DS

Introduction

Affective from 14th September 2019, Issuers in the EU/EEA are required to implement strong consumer authentication (SCA) of payers; SCA will ensure payers are in control of their funds and will also combat fraud.

Financial institutions are also required to implement Transaction Risk Analysis (TRA) and maintain strong and affective monitoring of transactions.

The requirement for TRA and SCA derive from regulatory frameworks such as the Payment Services Directive (PSD2) and the General Data Protection Regulation (GDPR) within the European Union (EU) and the European Economic Area (EEA) and many similar regulations in different jurisdictions around the world.

This article is abstracted from one of the documents made available to clients using Endeavour 3DSecure.

Strong Consumer Authentication

Strong Customer Authentication (SCA) can be performed using two-factor authentication (2 FA), i.e. two of the following three factors have to be systematically used during the authentication experience:

• Knowledge – something only the Cardholder knows: password, PIN
• Possession – something only the Cardholder has: mobile phone
• Inherence – something the Cardholder is: finger, face, voice, behavioral biometrics

Merchant White Listing

Merchant White Listing is the ability of cardholders to select a number of merchants who they explicitly trust and do not require the step-up or challenge associated with SCA.

‘White listing’ of merchants exempts from applying SCA for any amount, regardless of the merchant’s/acquirer’s and issuer’s fraud rate; it enables and protects one-click payments for cardholders, including card-on-file payment, as well as to enable recurring payments for variable amounts.

Merchant Selection

The selection of merchants proposed for whitelisting is controlled by the Issuer; the Issuer will consider the industry type, the low risk of the merchant and also the purchasing history of the cardholder; for example, the Issuer may propose 10 merchants which a particular cardholder uses often and the Issuer may include merchants which the Issuer knows to be low risk.

It is recommended to exclude specific merchants that have high fraud, e.g. above 13bps as defined in PSD2 RTS for Transaction Risk Analysis exemptions (such high risk merchants may already appear on the ACS’s black list of merchants that systematically require SCA today) or specific MCC with high chargeback rates.

It is recommended to allow merchants to be whitelisted that use any of the following merchant risk assessment data available in EMV 3DS authentication requests:

• Merchants sending the 3DS Requestor Authentication Method: threeDSReqAuthMethod with values:

 02/authentication using merchant credentials

 03/authentication using federated ID

 05/authentication using 3rd party authentication

 06/authentication using FIDO authenticator

• ShipIndicator with value 02/ship to verified address on file.
• CardholderAccountAgeIndicator with values

 03/ Less than 30 days

 04/ 30−60 days

 05/ More than 60 days.

Cardholder control

A merchant cannot be automatically white listed; the cardholder must always consent and an SCA is required as part of this consent. Merchants cannot automatically propose themselves to Issuers for whitelisting; merchants can promote whitelisting to payers although they have no automatic way of knowing if the Issuer supports whitelisting or if the cardholder has already whitelisted the merchant.

It is likely that the large international internet merchants, as well as strong local retailers will have the resources and influence to propose themselves to Issuers in key markets.

To obtain from the cardholders an express informed consent (as per Global Data Protection Regulation or GDPR); it should be clear to cardholders what they are agreeing to, including which entity (or entities) was white listed and in which countries and for which products and services (in case an entity provides multiple products and services); this can be achieved by adding a link to the terms & conditions; it should be noted that this requirement is similar to setting up a direct debit (i.e. e-mandate).

If a cardholder does not consent to whitelisting a particular merchant, the Issuer should not continue to propose that merchant to the cardholder after the first few refusals.

A cardholder has the ability to remove a merchant from MWL at any time; this can be done either through internet banking or via an option provided by the ACS used by the Issuer.

Whitelisting Process

A merchant can be whitelisted during the payment process or through internet banking. SCA is required to whitelist a merchant. A single SCA, performed for both the payment transaction and the whitelisting confirmation is sufficient and compliant with the PSD2 RTS, provided that payment and white listing happen simultaneously.

The authentication screen can contain a checkbox prompting the cardholder to whitelist the particular merchant for the particular merchant as identified by the Merchant Name (see Merchant Name section further below). The SDK for native support of 3DS can handle the checkbox prompt via the Single Select UIType, so whitelisting can happen without leaving the merchant application.

Still an Authenticated transaction

A Merchant has no way of knowing if they have been whitelisted by a particular cardholder or if they have been removed. A Merchant must therefore always send the transaction for authentication. In future versions of 3DS, new fields may be introduced to enable the Issuer to notify the merchant that they are whitelisted for the particular card used by the cardholder.

Transaction Risk Analysis

Even if a merchant is whitelisted, the Issuer is required to perform transaction monitoring and Transaction Risk Analysis (TRA), the Issuer must require SCA if the transaction is considered to be high risk; the requirement to prevent fraud always comes first.

To determine if SCA is required; TRA will consider data points such as:

• Device data (e.g. platform, device model, device name, OS name and version, IP and WiFi MAC address, screen resolution, time zone…)
• Cardholder shipment address if physical goods are purchased

Liability Shift

Unless the Acquirer applies an SCA exemption, the Issuer is liable for fraud if an authorization was approved, provided that the merchant sent an authentication request for the transaction.

If a merchant is whitelisted, the merchant is not assuming the risk – there is no change to the 3DSecure liability rules, it still stays with the Issuer; even with whitelisting, transactions are still sent for authentication and the Issuer is still responsible for performing TRA.

As per PSD2 regulation, the cardholder is – without SCA – only liable if he/she acted fraudulently (the cardholder is not liable under PSD2 if he/she acted with gross negligence and no SCA was applied).

How the ACS Identifies Merchants and Cardholders for whitelisting

Merchants

The ACS will use the merchant name sent in the authentication request message (field MerchantName in AReq) to identify merchants enrolled for whitelisting.

Merchant names typically do not change when 3DS Server or acquirer is changed and an estimated 99% of merchants already use a single merchant name which is unique and easy to recognize by the payer.

Merchants can include a country suffix in the merchant name which will allow the payer to only white list a merchant in a given country and not in others.

Acquirers and merchants should ensure that the merchant name used in EMV 3DS messages is unique, consistent and recognizable by the cardholder, especially if multiple 3DS Servers or PSPs are used. For merchants offering very different products and services (e.g. groceries and telecom services), the merchant name should also describe the activities of the merchant to ensure that the payer knows what entities (and related activities) are white listed.

Cardholders

Cardholders are identified for whitelisting by the PAN. If, for any reasons, the PAN of the payer changes (e.g. due to lost & stolen card), then the ACS should ensure that its MWL is updated to link the new card to white listed merchant name.