TL;DR

• What it is: Model validation is the independent test of whether one specific model works as claimed, run by people who did not build or operate it.
• The core mechanic: A validation review checks four things: conceptual soundness, data and assumptions, calculations, and outcomes analysis against real results.
• Who performs it: People separate from the model’s development and use, to a standard of independence comparable to an audit function.
• Key RBI dates: The RBI’s Draft Guidance on Regulatory Principles for Model Risk Management (24 June 2026, Press Release 2026-2027/528) requires independent validation of every model, including third-party models, with reports to decision-makers within three months.
• One caveat: This RBI guidance is a draft under consultation, not final law, and it does not itself set a fixed numeric revalidation schedule (such as “annually”).

A risk team builds a new collections scorecard, tests it against last quarter’s data, and ships it. The development team calls that testing “validated.” It is not. A model checking its own homework is not validation, it is confidence, and confidence is not what a regulator asks to see. Independent review is what actually stands between a working model and a model that only looks like it works.

What model validation checks that model risk management does not

Model validation is the set of tests that checks whether a specific model does what it claims, run by people who did not build it. It examines the model’s assumptions, the data feeding it, its calculations, and its results against real outcomes, then documents exactly where the model can and cannot be trusted.

Model validation is one control inside the wider model risk management framework, which also covers governance, the model inventory, and ongoing monitoring. Validation answers a narrower question: does this one model, right now, hold up under independent testing? Governance decides who is accountable. Monitoring watches the model after validation is done. Validation is the test in between.

The four things a validation review has to test

A validation review is not a single check. It has four parts, and skipping any one leaves a real gap a regulator or an examiner will find.

Conceptual soundness. The reviewer checks whether the model’s underlying logic and assumptions make sense, using the developer’s own documentation as evidence. A credit model that assumes stable employment patterns needs that assumption tested against the borrower segment it actually scores.

Data and assumptions. The reviewer examines what data trained and feeds the model, and whether its assumptions hold for the population it is used on. A collections model trained on urban salaried borrowers and then applied to rural self-employed borrowers is being tested on the wrong assumption before a single score is produced.

Calculation review. The reviewer tests the model’s actual math and code, independent of what the documentation claims it does. This catches the gap between what a model is supposed to compute and what it actually computes.

Outcomes analysis. The reviewer checks the model’s results against what actually happened, including backtesting against historical outcomes and benchmarking against alternative models. A default-risk model that scored a segment as low risk gets checked against that segment’s real default rate.

Skip outcomes analysis and a model can look sound on paper while quietly mispricing risk in the book.

Why the person validating a model can’t be the person who built it

Model validation has to be performed by people who are separate from the model’s development and its day-to-day use. This is not a courtesy. A developer who spent months building a model has a stake in it working, and that stake compromises objectivity in ways that are hard to self-correct.

The standard is closer to audit independence than to peer review. Someone who regularly operates a model, or who built it, cannot also be the one who certifies that it works. A validation function or team with no ownership stake in the outcome, reporting through a separate line, is what makes independent findings possible instead of theoretical.

How often a model needs revalidating, and why “once at launch” fails

A model validated once at launch and never revisited is a model an institution is trusting blind after month one. Revalidation frequency should scale with the model’s risk tier: models with more material impact on decisions or losses get reviewed more often than models with limited exposure.

The RBI’s 2026 draft guidance takes this same risk-based approach, without prescribing a fixed calendar. It requires risk-based tiering that drives how intensively each model is validated, protected by an anti-dilution rule so a model cannot be scored as low complexity in a way that quietly reduces the validation intensity a high-materiality model actually needs.

This RBI draft is not yet finalized, and it does not itself set a specific numeric revalidation schedule such as “annually” or “every three years.” Institutions building their own cadence should tier by materiality and complexity, and revalidate sooner whenever a model’s inputs, use case, or the population it scores changes meaningfully. Waiting for a fixed calendar date while the world underneath the model has already moved is how drift gets past a validation schedule.

What the RBI’s draft guidance specifically requires of validation

The RBI’s Draft Guidance on Regulatory Principles for Model Risk Management, released 24 June 2026 (Press Release 2026-2027/528), sets validation-specific obligations distinct from its broader governance requirements.

• Every model must be independently validated, including third-party models. A vendor-built scorecard does not get a pass on independent review because the institution did not build it.
• Validation reports must reach decision-makers within three months of completion. A validation finding that sits unread for six months protects no one.
• Risk-based tiering determines validation intensity, with the anti-dilution rule preventing a low complexity score from understating a model’s actual materiality.
• Using a third-party model does not transfer accountability. The institution “remains fully accountable” for outcomes even when validation and the model itself come from a vendor.

This is a draft under public consultation. Comments closed 24 July 2026, and the guidance is not yet in force. On finalization, it would supersede Chapter 3 of the RBI’s 2002 Guidance Note on Credit Risk Management.

Building a validation process that produces a report someone actually reads

A validation report that takes six months to produce and lands in an inbox nobody checks does not protect an institution from anything. Meeting the RBI draft’s three-month reporting expectation, across every model in a growing inventory, is not realistic with a validation team running spreadsheets and manual tests.

A governed platform closes that gap by building the evidence validation needs directly into how models run. Every prediction carries an audit-grade explanation. Every model change moves through maker-checker approval before it reaches production. The full lineage from data to decision sits in an immutable audit trail, so a validator is reviewing documented evidence instead of reconstructing it from scratch.

A leading NBFC in India used this approach to rank borrowers by risk and focus collections on the highest-risk segment, seeing a 116% improvement in collections and 86% predictive accuracy, deployed in two weeks. Validation was not a separate project bolted onto that result. The audit trail and explainability that made the model easy to validate were also what made it fast to deploy with confidence.

If your validation function is scoping how to meet the RBI draft’s requirements, book a working session with our data science team to map your current process against the draft’s specific validation obligations.