MWL enables cardholders to choose their favorite merchants and avoid additional authentication, if applicable. However, this feature demands merchant risk assessment on the issuer side and possible change of known rules in certain scenarios. Learn how to act accordingly with risk associated to merchant whitelisting. Start from here.
This article is a part of our Merchant Whitelisting Best Practices series. To round up the story take a look at our post regarding MWL industry best practices, UX edition.
Merchant whitelisting, or trusted beneficiaries, is a new 3D Secure v2.2 feature enabling cardholders to whitelist their favorite merchants, and thus, skip additional authentication steps. It is a part of SCA exemption rule, included in the PSD2 directive. Regardless of the merchant fraud rate or the transaction amount, cardholders are able to enjoy a truly frictionless payment experience. While applicable to common online payments, MWL applies to card-on-file payments, as well as recurring payments with variable amounts.
To be an MWL eligible candidate, you need to be preselected by the issuing bank of your customer. Merchant whitelisting is under the issuing bank's control; i.e., issuing bank is the body in charge when it comes to compiling a list of merchants eligible for whitelisting. Mentioned assessment is based on parameters such as level of risk, cardholder transaction history, merchant industry type, etc.
A more detailed overview of merchant whitelisting is available in our recent post Merchant Whitelisting within PSD2: An Overview.
When introducing merchant whitelisting to your customers, be mindful of the associated risk that might come with it. The following sections reveal best practices when it comes to selecting eligible merchants for whitelisting, handling transactions with risk levels higher than usual, as well as questions regarding GDPR and liability shift.
The original statement regarding the liability shift states that for all transactions authenticated using 3D Secure technology, liability shifts to the issuer side. The same applies to transactions made with the merchant whitelisting feature. Since the issuing bank is the one that approved that a merchant can indeed be on a cardholder's whitelist, they are also liable for potential fraud.
As mentioned, cardholders will be able to whitelist only merchants who are deemed eligible according to the issuing bank's assessment. It is highly recommended to avoid merchants that have fraud rates exceeding 13bps. These merchants might automatically appear on the merchant blacklist, which requires SCA per default.
MasterCard's recommendation is to allow whitelisting of merchants who use any of the following merchant risk assessment data available in EMV 3DS authentication request:
• 3DSRequestorAuthenticationData 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 a verified address on file.
• CardholderAccountAgeIndicator with values 03/ Less than 30 days or 04/ 30−60 days or 05/ More than 60 days.
Merchants should provide as much data as possible in their EMV 3DS authentication requests. By doing so, they are enabling issuing banks to conduct a more quality risk assessment necessary for merchant whitelisting approval.
Another implication involves sharing lists of merchants that are not eligible for merchant whitelisting. The idea is to avoid double checks and make the candidate selection process as streamlined as possible.
Online payments made using merchant whitelisting should automatically be low risk because SCA is necessary to add a merchant to the whitelist. Moreover, issuers perform risk assessment in order for the merchant to be eligible for whitelisting. Lastly, cardholders are in charge of managing their merchant whitelist. They should whitelist only merchants whom they trust and have shopped before with.
However, PSD2 requires all transactions, regardless of the SCA exemption rule, to be monitored. If transaction monitoring deems transaction risk as considerable, SCA should be applied. Examples of data mismatches suggesting a risk that is higher than the usual include device data and shipping address mismatches.
In order to whitelist a merchant, cardholder consent is necessary. Screens containing the option to whitelist a merchant need to include updated terms and conditions as well.
If you want to find out more, contact our ASEE 3D Secure Team or download the datasheet.
