July 21, 2019 | Louise Basse
With less than three months to the final PSD2 deadline in September, the clock is ticking away faster than ever.
As of June this year, banks are required to have their production APIs ready — and that means it’s time for third parties to start using the banks’ APIs.
And why is that so interesting?
Essentially, it’s time for banks to demonstrate the quality of what they’ve built. If the maturity of the production APIs lives up to the expectations, banks can apply for a fallback exemption from the local FSA.
But what are the expectations of these APIs? And what is the reality?
Having spent the last three months testing the banks’ APIs, we believe they’re far from mature and production-ready.
In this first edition of the series PSD2 and beyond, we explain why we believe no banks should get a fallback exemption by September.
So. Is the quality of the banks’ production APIs good enough for businesses to rely on? And why is it actually important for banks to build fully-featured APIs?
Well. In reality, banks will be major consumers of the production APIs themselves.
Having access to account data from other banks is a huge benefit for banks, as they can build new features that enable consumers to manage their finances from any account in any bank.
Therefore, banks risk to harm themselves if they don’t take the proper time to build sustainable APIs that are ready for production.
Put simply: Banks will gain most from fully-featured interfaces.
… And the same goes for the banks’ dedicated interfaces. It takes time to build robust APIs that live up to the expectations.
Unfortunately, this means that the hundreds of APIs we’ve tested during the wide usage period are widely immature. Put simply, the interfaces are nowhere near as robust as they should be.
This is especially clear in parts of the documentation that has crucial importance for the stability and the overall user experience. The same stability is also affected when it comes to the downtime of the APIs.
A UK survey from May this year shows that the UK’s largest bank, HSBC, only had an uptime of 20 percent of Q1 in 2019.
So. Let’s say you’re creating a financial service that fetches data from your customers’ bank account. Needless to say, it will have a negative influence on the quality of the service you’re building if you can only fetch data 20 percent of the time.
If banks are granted a fallback exemption, third parties can no longer expect to be redirected to a fallback mechanism.
Leaving no other alternative than to use the banks’ immature APIs, such a fallback exemption could bring serious harm to the Open Banking project.
In addition to the downtime of the banks’ production APIs, it is also important to discuss the quality of the data that the banks’ API’s are providing.
According to EBA guidelines, banks are required to deliver the same data quality to third parties as they provide to their customers through their own services.
But as we’ve tested the banks APIs for the past three months, we’ve noticed that basic transaction details such as transaction amount, balance, text, and date of transaction are missing or exist in better quality in the banks’ own services.
As banks have been the safe holder of financial data for hundreds of years, it makes sense that there has been some doubt about who should handle the consent part of PSD2.
But as the EBA’s guidelines state, banks are never responsible for handling customers’ consent.
To be fully compliant with EBA’s Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA), banks must never ask for consent. It’s only up to the third party provider to prove that they have the consent of the customer to fetch data or initiate a payment.
As banks are moving into new technical challenges and spend huge amounts of resources to become PSD2 compliant, we hope that the bank industry can use our experience to tackle some of the big issues that are still outstanding.