API Evaluation Group recommended functionalities

This article has been provided by Ralf Ohlhausen, Business Development Director at PPRO and member of the API Evaluation Group as well as a member of the ERPB.

Back in January 2018, the European Commission (EC) established the API Evaluation Group (API EG) with the support of the ECB’s ERPB to evaluate standardised API specifications in order to help ensure that those standards are compliant with the requirements of PSD2 and the RTS, and also meet the needs of all market participants. By June 2018, it was supposed to make recommendations aimed towards API specifications convergence on a European level, and to help establish harmonised market practices. National competent authorities (NCAs) have the final say about any compliance matters, but the advice of the API EG was eagerly awaited.

With representatives from all market participants (ASPSPs/banks, TPPs, consumers, merchants, and more) as well as observers from the EC, EBA and ECB around the table, this was not an easy task and everyone following the meeting summaries, which were published on the EPC’s website all along, was probably not surprised that it took a bit longer to come to a conclusion supported by the whole group.

On 9 November, their recommended API functionalities were finally published. Had it just been for the original objective, for instance agreeing recommendations to the API initiatives, such as Berlin Group, UK OB, Polish and Slovakian API, the original timeline would have been met, but it became clear that the most controversial question was not what functionality APIs shall provide, but what part of that ASPSPs are obliged to offer for a) being compliant, b) getting an exemption from providing a fallback to their user interface, and c) really meeting the needs of all market participants.

Several hot topics have been analysed and discussed in great detail and with regard to the probably thorniest one, redirect vs embedded authentication, the API initiatives were advised on in May that both should be supported and also their decoupled variants. Unfortunately, to date, all, but the Berlin Group, have ignored this advice, which means that ASPSPs using any other API are running the high risk of not just not meeting the needs of most TPPs, but maybe not getting the desired exemption and potentially not even being minimally compliant.

The API EG expect the API initiatives to provide all the 38 listed recommended functionalities as a minimum, and thereby allowing their ASPSPs to be relatively safe, compliance wise, but also to go beyond that level, if desired. Some of these functionalities are not explicitly required by PSD2/RTS, but lack of them is likely to create obstacles for existing and/or new TPPs, and hence cannot be ignored, not just from a usage, but also from a legal perspective. The TPP’s original wish list has been cut down to the bone and from their perspective the list now constitutes the bare minimum needed to avoid a degradation of their existing services. Anything less would not just create obstacles, but a complete roadblock for some of them.

Furthermore, it should be noted that PSD2 and the RTS are not the only laws playing into the bank vs fintech disputes, and that both sides should have a vested interest in competing fairly and providing PIS and AIS, which work well, securely and user friendly. Some ASPSPs may be tempted to offer very narrow APIs, but neither the authorities nor their own customers will appreciate such an approach, and going down that route is likely to be a dead end for them.

As a matter of fact, taking the end-user (PSU) perspective has been crucial in overcoming some of the disagreements, because the law was not always driven from that angle, and any remaining room for interpretation, of which there is quite a lot, should be leveraged with the PSU’s interest, and in particular the ease of use in mind. Examples for that would be 1) letting the PSU get their purchase right away, by enabling the PISP to provide reliable payment confirmations (as opposed to just initiations) to the merchant, 2) letting the PSU use their AISP credentials for their 90-day consent renewal (as opposed to renewing every single account at every bank all the time), or 3) letting the PSU add the recipient of their current PISP payment to their trusted beneficiary list as part of the flow (as opposed to doing this before or after the payment separately with their bank).

There is still time to get these, and all the other missing functionalities pointed out in the API EG list into the APIs on offer from 14 March 2019, so that the EU can keep and extend their worldwide lead when it comes to open banking – as opposed to entering a vicious circle of degrading services, disputes and litigations.

About Ralf Ohlhausen

Ralf Ohlhausen, MSc in Mathematics and Master of Telecommunications Business, has over 25 years’ experience in ecommerce, financial services, mobile telecoms and IT. Ralf is responsible for expanding the company’s portfolio and global reach, as well as developing new business areas and partnerships.

About PPRO

PPRO enables integrated electronic payment processing on a global scale spanning the entire payments value chain from acquiring through processing, collection and settlement. Positioned as ‘The Payment Professionals’, PPRO acts as a B2B payments hub, connecting PSPs and other merchant aggregators such as acquirers and processors with local payment schemes.