Payments in Europe have come a long way since PSD2’s predecessor Directive established a modern and comprehensive set of rules for all payment services in the European Union (EU) and the European Economic Area (EEA), laying the legal framework for the Single Euro Payments Area (SEPA). That first payments revolution brought faster, more convenient and safer payments to millions of payment service users (PSUs). Today, however, we are on the cusp of a second, potentially even more significant, revolution that will ultimately affect not just payments, but banking services in general.

PSD2 aims to better align payment regulation with the current state of the market and technology, strengthen payment security and enhance consumer protection. Yet it goes further still: its purpose is also to shake up the European payments market by encouraging greater competition, transparency and innovation in payment services.
What will bring about this change is PSD2’s requirement to open up the payments market to third party providers (TPPs), obliging traditional account servicing payment service providers (ASPSPs) including banks to give them guaranteed access to the customer account information they need to provide their services.

While this prospect initially caused concern to some in traditional financial institutions, most are now embracing it as a timely and necessary stimulus to the industry to future-proof itself against a new age in payments and banking services. Given the clear benefits to customers, banks should therefore not delay getting PSD2-ready and instead participate in the consultations and act on the early drafts of the European Banking Authority’s Guidelines immediately in order to ensure smooth implementation projects.

Timelines and the 'implementation gap'
So, what must organisations do now to comply with PSD2? There are several points worth noting concerning the Directive’s implementation timeline.

Firstly, although the regulation comes into force on 13th January 2018 across all member states, not all are likely to meet this deadline. To date only Denmark, France, Germany and the United Kingdom have transposed PSD2 into national law, with a number of other member states having draft legislation in place.

Secondly, due to the way the various European bodies elaborate and scrutinise legislation, there is going to be a significant ‒ even a problematic ‒ gap in implementation of different parts of PSD2.

As said, the regulation as a whole comes into force on 13th January 2018, but the provisions introducing the third party interface have been delayed by discussions between the European Banking Authority (EBA) and the European Commission over its content. However, the final version of the EBA’s Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common Standards of Communication (CSC) was provided by the European Commission on 27th November, providing a solution that should address the interests of all market participants. Once adopted, the RTS have an eighteen-month implementation period, so the relevant provisions of PSD2 are likely to become applicable around September 2019.

So can ASPSPs put off building their third party interface, and implementing 2-Factor authentication until later next year? The answer is a resounding no. No organisation should use the “implementation gap” as an excuse to delay any of their PSD2 preparations. One minor exception is that it would be premature to publish amended terms and conditions for customers in member states that have not yet transposed PSD2 into their national law (though these can of course be ready in draft).

There are a number of reasons why preparations for all parts of PSD2 should advance at full speed. The first is that a number of important provisions in PSD2 that are closely bound up with interface requirements will be mandatory from 13th January 2018, irrespective of whether an organisation has a live interface or not.

One example concerns errors in payments involving a TPP. From 13th January 2018, the legal position concerning payments involving a TPP, and consequently their risk profile for ASPSPs, will change entirely. A PSU complaining of an erroneous payment initiated by a TPP will no longer be able to claim reimbursement from the TPP, but only from the ASPSP, who must recover from the TPP. However, an ASPSP without 2-Factor authentication in place dynamically linking a transaction to the amount and the payee specified by the payer initiating the transaction may not have sufficient means of demonstrating who was responsible for the error.

A second example is cancellation of payments. From 13th January, PSUs will no longer be allowed to cancel payments involving a TPP. An ASPSP without a dedicated interface for TPPs will not be able to tell whether a transaction was initiated by a TPP or not. It will of course incorporate into its terms and conditions of acting for its PSUs that they are not entitled to cancel transactions involving TPPs. The really effective and practical solution, however, will be to have the interface in place.

Quite apart from these considerations, getting the interface and strong customer authentication up and running will benefit customers immediately, and ensure readiness and functionality when it is required. Additionally, those dragging their feet will miss out on prime mover opportunities in the new environment of Open Application Programming Interfaces (APIs). Widely seen as front runners among ways of implementing the third party interface that PSD2 requires, the wide introduction of Open APIs is also predicted to stimulate the ASPSPs and TPPs they connect into generating new and convenient products and services tailored to changing user needs. This will benefit both PSUs and all payment service providers involved, helping them retain existing and win new customers and build new revenue streams.

Preparation, preparation…
Clearly, building (or buying in) a third party interface and implementing 2-Factor authentication require substantial investment in time and resources. But these are not the only areas needing attention. Many organisations may be surprised to learn how much work is involved in complying with the Guidelines on security measures for operational and security risks, and the Guidelines on major incident reporting, under PSD2. Both are more detailed and more comprehensive than the previous Guidelines on the Security of Internet Payments.

TPPs arguably have even more to comply with, as they have to comply with Guidelines on authorisation, registration and professional indemnity insurance, as well as all those applicable to ASPSPs. PSUs, on the other hand, need make no major adjustments, but will reap benefits from Day 1, for example through changes concerning value dating, and enhanced consumer protection.

More than just regulatory compliance
PSD2 is set to revolutionise the European payments market, opening it up to new players and technologies. The widespread use of standardised Open APIs will eventually result in a multitude of new value-added services for customers. Payments, across an array of devices and platforms, will become faster, safer, more reliable and convenient. Payment customers will have routine convenient access to information from their accounts with different institutions.

And soon, similar developments will extend to other banking services, with customers for example accessing stock portfolios, monitoring online securities transactions and managing borrowings all in one place.

In this new innovative ecosystem, the winners will be those who can exploit the full potential of Open APIs, leveraging their existing assets and collaborating with new partners. To get onto this springboard, however, they must be PSD2-ready.