UAE Open Finance Regulation: Licensing, Security Requirements, and the CBUAE Transition

Last updated: September 2026.

If your business touches customer financial data in the UAE, moves it between institutions, or lets a user trigger a payment from an account they hold somewhere else, you are probably inside a licensed activity, and the transition period to regularise it closed on 16 September 2026.

That is the short version. The change came from the new CBUAE Law, Federal Decree-Law No. 6 of 2025, which entered into force on 16 September 2025 and named open finance services as a licensed financial activity in their own right. Firms that were outside the perimeter before, and many that assumed they were selling a technical integration layer rather than a regulated service, were given a one-year transition to obtain the licence or approval they now need. That year has run out.

This guide covers who is in scope, what the Open Finance Regulation actually requires, the security and technology obligations that decide whether an application survives review, and what a firm can realistically do now that the transition date has passed.

Which deadline 16 September 2026 actually was

Worth separating two things that are constantly merged, including on vendor sites that sell compliance services.

The Open Finance Regulation itself sets no phase dates. Phase One of the onboarding covers banks and insurance companies only, including foreign branches, and the regulation states that later phases will be announced by the Central Bank through official channels. Anyone quoting an Open Finance licensing deadline out of the text of the regulation is quoting something that is not in it.

The 16 September 2026 date came from the CBUAE Law: the one-year reconciliation period that ran from the Law's entry into force on 16 September 2025. Entities brought newly into the Central Bank's licensing perimeter had that year to regularise. The period has now expired with no published extension, although the Central Bank retains discretion to extend individual cases.

The practical effect on a firm that needed a licence is the same either way, which is why the two get conflated. The distinction matters when you are writing to a supervisor, because citing the wrong instrument in a submission colours everything else in the letter.

What changed, and why firms missed it

Before the 2025 Law, open finance in the UAE was mostly discussed as infrastructure: API access, bank data connectivity, consent flows, product design. Plenty of founders reasonably concluded they were a technology vendor rather than a financial institution.

The 2025 Law closed that reading. Article 61 lists open finance services among the activities within the CBUAE's remit, alongside payment services using virtual assets. Article 62 then imposes the licensing requirement on any person carrying on, offering, issuing, or facilitating a licensed financial activity, directly or indirectly, regardless of the medium, technology, or form used. It reaches platforms, decentralised applications, protocols, and technological infrastructure that facilitate or enable financial services. The drafting is deliberately technology-neutral, which means calling yourself a middleware provider does not remove you from scope.

Operating a licensed financial activity without authorisation is a criminal offence under the 2025 Law, carrying imprisonment and substantial fines. This is the part that turns a compliance project into a board matter.

Who is in scope

Two very different populations are affected, and they have different problems.

Existing CBUAE Licensees, meaning banks, finance companies, and other institutions already regulated by the Central Bank, are pulled in as Data Holders and Service Owners. Participation in the Open Finance Framework is mandatory for licensees in respect of the products and services within its scope. They have to expose customer data and transaction initiation to authorised participants, subject to user consent, appropriate authentication, and secure communication. Onboarding of licensees runs in phases, with Phase One covering banks and insurance companies, so the practical question for an existing institution is whether it sits in Phase One and, if not, how it is monitoring for the announcement of the phase that will catch it.

New entrants need the licence itself. The Regulation created a licence category for Open Finance Providers, covering two permissions that a firm can hold separately or together: Data Sharing, which is access to customer data, and Service Initiation, which is initiating transactions on a customer's accounts and products. If your product reads bank data on a user's behalf, or triggers a payment from an account you do not hold, you are describing one or both of these.

The Regulation also treats six categories as deemed licensed for open finance purposes, including banks, finance companies, retail payment service providers, insurance brokers, insurance companies and stored value facility providers. Deemed licensed is not the same as free to proceed: written notice to the Central Bank and its approval are required before commencing, the Central Bank decides within 60 working days, and registration on the Trust Framework follows within 14 days of approval.

The boundary that catches groups out is the free zone question. The CBUAE framework applies onshore. Entities regulated in the DIFC by the DFSA or in ADGM by the FSRA sit under their own regimes, and some firms will find that a sequencing route through a free zone sandbox builds a track record before onshore authorisation. That is a licensing strategy question for your counsel; what it does not do is remove the onshore obligation if you are serving onshore customers through an onshore entity.

What the Open Finance Regulation sets up

The Regulation establishes an Open Finance Framework built around an API Hub, which carries a Trust Framework and Common Infrastructural Services. The API Hub is itself licensed and regulated under the same Regulation, which is why the rulebook splits into parts: one set of requirements applies to Licensees, another to the API Hub, and a third to both.

Three principles run through the whole thing, and every security control you build traces back to one of them:

Consent. Data sharing and service initiation happen only with the express consent of the user. Consent has to be specific, recorded, and revocable, and you have to be able to prove after the fact what a customer authorised and when.

Authentication. Access is subject to appropriate authentication processes. This is the anti-fraud spine of the model, and it is where most technical review attention lands.

Secure communication. Data moves between participants over secure channels under the Trust Framework, with participants authenticated to each other rather than merely to the end user.

On the commercial side, the licence carries a minimum capital requirement, reported at AED 1 million with the CBUAE able to set a higher figure on a risk-adjusted basis, along with a professional indemnity insurance requirement reported at AED 5 million per claim, and governance and control expectations consistent with other CBUAE licence applications. Capital is expected to be in place at the point of grant, with documented source of funds.

Open Finance security requirements: where applications actually fail

This is the part most firms underestimate, and it is where a licensing timeline slips from weeks to months.

Article 31 of the Open Finance Regulation requires a technology and cyber security risk management framework, an IT governance structure, and secure authentication and communication standards. Read that as three separate build items, because that is how a reviewer reads it.

A technology and cyber security risk management framework means a documented, operating risk process: an asset and data inventory covering the systems that touch customer financial data, a risk assessment methodology, a live risk register with owners and review dates, and a treatment plan with evidence that treatments were carried out. A register produced for the application and never touched again is visible immediately.

An IT governance structure means defined ownership at the top, separation between the people running technology operations and the people accountable for security, and technology risk reported to the board rather than kept inside IT. Across CBUAE regimes this expectation is consistent, and for payment service providers the UAE Information Assurance Standards are named as the minimum security baseline in Article 13 of the Retail Payment Services and Card Schemes Regulation (Circular 15/2021). Those standards make the security leadership appointment an always-applicable control, separate from IT. We set out that framework in the UAE IAR guide and the wider Central Bank picture in the CBUAE compliance guide.

Secure authentication and communication standards means the technical controls specific to this model, and they are unlike a generic security programme:

API security across the full surface: authorisation scopes tied to the consent granted, token lifetimes and revocation, rate limiting, replay protection, and input validation on every endpoint a participant can reach.

Mutual authentication between participants under the Trust Framework, with certificate lifecycle management that does not depend on one person remembering a renewal date.

Strong customer authentication through the consent and initiation flow, designed so that fraud controls do not quietly become a usability workaround.

A consent audit trail that can reconstruct, for any transaction, who consented to what, through which interface, and when it was revoked.

Data minimisation in practice, so that the data actually retrieved matches the scope consented to rather than everything the endpoint could return.

Logging and monitoring with retention aligned to policy, because an open finance firm that cannot show what an API client did during an incident has no answer for the regulator.

Two more obligations sit alongside these and are routinely left until last. Incident reporting: a security incident in this model can trigger notification duties to the Central Bank and, where personal data is involved, under the UAE PDPL, on different clocks. The runbook has to list every applicable regulator and its deadline, because you cannot design a reporting matrix during an incident. And third-party risk: your dependency on the API Hub, your cloud provider, and your own technology suppliers is in scope, with contractual provisions on data security, service continuity, and regulatory compliance expected in commercial agreements.

The operational resilience layer that arrived in September 2026

One instrument has changed the picture for every licensee since this guide was first written. The Operational Risk Management Regulation (C 1/2026) took effect on 14 September 2026 and applies to all licensed financial institutions that are juridical persons, which includes Open Finance Providers once licensed.

Three of its requirements interact directly with an open finance build. The master system of record must be continuously maintained and stored within the UAE, including where the activity is outsourced, which forces an explicit determination of where the authoritative record for each critical operation lives. Business continuity and disaster recovery plans for critical operations must be reviewed and tested at least annually, against scenarios extending to major assets being permanently unrecoverable. And a material change affecting a critical operation requires an independent expert report filed with the Central Bank at least 30 calendar days ahead, plus a written no-objection before implementation, which changes how any platform migration has to be scheduled.

We cover the instrument in full in our guide to the CBUAE Operational Risk Management Regulation.

Why this needs a named security owner

The pattern across CBUAE regimes is consistent: the regulator wants a qualified individual accountable for information security, governance that puts technology risk in front of the board, and evidence that the controls operate rather than exist on paper. For an Open Finance Provider the bar is higher than for a generic licensee, because the entire product is an authenticated data and payment interface, and the security programme is not a support function but the thing being licensed.

For most firms applying, hiring a full-time CISO to satisfy this is the wrong instrument, and on a compressed supervisory timeline an unavailable one. The recruitment market for a credible CISO in the UAE runs to months, and the workload here is front-loaded: heavy through the application and the first year of supervision, lighter afterwards. A virtual CISO fills the appointment and carries the build, and we set out the economics in Virtual CISO vs Full-Time CISO and the market bands in how much a vCISO costs in the UAE.

What to do now the transition has closed

If you are in scope and did not complete the process, the sequence matters more than the speed.

Classify the activity first. Before anyone drafts or amends an application, establish whether you need Data Sharing, Service Initiation, both, or in fact a different CBUAE licence category. Firms regularly discover that their actual product spans two categories, and a misclassified application costs more time than the classification work would have.

Run a gap assessment against Article 31 and the IA Standards baseline in parallel with the licensing analysis, not after it. The security build is the long pole, and most of it is required either way.

Build the evidence as you go. A reviewer wants the risk register, the governance minutes, the policy set, the authentication design, the consent model, the third-party assessments, and the incident runbook. Assembling these after the application is drafted is how firms end up filing late.

Approach the Central Bank rather than waiting to be contacted. A firm that arrives with its application status, a list of what is outstanding, and a dated remediation plan is in a materially different conversation from a firm that is found operating unlicensed. Take legal advice on your position first, and have the security programme demonstrably underway when you do it, because a plan with evidence behind it is the only part of this you control.

How Dynova works with Open Finance applicants

Dynova provides virtual CISO and DPO services in Dubai to regulated firms across the UAE, including payment providers, virtual asset businesses, and fintechs approaching a CBUAE licence. A senior CISO (CISSP, CISM) is named in the engagement and serves as your security lead of record, builds the technology and cyber security risk management framework the Regulation requires, designs the authentication, consent, and API security model with your engineers, assembles the evidence set, and faces the regulator alongside you. The same engagement can carry the Data Protection Officer role, which matters here because open finance is a personal data business as much as a payments one.

On the larger plans the CISO comes with a delivery team, a GRC analyst and a security engineer, which is what makes a compressed timeline realistic rather than aspirational. For proof that the model delivers under a deadline, we took OGold from a standing start to ISO 27001 certification with BSI in six months. For how the same arrangement works in a licensed firm that already employs security staff, see our in-house security team case study.

If you are inside the perimeter and on the wrong side of the transition date, book a 30-minute call and we will map your classification, your Article 31 gaps, and what a credible remediation position looks like.

Frequently asked questions

What is the UAE Open Finance Regulation?

It is the CBUAE regulation establishing the licensing, supervision, and operation of an Open Finance Framework in the UAE. The Framework is built around an API Hub carrying a Trust Framework and common infrastructural services, and it lets authorised participants access customer data and initiate transactions on customer accounts, in every case with the user's express consent, appropriate authentication, and secure communication.

Who needs an Open Finance licence in the UAE?

Firms providing open finance services as a business: accessing customer financial data on a user's behalf (Data Sharing), initiating transactions on accounts and products the customer holds elsewhere (Service Initiation), or both. Existing CBUAE licensees are separately mandated to participate in the Framework as Data Holders and Service Owners, with onboarding running in phases and Phase One covering banks and insurance companies. Entities regulated in DIFC or ADGM fall under the DFSA and FSRA regimes instead.

Was there an Open Finance licensing deadline in September 2026?

Not in the Open Finance Regulation, which sets no phase dates and states that later phases will be announced by the Central Bank. The 16 September 2026 date was the end of the one-year reconciliation period under Federal Decree-Law No. 6 of 2025, which gave newly in-scope entities a year from the Law's entry into force to obtain the licence or approval they needed. That period has expired and the CBUAE retains discretion to extend individual cases.

What are the security requirements for an Open Finance Provider?

Article 31 of the Regulation requires a technology and cyber security risk management framework, an IT governance structure, and secure authentication and communication standards. In practice that means an operating risk process with a live register, board-level technology risk governance with security accountability held separately from IT, and the technical controls the model depends on: API authorisation tied to consent scope, mutual authentication between participants, strong customer authentication, a consent audit trail, data minimisation, and logging that supports an incident investigation. Since 14 September 2026 the Operational Risk Management Regulation adds operational resilience, UAE storage of the master system of record, annual continuity testing and regulatory approval of material changes.

Does an Open Finance Provider need a CISO?

The Regulation requires an IT governance structure and a security risk management framework rather than naming a job title, but the CBUAE's wider expectation across its regimes is a qualified individual accountable for information security, kept separate from IT operations, reporting technology risk to the board. For payment providers the UAE Information Assurance Standards are the named minimum baseline, and they make that appointment an always-applicable control. A retained virtual CISO can hold the role.

What capital does an Open Finance licence require?

Reported minimum capital is AED 1 million, with the CBUAE able to impose a higher figure on a risk-adjusted basis, alongside a professional indemnity insurance requirement reported at AED 5 million per claim. Capital is expected to be in place at the point the licence is granted, with documented source of funds. Confirm current figures with the CBUAE rulebook or your counsel before you budget.

What happens if we are operating without the licence now?

Under the 2025 Law, carrying on a licensed financial activity without authorisation is a criminal offence carrying imprisonment and substantial fines, and the licensing requirement applies regardless of the technology or medium used. That is a materially different exposure from the administrative penalties firms may be used to. Take legal advice on your position, then approach the Central Bank with a documented remediation plan rather than waiting for supervisory contact, because self-reporting with evidence of progress is a different conversation from being found.

Related: CBUAE Cybersecurity Requirements: Do You Need a CISO? · CBUAE Operational Risk Management Regulation (C 1/2026) · UAE IAR Compliance (NESA IAS): A vCISO Guide · vCISO for Fintechs in the UAE · UAE PDPL Compliance: A vCISO and DPO Guide