When a central bank or regulator sets out to mandate open finance, one of its earliest and most consequential decisions is architectural: how should the data actually move between institutions? The choice comes down to two broad models — decentralized and centralized — plus hybrids in between, each with real tradeoffs in cost, speed, and supervision, and it tends to lock in for years.
There is no universal winner. A decentralized model suits markets with mature banks and strong supervisory capacity; a centralized national hub suits fragmented markets that need speed, interoperability, and lower per-bank cost; a hybrid blends the two. The right choice depends on four things: whether a capable operator exists to run it, whether trusted national rails already exist, funding, and how fast you need a working ecosystem.
That single decision — made early, often irreversibly — shapes the cost, timeline, and competitive dynamics of a national open finance program for a decade. Below is how the models actually differ, and a practical framework for choosing between them.
What do “centralized” and “decentralized” open finance actually mean?
The terms describe where connectivity and data flow live, not whether a regulator is involved. Every credible program has a central authority setting standards. The difference is what sits in the middle.
In a decentralized model, each bank builds and operates its own APIs against a common standard. A central body publishes the specification, runs a directory or trust registry, and certifies conformance — but data flows point-to-point between the data holder and the licensed third party. The United Kingdom is the reference case: the nine largest banks each expose their own endpoints to the Open Banking Standard, coordinated by a central entity that manages trust and conformance rather than traffic. Saudi Arabia (SAMA) and Bahrain apply broadly the same decentralized approach, with each bank exposing its own APIs to a common standard.
In a centralized model, a single national hub intermediates connectivity. Consent, routing, and often data delivery pass through shared infrastructure operated by a central player — frequently the national payments network or a regulator-backed entity. India (via its Account Aggregator network) and Singapore (via SGFinDex) sit here today; the UAE (through CBUAE subsidiaries Nebras and Al Etihad Payments) and Qatar are building the same hub model, and Malaysia’s PayNet-operated hub goes live in 2027. Banks connect once, to the hub, instead of maintaining bilateral links with every participant.
A hybrid model centralizes some functions — the directory, consent management, conformance, standardized connectivity — while allowing direct connections for others, or phases from one toward the other. In short: central rules and a shared directory, but data that still flows peer-to-peer. Brazil is the best-known variant: strong central governance and a shared directory, with data flows distributed across participants.
How do the models compare?
| Dimension |
Decentralized |
Centralized hub |
Hybrid |
| Who builds connectivity |
Each bank |
Central operator |
Shared + bank-level |
| Reference market |
United Kingdom, Saudi Arabia, Bahrain |
India, Singapore, Malaysia, UAE, Qatar |
Brazil |
| Time to a working ecosystem |
Slower — each bank runs its own dev portal and onboards API users (TPPs/FIs) |
Faster — connect once to the hub |
Moderate |
| Cost per bank |
Higher (build + run own APIs) |
Lower (shared infrastructure) |
Mixed |
| Interoperability |
Depends on strict conformance |
High by design |
High for centralized functions |
| Supervisory load |
Distributed, harder to monitor |
Concentrated, easier to observe |
Moderate |
| Best fit |
Many capable banks, strong oversight |
Fragmented or capacity-constrained markets |
Balancing scale and bank autonomy |
Why do most emerging markets choose a centralized hub?
Because it removes the two things that most often stall a program: cost and coordination. A decentralized model assumes every participating bank has the engineering capacity to build, secure, and maintain standards-compliant APIs — and the appetite to fund it. In markets where a handful of large banks hold most of the assets and mid-tier banks run lean IT teams, that assumption breaks. Timelines slip to the slowest participant.
And banks ship in both models — the difference is what a decentralized model asks of each one: build and run its own developer portal, and onboard every third party (other FIs or TPPs) itself. That is why a decentralized market usually needs an AISP/PISP aggregator layer to become usable — the role Brankas plays in the Philippines and Indonesia, Plaid in the US, and Lean in the Middle East — and that layer itself takes time to emerge and mature.
A national hub collapses that problem. Banks integrate once, to shared infrastructure, and the operator handles routing, consent orchestration, and conformance centrally. It is cheaper per institution, faster to reach critical mass, and far easier for a regulator to supervise, because activity is observable in one place rather than across dozens of bilateral links.
The trade-off is real: a hub is a single point of dependency and requires an operator capable of running critical national infrastructure. That is precisely why the choice of operator matters as much as the choice of model.
Case in point: India’s Account Aggregator network
India offers the clearest live illustration of the centralized logic. Under the Reserve Bank of India’s framework, licensed Account Aggregators sit between the banks that hold data and the lenders and fintechs that want it: a bank connects once to the network, and any authorised provider can then pull consented data through it, rather than integrating with each institution one by one. The framework has been live since 2021 and now spans most of the country’s major banks, operating at national scale.
Malaysia is pursuing the same centralized route with its PayNet-operated hub, but its first institutions only go live in 2027, making it one to watch rather than a system you can study in production today. We unpack the readiness, regulatory timeline, and commercial opportunity in our Malaysia Open Finance Market Report.
India went this route because its conditions pointed there: a vast, fragmented banking market, uneven engineering capacity across thousands of institutions, and a regulator (the RBI) willing to stand up shared consent infrastructure. Change those conditions and the answer changes with them.
How should a regulator choose?
- Is there a capable operator to run it? A central hub only works if the central bank or a trusted subsidiary has the technical capacity to build and operate national infrastructure — as BNM does through PayNet, or the CBUAE through Nebras and Al Etihad Payments. Where that capability is absent, a decentralized model with an aggregator layer may be a more realistic path.
- Do you already have national rails to build on? Markets with trusted, interoperable payment infrastructure can extend it into open finance far faster than those starting cold.
- Who funds it, and how? Decentralized shifts build-and-run cost onto each bank. A hub concentrates cost but lowers the total and the per-bank burden, provided a viable operator and funding model exist.
- How fast do you need an ecosystem? If the mandate has a hard deadline, a hub reaches live use cases faster because banks integrate once, not n times.
In practice the first two questions dominate: where a capable operator and trusted rails are both present — Malaysia (PayNet), the UAE (Nebras) — a hub is usually the shortest path to scale; where they are not, a decentralized model plus an aggregator layer is the more realistic route.
Frequently asked questions
What is the difference between centralized and decentralized open finance?
In a decentralized model, each bank builds and runs its own APIs to a common standard, and data flows point-to-point. In a centralized model, a single national hub intermediates connectivity, consent, and often data delivery. Both rely on a central authority for standards; they differ in what sits in the middle.
Which countries use a centralized open finance model?
India (via its Account Aggregator network) and Singapore (via SGFinDex) operate live centralized models; the UAE (CBUAE / Nebras) and Qatar are building the same hub model, and Malaysia’s PayNet-operated hub launches in 2027. The United Kingdom, Saudi Arabia, and Bahrain are decentralized, and Brazil is the best-known hybrid, pairing strong central governance with distributed data flows.
Is a centralized hub better than a decentralized model?
Neither is universally better. Centralized hubs tend to be faster to scale, cheaper per bank, and easier to supervise — advantages in fragmented or capacity-constrained markets. Decentralized models suit markets with many capable banks and strong oversight. The right answer depends on whether a capable operator and trusted national rails already exist, on funding, and on how fast you need an ecosystem.
What is a hybrid open finance model?
A hybrid centralizes some functions — such as the directory, consent management, and conformance — while allowing direct or bilateral connections for others, or phases from one model toward another over time. It balances the scale benefits of a hub with bank-level autonomy.
How long does it take to launch a national open finance ecosystem?
It varies with the model and market, but a centralized hub typically reaches live use cases faster because banks integrate once to shared infrastructure rather than building bilateral connections with every participant.
Todd Schweitzer is Co-founder and CEO of Brankas, an open finance infrastructure provider with live national implementations across APAC and MENA.
Scoping a national open finance framework? Talk to our team →