This is the second piece in an ongoing series called Tink Thinks: Inside the EBA, where Tink’s experts explain and comment on the business of the European Banking Authority’s (EBA) PSD2 API working group, which is helping to ease the implementation process ahead of the September deadline.
The series Tink Thinks: Inside the EBA is part of a broader public policy effort at Tink to advocate for third-party providers (TPPs), so that the possibilities for innovation are broadened ahead of the September PSD2 deadline. Tink take you deep into the EBA’s PSD2 API working group to talk about the progress that’s been made – and offer an explanation about how it impacts the industry.
Since Tink last blog, the EBA has published two further clarifications on the topics of API performance and support (Issues IV-VII), as well as eIDAS certificates and clarification on the EBA’s use of the term “widely used” (Issues VIII-XIII).
On the whole, there have been a number of important clarifications. But how effective and useful these will be is in the hands of the national regulators enforcing PSD2.
Here are the most recent EBA clarifications and what we think about them:
API quality needs to increase
The EBA reiterated that the APIs released ahead of 14th September deadline need to be as good as – or better – than the payment service user interfaces the banks and financial institutions currently have. They reject the view of some banks that these interfaces are not comparable.
Given that after 16 months of operation, the APIs in the UK are still hovering at just above 95% uptime – well below the industry standard and expected uptime of +99.9% for user interfaces – it is unlikely that many APIs can reach the threshold anytime soon.
The EBA also clarified that banks and financial institutions should actively try to cooperate with third parties for testing purposes, and they cannot reject third parties that have not obtained their PSD2 licenses yet.
Little prospect for exemptions
In the annex of this document, the EBA collected and published the exemption timelines for all countries – the time by which all banks need to apply for an exemption from creating a fallback mechanism, when to apply, when to have production APIs and more.
A quick primer: the fallback mechanism is required by the EBA to ensure that third parties have a reliable way to access customer data in the event that they can’t get it through the bank’s PSD2 APIs. The banks need to meet certain conditions to qualify for the fallback exemption – which would help them avoid investing even more in this alternative way for third parties to access data.
In the end, if they can’t provide third parties with the data through well-functioning APIs, they need to provide it another way.
The EBA now says that banks need to have a dedicated interface (API) that has been “widely used for at least three months” – by 14th September deadline – to get exemption from the fallback.
But based on the current state of the banks’ testing and production APIs, it is unlikely they will be ready or get the exemptions. It means they’ll need to make additional investments – as well as “a strategy and plans” to prepare that fallback mechanism.
“Wide usage” means what exactly?
What remains very concerning is the EBA’s ongoing mixup of the terms “wide usage” and “available for wide use”, which are of course not the same thing at all.
We need to count on the national regulators not to exempt any non-used, non-tested, bad APIs just because they were advertised broadly.
No need for banks to check passports
The EBA also collected and published a list of national authorities planning to follow their suggested process – which most of them will – for revoking third-party licenses (see the Annex here).
There were long discussions on the topic of passporting the account information (AISP) and payment initiation (PISP) licenses of third parties. The EBA is now stating that banks are not legally required to check the passporting information – the permission third parties have to use their licenses in European countries outside of the issuing one – and should not block access to an account because that info isn’t available.
TPP should be able to identify themselves
There was also a significant development regarding the use of eIDAS certificates, the standards for electronic identification in EU. In the case of PSD2, everyone from banks and financial institutions to the third parties need to have these certificates.
The EBA came out and said that banks who are applying for the fallback exemption must support the use of eIDAS certificates by 14 June – the first time they have specified a due date for supporting the certificates and one that is rapidly approaching.
Very few APIs will be compliant
In the coming weeks, Tink will be publishing a follow-up to our piece on the 41% of European banks that missed 14th March deadline to release testing environments. In it, we’ll detail our experience with testing environments across Europe.
But we can already say now that if the guidelines we discuss above are applied strictly by the regulators, there will not be many (if any) APIs that will be exempted from creating a fallback mechanism.
Tink sincerely hope that the EBA API working group can now tackle some of the more fundamental issues that are still outstanding – issues like redirection, account-holder data, 90-day renewals and more.
About our authors:
Tomas Prochazka, our VP of Product, is a member of the EBA working group, representing TPPs. Our Executive Advisor Ralf Ohlhausen is a member of the European Central Bank’s Euro Retail Payments Board, and vice-chairman of the European TPP Association (ETPPA).