AI Model Migration and SR 11-7 Compliance: What Financial Services Teams Need to Know

For most engineering teams, a model migration is a technical event. A provider announces deprecation, the team evaluates replacement options, tests the new model in a staging environment, and schedules the cutover. The work is measured in sprints and deployment cycles.

For financial services organizations operating under SR 11-7, the Federal Reserve’s model risk management guidance, the same migration is something else entirely: a model risk management event with documentation, validation, and approval requirements that the engineering team may not be aware of.

This disconnect between technical execution and regulatory obligation is creating compliance exposure across the industry. When AI model providers announce deprecation timelines, engineering teams move quickly to maintain operational continuity. Model risk management functions often learn about these migrations late in the process, sometimes after the replacement model is already in production.

The consequences surface during examinations. OCC and Federal Reserve examiners are increasingly asking for model change management records as part of AI-related examination activities. Organizations without documented migration processes are discovering this gap at the worst possible time.

What SR 11-7 Requires for Model Changes

The Federal Reserve’s SR 11-7 guidance, issued in 2011 and still the governing framework for model risk management at supervised institutions, establishes clear expectations for how banks manage models throughout their lifecycle. The guidance requires that material model changes go through validation, documentation, and approval processes equivalent to a new model deployment.

The logic is straightforward: a model that performs differently than the one previously validated represents new risk. The original validation no longer applies. The model risk management function needs to independently assess whether the replacement model performs acceptably before it enters production.

This requirement applies regardless of whether the change was initiated internally or forced by an external provider. The regulatory obligation does not adjust based on the reason for the migration.

Why AI Model Migrations Qualify as Material Changes

AI model migrations meet the materiality threshold under most reasonable interpretations of SR 11-7 guidance. A replacement model has different behavioral characteristics, different training data, and different performance profiles from the deprecated original.

Even when a provider positions a new model as a direct successor to the previous version, the replacement is not the same model. It may perform better on some tasks and worse on others. It may respond differently to edge cases. It may have different failure modes.

For a financial services organization using that model in a decision-support or customer-facing application, these differences matter. They affect the accuracy, fairness, and reliability of the model’s outputs in ways that the original validation did not assess.

The materiality determination is not a close call. Swapping one AI model for another is a material change that triggers SR 11-7 requirements.

The Specific SR 11-7 Requirements Triggered by Migration

When a model migration triggers SR 11-7 obligations, organizations must complete several specific activities:

Independent validation of the replacement model before production deployment. The model risk management function, or a qualified third party, must assess the replacement model’s performance, limitations, and suitability for its intended use. This validation must be independent from the team that developed or implemented the model.

Documentation of the validation process and outcome. The validation activities and findings must be documented in a form that can be reviewed by examiners. This documentation should explain the validation methodology, the data used for testing, the performance metrics evaluated, and the conclusions reached.

Approval by the model risk management function before the switch. The migration cannot proceed until the model risk management function has approved the replacement model for production use. This approval should be documented and traceable.

Updated model inventory reflecting the change. The organization’s model inventory must be updated to reflect the new model, including its version, provider, intended use, risk classification, and validation status.

Ongoing monitoring evidence for the replacement model. Once the replacement model is in production, the organization must demonstrate ongoing monitoring of its performance. This includes tracking key performance indicators and documenting any deviations from expected behavior.

Organizations that use AI governance platforms can automate much of this documentation and evidence collection, reducing the manual effort required to maintain compliance.

The Timeline Problem

Here is where engineering realities and regulatory requirements collide.

SR 11-7 validation for complex AI models typically requires 4 to 8 weeks. The validation team needs time to understand the model, design appropriate tests, execute those tests, analyze results, and document findings. For models used in high-risk applications, the timeline may be longer.

Provider deprecation windows commonly run 90 days. That sounds like adequate runway until you account for the full scope of the work:

The organization may have multiple affected systems, each requiring independent validation
Validation resources are typically constrained and shared across the institution
The validation queue may already contain other models awaiting review
Testing environments need to be configured and data needs to be prepared
Stakeholder reviews and approvals add elapsed time even when work is complete

A 90-day window can compress very quickly. Organizations with five or ten affected systems may find that the math simply does not work without compromising validation quality or missing the deprecation deadline.

This is why building a comprehensive model inventory and governance framework before a deprecation notice arrives is essential. Organizations that already know which models are in production, where they are used, and how they are classified can respond to deprecation announcements with a plan rather than a scramble.

What Examiners Are Looking For

Regulatory examination practices have evolved alongside AI adoption. OCC and Federal Reserve examiners are now routinely asking questions about AI model governance, including:

How does the organization maintain its inventory of AI models?
What process governs changes to production models, including migrations?
Can the organization produce validation documentation for AI models currently in use?
How does the organization monitor AI model performance on an ongoing basis?
What approval workflow governs AI model deployment and changes?

Organizations that cannot answer these questions with documented evidence are receiving examination findings. The findings often require remediation on accelerated timelines, creating the same resource constraints that led to the gaps in the first place.

Examiners are not evaluating whether organizations use AI. They are evaluating whether organizations govern AI with the same rigor they apply to other models. The expectations are not new. The application to AI models is what has changed.

The Practical Compliance Path

The organizations that manage AI model migrations successfully share a common approach: they build the governance infrastructure before the deprecation notices arrive.

This means:

Maintaining a complete model inventory. Every AI model in production should be cataloged with its provider, version, intended use, risk classification, validation status, and owner. When a deprecation notice arrives, the organization can immediately identify affected systems and prioritize validation work.

Establishing validation frameworks in advance. The methodology for validating AI models should be defined before any specific model needs validation. This includes performance metrics, testing approaches, documentation templates, and approval workflows. Validation teams should not be designing processes under deadline pressure.

Implementing continuous governance and monitoring. Ongoing performance monitoring should be automated and documented. When a migration occurs, the organization can demonstrate a clear before-and-after comparison of model behavior.

Integrating engineering and risk management workflows. Engineering teams need visibility into regulatory requirements. Model risk management functions need visibility into technical changes. The migration process should include checkpoints that ensure both perspectives are represented.

Building SR 11-7 Compliance Into Your AI Operations

Airia’s Model Risk Management integration with Microsoft Foundry is designed specifically for the SR 11-7 compliance motion. The platform provides continuous validation, behavioral drift detection, governed change workflows, and automated compliance documentation mapped to SR 11-7 model risk management requirements.

Rather than treating compliance as a separate workstream that runs parallel to engineering, Airia’s governance and compliance capabilities embed regulatory requirements directly into AI operations. Validation evidence is generated automatically. Model inventory updates happen in real time. Approval workflows route to the right stakeholders without manual intervention.

For financial services organizations, this approach transforms model migrations from compliance emergencies into governed transitions. When a deprecation notice arrives, the validation framework is already in place. The model inventory is already current. The monitoring baseline is already established.

The migration can proceed on a governed timeline rather than an emergency one.

Ready to build SR 11-7 compliance into your AI operations? Schedule a demo with Airia to see how continuous governance and automated compliance documentation can transform your model risk management program.