.png)
1. Executive summary
UAE insurance operations face a compounded regulatory reset. Five frameworks are converging on the same compliance window: the CBUAE FIT Programme, the Open Finance Regulation, Federal Decree-Law No. 6 of 2025 (the new CBUAE Law), IFRS 17, and the UAE Personal Data Protection Law. Federal Decree-Law No. 48 of 2023 Regulating Insurance Activities sits alongside them as the insurance-specific governing law. The binding date is 16 September 2026, when the new CBUAE Law takes full effect for newly-in-scope entities. The new AML/CFT regime under Federal Decree-Law No. 10 of 2025 has already been in force since 14 October 2025.
The operating-model implications are the same across all five frameworks. Insurers can no longer run siloed policy administration systems with spreadsheet underwriting, duplicated customer masters, and retrofitted compliance documentation. What the regulators now require is a single source of truth for the customer, event-driven claims and underwriting flows, embedded compliance controls, governed data with full lineage, API-first architecture, and identity- and consent-aware processing. Most UAE insurers are two to three years of work away from that target state. They have eighteen months.
What makes this different from previous regulatory waves. The five frameworks do not each demand a separate compliance project. They demand the same underlying operational capability: a governed, integrated data layer with end-to-end traceability and API-ready exposure. An insurer that treats them as five independent IT initiatives will run out of budget, capacity, and management attention long before any of them is delivered cleanly.
Why motor claims is the first domino
Motor is where the regulatory load is heaviest: high volume, high fraud exposure, complex third-party interaction, personal data at every step, and cash leaving the business on every claim. It is also where the in-house case is weakest. Motor claims rarely generate underwriting advantage, and the economics reward specialists who can run a governed repair network, enforce cost discipline, and produce audit-grade documentation on every file. Taking motor out of the insurer's critical path frees the transformation program to focus on the lines where in-house ownership is non-negotiable, and it delivers a visible compliance win inside the September 2026 window. Section 7 sets out the full argument and the engagement model; Section 6 sets out how motor fits into a realistic twenty-four-month sequence for the rest of the operation.
What Axxion offers
Axxion Claims Settlement Services L.L.C. is a UAE-licensed motor claims operating partner. The senior team carries more than forty years of hands-on motor claims experience across the UAE and international markets, and the operation runs on a governed repair network rather than an open panel, with published repair standards, fixed labor rates, transparent parts pricing, and documented quality control including ADAS calibration and high-voltage systems. The platform is built to the six operating principles set out in Section 5, and insurer integration runs through APIs that plug into the existing estate without a rebuild. The result is lower repair costs, shorter cycle times, compliance as a by-product of the workflow, and a repair chain that meets modern safety standards.
Next step. Axxion's managing director, Frederik Bisbjerg, leads insurer engagement directly during this market phase. The initial conversation is confidential, carries no commercial commitment, and produces a written assessment of the insurer's current motor claims operation against the six operating principles in Section 5. That assessment is useful to the board whether or not Axxion is the chosen partner. Insurers planning their response to the September 2026 window should aim to open the conversation during Q2 2026. The foundation phase of the twenty-four-month transformation only works if the motor decision is made first.
Contact: axxion.co · f@axxion.co
The sections that follow set out, framework by framework, what the regulations demand, why legacy operations cannot meet them, what a compliant operating model looks like, and how the motor claims decision fits into the broader transformation. Appendix A holds the full regulatory evidence base with sources, so every claim in the paper can be independently verified.
2. The regulatory convergence
Between 2023 and September 2026, UAE insurance companies face the simultaneous operational impact of five distinct regulatory frameworks. They were not designed to arrive together. They are the product of separate initiatives within CBUAE, the UAE federal government, and the international accounting standards body, each pursuing its own policy objective. The convergence in 2025 and 2026 is a timing accident with a predictable operational consequence: insurers that were already running at the edge of their operational capacity are being asked to absorb five significant changes at once.
The CBUAE Financial Infrastructure Transformation Programme was launched in 2023 as a nine-initiative program to modernize the financial services infrastructure across the UAE. Its target for full integration is 2026 and, according to public reporting, it stood at approximately 85% completion in 2025. The program is building the shared plumbing on which the rest of the frameworks depend, including the financial cloud, the eKYC platform, and the open finance infrastructure.
The CBUAE Open Finance Regulation was issued in 2024. It establishes mandatory participation in a cross-sectoral data-sharing framework for UAE licensed banks, foreign bank branches, and insurance companies, on a phased basis. It applies explicitly to motor, health, life and property insurance products. The framework runs on a centralized API hub governed by Nebras, a CBUAE spin-off entity, and a trust framework governing identity, authentication, and data security. For insurers, this means the ability to expose customer data through standardized APIs, on customer consent, will become a regulatory obligation rather than a strategic option.
Federal Decree-Law No. 6 of 2025, referred to as the new CBUAE Law, repeals and replaces the 2018 Central Bank Law and introduces a consolidated regulatory framework for banks, payment providers, enabling technology providers, and insurance business. Entities newly in scope or existing entities required to make changes have until 16 September 2026 to regularize licensing and compliance. This is the compliance anchor that sets the 2026 deadline. It is not a motor-specific rule, but it captures insurance business inside a unified regulatory architecture for the first time. The insurance-specific law, Federal Decree-Law No. 48 of 2023 Regulating Insurance Activities, continues to apply in parallel and provides the licensing and conduct requirements for insurance professions.
Federal Decree-Law No. 10 of 2025, together with Cabinet Resolution No. 134 of 2025, replaced the previous AML/CFT framework and came into force on 14 October 2025. The executive regulations contain 71 articles and approximately 300 enforceable requirements, including mandatory connection to the goAML platform for suspicious transaction reporting, real-time transaction screening, and automated suspicious activity reporting workflows. CBUAE is the supervisory authority for insurance companies under this framework. The operational implication is that AML/CFT compliance can no longer sit in a separate system running batch extracts overnight; it must be embedded into the transaction flow itself.
IFRS 17 Insurance Contracts was enforced by CBUAE on 1 January 2023 without extensions, and has been in active supervision through a rigorous three-phase transition in which insurers submitted four to seven rounds of technical documents including actuarial model validation reports. IFRS 17 is the oldest of the five frameworks but the one with the heaviest data requirement: ten or more years of granular historical data, consistent formats, reliable traceability, and board-level governance over data integrity and assumption management. It is the clearest granular unified data mandate already in effect for UAE insurers.
Why this is not a coincidence
The five frameworks arrived in parallel because the UAE's broader national strategy has been moving in the same direction for several years. We the UAE 2031, launched in November 2022, set the federal vision of a digitally-enabled government delivering proactive, integrated services. UAE PASS is its operational expression: a single digital identity, single sign-on, digital wallet, and document-signing service covering more than 15,000 services across 350 entities, including from the private sector.
At emirate level, the Dubai Economic Agenda D33, launched in 2023, set a ten-year economic strategy targeting AED32 trillion in cumulative GDP and an AED100 billion annual contribution from the digital economy, supported by 100 transformation projects. On 1 April 2026, Sheikh Hamdan bin Mohammed bin Rashid Al Maktoum directed all Dubai government entities to integrate individual and business services into a single digital platform within twelve months, with Digital Dubai coordinating implementation.
Financial services regulation is now catching up to the rest of the UAE government. The Hamdan directive is the most visible and most recent signal, but it is a capstone rather than a foundation. The financial regulator has been building toward the same outcome since 2023 through the FIT Programme, and the 2025 legislative updates (the new CBUAE Law and the new AML/CFT framework) lock that direction into place.
What the five frameworks share
Reading the five frameworks side by side, a pattern emerges that is obscured when they are read individually. Each framework, regardless of its stated purpose, asks the same operational question: can the insurer produce, on demand, a complete, granular, traceable record of what happened, when, to whom, and on what basis? IFRS 17 asks this question in accounting terms. AML/CFT asks it in compliance terms. Open Finance asks it in data-exposure terms. The new CBUAE Law asks it in regulatory reporting terms. The FIT Programme asks it as an infrastructure question.
The answer to all five questions is the same. It requires a data operation with certain characteristics: a single source of truth per business entity, event-driven state capture, embedded compliance controls, API-ready exposure, and governance at the data layer rather than at the application layer. These are not five separate capabilities. They are five aspects of one operating model.
The common misreading
The most frequent misreading in the UAE market today is to treat each of the five frameworks as a separate IT project. The compliance team takes AML/CFT, the finance team takes IFRS 17, the IT team takes FIT and Open Finance, and the legal team takes the new CBUAE Law. Each workstream then procures its own vendor, builds its own interfaces, and sets its own data definitions. Twelve months later, the insurer has five disconnected compliance projects, five overlapping data models, and no coherent operating model. It has also spent roughly four times what a single integrated program would have cost, and it still cannot produce a clean regulatory response when asked.
The correct reading is that the five frameworks are symptoms of a single requirement: the operating model must be rebuilt around a governed, integrated data layer. Once the data layer is right, all five frameworks can be satisfied as views over the same underlying operation. Get the data layer wrong, and no amount of point-solution buying will fix it.
3. Operations under pressure
This section takes each of the operational functions most directly affected by the regulatory convergence and describes, in concrete terms, what the regulations require, how legacy operations typically fall short, what must change, and what a compliant operating state looks like in practice. The sequence is designed so that readers can turn directly to the function most relevant to their role.
3.1 Claims operations
What the regulations demand
Claims operations sit at the intersection of four of the five frameworks. IFRS 17 requires granular, structured claim-level data with full historical continuity for reserving and disclosure purposes. AML/CFT under Federal Decree-Law No. 10 of 2025 requires real-time screening of claims transactions, including payments to repairers, suppliers, salvage buyers, and third-party claimants, alongside automated suspicious activity reporting where red flags are triggered. The new CBUAE Law consolidates insurance supervision under a framework that expects end-to-end operational visibility, auditable process controls, and segregation of duties. Open Finance will, in the phased roll-out, require insurers to expose customer claims data through standardized APIs on customer consent.
Translated into operational terms, this means every motor claim must be traceable from first notification of loss through final settlement, with every state change captured as a timestamped event, every decision linked to the person who made it, every payment screened in real time, and every supporting document stored in a retrievable format. It also means the claim data model must be rich enough to support operational-level reporting on metrics such as vehicle drop dates, drivable-versus-towed condition, parts procurement timelines, and per-function cycle times.
What legacy claims operations look like
A typical UAE motor claims operation today runs across multiple disconnected tools. Intake happens through a mixture of call center scripts, insurer apps, and garage networks. Initial registration goes into a claims system that was built primarily to track reserves and payments, not operational events. Repair authorization and supplement management happen over email, WhatsApp, and phone calls between the claims adjuster, the surveyor, and the repair workshop. Approvals are logged as free-text notes in the claims system after the fact, if at all. Subrogation recoveries are tracked in spreadsheets. Salvage disposal runs on a separate process with its own documentation. The relationship between the policy, the claim, the repair, the parts, the payments, and the recoveries exists only in the head of the claims handler who is working on the file.
This operating model produces reserve and payment figures comfortably. It cannot produce, on demand, an immutable audit trail of who did what when, with real-time AML screening on every transaction and structured repair data queryable across a portfolio. It cannot support IFRS 17's historical data requirements without significant manual reconstruction at each reporting cycle. It cannot expose claim data through APIs without substantial integration work on each individual request.
What must change
The claims operating model must move from a document-based workflow held together by human memory to an event-captured workflow held together by a shared data model. Every state change in the claim lifecycle, from FNOL through reserving, assignment, survey, authorization, repair, quality control, settlement, and closure, must be captured as a discrete timestamped event tied to a specific user and a specific rationale. Every payment must flow through a single transaction engine that performs AML screening in real time, flags exceptions, and generates the required suspicious activity reports automatically where criteria are met. Every document must be stored in a governed repository linked to the claim event stream, not in an email attachment, a WhatsApp group, or a local folder. Every supplier interaction, whether a repair workshop, parts supplier, salvage buyer, or assessor, must flow through the same data model, with structured outputs rather than free-text handoffs.
These changes cannot be delivered by adding another portal or another reporting layer on top of the existing claims system. They require the claims operation to run on a unified data layer in which the workflow engine, the data capture engine, the compliance engine, and the reporting engine all share the same event stream.
What good looks like
In a compliant claims operating state, a claim can be queried at any point in its lifecycle and return a complete, ordered history of every event, every decision, every payment, and every document, linked to the person and the rationale behind each action. The AML/CFT compliance officer can demonstrate real-time screening of every outgoing payment. The actuarial team can extract granular historical claim data for any required period without manual reconstruction. The regulator, when requested, can be given a read-only window into a sample of claims and will see the same operational truth the insurer sees internally. The internal management team can produce operational KPIs such as cycle time by claim type, cost variance by workshop, and supplement frequency by assessor as a routine output rather than a quarterly exercise.
3.2 Underwriting and policy administration
What the regulations demand
Underwriting and policy administration are affected by four of the five frameworks. Open Finance requires insurers to expose customer-level product data through standardized APIs, on customer consent, for cross-sectoral data sharing purposes. The UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021) requires traceable consent for processing of personal data, technical and organizational safeguards, DPO appointments where applicable, and data protection impact assessments for high-risk processing. IFRS 17 requires insurers to retain ten or more years of granular policy-level data with consistent formats, including assumption changes and historical pricing decisions. The new CBUAE Law brings the full operation under a consolidated supervisory framework that expects documented governance over pricing, underwriting guidelines, and customer data handling.
What legacy underwriting operations look like
Most UAE insurers run on multiple policy administration systems, typically accumulated through lines of business, geographies, or acquisitions. A commercial lines system will coexist with a retail motor platform and a separate health administration system, each with its own data model, customer master, and reporting output. Underwriting for commercial lines is frequently conducted in spreadsheets, with rating models that exist as Excel macros maintained by individual underwriters. Customer data is duplicated across systems with no reliable master record; the same policyholder may appear with three different spellings, two different Emirates IDs, and inconsistent contact details. Consent tracking, where it exists at all, is captured as a checkbox in the application form rather than as a governed data point linked to specific processing purposes.
What must change
The shift required is from multiple policy systems coexisting with manual workarounds to a governed customer and policy data layer that sits above the application systems and provides a single queryable view. This is not necessarily a policy administration system replacement program, though for some insurers it will become one. It is a data governance program that establishes clear ownership of customer identity, policy state, consent records, and pricing decisions as data products rather than application outputs.
Practical elements of the change include the establishment of a customer master data management capability with deterministic identity resolution across source systems, a consent management platform that records consent at the level of specific processing purposes with full audit history, an API gateway capable of exposing customer and policy data externally under Open Finance obligations, and a historical data reconstruction program for IFRS 17 gaps where ten-year continuity does not currently exist.
What good looks like
In a compliant state, an underwriter can retrieve a complete, time-sequenced view of any customer across all products and all historical periods, with consent status attached to each data element. A data protection officer can demonstrate, for any processing activity, the legal basis under PDPL and the consent history supporting it. Open Finance API requests can be served without special integration work, because the API gateway is already exposing governed data from the data layer rather than assembling responses from source systems on each request. IFRS 17 actuarial extracts can be generated on demand without manual reconciliation between the policy administration system and the actuarial database.
3.3 Finance and actuarial reporting
What the regulations demand
Finance and actuarial reporting sit at the center of the IFRS 17 requirement, and are also affected by the new CBUAE Law's consolidated reporting expectations and by indirect requirements flowing from AML/CFT (which requires financial transactions to be traceable end to end) and Open Finance (which requires financial exposure data to be available for customer-consented sharing).
CBUAE enforced IFRS 17 from 1 January 2023 without extensions. The regulator has run a rigorous three-phase transition supervision program in which insurers submitted four to seven rounds of technical documents, including actuarial model validation reports, and the regulator has required the development of governance frameworks covering board-level awareness, internal audit mechanisms, and documented processes for data integrity, assumption management, and risk assessment. The framework is active, not a one-time implementation, and supervisory expectations continue to rise.
What legacy finance and actuarial operations look like
In most UAE insurers, finance and actuarial still operate as separate data pipelines that converge only at quarter-end and year-end reporting cycles. The general ledger lives in a finance system that records transactions at the account level but not at the contract level. Actuarial data is extracted from the policy and claims systems, cleaned and adjusted in Excel or specialized actuarial software, run through reserving and IFRS 17 models, and then reconciled back to the finance ledger through manual entries. Reconciliation breaks are common and frequently resolved through adjusting entries rather than by fixing the underlying data. Historical data, required under IFRS 17 for ten or more years, is assembled by hand from archived extracts, some of which predate the current policy administration system and exist only as database backups or paper records.
What must change
The shift required is from separate finance and actuarial pipelines converging at reporting deadlines to an integrated data pipeline in which contract-level economic events flow directly from the operational systems into both the general ledger and the actuarial data store, with automated reconciliation and exception management. The actuarial models themselves must be version-controlled, validated, and governed as enterprise assets rather than as individual analysts' spreadsheets. The historical data estate must be remediated, consolidated, and made queryable on demand, with gaps explicitly documented and approved by the audit committee.
Practical elements of the change include event-driven accounting that posts contract-level events to the ledger automatically, actuarial model governance with documented ownership, validation, and change control, a historical data remediation program with a clear remediation plan for any gaps, and a board-level reporting mechanism that tracks IFRS 17 compliance as an operational metric rather than as a one-time project deliverable.
What good looks like
In a compliant state, the IFRS 17 reporting cycle becomes a routine operational output rather than a quarter-end crisis. The actuarial team can produce reserving and disclosure figures with full confidence in the underlying data. The finance team can trace any ledger balance back to the operational events that generated it. The audit committee has visibility into data quality and assumption management as a standing agenda item rather than as a year-end surprise. External auditors spend their time challenging judgments rather than reconstructing data.
3.4 Compliance and AML/CFT
What the regulations demand
Federal Decree-Law No. 10 of 2025 and Cabinet Resolution No. 134 of 2025 came into force on 14 October 2025 and replaced the previous AML/CFT framework. The executive regulations contain 71 articles and approximately 300 enforceable requirements. Insurance companies are explicitly within the scope of CBUAE supervision under the framework. Key operational requirements include connection to the goAML platform for suspicious transaction reporting, real-time transaction screening against sanctions and PEP lists, automated suspicious activity reporting workflows where red flags are triggered, risk-based customer due diligence with ongoing monitoring, and a compliance-by-design approach in which AML/CFT protocols are embedded into the core operational systems rather than applied as post-hoc controls.
CBUAE has made clear through its supervisory activity that the expectation is for real-time screening and automated workflows, not batch extracts processed overnight. The regulator is also increasingly focused on the quality of suspicious activity reports, not only their volume. The ratio of actionable reports to noise is a supervisory concern.
What legacy compliance operations look like
Most UAE insurers today run AML/CFT as a batch process. At the end of each business day, transaction data is extracted from the policy and claims systems and uploaded to a compliance platform that performs screening against sanctions lists. Exceptions are reviewed the following morning by a compliance analyst, who decides whether to escalate to a suspicious activity report. The SAR itself is drafted by hand in a word processor, reviewed by a compliance officer, and submitted to the goAML platform as a separate activity. The end-to-end cycle between a transaction occurring and a SAR being filed can be measured in days, not minutes.
This approach satisfied the previous regulatory environment. It does not satisfy the 2025 framework. The new rules require real-time screening, automated workflows, and embedded controls. A batch process with next-day review does not meet the definition of real-time under the current supervisory expectations, regardless of how diligent the compliance team is.
What must change
The shift required is from post-hoc batch compliance to embedded real-time compliance. Every operational transaction, whether a claim payment, a premium receipt, a supplier payment, or a reinsurance settlement, must flow through a screening engine before it is executed, not after. Exceptions must be raised in the operational workflow itself, with the compliance team able to clear, hold, or escalate without leaving the system. Suspicious activity reports must be generated automatically from the event data, with human review happening before filing rather than after the fact. Compliance events must become first-class data in the operational system, visible and auditable like any other event.
The practical architectural element underpinning all of this is that the compliance engine must sit inside the transaction flow, not alongside it. This is the single hardest change for insurers still running on legacy claims and policy systems, because legacy systems frequently cannot accommodate an inline compliance check without significant re-engineering.
What good looks like
In a compliant state, the compliance officer can demonstrate to CBUAE, on request, that every financial transaction processed in the last twelve months was screened against current sanctions and PEP lists at the moment of execution, that every exception was reviewed and resolved within defined time windows, and that every suspicious activity report was generated, reviewed, and filed through a controlled workflow with full audit history. The compliance function is no longer a separate control layer fighting the operational systems for data. It is an operating mode of the systems themselves.
3.5 IT architecture and data governance
What the regulations demand
IT architecture and data governance are not the subject of a specific regulation on their own. They are the common underlying capability that all five frameworks implicitly require. The CBUAE FIT Programme builds the shared infrastructure; Open Finance requires API exposure over a governed data layer; the new CBUAE Law expects documented operational controls; AML/CFT requires embedded real-time processing; IFRS 17 requires governed granular historical data with documented lineage and quality controls. The PDPL adds a further requirement for technical and organizational safeguards over personal data, with DPO appointments for large-scale processing of sensitive data.
Taken together, these frameworks describe the outline of a data operating model that most UAE insurers do not currently have. It includes a governed data layer with clear ownership and stewardship, an enterprise data catalog, an API gateway with appropriate authentication and consent handling, a consent management platform, integration with UAE PASS for identity, documented data lineage and quality controls, and a change management process for the data model itself.
What legacy IT architectures look like
The typical UAE insurer IT estate is the product of fifteen or more years of accumulated decisions. It includes a core policy administration system procured ten years ago, a claims system added later, a finance system running on a different technology stack, an actuarial environment maintained by a small team of specialists, a compliance platform added when AML/CFT rules first changed, a data warehouse built for reporting purposes, and a range of shadow systems — departmental databases, Excel models, Power BI dashboards, and SharePoint libraries — that hold critical operational information outside the formal architecture. Integrations between these systems are typically point-to-point, maintained by a small integration team or by external vendors, with limited documentation and high key-person risk. Data governance exists on paper as a set of policies but is rarely enforced at the architectural level. There is frequently no single authoritative inventory of what data the insurer holds, where it sits, who owns it, or who is responsible for its quality.
What must change
The shift required is from an integration-heavy application estate to a data-centric architecture in which the governed data layer is the primary asset and the applications are interchangeable consumers and producers of that data. This is a significant architectural change, and it is the one that will determine whether the other four functional changes described in this section can actually be delivered.
Practical elements include the establishment of a data governance function with real authority (not a committee; a function with the power to approve or block changes to critical data), an enterprise data catalog that documents every significant data asset and its owner, an API gateway serving as the single integration spine, a consent management platform covering all customer data processing activities, integration with UAE PASS as a foundational identity service, and a data quality measurement and remediation program with transparent metrics reported to the board.
What good looks like
In a compliant state, the IT architecture treats the data layer as the primary asset and the applications as secondary. New products can be launched without building new integrations from scratch, because the data is already governed and exposed through the gateway. Regulatory change, whether a new reporting requirement, a new compliance rule, or a new API obligation, becomes a change at the data layer rather than a project at the application layer, which reduces the cost and time of response. The IT function moves from firefighting point-to-point integrations to managing a coherent architecture, and the business sees IT as an enabler of regulatory compliance rather than a blocker.
4. The constraint reality
Any paper that tells UAE insurers to simply modernize has not met a UAE insurer. The operations leaders reading this already know what needs to change. What stops them is not imagination or ambition. It is a set of structural constraints that do not disappear because a regulator publishes a circular. Before the next section describes what good looks like, this section names the constraints that any credible plan has to work around.
4.1 The system estate
A typical UAE composite insurer runs somewhere between two and four policy administration systems, two to three claims systems, a separate actuarial reserving platform, a finance suite that was fitted in a different decade, a compliance and AML tool that was bolted on after 2020, and a document management layer that nobody fully owns. Several of these systems are on vendor versions that are no longer the vendor's current product. Some are on-premise. A few are held together by middleware scripts that exist only because one engineer wrote them in 2017 and nobody has dared touch them since.
None of this is unusual. It is the result of two decades of growth, acquisitions, line-of-business expansions, and pragmatic decisions that made sense at the time. The practical consequence is that a single regulatory change, such as a new CBUAE reporting field, can require coordinated updates across five systems, each with its own release cycle, its own vendor, and its own integration dependencies. The engineering effort is real. The testing burden is larger. The risk of breaking something live is non-trivial.
Most insurers know their estate needs a rebuild. Most have a multi-year program on the books to do it. Most of those programs have slipped at least twice. This is the honest starting point.
4.2 Bureaucracy and the approval tax
Any program of material size inside a UAE insurer runs through a sequence of gates: business case, IT architecture review, procurement, vendor security assessment, legal, risk committee, board subcommittee, and in some cases the main board. Each gate has a legitimate purpose. Together they add twelve to twenty-four months to anything that touches core systems, even before a single line of code is written.
Change management committees add further drag. Every proposed change has to be scheduled, risk-rated, communicated, and slotted into a release window that does not collide with month-end close, quarter-end reporting, renewal season, or the run-up to audit. The time between decision made and change in production is often measured in quarters, not weeks.
This is not a criticism. Financial services bureaucracy exists because the cost of uncontrolled change in a regulated firm is higher than the cost of delay. But it is the environment any transformation plan has to survive.
4.3 Organizational inertia
Teams have been trained on the current systems. KPIs and bonuses are tied to metrics that the current systems produce. Senior staff have built their authority on knowing how the maze works, including which fields matter, which reports are reliable, and which workarounds are load-bearing. A unified operating model threatens all of that. Not because the people involved are obstructive, but because the transition period is genuinely painful for anyone whose job depends on the status quo working.
Middle management is often the real friction point. Executives can approve a strategy. Frontline staff can be retrained. It is the layer in between — the heads of function who have to deliver current-quarter numbers on legacy tooling while also running the program that will eventually replace it — who carry both loads and have the least slack to absorb change.
4.4 Finite project capacity
The honest constraint most strategy papers ignore is that an insurer cannot run five major programs in parallel without failing all five. There is a limited number of internal people who can own a significant change initiative, a limited number of external consultants who understand both the regulation and the insurer's specific estate, and a limited number of board bandwidth slots for project oversight.
The implication is brutal but necessary. If an insurer decides to rebuild its policy admin core in 2026, it cannot simultaneously rebuild its claims platform, its finance suite, and its compliance stack. Something has to be sequenced. Something has to be outsourced. Something has to be accepted as good enough for now. Any plan that does not make explicit sequencing decisions will end up making them implicitly, under pressure, when the deadline is six weeks away.
4.5 Board risk appetite
Board directors are not technology transformation specialists. They read the same industry press as everyone else. They hear about failed core system replacements at other insurers. They have seen budget overruns turn into board-level incidents. They approve large programs reluctantly, and they monitor them nervously.
For marginal lines, motor being the obvious example in the UAE context, this is particularly acute. Motor is a high-volume, low-margin line that consumes a disproportionate share of operational capacity. A board that is asked to fund a multi-million-dirham rebuild of motor claims infrastructure, for a line that barely breaks even, will push back hard. The question the board will ask is not whether motor should be modernized but whether the insurer itself has to be the one modernizing it. That question has a defensible answer, and the answer shapes the close of this paper.
4.6 What this means for any credible plan
Taken together, these five constraints mean that the right answer for most UAE insurers is not to replace everything before September 2026. That plan will fail. The right answer is a sequenced program that concentrates internal capacity on the lines and functions where ownership is non-negotiable, uses specialist partners for domains where the case for building in-house is weak, and designs the unified operating model as a target state that the estate migrates toward rather than as a single cutover event.
The next section describes what that target state looks like. The section after that describes the sequence. Section 7 addresses the specific case for outsourcing motor claims to a specialist, which is the practical implication for most insurers reading this paper.
5. What a unified operating model looks like
Unified is one of those words that sounds obvious until someone asks what it means in practice. This section defines it through six operating principles that any target-state design should satisfy. These are not technology choices. They are design constraints that determine whether the resulting operating model can carry the regulatory load described in Section 2 without collapsing back into the workaround patterns described in Section 4.
5.1 A single source of truth per data domain
Policy data lives in one system. Claims data lives in one system. Customer identity lives in one system. Financial transactions live in one ledger. Each domain has one authoritative record, and every other system reads from that record rather than maintaining its own copy. Reconciliation between systems stops being a monthly exercise because there is nothing to reconcile.
This is the hardest principle to implement and the one insurers most often compromise on. The compromise is always expensive later. When IFRS 17 asks for auditable reconciliation between claims reserves and finance postings, the insurer that maintained separate copies in claims and finance spends three weeks a quarter explaining variances. The insurer that runs one ledger spends three hours.
5.2 Event-driven flow
Business events such as policy issued, premium paid, claim notified, settlement approved, and payment released are published to a central event stream as they happen. Downstream systems subscribe to the events they care about. Finance sees the settlement approval at the same moment as operations. Compliance sees the large payment trigger at the same moment as the payment team. Reporting is built on the same event stream.
The alternative is the current pattern: nightly batch extracts, morning reconciliation, discrepancies that are investigated two days later. Batch processing is incompatible with AML real-time monitoring, with open finance API response-time expectations, and with any regulator that can log into its own dashboard and watch the numbers update. The CBUAE increasingly can.
5.3 Embedded compliance
Compliance controls live inside the transaction flow, not alongside it. The AML screening runs before the payment is released, not after. The consent check runs before the data is shared, not during the audit. The IFRS 17 cash flow attribution runs when the claim transaction is booked, not when the finance team reopens it for quarter-end.
Embedded compliance changes the economics of the compliance function. Instead of a large team that investigates and reconciles exceptions after the fact, a smaller team monitors a flow that is correct by construction. The headcount savings are real. The audit advantage is larger.
5.4 Data governance as a product
Data definitions, lineage, ownership, and quality rules are managed like a software product: versioned, documented, tested, and owned by a named team. When a new regulation introduces a new field, the change goes through a controlled release. When a downstream team needs a new metric, they request it against a documented catalog. When the regulator asks why a number moved, the lineage answers in minutes.
This is the principle that separates insurers who pass a CBUAE data audit from insurers who spend the audit week reconstructing spreadsheets. The PDPL and the Open Finance regulation both assume this discipline exists. Neither works without it.
5.5 API-first by default
Every system exposes its data and its transactions through documented APIs. Internal integrations use the same APIs as external partners. There is no special connector for the actuarial team, no bespoke extract for the CFO, no manual CSV for the compliance officer. If the capability is not in the API, it does not exist.
The discipline this imposes is uncomfortable in the short term and liberating in the long term. Short term, it slows down the first three integrations because the API has to be designed properly. Long term, every subsequent integration is faster, and the insurer is ready for Open Finance, for UAE PASS identity, for insurer-to-garage APIs, and for whatever the CBUAE asks for next, without a bespoke project each time.
5.6 Identity and consent as infrastructure
Customer identity is federated with UAE PASS where applicable. Consent is captured, versioned, and checked on every data use. The insurer can answer, for any customer at any moment, three questions: who they are, what they have agreed to, and what has been done with their data. The answer lives in a system of record, not in a shared drive of signed PDFs.
This is the foundation the UAE PDPL assumes, the Open Finance regulation requires, and the government digital strategy is built on. Insurers who treat identity and consent as compliance paperwork will be outcompeted by insurers who treat them as product capability.
5.7 The operating model implication
These six principles are not a menu. An operating model that satisfies five out of six is not 83% ready. It will fail the first audit that touches the missing principle, because regulatory frameworks compound. The PDPL audit needs the lineage from data governance and the consent infrastructure from identity. The IFRS 17 audit needs the single ledger and the event flow. The AML inspection needs embedded compliance and the single customer record. Each weak link pulls the others down.
The implication is that the target state has to be designed coherently, even if it is delivered in stages. Insurers who bolt on one capability at a time, without a unifying architecture, end up with the same fragmentation they started with, just more expensive and harder to explain to the regulator. Section 6 describes a sequence that delivers the target state in stages without losing the coherence.
6. A practical implementation sequence
This section describes a sequence that delivers the six principles in Section 5 while respecting the five constraints in Section 4. It is not a blueprint, because every insurer's estate is different, but the phasing logic is common. The sequence is built around a 24-month horizon because that is the longest period over which a board will sustain attention on a single program, and the shortest period over which a credible operating-model shift can be delivered.
6.1 Months 1 to 3: diagnostic and decision
The first 90 days are not a project. They are a decision period. The deliverable is a board paper that answers five questions with evidence: what is the current state of the estate, where are the regulatory gaps, what lines and functions will be built in-house, what will be partnered or outsourced, and what the investment envelope looks like for the full 24 months.
The diagnostic work involves a data and systems inventory, a regulatory gap assessment mapped to the nine frameworks in Appendix A, a capability assessment against the six principles in Section 5, and a commercial assessment of which lines justify in-house ownership of claims and operations. The output is a sequencing decision, not a wish list.
Most insurers resist this step because the diagnostic work feels like delay. It is not. Programmes that skip the diagnostic spend the first year building in the wrong direction and the second year correcting. Programmes that do the diagnostic properly spend the remaining 21 months building once.
6.2 Months 4 to 9: foundation
The second phase builds the architectural foundation: the event stream, the core data domains, the identity and consent layer, and the API framework. None of these are visible to customers or frontline staff. All of them are prerequisites for anything that comes later.
This is the phase boards find hardest to fund because the deliverables are infrastructural. The honest answer is that without the foundation, every subsequent phase becomes another workaround on top of the existing estate. The investment case for the foundation is the avoided cost of the workarounds, and that avoided cost is documentable from the insurer's own history of previous regulatory-driven changes.
Parallel to the foundation work, the insurer should begin decoupling one high-volume domain from the legacy core as a proof point. Motor claims is often the right candidate because it is high volume, relatively self-contained, and, as Section 7 explains, a strong candidate for specialist partnership.
6.3 Months 10 to 15: hard lifts
The third phase addresses the systems that cannot be left alone: the policy administration core for any line that is staying in-house, the IFRS 17 finance and actuarial integration, and the AML and compliance flow. These are the expensive, risky, long-duration workstreams that the program was really about.
Running them in parallel with the foundation work in phase two is a mistake. Running them before the foundation is laid is a larger mistake. Running them in phase three, on top of a working foundation, is the path that has the highest probability of landing on time.
The specific sequence inside phase three depends on the insurer's regulatory exposure. If IFRS 17 audit findings are the immediate pain, finance and actuarial come first. If AML inspection risk is the immediate pain, compliance comes first. If the policy admin core is the blocker for everything else, it comes first. The sequencing decision is part of the phase-one board paper.
6.4 Months 16 to 21: compliance steady state
The fourth phase is when the operating model starts to feel different. The major rebuilds are in production. Reporting comes out of the event stream rather than spreadsheets. The compliance function is monitoring a correct-by-construction flow rather than investigating exceptions. The finance close takes days rather than weeks.
The work in this phase is less heroic than the previous phases and more uncomfortable. It is the work of decommissioning legacy systems, retraining staff on the new model, retiring the workarounds that are no longer needed, and proving to the regulator that the new estate meets the frameworks in Section 2. The instinct to keep the old systems just in case has to be actively resisted, because every retained legacy system creates a reconciliation burden that erodes the benefits of the new one.
6.5 Months 22 to 24: operating model as commercial advantage
The final phase shifts the program from defense to offense. By month 22, the insurer has an operating model that can onboard a new product in weeks rather than quarters, integrate a new distribution channel through an API rather than a project, and answer a regulator's question from a live dashboard rather than a six-week data request. These capabilities are commercial advantages, not compliance artifacts.
The insurers who get to this phase first will be the ones winning tenders, signing partnerships, and absorbing market share from the insurers who are still in phase two. The compliance deadline that drove the program will feel, in retrospect, like the lesser of the reasons to have done it.
6.6 What breaks this sequence
Three things routinely destroy a 24-month program: changing the scope mid-flight, under-resourcing the diagnostic, and treating the sequence as a suggestion rather than a commitment. The remedy for all three is the same, which is board-level discipline enforced by a named program sponsor with the authority to say no to scope changes that are not regulatory in origin.
One more thing breaks the sequence: attempting to do it all in-house on lines that do not justify the capacity cost. That is the specific case Section 7 addresses.
7. Motor claims: the first domino
The argument so far applies to every line of business a UAE insurer writes. Section 7 is narrower. It makes the case that motor claims is the line insurers should move first, and that for most insurers the right move is to hand it to a specialist rather than rebuild it in-house.
Motor is the right place to start because it is where the regulatory load is heaviest and the in-house case is weakest. Axxion exists to take that load off the insurer's transformation program while lifting the whole repair chain to a standard the new frameworks require. The conversation is confidential, low-commitment, and useful regardless of the outcome. Insurers should aim to open it in the next quarter.
7.1 Why motor claims is the right place to start
Motor is the highest-volume, lowest-margin line in most UAE composite insurers' books. It consumes a disproportionate share of operational capacity, including claims staff, IT releases, vendor management, customer service, and reporting, and returns the least commercial upside for that investment. When a board looks at where to allocate a finite transformation budget, motor is almost always the line where the in-house case is weakest.
Motor is also the line where regulatory exposure is most concentrated. Every principle in Section 2 applies to motor more sharply than to any other line: high claim frequency means AML thresholds are touched more often, large settlement volumes make IFRS 17 cash flow attribution more material, customer data flows are more intensive, and customer experience expectations are highest because motor is the touchpoint where retail customers actually interact with their insurer. A motor claims operation that is not unified, not event-driven, and not audit-ready is the single biggest regulatory liability most UAE insurers carry.
Fixing motor first has a second advantage. It demonstrates the target operating model in a contained domain before the insurer commits to rebuilding the rest of the estate. The lessons from the motor rollout inform every subsequent phase. And the capacity that motor claims currently consumes, including staff, budget, and board attention, is released back into the rest of the program.
7.2 Why specialist partnership is the pragmatic answer
The in-house alternative is real but expensive. Building a motor claims operation that satisfies all six principles in Section 5 requires specialist capability the insurer may not have: repair network management, ADAS and EV repair standards, fraud detection, parts supply economics, garage SLA enforcement, audit-grade documentation, and the technology platform underneath all of it. Each of these is a discipline. Together they are a business. Running that business well is not the core competency of a composite insurer, and doing it badly is the source of most motor underwriting losses in the UAE market.
A specialist third-party administrator that already operates this model, with the repair network, the fraud controls, the technology platform, the compliance discipline, and the audit trail in place, can absorb the motor claims function at a lower marginal cost than the insurer can build it. The insurer keeps the customer relationship, keeps the underwriting, keeps the pricing, and keeps the brand. The operational load moves to a partner who has the scale and focus to do it well.
This is the model UK, European, and parts of the US motor insurance markets have used for decades. It is the model the UAE is now mature enough to support.
7.3 What Axxion offers
Axxion Claims Settlement Services L.L.C. is a UAE-licensed motor claims operating partner built specifically for this moment in the market. The senior team carries more than forty years of hands-on motor claims experience across the UAE and international markets, and the operation runs on a governed repair network rather than an open panel. This matters because the regulatory frameworks in Section 2 cannot be satisfied by software alone. They require the claims operation itself, including the people who handle the files, the workshops that execute the repairs, and the controls that sit around both, to meet a higher standard than legacy motor claims functions have historically been held to.
The platform is designed to the six principles in Section 5: single source of truth, event-driven flow, embedded compliance, governed data, API-first, and identity- and consent-aware. The services in scope include first notification of loss through digital and voice channels, liability assessment, repair network management across the UAE, estimate review and supplement control, parts and labor cost containment, salvage and subrogation recovery, fraud detection, settlement processing, and full audit-grade documentation for every claim. Insurer integration is handled through APIs that plug into the insurer's existing estate without requiring a rebuild of surrounding systems.
The governed garage network is the part that most in-house motor claims operations cannot replicate at scale. Axxion operates to published repair standards, fixed labor rates, transparent parts pricing, and documented quality control on every job. The result is that the insurer sees the real cost of each repair, the policyholder gets a repair that meets modern safety standards (ADAS calibration, high-voltage systems, structural integrity), and the garage operates a sustainable business on fair terms. The operating standard lifts the whole chain: better repairs produce safer roads, fair treatment creates better customers, and governed workshop standards build sustainable repair businesses. That is not a by-product of the operating model. It is the operating model.
For insurers whose broader operating-model transformation is still in the diagnostic or foundation phase, Axxion provides a way to take motor claims out of the critical path entirely. The insurer's internal transformation capacity can be redirected to the lines and functions where in-house ownership is non-negotiable. The motor claims function continues operating, and in many cases improves, while the insurer focuses on the rebuilds that only the insurer can do.
7.4 Who should engage
This paper is written for insurance operations leaders, and the specific leaders who should consider engagement are the COO, the head of motor claims, the CIO or head of transformation running the 24-month program described in Section 6, and the CFO whose IFRS 17 and cost-base conversations are the reason the program exists in the first place. Each of these stakeholders has a different question about motor claims, whether operational quality, regulatory exposure, transformation capacity, or unit economics, and Axxion is set up to answer all four in the same conversation.
The conversation is worth having even for insurers who believe they will keep motor in-house. Understanding the specialist alternative is the only way to price the in-house option honestly, and the diagnostic benchmark Axxion provides is useful regardless of the decision the insurer reaches.
7.5 How to make contact
Axxion's managing director, Frederik Bisbjerg, leads insurer engagement directly during this market phase. Initial conversations are confidential, cover a structured assessment of the insurer's current motor claims operation against the six principles in Section 5, and do not require any commercial commitment. The output of the initial engagement is a written assessment the insurer can take back to its own board, whether or not Axxion is the chosen partner.
Contact details and next steps are available at axxion.co, or by direct email to the managing director at f@axxion.co. Insurers planning their response to the September 2026 compliance window should aim to have the initial conversation during Q2 2026. The sequencing in Section 6 only works if the motor decision is made before the foundation phase begins.
About Axxion Claims Settlement Services L.L.C.
Axxion Claims Settlement Services is a Dubai-based end-to-end motor claims management company and the UAE's first dedicated motor TPA. Axxion manages the full claims lifecycle for insurance partners, from first notification of loss through repair coordination, quality control, and settlement, operating on a six-layer claims architecture designed around regulatory compliance, data integrity, and AI-augmented decision-making.
Axxion is part of the Skelmore Group, a diversified automotive and insurance services group founded in Toronto in 1994. The group operates across North America and the Middle East with approximately $650 million in revenue and 4,000 employees, spanning multi-brand automotive aftermarket services, retail and wholesale distribution, and luxury automotive.
About Frederik Bisbjerg
Frederik Bisbjerg is Co-founder and Managing Director of Axxion.
His career spans more than two decades of insurance leadership across the MENA region, including roles as CEO of Al Wathba Insurance, Chief Transformation Officer at AXA Global Healthcare, Senior Vice President of Digital Transformation and Innovation at Daman National Health Insurance Company, and Executive Vice President at Qatar Insurance Group.
Before moving into executive roles, he spent several years at a top-tier management consulting firm, where he developed the habit of building alliances between business partners that had not previously thought to work together.
He also serves as Head of MENA and Digital Transformation specialist at The Digital Insurer, where he is a founding member of the world's first mini-MBA in Digital Insurance and lectures on strategy, transformation, big data, and technology architectures.
He is the author of the best-selling Insurance_Next, a practical guide to transforming incumbent insurers into flexible, resilient organizations ready for the post-COVID, generative-AI era. The ideas in this white paper grew directly from his experience: the gap between what AI can technically do in claims and what governance structures actually exist to make it safe, auditable, and worth an insurer's trust.
Appendix A – Regulatory evidence base
The nine regulatory and strategic frameworks referenced throughout this paper, consolidated into a single evidence base. Each entry lists the issuer, key dates, the specific demand placed on insurer operations, and the sources used.
A1. CBUAE Financial Infrastructure Transformation Programme
CBUAE launched the FIT Programme in 2023 with nine initiatives and a 2026 full-integration target. Stage one covered payment infrastructure: a domestic card scheme, an instant payments platform, and Central Bank Digital Currency for cross-border and domestic use. Stage two covers the infrastructure insurers are expected to plug into, including Financial Cloud, eKYC, and Open Finance. The program is reported to be 85 percent complete as of 2025.
The implication for insurers is that the shared financial infrastructure is being rebuilt around digital-native standards. Any participant running on isolated legacy stacks will either integrate or fall out of the ecosystem.
Sources: CBUAE press releases; Global Government Fintech.
A2. CBUAE Open Finance Regulation
Issued in 2024, the Open Finance Regulation is the clearest single signal that cross-sectoral data unification is now regulatory policy rather than a market trend. The regulation applies to current and savings accounts, credit cards, loans, mortgages, and explicitly to motor, health, life, and property insurance products. Participation is mandatory for licensees on a phased basis. The framework relies on a trust framework, a central API hub governed by Nebras (a CBUAE spin-off), and common infrastructural services. Insurers must expose customer data and support transaction initiation through standardized APIs.
An insurer whose claims data lives in Excel files, email threads, and WhatsApp groups cannot meet API-first obligations without prior rebuild.
Sources: CBUAE Rulebook; DLA Piper; Bird & Bird; Pinsent Masons.
A3. Federal Decree-Law No. 6 of 2025 (new CBUAE Law)
The new CBUAE Law repeals and replaces the 2018 law. It introduces a consolidated regulatory framework covering banks, payment providers, enabling technology providers, and insurance business under a single supervisor. Entities newly in scope, or existing entities required to make changes, have until 16 September 2026 to regularize licensing and compliance. This is the correct anchor for the September 2026 deadline referenced throughout this paper. The date is real and material, but the framework is a broader regulatory consolidation rather than a motor-specific circular.
Federal Decree-Law No. 48 of 2023 Regulating Insurance Activities remains the insurance-specific governing law and sits in parallel with the new CBUAE Law. It replaced Federal Law No. 6 of 2007 and provides the licensing, conduct, and insurance-related profession requirements that apply to insurance companies, brokers, loss adjusters, and TPAs. The new CBUAE Law does not displace it; the two operate together as the primary regulatory stack for UAE insurance business.
The operational consequence is that every in-scope insurer has to demonstrate, by 16 September 2026, an operating model that meets the consolidated licensing, governance, and reporting standards of the new framework, while continuing to comply with the insurance-specific obligations under the 2023 law.
Sources: White & Case; Norton Rose Fulbright; Ashurst; GLA & Company; UAE Legislation portal (FDL 48/2023).
A4. Federal Decree-Law No. 10 of 2025 and Cabinet Resolution 134/2025 (AML/CFT)
The new UAE AML/CFT law came into force on 14 October 2025. The accompanying Executive Regulations contain 71 articles and approximately 300 enforceable requirements. Insurance companies are in scope as Licensed Financial Institutions under CBUAE supervision. Obligations include mandatory connection to the goAML platform for suspicious transaction reporting, real-time transaction screening, and automated Suspicious Activity Report workflows. Law firm commentary describes the expected operating model as compliance-by-design, with compliance embedded into core operating systems rather than monitored alongside them.
For a claims operation, this means an AML control layer that runs before a payment is released, on a data flow that is continuous rather than batched. Insurers that cannot track a claim from FNOL through settlement in one data flow cannot meet the screening obligation on that flow.
Sources: Al Tamimi & Company; CBUAE Rulebook; amluae.com.
A5. IFRS 17 Insurance Contracts
CBUAE enforced IFRS 17 from 1 January 2023 without extensions and ran a rigorous three-phase transition process in which insurers submitted four to seven rounds of technical documents including actuarial model validation reports. The standard requires highly granular historical data, often ten or more years, with consistent formats and reliable traceability. CBUAE has explicitly required governance frameworks covering board-level oversight, internal audit, documented processes for data integrity, assumption management, and risk assessment.
Legacy systems struggle to supply this level of detail. IFRS 17 is the clearest governed, granular, unified data mandate already in force for UAE insurers, and it predates the more recent frameworks by several years.
Sources: CBUAE Rulebook – Financial Reporting and External Audit Regulation; PwC Middle East; BADRI Consultancy; Insights UAE.
A6. UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021)
The PDPL came into force on 2 January 2022 and became enforceable in January 2023. Data controllers must adopt technical and organizational safeguards against breach, destruction, alteration, or tampering. Data Protection Officer appointments are required for large-scale processing of sensitive data. Data Protection Impact Assessments must be completed before starting high-risk processing. Penalties range from AED50,000 to AED5 million.
For a motor claims operation, PDPL obligations are impossible to meet on a patchwork of personal devices, shared drives, and ad-hoc spreadsheets. There is no way to demonstrate controlled processing, lineage, or deletion rights on data that lives in WhatsApp.
Sources: UAE Legislation portal; Securiti; CookieYes; DPO Europe.
A7. We the UAE 2031 and UAE PASS
The We the UAE 2031 vision, launched in November 2022, sets the federal direction toward a digitally-enabled government. UAE PASS is its operational expression: a single digital identity, single sign-on, digital wallet, and document signing service. More than 15,000 services across 350+ government entities are already accessible through the platform, including from the private sector.
This is the federal-level precedent on which the Sheikh Hamdan directive builds. The direction of consumer expectation is established: individuals and businesses are being trained to expect unified digital interactions, and fragmented insurer processes are increasingly out of step with that expectation.
Sources: u.ae; TDRA; Zawya.
A8. Dubai Economic Agenda D33
D33 is Dubai's ten-year economic strategy, launched in 2023, targeting a doubling of the emirate's economy by 2033 and AED32 trillion in cumulative GDP. The digital economy is a core pillar with an explicit AED100 billion annual contribution target. The agenda includes 100 transformation projects and prioritizes AI, fintech, and advanced manufacturing.
D33 is not a regulation, but it is the strategic context in which the Hamdan directive sits. The emirate has committed to a decade of digital-first economic growth, and the regulatory decisions cascading from that commitment reflect it.
Sources: u.ae; Invest in Dubai; Dubai Executive Council.
A9. Sheikh Hamdan unified digital services directive
On 1 April 2026, Sheikh Hamdan bin Mohammed bin Rashid Al Maktoum, Crown Prince of Dubai and Chairman of the Executive Council, directed all Dubai government entities to integrate individual and business services into a single digital platform within twelve months. Digital Dubai has been assigned coordination responsibility for the implementation.
This is the most recent and most visible signal of the direction, but it is the capstone of a multi-year program rather than the start of it. The frameworks in pillars A1 through A6 were already in motion when the directive was issued.
Sources: Dubai Media Office; Gulf News; Fast Company Middle East; Gulf Today.
Note on gaps in the evidence base. Three points where the public record is thinner than ideal. First, no CBUAE motor-specific circular referencing immutable audit trails from FNOL to settlement was found in public sources; the framing used by some industry commentators appears to be a market-level interpretation of the combined effect of IFRS 17, AML/CFT, and PDPL rather than a verbatim regulatory requirement. Second, the exact insurer-by-insurer phasing of the Open Finance roll-out was not confirmed in the research pass behind this paper. Third, whether Federal Decree-Law No. 6 of 2025 contains motor-specific provisions beyond the general framework was not independently verified against the Arabic-language source text. Insurers relying on this briefing for compliance planning should verify the specific articles applicable to their licensing category directly against the CBUAE Rulebook or through their own legal counsel.
Appendix B – Regulatory calendar
The key dates referenced in this paper, shown chronologically. Dates in the past mark frameworks already in force. Dates in the future mark the windows in which insurer operating-model decisions have to be made.
2 January 2022 – UAE PDPL (Federal Decree-Law No. 45 of 2021)
Technical and organizational data safeguards required; DPO appointments and DPIAs in effect.
November 2022 – We the UAE 2031 vision launched
Federal digital-first direction set; UAE PASS operational.
1 January 2023 – IFRS 17 Insurance Contracts enforced by CBUAE
10+ years granular data, governance, lineage obligations active.
January 2023 – UAE PDPL enforceable
Penalties from AED50,000 to AED5 million applicable.
2023 – Federal Decree-Law No. 48 of 2023 Regulating Insurance Activities
Primary insurance-specific law; licensing, conduct, insurance-related professions.
2023 – Dubai Economic Agenda D33 launched
10-year digital economy program underway.
2023 – CBUAE Financial Infrastructure Transformation (FIT) Programme launched
Reported at 85% completion in 2025; full integration target 2026.
2024 – CBUAE Open Finance Regulation issued
Mandatory API-based cross-sectoral data sharing including insurance.
14 October 2025 – Federal Decree-Law No. 10 of 2025 (AML/CFT) in force
Real-time screening, goAML connection, embedded compliance required.
1 April 2026 – Sheikh Hamdan unified digital services directive issued
All Dubai government services into single digital platform by April 2027.
16 September 2026 – Federal Decree-Law No. 6 of 2025 (new CBUAE Law) compliance deadline
Newly in-scope entities must regularize licensing and compliance under consolidated framework.
Throughout 2026 – CBUAE FIT full integration target year
Financial Cloud, eKYC, and Open Finance infrastructure expected operational.
April 2027 – Dubai unified digital services platform target
Capstone of current digital consolidation wave at the emirate level.
The critical window. The compressed period between April 2026 and September 2026 is where insurer operating-model decisions have to be finalized. The 24-month implementation sequence described in Section 6 starts from a decision point, not from the compliance deadline. An insurer that has not completed its diagnostic and made its sequencing decisions by mid-2026 will be running the hardest part of the program under compliance pressure rather than ahead of it.
Sources
Sources are grouped by tier. All sources were consulted in the April 2026 research pass that underlies this paper. Insurers using this briefing for compliance planning should verify specific articles directly against the current CBUAE Rulebook and through their own legal counsel.
Tier 1 – Primary and regulatory
CBUAE Rulebook: Motor Insurance, Insurance Guidelines, AML/CFT, Financial Reporting and External Audit Regulation, Open Finance Regulation, Federal Decree-Law No. 6 of 2025. rulebook.centralbank.ae
CBUAE press releases: Financial Infrastructure Transformation Programme launch. centralbank.ae
Dubai Media Office: Hamdan bin Mohammed unified digital services directive, 1 April 2026. mediaoffice.ae
u.ae – official UAE Government Portal: We the UAE 2031 vision, UAE PASS, Dubai Economic Agenda D33.
UAE Legislation portal: Federal Decree-Law No. 45 of 2021 (PDPL), Federal Decree-Law No. 48 of 2023 Regulating Insurance Activities, Federal Decree-Law No. 10 of 2025 (AML/CFT). uaelegislation.gov.ae
Cabinet Resolution No. 134 of 2025 – Executive Regulations for the AML/CFT Law.
Tier 2 – Law firm and audit firm analysis
White & Case – UAE enacts the New CBUAE Law which repeals and replaces the 2018 Law. whitecase.com
Norton Rose Fulbright – UAE ushers in new era of financial regulation with Central Bank Law overhaul. nortonrosefulbright.com
Ashurst – UAE enacts landmark Central Bank law. ashurst.com
DLA Piper – New fintech regulations in the United Arab Emirates: Open Finance Regulation. dlapiper.com
Bird & Bird – UAE Central Bank Implements Open Finance Framework. twobirds.com
Pinsent Masons – Open finance in the UAE: laws and regulation. pinsentmasons.com
Al Tamimi & Company – The UAE's AML Framework: Navigating a New Era of Financial Crime Compliance in 2026. tamimi.com
GLA & Company – New CBUAE Law No. 6 of 2025: A Consolidated Overhaul. glaco.com
PwC Middle East – IFRS 17 Insurance Contracts implementation. pwc.com/m1
Moody's – CBUAE includes financial cloud, eKYC, and open finance on its agenda. moodys.com
Tier 3 – Trade press and specialist media
Global Government Fintech – UAE Financial Infrastructure Transformation Programme reported at 85% complete. globalgovernmentfintech.com
Fintechnews Middle East – UAE Central Bank Issues Open Finance Regulation. fintechnews.ae
Middle East Insurance Review – UAE IFRS 17 three-phase implementation schedule. meinsurancereview.com
Gulf News – Sheikh Hamdan directs Dubai government entities (1 April 2026) and related CBUAE coverage. gulfnews.com
Fast Company Middle East; Gulf Today – coverage of the 1 April 2026 Hamdan directive.
Insights UAE; BADRI Consultancy – IFRS 17 implementation commentary. ae.insightss.co; badriconsultancy.com
Tier 4 – Secondary references
CookieYes; Securiti; DPO Europe; Ardent Privacy – UAE PDPL general compliance guides.
amluae.com – New UAE AML/CFT Law commentary.
Hammer Mindset; Invest in Dubai; Meydan Free Zone; GCC Business Watch – D33 and We the UAE 2031 overviews.
This paper is published by Axxion Claims Settlement Services L.L.C. in the United Arab Emirates for general information and discussion purposes only. It does not constitute legal, regulatory, financial, or investment advice, and should not be relied upon as such. Regulatory references are accurate as of the date of publication to the best of Axxion's knowledge, but the underlying laws, regulations, and circulars may be updated without notice. Insurers should consult qualified legal and compliance counsel in respect of their own obligations under UAE federal law, CBUAE regulation, and applicable emirate-level requirements.
© 2026 Axxion Claims Settlement Services LLC
