Banks struggle to balance two imperatives: to open their systems to external partners and clients via application programming interfaces (APIs) and to control the user interaction. In order to maintain the direct and captive relationship with their corporate clients, banks are building their own API-based catalogs with high walls separating them from other institutions.

APIs are not really a topic of interest for corporate treasurers, who are not interested in how the data is provided but in what they can get from banks. Treasurers are also continuously demanding a single point of access to services from multiple banks, without being forced to hop from one user interface to the other. Therefore, single-bank platforms are passing away.

The only viable option that banks have—so far—identified is to invest in a fintech firm that takes on the challenge of connecting all these disparate systems using different standards and formats and do that mapping on behalf of the parent bank. This is a solution that any bank would aspire to. It allows a bank to maintain the one-to-one relationship with the clients while satisfying the needs of clients that want one point of access to their multiple bank relationships.

This model works in principle, but a bank can hardly manage it in a profitable way. While the client user enjoys a single user interaction and experience (UIX), the interface that the bank must deal with in the background—with highly separated connectivity channels, definitions, nomenclature, access protocols, and authentication of multiple proprietary API formats—is very expensive to maintain and manage. This is not a bank’s business, even if it is technically in the hands of the acquired fintech provider.

To resolve this, banks are starting to turn to a business process intermediary, most likely an enterprise resource planning system, a treasury management system, or a portal managed by one of the major core banking software providers (e.g., Finastra, Temenos, Infosys). These partners ensure that the bank’s client enters the portal via a one-key gateway and consumes the services that the intermediary will make available by individually connecting the various bank proprietary APIs. The bank is free to concentrate on the client, handing off to the intermediary all the technical complexities.

Leading core banking systems providers have further evolved this approach and consolidated the bank-as-a-service (BaaS) model. With BaaS, a bank has the necessary front-, middle-, and back-office components to satisfy the corporate client’s need for a single point of entry and flexibility of choice, but it inevitably reduces the chance for a bank to maintain that UIX. Every time the corporate system interacts with the various bank applications that the BaaS layer connects, it will go through the third-party layer that shields the bank system from complex “behind the scenes” connections, orchestrations, and maintenance of disparate API protocols and standards. Without appropriate “countermeasures” to the BaaS model, in the likely near future banks will completely lose the UIX with their clients because treasurers will find it normal—and the only available option— to go through third-party providers instead of their own banks to access banking services.

BaaS contains the same inherent “original sin” of any bank-centric model: Every bank will want its own BaaS layout, and this will inevitably create a proliferation of BaaS ecosystems to the detriment of the corporate user. Considering that the more the banks engage in developing and exposing their open banking APIs, the more they will have to give up the direct UIX connection with the client, the option that banks are left with is to create a consortium.

I anticipate that banks will partner together in consortia-based platforms to harmonize the different legacy and proprietary API standards while regaining a collective control of the business relationship with the clients they now risk losing. Banks will compete not by holding the individual relationship with the client but by servicing the client with a bigger population of corporate users on the platform and with API-based products and services that more closely align with their needs. It is a new era for open banking: APIs “dematerialize” the banks and separate the asset (e.g., the bank account number, the payment channel, the loan contract) from the service (respectively, the most rewarding place to hold liquidity, the most efficient and cheapest rail to exchange a payment transaction, the most economic option to access funding).

This will require consortium banks to be competitive in terms of product pricing, risk pricing, market coverage, time to market, and delivery capabilities. The loss of the captive relationship with the client is counterbalanced in the consortium-based ecosystem by the access to a wider community and network of prospective clients that are free to select and test new propositions and new services via the exposed APIs.