Your Model Passed Validation. Now It Is On Its Own. That Is the Problem.

TL;DR

• RBI’s 2026 MRM guidance requires regulated entities to monitor deployed AI models for two distinct failure modes: long-term structural bias and short-term drift across data, features, and overall model performance.
• Long-term bias builds when training data encodes historical decision patterns rather than true creditworthiness signals. Para 54(3) requires institutions to conduct fairness assessments and address discriminatory outputs through recalibration or redesign.
• Three types of drift require monitoring at different frequencies: data drift, feature drift, and model drift. Para 54(7) makes ongoing monitoring of data drift and concept drift an explicit regulatory requirement for AI and ML models.
• Para 56 creates enhanced obligations for models with dynamic or automatic updates, including defined scope for automatic changes, enhanced data quality checks, and more stringent monitoring frequency.
• Para 42 requires institutions to define a material change threshold. Crossing it restarts the validation and approval process. Without continuous monitoring, institutions have no reliable mechanism to know when that threshold has been crossed.

Your credit scoring model passed validation 18 months ago. Since then, it has processed tens of thousands of applications. The macro environment has shifted. New borrower segments have entered your product mix. Several of the input features your model was trained on have changed in distribution. Your model has none of this context. It continues applying the logic it learned from data that no longer reflects the population it is making decisions about today.

RBI’s 2026 draft guidance on Model Risk Management does not treat a validated model as a compliant one. Validation is a point-in-time checkpoint. The guidance establishes ongoing monitoring as the continuous obligation that determines whether a model remains fit for use. Para 16 makes this explicit: regulated entities must undertake ongoing performance testing using backward-looking and forward-looking approaches, including AI-specific evaluations where applicable.

Most institutions have some form of post-deployment monitoring. Most of it tracks one dimension of model health and misses the other. Understanding both failure modes is the foundation for a monitoring programme that meets what the guidance actually requires.

Two failure modes, one monitoring gap

AI models degrade in two fundamentally different ways.

The first is structural bias 

The model has encoded patterns from its training data that do not reflect creditworthiness but reflect historical institutional decision-making. These patterns are typically present from the moment of deployment. They do not worsen in the way drift does. They persist silently because the model produces outputs that look coherent, pass standard accuracy checks, and correlate with historical outcomes. The problem is the historical outcomes themselves encode the bias.

The second is drift 

The relationship between inputs and outputs changes over time as the population the model operates on evolves. Drift is not a flaw in the original model. It is an inevitable consequence of deploying a static model in a dynamic environment.

Monitoring programmes that focus on model-level performance metrics such as AUC and accuracy scores tend to catch drift once it has become severe. They rarely surface structural bias. And they often miss the early-stage drift signals that, if caught at the feature and data level, would allow remediation before headline performance deteriorates. The guidance requires institutions to address both failure modes. A monitoring programme built for one will leave the other ungoverned.

Long-term bias: how training data shapes lending decisions for years

A model trained on historical loan decisions learns from the outcomes those decisions produced. If your institution declined applications from a particular geography at a higher rate over the past five years, not because of credit fundamentals but because of portfolio concentration preferences, the model treats geographic origin as a predictor of default. It has learned the pattern correctly. The pattern reflects what your institution decided, not what those borrowers would have done with capital.

The same logic applies to income band, employment type, or any other variable that correlates with historical institutional decisions rather than with actual borrower behaviour.

Para 54(3) of the RBI guidance addresses this directly 

It requires institutions to identify the risk of bias and discriminatory outputs, specifically in use cases involving potential unfair treatment of certain customer groups. Where bias is identified, the institution must conduct a fairness assessment and implement mitigants, which may include recalibration or redesign. For complex models, the guidance permits constraining model complexity through regularisation and limiting feature selection as additional risk controls.

Para 54(5) carries a related requirement 

Institutions must ensure models do not rely on spurious correlations or unintended relationships that may adversely affect outcomes. A model that has learned a correlation between geography and decline rates when no causal credit relationship exists is relying on exactly the kind of spurious relationship this paragraph targets.

What the fairness assessment obligation means in practice

The fairness assessment requirement is not a one-time exercise at the point of validation. As the borrower population changes, the demographic distribution of model inputs changes, and a model’s differential treatment of subgroups can shift even when overall accuracy metrics hold steady. Satisfying Para 54(3) requires tracking model outputs across population subgroups on an ongoing basis, not just at deployment.

The three types of drift, and why each needs a different monitoring approach

When practitioners discuss model degradation, the default reference is model drift: headline performance metrics falling below acceptable thresholds. By the time AUC drops meaningfully, two other types of drift have typically been building for months. RBI’s guidance in Para 54(7) makes ongoing monitoring of data drift and concept drift an explicit obligation. Three categories map directly to this requirement.

Data drift

Data drift occurs when the statistical distribution of model inputs shifts from the training baseline. A collections model built in 2022 on a borrower portfolio concentrated in urban salaried segments now processes a meaningfully different mix if your institution expanded into self-employed and semi-urban borrower profiles through 2023 and 2024. The model’s logic was calibrated to the earlier population. Its outputs on the current population carry increasing uncertainty.

Data drift occurs at the highest frequency of the three. Input distributions can shift within a single quarter. Effective monitoring tracks distributional statistics at the input level: mean, standard deviation, skewness, missingness patterns, and variance. A significant shift in any of these signals that the model is operating on data materially different from its training set.

Feature drift

Feature drift is more targeted: a specific input variable loses its predictive relationship with the outcome the model is designed to predict. A bureau score feature that was highly discriminatory at model development may lose that power as score inflation occurs across the lending market, or as your acquisition strategy moves toward segments with thinner bureau history.

Feature drift is measured through predictive power statistics on individual variables: Fisher Score for numerical features and Information Value for categorical ones. It tends to occur at a slower frequency than data drift, but it can remain invisible in model-level metrics. The model compensates by redistributing weight to other features, which can create new and unintended dependency risks in the process.

Model drift

Model drift is what most monitoring programmes already track: overall model performance metrics deteriorating below acceptable thresholds. AUC falls. PSI rises. F1 score declines. By the time these metrics cross the alert threshold, the underlying causes have typically been accumulating across data and feature dimensions for months.

Monitoring model drift in isolation means institutions respond to degradation that is already complete rather than to a signal they can act on early. Three-layer monitoring surfaces the leading indicators before the headline metric moves, giving model risk teams time to investigate, remediate, and document before the degradation reaches a level that requires RMCB escalation.

Running models across banks, NBFCs, or insurance? See how iTuring monitors drift across all three layers in real time.

Para 56: The enhanced obligation for models that update automatically

Para 56 is the most operationally demanding paragraph in the guidance for institutions running adaptive or continuously retrained models.

The guidance requires enhanced controls for models with dynamic or automatic updates. The institution must define a clear scope for what the model can update automatically. It must provide strict justifications for enabling those automatic update mechanisms. It must apply enhanced data quality checks to the incoming data before it enters the model. And it must implement more stringent and more frequent monitoring for models operating under automatic update regimes.

The practical implication is direct 

If your credit scoring model retrains on a rolling six-month window, each retraining cycle is not a routine operational event. The updated model is not the same model the RMCB approved for deployment. Para 56 requires the institution to define, justify, and govern that update process with controls commensurate with the risk the change introduces.

Institutions that have automated retraining pipelines without formalised oversight structures for those pipelines carry an obligation gap under Para 56 that a point-in-time validation review would not surface.

When drift becomes a regulatory event: Para 42 and the material change threshold

Para 42 requires each regulated entity to define the threshold or criteria that constitute a material change to a model. Crossing that threshold restarts the validation and approval process.

Paras 38 through 41 build the change management structure around that threshold. Any change must be preceded by a documented impact assessment covering the model’s continued suitability for its intended use. The institution must maintain a comprehensive change log and version history. Recovery mechanisms must exist for failed changes or unexpected results.

The monitoring implication is significant 

An institution tracking only model-level performance will detect a material drift only after it has accumulated to a level that visibly affects headline metrics. An institution with three-layer monitoring, tracking data and feature drift as leading indicators, can identify that the material change threshold is being approached before the approval obligation is formally triggered. Compliance and model risk teams have time to prepare documentation and schedule re-validation proactively rather than reactively.

For models approved with exceptions, Para 37 specifies enhanced RMCB monitoring. These models carry a more frequent review cadence and additional reporting obligations. Tracking drift continuously against the material change threshold is directly relevant to how the RMCB exercises oversight of this model category.

The compliance case and the business case point to the same number

A lending model carrying undetected geographic or demographic bias declines applications from borrowers who would have repaid. The revenue from those declined loans does not appear in any report. The borrowers move to a competitor. The portfolio’s concentration risk increases as approvals skew toward a narrower slice of the eligible market. The loss is real and accumulating, but it does not register until a fairness assessment surfaces it.

A collections model experiencing data drift routes accounts to recovery strategies calibrated to a borrower profile that no longer matches the current portfolio. Recovery rates fall. Cost-to-collect rises. The degradation is typically attributed to macro conditions or portfolio quality, not to the model. The model continues running. The gap compounds.

Para 54(3) and Para 54(7) create the compliance obligation to find these problems. The business case for finding them exists independently. A monitoring programme that satisfies the RBI requirement also produces the information needed to stop the revenue leak and the recovery rate deterioration. The two objectives do not require separate programmes. They require one programme built to cover both failure modes.

Where iTuring.ai fits in the ongoing monitoring requirement

iTuring.ai MRM runs simultaneous three-layer drift analysis across model, feature, and data dimensions. The Model Relevancy Score detects degradation patterns before headline performance metrics move. Investigations that typically require three weeks of manual analysis complete in 30 minutes.

The monitoring parameters are comprehensive 

Model drift is tracked across AUC, Precision, F1, Recall, PSI, CSI, and EMD. Feature drift is measured through Fisher Score for numerical variables and Information Value for categorical ones. Data drift monitoring covers distribution changes, missingness patterns, skewness, variance, mean, and standard deviation across the full input set.

Every investigation action is automatically time-stamped and documented 

When drift approaches the material change threshold, the audit trail for RMCB reporting and re-validation documentation is already in place. Institutions are not reconstructing evidence after the fact. The documentation exists as a by-product of the monitoring operation rather than as a pre-examination project.

iTuring.ai MRM monitors models regardless of where they were built 

This includes models developed within the iTuring environment, models deployed through Python, R, SAS, PyTorch, or Spark, and third-party models from external platforms. Para 37’s requirement for ongoing monitoring applies to the full portfolio. The monitoring programme needs to match that scope.

When RBI’s guidance moves from draft to final circular, the difference between institutions that are ready and those that are not will largely come down to whether monitoring was operational before the examination. A programme that begins after the final circular is issued will carry a gap in its drift history. 

A programme already running will have the baseline data that demonstrates the model was fit for use throughout the period before the guidance came into force.

If the question is how confident you are that every model in production is still making decisions consistent with what your board approved, the honest answer requires a monitoring programme, not an assumption.

Every batch of new data an AI model processes is a potential source of drift, bias shift, or concept change. This is not a compliance problem that appears periodically. It is a property of how AI models behave in production. 

RBI’s requirements in Para 54(7) and Para 56 are not arbitrary obligations layered on top of an otherwise stable system. They are a regulatory description of a dynamic that was already present. The institutions that will carry the least examination risk are not the ones that build a compliance programme in response to the final circular. 

They are the ones that build monitoring into their model operations so that compliance is a by-product of how they run their models every day, not a project they stand up when a mandate arrives.

iTuring MRM monitors 1,000+ models for drift and bias, with complete audit documentation for RBI compliance.