Prepared by Shubhank Suman, AI, Privacy and IP Counsel
I have been reading a lot of misleading posts claiming that the “RBI HAS BANNED AI”. That is not an accurate reading of the draft Guidance. Further, I have also come across the argument that the RBI’s proposed checks on AI go against the principle of “INNOVATION OVER RESTRAINT” introduced by MeitY’s AI Governance Guidelines. I do not think that reading is correct either.
In light of this, I have analyzed the Reserve Bank’s draft Guidance on Regulatory Principles for Model Risk Management, 2026, and mapped it against one key question: whether it supports or contradicts the principles of the MeitY India AI Governance Guidelines of 5 November 2025.
It is important to note at the outset that the RBI Guidance is still a draft issued for public consultation. Once finalized, the Guidance will supersede Chapter 3 on Credit Risk Models of the 2002 Guidance Note on Credit Risk Management.
What This Note Covers
- RBI has not banned AI: The draft Guidance permits AI and ML models where risks can be properly identified, measured, monitored, and managed.
- The wide meaning of “model”: Calculators, spreadsheets, scripts, chatbots, scorecards, and AI tools may all be models if their outputs influence business or operational decisions.
- Accountability stays with the entity: Banks and financial institutions remain responsible for model outcomes, even when the model is bought from a vendor or used through a third-party service.
- The key AI controls: Explainability, bias testing, hallucination safeguards, human oversight, kill switches, prompt-injection protection, customer disclosure, monitoring, and grievance redressal.
- MeitY alignment: The RBI draft does not contradict the MeitY AI Governance Guidelines; it turns those principles into sector-specific obligations for the financial sector.
The One Definition That Drives The Whole Framework
Regulated entities now run much of their business on models, and every model carries model risk: the risk that a poorly built, poorly fed, or poorly used model produces wrong outputs and flawed decisions. The Guidance answers this with a single discipline that applies to all models, whether built in house, bought from a third party, or a mix of the two, and to almost every Reserve Bank regulated lender and financial institution, applied in proportion to scale, complexity, and materiality.
The most consequential feature is the definition of model. A model is any system with an input, a processing logic, and an output that feeds a business or operational decision, and the processing expressly includes AI and ML. The decisive words are that a tool is a model irrespective of whether the entity itself recognises it as a model. Substance governs, not the label. An entity cannot escape the framework by calling something a calculator, a sheet, a script, or a utility.
1. What Counts As A Model
The framework turns on one wide definition: any system that takes inputs, applies a processing logic, and produces an output used in a decision is a model, even if the entity does not call it one. Substance governs, not the label, so the first task is to find every such tool. Shadow models are not allowed.
Everyday tool | Why it is a model |
|---|---|
Spreadsheet loan pricing calculator | Takes borrower type, tenor, score, and collateral, applies rate grids and margins, and outputs the lending rate the bank charges. |
Fraud or AML rules engine | Scores transactions and decides which to block or flag, shaping customer and risk outcomes. |
Credit scorecard or decisioning model | Converts applicant data into an approve or decline decision. |
Customer or generative AI chatbot | Produces answers and guidance that influence customer decisions and the bank's conduct. |
Illustration. The Reserve Bank's own example: a spreadsheet that merely does arithmetic is a basic tool, but the moment it takes borrower data, applies rate grids and margin formulas, and produces the lending rate the bank actually charges, it is a model and must be governed as one.
2. Accountability Cannot Be Outsourced
The governance chapter rests on one rule: the entity is accountable for the outcomes of all models it uses, including those bought in. Accountability does not move to the vendor on purchase or to the IT team on deployment; it stays with the entity and, through it, with the Board. Each entity must therefore put in place a Board approved Model Risk Management Framework (MRMF) covering taxonomy, governance, tiering, the full lifecycle, and documentation.
The roles are clearly split. The Board approves and reviews the MRMF, the risk appetite for model risk, and the tiering policy. The Risk Management Committee of the Board (RMCB) oversees implementation, approves the deployment of high risk models, oversees all models approved with exceptions, all third party models, and all models involving AI, and reviews breaches. Senior management operationalizes the framework, maintains the inventory, and reports up. Beneath them sit the three lines of defense: model owners, an independent validation function, and internal audit.
Independence is the operative word, because the people who validate and audit a model must not be the people who built or use it.
Who | Responsibility |
|---|---|
Board | Approves and reviews the MRMF, the risk appetite for model risk, and the tiering policy. |
RMCB | Oversees implementation, approves high risk model deployment, oversees all exception, third party, and AI models, and reviews breaches. |
Senior management | Builds the processes, maintains the inventory, and reports to the RMCB. |
Three lines of defence | Model owners build, an independent function validates, and internal audit checks; validators and auditors must not be the people who build or use the model. |
3. Tiering, Inventory, And Consumer Protection
Every model must be classified into a risk tier and reviewed at least annually. The tier is not a label; it decides validation intensity, the approval route (high risk models go to the RMCB), the controls, the depth of monitoring, and the documentation. Tiering turns on materiality, complexity, and regulatory factors, with an important anti gaming rule: a low complexity score must not be used to dilute the tier of a highly material model. The tier must reflect composite risk, so a simple but business critical model still ranks high.
Aspect | Rule in short | Practical effect |
|---|---|---|
Risk tiering | Classify every model by risk and review at least yearly; the tier sets validation depth, approval route, and controls. | High risk models need RMCB approval and intensive validation; lower risk ones may follow delegated approval. |
Composite risk | Low complexity must not dilute the tier of a highly material model. | A simple but flagship retail loan eligibility model still ranks high risk. |
Inventory rule | Keep a complete inventory of all models; no model may be used unless it is in the inventory. | A tool built quietly in a business unit cannot go live until it is registered, tiered, and validated. |
Retention | Keep decommissioned models and their documentation for at least ten years. | A 2026 lending decision must be reconstructable until at least 2036 if challenged. |
Consumer protection | Do not use models that harm consumers; grievance redressal must cover model driven decisions. | A customer repeatedly auto declined can raise a grievance the bank must examine. |
Illustration. A simple, rules based model that decides eligibility for a flagship retail loan is low in complexity but very high in materiality. The entity may not average these into a comfortable middle tier; the composite risk is high, and the model attracts RMCB approval and intensive validation.
The inventory rule is equally firm. An entity must keep a complete and current inventory of all active, inactive, and decommissioned models, and no model may be used or deployed unless it is in the inventory. Decommissioned models, with their documentation, must be retained for at least ten years, so that a decision made years earlier can still be reconstructed if a customer, a court, or the supervisor questions it. Finally, the Guidance bars any model that harms the consumer and requires the grievance mechanism to handle complaints arising from model driven decisions, tying model governance directly to fair conduct.
4. The Lifecycle
The Guidance attaches obligations to each stage of a model's life. Two themes run through them: validation is continuous rather than a one time gate, and a material change is treated as effectively a new model that must be revalidated and reapproved.
Stage | Core obligation |
|---|---|
Selection and development | Document rationale, scope, and a cost benefit view that expressly weighs fairness, ethics, and bias; develop through a structured process on governed data. |
Validation | Independent validation of all models, including third party models, before and after deployment, on change, on triggers, and periodically, reported to the RMCB within three months. |
Approval | A defined approval and exception structure with authorities, thresholds, remediation timelines, and a documented rationale for every decision. |
Deployment and monitoring | Deploy with IT and data functions, confirm stable and replicable outputs, monitor continuously, and place models approved with exceptions under enhanced RMCB monitoring. |
Change management | A controlled change process with a documented impact assessment, a full version log, and a defined materiality threshold that re triggers validation and approval. |
Continuity and decommissioning | Model continuity folded into business continuity planning, with fallback options, and timely notice to stakeholders on retirement. |
5. Third Party Models: Bought In, But Still Your Risk
Because many entities license models rather than build them, the Guidance is direct: an entity that acquires or relies on a third party model is accountable for its outcomes. The MRMF applies to such models with the necessary adjustments, and two extra duties attach. The entity must validate the model itself, regardless of any vendor certification, and must place it under enhanced RMCB oversight whatever its tier. Before acquisition it must run due diligence on the provider, the model, and the data, and the contract must secure access to technical documentation, audit rights for the entity and the supervisor, and orderly exit and continuity terms.
Illustration. A non banking financial company that calls a vendor's model or a large language model to assist lending cannot rest on the vendor's assurance: it must validate the model, place it under RMCB oversight, and ensure the contract gives it documentation, audit rights extending to the Reserve Bank, and an exit. Vendors who cannot offer these terms will struggle to onboard regulated buyers.
6. AI And ML Models: The Operative Core
The AI and ML chapter keeps everything above and adds a dense layer of controls that recognise what makes these models different: opacity, autonomy, data hunger, and the ability to generate content. An AI model may be deployed only in use cases where the entity can actually identify, measure, monitor, and manage the risk, and tiering must add two factors, the degree of reliance on the model's outputs and the model's autonomy in deciding. The principal controls are below.
AI risk | Control in short | Practical illustration |
|---|---|---|
Explainability | Set thresholds, higher for material decisions; if not explainable, add corroboration, frequent review, and usage limits. | A black box credit model can run only inside heavier controls. |
Hallucination | Build guardrails for generative models and any output reaching customers. | A chatbot must not invent product terms or rates. |
Bias and fairness | Test for discriminatory outputs and remediate by recalibration or redesign. | Check that a group of customers is not being unfairly declined. |
Reliability | Prevent overfitting, spurious correlations, and unexplained output swings; test out of sample. | A model that shines only on training data is not fit to deploy. |
Data and IP | Manage data quality and intellectual property rights in training data; monitor data and concept drift. | Confirm rights to use training data and watch for drift over time. |
Concentration and auto updates | Weigh reliance on a few providers; control models that update automatically. | A silent vendor update can change behaviour, so monitor and limit it. |
Customer facing duties | Defend against prompt injection, disclose AI use and limits, and offer a human option. | Tell users they are talking to an AI and let them reach a person. |
Human oversight | Keep a human in command, with override and kill switch, and periodic human review. | Staff must be able to switch the model off and challenge its outputs. |
Two further sets of duties matter in practice. On deployment, the entity must add access controls, cyber safeguards, and controls over APIs and integration pipelines, and for customer facing or generative models it must defend against prompt injection, disclose to users that they are dealing with an AI system and its limitations, and offer a route to a human. On oversight, it must keep a human in command through human in the loop or on the loop arrangements, override and kill switch mechanisms, and periodic human review, while guarding against automation bias and over reliance, and ensuring overseers actually understand the model well enough to challenge it.
7. Comparison: Supportive Of The Meity Principles, Not Contradictory
The MeitY Guidelines take a soft law, principle based approach that leans on existing statutes and deliberately leaves binding AI rulemaking to sectoral regulators such as the Reserve Bank. Two facts make the comparison straightforward. First, the seven MeitY sutras are themselves adapted from the Reserve Bank's August 2025 FREE-AI report, so the two share a common parent. Second, the MeitY design expects sectoral regulators to convert its principles into enforceable rules. On that design, the Guidance is precisely what the MeitY framework anticipates: the financial sector's hard, supervisory expression of the same philosophy.
MeitY sutra | How the RBI Guidance gives it effect |
|---|---|
Trust is the Foundation | Governance, validation, monitoring, and non transferable accountability exist to make model driven finance trustworthy. |
People First | Human in command oversight, kill switches, AI disclosures, the right to reach a human, and the bar on consumer harming models. |
Innovation over Restraint | Risk based and proportionate, not a ban. AI, including foundational and frontier models and even low explainability models, is permitted where the risk can be managed. |
Fairness and Equity | Express duties to test for bias and discrimination and to remediate, reinforced by the consumer protection rule. |
Accountability | A clear allocation across Board, RMCB, senior management, owners, validators, and the three lines of defence. |
Understandable by Design | Explainability and transparency thresholds, raised for material decisions, with compensating controls where full explainability is not achievable. |
Safety, Resilience and Sustainability | Adversarial and stress testing, red teaming, cyber and prompt injection defences, and business continuity with fallback mechanisms. |
The mapping shows support on all seven principles. The one point where a reader might expect friction is innovation over restraint, given the Reserve Bank's instruction to deploy AI only where risk can be managed and to limit opaque third party models.
Is There Any Tension? Innovation Over Restraint,
On a careful reading, this is not a conflict. The MeitY principle is not innovation without limits; it is innovation that takes precedence over precautionary restraint provided appropriate safeguards are in place. The Reserve Bank's controls are precisely those safeguards.
The Guidance does not forbid AI; it conditions its use on the entity's ability to manage the risk, which is the same balance the MeitY principle strikes, expressed for a high stakes sector.
There is a genuine difference in form, and practitioners should hold it clearly in mind. The MeitY Guidelines are soft law: principle based, largely voluntary, and reliant on existing statutes. The Reserve Bank's Guidance is a supervisory instrument: specific, prescriptive, and enforceable for regulated entities, with the Reserve Bank able to examine compliance directly. For a bank or non banking financial company, the operative obligations come from the Reserve Bank, while the MeitY sutras supply the interpretive backdrop and may guide regulators and courts when they assess conduct. The two are complementary in substance and sequential in force.
Conclusion
The Reserve Bank's draft Guidance turns model risk into a governed, documented, and supervised discipline for the whole financial sector. Its reach comes from a wide definition of model that captures far more than Al, its spine is Board level accountability that cannot be outsourced, and its sharpest edge is the Al and MI chapter, which demands explainability, fairness testing, hallucination control, red teaming, and real human oversight. Entities should begin now with model discovery, an inventory, a Board approved framework, and a review of third party contracts, because the heaviest lifting is organizational, not technical.
Read against the MeitY India Al Governance Guidelines, the Guidance is supportive rather than contradictory. Both descend from the same FREE-AI principles, and the MeitY framework expressly relies on sectoral regulators to convert its sutras into binding rules. The Reserve Bank has done exactly that for finance. The result is a layered Indian model of Al governance, in which a light touch national philosophy is given enforceable shape, sector by sector, and the Model Risk Management Guidance is the financial sector's first full expression of it.