UAE Open Finance Regulation: Licensing, Security Requirements, and the September 2026 Deadline

Last updated: July 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 now, and the clock to regularise it runs out 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 is nearly gone.

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 in the weeks that remain.

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 now 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, so the practical question for an existing institution is which phase it sits in and what its readiness date is.

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 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 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.

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, at eight weeks out, an impossible 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 in the remaining weeks

If you are in scope and have not started, the sequence matters more than the speed.

Classify the activity first. Before anyone drafts 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. Getting this wrong wastes the time you do not 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 it can start before the licensing route is finalised because 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.

File early. CBUAE application processing is not instantaneous, and a submission that lands in the final week of the transition period leaves no room for questions, clarifications, or a request for more evidence.

If the deadline is genuinely unreachable for your build, that is a conversation to have with counsel about your position and options rather than a reason to stop, and it is a strong argument for having the security programme demonstrably underway.

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.

If you are inside the perimeter and the September date is close, book a 30-minute call and we will map your classification, your Article 31 gaps, and what can realistically be built before the deadline.

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. Entities regulated in DIFC or ADGM fall under the DFSA and FSRA regimes instead.

What is the deadline for CBUAE licensing under the 2025 Law?

Federal Decree-Law No. 6 of 2025 came into force on 16 September 2025 with a one-year transition period, giving newly in-scope entities until 16 September 2026 to obtain the necessary licence or approval. The CBUAE retains discretion to extend. Because application processing takes time, filing well before the date is the only workable plan.

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.

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. 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 operate without the licence after the deadline?

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. This is a materially different exposure from the administrative penalties firms may be used to, which is why the classification question deserves legal input rather than an internal judgement call.

Related: CBUAE Cybersecurity Requirements: Do You Need a CISO? · UAE IAR Compliance (NESA IAS): A vCISO Guide · vCISO for Fintechs in the UAE · UAE PDPL Compliance: A vCISO and DPO Guide