Model Risk Management Platform Design: From SR 11-7 to SR 26-2
Building the Platform That Runs Model Governance, Not Just Records It
Most model risk platforms are document repositories with a workflow bolted on. They hold validation reports, track approval dates, and produce a quarterly inventory count for the risk committee. What they cannot do is tell you which models are currently outside their performance thresholds, which models feed which other models, or whether the thing the front office deployed last month is in the inventory at all.
That gap matters more now, because the guidance underneath these platforms just changed. A model risk management platform SR 11-7 governance shaped for fifteen years now has to operate under revised guidance, alongside a growing population of AI systems that the revised guidance deliberately does not cover.
Where does SR 11-7 stand now?
Superseded. SR 26-2 replaced it on 17 April 2026, with an OCC companion bulletin issued the same day.
The Federal Reserve issued SR 26-2, Revised Guidance on Model Risk Management, on 17 April 2026, replacing SR 11-7 from 2011 and SR 21-8 from 2021, emphasising a risk-based approach tailored to the institution's model risk profile, and applying primarily to organisations above thirty billion dollars in assets. OCC Bulletin 2026-13 of the same date rescinds the Model Risk Management booklet from the Comptroller's Handbook, OCC 1997-24 on credit scoring models, OCC 2011-12 on sound practices for model risk management, and OCC 2021-19 on model risk in anti-money laundering systems.
What changed, and what did not?
The framing became explicitly risk-based and proportionate, and the underlying disciplines did not change.
Development, validation, monitoring, and governance remain the four pillars, and the practices your institution built against SR 11-7 are not invalidated. What changed is the emphasis: practices should fit the organisation's circumstances rather than following one pattern, and the OCC bulletin notes that non-compliance with the guidance will not result in supervisory criticism. That is a meaningful shift in tone, and it should not be read as permission to relax, since the underlying prudential expectations about sound risk management are unchanged and internal audit will still hold you to your own policy.
Why does your internal policy still look like SR 11-7?
Because policies are written once and referenced for years.
Almost every large institution's model risk policy paraphrases SR 11-7, including its tiering language and validation expectations, and those documents do not update themselves. The practical task is a policy refresh that references current guidance, keeps the disciplines that were working, and adds an explicit position on AI systems, which is the part the revised guidance leaves to you. Treat that refresh as a platform requirement too, since the platform enforces whatever the policy says.
Does your model risk policy still cite guidance superseded in April 2026?
Talk to Digiqt about a model risk platform and policy review
What does the platform have to do?
Hold a true inventory, run the lifecycle, capture evidence, wire in monitoring, and report honestly.
| Capability | What it means in practice |
|---|---|
| Model inventory | Every model with owner, tier, purpose, status, and dependencies |
| Lifecycle workflow | Development, approval, deployment, change, retirement, with gates |
| Documentation and evidence | Development records, validation reports, approvals, attestations |
| Validation management | Scheduling by tier, independence tracking, finding capture |
| Ongoing monitoring | Thresholds, automated metric feeds, breach workflow |
| Findings and remediation | Owners, dates, severity, closure evidence, ageing |
| Change control | Version history linked to approvals and to production deployments |
| Reporting | Committee packs, regulatory responses, audit evidence |
Why is the inventory the hard part?
Because the boundary is contested and the omissions are exactly what get found.
Every institution has models nobody registered: a spreadsheet computing an adjustment that feeds a reported figure, a vendor tool applying a score, embedded logic in an origination system, a machine learning service a product team deployed. Each behaves like a model and each represents unmeasured risk. Define the boundary in policy, then discover rather than survey: scan for scoring endpoints, look at what feeds regulatory reports, review vendor contracts for embedded analytics, and reconcile against the change management record. Surveys return what people think is registrable and discovery returns what exists.
What should the inventory record?
Purpose, owner, tier, inputs, outputs, dependencies, deployment location, and version.
Owner means a named accountable individual rather than a team. Tier drives every downstream requirement, so tiering criteria must be written and applied consistently. Inputs and outputs matter because they let you trace impact. Dependencies matter most of all, since models consuming other models' outputs form chains where an upstream weakness propagates invisibly. Record the chain explicitly, and be able to answer which downstream models are affected when one model is found deficient, because that question arrives during an incident rather than in a planning meeting.
How should validation be supported?
Tiered scheduling, independence tracking, standardised evidence, and a workflow that does not queue everything behind the highest tier.
Validation capacity is the binding constraint in most institutions, so the platform's job is to spend it well. Schedule by tier and by change rather than uniformly by calendar, standardise the evidence requirements per tier so preparation is predictable, track independence so the platform can show who challenged what, and let low-tier models follow a lighter documented path with senior review of the tiering itself rather than of every model. Then measure the queue: validation backlog by tier and ageing is the metric that tells you whether governance is functioning or performing.
How does effective challenge get evidenced?
By recording what was challenged, by whom, what changed as a result, and what was accepted.
Effective challenge is independent, competent scrutiny with authority to require change, and it is evidenced by outcomes rather than by attendance. Capture the specific challenges raised, the responses, the resulting changes, and any accepted limitations with rationale. A validation report that records no challenges and no changes is a signal about the process rather than about the model. The governance framing here is developed in this guide to AI model governance and explainability.
How should monitoring be wired in?
Metrics computed in the serving and data platform, thresholds and workflow in the governance platform, fed automatically.
This is where most platforms fail. If monitoring results arrive as a spreadsheet uploaded quarterly by the model owner, then the platform does not know today whether a model is performing, and neither does anyone else. Compute performance, stability, input drift, and override rates in the platform that serves the model, publish them to the governance platform through an interface, and hold thresholds and breach workflow there. Then a breach becomes a tracked item with an owner rather than a line in a report. That integration is ordinary machine learning operations work, as set out in this guide to MLOps for regulated workloads, and it is the single highest-value investment in the whole platform.
Can your platform tell you today which models are outside threshold?
How do findings and remediation work?
As tracked engineering and risk work with owners, dates, severity, and ageing reported upward.
Findings from validation, monitoring breaches, and audit should live in one register with consistent severity definitions, named owners, agreed dates, and evidence required for closure. Report ageing by severity, because ageing findings are the clearest indicator that governance has become documentation. Link findings to the model, the version, and any dependent models so the impact is visible. And allow accepted risk as an explicit outcome with senior approval and an expiry date, since pretending everything gets remediated produces a register full of silently abandoned items.
Where do AI and generative systems sit now?
In your inventory, under your own policy, governed through an AI framework rather than through model risk guidance.
This is the live gap. OCC Bulletin 2026-13 states that the revised guidance explicitly excludes AI and generative AI models as novel and rapidly evolving, which means the framework most institutions expected to lean on does not claim them. The sensible response is not to leave them ungoverned but to govern them deliberately: register them in the same inventory with an AI-specific classification, apply a recognised framework such as the NIST AI Risk Management Framework 1.0 released in January 2023 together with its Generative AI Profile published in July 2024, and expect supervisory attention to arrive through consumer protection, fair lending, conduct, and operational resilience routes instead. The system-level evidence that works is described in generative AI and model risk review, and the fair lending dimension in AI explainability for adverse action.
What should the platform capture for an AI system?
Evaluation sets and results, grounding sources, prompt and model versions, human controls, and monitoring specific to generative behaviour.
The artefacts differ from a statistical model, so the platform needs fields for them rather than forcing them into a validation report template. Capture the held-out evaluation set and its construction, results including variance across runs, grounding sources and their refresh cadence, pinned model and prompt versions, the human review design and its measured effectiveness, and monitoring covering grounding rates, override rates, and refusal behaviour. Where training data is synthetic, record its provenance and validation too, which is the discipline covered in synthetic data generation for financial models.
What reporting does the committee actually need?
Coverage, tier distribution, validation currency, breaches, findings ageing, and unregistered discoveries.
| Report element | Why it matters |
|---|---|
| Inventory coverage and new discoveries | Whether the inventory is converging on reality |
| Tier distribution and changes | Where risk is concentrated and whether tiering is drifting |
| Validation currency by tier | Overdue validations are the classic examination finding |
| Models outside threshold | The live risk position rather than the historical one |
| Findings ageing by severity | Whether remediation happens |
| Accepted risks and expiries | Explicit choices rather than quiet acceptance |
| AI systems and their governance status | The population your guidance no longer covers |
Should you build or buy?
Buy the workflow and documentation layer, build the integrations that make it live.
Vendor platforms handle inventory, workflow, documentation, and reporting competently, and reimplementing that is rarely a good use of engineering. What vendors cannot do for you is connect to your model serving estate, your data platform, your deployment pipelines, and your finding management so that monitoring and version linkage flow automatically. Build those integrations, insist on an open interface when selecting a vendor, and keep your own copy of the data. A bought platform with manual feeds is a repository, and the repository is the thing everyone already had.
How should delivery be phased?
Boundary and discovery first, then inventory, then workflow, then monitoring integration, then AI.
| Phase | Duration | Deliverable |
|---|---|---|
| Boundary definition and policy refresh | 1 to 2 months | Current guidance referenced, model definition, tiering criteria, AI position |
| Discovery | 2 to 3 months | Inventory built from the estate, not from surveys, with dependencies |
| Workflow and documentation | 2 to 3 months | Lifecycle gates, evidence standards per tier, approvals |
| Validation management | 2 months | Tiered scheduling, independence tracking, findings register |
| Monitoring integration | 3 to 4 months | Automated metric feeds, thresholds, breach workflow |
| AI governance extension | 2 to 3 months | AI-specific fields, framework mapping, generative monitoring |
| Reporting automation | 1 to 2 months | Committee and examination packs generated from the platform |
Start with the boundary and the policy refresh, because everything else inherits them, and the refresh is now overdue at most institutions given the April 2026 change. Do discovery before buying a platform, since the inventory you find determines what you need the platform to handle.
Which metrics show governance is real?
Inventory convergence, validation currency, breach response time, findings ageing, and automated feed coverage.
Report new models discovered per quarter and watch it fall toward zero, which indicates the inventory is catching up with reality. Track validation currency by tier and overdue counts. Measure time from a monitoring breach to an owned action, since that interval distinguishes live governance from periodic reporting. Report findings ageing by severity. And measure the share of monitoring metrics arriving automatically rather than by upload, because that single ratio predicts whether the platform will still reflect reality in two years. The judgment-heavy dimension of model risk, where numbers alone mislead, is well described in this piece on signal, noise, and model risk.
Model risk platforms are easy to build as archives and hard to build as control systems. The difference is whether monitoring arrives automatically, whether the inventory was discovered rather than declared, and whether anyone can name the models that are outside threshold this morning.
Frequently Asked Questions
Is SR 11-7 still the governing guidance?
No. SR 26-2 replaced SR 11-7 and SR 21-8 on 17 April 2026, with OCC Bulletin 2026-13 as the companion issuance. Most internal policies still reflect SR 11-7, which is now a gap to close.
Does the revised guidance cover AI models?
The OCC companion bulletin states it explicitly excludes AI and generative AI models as novel and rapidly evolving, so AI governance needs a separate framework rather than an assumed extension.
Why is the model inventory the hard part?
Because the boundary is contested. Spreadsheets, vendor tools, and embedded scoring logic all behave like models, and an inventory that omits them understates risk in a way examiners find.
What are model chains and why do they matter?
Models consuming other models' outputs. A weakness upstream propagates silently, so the inventory must record dependencies rather than treating each model as standalone.
How do you stop validation becoming a bottleneck?
Tier by risk, schedule accordingly, standardise evidence requirements, and let low-tier models follow a lighter documented path. Uniform depth for every model guarantees a queue.
Should monitoring live in the model risk platform?
The thresholds, breaches, and workflow should. The metric computation belongs in the model serving and data platform, feeding the governance platform automatically rather than by upload.
Where do generative AI systems sit now?
In your inventory under internal policy, governed through a recognised AI framework plus consumer protection, conduct, and resilience expectations, since model risk guidance no longer claims them.
Should you build or buy the platform?
Buy the workflow and documentation layer if your processes are conventional, and build the integration that pulls monitoring and lineage automatically, because that is what makes governance real.
