What Is Open Banking?

Open banking is the future of how our financial system works. Looking for a deeper understanding of what it is, why it matters, how it works and why APIs are such an important part of it? Start from the beginning, or jump to what you're looking for by clicking the quick links below.

1. What is open banking?

Open banking refers to the use of APIs to share financial data and services with third parties. Third parties typically provide technology, a service or an app to the bank’s customers that makes use of the shared financial data and services. The shared financial data comprises e.g. the statements and transaction records belonging to the banks customers. This data cannot be made openly available, but it is only shared at explicit request of the customer. Open banking provides the technological infrastructure and the legal frameworks to make such consent-driven sharing happen.

Open Banking is a global phenomenon, but details differ tremendously in different parts of the world in many different dimensions:

  • Is it mandatory for banks to provide Open Banking APIs?
  • If open banking is mandatory, until when do banks need to implement it and what are the timelines?
  • Can banks choose to work with only some third parties or do they need to work with all eligible third parties?
  • What constitutes an eligible third party?
  • Do banks need to build APIs according to certain specification?
  • Which banking products and banking services are in scope of open banking

Open Banking around the world

Despite open banking being a global phenomenon, each country or region finds different answers to above questions.  It is often difficult to keep an overview of
the developments in various countries. Some countries already have regulation in force (such as EU and Australia), others plan to extend the scope of Open Banking (such as UK), and others are planning to introduce open banking. Information about open banking initiatives is scattered, hard to navigate, not uniformly available and it requires considerable effort and research to retrieve the needed information.

The openbankingmap.com website makes this information conveniently and uniformly available, saves time, and serves as a starting point for in-depth research. Learn about API initiatives around the world, including standards, API specifications, legal frameworks, participating banks, regulatory or market drivers, the scope of banking products and functionality covered, and the timelines for implementation and subsequent market take-up.


Open Banking vs Open Finance

Open banking has started with a focus on payments and checking/cash accounts. But the scope of open banking in terms of the banking products covered is increasingly broadened and extended. In some countries even savings accounts, and credit card accounts are included under the name open banking.

If additional financial products are exposed via APIs, the term "open finance" is used, which includes APIs for mortgages, loans, pensions, depots, trading accounts and more.      

The open banking myth

Let’s address a common myth: It is erroneously believed that open banking makes the customer’s data openly available to anyone.  But this is not true, as open banking puts a lot of effort on controlling both the circle of eligible third parties and letting the customers control the sharing of their financial data, by requiring their explicit consent.

So what is “open” in open banking?

With open banking, the digital value chain of banking gets opened up, allowing third parties to participate in the previously closed value chain.

Another perspective is that the banking stack gets opened up. The banking stack consists of customers, channels and banking products. When it gets opened up, it allows third parties to participate.

2. Typical challenges of banks

With respect to their digital transformation, banks are faced with a challenging situation. They have been some of the first businesses that introduced and used computers, in times when they were still synonymous with big mainframes.

Software was used to automate bank’s internal processes – those parts that customers never see. Customers interfaced with their bank via the bank branch.

But today, customers interface with banks via their smartphone, website or voice assistants. Customers interface with their bank via software. And software has become a differentiator. Traditional banks already observe customers switching completely to new digital banks or move a part of their banking activities to digital banks, which offer better digital services.

Banks face several challenges regarding digital channels to their customers

Changing customer needs

Customers demand more and more digital solutions, but banks' organically grown legacy systems are often overly complex, expensive to change and cannot hold up to the requirements. Bank customers are interested in using new, innovative apps to manage aspects of their personal finances. There is a range of financial apps out there, including apps that provide a holistic overview of transactions and balances across multiple bank accounts (multi banking), tailored recommendations to optimize finances (PFM - personal financial management) or faster and more seamless processes to get a loan or mortgage approved. These new apps are offered by tech-savvy fintechs and often surpass the functionality, convenience and personalization typically offered by banks’ apps.

Regulatory compliance

Regulators increase competition in banking by enforcing open banking, mandating banks to share data. Regulatory requirements need to be implemented within given timeframe and fines are imposed to non compliance.      

Increased competition

Open banking and embedded banking lead to increased competition and increased pressure to innovate. As traditional banking services get commoditized, banks need to find new revenue streams.

We will likely see financial services deeply embedded in a variety of non-financial products, resulting in more customer-centric, tailored, and relevant niche products offered by tech companies. Those tech companies will become the customers of tech-savvy banks, buying Banking-as-a-Service (BaaS) in the form of APIs from banks.

As this new dynamic plays out, it is important to distinguish between tech-savvy and traditional banks. Tech-savvy banks will enable embedded banking by offering BaaS to product companies as their customers, whereas traditional banks unable or unwilling to offer the same, will have to compete for end-users against the long tail of embedded banking offers. Today, those traditional banks mainly compete against other traditional banks just like them but will increasingly face competition from product companies outside the financial services industry with different business models, technology stacks, and fewer regulatory constraints.

To participate in this new and fast-growing market, banks need to be as technologically savvy as their customers and offer their services as attractive APIs.

Despite being a deeply technical concept, APIs are revolutionizing the financial services industry. APIs make core banking functions such as accounts, transactions, balances, and payments programmatically available - within the organization and to third parties outside the organization. Since the APIs are available outside the organization, innovative apps of fintechs can interact with the financial data of a bank’s customers, given he/she consents to share the data.


Long tail distribution of banking products

Banking promises to become more meaningful and more contextual for end-users, driven by tech-savvy banks offering Banking-as-a-Service in the form of APIs to product companies. Product companies (banks, non-banks, or near-banks) are thus enabled to enrich their digital products that end-users already use today with deeply embedded financial services, resulting in more customer-centric, tailored, and relevant niche products than mass-market banking can provide. Those niche products form the so-called long tail distribution, consisting of a battery of highly specialized niche products. Each product has only a small distribution compared to mass-market products, but within the broad range of products, end users can likely find a product that exactly fits their needs. To profit from the growing Banking-as-a-Service market, product companies from a variety of industries need to be great at consuming, orchestrating, and integrating financial APIs into their products.


How lane changers compete by using open banking APIs

So far, banks mostly compete against other banks that are just like them: the competition belongs to the same industry, is known, has the same business model, and addresses the same mass market. But with the advent of Banking as a Service (BaaS), banks have to face a new type of competition: I call them "lane changers" because they come from another industry and they quickly move into the lane that banks previously had all for themselves. It makes sense to understand how these lane changers work and what traditional banks can do in a changed competitive landscape.

3. How banks leverage open banking APIs to face the challenges

Open banking can make life easier for a bank’s customers. But why is open banking strategically interesting for banks? Won’t banks need to give up a lot of their control?

To face the challenges, banks use APIs for (1) system modernization, (2) regulatory compliance, and (3) to realize ecosystem & platform business strategies.        

System modernization

Banks rethink their monolithic applications to become more agile and nimble, to be able to react to future market changes more quickly. Monolithic systems are decomposed into microservice architectures with APIs. These internal APIs are primarily used internally to power the multiple digital channels of the bank, such as the bank’s mobile app, or website. Internal APIs can be the basis for open banking initiatives, whether these are enforced by a regulator or the APIs are used voluntarily for open innovation, to build platforms and ecosystems.

Regulatory compliance

Ensure bank stays compliant with upcoming open banking regulation (world-wide trend, but laws are regional) and avoid fines imposed for non-compliance. In the past, the open banking strategy of banks has been focused on regulatory compliance to avoid fines for non-compliance, pre-empting pending regulation and avoiding the threats of open banking competition.      

Ecosystem play

Open banking has moved away from "check-the-box” regulatory compliance to creating innovative opportunities, making it a topic of strategic interest to the board. In an attempt to differentiate, prospects innovate together with ecosystem partners, participate in and orchestrate digital ecosystems (e.g. for home, mobility, etc.) by strategically sharing data. As open banking becomes a reality in many countries around the globe, the advantages for bank clients are clear: more choice on digital banking offers, personal financial management, multi banking or faster loan and mortgage approvals. Technically, open banking is based on API technology and allows clients to ask their bank to share their financial data conveniently, safely and securely with fintech companies. Banks work with a broad range of fintech partners, who develop digital products. Banks provide the data via open banking APIs to the partner - the partner provides the innovative digital solutions that customers are looking for. The partner’s digital solutions simply use the bank’s open banking APIs. This ecosystem play has an attractive trade-off with limited costs for the banks, low risks shouldered by the bank, and it still allows customers to get the digital solutions they want. The digital solutions provided by fintech partners are not a threat – but they provide a moat for you as an incumbent bank, allowing you to ward off attacks by digital banks, neo banks or big-tech banking offers.

Open banking is great for banking customers and banks alike, making it a WIN-WIN proposition. Banking customers win, as they can use the new apps they want and need, and you as a bank win by keeping your digitally most-demanding customers without having to fund, develop, and offer a plethora of innovative apps yourselves.

4. Use cases for open banking APIs

How does open banking work from an end-user perspective? Open banking supports a number of different use cases; here are two examples.

Open banking case 1: Cathy and the accounting software

Cathy is a small business owner. She does the accounting for her business with a web-based accounting software. She spends a lot of time copying transaction data from her online banking software to her accounting software.

How can open banking help Cathy?

Cathy’s accounting software supports open banking. She instructs it to sync with her bank account number 1234. The accounting software requests access to account 1234 from Cathy’s bank. As a precaution, the bank asks Cathy if she really wants to share her transaction data with the accounting software - and asks her to digitally prove her identity by logging in to her bank. After this one-time setup, the data flows periodically from the bank to the accounting software. Cathy’s accounting software is always up to date - automatically.

Open banking use case 2: Cindy and the mortgage

Cindy is in the process of buying a home, but it is not easy to find one she really likes. When she finds her dream house, she wants an instant confirmation of the mortgage, so she can lock that deal in with the seller.

How can open banking help Cindy?

Cindy found a mortgage with a low rate offered by fintech XYZ. To assure eligibility, the fintech runs an affordability check based on the transaction history of her bank account. The fintech requests transaction data from Cindy’s bank. The bank asks Cindy to authenticate and confirm the data sharing. The bank can then share the data with the fintech, which crunches the numbers. This takes start to finish only a couple of seconds, the fintech provides an instant go/no-go result.

5. Technologies that power open banking

Financial services are built on trust, and it is vital for banks that their clients trust them. Clients need to trust banks to safely store their money, process transactions correctly, and keep their data secure. When banks introduce digital technology, such as open banking, it not only needs to improve customer experience, or enable the emergence of a vibrant digital ecosystems with a large selection of apps and digital solutions. When banks introduce open banking, it is imperative that its underlying open banking technology stack can establish, support, and strengthen the trust that clients have in their bank. Which technologies are required to participate in open banking ecosystems and how can these technologies be leveraged to establish trust with partners and clients?

When banks participate in an open banking ecosystem, they need to master several digital technologies, most importantly APIs. APIs are used for sharing financial data in the open banking ecosystem. By using APIs and surrounding technologies correctly, you can establish yourself as a trustworthy ecosystem participant with partners and clients.

  • Partners: To establish trust with partners, it is important to secure APIs and the data they carry according to best practices; develop APIs according to established specifications and industry standards; and create a smooth onboarding experience.
  • Clients: To establish trust with clients, banks need to educate them; show that bank clients are in control of their data; request the consent of the bank client for any data sharing or transaction triggered by the API; and create a smooth and convenient user experience for clients.


Sharing financial data must be secure, this is essential for gaining the trust of clients and also for the fintech partners. This means that API for sharing the data needs to be secured, all ecosystem players need to be properly authenticated & authorized, and the fintech receiving the data need to be trustworthy.

Not every fintech can get access to open banking data. They typically need to undergo a rigorous due-diligence process and, if successful, they get a machine-readable certificate. Under the PSD2 regulation these certificates build on TLS certificates and contain specific extensions, called QWAC and QSEAL. Banks check the validity of the certificate every time open banking data is requested by the fintech. Certificates are used to establish both the identity of the fintech and its status as a qualified recipient of open banking data.

The bank authenticates and authorizes the identity of the bank client – typically based on existing web-based or mobile authentication mechanisms. Once the identity of both fintech and bank client is established, the bank clients can delegate fine-grained access rights to their bank accounts to a fintech – and thus consent to the data sharing.


To trust an open banking system, bank clients must stay in charge of their financial data, with final say over when their data is shared and with whom. To support this vital aspect, consent mechanisms are built into open banking. They ensure that bank customers are first identified and then actively and intentionally consent to sharing their data. The OAuth framework and its various security profiles (such as FAPI) are used as the technological protocol for implementing the consent mechanism.

API specifications and standards

Ecosystem players need to agree on the shape and form of the API, the formats and data structures involved, technical standards for exchanging data and calling functionality. If all participants operate on the same interface specification, complexity is vastly reduced, there is no need for translation and unification, leading to faster evolution in the ecosystem.

In some jurisdictions, the regulator prescribes the API specifications in the form of implementation-ready OpenAPI Specifications (e.g. Open Banking Specifications in the UK), in other jurisdictions (e.g., in the EU) regulation provides only vague guidelines for the API interfaces, leaving lots of room for different incompatible implementations. In the later case, voluntary industry standardization emerges such as the BerlinGroup’s NextGenPSD2 API specification or STETs PSD2 API specification. Following these established standards and API specifications signals partners that there are no surprises to be expected; and thus strengthens their trust.

Documentation and onboarding

It needs to be easy for fintechs to figure out how to use the banks’ APIs. Banks need to provide documentation of their APIs, and a straightforward onboarding process. Since the due diligence requirements for fintechs can delay the onboarding of new fintechs using the APIs productively, it is all the more important to provide ungated access to the API portal and the sandbox. It allows fintechs a soft start with a bank’s API on a sandbox. In such a sandbox the fintech operates only with synthetic data – while experiencing the capabilities and the behavior of the API.


Leveraging API technologies correctly gives banks and fintechs not only the possibility to participate in open banking ecosystems, improve customer experience, and fulfill regulatory compliance requirements, but also with a great opportunity to build, maintain and strengthen trust with their clients and partners.

6. How open banking ecosystems emerge

For open banking to be usable, banks need to make their data available in the form of secure APIs – then  fintechs with innovative ideas will need to connect to those APIs, and leverage the data provided by the APIs. So open banking is more than just APIs for banks, it requires the emergence of a digital ecosystem that fosters the active collaboration among banks and fintechs.

How do open banking ecosystems emerge and what kind of ecosystem do we strive for?

Open banking ecosystems

There are different types of ecosystems - imagine a tropical rainforest on one side of the spectrum and a structured English garden on the other. In one you design and enforce rules, resulting in a predictable but also more constrained system - in the other you let things emerge, resulting in a more prolific, but also more intricate and even chaotic system. When it comes to finances, people tend to prefer the English garden with its predictability and are willing to accept some rules and constraints.

So with open banking resembling more the english garden than the rainforest, you need rules - both foundational and technical rules. What do these rules cover?

Foundational rules for open banking ecosystems:

First, an agreement is needed on who is in charge of making the open banking rules. Is it the government or the banking industry? One results in a regulatory approach, the other  a market-driven one. A legal framework with rights and obligations of all open banking participants is the basis for both.

Second, there needs to be agreement on the scope of banking data and functionality to be exposed (payments, checking accounts, transaction data, balances, trading accounts, pension accounts …) and whether every bank is mandated to expose the data/functionality or it is voluntary.

Open banking is emerging in many countries around the world. The details differ among countries but the above points always need to be covered.

Based on these foundational rules, more technical rules are stipulated.

Technical rules for open banking ecosystems:

The players in the ecosystem need to agree on technical standards for exchanging data and calling functionality.

It needs to be ensured that customers stay in charge of their financial data. This means that customers need to be made aware of the fact that they are sharing their financial data. They actively and intentionally need to consent to sharing their data.

Sharing the financial data needs to be secure. This means that the mechanism (API) for sharing the data needs to be secured, all ecosystem players need to be properly authenticated & authorized, and the fintech receiving the data need to be trustworthy.

It needs to be easy for fintechs to figure out how to retrieve the data and use the APIs. Banks need to provide documentation of their APIs, and straightforward onboarding processes.

For banks to follow those technical rules, they need to understand and properly leverage the underlying enabling technology. Universally, APIs are chosen as the technical enablers and as foundation for implementing open banking. So to master open banking, and create digital ecosystems, banks need to first master APIs.

7. How open banking APIs reshapes the value chain

APIs are revolutionizing the financial services industry by making core banking functionality - such as accounts, transactions, balances and payments – digitally and programmatically available both inside the organization and outside to third parties. 

This is the foundation of open banking. But open banking is more than just the technical APIs in the financial space alone, it also provides the security, legal and regulatory context necessary to transform financial services and reshape the value chain.

How does open banking reshape the value chain? By opening up the traditional value chain of financial services and make it more broadly accessible.

Often it is believed that there is only one way to open up the value chain - in the front of the value chain, where banks need to provide APIs for fintechs to use. But this is only half the story. There is also the possibility for banks to open up in the back of the value chain, allowing banks to use APIs of others and be on the consuming end. So there are at least two possibilities to open the value chain: In the front of the value chain, where banks are API providers or in the back of the value chain, where banks are API consumers.

Let’s look into each of these options.

Traditionally, a bank delivers its own apps and end-user facing technology

Instead of (or in addition to) that, the bank may become an API provider and deliver APIs to its products (accounts, transactions, balances, payments, loans). These APIs are used by fintechs and other third parties, in the role of API consumers. They build end-user-facing apps that call the APIs of the bank.

Moreover, in their apps fintechs integrate, orchestrate and aggregate the bank’s APIs with APIs of their own and from other players. The resulting apps are provided to end-users, who are typically also customers of the bank. Value flows from the banks via the fintechs to the end-users and compensation opportunities also exist in the opposite direction.

An example use case for opening up the value chain in the front is a multibanking app offered by a fintech that aggregates data from several bank accounts. The fintech gets transaction data and balances or all of the customer’s bank accounts, via APIs offered by those banks.  Even though customers seldomly see the API, they will appreciate that they can see their banks’ account in their favorite multibanking app - Thanks to Open Banking APIs. 

When banks open up their value chain in the front, the value chain gets longer and moves left, as you can see in Image 1. In this scenario, banks need to be good at exposing APIs, securing APIs, marketing their APIs and building partnerships.

Open banking also allows banks to open up the back end of their value chain

This allows banks to offer - via their own channels - banking products that are actually provided by other players. The bank simply uses the API provided by the other player. The bank does not need to build product functionality in its systems, nor does it need to hold the data in its systems. Instead, the bank simply takes on the role of an API consumer, uses the API, and thus integrates the banking product into its UIs and channels. 

An example use case for opening up the value chain in the back is a bank that wants to start offering unsecured loans as part of its own product portfolio – something this bank has not offered before. Instead of creating the unsecured loan product in-house, the bank uses the unsecured loan product from a fintech via API. By opening up the back end of its value chain, the bank can fill the gap in its portfolio quickly. With a short time-to market it can start offering unsecured loans to its customer base via its own channel.  

When banks open up their value chain in the back, the value chain moves right, as can be seen in Image 2. The value chain now extends out to an  external API provider. When opening up the back of the value chain, banks need to focus on new capabilities and skills, such as consuming, orchestrating and integrating third-party APIs. Moreover, they need to be good at building eye-level partnerships with fintech companies.

Learn more

If you are interested in reshaping your value chain, check out the in-depth video explaining how open banking APIs reshape the value chain.



As we have seen, banks not only have the possibility to change the structure of their value chain but also find value in doing so. Thanks to open banking and API technology, banks have more choice than ever to change the structure of their value chain, and this helps them to adapt to changing customer needs and to keep their customers happy. More choices in structuring the value chain also bring more responsibility to banks to make smart choices. In the following sections I will discuss how banks need to think strategically when opening up their banking stack.

8. Open up the banking stack

Banks traditionally prefer to have tight control over their products and delivery channels, but today’s customers are increasingly looking for broader choices. 

Customers want the banking products in the channel of their choice, at exactly the time they need it, and tailored to their personal preferences. As we will see, fulfilling these needs with the traditional, closed banking stack proofs to be difficult.

The banking stack

Banks typically organize around the concepts of products and channels, where products are for example loans, accounts and payments. Channels are the delivery mechanism (such as mobile. web or voice) of these products to the customer. This results in a simple three-tiered architecture: the so-called banking stack.

Traditionally banks follow a do-it-yourself approach

Meaning that they both produce their products and distributes them via their own channel. This approach gives banks a tight control over their banking stack. In the figure below, we visualize the level of control, where orange is controlled by the bank, and black is outside its sphere of control.

Oftentimes, product and channel are linked on an IT level (e.g. in a big monolith), but are also tightly linked from a business perspective. Owning the channel gives control over the customer interface and allows banks to cross-sell products from their product portfolio. Owning the digital products, in addition to the channel, provides tight control of the value chain.

The downside to tight stack integration

 But this tightly integrated banking stack has also disadvantages: Customers might feel that the product portfolio is too limited and wish for broader choice, e.g. in loans or mortgages. Customers might also see limitations in the capabilities of the channels - a more modern mobile app, personal financial management, personalized savings goals or account aggregation across the accounts of several of their banks. 

Achieving these customer demands is not so easy in a tightly linked banking stack such as the one shown above. With the growing number of digital channels (mobile, web, voice,…) that customers now want to use,  the tight linkage between channel and product can be prohibitively expensive for banks, as they need to invest in building out all of the channels they want to be present in. 

To address this challenge, it makes sense to follow two steps: Introducing a zipper between channel and product and then – where it makes sense – open up that zipper. 

Introducing internal APIs

Banks renovate their IT system landscapes, and break up the monolithic structure into layers - channel and product - using internal APIs. The API is the mechanism for structuring the opaque banking stack into separate components with clear roles and responsibilities: 

  • The banking products are below the API and have the role of API providers
  • The banking channel sits above the APIs and has the role of an API consumer
  • The API sits between banking product and banking channel

However, since these APIs are internal, they do not have any major effect on business

APIs are like a zipper between channel and product, introducing an improved structure and a separation between channel and product. But as long as the zipper is closed, the two ends of the zipper - channel and product - are still tightly held together. This reflects the value of internal APIs, they provide an improved internal structure. The true value of the zipper is in its potential to be opened up, bringing us to the next step.

Open banking APIs

When internal APIs have been built it is time to selectively open up the zipper between channel and product. This is what we call open banking. It makes the banking product, the lowest component in the banking stack,  available via API – even to external third parties. This allows external players to contribute to the banking stack in several ways, which will have a major business implication. New business models become possible when the bank's products can be distributed via third-party channels or when products of third-parties can be easily distributed to own customers, maybe to fill a gap in the product portfolio.

Of course, open banking comprises more than just the technical aspects of internal APIs, since opening up the APIs between channel and product to third parties requires a legal, contractual or in some cases even regulatory context.

With this structure and especially with the clear interface for the various components of the stack, banks can:

  • Open up their stack and easily invite compatible solutions from third parties
  • Easily integrate third-party solutions into the banking stack on both the channel side and product side
  • Still develop their own banking products and distribute them via fintechs
  • Or become the distributors of products and services created by fintechs

With their banking stacks open, banks have more flexibility

And they have a lot more options to adapt quickly to changing customer demands, be present on the latest channels, and efficiently serve the long tail market by providing tailored solutions for specific customer segments and niches. Finding the optimal mix amongst these new options is now up to the strategy of the bank. 

Learn more

If you are interested in opening up your banking stack, watch the video below to learn about the opportunities.

9. Six open banking strategy blueprints

After focusing intensely on the compliance aspects for the past couple of years, many banks are starting to embrace innovation the opportunities of open banking. There are many reasons for this change in perspective, ranging from the push in digital transformation provided by the Covid-19 pandemic, changed client needs and expectations of seamless and convenient digital experiences, and the many successful applications of open banking by pioneering banks.

Since open banking has moved away from the area of compliance and into the area of innovative opportunities, it has also become a topic of strategic interest. 

Open banking encourages competition and provides a mixture of challenges and opportunities for incumbents. Banks that can translate the opportunity of open banking into a clear strategy will be in the best position to start realizing its benefits. 

Here are some reflections on how to get there. As a basis for the strategies, we use a simple model of the typical banking stack with the three layers of products, channels and customers. Products are things like as loans, accounts and payments. Channels are the delivery mechanism (such as mobile or web) of these products to the customer. And customers of the bank use the banking products via the channels. This banking stack can be configured differently, by internalizing or externalizing parts of it. We explore six different open banking strategies, classified along two dimensions that traditionally have had a high importance to banks:

  • Ownership of the channel, on the x-axis. The channel, or customer interface, can be either owned internally (by the bank) or owned externally (by a fintech).
  • Origination of banking products, on the y-axis. The banking products can be provided internally (by the bank), externally (by a fintech), or it is a mix where external fintech products extend the internally available product portfolio.

As a result, we get a 2x3 matrix of strategy options for open banking, as shown in the figure below.

Traditional model

In the traditional model, banks own the digital value chain and the customer interface. There are two options: (A) If banks stick to their existing digital channels and don’t innovate, they might send customers into the arms of digital banks, neo banks or a bigtech banking offer. (B) If banks develop several new digital offerings themselves to satisfy increased customer demands and expectations, costs may be skyrocketing, innovation risks may be high, and they still may not be able to fulfill all the digital needs of their customers.

Open banking APIs with the plug-and-play model

In the plug-and-play model, banks extend their product portfolio with optional and complementary fintech products. They keep the customer interface under their control and distribute the mixed product portfolio to their own customers. The model has an attractive trade-off with limited costs for the banks, low risks shouldered by the bank, and it still allows clients to get the digital solutions they want. In the open banking model, those digital products are offered to clients in collaboration with a fintech. Open banking provides a moat for incumbent banks, allowing them to ward off attacks by digital bank, neo bank or a big tech banking offers.

Open banking APIs with the banking-as-a-service (BaaS) model

In the banking-as-a-service (BaaS) model, banks distribute their financial products via fintechs and thus have the role of a supplier to the Fintech. The customer relationship to the end-user is not owned by the bank anymore - but by the fintech. This means, that from the end-users’ perspective the bank is (almost) invisible and they only interact with the fintechs. The fintech is the customer of the bank, consuming the bank's APIs, in order to build innovative customer-facing applications.

With this model, banks can substantially extend their reach, it is an opportunity for tech-savvy banks to become the "Twilio for banking”. Due to cannibalization risk, BaaS is typically not rolled out in the home market, where direct customer relationships need to be protected.

Open banking APIs with the banking-as-a-platform (BaaP) model

In the banking-as-a-platform (BaaP) model, banks run a multisided platform in addition to providing classic banking services. One side of this platform represents the bank's regular clients. The other side of the platform is made up of a set of fintechs, which have integrated with the API of the bank. Bank showcases all its fintech participants and their value proposition on a marketplace. Banks can differentiate by the breadth of their fintech offers.

Bank partially owns the customer experience of the end-user and guides end-user to matching Fintech offers on its platform. That means the bank will strive to strike partnerships around the services that are relevant to its customers while forming close partnerships with fintechs in the industry.

Whereas the four models above were only for banks, the following two models can be applied by banks and fintechs alike.

Open banking APIs with the banking-as-a-platform (BaaP) model

In the banking-as-a-platform (BaaP) model, banks run a multisided platform in addition to providing classic banking services. One side of this platform represents the bank's regular clients. The other side of the platform is made up of a set of fintechs, which have integrated with the API of the bank. Bank showcases all its fintech participants and their value proposition on a marketplace. Banks can differentiate by the breadth of their fintech offers.

Bank partially owns the customer experience of the end-user and guides end-user to matching Fintech offers on its platform. That means the bank will strive to strike partnerships around the services that are relevant to its customers while forming close partnerships with fintechs in the industry.
Whereas the four models above were only for banks, the following two models can be applied by banks and fintechs alike.

Open banking APIs with a marketplace model

In the pure marketplace model, the organization (bank or fintech) is nothing more than a broker of banking products. Think of it as the operator of a shopping mall, instead of the operator of a single shop. It is a thin layer between API consumer and API provider. Marketplaces often don’t provide any products themselves but resell the products of others. They might add value by standardizing the APIs they provide, unify all the various open banking APIs offered in one area, or provide supporting/auxiliary services, such as due diligence of the participants.

Learn more

If you are interested in opening up your banking stack, watch the video below to learn about the opportunities.

Open banking from the perspective of a consumer of banking-as-a-service (BaaS).


Keep in mind, that the strategy models do not need to be applied to the complete product range of a bank but will more likely be applied to single products only, such as loans or mortgages. 

Based on the six open banking strategy models, banks can assess the viability of each model in terms of strategic alignment. Certainly, tradeoffs need to be made between what banks aim to gain versus what they are giving away. Important factors in an assessment can be the value of customer relationships, trust and security.