Skip to content

Consumer Redress and Third-Party AI

The obligations on this page differ from the rest of the framework in one respect: they are conditional. They apply where the institution or the use case meets a specific condition — a material external AI dependency, or a use that materially affects consumers. This page covers third-party and outsourced AI governance and assurance (ORF-432 / MRF-405), consumer human review, complaints, redress, and communication support (ORF-435 / MRF-406), and how Modulos records applicability without a dedicated scoping questionnaire.

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 9 (Outsourcing and Third-Party Risk) — anchored to MMS 4.7 and the Outsourcing Regulation for Banks — and the consumer-redress elements of Section 7 (Human Oversight and Consumer Protection), which align complaints and redress to Article 8 of the Consumer Protection Regulation.

The conditional families

RequirementLayerApplies whenUAE-exclusive control
ORF-432OrganisationThe institution relies on material external or outsourced AI/ML dependenciesOCF-349
ORF-435OrganisationAI materially affects consumer outcomes, treatment, or disputesOCF-352
MRF-405AI applicationThe use case materially depends on an external AI service, model, or processing arrangementMCF-637
MRF-406AI applicationThe use case materially affects consumer interactions or outcomes and needs notices, rationale, or challenge routesMCF-638

These are genuine conditional duties, not optional extras. Where the condition is met, the requirement is in scope and its controls must be executed; where it is not, the requirement is marked out of scope with recorded rationale.

Third-party AI governance and assurance

Section 9 addresses the common case where an LFI relies on third-party or cloud AI providers. The framework splits the duty across two layers because external AI risk is not only a procurement matter — it reaches consumer treatment, data handling, explainability, fallback options, and ongoing operational assurance.

ORF-432 (OCF-349) governs the dependency at the institution level, carrying Section 9's specific demands:

  • due diligence on provider reputation, governance, security, and data protection, per MMS 4.7 and the Outsourcing Regulation for Banks;
  • contractual audit and information rights and provisions securing CBUAE compliance;
  • documented procurement and selection, including annual independent cybersecurity reviews and pre-deployment testing;
  • inventory reach — third-party-hosted models included in the AI/ML inventory and held to the same fairness, explainability, and robustness standard as in-house models;
  • avoiding over-reliance on a single provider, with multiple providers considered where appropriate.

MRF-405 (MCF-637) is the per-use-case assurance side: where a specific use case materially depends on an external AI service, the team evidences provider due diligence for that dependency, the documented procurement justification, the contractual audit and information rights in force, the dependency's inclusion in the inventory at in-house parity, and the retained institutional accountability. The note is explicit that accountability is retained — outsourcing the capability does not outsource responsibility for consumer outcomes.

Consumer human review, complaints, and redress

ORF-435 (OCF-352) carries the consumer-rights core of Section 7. Where AI materially affects consumer outcomes, treatment, or disputes:

  • consumers should be able to request human review or an explanation of an AI decision;
  • an alternative arrangement should be available where a consumer does not want an AI decision;
  • the institution should maintain complaints and redress channels that align with Article 8 of the Consumer Protection Regulation and are efficient, confidential, and accessible;
  • consumers have the right to challenge decisions and correct inaccurate data inputs behind them.

This is more than logging complaints. The requirement is about whether the institution can recognise AI-affected complaints, escalate them properly, link them to governance and remediation, and support redress where it is due. It commonly bites on eligibility and treatment decisions, pricing or profiling impacts, fraud handling, dispute handling, and complaint-routing logic.

Consumer communication support

MRF-406 (MCF-638) is the consumer-facing communication surface, and it is deliberately distinct from the internal explainability artefacts held under MRF-400 (see Fairness, transparency, and oversight). It covers, where the use case materially affects consumers:

  • bilingual, plain-language disclosures (Arabic and English), with understandability checked;
  • consideration of opt-out for high-impact decisions;
  • human-review, complaint, and challenge routes, and handoff to human review or complaint pathways;
  • compliance with fair-treatment and anti-pressure-selling disclosure rules, including for chatbots and promotional materials.

An internal model-explanation record does not satisfy this standard; the consumer-facing notice has its own bar. That is why consumer communication support (MRF-406) and internal explainability (MRF-400) are separate requirements.

How applicability is recorded in Modulos

Because there is no dedicated UAE Consumer AI questionnaire and no framework-specific scope tag, the conditional families are handled through an explicit, reviewable pattern:

  1. Read the Applicability section in the requirement text (ORF-432, ORF-435, MRF-405, MRF-406 each carry one).
  2. Decide whether the use case or institution meets the condition — a material external AI dependency, or a material consumer effect.
  3. Record the scoping decision and its supporting rationale on the requirement (in scope or out of scope).
  4. If in scope, execute the mapped controls and evidence them normally.

This keeps the decision explicit and auditable without implying an automated descoping engine that does not exist. A requirement marked out of scope carries its rationale in the requirement's comments and logs, the same way an in-scope requirement carries its fulfilment rationale.

Cross-framework mapping (preview)

Preview

The third-party and consumer-redress duties sit adjacent to frameworks UAE LFIs commonly run, at a high level only:

  • ISO/IEC 42001:2023 and ISO/IEC 27001 — third-party AI due diligence, audit rights, and inventory parity correspond to the supplier-governance and outsourcing controls.
  • EU AI Act — deployer duties over third-party systems and consumer human-review expectations overlap at the control level.
  • MAS FEAT — comparable consumer-fairness and accountability intent, including for outsourced AI.

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

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 9 (Outsourcing and Third-Party Risk), anchored to MMS 4.7 and the Outsourcing Regulation for Banks, and the consumer-redress elements of Section 7, aligned to Article 8 of the Consumer Protection 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.