As you know, PSD2 and SCA are coming our way. I will continue to provide you with updates that I hope will help you navigate and implement the directives without loss of customers or sanity!
19 JANUARY UPDATE:
Many have been looking forward to (or in some cases, dreading) the December 31, 2020 PSD2/SCA deadline for a few years now. So here we are. But where are we? Adyen recently provided an update on the “Latest PSD2 migrations.” They tracked Soft Declines on a small percentage of transactions returned for non-authenticated transactions in 10 of the EU countries. I noticed that the list included some countries whose competent authorities had not yet specified a compliance deadline (Poland, Sweden) or had originally indicated a later enforcement date (Denmark). I would say that Adyen’s update looks very optimistic for the success of the rollout of PSD2/SCA for the most part, with the exception of Norway, where all issuers migrated to PSD2 logic on December 28th, but reverted after a couple of hours. But that is just one perspective, as Adyen’s clients tend to be of the enterprise variety, more established players that have already prepared their customers for the extra authentication steps. For example, Otto.com in Germany, which is one of the largest e-commerce players after Amazon, has already been enforcing 3D Secure for many years. Their customers are used to it.
I have been in touch with my various contacts in the payments industry, and they tell me that actually most merchants have not upgraded from 3DS 1.0, even though the EMV 3DS 2.1 Mastercard mandate for issuers was October 2019 and Visa’s mandate was March 14, 2020. An increase in scheme fees have made many merchants wary of upgrading.
Also, some merchants have reported recent, drastic declines in acceptance rates (some even reporting dismal acceptance rates of 60%). If a merchant hasn’t been offering 3D Secure for a while, then their customers will experience a completely different checkout experience. So it appears that the rollout is proving to be challenging for many except for select enterprise-level merchants.
I'm a little surprised that there haven't been more updates and educational campaigns from the EBA and the competent authorities in the various EU countries. I think merchants and PSPs could use some support. So there is a bit of work that remains, but we knew that might be the case :) Reach out if you want to talk about increasing your acceptance rates with an anti-fraud solution that works in the background of your page. I know I threw around some of the many acronyms and jargon that come with the territory of PSD2 and SCA. Here are some definitions and explanations:
What is a “soft decline”?
Soft declines occur when the bank issuing the funds has approved the payment, but the transaction fails somewhere else. As David Goodale, CEO of Merchant Accounts writes, “If you think of the payment process as a chain of events, there are several “handshakes” that must occur in order for a transaction to complete. If one of these parties in the chain is down, interrupted, or unavailable during the transaction resolution, a problem will occur.” Hard declines, by contrast, occur when the issuing bank does not approve payment for processing. Hard declines usually require the payment card information to be updated before the transaction will be successful, regardless of how many retries are attempted.
What are the differences between 3DS 1.0 and 2.1 and 2.2?
3D Secure 1.0 (3DS 1.0) connects merchants, payment networks, and financial institutions in order to authenticate transactions and share data. The latest iteration -- 3DS 2.2 -- provides improvements in mobile payments processing. The 3D Secure 1.0 version was developed well before the advent of the smartphone.
2.x is intended to reduce the occurrence of authentication challenges -- which can range from an app-switch to a one-time password sent via SMS -- by requiring issuing banks to utilize a larger number of data points to determine if a challenge is warranted. Some of these data points, such as the email address, billing address, etc, will be supplied by customers, while others come from the customer’s device and browser data. The premise for these changes is that if the issuing banks have sufficient data about the customer attempting the transaction, it will reduce the need for authentication challenges.
15 DECEMBER UPDATE:
PSPs had until the 14th to provide the EBA feedback on the incidents reporting procedure under PSD2; Brexit complicates the alignment between the EU and the FCA as the FCA will no longer be a recognized NCA by the European Banking Authority (EBA) when a no-deal Brexit happens; finally, the EU Court of Justice recently “clarified” three PSD2 provisions (it’s a bit of confusing legalese, but bear with us). /Patrick
1. PSPs had until the 14th to provide the EBA feedback on the incidents reporting procedure under PSD2
The EBA (European Banking Authority) was collecting feedback from PSPs regarding the incidents reporting procedure under the Payment Service Directive (PSD2) until yesterday. The proposal aimed at optimising and simplifying the reporting process, capturing additional relevant security incidents, reducing the number of operational incidents that will be reported, and improving the meaningfulness of the incident reports received. The revision of the Guidelines also intends to decrease the reporting burden on payment service providers (PSPs). The consultation ran until 14 December 2020.
2. You can file this one under “probably not a huge surprise but of course it’s still important to consider” → PSD2 meets Brexit.
Brexit complicates the alignment between the EU and the FCA (Financial Conduct Authority - the UK National Competent Authority) regarding PSD2 implementation. According to Paymentssource, the post-Brexit era introduces an array of economic and geopolitical issues, one being digital payments between the European Union and the U.K. and how they will be handled moving forward. One of the interesting areas is the validity of digital certificates issued to financial entities located in the U.K. in the context of compliance with the Payment Service Directive 2 (PSD2). The reasoning is that the FCA will no longer be a recognized NCA by the European Banking Authority (EBA) when a no-deal Brexit happens. On the other hand, the FCA has indicated its continued acceptance of PSD2 certificates, while also recognizing that alternative methods may be required for UK entities. Both solutions are currently included in the draft version of the FCA's Regulatory Technical Standards on strong customer authentication and secure communication. Extensive dialogue is currently ongoing between the authorities, QTSPs and financial institutions seeking a solution for this tension in the positions of the EBA and the FCA.
3. The EU Court of Justice recently “clarified” selected PSD2 provisions (it’s still a bit confusing, but bear with us). Here is my summary of interpretation and commentary written by Lexology.com
Changes to the framework agreement – tacit consent by the PSU (meaning the customer, or user) not notifying any objection
Sometimes a PSP wants to make changes to an existing framework agreement (e.g. its terms and conditions or Terms & Conditions) in place with a customer (also known as a Payment Service User or PSU in PSD2 language) and, in order to make those changes, the customer’s consent is required. In November this year, the EU Court of Justice issued a further judgment relating to this and various other PSD2 provisions. The questions before the Court were raised by the Austrian Supreme Court as part of an on-going trial between DenizBank and the Austria’s Association for Consumer Information (VKI). However, as an alternative to an actual PSU consent being obtained, the parties can (and typically do) agree in the Terms & Conditions that the PSU “is to be deemed to have accepted [proposed] changes if it does not notify the [PSP] before the proposed date of their entry into force that they are not accepted.”
PSP obligation to prove and to refund – exception for anonymous payments, including contactless payments without SCA
There are various provisions which make the PSP liable with respect to any unauthorised use of a payment instrument which it has issued, subject to certain limitations – such as the potential for the PSU to be liable for up to the first €50 of any loss and also bearing full liability to the extent of fraud or gross negligence on their part. There is one exception from the above PSP-bears-liability principle (the Low Value Derogation) for low-value instruments which are being used anonymously or in circumstances where it is not possible to prove PSU authorisation. Where the derogation (exception) applies, the PSU can be required to bear the full loss of unauthorised transactions.
Exception to notification requirement and PSU liability – obligation for PSP to prove that the low-value payment instrument cannot be blocked
Should a PSU (also known as a customer) find that their payment instrument has been lost or its security compromised, they can cap off any liability (including their potential liability for the first €50 of any financial loss) by notifying the instrument’s PSP issuer and getting it cancelled. There is a potential exception to the rule (the No-Cancellation Derogation) available which will dis-apply these PSU protections for certain low-value payment instruments. The test of whether a payment instrument is sufficiently low value is the same as it is for the application of the Low Value Derogation.
The No-Cancellation Derogation is only available if:
(1) “the payment instrument does not allow its blocking or prevention of its further use”; and
(2) the PSP and the PSU have agreed in the framework agreement for the use of the payment instrument that the derogation will be available.
12 NOVEMBER UPDATE:
I like how Revolut put it back in 2018: “In case you’ve been living under a rock, this is about to kick off!” The “this” they referred to is Payment Services Directive 2 (PSD2). It has already changed the banking game in Europe and around the world, introducing new fintech players that can now access the open banking API. We’ve discussed previously how the open banking revolution has recently begun in Brazil too. The Strong Customer Authentication (SCA) element of PSD2 has yet to be fully implemented, but alas, the extended deadlines approach! Yes, there is more than one deadline, and they vary by country (see below). I have worked in payments for several years and I’m excited by the innovations in the industry but I also feel for the merchants who have to keep rejected transactions low during a period of transition. So I will update this blog post every other week during this implementation phase.
What are the PSD2 SCA exemptions?
SCA applies to all accounts where the holder can place and withdraw funds without any additional intervention or agreement of their payment service provider (such as a current account). All electronic payments are subject to SCA. Exemptions include payments for online transactions below €30, as well as contactless payments at points of sale for amounts €50 and below. If there are several contactless payments of €50 and below in a row, then SCA should be performed when the cumulative total is €150 or during the 5th subsequent payment. There is another exemption for corporate payments. Most corporations make payments in batches rather than one by one. Security mechanisms for these types of transactions can be as effective as SCA. Examples are payments made through central travel accounts, lodged cards, virtual cards, and secure corporate cards.
Low Risk / Transaction Risk Analysis (TRA): Issuing banks can consider transactions as low risk based on the average fraud levels of the card issuer, or of the acquirer processing the transaction, or both. But this will not be in the merchants hands only but it will also depend on the overall chargeback rate of their Payment Provider or Acquirer on a platform level. Whitelisted Merchants or Trusted Beneficiaries: After a strongly authenticated payment session, shoppers can add the merchant to a whitelist for the issuer, but double check to see the issuer supports whitelisting. But realistically this is not an option yet as it would require banks to implement such a feature within their online banking panel. Strong customer authentication will only be required for payments when both the cardholder and merchant bank are within the EEA, but this will still have indirect consequences for non-EEA payments. There’s a chance that some EEA-based issuing banks will apply the SCA requirement to all payments even if the merchant’s bank is outside the EEA. This means non-EEA sellers could see more payments being challenged starting in December.
A takeaway: work on reducing those fraud rates
Under PSD2, if your acquirer’s fraud rate is below 13 basis points (bps) there’s no requirement for a challenge of transactions of up to €100. But if the fraud rate is below 6bps that ceiling rises to €250 (if you want to reduce your fraud rates, Nethone Guard can certainly help). Theoretically this could go up to amounts of € 500 or more but it will again be different from acquirer to acquirer and it would require chargeback rates below 10bps.
Out-of-scope transactions not covered by the PSD2 directive
Out-of-scope transactions are transactions not covered by the PSD2 mandate. The issuing bank will not apply SCA unless you specifically ask for 3D Secure in your payment request.
Out-of-scope transactions include:
Interregional transactions: Payments where the card was issued outside of Europe or where the country you are acquiring from is outside of Europe. Some European issuing banks are expected to require SCA anyway even if a payment is acquired outside of Europe. So using a foreign acquirer will not be the solution, of course also considering the schemes’ location rules.
Merchant-Initiated Transactions (MIT) and Direct Debits: A payment or a series of payments with fixed or variable amounts that the merchant performs without direct involvement of the shopper. Examples are subscriptions, automatic account top-ups, and installments. The initial transaction should have gone through SCA and the shopper should have agreed to the terms and conditions of the succeeding MITs.
Mail Order and Telephone Orders (MOTO): MOTO transactions are not considered to be electronic payments, so these are out of the scope of the regulation.
Anonymous cards: These types of cards can only be identified by the issuing bank, such as anonymous prepaid cards.
When will strong customer authentication (SCA) become mandatory?
It varies by country! Here is a list of current implementation dates.
Consequences of not being PSD2 SCA compliant
PSD2 is actually directed at banks, not merchants. This means that issuing banks that approve non-compliant transactions will be penalized. Of course merchants should ensure that their transactions are compliant to avoid the risk of issuing banks refusing their transactions.
The time is now to Focus on building a plan of implementation, testing and iterative releases
Merchants should focus on building a phased plan of implementation, A/B testing and iterative releases in order to ensure that the introduction of SCA causes minimal disruption to their purchase flows. I talk to merchants and payment providers every day, so I know that PSD2/SCA implementation is a challenge! If you have any questions about the process, please feel free to reach out via Linkedin.
To wrap up today’s post, let’s see how many PDS2 and SCA acronyms we can fit into one update:
PSD2 and SCA are about to launch in most EU and EEA countries by the end of Q4 2020. With an open banking API, PSD2 helped lay the groundwork for exciting new fintechs operating as AISPs and PISPs. Like GDPR, PSD2 will impact businesses outside the EU if it provides payment services in the EEA; non-EEA sellers could see more payments being challenged starting in December. For out-of-scope transactions, issuing banks will not apply SCA unless you specifically request 3DS in your payment request. Out-of-scope transactions include MIT and MOTO.