From a technical point of view, now is the time to ensure the implementation of a dedicated PSD2 interface – for those that have concluded that such is the best way forward. Their focus will most likely be on an API-based approach.
This approach may itself generate a number of highly relevant questions, such as: “What exactly does it mean to create an API-based interface?”, “What are the implications of using APIs?”, and “Does the available PSD2 documentation give me sufficient information on everything that’s involved?”
This article addresses these questions and concerns and is the first in a series covering:
- PSD2 and its technical implications: an overview of current status
- A sample overview of what a technical implementation could look like
- Leveraging the UK Open Banking experience (re: implementation standards)
- Managing the PSD2 APIs
Let’s first have a closer look at PSD2: the revised Payment Services Directive and its current status from a technical perspective.
The revised payments services directive (PSD2) was first proposed by the European Commission in June 2013, adopted by the Parliament in October 2015 and entered into the Official Journal (OJ) of the EU on 23rd December of that year (making it legally binding in all member states). Its ‘entry into force’ (EU jargon for ‘effective from’) was the 12 January 2016 (20 days after publication in the OJ), giving all member states two years to transpose it into national law.1
This year is going to be crucially important from a PSD2 perspective as the date on which it officially enters into force across the EU has now passed. This means that all EU member states should now have PSD2 incorporated in their national legislation. Though not all member states have managed to complete this just yet, the expectation is that they will have done so by the end of the first quarter.
Secondly, and more relevant from a technical standpoint, the European Banking Authority (EBA) has finally submitted the final draft of the so-called ‘Regulatory Technical Standards (RTS) on strong customer authentication and common and secure open standards of communication’ to the EU Council and Parliament, which should formally adopt it by March of this year at the latest.
That means we now have all the information necessary to successfully create a compliant, dedicated PSD2 interface, right? So, let’s get to work!
Well – not quite. How come?
A closer look at PSD2
The essence of PSD2 is that it allows for highly-secured and consented access by Third Party Providers (TPP) to a bank customer’s account information and/or the bank’s payment services. There is general consensus that these provisions will be best addressed by the bank, or Account Servicing Payment Service Provider (ASPSP) as banks are formally called under PSD2, by offering a dedicated interface based on APIs.
Indeed, such an approach may coincide very well with the bank’s digital transformation programs already underway.
As we know well by now, APIs offer an effective way to quickly and securely expose business capabilities to whichever consumer audience they are intended to be shared with. Hence, it makes great sense to look at APIs as the technology of choice for the dedicated interface.
What’s more, the security standards that have evolved around APIs, in particular those safeguarding restricted access (authentication, authorization), appear to fit very well with the security requirements as they are laid down in the RTS.
Or do they?
The RTS describe the requirements with regard to secure communication at a rather high level only. In order to remain ‘technology neutral’, technical implementation details are left open. Yet, in particular from an interoperability perspective, it is clear that standardization is critical for a successful implementation across the board. Though a number of initiatives that are undertaken in this respect can be identified, it remains to be seen which of those are going to be widely adopted, whether they offer sufficient detail and, ultimately, what effect they will have on interoperability.
At a higher level, there is even debate on some fundamental PSD2 aspects, for example the use of redirection in user authentication scenarios, which some claim may not be in line with the RTS or even illegal2.
This leaves us with a situation that is not exactly without risk. Whereas the time for implementation is imminent, we’re still groping in the dark, more or less, as to what to implement exactly. Therefore, it would be wise to allow for significant flexibility in the chosen implementation architecture, ensuring that anticipated modifications can be applied without having a severe impact on the overall work.
That’s it for the first blog, next time I’ll zoom in on some of the technical challenges and implications, and how to deal with them.
For more information on open banking solutions provided by Rogue Wave Akana, read our latest datasheet.