The Open Banking revolution is, apparently here, but there is a certain lack of excitement, and not everyone seemed to be prepared for what was set to ‘revolutionise’ the financial sector. Steve Kirsch, CEO and founder of Token writes on how to make Open Banking work
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 are not required to adopt open APIs are doing so 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 standardisation. Of the APIs now available, only a handful of banks in the UK and Ireland are using the same one – and they only did so because the UK regulator required them to. But each bank implemented the standard differently. This lack of standardisation 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 the bandwidth to write to one or two open APIs at most, and
4. The standards that have been created or proposed leave a lot of room for improvement. The UK Open Banking API, for example, is only usable by human beings, and it took around 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.
Go deeper with GlobalData
If Open Banking is to reach its full potential, it is 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 specialises in Open Banking APIs, and also has expertise in secure, instant micropayments,
and
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 is why these are important. To be a global standard, it is really best that it starts with global support. Trying to take a single region or country’s standard and get others to adopt it is harder – especially one 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 a very long time to come to fruition and the results are generally sub-par. 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 consortia. Choosing multiple vendors to work together is also infeasible: great products are not created this way.
US Tariffs are shifting - will you react or anticipate?
Don’t let policy changes catch you off guard. Stay proactive with real-time data and expert analysis.
By GlobalDataGetting input from all stakeholders is not controversial. Importantly, however, this does not mean the vendor should accept it all blindly; good design is always an iterative process, and input is often conflicting. APIs 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 that handles authorisation 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. We should always be asking: do we need this complexity at the core layer? More often than not, the answer is no.
Things should be specified at a high level, for example a payment request that can include metadata, and let the metadata itself be self-describing. Higher-level APIs could translate the meta-data to or from a variety of formats.
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.
Following on from that, it should be available as a commercial product from at least one commercial vendor so banks do not have to write it themselves. As a result, the back end of the API server should be easy for a bank to implement.
The API should use modern security and software methodologies for authentication and authorisation/SCA. There must be no shared secrets between the account owner and bank.
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. Obviously, it 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. Moreover, the API should be designed to be extensible so it can last for at least 50 years. Also, the API should allow for instantly pushing payments worldwide, not just a local payment push.
However, there should not be any sacred cows, or 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.
