There’s a fact that is often overlooked when talking about open banking: It’s all about the APIs. The clue is in the title: “open” refers to “open APIs” available over the Internet. In fact, APIs are at the heart of the original model designed by the Open Bank Project.

For the most part, however, the subject has moved away from the APIs themselves. Open banking has become focused on the benefits of the model for the banking ecosystem as a whole. Typically, these benefits are couched in the roles and responsibilities established by the regulations that are pushing open banking forward, such as PSD2 in Europe (as we’ve covered before) and a myriad of different initiatives elsewhere in the world. The goal of these regulations is typically to drive competition in the market and ensure there is room for non-bank participants in financial services.

However, this trend towards regulation-driven development of the market belies an important fact that tends to be overlooked: For a good number of participants, APIs are only a means of meeting regulatory requirements forced upon them rather than being a driver for pushing products into the market through APIs. This trend can potentially result in a disparity that could significantly affect the financial services arm of the API economy.

In this post, we look at how this might be skewing the API economy away from the regulated banks and – as a result – what participants are more likely to reap the rewards of being active participants in the API Economy. In particular, we’ll look at whether the banks are only meeting their regulatory commitments, or pushing their API agendas – and their products – through the open API model. We’ll also consider why taking an API-first approach to open banking would be of benefit.

The Realities of Open Banking

The phrase “open banking” gets thrown around with such abandon that a layperson might think that a financial epiphany has taken place, where banks and fintech alike are co-operating in some halcyon vision of consumer-orientated openness. However, the open banking ecosystem, as represented in Europe, the most significant market, is only in the first stages of opening up. It is, however, growing rapidly. As Juniper Research highlights, the number of users aggregating their accounts is predicted to double to 40 million by 2021, and payment volume is expected to increase to USD $9 billion by 2024.

As we mentioned above, the origins of the name lay in the Open Bank Project, which proposes a model for banks as API Providers. The model is one of composable banking, a phrase devised to represent the functions of the bank that can be consumed by APIs without requiring that the other “human-orientated” channels like branches, customer support, and internet banking all be delivered by the account-holding bank. Want to hold an account with a bank that has great interest rates, but want an internet banking experience another software provider delivers? No drama – the style of open banking proposed by the Open Bank Project allows for this.

Whether that is the end state we are expecting from the growth in open banking remains to be seen. The truth is that the current phase is driven in most markets by regulation, not products, and banks have become API providers because they have had to. In most markets, it appears that banks have had limited motivation for providing open APIs that could make composable banking possible, and regulations like PSD2 have been created to coerce banks to provide them to open the market to fintech.

PSD2 homes particularly on two specific roles, namely Account Information Service Providers (AISP) and Payment Initiation Service Providers (PISP). These are regulated third parties to whom banks must expose APIs to allow them to access consumer data or initiate a payment on behalf of a consumer. It’s no surprise that the majority of markets, whether through regulation or encouragement, have tended to mirror these roles in their regulations and/or standards. While the spirit of these roles is correct, it has a number of side effects:

• Minimum requirements met: The Open Banking market as a whole is driven towards a certain “type” of offering, based solely on what the banks have to make available – account information and payment initiation – rather than what they can make available.
• Little productization effort: Banks are required to make huge investments in exposing public APIs that are created according to standards. The APIs offer virtually zero return or opportunity for revenue, which breeds the perception that only compliance is required.
• Only “adequate” developer experience: The relationship between the banks and API Consumers (typically Fintech companies) is not symbiotic, given their competing interests. Given this lack of investment in the relationship between the two parties, the average developer experience could, at best, be described as “adequate.”
• Poor service reliability: The potential lack of buy-in by banks means that the APIs deployed to the market are less reliable than would be expected in a typical API Provider’s implementation. For example, UK banks typically perform periods of maintenance on their APIs that your average API Provider would simply not countenance. The figures available from Open Banking Limited highlight this fact. For example, in May 2020, the average time large UK bank APIs were unavailable was just over 8 hours. Compare that to an established API provider like Stripe, which reported only 2 hours of downtime in the same period.

Perhaps the last point drives home a critical factor about the open banking ecosystem in that it is at odds with the development of the API Economy as a whole, which is largely driven by great products, not regulatory coercion. The general impression is one of an ecosystem not quite ready for the open banking big time. Mark Boyd from Platformable reports from his work on the Open Banking Trends Report:

• “..the fintech startups are still building their solutions in ways that rarely even use the APIs because it is still too hard. And API teams within those banks that are showing they want to shift to a platform mindset are struggling to get the resources necessary to really demonstrate the potential of working with ecosystem partners.”*

This viewpoint appears to validate some of the assertions we made about screen scraping in 2017. This is reinforced by the fact that some organizations such as Metro Bank have simply redeployed their scrapable online banking interfaces in order to meet their regulatory obligations for PSD2.

While regulations definitely have their place to spur banking APIs, commercial imperatives are likely to drive successful API providers to create great APIs and the developer experiences to support them. The recent high-profile acquisitions in the Open Banking market of Plaid and Finicity by VISA and MasterCard respectively shows how valuable the fintechs are becoming. The impetus to create such open banking brands comes from the desire to bring a great product to market. To create a thriving market, this desire must extend to banks as well as fintech.

The Commercial Imperative

Regulation and standards may be the starting gun for open banking in many markets. While the commercial imperatives on the banking side may not be clear in Europe, other markets are showing alternative approaches.

For example, the Monetary Authority of Singapore is driving adoption by creating a framework for Open Banking without laying down exact technical standards. While this may require bespoke integration across different banks, it also allows for a diversification of API products, allowing banks to serve APIs that have a more commercial imperative. In their report on the Singaporean approach EY highlight the fact they “see some banks using APIs to establish cross-sector partnerships and create ecosystems focused on financial services ” The Standard Chartered Good Life API is also highlighted by the report. The service provides a network of merchants that offer rewards, points redemption, and alternative payments, demonstrating how an open banking initiative can power a successful consumer-facing product.

While the Singaporean market has specific conditions – especially the fact that it is already relatively innovative when it comes to technology – it shows that regulation-driven development of open banking is not the only approach. When one considers the functions of the core open banking model – and the idea of composable banking – a great diversity of APIs would most likely mean a greater number of the functions required to make composable banking a reality being available. However, exposing APIs should not just be about meeting the demands of an idealized model. It should be about meeting market demand. Otherwise, we arrive back at the arguably one-sided market that European regulations have manifested.

Market forces should, therefore, be allowed to drive demand. Like it or not, the market needs to include the incumbent banks as they hold the all-important customer accounts. Standardization has its place by making the integration efforts of API consumers easier across the ecosystem, but demand rests with the market and giving customers what they want. Many of the arguments for the extension of Open Banking into “Open Finance” include the need to encourage commercialization of APIs outside of the regulatory model. However, it takes more than either regulations or encouragement to bring APIs to market. Organizations have to want to be API Providers because they:

• Appreciate what the model offers.
• See commercial advantages to that model.
• Can imbibe themselves in the “spirit” of becoming an API provider.

This takes more than regulation and standards; it requires a mindset geared for change. Despite the regulatory drivers, there are examples of European banks that are embracing this need, and taking products to market that go beyond the regulatory mandate. For example, OP in Finland provides API-based access across a number of their banking products, especially in wealth management. They also tackle problem areas – published with their developer content – that have grown up around standards such as Refunds. Another example from the Netherland is ABN AMRO with the Tikkie API, which diversifies their payments solutions towards Business to Business/Consumer use cases and has resulted in a Salesforce intergration for the product.

Banks that understand the value of APIs-as-products and the need to operate as an API provider will put themselves in an advantageous position. As the market grows, standards will continue to set the tone, but diversification will be marked by the banks becoming more tech-focused.

As the Platformable Open Banking Trends Report for Q1 2020 advises: “You should be thinking about how to measure the value of your external-facing APIs so that you can better define your API business models.” Those that succeed will adopt API-first principles, using best-fit API styles and decomposable architectures deployed as microservices that allow them to both react to and plan for change more readily. This will come from really thinking about the needs of the API consumer.

The Road Ahead

We as technologists are lucky enough to understand how convenient the open API model is for bringing great products to the market. However (and more’s the pity) technologists don’t make the rules for the vast majority of large corporations. The decision-making process involves possibly hundreds of stakeholders with a multitude of concerns and pre-defined conceptions on how products should be delivered. To move these stakeholder’s opinions to a place where they are supportive of the open banking model requires cultural change within these organizations, moving towards the notion of the bank as a technology provider.

The conditions for such a reckoning are ripe given two factors:

• The investments made by banks for regulatory compliance in a technology stack dedicated to hosting open APIs have the potential to realize a return on investment.
• Competitive forces that are already starting to manifest themselves in the Open Banking market will prompt banks to assess their product placement by virtue of what is gaining traction – and most importantly, revenue – in the market.

The next step is for incumbent product managers to realize and then seize the opportunity, taking their new products to market using APIs as the vehicle. As Mark Boyd puts it “…the difference is becoming clearer between banks that see APIs as a regulatory necessity and those that are seeing APIs as a springboard to creating a platform”.