Public comments on the Reserve Bank of India’s draft Guidance on Regulatory Principles for Model Risk Management, 2026 close on 24 July 2026.
Much of the early commentary has centred on its AI provisions: kill switches, human oversight and customer disclosures.
Those requirements matter, but they sit inside a far larger structural change. The draft brings every model used by a regulated entity, whether statistical, spreadsheet-based or AI-driven, under one governance framework, and it makes accountability for those models impossible to outsource.
If finalised, this becomes one of the most significant updates to model governance in Indian banking in over a decade.
This blog breaks down:
- what qualifies as a model under the draft
- how accountability and vendor risk shift
- what the board and risk committee are now expected to do, and
- how institutions can start preparing before the guidance is finalised.
Why RBI is broadening the scope now
Financial institutions run on models more than most functions realise day to day. Credit scoring, fraud detection, anti-money laundering monitoring, treasury pricing, liquidity forecasting, customer segmentation and cybersecurity threat detection all depend on some combination of statistical methods, machine learning or deterministic calculation.
As these systems multiplied, governance evolved unevenly. Credit risk teams built one framework, AI teams built another, procurement assessed vendor tools on its own, and cybersecurity functions managed AI-enabled security products independently.
The result across many institutions has been fragmented oversight and inconsistent documentation.
This pattern isn’t unique to India. Regulators across major financial markets have moved from governing individual technologies toward governing automated decision-making. RBI’s draft reflects that same shift, treating AI governance and traditional model risk management as one discipline rather than two.
As many experts have pointed out already a relatively simple spreadsheet-based calculator can carry the same business consequence as a sophisticated machine learning model if it produces inaccurate outputs that feed into lending or pricing decisions.
Recognising that automated decision-making, not the underlying technology, is what carries risk is one of the draft’s most significant contributions, and it explains why the framework treats a credit scorecard and a generative AI chatbot as variations of the same governance problem rather than separate categories.
What counts as a “model” under the draft
The draft’s scope extends well beyond machine learning.
In broad terms, if a system takes inputs, applies logic or calculations, and produces an output that supports a business decision, RBI is likely to treat it as a model.
That includes credit scorecards, fraud detection engines, treasury pricing calculators, and, notably, spreadsheet-based tools. A loan pricing calculator built years ago by a business analyst, updated informally over time, distributed by email and never formally validated, falls squarely within scope once it applies predefined assumptions and influences a lending decision.
The same logic applies to externally delivered AI capabilities: generative AI chatbots, cloud-based fraud detection services, credit scoring APIs and AML monitoring platforms.
Because these tools are consumed as software services, institutions have sometimes treated them as vendor-owned black boxes. The draft narrows that gap. If the output shapes a customer, operational or risk decision, the system belongs in the enterprise model inventory regardless of who built it.
Key changes from the 2026 RBI draft
RBI’s 2024 consultation focused mainly on credit models, and the FREE-AI Committee addressed AI governance as a separate track. The 2026 draft merges both into one enterprise-wide framework covering models built in-house, purchased from vendors, open-source, delivered as SaaS, or a mix of these.
Where it conflicts with an existing RBI direction, that direction prevails, so the draft complements rather than replaces current regulation.
Accountability does not transfer with the model
Using a model, whether built internally, licensed, or cloud-accessed, does not transfer accountability for its outcomes. Vendor certifications support due diligence but aren’t sufficient on their own. Institutions must be able to answer how a model reaches its conclusions, its limitations, revalidation frequency, and what happens when it produces unexpected results.
Vendor risk becomes model risk
Most banks source fraud detection, AML, credit scoring, and chatbot capabilities externally. If one of these systems misfires, regulators ask what the institution did, not just the vendor. Typical questions:
- Was the model independently assessed before deployment?
- Was its intended use and limitations documented?
- Was performance monitored, with material changes reviewed before redeployment?
- Was human oversight and customer escalation maintained?
The same standard applies to cloud-hosted generative AI, open-source ML libraries, and embedded AI features, regardless of whether the bank trained the model itself. Vendor agreements will increasingly need to cover documentation access, validation support, audit rights, and change notification, pulling procurement closer to risk and compliance functions.
Board and risk committee responsibilities
Model governance moves from a technical function into an enterprise governance responsibility. The board is expected to approve the institution’s overall Model Risk Management Framework and set its appetite for model risk.
The Risk Management Committee of the Board handles ongoing oversight, including:
- Reviewing and approving deployment of high-risk models.
- Periodically reviewing model risk classifications.
- Monitoring models approved under exceptions.
- Overseeing third-party models and maintaining oversight of AI-enabled models specifically.
Three lines of defence
Underneath the board and RMCB sits a familiar structure:
- First line: business owners who develop and operate models.
- Second line: an independent validation function assessing performance, assumptions and risks.
- Third line: internal audit providing assurance that the governance framework itself works as intended.
Many institutions already run similar structures for operational risk and information security; the draft formalises the same approach specifically for models.
The AI-specific layer
Once the broader framework is in place, the draft adds enhanced expectations for AI and machine learning models specifically, including:
- Explainability and transparency.
- Hallucinations.
- Bias and discriminatory outcomes.
- Overfitting and poor generalisation.
- Spurious correlations.
- Output variability and uncertainty.
- Data quality risks.
Validating an AI model becomes more than measuring predictive accuracy; it means checking whether outputs stay explainable, whether bias has been assessed, and whether human oversight mechanisms remain effective.
Human override mechanisms
Every AI model needs a mechanism for suspension, override or deactivation when it behaves unexpectedly, along with clear governance around who can intervene, when, and how the decision gets documented.
Customer transparency
Where AI interacts directly with customers, institutions need to disclose that the customer is talking to an AI system and provide a practical route to escalate to a human.
Together, these two requirements reinforce a broader expectation running through the draft: AI stays subject to meaningful human oversight across its operational lifecycle rather than functioning as a fully autonomous decision-maker.
Risk tiering and the anti-dilution principle
Every institution is expected to classify its models by risk, based on materiality, complexity and business impact, not technical sophistication alone. A model cannot be classified as low risk simply because it is technically simple. A machine learning model recommending marketing campaigns may be complex but carry limited regulatory impact, while a basic spreadsheet-based loan pricing calculator, built on simple formulas, can receive a higher governance classification purely because it directly affects lending decisions for thousands of customers.
Documentation, retirement and change management
RBI proposes that decommissioned models remain in the institution’s inventory for at least ten years after retirement, longer if they continue serving as reference or backup models. That matters when a customer disputes a seven-year-old lending decision, or an audit uncovers a historical issue in fraud detection thresholds. Institutions need to be able to identify which model and version generated a decision, who owned and validated it, and what data and assumptions it used.
Change management gets the same rigour. Thresholds, data sources and features shift over time, and each change needs documentation, version control and impact assessment before deployment, with material changes triggering fresh validation.
Consumer protection as part of model governance
Model risk connects directly to consumer protection. If a model shapes a customer’s interest rate, loan approval, fraud investigation or account access, the model’s quality shapes that customer’s outcome. Existing grievance redressal mechanisms are expected to accommodate complaints arising from model-driven decisions, particularly as AI becomes more visible in customer-facing banking services.
What institutions can start doing now
Waiting for the final circular adds pressure later, since inventory creation, governance design and vendor assessment work takes months. Five starting points:
- Build a complete enterprise model inventory that goes beyond AI and credit models to include spreadsheet-based tools, internal analytical systems, vendor solutions and embedded AI features.
- Assign clear ownership to every governed model, since unowned models tend to become the largest governance gap.
- Review third-party relationships for governance maturity, not just functionality, including what documentation and audit rights vendors can provide.
- Assess whether existing validation teams have the skills, independence and capacity for enterprise-wide coverage.
- Prepare board and RMCB reporting structures that give consistent visibility into model inventories, validation findings and AI governance metrics.
None of this needs to wait for the final wording. Inventory building, ownership assignment and vendor documentation reviews can start against the draft as it stands, and institutions that begin now avoid the compressed timeline that typically follows a final circular.
Conclusion
RBI’s draft moves model governance from a specialist activity run by quantitative risk or AI teams into an enterprise-wide capability spanning business functions, technology, procurement, compliance, internal audit and the board. Institutions that treat AI governance, vendor risk and model risk as separate programmes risk duplicated effort and governance gaps. Those that build one unified framework, backed by a complete inventory, independent validation and board-level accountability, will be better positioned once the guidance is finalised.
Preparing for a framework of this scope touches governance, technical validation and vendor oversight at the same time. CyberNX supports BFSI institutions with model and third-party risk assessments, GRC advisory aligned to RBI, SEBI and DPDPA requirements, and technical security validation for AI-enabled and vendor-delivered systems, helping institutions build the enterprise model inventory, documentation and board reporting structures this draft expects, well ahead of the final circular.
FAQs
Does the RBI draft only apply to AI models?
No. The draft covers any system that takes inputs, applies logic and produces an output influencing a business decision, including spreadsheet-based calculators, statistical models and vendor-supplied tools, not only AI or machine learning systems.
Who is accountable if a vendor-supplied model causes a bad outcome?
The regulated institution remains accountable, not the vendor. Vendor certifications and audit reports support due diligence but do not replace the institution’s own validation and monitoring responsibilities.
How long must retired models stay in the model inventory?
At least ten years after decommissioning, and longer if the model continues to serve as a reference or backup, so historical decisions can still be traced and explained.
What is the anti-dilution principle in risk tiering?
It means a model cannot be classified as low risk purely because it is technically simple. Classification is based on business materiality and impact, so a basic spreadsheet affecting lending decisions can carry a higher risk tier than a complex model with limited regulatory impact.
