Steve Kirsch, CEO and Founder, Token

There are four things that should now be crystal clear to everyone involved in open banking:

1.   Open banking has arrived. It was the #1 topic at Money 20/20 Europe. Open banking regulations are now appearing in other parts of the world beyond the EU.

2.   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.

3.   There is a lack of standardization. Of the APIs now available, only a handful of banks in the UK and Ireland are using the same API. And they only did that because the UK 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 which 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.

4.   The standards that have been created/proposed leave a lot of room for improvement. The UK 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, it’s critical that points 3 and 4 are resolved. Here’s what I think should be done:

1.   The top banks worldwide should jointly fund the creation of a worldwide open banking standard.

2.   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 micro-payments.

3.   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.

Here’s why:

1.   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).

2.   The best standards are created by small teams of highly competent people working together in close proximity. In contrast, “design by committee” efforts take a very long time 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 non-profits or industry consortiums. Choosing multiple vendors to work together is also infeasible. Great products aren’t created this way.

3.   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.

Finally, the direction given to the selected vendor should include things such as:

1.   The API should be simple and low-level, somewhat analogous to the BIOS layer in personal computers: the simplest possible API which safely exposes the offered banking functionality and which 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.

2.   The API standard should specify things at a high level, e.g. 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.

3.   The API 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.

4.   The API should 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.

5.   The API should be available as a commercial product from at least one commercial vendor so banks don’t have to write it themselves.

6.   The spec should be sufficiently detailed that all implementations operate identically.

7.   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.

8.   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.

9.   The API should not support the use of insecure standards. For example, OAuth2 is fundamentally insecure. It was designed to be insecure because they 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.

10.  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.

11.   The API should be designed to be extensible so it can last for at least 50 years.

12.   The API should support charging API callers for the service(s) provided so that banks can make money, e.g. by secure instant micro-payments that work worldwide.

13.   The API should allow for instantly pushing payments worldwide, not just a local payment push.

14.   There should not be any sacred cows, e.g. directives such as “you should start with the xyz standard and build off of that.”

Following this process will create a solid foundation for building great applications and benefit all parties.