Periodic validation and trigger-based revalidation are not the same control, and banks that treat them as one tend to discover the gap during an RBI examination, not before. SR 11-7 and RBI's draft eMRM guidance each describe conditions that force revalidation regardless of where a model sits in its annual or biennial cycle. Between the two frameworks, eight triggers come up consistently in examinations. LLMs add a ninth — RAG corpus drift — that neither framework has caught up to yet.
Why a Validation Calendar Alone Doesn't Satisfy SR 11-7 or RBI's Draft eMRM Guidance
Most banks run a fixed cadence: annual revalidation for High-risk models, biennial for Medium-risk. That cadence satisfies the floor requirement but says nothing about what happens when a model's environment changes mid-cycle. SR 11-7 requires "ongoing monitoring" and revalidation on "significant" change, but never defines significant — a gap regulators have lived with for fifteen years because most of what they were supervising were scorecards and GLMs with stable feature spaces.
RBI's draft Guidance on Regulatory Principles for Model Risk Management, issued 24 June 2026 with comments closed 24 July 2026, closes that gap considerably. It applies across eleven categories of regulated entities — banks, NBFCs, payments banks, ARCs, CICs, co-operative banks, All-India Financial Institutions and others — and it mandates board-approved MRM frameworks, model inventories, risk-based tiering, and independent validation as baseline infrastructure. What makes it more useful than SR 11-7 for an LLM-era validation function is the AI-specific layer: it requires human-in-the-loop or human-on-the-loop review for AI-driven decisions, kill-switch or override mechanisms the validation function has to actually test, and explicit attention to automation bias and decision fatigue in the humans doing that review. That last point rarely appears in model risk frameworks anywhere else — most treat the human reviewer as a control, not as something that itself degrades under load. The draft also makes third-party and vendor model risk non-delegable, which matters enormously once foundation models enter the inventory.
The 8 Revalidation Triggers (Plus the One LLMs Add)
1. Performance metric breach. Gini drops below the tier floor, PSI breaches the drift threshold, or FPR breaches at the segment level even while the aggregate metric looks fine. In practice, most validation teams treat PSI above 0.25 as a material population shift requiring full assessment, and PSI between 0.10 and 0.25 as a watch-zone trigger that at minimum demands a targeted look at the affected segment. A model that's drifting only in one state or one product line almost never needs a full revalidation — but the watch-zone band is where validators get lazy, and it's exactly where segment-level fraud or credit shifts hide before they show up in the aggregate number three months later.
2. Material data change. A new data source, new features, a pipeline change, or data quality deterioration. The scope call hinges on whether the core feature set changed or whether this was additive. In practice "additive only" is the claim development teams make and the claim validators should distrust by default — an added feature rarely sits independently; it changes interaction effects with everything already in the model, and a validator who takes "we only added a feature" at face value is signing off on an assumption, not a test result.
3. Significant use change. New population, new product, new geography, new decision context. A model trained and validated on urban salaried applicants deployed against a rural self-employed segment is, for validation purposes, effectively a new model — this one calls for full revalidation, not a scoped look.
4. Material environmental change. Interest rate regime shifts, fraud tactic shifts, market structure change. This doesn't automatically trigger revalidation — it triggers an assessment, and the assessment decides whether revalidation follows. The mistake banks make here is treating the assessment itself as optional.
5. AI incident linked to model outputs. Incorrect credit guidance, a missed fraud pattern exploited at scale, an LLM hallucinating financial information that reached a customer. If the failure mode is systemic rather than a one-off, full revalidation follows. The test is whether the same failure could recur across the population, not whether this particular customer complaint gets resolved.
6. Regulatory change. A pre-existing credit or underwriting model that hasn't had proxy variable testing needs a targeted revalidation to add it, scoped to the new requirement rather than the whole model. On explainability: the DPDP Act gives data principals a right to know what personal data is being processed and some transparency through grievance and correction mechanisms, but it doesn't contain an explicit "feature-level explainability" obligation as statutory text — that's a reasonable reading of DPDP's transparency intent combined with RBI's own documentation expectations, not a citable requirement. A model with only model-level SHAP and no decision-level explanation is still a defensible gap to close under that reading; banks in EU AI Act scope have a cleaner anchor in Article 86's right to explanation of individual decisions for high-risk systems.
7. Vendor or foundational model update. GPT-4o to GPT-4o-mini, a Claude version bump, an open-source foundation model point release. This is the trigger validation teams miss most often, because the change doesn't show up as a ticket in the bank's own change log — it shows up as a silent API-level swap on the vendor's side. The pattern we see repeatedly: a vendor ships a "minor" version update, nobody on the bank's side is notified because nothing in the contract requires notification, and three weeks later someone in the business unit flags that the chatbot's tone or refusal behavior has shifted. By then it's not a revalidation question anymore, it's an incident investigation. Assessment is required on any vendor update; targeted revalidation if configuration is unchanged, full if behavior has moved materially.
8. Scheduled periodic revalidation. Annual for Critical/High, biennial for Medium, triennial for Low with continuous monitoring in between. This is the floor, not a substitute for trigger-based revalidation — initiate the process 60 days before the due date so scope decisions aren't made under deadline pressure.
9. RAG corpus change (LLM-specific). Neither SR 11-7 nor the RBI draft fully addresses this yet. A retrieval-augmented model's behavior is a function of its corpus as much as its weights — swap the knowledge base, change the chunking strategy, or update the embedding model, and the system's answers shift without a single parameter changing. Treat corpus versioning as a tracked model attribute, not a documentation afterthought.
Full vs. Targeted vs. Change-Assessment: What Scope Each Trigger Actually Requires
| Scope | Triggers | Typical output |
|---|---|---|
| Full revalidation | New population, structural performance failure, significant use change, scheduled Critical/High cycle | Complete re-run of methodology, conceptual soundness review, outcomes analysis, new validation opinion |
| Targeted revalidation | Additive feature, new regulatory requirement, isolated segment breach, vendor minor update with unchanged config | Scoped test plan covering only the changed component, addendum to existing validation opinion |
| Change assessment | Environmental shift, vendor update (pre-scope decision), minor configuration change | Documented assessment memo that concludes either "no revalidation needed" or routes into full/targeted scope |
The LLM Revalidation Problem: No Fixed Output Space to Benchmark Against
Traditional model validation assumes a bounded output — a score, a probability, a class label — against which you can measure stability. An LLM doesn't have that. Validating it requires behavioral consistency testing across prompts, adversarial evaluation against jailbreak and prompt-injection patterns, and reference-output comparison across model versions. None of this maps cleanly onto a standard SR 11-7 validation template built around backtesting a PD model. A validator trained on statistical model review will reach for a confusion matrix and find there isn't one to build.
The demographic dimension compounds this. Behavioral consistency has to be tested at the segment level — does the model answer a rural Hindi-speaking customer with the same accuracy and tone as an urban English-speaking one — and that's a test most validation teams have never had to design before, because traditional credit models were already segment-aware by construction. An LLM isn't; it has to be tested into being segment-fair, and that testing has to be repeated on every material prompt, retrieval, or foundation-model change.
Proxy Variable Testing for Indian Deployments: Why Maharashtra and Karnataka Need Separate Test Sets
Proxy variable testing isn't a one-time fairness audit — it's a trigger-based obligation that fires on new geography, feature addition, segment-level performance breach, or a regulatory change that re-scopes fairness requirements. The reason geography matters specifically: pincode-to-caste and pincode-to-religion correlate mappings are state-specific, not national. A pincode-based proxy that correlates strongly with a protected category in Maharashtra can correlate weakly — or differently — with a completely different category pattern in Karnataka, because settlement patterns, migration history, and administrative boundaries differ. A validator who reuses a Maharashtra proxy test set against a Karnataka rollout is testing the wrong thing and will likely get a clean result that means nothing. The only defensible practice is a state-specific proxy variable registry, rebuilt and re-validated every time the model enters a new state, not inherited from the last state it launched in.
The Minimum Evidence Set an Examiner Will Ask For
Every trigger-based revalidation needs seven items on file, regardless of scope:
- Trigger documentation — what happened, when, and how it was detected
- Scope decision — full, targeted, or assessment-only, with the reasoning
- Methodology — what was tested and why that method fits the trigger
- Results — the actual test outputs, not a summary paragraph
- Validation opinion — a signed conclusion, not a pass/fail checkbox
- Committee approval — model risk committee sign-off with date
- Model card update — the model's documented state reflects what changed
Missing any one of these turns a clean revalidation into an examination finding, because the gap looks like the revalidation didn't actually happen even when it did.
Action Checklist: What the Validation Function Should Build Before the Next Trigger Fires
- Replace the schedule tracker with a trigger log. Timestamp every drift signal, data change, incident, and vendor notice against the model ID and affected segment — a calendar alone can't prove trigger-based coverage to an examiner.
- Pre-register thresholds per risk tier before a drift event happens. PSI >0.25 as material, 0.10–0.25 as watch-zone-triggers-targeted-review, segment-level FPR tolerances — written into the MRM framework now, not negotiated during an active breach.
- Put a version-pin and notification clause in every foundation-model and vendor contract, and build an independent monitor for vendor version changes — don't rely on a changelog email that may never arrive before customers notice a behavior shift.
- Maintain a state-specific proxy variable registry for every Indian geography the model touches, and treat a new-state rollout as an automatic full proxy-testing trigger, never an inherited test set from the last launch.
- Version-stamp the RAG corpus as a tracked model attribute, and write demographic- and language-segment behavioral consistency tests into the release gate for any LLM or agentic system — not as a nice-to-have appendix to the validation plan.
Zytra's model risk platform tracks all nine triggers automatically against live model telemetry, vendor version feeds, and corpus change logs — see related guides on RBI's draft eMRM guidance and AI incident response for banks.
Related: model validation and lifecycle governance
Monitor all 8 re-validation triggers automatically — never miss one
Zytra tracks performance drift, data source changes, behavioral consistency, RAG corpus changes, and scheduled re-validation dates in one platform. When a trigger fires, the re-validation workflow starts automatically with the evidence already assembled.