If Your Risk Model Left Today, Would Your Data Still Work?
Banks have gotten serious about model risk management. SR 11-7 gave them no choice. Model validation is now a mature discipline. Model inventory is a standard practice. Model risk committees meet regularly and challenge assumptions.
But here's the gap that most model risk programs don't cover: the data flowing into and out of those models.
A perfectly validated model fed by unmaintained data is a ticking finding. The model's outputs will be wrong in ways the validation didn't test for, because validation tests the model, not the data pipeline that feeds it. When examiners cite model risk deficiencies, they increasingly point to data governance failures: stale inputs, undocumented transformations, and missing lineage between source data and model features.
Why It Matters
For Tier 2 banks, this is an acute risk. You're adopting more models, such as AI/ML models for credit decisioning, fraud detection, and stress testing, while your data governance infrastructure hasn't kept pace. The model is new. The data feeding it is managed by processes designed for a different era.
The disconnect is structural. Model risk teams own the model. Data governance teams own the data. The handoff between them is often a shared drive, an informal briefing, or nothing at all. When the data changes and nobody tells the model team, model drift happens silently.
The Wrong Approach
The instinct is often to extend model validation to cover data quality. Add a data quality section to the validation report. Include a data sourcing appendix in the model documentation.
This is checkbox compliance. Validation happens periodically, such as annually for less critical models or more often for high-impact ones. Data quality degrades continuously. A data quality check at validation time doesn't protect the model between validations.
Another mistake: putting data governance in charge of model data without connecting it to model risk governance. Two separate governance frameworks, two separate reporting lines, two separate views of the same risk.
The Right Approach
Treat model data as a first-class governance concern with its own certification framework.
First, extend critical data element definitions to include model inputs. Every feature that feeds a regulatory or high-impact model should be a critical data element with assigned ownership, quality thresholds, and certification requirements.
Second, require data certification as part of model approval. Not "data looks fine" — certified. The data owner attests to quality. The certification captures lineage from source to model feature. The evidence is auditable.
Third, integrate data governance monitoring into model monitoring. If a model's performance degrades, the first question should be: "Did the data change?" That question can't be answered without real-time governance visibility.
The CoComply Angle
CoComply doesn't validate models; it certifies the data foundation they stand on. When a model's input data is certified, you know exactly who owns it, where it came from, and whether it meets the quality standard the model was built on. When something changes, and it always does, the certification record shows you what shifted and when.
This turns model risk from "we think the data is fine" into "we can prove it." That distinction matters during model validation reviews, regulatory examinations, and when the model's output surprises you.
The Test
Pick your highest-impact model. Ask the model owner: "Can you show me the complete data lineage for every input feature, with certified quality status, right now?" If they point you to a spreadsheet that someone updated last quarter, you have a model risk problem disguised as a data problem. Certify the foundation. Then trust the model.