If you’re a bank looking to digitize your services, you probably know that APIs are central to your future. As McKinsey underlines in its 2023 article "APIs in banking: From tech essential to business priority,” APIs have evolved in their role and importance, from a technical enabler to a business priority. A business priority needs to be driven by strategy.  

Many banks build APIs today, and they perform a range of different functions. APIs can be used internally, to improve the connectivity of a bank’s digital channels, or to exchange data with trusted partners. They’re the chief enablers of open banking and Banking-as-a-Service (BaaS), both of which provide unique opportunities for expanding digital products. They can also be used to generate new streams of revenue, either through BaaS, or by allowing customers to access fee-based premium features. 

Which of these API strategies should your bank consider? In the following blog, the second of a three-part series, we’ll take a deeper look at several—with a particular focus on open banking and BaaS, and what they might entail for your business moving forward.

API-led banking strategies

An API strategy describes the intention, purpose and goal for using APIs. Banks use a broad range of API strategies and here we want to introduce some of the most common ones. The differences between these strategies may appear subtle—after all, they are all based on APIs—but they differ in the degree of “openness”, the business model they support, and how they generate revenue.

Internal API strategy

Banks follow this strategy when their goal is (1) creating an omnichannel experience with more convenience for their clients, (2) overhauling the internal, organically grown system landscape, and (3) making its services more accessible for new digital initiatives. These goals often go hand-in-hand. From a business perspective, the value is an improved customer experience, and from an IT perspective, the value is in a clean system architecture, designed to modularize functionality and break up silos. Internal APIs often serve as the basis for any digitization efforts in other areas of the bank.  

Internal APIs are not visible outside the bank, they are primarily used in the bank’s own digital channels, including mobile banking and digital banking. The use of internal APIs outside the bank’s own digital solutions is intentionally constrained, whether it is for security reasons or for strategic reasons. Whatever the reason, the result is the same: internal APIs cannot be used by the apps of partners or fintechs. This concern is addressed by the next API strategy.

Open banking API strategy

The goal of open banking is to enable data exchange with the apps of partners and fintechs, with APIs as the technical enablers. The open banking API strategy starts where the internal API strategy ends. 

The customers of the bank with their increasing hunger for more convenience are the drivers of such an open banking strategy. For example, they want to use apps for instant payments or for managing their budget, which require real-time data exchange with the bank. Given the customer demand, it is a differentiating feature for a bank to be able to offer connectivity with these popular apps. The more apps a bank can connect to, the more attractive it becomes to customers, so each user can connect their favorite apps with their bank account. Some customers might even switch banks and choose a bank with better connectivity features. This market pressure is the driver for open banking API strategies. 

But there is more to it. While some jurisdictions, such as the US, follow a market-driven approach to open banking, other regions, such as the EU, have a regulatory open banking approach. In the regulatory approach, legislation is used to as the main driver for open banking API strategies. But even in a regulatory approach, the market pull is an important factor that motivates banks to invest in high-quality APIs. 

Technically, open banking APIs are often realized by leveraging internal APIs. Sometimes the decision for an open banking strategy might trigger the need for an internal API strategy, and when an internal API strategy is already in place, an open banking API strategy is a natural extension. Technical standards should be used for implementing open banking APIs, to ensure they can be used broadly by as many apps as possible. Technical standards can cover several aspects. For example, the use of REST as an architectural style, the use of OAuth for API security, but also the exact API design with the endpoints and parameters. In the US, the FDX (Financial Data Exchange) standard has a leading role, in the EU, the Berlin Group NextGenPSD2 or STET are widely used. 

An open banking API strategy typically does not aim to create revenue, and the APIs are not directly monetized—so the API does not come with a price tag. However, Open Banking APIs are indirectly monetized—a bank account with Open Banking APIs is more attractive to customers than one without. The APIs are typically seen as a new and attractive feature of a bank product, which makes them want to stay customers and pay the bank fees for their accounts. So indirectly, a link to the revenue exists for open banking APIs.

Premium API strategy

Many banks see the possibility of monetizing their APIs. By focusing on APIs that are beyond the scope of open banking standards and regulations, they can create differentiating APIs—APIs that not many banks offer. Examples include APIs for foreign exchange (FX) trading, instant reporting, or corporate payouts.  

Premium APIs act as an additional feature on existing banking products. They enable banking customers to gain API access to the bank’s digital products through automated interactions.  

Premium APIs do not require a fundamentally new business model; instead, they provide an additional monetized feature to the existing banking product. Typically, this shows up as a new line in the pricing sheets that banks hand out to their customers.

Banking-as-a-Service strategy

Banking-as-a-Service is a new business model that allows banks to embed their financial services into the digital products offered by other companies. An example is a loyalty program of a supermarket chain that comes with a branded credit card. 

Behind the scenes, it is realized with Banking-as-a-Service, offered by a tech-savvy bank that teamed up with the supermarket. Jointly they bring a new form of banking—embedded banking—to their customers. Banks offer their credit card products white label in the form of an API, which allows them to be integrated deeply into their partner’s value chain—in our example, it is the value chain of the supermarket.  

Another example is the Apple Card, which is provided as a BaaS API by Goldman Sachs, or the Lyft credit card, which is provided as a BaaS API by Stride Bank, or business bank accounts that come bundled with SME accounting software.  

To make this happen, both partners bring their strengths to the table to create synergy, creating a win on both sides. Banks provide their banking license, the banking product, compliance know-how, and their tech stack in the form of BaaS APIs. Digital leaders—typically brands that customers trust (such as the supermarket or Apple in the examples mentioned above) provide access to their customer base and a unique customer experience. This allows banks to acquire new customers, at a lower cost—while diversifying their streams of revenue, often by charging a fee per API transaction.

To participate in this attractive market, banks need to be as technologically savvy as their customers, build a strong digital platform with Banking-as-a-Service APIs, and partner with digital leaders. Technologically, APIs are important enablers, and Banking-as-a-Service offers the business model for monetizing these APIs. BaaS allows banks to diversify their revenue streams and acquire customers at significantly lower costs.

How do BaaS APIs differ from open banking or premium APIs?

As we’ve already discussed, both open banking and Banking-as-a-Service require the use of financial APIs that are provided by banks. These APIs are embedded into the products and services of partners. The differences between open banking and BaaS APIs include how deeply the respective type of API can be embedded into a third-party product; how much of the lifecycle of the exposed banking product is captured; and which lifecycle activities of the banking product happen within the embedded context or outside of it.

Illustrating the difference

Distinctly BaaS API

BaaS provides an autonomous, embeddable product—and BaaS APIs allow non-banks such as fintechs to build a service that looks like a bank. Using BaaS, the bank as API provider is invisible to the end-user and the fintech, or API consumer, is able to completely own the channel to the customer. The end-users might not even be aware of the existence of the BaaS provider.

Distinctly open banking API or premium API

Open banking only provides embeddable features of a larger product, which needs to live outside the embedded context. Open Banking APIs do not allow a fintech to build a service that looks like a bank. End-users primarily interact with the bank and its primary mobile, digital or physical channels, and only sporadically access their account information via the Open Banking APIs on a fintech app.

APIs and your bank

By now, the difference should be clear: open banking exposes features of banking products as APIs. It still relies on the traditional business model of selling banking products. And though it’s more often used for compliance than for drumming up new business, there’s a chance, with premium APIs, for some monetization. In contrast, Banking-as-a-Service offers a new business model, with new product distribution channels, and a greater chance of driving new revenue.

Are you interested in learning more about what your bank needs to consider to take advantage of these opportunities? If so, we invite you to sign up for our upcoming BaaS webinar, where we’ll cover all of this in greater detail.

Stay tuned, as well, for our third installment of this series, where we’ll introduce you to webMethods, our industry-leading API management solution, and how it could help get you started with BaaS and open banking, faster.