Demystifying RBI's Model Risk Management Framework: A Compliance Guide for Banks and NBFCs

INTRODUCTION

Context and the Compliance Challenge

Machine learning has moved from experimentation to production across nearly every function in lending institutions. Credit underwriting, fraud detection, collections prioritization, and portfolio monitoring now routinely run on predictive models rather than static rulebooks. A mid-sized NBFC might run a bureau-based credit score, a fraud flag model, a collections propensity model, a cross-sell model, and several regional variants of each, all live at once.

As the number of production models climbs into the hundreds across an institution’s business lines, the regulatory conversation has shifted. RBI is no longer asking whether AI is used in credit decisions. It is asking how that AI is governed, validated, and controlled. This shift became concrete on June 24, 2026, when RBI released its draft “Guidance on Regulatory Principles for Model Risk Management, 2026,” a framework that applies to nearly every entity RBI regulates.

The draft guidance requires institutions to demonstrate six things in a way that can withstand an audit or a supervisory review:

Complete model governance, anchored by a Board-approved framework
Independent validation of every model before and after deployment
Explainability, so that decisions can be justified to customers, auditors, and regulators
Auditability, meaning every decision can be traced back to a specific model version
Lifecycle monitoring that continues long after a model goes live
Documented decision trails covering approvals, changes, and overrides

The problem is that most institutions are trying to meet these expectations with tools that were never built for this purpose. Model inventories live in spreadsheets that different teams update inconsistently. Validation reports arrive as static Word documents. Approval records sit in email threads. Feature lists and training data descriptions exist only in the memory of the data scientist who built the model, and that person may have since left the organization. This patchwork makes audits slow, makes regulatory responses expensive, and leaves real gaps that a supervisor can find in a single sample check.

Why RBI’s Model Risk Management Framework Matters

The Shift from Scorecards to Machine Learning

For years, Indian lenders relied on traditional scorecards: linear models built on a handful of bureau variables, reviewed once a year, and easy for a risk committee to understand at a glance. That world is disappearing. ML-driven decision engines trained on hundreds of features, including alternative data like utility payments, app usage, and transaction patterns, now sit inside underwriting, fraud, and collections workflows.

This shift brings real advantages in accuracy and reach, especially for thin-file and new-to-credit borrowers. But it also introduces risks that traditional governance structures were never designed to catch:

Biased or discriminatory outcomes, where a model systematically disadvantages a demographic group without anyone noticing until a complaint or an audit surfaces it
Model drift, where a model’s predictive accuracy degrades quietly as borrower behavior, macroeconomic conditions, or the applicant pool itself changes over time
Undocumented model changes, where a data scientist retrains or tweaks a model without a formal change record, leaving no trail for anyone to reconstruct later
Regulatory scrutiny, since RBI has proposed Board-level accountability and direct Risk Management Committee of the Board oversight for high-risk models
Lack of accountability, particularly for models sourced from third-party vendors, where RBI has made clear that outsourcing the model does not outsource the risk

The Real Cost of Poor Model Governance

Weak model governance shows up as measurable financial and reputational cost.

RBI’s recent enforcement history illustrates the pattern. In FY 2025-26, RBI issued penalties against multiple NBFCs and cooperative banks for lending and exposure-related non-compliance, with the majority of NBFC penalties falling below Rs 5 lakh but a meaningful share running higher for repeated or more serious violations. As RBI’s Model Risk Management guidance moves from draft to final, model-specific governance failures are likely to become their own category of enforcement action, separate from the general lending violations seen today.

Beyond direct penalties, institutions face several other costs:

Audit observations that consume weeks of management time to remediate and that damage credibility with the Board and with regulators
Incorrect lending decisions driven by an undetected biased or drifted model, which can mean both wrongful declines that cost revenue and wrongful approvals that increase losses
Reputational risk, since a public regulatory action or a customer complaint about unfair credit decisions travels fast and is hard to undo
Higher non-performing assets, when a collections or underwriting model degrades silently and nobody catches it until delinquency numbers climb

The chart above shows the kind of performance bands risk teams typically monitor. When a model’s KS Score, Gini Index, or ROC-AUC drifts from the healthy range into the caution or weak zone, and nobody is watching, the NPA impact shows up months later, by which point the damage is already in the portfolio.

RBI’s FY 2025-26 enforcement data shows most NBFC penalties stayed under Rs 5 lakh, but a smaller share of repeat or serious violations crossed higher bands.

1. Understanding RBI’s Model Risk Management Framework

What Counts as a Model

RBI defines “model” broadly. Under the draft guidance, a model is any system, method, or approach that applies quantitative or qualitative processing logic to inputs and produces outputs that materially influence a business decision. This includes traditional statistical scorecards, machine learning and deep learning systems, generative AI tools, and, notably, spreadsheets that drive a lending or pricing decision. Many institutions will discover, once they map their operations against this definition, that they are running far more “models” than their current inventory shows, including tools built by business teams outside the formal data science function.

Why RBI Introduced Model Risk Governance

RBI’s move follows two parallel tracks. First, the FREE-AI Committee report, released in August 2025, set out a broader vision for responsible AI in finance built around seven guiding principles, or “sutras”: Trust is the Foundation, People First, Innovation over Restraint, Fairness and Equity, Accountability, Understandable by Design, and Safety, Resilience and Sustainability. That report also proposed 26 recommendations across six pillars, including infrastructure, policy, capacity, governance, protection, and assurance.

Second, the draft Model Risk Management guidance translates those principles into specific, auditable requirements. It builds on an earlier draft that RBI circulated in August 2024 focused narrowly on credit models, and expands the scope to cover generative AI, foundational models, frontier models, and third-party models across nearly every category of regulated entity.

Which Institutions Are Affected

The draft guidance applies to commercial banks, small finance banks, payment banks, regional rural banks, cooperative banks, NBFCs across all four layers of RBI’s scale-based regulation, All-India Financial Institutions, asset reconstruction companies, and credit information companies. In practice, this means almost every entity RBI regulates that uses a model, in any form, to make or influence a decision that affects a customer or the institution’s risk exposure.

Governance Expectations

At the center of the framework is a requirement for a Board-approved Model Risk Management Framework, or MRMF. This document must define governance roles, a risk-tiering methodology, inventory requirements, validation standards, approval workflows, deployment controls, monitoring cadence, change management procedures, and a decommissioning process.

RBI has also proposed a three-lines-of-defence structure that assigns clear ownership at each level:

First line: model owners and business teams who develop and use models day to day
Second line: an independent model risk management and validation function that tests and challenges models before and after deployment
Third line: internal audit, which periodically reviews the entire governance process itself, not just individual models

The Risk Management Committee of the Board sits above all three lines, with direct oversight of high-risk, third-party, and AI-driven models.

Risk Categories and Annual Validation Requirements

Not every model carries the same weight. RBI’s draft guidance expects institutions to tier models by materiality and complexity, and to scale governance intensity accordingly. A high-risk model, such as one that drives automated credit decisions for a large portfolio, needs RMCB-level approval, more frequent validation, and tighter monitoring. A lower-risk model, such as an internal reporting tool, can follow a lighter, delegated approval path.

Annual, independent revalidation is expected for models in active use, and this validation must be documented in a way that the RMCB, internal audit, and RBI examiners can all review. Vendor-supplied and third-party models are not exempt. RBI has stated plainly that independent validation is required regardless of any certification or assurance a vendor provides.

Documentation Expectations

Documentation under the new framework is not a one-time artifact. RBI expects institutions to retain model records, including inventory entries, validation reports, approval history, and monitoring records, for at least 10 years. That retention period alone rules out ad hoc spreadsheet tracking as a viable long-term solution, since spreadsheets get overwritten, lost, or simply abandoned when the person maintaining them changes roles.

The Five Stages of the Model Lifecycle

RBI’s framework treats model governance as a continuous cycle with five distinct stages, each with its own owner and its own documentation requirements.

Stage	What Happens	Who Owns It	Key Output
Model Development	Data selection, feature engineering, and model build against a defined business purpose	First line (model owner/business team)	Model specification and training documentation
Model Validation	Independent testing of accuracy, stability, and bias before go-live	Second line (independent validation function)	Validation report with pass/fail recommendation
Model Approval	Sign-off based on risk tier; high-risk models go to the RMCB	RMCB or delegated authority	Approval record with conditions, if any
Model Monitoring	Ongoing tracking of performance, drift, and fairness after deployment	Second line, reported to RMCB	Periodic monitoring report and alerts
Model Retirement	Formal decommissioning with records retained for 10+ years	Model owner and governance team	Retirement record and archived documentation

A common point of confusion is treating “approval” and “validation” as the same step. They are not. Validation is the independent, technical assessment of whether a model works as intended and behaves fairly. Approval is the governance decision, made by an authority appropriate to the model’s risk tier, to allow the validated model into production. Skipping straight from development to approval, without a documented and independent validation step in between, is exactly the kind of gap RBI’s guidance is designed to close.

2. Why Traditional Model Governance Fails

Most institutions did not choose spreadsheet-based model governance. It accumulated over time, as teams added models faster than their governance processes could keep up. The result is a set of predictable failure points that show up in almost every institution that has not yet modernized its approach.

The Excel-Based Model Inventory Problem

An Excel-based model inventory looks manageable when an institution has five or ten models. It breaks down completely once that number reaches fifty or a hundred, which is common even for a mid-sized NBFC running separate models across products, regions, and vintages. Rows go stale the moment someone retrains a model without updating the sheet. Different teams keep their own versions, and nobody can say with confidence which one is current.

Version Confusion

When multiple teams or analysts retrain the same underlying model, version confusion follows almost immediately. Without a system that automatically tracks version and rollback history, an institution can end up with a production model that nobody can definitively map back to the training run, dataset, and feature set that produced it. If a regulator asks “which model version made this decision on this date,” and the answer requires reconstructing the sequence of emails and shared folders, that is a governance failure regardless of how good the underlying model actually is.

Missing Approval Records

Approval records scattered across email threads, chat messages, and meeting notes create the same problem from a different angle. RBI’s framework expects a clean, retrievable record showing who approved a model, at what risk tier, on what date, and under what conditions. A missing or incomplete approval record is one of the fastest ways to turn a routine audit into an adverse finding.

No Feature Lineage

Feature lineage, the ability to trace exactly which data fields and transformations fed into a specific model version, is often the weakest link in manual governance. Without it, an institution cannot answer a basic explainability question: which pieces of data actually drove this decision? That gap becomes acute the moment a customer disputes a decision or a regulator asks for the reasoning behind a declined loan application.

Static Documentation

Documentation written once, at model launch, and never revisited afterward, quickly diverges from reality. A model’s actual behavior in production, including any threshold adjustments or retraining events, needs to be reflected in living documentation, not a PDF that was accurate on the day it was written and stale ever since.

Manual Validation Reports

Manual validation reports, built by an analyst pulling metrics into a Word document or PowerPoint deck, take days or weeks to compile for each model. When an institution runs a hundred models and needs annual revalidation on all of them, that manual process alone can consume a disproportionate share of the risk team’s capacity, capacity that should be going toward actually improving model quality.

Independent Validator Dependency

Many institutions respond to the demand for independent validation by hiring external consultants for every review cycle. This is expensive, slow, and creates a bottleneck, since external validators need to be scheduled, briefed, and given time to understand each model before they can produce a useful report. It also does not scale as the number of models grows.

No Audit Trail

The cumulative effect of all these gaps is the absence of a coherent audit trail. When a supervisor asks an institution to reconstruct the full history of a specific model, including who built it, who validated it, who approved it, when it was last monitored, and what changed along the way, a spreadsheet-and-email-based process usually cannot produce a complete answer within a reasonable timeframe. That inability, more than any single technical flaw in a model, is what turns an examination into an enforcement risk.

The comparison above reflects a pattern seen consistently across institutions moving from ad hoc tracking to governed platforms: audit preparation time, validation independence, and drift detection speed all improve sharply once governance runs through a single connected system rather than scattered files.

3. Building an Audit-Ready Model Inventory

Why the Model Inventory Is the Centerpiece

Of everything covered in this guide, the model inventory deserves the most attention, because it is the single artifact regulators will ask for first. RBI’s draft guidance is explicit that no model may be used in production unless it appears in the inventory. A complete, current, and centralized inventory is also the foundation that makes every other governance requirement, from validation scheduling to monitoring alerts to audit response, actually workable.

What Every Institution Should Maintain

A properly structured model inventory needs to capture enough detail that any authorized reviewer, whether internal audit, the RMCB, or an RBI examiner, can understand a model’s full history without needing to track down the original developer. At minimum, each entry should include:

Model name, so entries are consistently identifiable across teams
Owner, the individual or team accountable for the model’s ongoing performance
Business purpose, describing exactly what decision the model supports
Training dataset, identifying the data used to build the model
Features used, listing every input variable that feeds the model
Version history, tracking every retrain or update event
Validation status, showing whether the current version has passed independent review
Approval date, recording when governance sign-off occurred
Cutoff history, capturing every change to the decision threshold
Performance metrics, the latest KS, Gini, ROC-AUC, and similar figures
Last monitoring date, showing when the model was most recently checked
Reviewer, identifying who conducted the most recent validation or monitoring review
Expiry date, flagging when the model is due for revalidation or retirement

Why Regulators Expect Centralized Visibility

RBI’s supervisory approach increasingly assumes that an institution can produce, on request, a single consolidated view of every production model and its governance status. This expectation reflects a broader pattern across financial regulation globally: supervisors want a system of record, not a collection of documents that need to be reconciled manually before they can be trusted. An inventory that lives inside the same platform where models are actually built, tested, and deployed avoids the reconciliation problem entirely, because the inventory reflects the live state of the system rather than a snapshot someone updated last quarter.

Fintly’s ML ScoreEngine builds this inventory automatically as part of the model training workflow. Every model that gets trained on the platform carries its dataset statistics, feature list, version and rollback history, cutoff calculation history, and performance metrics as inherent properties of the model record, not as a separate document that someone has to remember to update.

Because model listing, status visibility, and detailed views are native features of the platform, business users and risk teams see the same current picture at all times, with sorting and filtering available to manage inventories that span dozens or hundreds of models.

4. Model Explainability: Beyond Black-Box AI

Why Explainability Matters

Explainability is not a nice-to-have feature layered on top of a model. Under RBI’s emerging expectations, it is a core control, especially for models that materially affect a customer, like a credit approval or decline.

A model that cannot explain itself has to be offset with heavier validation, tighter output monitoring, and narrower usage limits, which is a more expensive and more constrained way to operate than building explainability in from the start.

Explainability serves several distinct audiences, each with different needs:

Feature importance shows, at a model level, which input variables carry the most weight in driving outcomes overall
Reason codes explain, at an individual decision level, exactly why a specific customer received a specific outcome
Decision transparency means the logic behind an outcome can be reconstructed and reviewed after the fact, not just at the moment the decision was made
Customer explainability means a lender can tell a declined applicant, in plain language, what factors contributed to that decision
Internal governance benefits when risk committees can understand and challenge model logic without needing a data science degree
Regulatory confidence grows when examiners can see a documented, consistent basis for automated decisions rather than an opaque score with no supporting rationale

How This Plays Out in Practice

Consider a borrower declined for a personal loan by an ML-driven underwriting model. Under RBI’s expectations, the institution needs to be able to show, on demand, which factors, such as recent bureau enquiries, income volatility, or existing exposure, drove that specific decision, and needs that explanation to be consistent with the model’s documented logic rather than reverse-engineered after the fact.

Fintly’s ML ScoreEngine generates feature importance at the model level and reason codes at the individual decision level automatically, as part of the standard scoring output, not as a separate add-on project. This applies across both single-case scoring and bulk portfolio scoring, so a batch of ten thousand collections scores carries the same audit-ready reason codes as a single real-time credit decision. Because these explanations are generated by the platform at the point of scoring, they form a natural, continuous audit-ready decision log rather than something a team has to reconstruct later under audit pressure.

5. Continuous Monitoring and Performance Governance

Governance Does Not Stop at Deployment

One of the most consistent gaps in traditional model governance is treating approval as the finish line. RBI’s draft guidance makes clear that governance is a continuous obligation: institutions must monitor deployed models for data drift and concept drift on an ongoing basis, not just at the point of initial validation.

The Core Monitoring Metrics

Risk teams in Indian lending institutions rely on a well-established set of metrics to track model health over time.

KS Score (Kolmogorov-Smirnov statistic) measures how well a model separates good accounts from bad accounts; a healthy model typically holds a KS score well above the caution threshold, and a falling KS score over time is an early warning sign
Gini Index summarizes overall discriminatory power in a single number, and is widely used because risk committees are already familiar with it from traditional scorecard governance
ROC-AUC (Receiver Operating Characteristic – Area Under Curve) gives a complementary view of predictive power, particularly useful when comparing model versions against each other
Population Stability Index (PSI) flags when the population currently being scored has drifted meaningfully from the population the model was originally trained on, which is often the earliest signal that a model’s assumptions are becoming outdated
Drift detection more broadly covers both data drift, where the input data distribution shifts, and concept drift, where the underlying relationship between inputs and outcomes changes
Performance degradation tracking watches whether accuracy, approval rates, or bad-rate outcomes are trending in the wrong direction over consecutive monitoring cycles
Threshold review and cutoff optimization determine when a decision cutoff itself, rather than the underlying model, needs adjustment to keep approval and decline rates aligned with business and risk targets

Review Cadence: Quarterly, Annual, and Beyond

A well-run monitoring program typically layers three review cadences. Quarterly reviews catch emerging drift early, before it becomes severe enough to show up in delinquency numbers months later. Annual independent validation, aligned with RBI’s expectation of periodic revalidation, provides a deeper, more formal reassessment of whether a model remains fit for purpose. Beyond these scheduled reviews, institutions need a trigger-based process: if monitoring detects a sharp drop in KS score or a spike in PSI between scheduled reviews, that should automatically prompt an off-cycle validation rather than waiting for the next quarterly checkpoint.

Model Retirement and Rebuilding

Not every model degradation calls for a full rebuild. Sometimes a threshold adjustment, recalibrating the cutoff to reflect a shifted population, is enough to restore acceptable performance. Other times, drift has moved far enough that the underlying model itself needs retraining on more recent data, or in the most severe cases, retirement and replacement with a newly built model. RBI’s guidance expects institutions to document this decision process just as carefully as the original approval, including the rationale for why a model was retired and how the transition to its replacement was managed.

Fintly’s ML ScoreEngine tracks KS Score, Gini Index, and ROC-AUC continuously,

alongside class distribution charts and anomaly and cluster analysis that surface unusual patterns before they show up as a full-blown drift event. The platform’s dynamic cutoff slider lets risk teams simulate the impact of a threshold change in real time and see the recalculated approval and decline distribution immediately, with every recalculation logged for audit purposes. When a model does need retraining, integrated rebuild options, including standard 70/30 and 90/10 retraining splits, let a team correct a drifting model directly inside the platform rather than restarting the entire development process from scratch.

Conclusion: Bringing It Together in a Governed AI Lifecycle

RBI compliance is not something an institution achieves by writing better policy documents. It requires a genuinely governed AI lifecycle, one where the model inventory, independent validation, explainability, continuous monitoring, and audit-ready records all operate as a connected system rather than five separate initiatives run by five separate teams.

The institutions that will find this transition easiest are the ones that stop treating model governance as a documentation exercise layered on top of model development, and start treating it as a property of the platform the models run on. When the inventory updates itself as models are trained, when explainability is generated automatically at the point of every decision, and when monitoring metrics are tracked continuously rather than recompiled manually each quarter, audit readiness becomes a byproduct of normal operations rather than a separate, disruptive project every time a regulator comes calling.

Fintly’s ML ScoreEngine was built around this principle. It combines no-code model development, performance analytics, version control, audit history, and deployment-ready APIs in one environment, so banks and NBFCs can move from reactive, scramble-before-the-audit compliance to proactive, continuous AI governance. That shift also reduces dependence on external validation teams for routine reviews, since the platform’s built-in analytics and explainability give internal second-line teams what they need to validate models directly, reserving external expertise for the cases that genuinely require it.

Book a personalized demo to see how Fintly’s ML ScoreEngine can help your institution operationalize RBI-aligned model governance, simplify audits, and accelerate compliant AI decision-making.