Model Risk Governance in Practice: What SR 11-7 and OCC 2011-12 Actually Require

When the Federal Reserve issued SR 11-7 and the OCC published its companion guidance in 2011, the regulatory framework for model risk management became unambiguous in its expectations. Models are assets that carry risk. That risk must be managed through a structured lifecycle of development, validation, implementation, and ongoing monitoring. Boards and senior management are accountable for ensuring this happens.

Fourteen years later, the gap between regulatory intent and institutional practice remains wide. Not because banks disagree with the principles, but because operationalising them at scale — across hundreds or thousands of models, with limited MRM staff, using tools that were never designed for the task — is genuinely difficult.

The institutions that have closed this gap share a common trait: they treat model governance not as a compliance exercise but as an operational system, with the same engineering discipline they apply to their core banking platforms.

The Inventory Problem

Every model governance programme begins with the model inventory. SR 11-7 is explicit: institutions must maintain a comprehensive inventory of models in use, under development, and recently retired. The inventory should capture model purpose, methodology, data inputs, outputs, ownership, validation status, and risk tier.

In practice, model inventories are often the weakest link. Many institutions maintain them in spreadsheets or SharePoint lists that are perpetually outdated. New models enter production without being registered. Retired models linger in the inventory because nobody updates the status. Metadata is inconsistent — one model's documentation calls it a "credit scoring model" while another labels a functionally identical model as a "risk rating tool."

The inventory is not administrative overhead. It is the foundation on which every other governance activity depends. Without an accurate, current inventory, an institution cannot answer basic questions: How many models do we have? Which are overdue for validation? Which have known issues? Which are most material to our risk profile?

A functional model inventory requires three things: a structured schema that enforces consistent metadata, integration with model development and deployment workflows so that registration happens as part of the development process rather than after the fact, and clear ownership assignment with accountability for keeping records current.

Tiering and Materiality

Not all models warrant the same level of governance. SR 11-7 recognises this implicitly, and most institutions implement a tiering framework that assigns models to risk categories based on materiality, complexity, and regulatory sensitivity. High-tier models — those used in capital calculations, CECL, or credit decisioning — receive more intensive validation and monitoring. Lower-tier models may follow a lighter framework.

The challenge is that tiering decisions are often made once and never revisited. A model that was Tier 3 when it covered a small portfolio may become Tier 1 as the portfolio grows, but the governance treatment does not automatically adjust. Similarly, models that interact — where the output of one feeds the input of another — may be individually low-tier but systemically important as a chain.

Effective tiering requires periodic reassessment and should account for model interconnections, not just individual model characteristics. This is difficult to manage manually but straightforward to systematise in a governance platform that tracks model relationships and portfolio exposure.

Validation: The Bottleneck

Model validation is where most MRM programmes face their most acute capacity constraint. SR 11-7 requires independent validation that evaluates conceptual soundness, ongoing monitoring results, and outcomes analysis. For quantitative models, this means replicating or benchmarking model performance, stress-testing assumptions, and assessing limitations.

The typical bank has far more models than its validation team can cover in any given cycle. The result is a backlog — models overdue for validation, findings that remain open for quarters, and a persistent sense that the programme is running behind. Regulatory examiners notice.

Three structural issues drive the bottleneck. First, validation is labour-intensive because it starts from scratch each time — validators spend significant effort simply understanding what the model does, how it was built, and what data it uses before they can assess its soundness. Second, validation findings are tracked informally, making it difficult to assess whether issues have been remediated. Third, there is no systematic way to prioritise which validations matter most beyond the tier assignment.

Reducing the bottleneck requires better model documentation at the development stage — not as an afterthought, but as a structured artefact that validators can consume efficiently. It also requires systematic findings management with clear ownership, deadlines, and escalation paths.

Ongoing Monitoring: From Quarterly Reports to Continuous Surveillance

SR 11-7 requires ongoing monitoring to confirm that models continue to perform as expected. In practice, this has traditionally meant quarterly performance reports that compare model predictions against outcomes — KS statistics, Gini coefficients, accuracy ratios, population stability indices.

Quarterly monitoring was adequate when portfolios evolved slowly and models were recalibrated annually. It is inadequate in an environment where economic conditions can shift rapidly, data distributions change with customer behaviour, and new model deployments happen monthly rather than annually.

The shift toward continuous monitoring does not mean watching dashboards in real time. It means establishing automated monitoring pipelines that evaluate model performance, data quality, and prediction stability at appropriate frequencies — daily, weekly, or monthly depending on the model's materiality and the volatility of its operating environment. When monitoring metrics breach predefined thresholds, alerts should trigger review workflows, not just email notifications.

This requires infrastructure. Performance metrics must be computed against current data, which means monitoring systems need access to both model predictions and actual outcomes. For credit models, outcome data may lag by months, which means monitoring must also include leading indicators — input data stability, score distribution shifts, override rates — that can signal problems before outcome data confirms them.

Documentation: The Perennial Weakness

Model documentation is universally acknowledged as important and universally executed poorly. SR 11-7 expects documentation that enables a knowledgeable third party to understand the model's purpose, methodology, assumptions, limitations, and performance. In practice, documentation ranges from comprehensive technical papers to sparse PowerPoint decks that omit critical details.

The root cause is structural: documentation is treated as a deliverable that is produced once at model development and updated reluctantly thereafter. It is disconnected from the model itself — the code may change while the documentation remains static.

Better documentation requires tighter integration between the development process and the documentation process. When a model's features, training data, or parameters change, the documentation should update accordingly. This does not require fully automated documentation — expert judgment in describing methodology and limitations remains essential — but the factual elements (data sources, performance metrics, feature lists, validation history) should be maintained programmatically.

Operationalising Governance

The common thread across inventory management, tiering, validation, monitoring, and documentation is that these are operational processes, not one-time compliance exercises. They require workflow management, role-based access, audit trails, and integration with the model development and deployment lifecycle.

Most institutions have attempted to manage these processes with generic tools — ticketing systems, shared drives, spreadsheets, and email. The result is governance programmes that are functional but fragile, dependent on individual knowledge, and difficult to scale.

Purpose-built model governance platforms address this by providing the structured workflows, automated monitoring, and centralised evidence repositories that SR 11-7 envisions. StratLytics' SLERA platform exemplifies this approach — it was designed from the ground up for regulated financial institutions, with model inventory management, validation workflow orchestration, continuous monitoring, findings tracking, and audit-ready evidence generation built into a single integrated system.

The institutions that treat model governance as a first-class operational capability — not a cost centre, but a source of competitive advantage through faster, safer model deployment — are the ones that satisfy both their regulators and their business stakeholders. The tooling they choose is a critical enabler of that outcome.