CBUAE Model Management Standards — the structural shifts that get under-appreciated

The CBUAE Model Management Standards, published on 21 December 2022 and effective immediately upon publication, established a comprehensive framework for how banks operating in the UAE must govern quantitative models. The gap assessment required under Article 2.2.2 was due within six months of the effective date — meaning most institutions in scope have now spent more than two years working through what compliance actually requires.

Most of the requirements in the standard are tractable for an institution that approaches them with serious intent. Documentation can be improved. Validation cycles can be established. Performance monitoring can be built. These are substantial pieces of work, but they are recognisable pieces of work — the kind that fit within the conventional toolkit of a risk function.

The parts of the standard that have proven harder, in our observation across multiple engagements, are not the ones that get the most attention in compliance discussions. They are a small number of structural shifts that affect how the institution organises itself, not just what documentation it produces. These are the shifts that have separated the institutions whose MMS implementation has held up under supervisory dialogue from those whose implementation has needed material rework.

Who the standard applies to, and what it covers

The starting point worth being precise about is scope. Article 2.1.2 of the MMS specifies that the standard applies to all banks operating in the UAE, irrespective of size. There is no de minimis threshold. A small bank with a focused portfolio is in scope, just as a tier-1 commercial bank is in scope, with the substantive expectation that the framework be proportionate to the institution’s model footprint rather than waived where the footprint is small.

The standard’s model definition is broad. Article 3 sets out the seven components of the framework — governance, data, development, implementation, usage, monitoring, and validation — and each component applies across the full set of models the institution uses. This includes IFRS 9 ECL models, ICAAP capital projection models, stress testing models, AML transaction monitoring models, credit decisioning models, market risk models, and increasingly the AI and machine learning models being deployed across digital channels. The framework treats them as a single population requiring consistent governance, even where the underlying methodologies differ substantially.

Within that population, Article 4.4.5(ii) sets a Tier 1 minimum: institutions are required to have, at a minimum, IFRS 9 models for material portfolios and capital forecasting models in the Tier 1 category. The tiering itself is the institution’s responsibility to maintain, with the supervisor’s interest being in whether the tiering decisions are defensible against the materiality of the model’s outputs.

The structural shifts that prove harder than they look

Three structural elements of the standard tend to require more organisational change than the documentation work, and they are the ones where most of the meaningful implementation effort ends up.

The first is the Model Oversight Committee. Article 4.6.3 requires that institutions establish a Model Oversight Committee with explicit responsibilities for the model risk framework, meeting at least quarterly.

An existing risk committee whose membership reflects business-line representation cannot, by composition, satisfy the MOC requirement. The institution must either restructure the committee, create a sub-committee with the required composition, or stand up a new committee.

Each of these has organisational implications that take time to work through.

The second is the Data Management Function. Article 5.1.1 requires that the data management function for models be functionally separated from operational risk data. The institution that treats model data as a sub-function of operational data — a common enterprise architecture — has to restructure the responsibility allocation. The data lineage, quality controls, and dimensional ownership for model inputs has to be visibly distinct from the broader data governance framework, with explicit ownership at a level that the supervisor can identify in the institution’s organisational chart.

The third is third-party provider governance. Article 4.7 through Article 4.7.5 sets out detailed requirements for institutions that use external vendors for model development, validation, or maintenance. The requirements include explicit knowledge transfer to internal staff, demonstrable internal capacity to challenge the third-party outputs, and the avoidance of structural dependency on a single provider. This is the article that most directly addresses the lock-in concern that institutions have raised about vendor-led implementations. The standard does not prohibit using external providers — it requires that the institution remain the substantive owner of the models even when external providers are part of the operating model.

Three foundational requirements that anchor everything else

Beyond the seven structural components, the standard introduces three foundational requirements that cut across the framework.

The first is the integration of model risk into the broader risk framework. Article 3.1.3 requires that model risk be treated as a distinct risk category, with appetite, limits, and reporting integrated into the institution’s existing enterprise risk framework. The model risk number — usually expressed as a capital add-on under Pillar 2 — should appear in ICAAP, in risk appetite reporting, and in board-level risk dashboards. This integration is the test of whether the institution treats model risk as a real risk or as a compliance category.

The second is the requirement for both quantitative and qualitative validation. Article 3.7.7 is explicit that validation must include both dimensions. The quantitative component is what most institutions focus on — backtesting, sensitivity analysis, benchmark comparison. The qualitative component is conceptual review, examination of methodology choices, and assessment of whether the model remains appropriate for the portfolio. The qualitative component is the one most often under-developed in practice, and it is the one most likely to surface the issues that pure statistical validation does not detect.

The third is the documentation minimum. Article 4.9.3 sets out nine items that any in-scope model’s documentation must cover: model purpose, methodology, assumptions, limitations, data lineage, validation results, performance monitoring, model uses, and dependencies. The list is not exotic. Every institution’s documentation can be mapped against it. The exercise of doing that mapping reliably surfaces gaps — items that are documented for some models but not consistently for others, items that exist in fragmentary form across multiple documents, items that depend on the institutional memory of specific individuals rather than on a written record.

Where the largest gap usually sits

The single area where MMS implementation most often falls short of the standard, in our experience across multiple gap assessments, is not in any of the structural components above. It is in the institution’s ability to demonstrate continuous compliance rather than point-in-time compliance.

An institution can complete a gap assessment in 2023, run a remediation programme, and arrive at a state of substantial alignment with the standard. That state is not the supervisory expectation. The expectation is that the institution’s governance, validation, monitoring, and documentation continue to operate at the standard’s level on an ongoing basis, with evidence retrievable at any point that the framework continues to function. The difference between a one-off remediation and an embedded framework is the difference that thematic reviews increasingly examine.

The institutions that have built embedded MMS frameworks tend to have done three things. They have placed ownership of the framework with a named function — usually a model risk management or model governance team reporting to the CRO. They have integrated MMS-required outputs into the regular cadence of the risk function, rather than treating them as a separate compliance workstream. And they have invested in the qualitative validation capability that the standard requires but does not provide a template for.

A closing observation

The MMS is, in our experience, a thoughtfully constructed standard. The requirements are coherent, the structure is consistent with international model risk governance frameworks such as SR 11-7, and the supervisory direction of travel — toward genuine institutional ownership of models rather than external dependency — is one that aligns with what most CROs and risk committees already say they want.

The implementation work is real. The structural shifts around governance separation, data function ownership, and third-party dependency are the ones that take longest. For institutions still working through these — and many are, even with the gap assessment more than two years behind them — the question worth asking is whether the framework is operating as a continuous discipline or as a periodic exercise. The first survives supervisory dialogue. The second has tended not to.

For institutions that want a deeper treatment of the standard, including the specific provisions of Articles 4.6 through 4.9 and the practical implementation patterns we have observed across recent engagements, our white paper on CBUAE MMS implementation is available in the Library.