Open Banking Regulations Around the World: A Practical 2026 Guide

Open banking is often explained as an API project. That is only partly true.

An API is the road. A regulator or industry body still has to decide who may drive on it, what type of vehicle they may use, which journeys are permitted and who pays when something goes wrong.

That is why open banking looks different from country to country. Every framework is solving the same underlying trust problem:

“

How can a customer safely instruct one financial institution to share useful data—or initiate an action—with another service, without handing over their online-banking password?

This guide compares the main regulatory models as at 20 August 2026. It is written for founders, product leaders and operators rather than lawyers or engineers. It is a practical planning guide, not legal advice.

The four decisions every open banking framework makes

A country does not need to copy the UK or Australia to have open banking. It only needs workable answers to four questions:

1. Is access mandatory or negotiated? A regulator can require banks to participate, or banks and technology providers can negotiate access commercially.
2. What can the customer authorise? Some systems cover read-only account data. Others also allow payment initiation, switching, product applications or broader financial data.
3. Who is trusted to receive data? The recipient may need a direct licence, accreditation, registration, regulated status, sponsorship or a contract with each bank.
4. How is trust implemented? Common standards may define consent, authentication, digital certificates, directories, API security, conformance testing, complaints and incident reporting.

The easiest mistake is to compare countries only by their API specifications. The more important comparison is the permission model around those APIs.

Start with the service, not the licence

Before asking “How do we get accredited?”, define what the product actually does.

Read-only data is the lightest route

A budgeting tool that reads balances and transactions creates privacy and security risk, but it cannot move money. Many frameworks therefore give data-only providers a lighter registration route, or allow them to operate under a regulated principal.

Payment initiation adds a different class of risk

A payment initiation service does not normally hold the customer’s funds, but it can trigger an irreversible action. Regulators therefore focus more heavily on fraud, liability, authentication, operational resilience and professional indemnity insurance. In the UK and EU, this is the practical difference between AIS and PIS.

Holding money is another step again

If the product receives customer funds, issues stored value, operates accounts or remits money, open banking is only one part of the regulatory picture. Payment-institution, e-money, money-transmission, safeguarding and anti-money-laundering rules may also apply.

This leads to a useful rule of thumb:

Data access is a trust-and-privacy programme. Payment initiation is also a fraud-and-liability programme. Holding funds is a full financial-infrastructure programme.

United States: market-led first, federal rules still in motion

The United States developed open banking from commercial relationships rather than one national API mandate. Banks, data aggregators and fintechs negotiated access, security reviews and data-sharing contracts. This produced broad coverage, but also different API behaviours, uneven data quality and a continuing role for credential-based access at institutions without suitable APIs.

Section 1033 of the Dodd-Frank Act provides the statutory foundation for a consumer’s right to access financial information. The CFPB finalised its Personal Financial Data Rights Rule in October 2024. It defines covered data, authorised third parties, developer interfaces, privacy limits and the possible role of recognised industry standards.

The current position is more complicated than “the rule started in 2026.” According to the CFPB’s current compliance page, a federal court stayed the rule’s compliance dates on 29 October 2025. The CFPB had also begun reconsidering questions including who can act for a consumer, fees, data security and privacy. The rule remains part of the legal landscape, but the rollout timetable is not operating as originally announced.

What permission does a fintech need?

There is no single US equivalent of a UK AISP registration or Australian ADR accreditation.

A data-only product normally enters through one or more aggregators or through direct agreements with banks. Each provider performs commercial and security due diligence. Expect to provide:

• a clear data-use description and privacy notice;
• evidence of security controls, encryption and access management;
• incident-response and business-continuity plans;
• data-retention and deletion rules;
• consumer authorisation and revocation flows;
• subcontractor and onward-sharing controls; and
• production testing evidence.

The current federal rule text also places purpose, collection, use and retention limits on authorised third parties. The CFPB’s rule page is the right source for the live text and any future amendments.

If the product also moves money, separate federal and state payment rules may apply. “Connected to bank data” does not remove money-transmission or payment-network obligations.

The practical US launch process

1. Define the accounts, data fields and use purpose.
2. Choose an aggregator for coverage, or identify banks worth integrating directly.
3. Complete vendor and bank security reviews.
4. Build consent, account-linking, error recovery and revocation.
5. Map each provider’s data into one internal model.
6. Pass sandbox and production approval.
7. Monitor bank-specific failures, refresh rules and data-quality differences.

The US route is easier to start than a formal accreditation regime, but harder to make uniform. The cost moves from a regulator application into recurring aggregator fees, bank-by-bank exceptions and operational support.

Australia: the Consumer Data Right is a formal trust framework

Australia’s CDR begins from a different premise: if a sector is designated, data holders must share in-scope data through the regulated system when the customer gives valid consent.

Banking went first, energy followed, and non-bank lending is rolling out from 2026. The CDR is broader in legal design than “open banking” because it can apply across the economy.

For a data recipient, the central question is whether to become directly accredited or operate as a CDR Representative.

Route 1: become an Accredited Data Recipient

The official accreditation process is managed by the ACCC in its role as CDR Accreditor. A non-bank applicant normally needs to show that it:

• is fit and proper to manage CDR data;
• protects data against misuse, loss and unauthorised access;
• has compliant internal dispute resolution;
• belongs to a relevant external dispute-resolution scheme;
• has adequate insurance; and
• has an Australian address for service.

A complete application is only part of the journey. After accreditation, the recipient must complete register onboarding and conformance testing before it can receive live data. Official guidance has said applicants should anticipate around three months for assessment of a complete application; preparing the evidence and passing technical onboarding generally makes the end-to-end project longer.

Route 2: operate as a CDR Representative

A representative can provide a customer-facing service under a written arrangement with one unrestricted accredited principal. The principal makes the CDR data request and remains responsible for substantial oversight and liability. The representative must be entered on the CDR register before handling service data.

The OAIC’s representative guidance explains the important constraints: the representative receives CDR data only from its principal, may have one principal, and must follow the contract and applicable privacy safeguards.

This route removes the need for the representative to obtain its own unrestricted accreditation. It does not remove security, consent, privacy or audit work; it changes who proves and supervises it.

What the IT programme includes

A production CDR service typically needs:

• a public consent and data-use flow that follows CDR consumer-experience standards;
• a consumer dashboard for viewing and withdrawing consents;
• CDR-compliant identity and certificate handling;
• information-security controls and evidence;
• data minimisation, deletion and de-identification;
• consent, disclosure and incident records;
• register onboarding and conformance tests; and
• monitoring across bank APIs and scheduled standards changes.

The OAIC privacy safeguards explain why the programme is broader than API integration.

Does Australian CDR include payment initiation?

The legislation now permits the government to declare action types, but no broad CDR payment-initiation service equivalent to UK PIS is live. The Australian framework should therefore be described primarily as regulated data sharing. Payment products use separate Australian payment rails and permissions unless and until relevant CDR actions are declared.

United Kingdom: a clear split between AIS and PIS

The UK model is comparatively easy to explain because it distinguishes two regulated services.

• An Account Information Service (AIS) displays or analyses information from payment accounts. A provider may be a registered account information service provider (RAISP).
• A Payment Initiation Service (PIS) asks the customer’s bank to initiate a payment. A PISP must be authorised.

The FCA’s consumer explanation is a useful plain-English definition. The bank holding the account is called the Account Servicing Payment Service Provider, or ASPSP.

The direct application process

A typical applicant must first map its exact regulated activities. It then prepares:

1. a programme of operations and business plan;
2. governance, ownership and fit-and-proper information;
3. risk, fraud, incident and business-continuity arrangements;
4. security controls and a security-policy document;
5. complaints, outsourcing and data-protection processes;
6. professional indemnity insurance or a comparable guarantee; and
7. financial forecasts, capital evidence and a wind-down plan where applicable.

The FCA says an AIS-only provider can apply for registration, while a provider of PIS needs authorisation. Its security requirements page describes the information expected before and after permission.

The statutory decision target is three months after a complete application and up to 12 months after an incomplete one. That is a regulator review clock, not a promise that an unprepared company can launch in three months.

Application fees are not the expensive part

For applications made under the fee schedule effective from April 2026, the FCA lists a RAISP in Category 3, currently £1,130. A payment institution applying only for activities including PIS and/or AIS is in Category 4, currently £2,820. The FCA fee page is the live source and should be checked immediately before filing.

A PISP must also have at least €50,000 of initial capital under the retained payment-services framework, and both AISPs and PISPs require professional indemnity insurance or a comparable guarantee. These amounts are separate from the staff and build budget.

Can a company use an agent?

Sometimes. FCA perimeter guidance explains that a technical provider can support a registered or authorised provider without itself providing AIS to the user. An agent may present the principal’s AIS through its interface, but cannot hold itself out as providing AIS in its own right. The commercial wording, customer relationship, data flow and allocation of responsibility must match the legal structure.

The UK standards layer is changing, not disappearing

The CMA’s Open Banking remedy and Open Banking Limited created a common API ecosystem around the largest banks. In 2025, JROC was wound down and the FCA became lead regulator for the next phase. The FCA is supporting the development of a not-for-profit Future Entity for standards, subject to future legislation. Its 2026 update makes clear that transition work is still underway.

For an applicant, the practical point is simple: FCA permission and bank/API onboarding remain separate workstreams.

European Union and EEA: PSD2 permission, national supervision and passporting

The EU and UK share the AIS/PIS concepts because both were built around PSD2. They are now separate legal systems.

Under PSD2, an AIS-only provider is registered and a PIS provider is authorised by the competent authority in its chosen home member state. The application package covers the business model, governance, internal controls, security, insurance and—in the case of PIS—initial capital.

Once authorised, eligible services can be passported across other EEA states through the home regulator. The EBA central register aggregates national records, but the national competent authority grants the permission.

PSD2 sets a three-month decision period after a complete application. Real elapsed time is longer. The EBA’s December 2025 follow-up review found that the median EEA authorisation process, measured from initial submission, was 9.5 months, with incomplete applications and remediation driving much of the delay. That is a much better planning assumption than the statutory decision clock.

What makes the EU technically demanding?

The hard parts are not unique to Europe, but PSD2 makes them visible:

• strong customer authentication;
• common and secure communication with banks;
• digital certificates used to identify regulated parties;
• professional indemnity cover;
• incident and fraud reporting;
• local governance and substance expectations;
• bank-specific API behaviour despite a common legal framework; and
• cross-border notifications and operational support.

PSD3, the Payment Services Regulation and FIDA

PSD2 remains the applicable core framework. On 27 November 2025, the Council and European Parliament reached a provisional political agreement on a new Payment Services Regulation and amendments often called PSD3. Technical work and formal adoption were still required.

The separate Financial Data Access proposal, or FIDA, is intended to extend regulated sharing beyond payment-account data into wider finance. It should be treated as a developing open-finance framework, not as a current replacement for PSD2.

For a 2026 applicant, build for today’s PSD2 rules while keeping architecture and consent records flexible enough for the next regime.

Asia: several different models, not one regional regime

Asia is not “behind” Europe. It has chosen different institutional designs, often using national identity, payment and data-exchange infrastructure rather than a single PSD2-style law.

Singapore: shared infrastructure and partnerships

Singapore’s approach is guided and infrastructure-led.

The MAS and Association of Banks in Singapore developed a Finance-as-a-Service API Playbook to encourage open API architecture. SGFinDex then created a national consented data-exchange service using Singpass.

SGFinDex lets individuals retrieve financial information from participating banks, insurers and government agencies through participating applications. Its central identity and consent design is powerful, but it is not a general statutory right for any accredited fintech to access every bank.

For a new company, the route is normally to partner with a participating institution or negotiate bilateral API access. If the product provides regulated payment services, the separate Payment Services Act licensing perimeter must be assessed.

Accreditation process: there is no universal AISP application. Expect institution-level due diligence, product approval, security testing, local privacy compliance and, where applicable, payment licensing.

Malaysia: moving from encouraged APIs to open finance

Malaysia established industry Open API implementation groups and published recommended open-data API standards. This first phase encouraged institutions to expose selected APIs rather than creating a universal consumer-data right.

Bank Negara Malaysia’s public innovation register now lists a November 2025 Exposure Draft on Open Finance. It proposes secure, interoperable and timely consent-driven sharing across the financial sector. As at August 2026, BNM’s payments and banking document registers still list it as an exposure draft rather than a final policy document.

Practical route today: partner with a regulated institution, PayNet or another approved ecosystem participant; define a narrow use case; and treat direct open-finance accreditation requirements as still developing. A company should not budget as if a public UK-style application path already exists.

Thailand: Your Data becomes a mandated rollout

Thailand has moved from consultation to a phased regulatory programme. In October 2025, the Bank of Thailand issued rules requiring supervised financial providers to create secure, standardised mechanisms for customers to share financial data with other supervised providers.

The Bank of Thailand’s current Open Data page says implementation begins in late 2026 with personal deposit information, followed by loans and payment information between 2027 and 2028.

Accreditation process: this is initially a supervised-institution network, not an open register for any technology company. A standalone fintech’s practical route is therefore a partnership with an eligible provider, with detailed allocation of consent, security, data use and customer responsibility.

India: a regulated consent manager, not a data warehouse

India’s Account Aggregator system is structurally different from both PSD2 and CDR.

An Account Aggregator is an RBI-regulated NBFC that manages consent and mediates encrypted data flows. It is not meant to read, sell or retain the customer’s financial information. Financial Information Providers (FIPs) hold the data. Financial Information Users (FIUs) request it for a consented purpose and must be entities regulated by a financial-sector regulator.

The RBI Master Direction requires an NBFC-AA to be a company, obtain a certificate of registration and maintain at least ₹2 crore in net owned fund. It also restricts the entity to the AA business, prohibits access to customer credentials and requires information-system audits and operational controls.

The technical flows are standardised by ReBIT’s AA API specifications, covering consent, FIP data flow and FIU callbacks.

India’s three practical entry routes

1. Become an NBFC-AA. This is the most regulated and expensive option. It makes sense only if operating the consent and routing layer is the business.
2. Participate as a regulated FIU or FIP. Banks, lenders, insurers, investment entities and other regulated institutions can take the appropriate ecosystem role.
3. Be a technology provider to a regulated participant. Many fintech products integrate the AA network through an eligible FIU rather than trying to become the regulator-recognised data user themselves.

Account Aggregator is for financial data. UPI and other payment systems are separate, so AA participation does not itself grant payment-initiation rights.

Why accessing consumer data feels complex

The apparent complexity comes from stacking several different jobs into one programme. None is mysterious on its own.

1. Legal perimeter

Write down what the product does in verbs: retrieve, display, analyse, recommend, initiate, receive, hold or transfer. Each verb can change the permission analysis.

2. Data purpose and consent

The customer must understand what data is requested, why it is needed, how long access lasts and how to stop it. A good consent record is both a customer experience and an audit record.

3. Organisational trust

Regulators and principals want to know who owns and manages the company, whether decision-makers are fit and proper, and whether there is enough financial capacity and insurance to resolve failures.

4. Security evidence

“Bank-grade security” is not a control. Evidence normally includes identity and access management, encryption, logging, vulnerability management, secure development, incident response, business continuity, supplier oversight and independent testing.

5. Technical identity

In a regulated ecosystem, a company often identifies itself using a directory entry and digital certificates. This prevents a bank from accepting a request merely because it came from a familiar internet address.

6. API integration and data normalisation

Even with a standard, banks use different product names, transaction descriptions, refresh patterns and error responses. A reliable product needs one internal data model and a support process for exceptions.

7. Conformance and production operations

Passing a sandbox proves that a happy-path request works. Production readiness also requires certificate rotation, consent expiry, revoked access, bank outages, duplicate data, delayed transactions, complaint handling and incident reporting.

This is why the project is manageable when sequenced correctly. It becomes difficult when a team tries to solve regulation, product design, every bank integration and every country simultaneously.

A practical accreditation workplan

For a nontechnical leadership team, the work can be organised into six stages.

Stage 1: choose the narrowest viable service

Start with one customer, one data purpose and one country. Decide whether read-only data is enough. Avoid payment initiation until it is necessary to the product outcome.

Stage 2: compare the partner and direct routes

Ask regulated principals for coverage, onboarding requirements, data-processing terms, control responsibilities, pricing and exit support. Compare that with the fixed cost and strategic value of direct permission.

Stage 3: complete a gap assessment

Map each regulatory or principal requirement to evidence you already have. A company with mature cloud security, privacy and incident management may be much closer than it assumes.

Stage 4: build evidence and product flows together

Do not let legal documentation and engineering run as separate projects. The consent wording must match the actual API scopes, retention code and deletion process.

Stage 5: apply with a complete file

Regulator clocks usually start only when the application is complete. A short application followed by months of questions is slower than a deliberate, evidence-backed submission.

Stage 6: plan the regulated operating model

Permission is the beginning. Assign owners for certificate renewal, regulator returns, control testing, bank incidents, complaints, audit evidence and changes to data use.

How to choose the right country and route

Use these questions in order:

1. Does the product need data, payments or custody?
2. Is the customer outcome valuable without direct regulatory control?
3. Does a reputable principal cover the required banks and data?
4. Will expected volume justify the fixed cost of direct permission?
5. Can the company support regulated operations for several years?
6. Is the framework live, or still a consultation, pilot or phased rollout?

A “yes” to partnership is not a compromise. It is often the fastest compliant design.

Sources and research method

This article prioritises primary regulatory and standards sources. The most important are:

• US CFPB: Personal Financial Data Rights and current stay
• Australia CDR: become an Accredited Data Recipient
• Australia OAIC: CDR Representative obligations
• UK FCA: AIS and PIS rules for third-party providers
• UK FCA: 2026 application fee categories
• EU EBA: PSD2 register and national competent authorities
• EU Council: November 2025 political agreement on PSD3/PSR
• Singapore ABS: SGFinDex
• Malaysia BNM: current Open Finance status
• Thailand BOT: Your Data rollout
• India RBI: NBFC Account Aggregator Master Direction
• India ReBIT: Account Aggregator technical specifications
• Philippines BSP: Open Finance PH
• New Zealand MBIE: regulated open banking standards
• Saudi Central Bank: open-banking licensing from March 2026
• UAE Central Bank: in-force Open Finance Regulation
• Brazil Central Bank: participants in Open Finance

The cost bands are planning estimates derived from the number of disciplines required, the maturity of each permission route, public application fees and published regulator timelines. They are not official charges or quotes. Re-estimate after fixing the exact product scope, legal entity, countries, data types, transaction volume and partner model.

For a simpler introduction before diving into regulation, read Open Banking Explained.