ABSTRACT: Since Jan 2018, banks are obliged by an EU regulation to publish open APIs. These APIs are meant to empower people across the EU to make use of their own banking data as they like, with the help of trusted third party apps. The regulation not only imposes that such APIs exist, but it is also providing requirements for their quality, so that they become “widely used”.
In the near future, banks will start being ranked by the quality of their open APIs. Find out, in this article, the 4 quality matters.
The Application Program Interface (API) allows data to flow between different software programs so as they communicate without human interaction. APIs could be perceived as a dialogue between two applications: once switched on, one app starts by asking a question to the other and this one responds with the requested information. When the trigger is switched off, the dialogue stops. But more importantly, there is always a beneficiary of that information exchange, a person or a company, who can control the dialogue.
More and more people and companies use their bank’s apps to access their bank accounts balances, transactions and perform payments.
As of 2018, the European Revised Payments Directive PSD2 ensures that customers have the right to also use other apps to benefit from these facilities. These third party digital services are offering account information services (AIS) and payment initiation services (PIS).
So far, the APIs have been deemed to be the most suitable channels to enable this task and hence have spurred different initiatives around the standards governing them. The most common ones in Europe are Berlin Group, Open Banking UK, PolishAPI and STET etc. It is therefore clear that since there is not a single standard to abide to, data receivers might struggle to obtain the aforementioned data.
Irrespective of the API standard being used by a certain bank, it should make sure that the data can be accessed, consumed and reported upon within certain levels of acceptability.
The European Banking Authority (EBA) has issued a report (EBA/GL/2018/07) that includes the guidelines around compliance and reporting obligations for API owners under PSD2. In other words, EBA is willing to remove the unnecessary frictions arising from bad API implementations. More so, EBA goes further to say that it empowers National Competent Authorities (banking regulatory bodies) to strictly monitor the status of the PSD2 APIs in their respective territories and to impose fines where and if applicable (EBA Opinion, February 22nd 2021).
There is a deadline to comply with EBA’s guidelines at the end of April 2021. Certain national authorities have communicated even shorter deadlines. That was the case of the National Bank of Romania who agreed March 31st to be the target date for API compliance. NBR has also mentioned that it encouraged third party providers (TPPs) to signal any issues they found in the process of local bank data consumption.
We believe there will come a time when banks will also be ranked by the quality of their APIs (think league tables in investment banking). Below are the 4 main guidelines for assessing the quality of an API, following the EBA report and structured according to our view on the impact of APIs efficiency and adoption.
1compliance — does the bank API exist? Does it respond to requests?
Availability & performance — the API should match the best KPIs and service level targets across all the bank’s customer facing interfaces
Publication of statistics — a requirement for banks to monitor and publish their availability and performance data on a quarterly basis for the use of both the national regulators as well as TPPs
2usability — can the API be used according to its purpose? How does the API technical experience look like?
Errors — daily errors response rate; error messages clarity
Design of the API — evidence that the API meets the regulatory requirements under PSD2 and RTS; this may be achieved by demonstrating the implementation of and the deviations from an open API standard initiative
TPPs feedback — EBA strongly encourages TPPs to test and use the banks’ dedicated interfaces as well as provide feedback to banks, in order to allow the them to correct the problems identified, with the end goal of supporting the development of high-performing dedicated interfaces that facilitate innovation and competition and deliver positive consumer outcomes.
3 experience — what are the obstacles (EBA opinion, June 2020) that may prevent, according to EBA, the API adoption on a larger scale? How does the end user experience look like?
Redirect — for enabling the user to provide its consent to data retrieval from its bank account, the bank should provide a simple flow of redirect to the banks’ page, authentication and automatic redirect back
No of necessary steps in the consent flow — the bank should not impose any additional steps as compared to those required for the use to log in their digital app, such as extra checks or approvals, be it for personal or corporate accounts
Account selection — APIs that require users to manually input their IBAN into the banks domain in order to complete their consent are an obstacle.
90 days consent validity period — EBA advises National Bank Authorities to encourage all banks to make use of the RTS Article 10 exemption, by supporting ongoing 90-day access without a new authentication.
4 usefulness — can the API be relied on in a variety of use case serving the purpose of PSD2 of enhancing competition, facilitating innovation, protecting consumers (EBA opinion, June 2018)
Available data: the API should allow users to have access to the maximum amount of data available to them regardless of the electronic channel used to access it, accordion to RTS, in Article 36(1)(a)
Frequency of data refresh — the API should allow users to refresh their data as many times a day as they wish, when they are triggering this refresh themselves. If they are not directly involved, the refresh can pe performed by the app automatically 4 times a day, according to RTS, Article 36 (5) (b)
To conclude, PSD2 is not “yet another piece of regulation” since it is a building block in the data democratisation process. The long term implications for open finance and systematic automatisation are way too important. Still, in the short run, more has to be done to improve the quality of the banking APIs. They do matter. At Finqware, we are happy to help.
** For the purposes of simplicity, account servicing payment service providers (ASPSPs) have been substituted with “bank(s)” in the material above.
