PSD2 Migration Status Update
Here we are in 2020, and the deadline for compliance with the revised Payment Services Directive (PSD2) has passed. To any American merchants thinking “deadline? What deadline?” right now, don’t panic—the PSD2 is a directive from the European Union that only applies to merchants with a presence within the greater European Economic Area. Whether you’re subject to it or not, the PSD2 is mandating big changes that are likely to have a ripple effect on ecommerce worldwide. Many players in the industry are starting to wonder: how well is the migration toward PSD2 compliance faring so far?
First, a refresher on what, precisely, the PSD2 entails. There’s a lot to unpack in a set of rules that covers as much as the PSD2 does, but two of its requirements have emerged as the most significant:
- Open Banking, which requires banks to make their payment initiation and account services accessible to third party service providers.
- Strong Customer Authentication, which mandates the use of two-factor authentication and other security requirements to protect consumers from fraud.
The SCA requirement has been easy enough to implement on a technical level (the biggest problem tends to be pushback from customers who find two-factor authentication inconvenient), but meeting the open banking requirement has been challenging for some banks. While the PSD2 does not specify that access to services must be provided via an API, this is the most logical way for most banks to meet the requirement to have a “dedicated interface” that third party providers can use.
Is PSD2 active?
First, let’s sound a positive note. Last March was the deadline for banks in the EU to have an API (or some equivalent interfacing system) set up and ready to be tested by third party service providers. For most banks, this would have been the toughest technological hill to climb in terms of PSD2 readiness and compliance, but among the 2,000 biggest banks in the EU, nine out of ten of them managed to produce functional sandbox testing environments and documentation by the March deadline.
To give credit where it’s due, that’s a fairly impressive showing. Beyond that, however, adoption has been progressing a bit more slowly, and fewer banks have met the subsequent milestones.
As of right now, less than half of all banks subject to the PSD2 have met all of the requirements. One of the most important deadlines came and went on September 14th, the date at which API production environments were supposed to be ready to go live.
Why is PSD2 behind schedule?
Is this failure to stay locked into the schedule a stinging indictment of either the banks or the PSD2 itself? Hardly. Rewind to January 2018 when banks in the United Kingdom had to comply with a similar, UK-only open banking mandate, and once again you’d see half of the affected banks failing to meet the production deadline. Stability, full documentation, and functional environments didn’t fully arrive until about a year later.
Effecting the similar changes in banks all across the EU is an even more ambitious task, and EU regulators presumably understand that buggy, incomplete, and poorly-documented APIs are a recipe for disaster. That’s why the September deadline was followed by a transition period that’s expected to last until the end of 2020, giving banks additional time to refine, test, and debug their API environments before getting hit with non-compliance penalties.
Who else is involved with implementing PSD2?
Another thing to keep in mind is that the banks aren’t stuck figuring this out by themselves. The third party providers they’re being compelled to cooperate with have an obvious stake in seeing a smooth and successful rollout of PSD2, and they are doing their best to lend solutions and technical expertise to banks who are still working out the kinks in their interfaces.
More than three thousand banks in France, Germany, the UK, and other European countries are working with third party providers to create platforms where all of the various banks’ bespoke APIs can connect through a single standardized API. This gives other third party providers a single, simple point of contact from which to access account data and initiate payments.
This isn’t any kind of quick fix for companies still struggling to develop the technical solutions necessary to meet PSD2 standards—it requires considerable time and labor in terms of testing, establishing secure and trusted connections, and verifying compatibility with existing providers. What it is doing is helping to build a robust and organized system that’s designed to take full advantage of the benefits the PSD2 is supposed to confer. Industry analysts expect even more banks to join in this process in the year ahead.
While some might have imagined that the big banks would have to be dragged kicking and screaming toward mandated openness, the reality is that most banks appear to be making a good faith effort to comply with the PSD2 and that the delays can mostly be attributed to the fact that developing and testing the technology needed to bring balkanized banking platforms together and open their data up (safely and securely) to third party account and payment service providers is simply a lot of difficult and time-consuming work.
In fact, the PSD2 is already starting to bear fruit, with APIs being used for single payment applications, wallet loading, and other relatively simple functions. As more banks get on board and developers grow more comfortable with the new systems and environments, we should expect to see even more useful and innovative explorations of the possibilities afforded by open banking.
Of course, one last question remains—what does this portend for the world of chargebacks?
The SCA requirement will have the most obvious and direct impact, as it will assist greatly in screening out true fraud and make it harder for cardholders to engage in friendly fraud. Open banking may well create new challenges, as customers will have the ability to use different service providers for storing and managing their funds. Be assured that consumers will test the logical limits of these systems and fraudsters will probe them for any possible weakness, so as always it is incumbent on merchants to look out for their own cybersecurity, keep detailed transaction records, and be prepared to fight chargebacks whenever they can.