BBVA started the open-banking and API journey back in 2014 with a perspective on building APIs and launching them to the market as plug and play. The idea was to create a library of off-the-shelf APIs that the customers and partners could pick up and use as a plug-and-play product with the proper technical implementation, which would be easy to use. As BBVA is a bank and is regulated, the aim was to encapsulate all the regulatory control aspects within the API. Businesses were also launched in multiple countries, keeping this idea in mind. But, as BBVA built products, the team realized that the reality was very different for a Banking System. BBVA needed to consider the following aspects –
- No plug and play
- Type of Operations
- Control and Regulations
- Core Technology
- Business Model
In a Banking System, all APIs cannot be simple plug and play. The users need guidance and operational support. Customers and clients that do not have basic or clean products need support to successfully integrate BBVA’s APIs and successfully get support for finance.
It is not just about the API layer within a bank but about the end-to-end product. We have to consider the operating system of the Bank. Core banking products control the entire value chain on the production and the distribution of the products. When you are in open banking, the distribution is something that you do with a partner. This fact changes many things and depends on the company’s work, its controls, and its business model.
For example, we have to build a checking account API or lending API and then sell and support it as a product for our clients and customers. But the regulatory part is of prime importance here. Irrespective of the relation or who is controlling, it is the end-to-end banking product or services for the customers, not just the API. So, all these aspects are essential for compliance and regulations, how the third party or client or customer is presenting information and marketing the information, whether they provide banking products, etc. Sometimes, there can be issues. For instance, in the US, a bank had a problem with regulations and had to stop all operations because a part of this Bank did something wrong or was not entirely correct.
The core technology is also crucial while considering APIs. For larger banks or with a more significant number of transactions, some pieces may not be ready for optimal performance.
One more vital aspect to be considered is the business model. Say we decide to sell the API at a price as a standard product and not a commodity, but it may not work every time. Sometimes, even with the very same API, we have different business models and ways of monetizing these APIs.
Business strategy determines the “shape” of open banking
The business strategy depends on whether the API can or cannot be standardized, which depends a lot on the “shape” of the banking. It is the amount of collaboration by the third party (customers) with you.
Regulatory APIs – For regulatory APIs, we know how the API should be and the rules we need to follow to run these APIs. The third-party will have a charter or a license to do that, and the compliance liabilities are going to the third party. We cannot monetize this because it is mandatory and not a business decision. It differs across countries.
Partnership – A partnership is more complex because you have a third-party channel helping; it is a supplement. From the Bank’s point of view, the third party is like a channel because it is helping us to distribute, sell or give a better service to our customers. So, unless it is a basic partnership, the situations are not standard across customers. The use-cases are different, leading to a lot of backend configuration. The API, per se, is not complex, but the preparation and bundling of the API, the end-to-end service, that are from the API call to the response, what is happening at the Bank and within the proper lead time, can be complex.
White label – White label is not exactly a different service; it is a different business strategy. It is not a discrete movement but a continuous movement between a partner and BBVA. Some partners may ask us to have another label. In contrast, some may ask for a BBVA label, which adds complexity but provides opportunities, and innovation capabilities and helps find new horizons.
Operating System – changes for third-party business models
Let us look at how products are built and run at BBVA.
We started with three platforms, having similar components with similar products on top of them. BBVA then had a group of people specializing in APIs and relationships with third parties. But, when we wanted to scale this, we needed the whole group at BBVA to be able to deal with APIs similarly, feeding our global API catalog. We required our partnerships and sales to understand the APIs and have open discussions with third parties to agree. The whole Bank is involved in the solutions development aspect, and some standard knowledge is mandatory across the Bank.
The API development is also distributed across countries with a central repository. Rules and standards of API development and standardization of documentation are clear and available to everybody and followed across BBVA. Sandbox and testing rules are in place.
An API in banking is not off-the-shelf, so we need a technical manager who liaises with third-party companies to know the requirements. When we run a business like a relationship through APIs, the third party will do some of the things that the Bank did earlier. Still, the Bank needs to have control, especially considering the regulations that need to be followed. E.g., If the third party is distributing loans in a marketplace or an E-commerce website or app, the Bank needs to monitor and control the end-to-end service. The channel is the API, and the actual person doing it is the third party, but the processes, control, and monitoring are with the Bank.
Synchronization between technical account managers, teams, and third-party is vital.
Control-Regulation still exists
Consider a use case.
- BBVA to partner is B2B
- BBVA to customer is B2C.
We need to understand who is doing what, which is helpful while designing the API. It helps with deciding the calls, responses, and output. This also helps define controls and responsibilities as it helps with who does what. We describe use-cases for all scenarios, and these are studied and approved before development. We can have multiple partners using the same use case (e.g., bundling or packaging), or it can be specific to a third party or case.
Technology – Resilience to succeed in B2B2X business models
In terms of technology, BBVA has large franchises. We have banks with 25 million customers, 5 million customers banks, basically, a wide range of sizes. We also have various third parties or partners, so we have different platforms behind the API layer in different countries. The hybrid cloud is helping BBVA to have the flexibility though 100% same configurations may not always work. We collaborate with third parties for monetization, and what we sell is the entire use case and not just the API. It is possible because of our development standards and processes, which are the key to our success in scaling business.
