PSD2: the implementation challenges

In Europe, the Payment Services Directive’s second draft (PSD2) and the second wave of the Markets in Financial Instruments Directive (MiFID II) are fast approaching. The ever-increasing onslaught of regulation poses challenges to firms that must comply – from both a cost and technological challenge perspective.

There are plenty of financial technology (fintech) and regulatory technology (regtech) vendors popping up that can help with compliance. However, treasury and risk departments must give careful consideration to choosing the right vendor to help streamline their compliance activities reasonably quickly and effectively so they can get on with business as usual.

The major banks that offer retail banking must meet the PSD2 go-live deadline on January 3 2018, seen by many as a very aggressive timeline. After this time, the directive must have been transposed to national law within current EU member states (which the UK is a part of until March 2019 – according to expected Brexit timelines).

Under the new PSD2 legislation, account servicing payment providers (AS-PSPs) will be required to provide access to third party providers (TPPs) to their small and medium enterprise (SME) customer accounts for payment initiation and/or account information. No mean task, considering there are currently over 4,000 banks viewed as AS-PSPs in the UK and Europe.

The significant operational and technical changes that banks will need to make to be compliant by the 2018 deadline pose some serious challenges.

Adoption challenges

Among the first challenges in adopting the new regulation, is understanding the overlap of the retail/SME accounts within PSD2 and the open banking initiative in the UK. There still needs to be clarity on this overlap, and clarity around the interpretation of the regulatory technical standards (RTS) for PSD2.

This is particularly onerous and difficult to achieve, as PSD2 will be in effect just months after the final the RTS comes into force. The recently-launched UK Competition and Markets Authority (CMA) implementation entity aims to address possible issues arising from the two independent, but functionally-aligned initiatives.

Another key issue is the standardisation around the application program interfaces (APIs). For example, will there be a single design for key payment information (PI) and account information (AI) for APIs? In a European Banking Authority (EBA) consultation paper published last August on the impact areas of PSD2, and in the responses, one of the key concerns raised was the potential impact of a lack of minimum specification of API for access to account (XS2A) services.

Furthermore, the CMA has said that UK APIs must be compatible with the major European open banking initiative, making standardisation an important consideration. European Banking Authority (EBA) chairman Andrea Enria, in a statement made to the EU Parliament’s committee on economic and monetary affairs last November, aimed to clarify how the RTS will reflect feedback to the consultation paper. Yet doubts remain on whether the final RTS, expected to be published by the end of this summer, will satisfy the differing concerns of the wide range of stakeholders in PSD2.

Technical and other considerations

In addition to the challenges of adoption, there are other considerations and technical challenges that also must be taken into account when implementing PSD2-compliant systems. The first is the EU General Data Protection Regulation (GDPR) which comes into effect in May 2018. The aim of this regulation is to ensure secure processing of personal consumer data. There are big penalties for non-compliance (up to 4% of global turnover), so it needs to be planned for, as open APIs by nature are exposing consumer information.

There are also fears over who is liable when transactions fail. Banks are worried that TPPs will have access to customer data with no formal contracts in place and no clear responsibilities if there is a security lapse, and there is also the concern over payer negligence. On the other hand, TPPs are concerned about having to go through multiple certifications from different countries unless there is a standardised approach. This raises another question – will directories of TPPs be managed on a pan-European level, or will national directories be interlinked?

Additionally, under PSD2, banks are responsible for strong customer authentication (SCA), which must be factored in when architecting a new system. Market participants are expressing some concern over the implications – and exemption rules – on implementing SCA as it’s defined in the draft RTS, and how a poorly-designed 2 factor authentication system may cause friction to payment processes and, in turn, impact merchants. Some other areas of concern for banks include the processing of “one-leg-out” transactions, where a PSP to the payer or payee resides outside the EU; complaints and dispute resolution; the definitions of the type of bank accounts in scope; and how customer “sensitive data” is defined.

On-going work

In Europe, there are several working groups actively looking to develop standards and the ancillary services. For example, as well as the aforementioned CMA Implementation entity, pan-European standards initiative The Berlin Group is working on a draft of PSD2 compliant standards that are also compliant to the principles of the single euro payments area (SEPA). The group is also working closely with Payments UK, among other industry groups, to look at PSD2 roles, use cases, standards and data flows.

At the same time, The Deutsche Banking Industry Committee ‘Kreditwirschaft’ (GBIC) has set up an implementation group for PSD2 specifically for banks across Germany, Switzerland and Austria. Their work is focusing on defining the approach to governance, standards, secure communications mechanisms, and creation of TPP/AS-PSP directories, similar to the work that the UK implementation entity is doing.

It’s great to see so many active working groups, although as with anything where several bodies are working on the same project, there is the chance of interoperability and fragmentation issues. To overcome this, the Convenient Access to Payment Services (CAPS) industry consortium is working on an open technical framework for PSD2, and the concept of aggregators that enable TPPs to secure easier access to varying APIs as published by AS-PSPs. Similarly, EBA subsidiary PRETA is looking to offer a directory service on certified TPPs – and AS-PSPs).

Getting ahead of the game

The onus should now be on banks worldwide to ‘tool up’. Choosing the right data integration tool that promotes agility (speed and flexibility), that is easy to use, involving configuration with minimal programming, is a key objective that needs to be met by the institution.

The most challenging aspect of PSD2 will be the integration of the APIs to the potential plethora of internal specialised banking processing applications. Integration protocols will likely vary significantly – some may be modern applications while others might be old and obscure. Because of this, banks will need platforms that flexibly connect to API components and can handle a multitude of formats and messages related to each new service that is exposed.

Sourcing technologies that can ease the integration of components such as APIs will help your enterprise gain traction in the new open banking environment; with the right solution that offers a comprehensive data integration capability, you can ultimately deliver streamlined agile compliance regardless of the challenges presented by PSD2.

Comments are closed.