Docs

Appearance

Data, Models, Monitoring, and Remediation ​

This is the operational backbone of the CBUAE guidance note: the duties that govern how data is handled, how models are validated and bounded at deployment, how activity is logged, how deployed AI is monitored and reviewed, how incidents and harms are contained and remediated, and the proactive use of AI to detect fraud and financial crime. It covers the org requirements ORF-430, ORF-431, ORF-433, ORF-434, ORF-436, and ORF-437, and the app requirements MRF-397, MRF-398, MRF-402, MRF-403, and MRF-404.

Primary source

CBUAE, Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E., 23 February 2026. This page draws on Section 5 (Data Quality, Privacy and Security) — including its distinct fraud-detection clause — Section 6 (Continuous Monitoring and Review), the resilience and incident elements of Section 5, and the recordkeeping elements of Section 8, all anchored to CBUAE's Model Management Standards (MMS).

Key requirement families ​

Governance (OFF-21)Execution (MFF-21)FamilyUAE-exclusive control
ORF-430MRF-398Data quality, privacy, confidentiality, and securityOCF-347 (org), MCF-640 (app)
ORF-431MRF-397Model governance, validation, and the deployment boundaryOCF-348 (org), MCF-639 (app)
ORF-436MRF-402Recordkeeping, logging, and supervisory readinessOCF-353 (org)
ORF-433MRF-403Continuous monitoring, drift, and outcome reviewOCF-350 (org), MCF-641 (app)
ORF-434MRF-404Incident, harm, and remediation responseOCF-351 (org), MCF-642 (app)
ORF-437—Proactive AI for fraud and financial-crime detectionOCF-354 (org)

MRF-402 (logging) runs on shared logging and audit-trail controls (for example MCF-184/MCF-435) rather than a UAE-exclusive app control. ORF-437 is org-only — it has no per-use-case execution requirement.

Data governance and privacy ​

The framework does not try to become a full privacy regime, but Section 5 makes data handling a first-class AI duty. Data used in AI and ML should be accurate, relevant, and up-to-date, with clear provenance and audit trails, and processed lawfully and proportionately under the UAE Personal Data Protection Law (PDPL) and the Information Assurance Regulation, respecting in-country data-retention rules (with a cross-reference to outsourcing in Section 9). Privacy-by-design and security-by-design are expected.

ORF-430 governs this at the institution level: data-use expectations, privacy and confidentiality rules, security expectations for AI-related data handling, and escalation triggers where consumer data use materially changes. MRF-398 (MCF-640) is where a use case evidences it:

  • what data is used, and why;
  • how lineage and provenance are maintained;
  • which privacy, confidentiality, and residency safeguards apply;
  • the lawful basis for processing personal data.

Robustness and stress testing and operational resilience also originate in Section 5; the resilience elements are carried into incident and remediation response below.

Model governance and the deployment boundary ​

The org-side model-governance anchor ORF-431 — MMS-aligned validation, periodic review, and independent challenge — is covered in Scope and governance. Its app-side counterpart is MRF-397 (MCF-639), which draws the deployment boundary for a specific use case:

  • pre-deployment robustness, stress, and safety testing for the use case;
  • testing of automatic model updates for bias before implementation — updates are not trusted by default;
  • the use-case risk rating, scored on data quality and sensitivity, AI capability, controls, impact, and third-party dependence.

MRF-397 is about what the model may and may not do in production for this use case, and the evidence that it was validated against that boundary — not a restatement of general model policy. Together, ORF-431 and MRF-397 keep model governance from collapsing into generic policy language.

Logging and traceability ​

MRF-402 maintains the audit trails that let an AI-supported outcome be reconstructed after the fact:

  • data activity;
  • model activity;
  • decision-support activity.

This traceability layer is what makes monitoring, complaint handling, remediation, and supervisory readiness possible — a complaint about a specific decision can only be investigated if the inputs and model behaviour behind it were logged. ORF-436 (OCF-353) is the org-level companion: it keeps the evidence pack coherent and retrievable, ensures AI policies complement rather than duplicate existing regulatory obligations, treats AI consumer risk as conduct risk with board and regulator reporting, and maintains the records (inventory metadata, validation and monitoring documentation) needed for supervisory readiness. It carries the note's closing position that the institution retains full legal responsibility.

Monitoring and outcome review ​

Section 6 is explicit that governance does not end at approval. AI should be continuously monitored per MMS for reliability, relevance, and consumer-protection alignment, and the institution is expected to consistently review, update, or cease models as data, market, or behaviour change.

ORF-433 (OCF-350) governs this institution-wide, and carries several specific Section 6 duties: periodic independent third-party or expert challenge of AI use; testing automatic model updates for bias before implementation; mechanisms to detect, report, and remediate performance issues or unintended consequences; the retained human-triggered ability to cease use of any AI system; and horizon-scanning to keep systems current with legal, provider, and market developments.

MRF-403 (MCF-641) operationalises this for a use case:

  • live monitoring of the deployed system;
  • drift and performance signals;
  • fairness and consumer-outcome review against expectations;
  • action thresholds that fire when live behaviour becomes unacceptable.

MCF-641 — reviewing deployed AI outcomes against consumer-protection expectations — is the UAE-exclusive control that distinguishes this from generic model monitoring: the review is against consumer-protection alignment, not only technical reliability.

Incident, harm, and remediation ​

The CBUAE guidance is principles-based on incidents — it does not prescribe fixed reporting timelines the way NIS2 or DORA do. The duty is to recognise, escalate, and remediate, with a response proportionate to the nature of the issue.

ORF-434 (OCF-351) governs how the institution recognises, escalates, and remediates AI performance issues, bias, unintended consequences, and consumer harms, and requires operational resilience — redundancy, contingency planning, and incident response — against system failure and cyber-attack (the resilience obligation introduced in Section 5).

MRF-404 (MCF-642) focuses on the operational response for a use case: containment, suspension, fallback, cease-use, and remediation, chosen according to the nature of the issue. Rollback can be part of the response, but it is not the universal answer — a fairness regression, a data-quality fault, a cyber-attack, and a consumer-harm event call for different containment paths. The retained human-triggered cease-use ability (Sections 6 and 7) is the backstop available under all of them.

Proactive AI for fraud and financial-crime detection ​

Section 5 carries a distinct clause, separate from the resilience obligation, that points the other way — using AI to protect consumers and the system rather than only constraining it. LFIs should assess and, where feasible, use AI to detect potential fraud, criminal activity, AML disparities and issues, and suspicious activity through trends and patterns, and comply with legal and regulatory reporting duties on material findings.

ORF-437 (OCF-354) carries this as an org-level, assess-and-use-where-feasible duty. It is not conditional in the applicability sense — it applies broadly to in-scope institutions — but it is an assessment-and-adoption expectation rather than a prescriptive mandate to deploy a specific system. The institution documents:

  • its assessment of where AI could feasibly strengthen fraud and financial-crime detection;
  • its use of AI for detection where that is feasible;
  • how material findings feed its existing legal and regulatory reporting obligations.

There is no separate app requirement for ORF-437 — the framework treats the proactive-detection posture as an institution-level assessment rather than a per-use-case execution obligation.

How these families are scoped in Modulos ​

The data, model, monitoring, incident, and recordkeeping families apply to every in-scope consumer-affecting use, scaled by the use case's risk rating and consumer impact rather than switched on or off. ORF-437 applies broadly as an assessment duty. None of the families on this page is conditional in the way third-party AI and consumer redress are; scoping is not tag-driven and carries no separate questionnaire. The risk rating set under MRF-397 calibrates how much monitoring depth, testing frequency, and incident readiness a given use case attracts.

Cross-framework mapping (preview) ​

Preview

The data, model, monitoring, and incident duties sit adjacent to frameworks UAE LFIs commonly run, at a high level only:

  • GDPR / UAE PDPL — data-quality, provenance, and lawful-processing duties reuse the data-protection control estate.
  • ISO/IEC 42001:2023 — model validation, monitoring, and incident response correspond to the AIMS operational-control and performance-evaluation clauses.
  • EU AI Act — logging, monitoring, and post-market duties overlap at the control level, not the article level.

These are framework-level adjacencies; cross-framework reuse is realised at the control layer, not as clause-by-clause equivalence.

Scope and governance

The MMS model-governance anchor and the inventory/risk-rating process — ORF-431, ORF-425

Fairness, transparency, and oversight

Where fairness testing meets monitoring and outcome review — MRF-399 / MRF-403

Consumer redress and third-party AI

Third-party assurance and the consumer-facing side of incidents and complaints

Operationalizing in Modulos

The rollout sequence and evidence model across OFF-21 and MFF-21

Source attribution ​

The authoritative source is the CBUAE Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E., published 23 February 2026 by the Central Bank of the United Arab Emirates. This page draws on Section 5 (Data Quality, Privacy and Security), Section 6 (Continuous Monitoring and Review), and the recordkeeping elements of Section 8, anchored to CBUAE's Model Management Standards (MMS), the UAE Personal Data Protection Law (PDPL), and the Information Assurance Regulation. Requirement and control codes are Modulos template identifiers, not CBUAE references.

Disclaimer

This page is for general informational purposes and does not constitute legal advice. The CBUAE guidance note supplements — it does not replace — applicable UAE law and CBUAE directives; the institution remains fully responsible for its own compliance. Verify against the current published edition and consult qualified advisers.