Why the UAE's New Central Bank Law Also Regulates Your Technology Partner

sourceCode | BFSI Technology Insight | 1 October 2026

Key Takeaways

• Federal Decree-Law No. 6 of 2025 replaced the UAE's 2018 Central Bank Law and consolidated banking and insurance regulation under the Central Bank of the UAE (CBUAE); its one-year transition period closed on 16 September 2026.

• Article 62 extends CBUAE licensing and oversight to "any person carrying on, offering, issuing, or facilitating a licensed financial activity - regardless of the medium, technology, or form employed" - explicitly naming platforms, apps, protocols and technological infrastructure that enable payments, credit, deposits, exchange, remittances or investment services, even where the operator is not itself a bank or insurer.

• Article 61(1)(h) separately makes advertising, marketing or promoting a licensable financial activity a licensed activity in its own right - a provision that reaches digital marketing and distribution channels a technology vendor may operate on a bank's behalf.

• Most UAE financial institutions' vendor-risk assessments were built to answer "is this an outsourcing arrangement that could hurt us operationally" under the CBUAE's existing 2021 outsourcing rules - not "is this vendor now itself inside CBUAE's direct licensing perimeter."

• Those are two different questions, testing two different regimes, and the gap between them is now a live compliance exposure rather than a theoretical one.

Introduction

On 16 September 2026, a one-year transition window closed quietly across the UAE's financial sector. There was no single headline event to mark it - no regulatory deadline countdown on trading terminals, no last-minute scramble comparable to a licence renewal cycle. But for every bank, insurer, payment institution and finance-adjacent technology vendor operating in the UAE, that date mattered more than most of the compliance calendar entries either side of it.

Federal Decree-Law No. 6 of 2025 Regarding the Central Bank, Regulation of Financial Institutions and Activities, and Insurance Business - the law replacing the UAE's 2018 Central Bank Law - gave regulated entities twelve months from its 16 September 2025 entry into force to "regularise" their positions under the new regime (White & Case, 2025; Ashurst, 2025). Most of the legal commentary on the law, sensibly, focused on what it does to banks and insurers directly: consolidated CBUAE authority, expanded enforcement powers, a formalised approach to virtual assets and payment tokens, and a broadened definition of what counts as a "Licensed Financial Activity" (CMS Law, 2025; Gibson Dunn, 2025).

What received far less boardroom attention - and is the subject of this piece - is a single provision, Article 62, that does something structurally different from a normal licensing update. It doesn't just tighten the rules for institutions that were already regulated. It redraws the outer edge of who counts as regulated at all, in a way that can pull a technology vendor across the line without that vendor ever having applied to be a bank, an insurer, or a payment service provider.

For Risk, Compliance and Procurement teams at UAE financial institutions, and for their counterparts inside the technology firms that serve them, this is not an academic distinction. It changes what a vendor-risk assessment needs to test for. And the evidence suggests most assessments in the market have not caught up.

The Regulatory Evidence: What Article 62 Actually Says

The core language is unusually direct for a piece of financial-sector legislation. Article 62 extends CBUAE licensing, regulation and oversight to "any person carrying on, offering, issuing, or facilitating a licensed financial activity - regardless of the medium, technology, or form employed" (Gibson Dunn, 2025; CBUAE Rulebook, 2025). The article goes on to name the categories of activity in scope: payments, credit, deposits, money exchange, remittances and investment services delivered through "platforms, decentralised applications (dApps), protocols, or technological infrastructure" - and it applies "even when the provider is not itself a bank, insurer or payment service provider" (White & Case, 2025; CMS Law, 2025).

Four independent legal analyses - from White & Case, CMS, Gibson Dunn and Ashurst - converge on the same reading: the law regulates the function a technology platform performs in the financial services chain, not the corporate label the platform operator carries (White & Case, 2025; CMS Law, 2025; Gibson Dunn, 2025; Ashurst, 2025). A company that has never held a financial services licence, has no banking relationship with the CBUAE, and may not think of itself as a financial institution at all, can nonetheless fall inside the licensing perimeter purely because of what its software does - intermediating or enabling a payment, a remittance, a credit decision, a deposit-taking flow, or an investment transaction.

A second, less-discussed provision compounds this. Article 61(1)(h) designates "advertising, marketing or promoting a licensable financial activity" as itself a licensed activity requiring CBUAE authorisation (Gibson Dunn, 2025). This captures promotional and distribution technology - marketing automation platforms, embedded-finance widgets, comparison and origination tools - operating through digital channels aimed at UAE residents, regardless of where the vendor is domiciled. A marketing-technology vendor that has never touched a customer's money can, on this reading, still be performing a licensable activity.

The transition period gave the market time to work through the implications. That period is now closed. Entities the law captures were expected to have regularised their licensing and compliance position by 16 September 2026, with the CBUAE retaining discretion to grant further time on a case-by-case basis (CMS Law, 2025; Addleshaw Goddard, 2025). Discretion is not the same as an extension, and nothing in the public record indicates a blanket extension has been granted.

Why This Is Happening Now

The UAE is not alone in wrestling with this problem, but its response is more explicit than most. Financial regulators globally have spent the past decade watching the delivery of financial services migrate away from the regulated institution's own infrastructure and onto third-party technology stacks: cloud-hosted core banking, embedded-finance APIs, payment orchestration layers, credit-decisioning engines run by external vendors, and - more recently - decentralised and blockchain-based settlement rails. Traditional financial regulation licenses the entity that holds a banking or insurance charter. It was not built for a world where the entity that decides whether a payment clears, or whether a remittance settles, might be a technology company with no banking licence at all.

Article 62 is CBUAE's answer to that gap, and its logic is function-over-form: if you enable, intermediate or facilitate a regulated financial activity, the regulator now looks at what you do rather than what your incorporation documents say you are (Mondaq, 2025). This mirrors a broader international direction of travel - the Basel Committee, among others, has been pushing toward outcomes-based supervision of the technology dependencies underneath financial services - but the UAE has moved from principle to statute faster and more concretely than most comparable jurisdictions, consolidating it into primary law rather than supervisory guidance.

It is also consistent with the UAE's wider ambition to be taken seriously as a hub for regulated fintech, virtual assets and cross-border financial infrastructure. A regulator that wants global institutions to trust its licensing regime cannot leave a large, unlicensed shadow perimeter of technology providers quietly performing bank-like functions underneath it. Closing that gap protects the credibility of the licences CBUAE does issue.

What Most Organisations Get Wrong

Here is the structural problem, and it is not a matter of anyone being negligent. UAE banks already have a mature, CBUAE-mandated process for assessing technology and outsourcing vendors: the Outsourcing Regulation for Banks (C 14/2021), which has governed third-party arrangements since 2021 (CBUAE Rulebook, 2021). That regulation requires a materiality assessment of every outsourcing arrangement, incorporation of outsourcing risk into the bank's own risk governance framework, prior non-objection from the Central Bank for material arrangements, ongoing monitoring and reporting, and immediate notification of material vendor failures (CBUAE Rulebook, 2021).

That is a well-built regime - for a specific question. It asks: if this vendor fails, is disrupted, or breaches its obligations, how exposed is the bank? It is a bank-centric risk lens, assessing the vendor as an extension of the bank's own operational and reputational risk.

Article 62 asks a categorically different question, and most vendor-risk questionnaires currently in circulation across UAE Risk and Procurement functions do not ask it at all: does this vendor's own activity now fall inside CBUAE's direct licensing perimeter, independent of its contractual relationship with us? A vendor can pass every test in a standard outsourcing risk assessment - financially stable, operationally resilient, contractually well-governed, data-secure - and still be a vendor that, under Article 62, should itself hold a CBUAE authorisation it does not currently have. In that scenario, the exposure is not "what happens if the vendor fails." It is "what happens if the vendor is found to have been conducting a licensable activity without a licence, and our institution's financial products depend on its unlicensed infrastructure."

This is the pain point sitting underneath the search intent driving this topic: institutions and their vendors have not updated their assessments to test the vendor's own status under the expanded perimeter - they have only tested the vendor's impact on the institution. Those two tests currently live in the same document, using the same checklist, and they should not.

The CBUAE has offered some relief here. Guidance associated with the law clarifies that a technology supplier providing pure software or infrastructure - without itself performing or facilitating a licensed financial activity - is not automatically brought into scope; the determining question remains whether the entity performs or facilitates the regulated activity, not merely whether it supplies technology used somewhere in the chain (Mondaq, 2025). That is a meaningful qualifier, and it means the answer to "are we exposed" is not a blanket yes for every SaaS contract a bank holds. But it also means the determination is a facts-and-function analysis specific to each vendor relationship - precisely the kind of analysis a generic vendor-risk questionnaire, built for outsourcing materiality rather than licensing-perimeter classification, is not designed to produce.

Business and Technology Implications

For Risk and Compliance leaders, the immediate implication is that vendor-risk assessment can no longer be a single-lens exercise. An assessment built to satisfy the Outsourcing Regulation for Banks answers a necessary but no-longer-sufficient question. A parallel classification exercise is needed: for every technology vendor touching payments, credit, deposits, exchange, remittances, investment execution, or the marketing and distribution of those activities, does the vendor's function - not its contract language, not its self-description - place it inside Article 62's perimeter?

For Procurement, this changes what "vendor due diligence" needs to capture at the point of contracting, not just at renewal. A new technology relationship that would previously have cleared standard IT procurement review, on the basis that it is "just infrastructure," may need a licensing-status check before signature. Contractual protections also need to evolve: warranties and indemnities that address vendor licensing status, audit rights that extend to a vendor's own regulatory posture, and termination triggers tied to loss or absence of a required CBUAE authorisation are not standard clauses in most existing technology contracts.

For CTOs and technology leaders, the implication cuts both ways. UAE financial institutions building or buying embedded-finance capability, payment orchestration layers, or credit-decisioning tools need architectural and vendor-selection decisions that account for the counterparty's own regulatory status - a vendor's technical excellence does not offset a licensing gap. And for technology firms serving UAE financial institutions, including sourceCode's own peer group in the region, the question is now reflexive: does our own platform, where it enables or intermediates a client's licensed financial activity, fall inside this perimeter itself?

A Decision Framework: The Perimeter Crossing Diagnostic

Because most existing vendor-risk tools weren't built to answer this specific question, it is worth having a distinct, narrow diagnostic rather than folding it into an already-crowded outsourcing questionnaire. We call it the Perimeter Crossing Diagnostic - four questions, asked per vendor relationship, that test whether a technology provider has crossed from outside CBUAE's licensing perimeter to inside it.

1. The Function Question. Strip away the contract's language and the vendor's marketing description. What does the platform actually do in the transaction chain - does it facilitate, intermediate or enable a payment, credit, deposit, exchange, remittance or investment activity? If removing the platform would prevent the activity from happening at all (not just make it harder), the function test is likely met.

2. The Distribution Question. Does the vendor operate a channel - a marketing platform, an embedded widget, a comparison or origination tool - through which a licensable financial activity is advertised, marketed or promoted to UAE residents? Article 61(1)(h) treats this as a licensable activity independent of the underlying transaction (Gibson Dunn, 2025).

3. The Substitution Test. Could the institution swap this vendor for an equivalent one without the vendor's own regulatory status changing what the institution can lawfully offer? If the vendor's absence would remove the institution's ability to deliver the regulated activity - not merely its efficiency in delivering it - the vendor is closer to "facilitator" than "tool."

4. The Licence-Gap Question. If the first three questions point toward in-scope status, does the vendor hold, or is it actively obtaining, the relevant CBUAE authorisation? If not, what is the institution's contractual and operational exposure if the vendor is later found to require one - and what termination, indemnity or transition rights exist today to manage that outcome?

None of these four questions has a universally correct answer supplied by the law itself; the CBUAE's own guidance is explicit that classification depends on the specific facts of what the vendor does (Mondaq, 2025). The value of the diagnostic is procedural, not substantive: it forces the classification conversation to happen, on the record, for every technology relationship that touches a regulated financial activity - before the CBUAE, a counterparty, or an auditor forces it instead.

Counterargument and Nuance

It would be a mistake to read Article 62 as bringing every UAE bank's technology supply chain into direct CBUAE licensing. The law and the guidance around it draw a real distinction between a vendor that facilitates a licensed financial activity and a vendor that merely supplies the software or infrastructure underneath one, without itself performing a facilitating role (Mondaq, 2025). A core banking software vendor that licenses its platform to a bank, with the bank operating the platform under its own licence, is a different case from a vendor operating a payment orchestration layer that itself routes and settles transactions on the bank's behalf. Not every SaaS contract, cloud hosting arrangement, or data-analytics tool becomes a licensing event.

There is also legitimate uncertainty about how actively CBUAE will enforce against foreign technology vendors with no UAE incorporation, and about how the transition-period closure will translate into actual supervisory action versus a longer period of case-by-case guidance. The CBUAE has signalled discretion to extend the transition period where appropriate (Addleshaw Goddard, 2025), which suggests a supervisory posture more consistent with phased engagement than a hard enforcement cliff on 17 September 2026. Institutions should treat the classification exercise as urgent, not treat the deadline's passing as evidence that every ambiguous vendor relationship is now an active violation.

The honest position is that this is a facts-and-function determination that will be tested and refined through CBUAE guidance and enforcement practice over the coming period, not a bright-line rule with a single correct answer available today. That uncertainty is itself the argument for running the classification exercise now, documented and defensible, rather than waiting for a regulator or an incident to force the question.

The sourceCode’s Perspective

We build technology for regulated financial institutions in this region, which puts sourceCode on both sides of this question - as a vendor whose own platforms need to be classified correctly, and as a partner helping clients think through their technology supply chain. What we'd flag from that vantage point is that the classification exercise described above is not primarily a legal exercise, though legal input is necessary. It's an architectural one.

The Function Question and the Substitution Test are easiest to answer when an institution actually understands where, in its technology stack, a transaction stops being under its own direct control and starts depending on a third party's infrastructure to complete. Institutions with well-mapped payment and data flows can answer the Perimeter Crossing Diagnostic in an afternoon per vendor.


Institutions where that mapping doesn't exist - where "how does this payment actually clear" requires convening three teams and a vendor call to answer - are the ones for whom this law will be genuinely disruptive, not because the legal analysis is hard, but because the operational visibility to perform it doesn't exist yet. The compliance question exposes an architecture gap that was already there. Talk to us here!

Conclusion

Federal Decree-Law No. 6 of 2025 did more than modernise the UAE's central banking statute. Through Article 62, and reinforced by Article 61(1)(h), it redefined who sits inside the country's financial licensing perimeter - on the basis of function rather than corporate form. The one-year transition period that gave the market time to adjust closed on 16 September 2026.


For Risk, Compliance and Procurement teams, the practical consequence is that a vendor-risk process built to satisfy the CBUAE's 2021 outsourcing regulation - a bank-centric test of operational exposure - is not the same instrument needed to test a vendor's own status under the expanded licensing perimeter.


Running that second test, vendor by vendor, functionally rather than contractually, is no longer a nice-to-have compliance refinement. It is the current state of UAE financial-sector law.

FAQ

What is the UAE Central Bank Law of 2025, and when did it take effect? A: It is Federal Decree-Law No. 6 of 2025 Regarding the Central Bank, Regulation of Financial Institutions and Activities, and Insurance Business. It entered into force on 16 September 2025, replacing the UAE's 2018 Central Bank Law, and gave regulated entities a one-year transition period that closed on 16 September 2026 (White & Case, 2025; CMS Law, 2025).

Does Article 62 really apply to technology vendors that aren't banks? A: Yes. Article 62 extends CBUAE licensing and oversight to any person or entity that carries on, offers, issues or facilitates a licensed financial activity "regardless of the medium, technology, or form employed," and explicitly includes platforms, apps, protocols and technological infrastructure that enable payments, credit, deposits, exchange, remittances or investment services - even where the operator is not itself a bank, insurer or payment service provider (Gibson Dunn, 2025; CMS Law, 2025).

Is every software vendor to a UAE bank now required to hold a CBUAE licence? A: No. CBUAE guidance clarifies that a vendor supplying pure software or infrastructure, without itself performing or facilitating a licensed financial activity, is not automatically in scope. The determination depends on whether the vendor's function facilitates the regulated activity, assessed case by case (Mondaq, 2025).

How is this different from the UAE's existing bank outsourcing rules? A: The Outsourcing Regulation for Banks (C 14/2021) tests whether a vendor relationship creates operational or reputational risk for the bank if the vendor fails or underperforms. Article 62 tests something different: whether the vendor's own activity independently falls inside CBUAE's direct licensing perimeter, regardless of the vendor's contractual relationship with the bank (CBUAE Rulebook, 2021; Gibson Dunn, 2025).

What happened when the transition period ended on 16 September 2026? A: In-scope entities were expected to have regularised their licensing and compliance position by that date, though the CBUAE has indicated discretion to extend the period on a case-by-case basis. There is no public evidence of a blanket extension, so institutions and vendors that have not completed a perimeter classification exercise should treat this as an active gap (CMS Law, 2025; Addleshaw Goddard, 2025).

Reference List

Addleshaw Goddard LLP (2025) CBUAE New 2025 Law - What you need to know. Available at: https://www.addleshawgoddard.com/en/insights/insights-briefings/2025/financial-services/cbuae-new-2025-law/ (Accessed: 1 October 2026).

Ashurst (2025) UAE enacts landmark Central Bank law. Available at: https://www.ashurst.com/en/insights/uae-enacts-landmark-central-bank-law/ (Accessed: 1 October 2026).

Central Bank of the UAE (2025) Federal Decree-Law No. (6) of 2025 Regarding the Central Bank, Regulation of Financial Institutions and Activities, and Insurance Business. CBUAE Rulebook. Available at: https://rulebook.centralbank.ae/en/rulebook/federal-decree-law-no-6-2025-regarding-central-bank-regulation-financial-institutions-and (Accessed: 1 October 2026).

Central Bank of the UAE (2021) Outsourcing Regulation for Banks (C 14/2021). CBUAE Rulebook. Available at: https://rulebook.centralbank.ae/en/rulebook/outsourcing-regulation-banks (Accessed: 1 October 2026).

CMS Law (2025) The new UAE Central Bank law: Expanding the regulatory perimeter for a digital era. Available at: https://cms.law/en/are/legal-updates/the-new-uae-central-bank-law-expanding-the-regulatory-perimeter-for-a-digital-era (Accessed: 1 October 2026).

Gibson Dunn (2025) UAE Central Bank Issues New Central Bank Law Consolidating Financial Sector Regulation. Available at: https://www.gibsondunn.com/uae-central-bank-issues-new-central-bank-law-consolidating-financial-sector-regulation/ (Accessed: 1 October 2026).

Mondaq (2025) Function Over Form: What The UAE's New CBUAE Law Means For Fintech, DeFi And Technology Providers. Available at: https://www.mondaq.com/financial-services/1762588/function-over-form-what-the-uaes-new-cbuae-law-means-for-fintech-defi-and-technology-providers (Accessed: 1 October 2026).

White & Case LLP (2025) UAE enacts the New CBUAE Law which repeals and replaces the 2018 Law. Available at: https://www.whitecase.com/insight-alert/uae-enacts-new-cbuae-law-which-repeals-and-replaces-2018-law (Accessed: 1 October 2026).