Phoebe Singer
Open banking revenue models are the commercial frameworks banks use to generate income from their open banking infrastructure, beyond the regulated minimum of free API access for licensed third parties. Regulation sets the foundation. What a bank builds above that base, and how it prices it, is what determines whether open banking becomes a cost centre or a new line of business.
Most banks have already built the infrastructure. The question that separates a compliance exercise from a commercial one is what happens next. This piece sets out the models available, the regulatory context that shapes them, and what makes each one viable in practice. For a primer on the underlying mechanics, see What Is Open Banking.
Open banking revenue models describe how banks turn API infrastructure into income. At the base layer, regulation (e.g. PSD2 in the EU, the open banking regulation in the UK) requires banks to give licensed third-party providers free access to account information and payment initiation. Above that regulated minimum, banks can build and charge for premium API products, platform and marketplace services, licensed banking infrastructure, and payment innovations such as commercial variable recurring payments. The regulated layer is a compliance cost; everything built above it is a commercial decision.
Under PSD2 in the EU and the open banking regulation in the UK, banks (as ASPSPs, or account-servicing payment service providers) must expose account information and payment initiation to licensed third-party providers, free of charge. Account information services (AISPs) can read transaction and account data with customer consent. Payment initiation services (PISPs) can trigger payments directly from a customer’s account. Article 36 of PSD2 is explicit that this access cannot be conditional on a commercial agreement or a fee.
The mandate covers licensed, FCA-authorised or nationally authorised TPPs, not the general public and not every developer who wants access. That distinction shows exactly where the regulated obligation ends and where a bank’s commercial discretion begins.
This is the floor, not the ceiling. Regulators built it to guarantee competition and consumer choice, not to design a bank’s product strategy. For more on how this mandate works in practice, see What Is Open Banking.
Banks that have built compliant open banking infrastructure have already paid for the hard part: secure APIs, consent management, TPP validation, data pipelines. The strategic question is whether that investment stays a sunk regulatory cost or becomes the foundation of a commercial platform. Four models are emerging as the main routes to revenue. They are not mutually exclusive, and most banks pursuing commercialisation will combine more than one.
Mandated APIs vs. Premium APIs
| What’s covered | Who can access | Regulatory basis | Who pays | |
| Mandated APIs | Account information, payment initiation | Licensed AISPs/PISPs only | PSD2 / CMA Order | Free, no charge permitted |
| Premium APIs | Enriched data, higher rate limits, identity and risk products | Any commercial TPP or fintech partner | Bank’s own commercial terms | Third parties, via subscription or usage |
Banks can charge for API access that goes beyond the regulated minimum: richer data endpoints (enhanced transaction categorisation, income verification, affordability signals), higher rate limits, or specialist products such as credit risk enrichment APIs.
The revenue mechanics follow standard API pricing: subscription tiers for predictable access, or usage-based per-call pricing for variable volume. Both rely on having an API business being in place: a developer portal, a published API catalogue, and clear SLA commitments. Without those, there’s no credible product to sell, whatever the underlying data is worth.
Banking as a Platform (BaaP) repositions the bank as an ecosystem orchestrator rather than a pure product provider. Third parties build their own products on top of the bank’s APIs and data, and the bank earns platform or marketplace fees, much as an app store earns from the developers building on it.
That means investing in developer experience (documentation, sandboxes, an API marketplace) as a product in its own right, since the third parties building on the platform are effectively the bank’s customers too. When done well, it turns the third parties into a distribution channel for bank products. The distinction from Banking as a Service is control: under BaaP, the bank still controls or co-shapes the customer-facing product, even where a partner builds the front end.
Banking as a Service (BaaS) licenses the bank’s regulated infrastructure (such as payment rails, account holding, and its banking licence) to fintechs or non-bank brands, who launch their own financial products under their own brand.
Revenue is typically usage-based: per-transaction charges, monthly minimum fees, or tiered access to specific regulated capabilities. The distinction from BaaP is where the brand sits. Under BaaS, the bank is largely invisible infrastructure; the fintech or brand owns the customer relationship. Both models can run from the same API catalogue, priced and packaged differently for different partners.
Variable Recurring Payments (VRP) let customers consent to flexible, recurring account-to-account payments with limits they set, rather than a fixed direct debit mandate. The CMA Order in the UK mandates sweeping as a, non-commercial case: moving money between a customer’s own accounts. Commercial VRP (cVRP) extends the same mechanism to third-party, merchant-facing use cases, and that’s where the new revenue sits: merchant acceptance fees for A2A payments, positioning banks as an alternative to card rails.
UK Finance published its cVRP Commercial Model Initial Findings in April 2025, examining how a commercial cVRP model might work, including who pays whom across the payment chain. This model is currently most developed in the UK. The EU is watching the cVRP debate closely as it shapes PSD3, which will decide whether a similar model gets mandated or left to commercial negotiation.
None of the four models above generate revenue on their own. They depend on infrastructure quality. API reliability, documentation and developer experience are what determine whether third-party providers choose to build on a bank’s APIs at all, and without that adoption there’s no base of paying customers for premium tiers to sell into.
In practice, that means banks pursuing commercialisation need to operate less like a regulated utility and more like an API product company: providing proper API versioning so partners aren’t broken by changes, real SLA guarantees, and developer support that treats TPPs as customers rather than as a compliance obligation to be tolerated. A standards-agnostic API platform that supports multiple regulatory frameworks and deployment models makes this easier to sustain, particularly for banks operating across more than one market.
The delivery choice matters too. Whether a bank runs its open banking infrastructure as SaaS or on-premise affects how easily it can scale into new markets and how it manages regulatory compliance across jurisdictions with different requirements. Consent management, often treated purely as a compliance checkbox, is in fact a commercial dependency: a consent framework customers trust is what lets a bank expand into new data sharing use cases and new premium products without constantly renegotiating trust from zero.
The commercial opportunity in open banking looks different depending on the regulatory regime a bank operates under, because each framework sets a different base and leaves a different amount of room above it.
The UK is the most mature market. The CMA Order roadmap is largely complete, the cVRP commercial model is actively being defined through the UK Payment Initiative, and attention is turning to open finance: extending the same data-sharing principles beyond payment accounts into pensions, mortgages, investments and insurance.
The EU, under PSD3, is working from a broader data scope than PSD2 covered. New data types and potential premium product categories are part of that expansion, though the region is still working through how much of the cVRP-style commercial model gets mandated versus left to individual banks and payment providers to negotiate.
The US, under Section 1033 and the CFPB’s rulemaking, has taken a different regulatory shape. There is no equivalent mandate forcing free access in the same way PSD2 does; that gives US banks more pricing discretion but also less of a regulatory forcing function pushing them to build commercial-grade infrastructure in the first place.
Brazil’s Open Finance framework has the broadest scope of the major regimes shared above, spanning multiple financial data types beyond payment accounts. That breadth creates richer data product opportunities than a payments-only mandate allows, though the level of opportunity still depends on which data holders build genuinely commercial-grade infrastructure on top of the mandate.
For banks tracking how these frameworks are evolving across markets, Ozone API’s Open Finance Tracker follows the global regulatory picture, and our piece on Open Banking 2.0 covers how open finance is extending the scope of what’s commercially possible beyond payment accounts.
For any banks wanting to talk about their options to monetise APIs, get in touch.
What is an open banking revenue model?
An open banking revenue model is a way for a bank to generate commercial income from its open banking infrastructure, beyond the free access it must provide to licensed third-party providers under regulation. Examples include premium API products, platform and marketplace fees, Banking as a Service licensing, and payment innovation revenue such as commercial VRP.
Are banks required to provide open banking APIs for free?
Yes, but only within a defined scope. Under PSD2 and the UK open banking regulation, banks must give licensed AISPs and PISPs free access to account information and payment initiation. That obligation does not extend to the general public, unlicensed developers, or to enhanced data and services beyond the regulated minimum.
What is the difference between a mandated API and a premium API?
A mandated API gives licensed TPPs free access to a narrow, regulator-defined set of data and payment functions. A premium API is a commercial product a bank builds and prices on its own terms, typically offering richer data, higher performance, or additional capability that sits outside what regulation requires.
What is Banking as a Service and how do banks earn revenue from it?
Banking as a Service (BaaS) is a model where a bank licenses its regulated infrastructure, such as payment rails, account holding capability and its banking licence, to fintechs or non-bank brands via APIs. Banks typically earn revenue through product fees and leanding revenues, usage fees, monthly minimums, or per-transaction charges, while the fintech or brand owns the customer-facing product.
What are Variable Recurring Payments and why do they matter commercially?
Variable Recurring Payments (VRP) let customers authorise flexible, consent-driven recurring account-to-account payments with limits they control. Commercial VRP (cVRP) extends this beyond the UK’s non-commercial sweeping mandate into merchant-facing use cases, creating a new revenue stream through merchant acceptance fees, as explored in UK Finance’s April 2025 Initial Findings.
How does a bank’s open banking infrastructure affect its ability to monetise?
API reliability, documentation quality and developer experience directly determine whether third-party providers will build on a bank’s APIs. Without that adoption, there is no base of paying customers for premium products, so infrastructure quality is a commercial precondition, not just an operational detail.
How does open banking monetisation differ between the UK, EU, and US?
The UK is the most mature regulated market, with the CMA Order largely complete and cVRP’s commercial model being actively launched. The EU’s PSD3 broadens the data scope beyond PSD2 but is still working through how much commercial structure to mandate. The US, in the absence of Section 1033, gives banks more pricing discretion but lacks an equivalent forcing function driving commercial-grade infrastructure.
What is open finance and how does it expand the commercial opportunity for banks?
Open finance extends open banking’s data-sharing principles beyond payment accounts into pensions, mortgages, investments and insurance, creating a much wider range of financial data products a bank can build and price. The UK, Australia’s Consumer Data Right, and Brazil are among the leaders in this expansion; our Open Banking 2.0 piece covers this shift in more detail.
Building any of these models raises implementation questions this overview doesn’t have room for. For the practical detail on specific API monetisation models, our CEO Huw Davies has written a companion piece looking at the specific API monetisation models banks are using, covering regulated APIs, premium services and embedded finance in more depth. For a structured route from strategy to execution, including a 90-day quick-wins assessment, see a practical guide to commercialising open banking.
Los bancos argentinos llevaban tiempo esperando saber qué les exigiría concretamente el esquema de Finanzas Abiertas (Open Finance). Esa espera concluyó con la emisión del Decreto 353/2025 en mayo de 2025. En la práctica, este decreto ubica a la Argentina en la misma senda regulatoria que los regímenes de Open Banking a nivel internacional. Aunque...
Fabio Caldeira
The Next Phase of KSA Open Banking Under the leadership of the Saudi Central Bank (SAMA), the Kingdom of Saudi Arabia continues to advance its Open Banking Framework as a core component of Vision 2030’s digital transformation agenda. Following the rollout of Account Information Services (AIS), the market is entering its next critical evolution: Payment...
An Ozone API & Finerio Connect Article Ask three regulators to build the same thing, in the same region, in the same decade, and you get three different roads. Chile, Colombia, and Peru are all building toward Open Finance. None of them are doing it the same way, and none of them are on the...
