Model Change Assessment: Revalidate, Reapprove, or Update the Inventory?

TL;DR

• A model change assessment is the routing record between a code ticket and a risk decision. It determines whether the change is maintenance, a material change, or effectively a new model.
• Classify the impact across methodology, data, use, population, output authority, performance, limitations, exposure, and controls. “No code change” does not mean “no model change.”
• The record should end with a specific route: inventory-only update, targeted testing, targeted validation, full revalidation, reapproval, parallel run, retirement, or a combination.
• Keep the original model ID when lifecycle continuity matters. Create a new record when two versions or forks need separate ownership, validation, monitoring, or retirement.

A model change assessment is where vague change control becomes an accountable model-risk decision. Without it, a developer calls the release “routine,” the validator learns about it after deployment, and the inventory still points to the version that was approved six months ago.

The April 17, 2026 interagency model risk guidance gives institutions room to tailor validation. It also makes the change decision impossible to dodge: validation timing, nature, and frequency vary based in part on model purpose, methodology, and the frequency and scope of model changes. The practical control is a short record that translates changed facts into testing, validation, approval, inventory, and deployment actions.

Regulatory status matters: the April 2026 document is supervisory guidance, not a binding regulation. The agencies state that it does not have the force and effect of law and that noncompliance is not, by itself, a basis for criticism. The routing matrix below is RiskTemplates suggested practice for operationalizing that guidance; it is not an agency-prescribed form.

This is not another summary of OCC Bulletin 2026-13. It is the artifact the model owner completes when somebody says, “We only changed one thing.”

Start the model change assessment before the release ticket closes

The assessment can begin with a proposed change, an emergency fix, a vendor release notice, or a monitoring result that leads to recalibration. It should not begin after production deployment unless the institution is documenting an emergency exception.

Use one record per governed change package. The minimum header is:

The model owner should draft the factual description. Model Risk or an authorized independent reviewer should challenge classification and validation scope. Technology Change Management owns the release mechanics; it should not decide model materiality by itself.

What changed? Test nine impact dimensions

A line-count comparison is a poor materiality test. Some large refactors preserve behavior. A one-line threshold adjustment can alter thousands of customer decisions.

Score impact qualitatively—none, limited, or material—across these dimensions:

The 2026 guidance’s model-use section specifically warns that extending a model beyond its original application introduces additional uncertainty and calls for analysis of the new use, its limitations, and existing controls. That means a product team can create a material model change without touching the model package at all.

Practical aside: ownership gets messy at the dependency line. Engineering may say a bureau-data schema change is “upstream.” Model Risk may say the model formula is untouched. The assessment needs an owner who tests whether the changed input distribution, missingness, and mapping alter model behavior. Organizational boundaries do not prevent output drift.

Use a routing matrix, not a single “material/non-material” checkbox

Binary classification hides the action. A better model change assessment produces one of three classifications and then selects every required route.

These are operating categories, not terms prescribed word-for-word by the agencies. Define them in policy and state who can approve each route.

A change can require targeted validation and reapproval without becoming a new model. It can also require a new inventory record and parallel-run controls while the prior model remains active. Do not force one checkbox to carry all of that logic.

A defensible routing decision

For each assessment, answer five separate questions:

1. Testing: What must the developer or owner test before release?
2. Validation: Which affected components require objective review—conceptual soundness, outcomes analysis, monitoring, data, implementation, or all of them?
3. Approval: Does the existing approval still authorize this version, use, population, exposure, and control package?
4. Inventory: Which fields, relationships, statuses, limitations, and dates must change?
5. Deployment: Is release blocked, conditional, phased, parallel, reversible, or subject to enhanced monitoring?

The interagency guidance says validation generally occurs before first use. Where urgent business need leads to use before validation is complete, it points to heightened attention to limitations, stakeholder notice, use limits, and closer monitoring. An emergency flag therefore creates more documentation: reason, remaining validation, permitted use, owner, monitoring, rollback, expiry, and approval authority.

Worked example: a threshold change that is not “just configuration”

Realistic hypothetical: a fintech uses a non-generative statistical fraud model to score outbound transfers. Operations proposes raising the auto-decline threshold because false positives are creating customer complaints. No features, coefficients, or source data will change.

The weak assessment says:

Configuration-only change. No model impact. Standard release approval.

The stronger assessment records:

• Methodology: limited change; scoring formula is unchanged, but decision threshold changes how output is used.
• Population: unchanged.
• Output authority: material operational impact because fewer transactions will be automatically declined.
• Performance: expected false positives decline; false negatives and fraud losses may increase.
• Exposure: quantify affected transaction count and value using a back-test, segmented by relevant product and customer risk tier.
• Controls: revise review-queue capacity, fraud-loss monitoring, override treatment, and rollback trigger.
• Validation route: targeted independent review of threshold analysis, segment performance, and monitoring design.
• Approval route: reapproval by the authority responsible for the model’s permitted use and fraud-risk tolerance.
• Inventory action: preserve the model ID; add the new version/effective date, threshold, validation reference, approval, monitoring changes, and prior-version retirement date.
• Deployment condition: retain the prior threshold for rollback; review agreed outcome measures after a defined observation window.

No universal percentage or loss threshold is implied here. Calibrate decision limits to the institution’s risk appetite, historical performance, customer-impact analysis, and model materiality. The control principle is that a threshold can change the decision even when it does not change the score.

When should the inventory get a new record?

A new record is useful when the organization needs to govern two objects independently. Consider it when:

• old and new models operate in parallel;
• a fork has a different purpose, owner, population, methodology, monitoring plan, or approval;
• a vendor replacement has a distinct lifecycle and limitations;
• the changed system meets the policy definition of a new model; or
• separate retirement evidence is needed for the predecessor.

Keep the same ID with version history when continuity is clearer and the change remains part of one governed lifecycle. Either way, never overwrite history. Retain predecessor/successor relationships, production dates, validation references, approval dates, limitations, incidents, and retirement status.

The inventory should show three clocks separately:

• technical version effective date;
• validation completion or conditional-use expiry; and
• governance approval date.

Collapsing them into one “last updated” field makes it impossible to tell whether production outran validation or approval.

For a deeper inventory design, pair this process with the model inventory fields and ownership guide and preserve material reviewer disagreements using the effective-challenge memo.

Do not misapply the guidance to generative or agentic AI

Footnote 3 of the April 2026 interagency guidance expressly says generative AI and agentic AI are outside its scope. It also says broader governance should determine appropriate controls for tools, processes, and systems not covered, while the guidance’s principles apply to traditional statistical and quantitative models and non-generative, non-agentic AI models.

That boundary belongs in the assessment:

The NIST AI Risk Management Framework offers a voluntary, use-case-oriented reference for broader AI governance. The immediate objective is not to squeeze every system into “model.” It is to ensure every consequential change reaches an accountable review route.

So what should you do this week?

Pull the last ten production changes touching a model, its data, its use, or its decision workflow. For each one, try to produce the impact assessment, validation-scope decision, approval, inventory update, deployment conditions, and retirement evidence.

If the evidence stops at a Jira ticket, add the model change assessment between technical release and production authorization. Start with the nine impact dimensions above. Require Model Risk to sign the route—not to rubber-stamp the code ticket—and require Change Management to verify that the selected conditions actually reached production.

The AI Risk Assessment Template & Guide includes inventory, assessment, approval, limitation, and monitoring artifacts you can adapt for AI use cases while keeping formal model changes aligned to your model-risk policy.

Primary sources: OCC Bulletin 2026-13 · Interagency Supervisory Guidance on Model Risk Management, April 17, 2026 · Federal Reserve SR 26-2 · FDIC interagency issuance · NIST AI RMF