API Strategies for Banks and FinTechs in an Open Banking World

This article by Matthias Biehl from Software AG talks about API strategy for banks and FinTechs in an open banking world. The article will look at the past, present, and future of banking products to understand what strategies we should apply.

In the past, banking as we know it was a bundling of separate banking products into a big mass-market banking product. What we experience at present with open banking and open finance is an unbundling of this mass-market banking and spans many different banking products. When we look into the future at what’s next in open banking, we will see a re-bundling. The small unbundled pieces will be reassembled in new ways; they will be re-bundled in banking as a service.

If we look at this step by step, we focused on efficiency and creating a mass-market in banking products in the past. We had different banking products, such as a current account, a credit card, a trading account, a savings account, mortgages, and a retirement account. All of these have been bundled together into a big mass-market banking product. If you have your mortgage at a bank, it’s very likely that you also have other banking products at this bank, a current account or your credit card. That results from this mass-market banking strategy that we had in the past.

With open banking and open finance, we started this mass-market banking offer that we have created. What we do now is unbundling—unbundling means that we take this big offer and create separate products for it. Of course, these products are technology products represented in the form of an API. For example, a credit card API, a current account API, and a savings account API. This is what we call open banking.

We also have other APIs emerging in this area, such as retirement accounts, trading accounts, mortgages, and loans. This more considerable scope is called Open Finance. It all moves in the same direction. It’s an unbundling of this big mass-market banking offer, making it available in the form of APIs that can be embedded.

If we look in the future, we’re going to start at precisely that step that was the output of open banking, where we have APIs in all of these different subcategories of banking. These are the financial services industry APIs, but a similar movement is also happening in other industries. APIs are also emerging in logistics, insurance, accounting, business, management, communications, and transportation. All APIs are evolving and contributing to a lego box from which we can start building stuff. Besides the financial industry, this Lego box contains APIs of other industries that can be re-bundled, and we will now get a new bundle.

In contrast to what we had in the past, this bundle is not a purely financial services bundle; it also contains all these other aspects of other industries. For example, we get a combination of the financial services industry and logistics, or financial services industry and insurance or financial services, industry and transportation, and so on. All of this together will create a very specialized banking offer. That specialized banking offers a personalized, very attractive market for a tiny niche end-user market.

For example, Judy is a musician. And as a musician, she now has a banking app specially created for musicians. It contains many features; your account and credit cards. It also takes care of the income streams that musicians typically have, for example, Spotify.

For example, Mike is in a completely different niche. He is a frequent traveler and a businessman and doesn’t have much time. He’s traveling a lot, and he wants to take care of his finances between flights. So in this little time that he has, he wants to maximize what he can do. When he has a lot of different bank accounts from different banks, he doesn’t want to log in to all of these different banks. Suppose he gets a multi-banking app to see all of these different banking transactions happening in one place. That allows him to be efficient. That’s not necessarily something that a bank provides. Here in this example, this is provided by an airline for their frequent travelers who have precisely that kind of challenge.

There will be some mass-market offers and many specialized niche-targeted banking offers in this new market. They are a combination of different APIs for various specific types of customers. We call this distribution a longtail distribution compared to the very narrow mass markets that have few offers but very popular ones. In niche markets, you have a lot of different offers, which are each by themselves, not very popular, but taken together, they can be a very attractive market. These are called longtail markets.

So are niche markets profitable for banks? Is it a good strategy to go for one of those niches for a bank? For example, if a bank would try to cover a specific niche, would that be a good strategy? Well, the answer is no! Because if there are few people in a specific niche, it would not be very attractive to focus on that.

But using API technology, there’s a better way of addressing these niche markets and addressing those niche markets at scale and in a very efficient way.

To address this longtail market that is created or about to be created, you use partners or developers. Each of these developers is focused on a specific niche. Some partners may already have a customer base in that area. As a bank, you leverage these existing customer bases that partners already have. You bring out these APIs and put them on a portal; you have a partnering process. You can address this mass-market very efficiently at that scale. You don’t need to go into each mass market yourself, but you do that with a partner.

Developers are super important; developers are now customers. Developers are super customers because they bring in a lot of end-users. That’s what gives them these superpowers and this multiplier effect.

Value Chain – Now, I want to look at this from another perspective. I want to look at it from the perspective of a value chain. 

And if you think about the typical value chain that a bank has, it starts with the bank having some data at the bank, which is exposed by the bank’s app to an end-user. There’s no developer; this is the traditional classical model. Value flows from the bank to the end-user directly via the bank’s app. There is a possibility of compensating for this value that the end-user receives in the form of fees. Open banking and banking service opens up this value chain; there are several places where you can open up this value chain. When we typically think of open banking, the bank becomes the API provider. The developers and the FinTechs are doing the integration. They build an app out of this that will be presented to the end-user like Judy or Mike. 

Value flows here, still from the bank, to the FinTech, who will get some value from integrating this, and to the end-user, eventually. For this received value, the end-user then will have the possibility to compensate the FinTech and potentially the bank as an API provider. Banks need to be good at exposing APIs, securing APIs, marketing those APIs, and partnering with interested FinTechs.

The other possibility is that the bank now doesn’t have the business assets anymore. The bank now becomes not the API provider but the API consumer. The bank will use APIs provided by someone else, let’s say a FinTech or another bank, and this other player is the owner of the business assets. Value flows from the FinTech to the bank to the end-user. And compensation is the other way around. Banks need to be good at consuming API’s orchestrating them, integrating them, and still building partnerships.

Technology Stack – Let us look at the technology stack and how open banking and other movements like banking as a service are changing the banking stack. 

I have a very simple banking stack here for you. On this banking stack, we have, on top the customer, we have a channel to the customer, and we have a banking product as the basis of it. We have a channel and a product in the traditional banking stack, all bundled together as one big block. This is inside the bank; the bank owns the channel, and the bank owns the product. And with this bundle, we go to the customer. Now, if we introduce internal APIs, what’s going to change? If we introduce an internal API, we have a zipper between the product and the channel, but this zipper is closed. This zipper means that now we have an internal cleanup process for our architecture, but it’s not available to the product and the channel. Even though they are potentially separable by this zipper, they are, in fact, not separate; they are still held together. Inside the bank, we still have both channel and product.

If we introduce open banking, we open up the banking stack. The zipper is opened up, but not all the way, just a little bit. Because still, to open the banking product, to open our bank account, we need to go via the bank’s channel. So it’s not a complete product and is not completely covered as a separate product.

If we introduce banking as a service, we have a complete separation between channel and product. This is a new reality. This is also happening in other industries. For example, we also have this separation between channel and product in the telecommunication industry. We now have providers that only have the product, for example, Twilio. That means this kind of pattern, as a service pattern, is happening all over the place in other industries, not only in banking. That leads us to a giant Lego box of building blocks that we can now assemble products from really quickly.

Strategies in an Open Banking Environment

On the x-axis is the “ownership of the customer relationship (internal or external).” On the y-axis is the origination of the banking product. In the middle, we have a mix; something is internal, something is external. And then, we get this three-by-two matrix, where we can look at strategies for each.

The traditional bank has everything internal, so the customer relationship is internal, and the banking product is internal. 

In Banking as a service, the channel is no longer owned by the bank; the channel is now owned by someone else. The bank provides only the banking product; it is only an API provider. We have no strategy for plug-and-play banking, where a bank still owns the channel. But in addition, it sources banking products, not only from itself but also from external sources, other banks, or other FinTech players. 

Then we have banking as a platform where the bank is a broker, and it has both a channel that adapts to the customer and sources its products from different sources. In addition, it provides its product also by other channels of a partner. 

Then we have a strategy that’s only interesting for FinTechs that are not banks. These are the consumers of banking as a service. Of course, banks can be consumers of banking as a service. But equally, non-banks can do that as well. 

Then we have a pure marketplace. And a pure marketplace means they don’t have the product; they don’t have the channel. They’re just a broker of banking as a service product in the middle. 

The top two strategies are actually for non-banks that look like banks as a result of using those banking as a service offers. And the bottom four strategies are strategies that banks can apply.