Open banking's global sweep will stall without an open tech standard
As regulations appear outside of the European Union, it is time for a serious open banking standard.
There are several things that should now be crystal clear to everyone involved in open banking. Open banking is so irresistible that even banks that aren’t required to adopt open APIs are doing it voluntarily. Wells Fargo, for example, has implemented APIs to support over 20 use cases that it thought were compelling.
There is a lack of standardization. Of the APIs now available, only a handful of banks in the U.K. and Ireland are using the same API. And they only did that because the U.K. regulator required them to do so.
But each bank implemented the standard differently. This lack of standardization is bad for everyone: It increases costs and complexity at each bank, it opens the door to insecure solutions that expose banks and their customers to unnecessary risk, and it hinders adoption by software developers who only have bandwidth to write to one or two open APIs at the most.
The standards that have been created/proposed leave a lot of room for improvement. The U.K. open banking API, for example, is only usable by human beings, and it took about two minutes and 15 screens for a typical human to approve a simple access request. None of the standards allow for charging the caller a fee. The Berlin Group standard is very complex.
If open banking is to reach its full potential, here's what should be done. The top banks worldwide should jointly fund the creation of a worldwide open banking standard. The creation of the API should be done by a commercial vendor selected by the banks. Presumably, it would be a vendor that specializes in open banking APIs and also has expertise in secure, instant micropayments.
The chosen vendor for the API design should seek input from all parties in the ecosystem: business, consumers, banks, service providers, software developers, system integrators, regulators, security experts.
To be a global standard, it’s really best that it starts with global support. Trying to take a single region/country standard and get other countries to adopt it is harder (especially one that has been designed by committee).
The best standards are created by small teams of highly competent people working together in close proximity. In contrast, “design by committee” efforts take long to come to fruition and the results are generally subpar. For example, all the computer platforms we use today to develop software on desktop and mobile devices were all created by commercial vendors, not by nonprofits or industry consortiums. Choosing multiple vendors to work together is also infeasible. Great products aren’t created this way.
Getting input from all stakeholders is not controversial. Importantly, however, this doesn’t mean the vendor should accept it all blindly; good design is always an iterative process and input is often conflicting.
The API should be simple and low-level, somewhat analogous to the BIOS layer in personal computers: the simplest possible API that safely exposes the offered banking functionality and handles authorization and consent management in a consistent, secure manner. This would enable vendors implementing other open banking API specifications to build on top of this core layer. For example, the OFX standard has worked very well over time for data and it is very simple. By contrast ISO-20022 is very complex. We should always be asking: Do we need this complexity at the core layer? More often than not, the answer is no.
The API standard should specify things at a high level, for instance a payment request that can include meta data, and let the meta data itself be self-describing. Higher-level APIs could translate the meta data to/from a variety of formats.
It should be fully open and not assume a particular style of API access. For example, it should not specify the interaction between a PSU and PISP/AISP; that should be out of scope. The API should assume the callers are evil and not compliant with any regulations. For example, Bitcoin and Ethereum are designed to be callable by anyone and it works extremely well because the security is built into the architecture. The API should also be easy to read, understand, and use by programmers. For example, Plaid and Stripe APIs are examples of APIs that are easy to understand, well documented, and easy to use.
The API should be available as a commercial product from at least one commercial vendor so banks don’t have to write it themselves. The spec should be sufficiently detailed that all implementations operate identically. The back end of the API server should be easy for a bank to implement. For example, Token offers banks a full PSD2/RTS compliant API including very sophisticated consent management, yet a bank only has to implement eight simple API calls.
Additionally, the API should use modern security and software methodologies for authentication and authorization/SCA. There must be no shared secrets between the owner of the account and the bank.
It should not support the use of insecure standards. For example, OAuth2 is fundamentally insecure. It was designed to be insecure because the designers wanted it to be easier for programmers to implement. Sadly, we see OAuth2 specified in pretty much every open banking standard proposal. This is a huge mistake; basing open banking protocols on OAuth2 is a recipe for never-ending security problems for the next 50 years.
The API should work for retail as well as corporate applications. For example, the API should not assume that there is a human being/user interface making the transaction; it should be computer to computer. Human interaction should be layered on top of the API, not designed into it. The API should be designed to be extensible so it can last for at least 50 years. And it should support charging API callers for the service(s) provided so that banks can make money, for example by secure instant micropayments that work worldwide.
Finally, it should allow for instantly pushing payments worldwide, not just a local payment push. There should not be any sacred cows, such as directives to “start with the xyz standard and build off of that.”