Those affected by the second payment services directive (PSD2) have a set of rules to help guide them on their compliance journey.
These are the regulatory technical standards (RTS).
Banks in the EU are the most impacted. If you run an account on behalf of a customer, you need to enable third parties (TPPs) to aggregate account information and initiate payments on that account through an API. Those third parties who use these services are called PISPs and AISPs. This, of course, includes banks who can also use the APIs of other banks, fintechs and any other third party providers (TPPs) whose business is payments transactions or includes payment services.
The key aspect that sets PSD2 apart from its predecessor, the first payments services directive, is that it stipulates financial services providers open their APIs to allow third-party access. Until now, banks have held their data close and no one else was allowed access to it. Many have operated on decades old legacy systems with internal servers meaning that even if they thought open banking was a good idea, embarking on the project was seemingly quite difficult.
But now, all banks have to create open banking in so far as their customers’ account data and the ability to initiate payments must be available to those authorised to access it.
Right. As mentioned in the introduction, the RTS are a set of rules aimed at creating a consistent implementation process – i.e. ensuring parties interpret the directives in the way they were intended and eliminating any confusion around possible loopholes. The security measures and guidelines within the RTS become applicable September 2019. Why is that? It’s because the banks, and other interested parties have been allowed to join the EBA in their work to form the RTS. So, when PSD2 becomes legislation on the 13th of January in all EU states, the law requires all banks to adhere to the RTS 18 months after this date. This brings us to September 2019.
The RTS makes it clear that most screen scraping practices will be banned – in all but very few circumstances. Read this interview with Bird & Bird’s Scott McInnes for more information about the very limited exceptions. The European Commission’s press release on the subject said: “With these new rules, it will no longer be allowed to access the customer’s data through the use of the techniques of “screen scraping””. Instead those wishing to gain customer account access must do so through the proper channels.
This is good news for the bank as it puts them in control in terms of having the ability to know who is accessing their customer’s data, when and what they specifically get access to. If they have a robust API in place, they don’t have to worry about the risk of screen scraping at all. They have much more control about the specifics of what data they’ll provide access to – despite having to give over the data in the first place, for free.
The intention of PSD2 from the outset was to set out stricter security requirements around electronic payments to better protect the public’s financial data and reduce the risk of fraud. All whilst enabling innovation, competition and lower-priced services for consumers and businesses.
The RTS explains how this works in practice. “Strong customer authentication” (SCA) is the process by which account access and making payments takes place. Users will have to complete a strong two-factor authentication to grant third parties access their accounts. The common practices around authentication under SCA don’t differ much from the in-store processes which take place today in most of the EU. What differs is that these rules require the same process to work digitally through APIs enabling data exchange and payments to happen in virtually any situation, inside apps, on websites and tied to new payment cards. Many online and app payments aren’t currently subject to such a strict authentication processes, potentially making cards the easiest options for a while more.
SCA usage will become mandatory in September 2019. This gives those affected – all payment service providers – enough time to ensure their security systems meet the requirements outlined in PSD2.
Whilst this directly affects payments providers and merchants, the banks must ensure the necessary infrastructure is in place to facilitate the new requirements. They must look at and ensure that fraud management practises are robust. The technical standards also say that merchants and consumers will need training and information about how to operate in this new environment.
To date, we haven’t seen much consumer-friendly PSD2 information coming from banks. This may be because prior to having any new channels in place or indeed, knowing the full effects of how the changes will impact them, they’re not wanting to share information without a “this is what you do next” plan in place. Once banks have their new channels operational, it would make sense for them to be the educator about the new requirements at the same time as marketing their new systems and services available, both to third parties and the banks customers.
If banks want to use PSD2 as an opportunity to create solutions which attract new customers, it would pay for them to do this sooner rather than later as before they know it, there’ll be plenty of consumer-facing information flooding through from competitors and third-parties.
The fact that there’s an 18-month timeframe for proper implementation of PSD2, following the RTS, means there’s a distinct window of opportunity to put a proactive strategy and new channels in place.
Banks, theoretically, have 18 months before they have to expose PSD2 interfaces to third-parties. Of course, if they’re to compete and gain the edge, they’ll be looking to ensure their compliance strategy is nailed much earlier than this, but holding back on launching the API until they have to. Further, many will be considering how competitors and third-parties will use the directive to their advantage and what they can do to get ahead of this. Google, Facebook and Apple have already launched payment solutions that can be introduced to the European market once they have API access. Banks don’t have to expose their APIs right now, as we know, so that means that in Europe they have an 18-month head start on the tech giants wanting to redirect the public’s attention to their own digital channels.
Our advice to banks is that they launch a new digital payments channel, wrapped up as a mobile wallet. This channel can be used by anyone in their region, in any circumstance, and gives unparalleled customer acquisition and new monetisation opportunities. To read six benefits of launching a mobile wallet as a bank, click here.