How to Build a National Open Finance Ecosystem: A Guide for Regulators and Central Banks

The UAE built a fully operational national Open Finance API Hub in 12 months, the UK took nearly five years and Brazil took almost three. This guide examines what made that speed possible, and what regulators and central banks need to get right to achieve the same.

What this guide covers:

• Why a centralised hub model consistently outperforms decentralised approaches on cost, speed, and regulatory oversight (the UAE saw banks cut compliance costs by over 80%)
• The six building blocks that determine whether a national open finance programme succeeds or stalls
• A realistic 12-month delivery timeline, drawn from the UAE programme itself
• The coalition model: which roles need to be filled, and by whom
• The commercial case for building this infrastructure now, not just the compliance case

Who it’s written for: Central bank governors, heads of financial regulation, policy directors, and technical architects responsible for turning a regulatory mandate into operational national infrastructure.

Twelve months. That’s how long it took the Central Bank of the UAE to go from regulatory vision to a fully operational, national-scale Open Finance API Hub — live across the country’s largest banks, with the foundation to serve 200+ financial institutions.

The UK took almost 5 years. Brazil took nearly 3. The UAE did it in one.

That’s not just an impressive statistic. It’s a signal that the model for building national open finance infrastructure has fundamentally changed — and that regulators entering the space today don’t have to repeat the mistakes or the timelines of the markets that went before them.

This guide draws on Ozone API’s direct experience designing, building, and operating national open finance infrastructure around the world. It’s written for the people making the decisions: central bank governors, heads of financial regulation, policy directors, and technical architects charged with turning a regulatory mandate into something real, operational, and lasting.

Why a National Approach Changes Everything

Most early open banking markets took a decentralised approach. The regulator set the rules. Each individual bank went away and built its own compliant API infrastructure. The result was a patchwork: inconsistent implementations, fragmented developer experiences, duplicated compliance costs, and an ecosystem that third-party providers found difficult to navigate.

The UK Open Banking model, while groundbreaking, followed this pattern. Progress was real, but slow. Coordination across nine major banks, with each institution responsible for its own implementation, created friction at every level: technical, commercial, and regulatory.

The lesson from that experience — and from Brazil’s phased multi-year rollout — is that decentralised delivery pushes the complexity down to institutions that are not best placed to absorb it.

A centralised national infrastructure model inverts that logic. Instead of asking 200 banks to each solve the same problems independently, you build the shared infrastructure once, build it to the highest standard, and let every institution in the market connect to it. The regulator gets consistent oversight. The banks get dramatically reduced compliance costs. The fintechs and third-party providers get a single, standardised integration point. Consumers get coherent, trustworthy data-sharing controls.

The UAE’s API Hub is the clearest proof of what this model can deliver at speed.

The UAE Blueprint: What Actually Happened

In 2024, the Central Bank of the UAE launched its Open Finance Framework as part of its broader Financial Infrastructure Transformation (FIT) Programme. The ambition was significant: build one of the most comprehensive open finance frameworks in the world, then bring it to life in real banking infrastructure, all within 12 months.

The first six months focused on regulatory design and technical standards. The CBUAE, working with Ozone API and consortium partners (Core42, Raidiam and Strategy&) developed a framework that ranked among the most thorough globally. Not an adaptation of an existing standard, but a genuinely considered design built for the UAE’s financial landscape.

The second six months were about delivery. The API Hub went live: a secure, consent-driven platform sitting at the centre of the UAE’s financial sector, enabling interoperability between licensed financial institutions and third-party providers. Over 20 banks onboarded ahead of regulatory deadlines. Multiple fintechs accessed sandbox environments and began integrating with production APIs from day one.

This was not a pilot. It was national infrastructure, built to production standard, operating at scale.

The Six Building Blocks of a National Open Finance Ecosystem

Based on this and other deployments, there are six areas that determine whether a national open finance programme succeeds or stalls.

1. Regulatory Framework and Technical Standards
2. Architectural Choice: Centralised Hub vs. Decentralised Model
3. Security and Trust Architecture
4. Inclusive Onboarding and Industry Alignment
5. Ecosystem Activation: Getting TPPs and Fintechs Engaged Early
6. Designing for Expansion, Not Just Compliance

1. Regulatory Framework and Technical Standards

The framework and the technical standards are inseparable. A well-written policy document means very little if the technical specification that banks must implement is ambiguous, incomplete, or inconsistent with international security standards.

The UAE’s approach was to treat these as a single workstream. Regulatory intent was translated directly into technical requirements, with alignment checked at every stage. The result was a standard built on FAPI 2.0, incorporating best-in-class security, strong customer authentication, and token-based consent — meeting and exceeding global benchmarks from the outset.

Regulators designing frameworks today should resist the temptation to produce regulatory text first and technical standards later. The two need to be developed together, ideally by people with experience on both sides of that boundary.

Q: Ozone API was founded by the original architects of the UK Open Banking standard. Looking back at how that standard was designed versus how you’d approach it today, what would you do differently? What are the most common mistakes you see regulators make when designing technical standards for the first time?

A: There are a few mistakes we’ve seen around the globe. One is assuming you can just copy and paste a standard without understanding local context and requirements. A further challenge in a number of markets is the lack of the right conformance and certification infrastructure. Standards can sometimes be interpreted in different ways, so conformance testing and certification helps ensure everyone builds consistently, reducing the fragmentation that has slowed  down adoption in a number of markets. Finally it is important that there is a clearly defined objective supported by prioritised use cases. Ideally also a clear vision for how value will be created for the banks and financial institutions.

– Huw Davies, CEO/CO-FOUNDER

2. Architectural Choice: Centralised Hub vs. Decentralised Model

This is the most consequential decision a regulator will make. It shapes everything that follows: cost structure, compliance burden, governance, timeline, and the long-term health of the ecosystem.

A centralised hub model removes much of the complexity for participants. A single platform, built to the highest technical and security standards. Banks and Financial Institutions connect to it, rather than each building their own compliant API layer. In turn, this makes it much easier for TPPs to connect. And the regulator can monitor the entire ecosystem in real time, from a single point of visibility.

In the UAE, this model reduced average compliance costs for licensed financial institutions by over 80% compared to previous bespoke solutions. Banks that previously needed 6 to 12 months to build compliant APIs could now integrate with the Hub in a fraction of that time. For the regulator itself, the centralised architecture delivers multi-million dollar annual savings by replacing manual, fragmented oversight with automated, data-driven supervision requiring a much smaller team

Decentralised models have their place, particularly in very large markets where a single hub creates concentration risk. But for most markets, the centralised approach is faster, cheaper, and more controllable.

3. Security and Trust Architecture

Open finance infrastructure will only attract adoption if participants trust it. That trust is built through the security architecture, the trust framework governing who can connect, and the consent model that puts customers in control.

The UAE’s API Hub incorporated mutual TLS, dynamic consent, strong customer authentication, and tokenised access from the start. These were not bolted on after launch; they were designed in from day one, as foundational requirements rather than optional enhancements.

Parallel to the technical security layer, the trust framework defines who is authorised to connect to the hub: how third-party providers are registered, validated, and monitored. Raidiam handled this for the UAE’s implementation, providing the participant governance layer that keeps the ecosystem trustworthy as it scales.

Regulators should treat the trust framework as critical infrastructure in its own right. A technically excellent API hub connected to poorly governed participants is still a security liability.

4. Inclusive Onboarding and Industry Alignment

One of the biggest risks in a national rollout is that larger, better-resourced institutions reach compliance while smaller ones fall behind. This creates a two-speed ecosystem that undermines the goal of universal interoperability.

The UAE programme addressed this through centralised onboarding support, standardised technical documentation, and a certification process that was designed to accommodate institutions at different levels of digital maturity. No bank or FI was treated as too small or too complex to integrate. The inclusive model was a direct factor in the programme’s success.

The implication for other markets: onboarding should not be left entirely to each institution’s internal teams. The central programme needs to provide active support, clear tooling, and a structured certification path that every institution can follow, regardless of their starting point.

5. Ecosystem Activation: Getting TPPs and Fintechs Engaged Early

Building the infrastructure is necessary. Filling it with useful services is what makes open finance valuable to consumers.

In the UAE, third-party providers and fintechs were given access to sandbox environments as part of the initial rollout, not as an afterthought. This meant that by the time production APIs went live, there was already an engaged developer community ready to build on them. Ecosystem adoption started from day one.

This sequencing matters. Regulators often focus their energy on getting banks to comply, and treat TPP onboarding as a later-stage problem. That approach creates a gap: banks are compliant, but there’s nothing for consumers to actually use. Sandbox access and early TPP engagement should be built into the programme timeline from the outset.

6. Designing for Expansion, Not Just Compliance

The UAE’s API Hub was not designed purely to meet the initial regulatory mandate. It was built as infrastructure that could grow: from the initial eight tier 1 banks to 200+ financial institutions, and from open banking into open finance, covering insurance and beyond.

This distinction matters enormously. Infrastructure built to meet a compliance deadline tends to be rigid. Infrastructure built as a platform for the country’s financial future is modular, extensible, and aligned with international standards from the start.

It also tackled the all important of commercialisation from the outset. Banks and FIs need to be a part of a balanced commercial ecosystem for the true potential to be fulfilled and for the benefits to be sustainable. The model is designed to be lower cost for banks, but also with a clear path to revenue generation. From day 1 a commercial framework was designed for open banking payments. The framework will also deliver more and more embedded finance capabilities to help turn the API channel into a genuine growth channel for banks and FIs.

The difference in design effort between these two approaches is smaller than it seems. The difference in long-term outcomes is very large.

Learning from the Benchmarks: UK, Brazil, and UAE

Every market that has gone through this process offers lessons. The three most instructive are the UK, Brazil, and the UAE.

The UK (from 2016): Pioneered the concept of regulated open banking with a focus on the nine largest banks. The decentralised model produced real results but required years of iteration, coordination, and enforcement. The UK’s experience gave the rest of the world a detailed map of what could go wrong. Every subsequent market has benefited from it.

Brazil (from 2020): Took a phased approach across multiple stages, expanding from payments to financial data to open insurance. Well-designed in principle, but the multi-year phasing created sustained implementation burden for participating institutions. Brazil’s framework became a reference point for regulatory ambition; its timeline became a cautionary note.

UAE (from 2024): Skipped the trial-and-error stage by learning directly from earlier markets, applying a centralised hub model, and partnering with teams that had built this type of infrastructure before. The result: full national implementation in 12 months.

The pattern is clear. Each successive market has moved faster, because each one inherited the learning of the markets before it. A regulator launching an open finance programme today does not need to repeat any of the early mistakes. The knowledge exists. The technology exists. The question is whether the institutional will and the right partnerships are in place to act on them.

Q: You’ve now worked with regulators and central banks across multiple regions. What separates the programmes that move quickly and succeed from the ones that stall? Is it primarily a regulatory question, a technical question, or something else entirely?

A: The key driver for moving quickly is a regulator with both a clear vision and a strong mandate. The vision is essential to set clear objectives for the programme and then to understand what to copy from other markets, and what to adapt, in order to deliver against these objectives. Part of this is ensuring the framework is commercially beneficial for banks and FIs, as well as TPPs. The mandate is needed to make quick decisions (based on industry feedback), to publish a common standard, with clear business rules, and then to enforce adherence to this.

– Chris Michael: CO-CEO/CO-FOUNDER

The Coalition Model: Why No One Succeeds Alone

One thing the UAE case study makes plain: national open finance infrastructure is not a technology project. It is a coordination challenge that happens to involve technology.

The UAE programme succeeded because of the coalition that delivered it. The Central Bank of the UAE provided regulatory oversight and strategic leadership. Al Etihad Payments (AEP) handled operational delivery under the FIT Programme. Nebras, a not-for-profit special purpose vehicle founded by the central bank, acts as the ongoing ecosystem operator. Core42 led the delivery consortium and programme management. Raidiam provided the trust framework and participant governance. Strategy& aligned policy and commercial considerations. Ozone API designed the open finance framework, built the core platform, and operates the Hub.

Each of those roles was essential. Gaps in any one of them would have slowed or stopped the programme.

Regulators designing national programmes need to think in these terms from the start. Which of these roles can we fill internally? Which requires external expertise? Where are the gaps in our coalition?

The answer shapes the procurement strategy, the timeline, and ultimately the outcome.

What to Expect in the First 12 Months

For regulators early in the process, here is a realistic view of what a well-run national open finance programme looks like across the first year.

Months 1–3: Regulatory and technical design. This is the foundational stage: defining the scope of the framework, selecting the architectural model, developing technical standards, and building the coalition. Rushing this stage is the most common cause of problems further down the line.

Months 4–6: Platform build and sandbox launch. The central infrastructure is built and tested. A sandbox environment is made available to TPPs. A pre-production environment is made available for banks and FIs. 

Months 7–9: Integration and testing. Early onboarding begins for the first cohort of institutions. Institutions complete the certification process and begin connecting to production infrastructure. The regulator provides onboarding support.

Months 10–12: Staged go-live. TPPs connect to production accounts and test with real data.. The regulator monitors early data flows and iterates its support model. The full initial cohort is live.

Months 12 onwards: Scale and consolidation. Ecosystem activation continues with TPPs. Lessons from the first cohort inform onboarding for subsequent institutions.

This is not a hypothetical timeline. It is, broadly, what happened in the UAE.

The Commercial Case for Central Banks

Open finance infrastructure is often framed as a cost. The honest framing is that it is an investment with a measurable return.

For the financial institutions connecting to a well-designed hub, the compliance cost reduction is significant. The UAE’s data is specific: over 80% reduction compared to bespoke solutions, with integration timelines for each bank/FI cut from 12 months down to a fraction of that.

For the regulator, the centralised model replaces expensive manual oversight with real-time, automated supervision across the entire ecosystem. The multi-million dollar annual savings in governance costs represent a direct return on the infrastructure investment.

And beyond compliance, open finance infrastructure creates the conditions for a new generation of financial services: account-to-account payments, embedded finance, data-driven credit, and hyper-personalised products. Those services drive economic activity, financial inclusion, and the kind of fintech ecosystem that attracts investment and talent.

The question is not whether a country can afford to build this infrastructure. It’s whether it can afford not to.

A Final Word on Speed

The UAE’s 12-month delivery has become a reference point for what is possible. What the UAE demonstrated is not that fast is always better, but that the conditions for fast delivery can be deliberately created.

Clear regulatory mandate. Centralised technical model. An experienced delivery coalition. Active support for industry participants. Early ecosystem engagement. These are the conditions. When they are in place, 12 months is not ambitious. It is achievable.

For every regulator and central bank working through the design of a national open finance programme: the blueprint exists. The tools exist. The precedent exists. What the UAE proved, more than anything, is that the choice of how quickly and how well you do this is largely yours to make.

Ozone API was founded by the original architects of the UK Open Banking standard. We design, build, and operate open finance infrastructure for central banks, regulators, and financial institutions across the world. To talk about what a national open finance programme could look like for your market, get in touch.