Risk models, regardless of how sophisticated their methodology, are bounded by the quality of the data they consume. This is not an observation that needs defending. What does need attention is the gap between accepting the observation in principle and treating data quality as a first-class governance discipline in practice.
The CBUAE Model Management Standards close that gap by codifying what data quality means in operational terms. The standard does not allow institutions to treat data quality as an aspiration or as a category that gets addressed when convenient. It specifies six dimensions along which data must be assessed, requires the function responsible for that assessment to be separated from broader operational risk data management, and treats deficiencies in data lineage as material findings in the same register as deficiencies in model methodology.
For institutions that have built their data governance around operational risk reporting requirements — which is most institutions — the MMS data provisions represent a structural shift, not an incremental adjustment.
The six dimensions, defined
Each dimension is operationally distinct, and each is independently testable.
Accuracy failures often arise from manual entry points and from data transformations that lose precision. A borrower’s reported income, the collateral valuation, the obligor classification — each can be tested through reconciliation to source systems, sample-based verification against external evidence, and pattern testing against expected distributions.
Completeness failures most commonly arise at the interface between systems — data that exists in the originating system but is not consistently captured in the model input layer. A portfolio of 10,000 obligors should have certain fields populated for each; the percentage of records with missing critical fields is the measure.
Consistency failures often arise from systems that have evolved separately, with reconciliation occurring through manual processes that are themselves a source of error. A borrower’s industry classification should be the same in the loan origination system, the risk reporting system, and the model input file.
Timeliness failures arise from batch processing delays, from systems that update on different cadences, and from data that is technically current but stale in substance. For IFRS 9 models, the data should reflect the position as at the reporting date. For real-time decisioning models, the data should reflect the position as at decision time.
Uniqueness failures most commonly arise in environments where the same underlying entity is captured in multiple systems with no enforced golden-source identifier. A single borrower should not appear as two records. A single collateral asset should not be counted against two exposures.
Validity failures are usually the easiest to detect with automated testing, and are often the most quickly addressable. A loan amount should be positive. An interest rate should fall within a defensible range. A property type should be drawn from a defined list.
The institutions whose data quality work most credibly addresses MMS requirements treat these six dimensions as a tested matrix — each dimension assessed for each material data element, with the results reported at a frequency that allows movement over time to be visible.
Why the data management function must be separate
Article 5.1.1 of the MMS requires that the data management function for models be functionally separated from operational risk data. The requirement is structural, and it has prompted significant organisational rework at institutions whose data governance was previously consolidated under a single umbrella.
The supervisory intent behind the separation is consistent with the broader independence principle that runs through the standard. Operational risk data serves a different purpose than model input data. Operational risk data is collected primarily for incident reporting, loss event capture, and Pillar 1 operational risk capital. Model input data is collected to drive PD, LGD, EAD, capital projections, and stress testing outputs. The data quality dimensions that matter most differ between the two — operational risk reporting can tolerate a degree of lag and approximation that model input cannot — and the people optimising for one set of trade-offs are not best placed to optimise for the other.
In practice, the separation typically takes one of two forms. Some institutions have established a dedicated data management function within the model risk management team, reporting through the CRO and structurally distinct from the operational risk data function. Others have retained a centralised data office but established a specific stream within it responsible for model input data, with separate governance, separate quality metrics, and separate reporting to the Model Oversight Committee.
What does not work, in our observation, is treating the requirement as a labelling exercise — describing an unchanged function as “separate” without changing how it operates. The supervisor reviewing the institution can identify the substance of separation by examining whether the data function for models has its own quality metrics, its own escalation paths, and its own representation in model governance forums.
Data lineage — the operational test
Beyond the six dimensions and the structural separation, the third area where the MMS sets explicit expectations is data lineage. Article 5 requires that institutions be able to trace each material data element used in a model back to its source system, through all the transformations applied to it, with the controls at each transformation point documented and tested.
In practice, this is the area where most institutions have the largest implementation gap. The data feeding a typical IFRS 9 model has passed through multiple systems — a core banking system, a risk data warehouse, an aggregation layer, a model input file — with transformations occurring at each stage. The institution can usually describe each stage in isolation. What is harder is presenting the lineage as a single traceable chain, with controls at each transformation point documented in a form that an independent reviewer could verify.
The operational test the supervisor applies is straightforward. Take a specific exposure in the institution’s portfolio. Trace its PD assignment back through the model to the input data. Trace the input data back through the data warehouse to the source system. Identify which transformations occurred between source and model input, what controls applied at each transformation, and when those controls were last tested. An institution that can perform this trace for a randomly selected exposure has data lineage. An institution that requires several days of investigation to perform the same trace does not.
Where the gap usually sits
These gaps are addressable. The institutions that have addressed them effectively have tended to begin with the data lineage exercise — tracing the chain from source to model input for a small set of critical inputs first, then expanding the coverage. The lineage work tends to surface the dimensional issues automatically. An accuracy problem at a specific transformation point is more visible when the transformation chain itself is documented. A consistency problem between two systems is more visible when both systems appear in the lineage.
The standard’s intent is that data quality be treated as a model risk topic rather than as a separate IT topic. The institutions that have made the most progress are those whose data quality work is led by people who understand both the models and the systems, with governance running through the Model Oversight Committee rather than through general IT or data committees.
A closing observation
The data quality provisions of the MMS are not, in themselves, novel. The six dimensions are recognisable from data management literature that predates the standard. What is distinctive about how the MMS applies them is the level at which the supervisor expects to see them operationalised — not as a target state but as a continuously functioning discipline visible to anyone reviewing the institution’s framework.
In recent engagements supporting data readiness work for institutions across the GCC, we have consistently observed that the technical solutions to the six dimensions are well understood. What requires more sustained attention is the governance model — who owns data quality for models, who they report to, how the cadence of monitoring is set, and how findings translate into remediation. That governance is what the supervisor examines, and that governance is where the implementation work usually sits.