On June 24, 2026, the Reserve Bank of India released a draft titled "Guidance on Regulatory Principles for Model Risk Management, 2026." It is open for public feedback until July 24, 2026. Because it is still a draft, it is not yet law — institutions should treat it as proposed guidance for now, not a final rule. Once finalized, it will replace the RBI's existing 2002 guidance on credit risk models, which has been the reference point for model governance in Indian banking for over two decades.
‍

The draft applies to a wide range of regulated entities: commercial banks, small finance banks, payments banks, cooperative banks, NBFCs (across all layers), All-India Financial Institutions, Asset Reconstruction Companies, and Credit Information Companies. In short, if an institution is regulated by the RBI and uses models to make decisions, this guidance will likely apply to it.
‍

What Counts as a "Model"
‍

The RBI has defined "model" broadly. It isn't limited to AI or machine learning systems. It covers any system including scoring algorithms, rule engines, pricing calculators, and even spreadsheet-based tools if its output materially influences a business decision, such as a lending rate, credit approval, or pricing outcome. For NBFCs, this means fraud scorecards, collections prioritization logic, pre-approved offer rules, and pricing sheets could all fall within scope, not just AI-based underwriting engines.
‍

Board-Level Accountability
‍

Every regulated entity is expected to put in place a Model Risk Management Framework (MRMF), approved by its Board of Directors. This shifts model governance from being a technical, back-office matter into a boardroom responsibility. The Board is expected to:
‍

· Approve the MRMF and review it periodically.

· Set the institution's risk appetite for model-related risk.

· Oversee implementation, typically through its Risk Management Committee (RMCB).

· Approve the deployment of any model classified as "high-risk."
‍

Three Lines of Defense
‍

The draft asks institutions to structure model governance using a three-lines-of-defense model, a structure already familiar in financial risk management:
‍

1. First line — Model owners and developers: the teams responsible for designing, building, and running day-to-day monitoring of a model.

2. Second line — Independent model validation: a function separate from the development team that independently tests and challenges each model before and after deployment.

3. Third line — Internal audit: provides independent assurance to the Board that the first two lines are actually functioning as intended.
‍

Risk-Based Tiering
‍

Not every model carries the same level of risk, so the draft asks institutions to classify each model into a risk tier  typically high, medium, or low  based on factors such as materiality, complexity, impact on customers, explainability, and regulatory significance.

Higher-risk models, such as those used in credit underwriting, require more rigorous validation, closer monitoring, and Board Risk Committee approval. Risk classifications should be reviewed at least once a year, or whenever a significant change is made to the model.
‍

The Model Inventory
‍

A central requirement is that every institution maintain a complete inventory of every model it uses  active, inactive, under development, or already retired. No model can be deployed unless it is formally recorded in this inventory. The inventory is expected to capture, at minimum: the model owner, developer, validator, approver, risk classification, intended use, dependencies, validation findings, and monitoring history.

Even after a model is retired, records must be kept  the draft proposes a minimum retention period of ten years for decommissioned models, to preserve a clear audit trail.

Managing the Model Lifecycle
‍

The draft lays out expectations across the full lifecycle of a model:
‍

1. Before building or buying a model: Institutions should document why the model  is needed, what it's intended to do, and weigh its expected benefits against risks including fairness and bias considerations.
2. During development: tructured processes should govern data collection, model design, testing, and refinement.
3. Before deployment: Every model including third-party models must undergo independent validation. This validation must also be repeated periodically and after any significant changes.
4. Change  management: Any modification to an existing model should follow a formal process, with version control and revalidation.
5. Business continuity: Institutions must have fallback plans such as manual  processes or backup models for situations where a model becomes unavailable or starts performing poorly.
6. Decommissioning: When a model is retired, it must be formally closed out, with records preserved in the inventory.
   ‍

Third-Party and Vendor Models
‍

A key message in the draft is that outsourcing a model doesnot outsource responsibility. If an NBFC uses a model built by a fintech partner, vendor, or Co-Lending partner, the NBFC remains fully accountable for its outcomes.

To meet this obligation, institutions are expected to:
‍

1. Conduct due diligence on the vendor and the model before adoption.
2. Secure contractual rights to technical documentation and audit access.
3. Independently validate the model themselves vendor certification alone is not sufficient.
4. Continuously monitor the model's performance after deployment.
   ‍

Specific Safeguards for AI and Machine Learning
‍

Because AI systems carry risks that traditional models don't— such as hallucinations, unpredictable outputs, and difficulty explaining decisions — the draft introduces additional requirements specifically for AI/ML:
‍

• Human  oversight is mandatory Institutions must ensure a human is meaningfully involved in AI-driven decisions, especially significant ones like loan approvals, through "human-in-the-loop" or "human-on-the-loop" arrangements.
  ‍
• Override and kill-switch capability Institutions must be able to override an AI model's decision, and must have a "kill switch"  a mechanism to immediately suspend or shut down a model that is behaving erratically or producing harmful outputs.
  ‍
• Explainability For material decisions like credit underwriting, institutions must apply stricter standards of explainability. Where a model's reasoning cannot be fully explained (a "black box" model), the institution must apply compensating controls, such as enhanced validation and usage restrictions.
  ‍
• Fairness and bias testing Institutions must proactively test AI models for discriminatory outcomes and recalibrate or redesign them if bias is found.
  ‍
• AI-specific risk assessment This includes testing for data drift, spurious correlations, and vulnerabilities like adversarial inputs often through structured stress testing or "red-teaming."
  ‍
• Custom transparency When customers interact with AI directly such as through a chat-bot institutions must disclose that they are speaking with an AI, explain its limitations, and offer an easy way to reach a human instead.
  ‍

What This Means, in Plain Terms?
‍

For NBFCs, MFIs, and HFCs, the takeaway is simple: any system that materially shapes a lending decision whether it's a machine learning model or a spreadsheet now needs a named owner, a documented purpose, independent validation, ongoing monitoring, and a way to be shut off if something goes wrong.

Vendor-supplied tools don't get a pass either, the institution using them stays accountable. And wherever AI interacts directly with a customer or drives a material decision, a human needs to remain meaningfully in the loop.
‍

A Note on Technology Readiness
‍

For lenders assessing how ready their technology stack isfor this shift, the relevant question is whether their platform can already support model inventory tracking, explainable decisioning, human over ride workflows, and audit-ready logs — or whether governance will need to be added on separately.

Platforms like AllCloud's Unified Lending Technology stack,which brings origination, servicing, collections, and co-lending together on asingle architecture, are built with this kind of consistency in mind, since governance is easier to apply uniformly when data and workflows aren't scattered across disconnected systems.