Model risk management as a continuous discipline — beyond the validation cycle

A model validation event is not a model risk management framework. The distinction matters because the two are frequently conflated, and the conflation tends to produce an institution that passes periodic validation reviews while maintaining meaningful model risk exposure in the intervals between them.

The event-based view of model validation — build, validate, deploy, validate annually — was never the full intent of sound model risk management. The Federal Reserve’s SR 11-7 guidance, which established many of the principles that national regulators including the CBUAE have adapted, frames model risk management as a continuous lifecycle discipline. The CBUAE Model Management Standards take the same approach, requiring that model risk be integrated into the enterprise risk management framework and managed through ongoing governance rather than periodic review.

The practical implication is that a model operating between validation cycles is not operating outside the governance framework. It is operating within a monitoring regime that should detect degradation, flag it through defined escalation channels, and trigger action — recalibration, restriction, or revalidation — proportionate to the observed deterioration. Where that monitoring regime does not exist, the institution has a validation programme and not an MRM framework.

What the CBUAE MMS requires for the lifecycle

The CBUAE MMS addresses the lifecycle requirements across several articles. The two that anchor the framework architecture are Article 3.7.7 (integration of model risk into ERM) and Article 4.6.5 (Model Oversight Committee composition and independence).

Article 3.7.7 establishes that model risk is a risk category — like credit risk, market risk, and operational risk — that requires board-level visibility and a governance structure proportionate to the institution’s model risk exposure. An MRM function that operates within the risk management department without board reporting, or that reports only to the CRO without specific model risk metrics in the risk appetite framework, does not meet this standard.

Article 4.6.5 requires that the Model Oversight Committee be composed to ensure independence from both model development and the business lines using models. This mirrors the independence requirement that applies to other control functions — the validation function must not validate models it developed, and must not report to the same governance structure as the business lines whose decisions depend on model outputs. In smaller institutions, achieving full organisational independence may require that external validators be used for some model categories, or that validation authority be formally delegated to a committee with independent members.

Model tiering — the governance that makes sustainability possible

Without tiering, institutions apply the same governance intensity to a simple pricing tool and to the IFRS 9 ECL engine — and exhaust their governance capacity on the former while under-governing the latter.

The CBUAE MMS requires that models be tiered by materiality and risk, with governance intensity calibrated to the tier. The tiering determination considers the model’s role in material financial decisions, the volume and value of transactions or exposures it drives, the consequences of model failure, and the complexity and opacity of the model structure.

In practice, most institutions operating under the MMS maintain three tiers. Tier 1 comprises models that are material to regulatory capital, IFRS 9 provisioning, or systemic risk decisions — ICAAP models, ECL engines, stress testing models, and the institution’s primary credit scoring models. These receive full independent validation on a defined cycle, with continuous monitoring between cycles, board-level risk appetite metrics, and formal approval from the MOC for any material change. Tier 2 comprises models that influence individual business decisions without reaching the same systemic materiality threshold — pricing models, collateral valuation tools, portfolio analytics. These receive lighter validation documentation, MOC approval, and defined monitoring. Tier 3 comprises tools that inform management analysis without driving binding decisions — dashboards, reporting aggregators, sensitivity tools. These are inventoried and subject to a light documentation standard, but not to formal validation cycles.

The tiering decision is not a one-time exercise. Models migrate between tiers as their use evolves. A portfolio analytics tool that begins as a Tier 3 management dashboard and is gradually embedded in credit committee reporting until it is de facto driving credit decisions has, in practice, become a Tier 1 model — and should be governed accordingly. Tracking this migration requires an active model inventory with use-case documentation that is reviewed at defined intervals, not a static register compiled once and amended only when someone remembers to update it.

The continuous monitoring requirement

Between validation cycles, every model operating in a material decision-making context should be subject to ongoing performance monitoring. The specific metrics depend on the model type, but the monitoring programme should be designed to detect the conditions under which revalidation or intervention would be required.

For credit scoring models, continuous monitoring typically covers discriminatory power stability (Gini trending), calibration stability (predicted versus observed default rates by scoring band), and input feature stability (Population Stability Index on key features). For IFRS 9 ECL models, it covers backtesting of PD, LGD, and EAD predictions against realised outcomes, and the stability of macroeconomic overlays. For stress testing models, it covers the plausibility of scenario calibrations relative to current conditions.

The monitoring programme should produce defined thresholds — amber and red — that trigger specific governance responses. An amber threshold on discriminatory power stability triggers enhanced monitoring and a documentation note. A red threshold triggers an expedited review and potential restriction of the model’s use until the revalidation is complete. The thresholds and responses should be documented in the model’s governance record and approved by the MOC — not determined ad hoc when deterioration is first observed.

The model inventory as a living document

The CBUAE MMS requires that all models used in material decisions be inventoried, with documentation covering development evidence, validation history, use-case specification, and ownership assignment. The model inventory is the foundation of the MRM framework — without it, the governance structure has no objects to govern.

In practice, the model inventory at most institutions is incomplete and partially stale. New models are sometimes deployed before the inventory is updated. Legacy tools — spreadsheet calculators, older statistical models, vendor tools embedded in core systems — may not be inventoried at all. The ownership assignment may be nominal rather than functional: a name is assigned but the assigned owner does not know the model’s documentation requirements or the escalation path for model issues.

The supervisory standard is a living inventory — one that is updated in real time as models are developed, deployed, changed, or decommissioned, and that contains sufficient information for the MOC and the validation function to exercise their oversight roles without seeking additional information from the model developers or users. Meeting that standard requires not only a governance policy requiring inventory updates, but an operational process that makes it natural for developers and users to interact with the inventory as part of their routine workflow.

The institutions that have invested in the operational process — rather than simply the governance policy — tend to find that their model inventories are materially more complete and accurate, and that their supervisory dialogue on MRM infrastructure covers the framework’s performance rather than its completeness.

For a detailed treatment of MRM ecosystem design — including tiering frameworks, MOC terms of reference, continuous monitoring threshold design, and inventory architecture — see our white paper in the Library.