Smooth and seamlessuser authentication should be a priority in Open API design

By Emilie Casteran, Head of Digital Strategy, Banking and Payments, Gemalto

For banks across Europe, the PSD2 clock is now well and truly ticking. Late last year, the European Commission issued its final draft of the RTS (Regulatory Technical Standards) that supports the new directive. Assuming it is approved by the European Parliament and Council, stakeholders now have clear sight of what is required, and when. However,the RTS does not define how to design the newly required direct interfaces.

In meeting the challenge of complying with this new regulatory framework, it is vital banks ensure a high level of interoperability and do not lose focus on the end user experience. In particular, this means relying on standards that combine the efficient access to account holder data for PISPs (Payment Initiation Service Providers) and AISPs (Account Information Service Providers) that is required by PSD2 with a smooth authentication process for consumers.

In agreeing the final draft of the RTS, one of the most contentious issues for the Commission to resolve was the precise means by which TPPs (Third Party Payment Service Providers) such as PISPs and AISPs would be provided access to bank accounts. Ultimately it has come down in favour of Open APIs(Application Programming Interfaces). These will need to becreated by the banks, be free of charge for TPPs to use, and subject to stringent service level requirements. The alternative, screen-scraping, is still an option, but primarilyas a fall-back for banks that fail to meet the necessary deadlines or performance targets. What’s more, the Commission expects Open APIs to be up and running six months before the RTS comes into force. Assuming a vote in the next few weeks, that gives banks a target date of March 2019.

Whilst the RTS defines the goals for Open APIs, they do not specify the detailed technical implementation that banks should adhere to for achieving them. And in deciding which route to go down, banks are not short of options.Standardization initiatives include the UK Open Banking Working Group, which was quick off the mark in unveiling its Open API specifications over the course of last summer. Subsequently, the country has also led the way in terms of the recent roll-out of AISP APIs, which are being piloted by the top nine banks. In France, a similar initiative is being driven by STET, the payment processing body owned by the country’s six leading banks. The Berlin Group, meanwhile, is a broader,processor-led initiative that aims to create a pan-European standard. National initiatives are also underway in Eastern Europe. Moreover, it should be remembered that a number of banks pre-empted the arrival of PSD2 and have already launched Open APIs to their own specifications.Finally,the API Evaluation Group kicked-off at the end of January,overseeing the implementation of API specifications and paving the way for further harmonization.

Each bank’s final decision will inevitably be shaped by a number of issues, including domestic context, wider corporate strategies and more detailed technical considerations. However, in the race for compliance, there is a real danger that banks will overlook the most important factor of all – the customer. In particular, banks need to consider how best to design an SCA (Strong Customer Authentication) solution that facilitates the work of AISPs and PISPs without compromising either the user experience or security.Of course, we are still in the early days of standards development, and different approaches to the issue are evolving rapidly. However,in broad terms, there are three clear options for SCA. These are known as redirect, decoupled and embedded.

With redirect, the TPP reroutes the end-user to the bank’s website. The ASPSP manages the entire SCA process, leveraging a hardware or mobile authentication method, before redirecting the user back to the TPP. As the name suggests, decoupled is an out-of-band process, fully controlled by the bank and leveraging its mobile authentication app. In contrast, with an embedded solution, the SCA is executed through the TPP interface. The bank generates a challenge that is sent back to the user for ‘signature’ through the TPP interface and verified by the ASPSP.

Of the three, there is no doubt that redirect represents the quickest and most straightforward solution for banks to implement. What’s more, at present it is the only one defined in all the leading standards initiatives. But in terms of the user experience, it is also the clumsiest. Indeed, in the long run, it might be considered incompatible with the requirement, set out in PSD2, that banks do not obstruct the experience offered by TPPs. In the short term it may be necessary for banks to utilize a redirect solution to meet pressing compliance deadlines. However, those seeking to optimize the customer experience should also target a seamless embedded implementation.

Digitalization and the emergence of the FinTechs have already changed the rules of the game for established banks. The implementation of PSD2 simply adds greater momentum to the on-going Open Banking revolution. PSD2 also confirms, once and for all, that banks must accept AISPs and PISPs as a fact of life and favour opportunities to co-innovate;by making it harder for customers to utilize their services, banks will simply undermine loyalty and the ability to attract new business.Moreover, in a world in which connected devices are rapidly supplanting bricks and mortar branches, the SCA process has become a key point of day-to-day contact between banks and customers. So, whilst PSD2 compliance is inevitably going to create some serious headaches in the coming months, it must not be allowed to distract banks from the bigger picture. And at the heart of that isthe need to create SCA journeys which can deliver a real competitive advantage in the brave new world of open banking.