In reading up on Open Banking, we recently came across an interesting letter from Olivier Guersent, the European Commission’s Director‑General for Financial Stability, Financial Services and Capital Markets Union to Andrea Enria, the Chairperson of the European Banking Authority (EBA).
The fact that such personages are exchanging letters about APIs tells us something about their perceived importance in the present and future worlds of open banking. And, tellingly, M. Guersent’s views about how to manage APIs are aligned with the recommendations of best practices that we at APIContext have made.
The letter states:
It is not possible for EBA or the Commission to anticipate all possible problems with APIs, and to specify in the RTS [Regulatory Technical Standard] how they have to be addressed. We will therefore have to rely on market players to develop together APIs that work for all sides – banks, third party providers (TPPs) and payments services users.
Banks and other service providers can adopt published standards, such as the Open Banking API standards for UK banking, the Berlin Group NextGenPSD2 Framework, the Open Bank Project, and payment services standards built directly around ISO 20022. It is then up to the institutions that consume and expose APIs, working with regulators, to keep one another honest by making sure that the APIs really do what they say they’re going to do.
Keep ’em honest
The letter continues:
The best way in which we can help national supervisors is by supporting this work by market participants, ensuring that they identify and solve problems themselves at an early stage and sparing national competent authorities (NCAs) the difficult task of investigating problems with APIs. This could be much heavier than granting exemptions from having to adapt the online banking interface as a fall-back option for TPPs. Banks will make their APIs available, TPPs will use them and if there are no complaints about them, NCAs grant an exemption, after having informed EBA of their intention to do so. All this should be a very smooth process if the work of the API standards evaluation group is successful.
This is a key phrase and needs some thinking about. What constitutes a complaint? Who adjudicates those complaints? How do you determine if a complaint is valid?
Essentially, as we have said frequently here, without a common framework and understanding about what constitutes a “good” or “acceptable” API, it might be challenging indeed to reach an agreement.
So key here is the work of the API standards group and what they conclude. We believe that something like our CASC standard for API performance quality takes a lot of the guess work out of the process – but others might disagree.
If you are interested in seeing some quality reports for APIs in the financial sector, feel free to sign up for our free service here. Or download our free white paper on the challenges of API monitoring in the financial sector.
