The Rails Behind the Permission
Open finance is not governed by consent screens alone. The decisive question is who supplies the shared rules and connections that allow a permission to work across institutions. This chapter examines the three broad ways jurisdictions organise that problem—prescriptive, facilitative, and market-led—and then follows the architecture underneath them. By the end, readers should be able to judge whether a proposed open-finance system gives new providers a real chance to participate, or merely gives them a formal right to ask.
Three ways to open a financial system
A customer’s permission has little practical value if the institution holding the data can decide, case by case, whether and how an outside provider may connect. Someone has to coordinate the request format, identity checks, security expectations, liability, and the conditions under which a provider becomes eligible. Jurisdictions have addressed that coordination problem in three broad ways.
A prescriptive approach requires institutions to share customer-permissioned data according to specified rules. The rules may define common API standards, data fields, authentication requirements, registration or supervision for third-party providers, and deadlines or service expectations. The European Union’s Second Payment Services Directive created a harmonised regime for third-party access to payment accounts, including account information and payment initiation. The United Kingdom required its nine largest banks to fund and implement a common API standard and central directory. In both cases, the point of the mandate was not simply to announce a consumer right. It was to force enough of the system to use a common language for the right to become usable at scale.
This model addresses a coordination failure. If each incumbent can choose a different interface, a new provider must build and maintain a separate integration for each one. The cost is not only technical. The provider has to understand different approval paths, data definitions, error responses, and operational expectations. A mandate can reduce that duplication and prevent the largest data holders from withholding the infrastructure needed for competition. It can also impose compliance costs and lock in a standard that later needs to evolve. A prescriptive framework therefore trades some flexibility for a more predictable baseline.
A facilitative approach supplies guidance, technical playbooks, common principles, or a phased roadmap while leaving participation and the pace of adoption more voluntary. Singapore’s API Playbook is an example of this style; it sets out governance principles, data standards, and consent ideas without requiring every bank to participate in the same way. Hong Kong’s Open API Framework began with public product information and expanded in phases toward customer and transaction interfaces. Such arrangements allow institutions and markets to learn before every detail is fixed. They may be appropriate where authorities want to encourage innovation without immediately imposing a comprehensive obligation.
The trade-off is that voluntary coordination can produce uneven coverage. A bank may support an attractive data set while another supports only a narrow one. A provider may have to negotiate commercial terms or build around differences that a mandatory standard would have removed. Adoption can still become substantial, but it depends more heavily on the incentives of incumbents, the usefulness of the services, and the ability of industry participants to coordinate.
A market-led approach relies mainly on private agreements between financial institutions, fintechs, and aggregation services. The United States historically developed open-banking connections through bilateral arrangements, including API-based services and, in some cases, screen scraping, before moving toward a more formal consumer-permissioned data-rights framework. Market-led development can respond quickly to customer demand and commercial opportunity. It can also leave the system with inconsistent standards, uncertain responsibility, and limited access for providers that cannot negotiate with every important data holder.
These categories are useful because they identify where coordination lives; they are not a ranking. The choice depends on concentration in the banking sector, digital infrastructure, privacy law, institutional capacity, political economy, and the authority of the regulator. A country with strong industry coordination may achieve useful interoperability through guidance. Another may need a mandate because the largest institutions have little commercial reason to make their data portable. Even a mandated framework can underperform if the standards are incomplete, the participants are not supervised, or customers see no service worth using.
The distinction also explains why “open” is not binary. A framework may be formally open but practically narrow if only a few institutions participate, if the data fields are inconsistent, or if a third party can read information but not complete the customer journey. Conversely, a less prescriptive system may produce useful services in a particular market while leaving other customers or providers outside. Openness is a property of the whole arrangement: eligibility, coverage, interfaces, trust, price, reliability, and actual use all matter.
Where coordination lives
Policy rules sit above a set of technical and institutional components. The customer supplies permission. Data holders maintain accounts and records. Third-party providers use the data to offer a service or initiate an action. Identity and trust functions help the participants establish who is asking and who is allowed to receive information. APIs define how a request and response are expressed. A directory or switching service may help participants discover one another or move data between them. Regulators and industry bodies set or enforce rules, while payment systems carry some of the actions that write access can initiate.
The system can place more of those functions in a centralised arrangement. A common directory, identity-verification service, or data switch can give participants one place to connect. This simplifies onboarding and makes interoperability easier to coordinate. A new provider may not need to establish a completely different trust relationship with every institution. A common service can also make it easier to apply a shared technical standard and observe system-wide performance.
Centralisation creates a corresponding dependency. If a critical directory, switch, or trust service is controlled by one entity, that entity becomes important to the operation of everyone else. The central node can become a point of concentration in governance, infrastructure, and commercial power. The design must therefore answer questions about access, oversight, security, substitutability, and what happens if the central service changes its terms or becomes unavailable. Simplifying the connection does not remove the need to govern the connector.
A decentralised arrangement uses direct connections between data holders and recipients, usually under common technical standards. The European payment-account regime and Brazil’s open-finance model are described in the BIS report as examples of arrangements with more direct bilateral connections. This approach gives participants more flexibility and avoids placing every exchange through one central switch. But the cost is distributed rather than eliminated. Each participant may have to implement, test, monitor, and maintain more connections, and every change to a shared standard requires coordination across the network.
Neither architecture is a shortcut around trust. Centralisation can make participation simpler while concentrating dependency. Decentralisation can distribute control while increasing integration and coordination burdens. The relevant question is which functions benefit from a common service, which risks need independent control, and whether participants can change or replace a critical provider without breaking the customer’s access.
The important flows are not all the same kind of flow. Customer permission moves through a consent and identity layer. Financial information moves from a data holder to an eligible recipient. A reciprocal contribution can move in the other direction when the recipient is also a data holder. Governance decisions cut across the system rather than belonging to one API endpoint. The architecture determines how those flows are connected and who controls the interfaces between them.
Common data definitions matter because a connection is useful only if the recipient can interpret what it receives. Common APIs matter because a provider can request information without designing a private method for each bank. Authentication and eligibility rules matter because an open interface without a trustworthy way to establish identity is not a meaningful customer-protection mechanism. Consent layers matter because the system needs to connect the technical request with the customer’s purpose and authority. If any one of these is missing, the connection may exist while the service remains unreliable or unsafe.
This is where architecture becomes a competition issue. A new provider pays a cost every time it must integrate with a different interface, interpret a different data vocabulary, or negotiate access from a separate incumbent. Those costs may be manageable for a large platform and prohibitive for a small entrant. Standardisation can therefore lower a fixed barrier to entry even before the provider wins a single customer. It does not guarantee that the entrant has a better service, but it makes it more possible for the entrant to test one.
Reciprocity is a market rule, not just a technical feature
Open finance also has to decide who is expected to share. Reciprocity means that eligible participants can be both data holders and data users: an institution that wants to receive customer-permissioned information is also willing and technically prepared to contribute information it holds. The principle is attractive because it reduces the chance that one group is permanently forced to open its data while another group can keep its own information closed.
The concern is especially sharp when banks, fintechs, and large technology firms hold different kinds of data. Banks may hold transaction, account, lending, and payment records. A large technology firm may already possess behavioural, social, or commercial information about the same customer and may also provide infrastructure used by many other companies. If a framework requires financial institutions to share with third parties but does not establish comparable access to relevant data held by those third parties, the system can shift information advantage rather than remove it.
That does not make the answer obvious. Including large technology firms may give customers more choices and allow providers with strong infrastructure to build useful services. Their cloud, model, or distribution capabilities can lower the cost of experimentation. Excluding them entirely may reduce innovation incentives and the network effects that make a data-sharing system valuable. The decision is therefore not “banks open, technology companies excluded.” It is whether participation rules, reciprocity, competition safeguards, and third-party oversight prevent access from becoming a one-way transfer toward an already concentrated platform.
The same issue appears in cross-border services. A person or business that moves across jurisdictions may want to use a financial history in a new market, but domestic API standards, consent rules, data-sovereignty requirements, and trust frameworks may not align. A system can be open within each country and still be closed at the border. Cross-border interoperability therefore adds another coordination layer without erasing the need for local accountability.
Adoption begins with use, not permission
The design choices above shape how adoption should be measured. The BIS review reports that 95 jurisdictions had some form of open-banking or open-finance policy framework by 2024, but the number says little about how many customers can use a particular service. Jurisdictions count adoption in different ways: registered users, linked accounts, active consents, API calls, successful responses, participating institutions, or completed use cases. These measures describe different stages of the system.
For example, the report records 36 million open-finance subscribers and 194 million registered accounts in Korea in December 2023, while Brazil recorded 55 API calls per user per month in March 2025. Those figures cannot be treated as a simple league table. The Korean figures use subscriber and account measures, and the subscriber number may include people connected to more than one institution. The Brazilian figure measures API-call intensity at a different date and with a different denominator. One indicates reach; the other indicates repeated system activity. Neither alone proves that customers received better products or that benefits were evenly distributed.
A consent can also be created without being used, and a successful data call can occur without changing a customer’s financial outcome. A more demanding assessment asks whether customers can complete a useful task, whether providers can serve them reliably, whether switching becomes easier, whether payments or credit access improve, and who benefits from those changes. The BIS report notes that read-only services may attract a small financially sophisticated segment, while payment initiation can encourage faster uptake by embedding data sharing in everyday activity. That is a claim about a possible adoption mechanism, not a universal rule.
The system behind the permission therefore creates a set of conditions rather than a guaranteed result. Policy determines who must coordinate. Architecture determines where dependency and integration costs sit. Reciprocity determines whether data access changes or reinforces existing asymmetries. Measurement determines whether a headline describes nominal permission or lived use. Once those conditions are separated, the next question is sharper: what does the international evidence show about entry, competition, credit, and inclusion when an open-finance system is actually operating?