AI Model Decommissioning for Banking: What Must Be Retained and What Must Be Validated Before Switch-Off

AI Governance · Model Lifecycle

AI Model Decommissioning for Banking: What Must Be Retained and What Must Be Validated Before Switch-Off

Decommissioning an AI model is not a deletion event — it's a governance event. Records must be retained for years under RBI's model risk expectations. The successor needs independent validation before the predecessor goes dark. Customer impact has to be assessed, and in India, DPDP Act data-deletion obligations kick in the moment the model stops processing live traffic.

Zytra Research Team · October 2026 · 7 min read

Most banks run decommissioning as an infrastructure task: switch off the endpoint, archive the registry entry, move on. Examiners don't see it that way. They see a model that made real decisions about real customers, and they expect a record of when it stopped, why, what replaced it, and whether anyone checked that the replacement was actually better. We've reviewed decommissioning files that had a clean validation report for the live model and nothing — not a memo, not a committee minute — for the model it replaced eighteen months earlier.

That gap bites in a specific way. Adverse action obligations don't expire when a model does. A customer declined for a personal loan by a model in 2023 can still ask why in 2025, or dispute the decision in an RBI ombudsman complaint in 2026. If the model is gone and so is its documentation, the bank is reconstructing a credit decision from memory — which is not a position any CRO wants to be in during an examination.

Why decommissioning governance is the thinnest part of most model risk frameworks

Model risk policies are usually dense on deployment and validation and nearly silent on retirement — a paragraph, sometimes a single bullet, buried at the end of the lifecycle section. That asymmetry isn't accidental: validation protects the model that's live and generating business value, so it gets resourced. The model being switched off has no one advocating for it internally, which is exactly why it needs a mandatory process rather than a best-effort one.

So what should the bank do: treat decommissioning as a defined stage of the model lifecycle policy with its own owner, its own evidence requirements, and its own committee sign-off — not a subsection of the deployment policy that nobody reopens until an examiner asks for it.

The 5-phase decommissioning governance process

1. Decommission trigger assessment

Document why the model is being retired: performance degradation past a validation threshold, a regulatory change, a technology migration, successor availability, or a straightforward business call. The trigger type sets the clock. A model failing ongoing validation may need immediate suspension with an interim manual or rule-based decisioning process running until the successor is ready — and that interim period needs its own sign-off, because "we fell back to manual underwriting for six weeks" is exactly the kind of fact an examiner will ask about later.

Record: trigger type, date identified, date the risk committee was notified, whether the bank chose immediate suspension or a planned transition, and who authorized keeping the predecessor running during that transition.

2. Customer and portfolio impact assessment

Before anything is switched off, run the successor against the same portfolio the predecessor is currently scoring and look for where outcomes move. Many banks use a materiality threshold — commonly a shift of 5% or more in approval rate, pricing, or limit decisions for a segment — as their own internal trigger for a customer communication plan; that figure is a bank policy choice, not an RBI-mandated number, and it should be documented as such in the model risk policy rather than cited as regulatory text.

For fraud models, compare false positive rates across customer populations rather than only in aggregate. A successor that pushes up false declines for a specific group is a fairness event, not merely a performance regression, and it needs to be treated — and escalated — as one. Document the impact assessment and its conclusions in the committee approval package; a committee that approves a switch without seeing this analysis has approved it blind.

3. Successor validation and parallel run — before the predecessor goes offline

The successor needs independent validation completed before the predecessor is switched off for any regulated use case — not concurrently, not after. Validation should cover conceptual soundness, out-of-sample performance testing, fairness testing (including India-specific proxy variables, covered below), and a parallel run comparing predecessor and successor outputs on the live portfolio.

How long the parallel run needs to be is a judgment call tied to the model's decision volume and how much seasonal or cyclical variation it's exposed to — many credit model teams run 30 to 90 days as a working rule of thumb, long enough to see a full statement cycle or two, but this is industry practice rather than a fixed regulatory period, and a thin-volume portfolio may legitimately need longer. The predecessor stays live and untouched throughout — it is evidence, not dead weight, until the committee says otherwise.

4. Committee approval for switch-off

The model risk committee approves the switch, and the approval package needs to show the full chain: trigger assessment, customer impact analysis, successor validation report, parallel run results, fairness testing outcomes, a customer communication plan where one is triggered, and the record retention plan. The committee should approve four things explicitly — the switch date, any transitional arrangement, the retention schedule, and the data handling plan — rather than waving the whole package through on general minutes.

This specificity matters more than it sounds like it should. When a decommissioned model turns up in an adverse action dispute two years later, the single document that satisfies an examiner is a committee record that names this model, this switch date, and this decommission rationale — not a quarterly model risk committee minute that mentions the model in a list of twelve others.

5. Archival and record retention execution

Once the committee has signed off and the switch has happened, the model artifacts, documentation, and governance records go into an archive with a defined retention period, an owner, and access controls. The bar for "archived" is retrievability, not storage — a record that technically exists on a tape somewhere but takes three weeks and two escalations to locate is functionally unretained when an examiner asks for it. Most banks target a short, defined turnaround (commonly cited informally as 48 to 72 hours for a specific record) as an internal service-level target for examination requests; that is an operational commitment the bank sets for itself, not a published RBI deadline, and it belongs in the archive's own SOP rather than in the regulatory citation column.

The retention schedule needs a named owner per record type and a documented process for responding to examination requests — an archive without an owner is a dataset, not a governance control.

What must be retained and for how long

India-specific decommissioning obligations (DPDP Act 2023 + RBI)

DPDP Act 2023 — retention versus deletion is a real conflict, not a formality. If the original consent for processing a customer's personal data was scoped to the model's stated purpose, and that purpose ends at decommission, data that's no longer needed has to be deleted or de-identified. That sits directly against the multi-year RBI retention expectation above, and the usual resolution is to split the record: keep the decision-level record (anonymized outcome plus model version) for the RBI retention period, and delete the raw personal feature data once the DPDP-applicable purpose has lapsed. Document the categories of personal data processed, the original consent basis, the retention schedule split, and the deletion execution record — the Data Protection Board will ask for the deletion record, not just the policy that describes it.

Get the exposure right when you brief the board: under the DPDP Act, failure to implement reasonable security safeguards that leads to a personal data breach carries a ceiling of up to ₹250 crore per instance (Section 8(5)); failure to notify a breach caps at up to ₹200 crore; most other contraventions cap at up to ₹50 crore. These are per-instance ceilings the Data Protection Board sets case by case, not automatic fixed fines, and that distinction matters when a board is deciding how much decommissioning-deletion rigor is actually proportionate.

India proxy variable fairness audit, at the point of decommission. For credit decisioning models, the decommissioning package should include a closing proxy variable fairness audit: disparate impact by caste (commonly operationalized via pincode or surname proxies, since caste itself isn't a collected field), religion (via UPI counterparty or merchant category code proxies), language community, and disability status. This isn't optional diligence — it's the baseline the successor's own fairness testing gets measured against in Phase 3, and without it, "the new model is fairer" is an assertion, not a finding.

PMJDY and financial inclusion — not a written mandate yet, but an examination area. For retail credit models, decommissioning documentation should include a final check on whether outcomes diverged for Pradhan Mantri Jan Dhan Yojana-enrolled or otherwise low-income customers relative to the broader book. There's no explicit RBI text requiring this specific check today, but RBI's FREE-AI principles — particularly the "People First" and "Fairness and Equity" sutras — make financial inclusion impact a live examination theme, and banks that can't answer the question when asked are the ones that end up explaining it after the fact instead of before.

Who this applies to. The eMRM draft guidance's scope runs wider than scheduled commercial banks — it reaches 11 categories of RBI-regulated entities, including NBFCs (including NBFC-ND-SI), payments banks, Asset Reconstruction Companies, Credit Information Companies, Urban Co-operative Banks, and All India Financial Institutions. A UCB running a vendor-built credit scoring model, or an NBFC-ND-SI relying entirely on a third-party AI underwriting tool, doesn't get to decommission that model with less rigor just because the model wasn't built in-house — the draft guidance is explicit that accountability for third-party and AI models is non-delegable.

What to do before you switch anything off: a working checklist

1. Confirm the trigger and the interim plan are both documented and dated — not just "we're replacing the model," but what the bank does operationally between suspension and successor go-live, and who signed off on that gap.
2. Run the impact analysis before, not after, the committee meeting — segment-level shifts in approval rate, pricing, or false positive rate need to be on the table when the committee votes, not discovered afterward from a customer complaint.
3. Don't switch off the predecessor until the successor's independent validation and parallel run are both complete and filed — "the new model looks fine in testing" is not the same evidence as a completed parallel run against the live portfolio.
4. Resolve the RBI-retention-versus-DPDP-deletion conflict in writing, per model, before archiving anything — decide and document what gets anonymized-and-kept versus deleted, rather than leaving it to whoever happens to run the archival script.
5. Name an owner for the archive and test retrieval before you need it — if nobody has pulled a specific record from the archive in a timed drill, you don't actually know your evidence store works, and an RBI examination is the wrong moment to find out.