As you know, PSD2 and SCA are coming our way... Well actually the deadline has passed and it's here! But the implementation is happening gradually in some countries and postponed in others. 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!
24 MARCH UPDATE:
In this month’s update, we look at (1) the recent release of an Opinion from the European Banking Authority regarding banks that are putting up obstacles to PSD2/SCA implementation and (2) and a lack of clarity in the PSD2 regulations about B2B transactions. Also I provide some commentary on where we are at in terms of PSD2 implementation as an industry and a society. I also provide a vocabulary list at the end of the post, because as we know, the jargon and acronyms build up quickly in the PSD2 topic. :)
I saw a webinar description with the following quote, which is one of the more optimistic I’ve seen regarding PSD2/SCA implementation since the January 2021 deadline: “This year marks the start of a change in the goal posts. With the influx of richer datasets, PSD2 is quickly shifting away from a pure compliance play and moving into its strategic mission of driving better customer experience and trust.” Its inspirational tone certainly caught my attention. So where is Europe in the rollout of the Second Payment Services Directive? I think we are at the stage of listing and describing the problems and gaps in the regulations. We’re drawing a circle around the things that need to be fixed and added. And to an extent, this was to be expected. How can we expect regulators to think of every single necessary piece of regulation, given an evolving technological landscape? The general lack of guidance provided by the European Banking Authority after the deadline leads me to believe that their regulators are depending on the stakeholders to organize their own comment period and speak out even though the deadline for implementation has passed.
In this month’s PSD2 update, I present a few of the potholes that need to be filled, so to speak.
The European Banking Authority speaks: ASPSPs (banks) must remove obstacles!
Back in June 2020, the European Banking Authority (EBA) published an official opinion on obstacles of the implementation of PSD2 and SCA, specifically calling out practices by account servicing payment providers (ASPSPs) that are obstacles to account access under Directive (EU) 2015/2366 (PSD2) and Article 32(3) of the EBA’s Regulatory Technical Standards. The EBA specified that they expect national competent authorities (NCAs) to take the necessary actions to ensure that ASPSPs (the banks) comply with the PSD2 and the RTS and remove any obstacle identified within the shortest possible time and without unnecessary delays (by the way, I added a vocabulary list at the end of this post, because I can sense that the jargon and acronyms are building up rather quickly).
The EBA stated that it continues to observe that some ASPSPs across the EU have still not removed obstacles and are preventing the competition-enhancing objective of the PSD2 from materialising in full. The recent Opinion’s purpose is that the relevant legal requirements are applied consistently across the EU by removing identified obstacles in a timely manner. The EBA expects NCAs (national competent authorities) to take, by 30 April 2021, take some supervisory actions requiring non-compliant ASPSPs to become compliant with the applicable law and to set a deadline for the removal of these obstacles. The EBA recommends that NCAs follow a risk-based approach with meting out the supervisory actions, which I think means to tread carefully and dot your i’s and cross your t’s. The supervisory actions may include but are not limited to issuing an instruction/warning to the non-compliant ASPSP or requiring an amendment to ASPSP’s rules, procedures and/or systems. Penalties can include, but are not limited to, the revocation of the exemptions from the contingency mechanism under the RTS on SCA already granted to ASPSPs and/or the imposition of fines. The former sounds more severe than the latter, that’s for sure.
So, removal of ASPSP obstacles are on the to-do list. :) Step by step… If we remove several major obstacles and fill in some gaps in the regulations, then we'll be well on our way to PSD2 bliss (driving better customer experience and trust).
A gap in the PSD2 regs: consumer vs. corporate environments
Adflex has done a great job of contributing some helpful critiques of the current PSD2 regulations especially with regards to how SCA rules apply to corporate or B2B environments, which operate a little differently than consumer or B2C environments. There is a lot at stake, including whether the precious SCA exemptions apply in certain cases. It appears that the PSD2 regulators devised the regs with the assumption that there are some pretty clear delineations between the two worlds; this has proven to not be the case...
B2B vs. B2C. B2B transactions can be much more complex than B2C transactions, so complying with SCA rules is currently a gray area type challenge. Often, prices fluctuate far more often than they would on a traditional B2C eCommerce platform. Dynamic pricing and disparities between a quote and final pricing lead to uncertainty over how and when SCA procedures should occur. For example, a repair service provider might provide an estimate, secure a sale, and then adjust the price as needed. Or, customized pricing agreements between buyer and supplier may see costs fluctuating depending on inventory and demand. So what happens when the initial amount is different to the final amount? It turns out that in the current regs, there are quite strict rules that the amount that’s authenticated must be equal to or less than the amount authorized.
Timing. There is also confusion around whether merchants should initiate SCA procedures at the time a purchase is made, when an order is fulfilled, or when payment occurs. In B2B transactions, these activities can potentially occur weeks apart from each other. Also, what if a B2B merchant accepts credit card details over the phone and enters that information into their own web portal? When should B2B merchants initiate SCA procedures in such a case? Another clarification from the EBA may be in order.
Exemptions. Another major area of uncertainty is in the SCA’s language surrounding exemptions. While the legislation leaves room for exemptions, it does not specify when B2B transactions might qualify for them. There is ambiguity of a consumer-versus-corporate environment and the difficulties in providing a commercial card transaction within a “secure” environment, as the SCA requires.
But how is a corporate environment defined? The U.K.’s Financial Conduct Authority has defined it as a transaction that’s taken in a closed loop between businesses and not open to consumers. But, as Adflex has pointed out, a lot of sites now, especially since the pandemic, are open to both corporations and consumers. Adflex’s CEO is quoted as saying “I think it’s going to take another year before we really know what’s happening.”
The CEO of Adflex is quoted as saying “I think it’s going to take another year before we really know what’s happening.” The other thing I’ve heard from folks in the payments universe is “No one knows what is going on.”
In other words, it’s a process.
The gaps, errors and mistakes will be identified and described and ironed out. In a year we’ll be well on our way to PSD2 nirvana, which is “shifting away from a pure compliance play and moving into its strategic mission of driving better customer experience and trust” (thanks Ekata).
There’s a lot of work to be done.
But the regs are clear and consistent on the need to keep fraud rates low, and the good news is that it is something your company can control. Keep your fraud rates low! Partner with a Machine Learning-based fraud prevention solution like oh, I don’t know, maybe NETHONE, and let us worry about the account takeovers, false positives, chargebacks, remote desktopping scams, acceptance rates, etc. Payment service providers (PSPs) will continue to bear the weight of compliance headaches, but we can help them too, as we’ve already demonstrated in some of the historically highest fraud-risk geographies in the world.
PSD2 jargon terms
API: Application Programming Interfaces. The API must allow Third Party Payment Service Providers to provide payment initiation or account information without difficulties.
ASPSP: Account Servicing Payment Service Providers provide and maintain payment accounts for payment service users (PSUs). Traditionally, ASPSPs are banks and similar institutions. Under Open Banking, ASPSPs publish Read/Write APIs. These enable consumers to share their account transaction data with third-party providers; in turn third-party-providers can initiate payments on their behalf. Under PSD2, all ASPSPs in Europe are required to participate in open banking and provide access to the data.
CSC: Common and Secure Communication. Common and Secure Communication (CSC) seeks to promote competition and innovation among payment service providers by introducing: TPP (Third Party Payment Service Providers). Entities that not have payment accounts for their customers but can provide the following services:
AISP – Account Information Service Provider – a one stop shop for all of your payment accounts, irrespective of where they are held
PISP: Payment Initiation Service Provider – entities who can make payments on your behalf
NCA: National Competent Authorities are not only responsible for supervision but also for registering and authorising providers and publishing registers that will be used both by Qualified Trust Service Providers (QTSPs) to make decisions on issuing certificates and by financial institutions to check whether other parties are authorised.
RTS: The Regulatory Technical Standards define how access to the customer's account is handled between ASPSP’s, AISP’s and PISP’s: Customer Consent, Secure Communication channel to access the payment account, secure screen scraping, all the while complying with GDPR – General Data Protection Regulation
SCA: Strong customer authentication (SCA) is a requirement of the EU Revised Directive on Payment Services (PSD2) on payment service providers within the European Economic Area. The requirement ensures that electronic payments are performed with multi-factor authentication, to increase the security of electronic payments.
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.