Why every European bank has to provide a safety net for PSD2 APIs
We raised the alarm bells earlier this month that the banks’ production APIs are far from ready – a reality that could threaten the services that millions of consumers enjoy. If they remain poor, then the success of PSD2 could hinge on a safety net that’s built into the regulation. But with no clarity around what this safety net should look like or how it will be applied, there is a real risk it won’t provide the security it was intended to.
This safety net is officially referred to as a ‘contingency mechanism’, and it’s something the banks are required to provide in the event that their APIs can’t be reliably used or if they choose not to develop one. It provides third parties with ‘direct access’ to financial data, using the same online or mobile interface that customers use today – with the user’s consent and authentication, of course.
But with less than two months to go before the deadline, the entire industry – banks, third parties and regulators – is facing a significant problem.
The bank APIs that are available are not production-ready. From our recent analysis of production APIs in 12 markets across Europe, we found that just 69% are available. And of those, none currently meet the regulatory requirements for integration. This doesn’t give third parties the required three months of testing they should be entitled to, and despite the banks’ efforts, there isn’t enough time to make the necessary improvements by 14th September.
We’ve run out of time.
To avoid a cliff-edge scenario that disrupts the services millions of customers rely on and use today, we’re calling for a industry-wide consensus on what the safety net should look like. In addition, we are advocating that all banks – regardless of their API readiness – should offer a safety net starting on 14th September and continue to do so until their APIs are up to speed.
A ‘contingency mechanism’ is what, exactly?
The Regulatory Technical Standards (RTS) that are written into PSD2 are supposed to provide detailed specifications around this safety net the banks are required to offer. However, it is too loosely defined – and is widely considered to be two different things.
The formal fallback – the ‘contingency mechanism’ – includes several pain points for banks. It requires full documentation (the same kind they’re required to provide for their APIs), as well as a mandatory three-month notice period for third parties if the banks want to change anything in the fallback. They don’t want to have to provide this.
Then the law also refers to ‘contingency measures’, which are even more loosely defined, less restrictive, and interpreted in such wildly different ways it defies definition.
This would broadly be the ability to access financial data through the online or mobile banking interface, and the ability for a third party to properly identify themselves to the bank.
What’s the confusion?
Simply put, these ‘detailed specifications’ are not specific at all. Both banks and third parties are making their own interpretations as to what the European Banking Authority (EBA) means by ‘direct access’. And the EBA has stayed silent on the matter.
In the absence of a clarification, everyone involved is left to ask: what is a contingency? What is a fallback? And what is the safety net?
This is a problem.
The ‘exemption’ question
There’s another issue with the safety net – it’s not clear which banks will have to provide it. And that clarity is not coming any time soon.
Under PSD2, banks are able to apply for an exemption from having to offer a safety net. It’s an attractive option. If a bank can prove to the national authority that its API has been “widely used” by and “designed to the satisfaction” of third parties (in the words of the EBA), they can qualify for an exemption from having to offer the safety net.
If a bank has gotten an exemption, then come 14th September third parties have to rely on that bank’s PSD2 API. But if the quality is poor, it will be hard for third parties to continue providing the financial services on which they’ve built thriving businesses.
The national authorities across Europe will make the decisions on which banks are granted exemptions and when – and it’s unclear the exact criteria they’ll use. It will also likely differ between countries.
If banks are judged on the availability of their API – rather than the quality – banks without fully functioning APIs could get exemptions, a worrying prospect. And there is little time for third parties to know what the situation will be on 14th September – or how to prepare.
A consensus is needed
Right now, what the industry needs is consensus on the safety net – both for how it lets third parties continue accessing data, and the banks that are required to offer it.
From the third-party perspective, it can either be a formal ‘contingency mechanism’ or the more informal ‘contingency measures’. To us it does not matter, as long as we can continue to reliably operate our businesses the way we have done for the last seven years and provide the same quality services.
However, the safety net needs to support all user interfaces – both online and mobile – and not just one. And we need to be able to identify ourselves using the required eIDAS certificates. To offer that kind of safety net, the banks would not need to do anything more than what they currently do. But at the same time, it cannot deliberately be blocked.
Keeping the customer experience safe
There are a lot of closed-door meetings going on to find a way forward for both third parties and the banks.
But in the end, what we all care about is one and the same: avoiding a situation in which the customer experience is disrupted or broken. As an industry, we have to do whatever it takes to avoid this cliff-edge scenario on 14th September.
We believe an agreement is needed on these two things:
Banks provide a safety net that allows third parties to continue accessing data in the same way they always have, including standardisation of how the eIDAS certificates should be used so third parties can identify themselves to the banks. This will ensure the continuity of services to customers across Europe, give banks the time needed to improve their APIs, and allow third parties to implement those better-quality APIs.
Regulators create a transitional period starting 14th September, during which banks coordinate with third parties if they plan to introduce new authentication measures (Secure Customer Authentication).Also, allow third parties to slowly migrate their customer base to these new measures so they can ensure the safety net works.
In order to move towards September with confidence, there needs to be assurances that the industry can preserve and protect the customer experience.
There are many ways in which PSD2 could fail. But the biggest of all would be if the financial services that customers have come to rely on and enjoy stop working – and stop bringing them value.
More in Open banking
2024-11-19
12 min read
From authentication to authorisation: Navigating the changes with eIDAS 2.0
Discover how the eIDAS 2.0 regulation is set to transform digital identity and payment processes across the EU, promising seamless authentication, enhanced security, and a future where forgotten passwords and cumbersome paperwork are a thing of the past.
Read more
2024-10-08
6 min read
Lending essentials: how enriched data solutions help lenders tackle constraints
Enhancing your affordability assessment with Tink’s data-enriched solutions helps you put an end to inaccurate data, prevent fraud in loan origination and stay compliant – read on to explore the benefits.
Read more
2024-09-24
4 min read
Why Pay by Bank fits luxury retail like a glove
Pay by Bank offers a solution that addresses the potentially higher transaction fees and fraud risks while enhancing the customer experience for luxury retailers.
Read more
Get started with Tink
Contact our team to learn more about what we can help you build – or create an account to get started right away.
