Huw Davies
I’ve recently got back from the Open Banking Expo UK and Europe where I was privileged to chair the main stage. The conversation I witnessed most, both on stage and in my direct discussions around the Expo, was the topic of commercialisation.
More pointedly, that commercialisation, or more accurately the lack of, is the real barrier (or the next frontier) to really unlock the potential of open banking.
According to Fortune Business Insights, the global open banking market reached $29.72 billion in 2024 and is projected to grow to $128.89 billion by 2032. In the UK, 31 million payments were made in March 2025 alone. But here’s the problem: without balanced commercial incentives it’s just a compliance project. With the right incentives, the case changes completely.
I’ll be honest, a lot of the discussion at the Expo was a little too binary around whether it’s OK to charge for access to data and APIs or not. Personally I think it’s a lot more nuanced.
So what’s the impact of open APIs on the business model for banks? In my view, the APIs should become a — or maybe THE — channel for how banks embed what they do wherever customers need it.
The primary channel for banks for many years was the branch. This wasn’t just a cost. It was a sales and revenue generating channel. APIs should be the same.
Most open banking initiatives to date have been a result of regulation. A mandate from a central bank or regulator that requires banks to open up access in order that trusted third parties can deliver propositions and use cases based on consent based access to a customer’s account.
Typically the banks are told they have to do it. Moreover, they are often told they have to do it for free.
It has also proven to be pretty complex. I’ll be honest, that’s why we built Ozone API, to take away the cost and complexity and to help banks deliver great open APIs quickly and simply. But for many it has been complex and costly, not just for the initial build, but every time the frameworks and standards change.
At the same time, the strategy teams within banks have also been concerned that this access is a risk, opening the door for third parties to whisk customers and their lending or balances away.
Whilst the thinking of banks has moved on and they are now often the biggest beneficiaries of open banking access. The ground was laid for this to be seen as a compliance project.
I’ve been in banking for 30 years now. Compliance projects secure investment with certainty, but typically deliver to just “tick the box”. Whereas an initiative that is seen as highly strategic and value creating tends to take a longer path to secure investment, but results in efforts to do way more than tick the box.
Open APIs should really be both. And the JP Morgan bombshell earlier this year about charging third parties to access their APIs has started to make that a more real consideration.
So back to the branch analogy. If you think about it, branches generated revenue through footfall, cross-selling, and relationship building. Open banking APIs can do the same thing, but digitally and at scale. They can be embedded in accounting platforms, e-commerce checkouts, point-of-sale systems and financial management apps.
The difference? Unlike branches with limited geographic reach, APIs have unlimited distribution potential.
So what are the different types of open banking APIs and how do banks monetize? I’ll talk now about 3 types of API business models:
This first model is what drives most of the open banking usage and use cases today. In fact, often regulation will mandate that certain access is a consumer data right and the banks should not charge for it. Long gone are the days where banks charge for statements and access to basic information such as balances and transactions. Now it’s just the right thing to do. It allows customers to embed their financial lives in the digital platforms they use.
Whether mandated or not, enabling secure, consent-based data access is just the right thing to do. It also acts as the foundation to get embedded in important channels that customers use, such as cloud accounting platforms, financial management platforms and the likes. It also lays the foundations for increasing access to credit and reducing the risk of default.
I mentioned nuance. I think there are arguments that there can also be charging models for data access which I’ll get to shortly.
So onto the second model, premium APIs. There are a number of potential use cases and models here, so I’ll bring a few to life to make the point (but stop short of too many).
Let’s start with the obvious. There are a number of premium open banking API use cases that are easy and less controversial.
Payments is a key area. In fact, payments is an area with real costs and real (and often expensive) liabilities. So I would argue there should be a commercial and liability model for person/business to business/government payments. A fee for the third party to initiate the payment and a liability framework for when things go wrong and there’s a dispute. This is essential to really unlock account to account payments for things like e-commerce, bill payment and point of sale.
The numbers back this up: open banking payments in the UK grew 72% year-over-year in 2024, with 31 million payments processed in March 2025 alone, valued at £12.9 billion. Payment initiation APIs represent a clear monetisation opportunity that third parties understand and accept.
There are also premium API use cases around enriched data access. One obvious example is banks acting as secure identity providers for customers. They invest heavily in KYC checks and identity validation. So they’re well positioned to expose APIs that give access to identity attributes and make it easier for third parties to onboard, identify and verify customers. An often costly area that third parties will pay for. The question is whether there’s still time for banks to step into this role or are Big Tech already there?
Here’s the nuanced bit around charging models for more, more frequent or higher fidelity access to the account data I talked about in the first section.
This is the moment heckles may start to rise. I strongly believe that in a modern digital economy, it makes sense to have a basic data right. But if we look across third parties the level and type of usage varies dramatically. Some third parties create a much heavier burden on the bank API infrastructure as they call the APIs for more information and more frequently than others (and possibly beyond what’s really needed). So I think there’s a valid argument for “free access” to a level (that could be frequency and depth of data request) and a paid for “unthrottled” access for more and more often. I hear more and more banks talk about this. It certainly requires more platform sophistication (we know, we do this) but it’s a very logical and justifiable model.
The final category is about really turning the APIs into a channel. Think for a minute about Google Maps. A great product and its APIs are the channel that means it can be (and is) embedded in apps of all types. The APIs are an incredible sales channel for maps.
The same opportunity exists for banks by enabling their product journeys to be accessible via APIs so that they can be easily embedded wherever a financial intervention (such as access to credit) solves a problem. Finance that is embedded…..if only there was a name for that?
The historic challenge with embedded finance is that it’s based around proprietary APIs of a single product provider.
For scale this needs to be based on the same design principles of open banking APIs. The same security model, the same approach for third parties to onboard, the same consent model. That allows the right combinations.
The embedded finance market is projected to reach $248 billion by 2032. But to capture that value, we need standardized approaches, not one-off integrations.
For example, imagine an SME is in their accounting platform which forecasts a cash crunch coming based on a series of invoices that are habitually paid late. That’s the moment to embed access to credit from a financial institution. A journey could commence which combines account information requests with a credit application request.
The good news is that we’re now seeing open banking and open finance standards evolve to include these kind of service initiation use cases. Things like account opening APIs, insurance quotes, credit requests. And all based on the same standardized principles and protocols. A much more likely route to scale for both banks and third parties.
Again, we know. We’re designing the standards for markets and delivering these capabilities for banks through our platform.
If banks get this right then anywhere where access to or the movement of money becomes a potential sales channel. At that point this is no longer a compliance exercise. This is a highly strategic channel.
Open banking is definitely global. It definitely has significant momentum. And it’s definitely creating value in economies and helping make people’s lives easier.
But the true potential hasn’t been reached yet. In fact not by a long shot.
There are of course other big enablers of scale, such as extending the scope to open finance and open data across other sectors. The impact of that will be seismic. But even then the missing piece is the balanced and sustainable economic model.
If you can’t “show me the money” then the potential will always be limited.
I know this topic can be controversial. If you’re a bank and want to talk, I’d love to discuss. If you’re a third party and I’ve just triggered you. I’d love to discuss. Get in touch here.
How can banks monetise open banking APIs? Ozone API CEO & Co-Founder explores 3 commercial models to turn APIs into profit.
Huw Davies
How Brazil built a comprehensive open finance ecosystem in 5 years with 700+ participants and 60M+ users—leapfrogging from follower to global leader.
Section 1033 US open banking regulation faces uncertainty as JP Morgan Chase introduces fees, CFPB changes stance, and industry awaits regulatory clarity.
Discover the top 5 benefits of early adoption in Open Finance — from gaining first-mover advantage to unlocking new revenue streams. Learn how your institution can lead, innovate, and shape the future of financial services.
