On June 24, 2026, the Reserve Bank of India (“RBI”) released its draft Guidance on Regulatory Principles for Model Risk Management, 2026 (“Draft Guidance”) for public comments. The Draft Guidance has broad applicability: (i) it covers 11 categories of entities regulated by the RBI (such entities, “REs”) – including commercial banks, non-banking financial companies (NBFCs), payments banks, asset reconstruction companies (ARCs), credit information companies (CICs), co-operative banks and All-India Financial Institutions (AIFIs); and (ii) it applies to all models used by REs, including third-party models and those employing artificial intelligence (“AI”) and/ or machine learning (“ML”).

The Draft Guidance provides a comprehensive governance framework for regulating and managing risks associated with the deployment of models in the financial sector, taking into account emerging global best practices. Pursuant to public consultation, the final form of the Draft Guidance is intended to supersede Chapter 3 on credit risk models of the RBI’s Guidance Note on Credit Risk Management, dated October 12, 2002.

Background and Purpose

Previously, with the aim of strengthening governance and risk management practices related to the use of models in credit management, the RBI had, on August 5, 2024, released a draft circular for comments titled “Regulatory Principles for Management of Model Risks in Credit.” This was followed by a report dated August 13, 2025 from the RBI-constituted committee on developing a Framework for Responsible and Ethical Enablement of Artificial Intelligence (FREE-AI) in the financial sector, aiming to harness AI’s potential while safeguarding against associated risks.

Against this backdrop, the Draft Guidance has been issued in view of the following:

• the use of models has expanded significantly, and REs are increasingly using models across various business and decision-making processes; and
• weaknesses in governance, oversight, risk management and controls when using models may expose REs to financial, operational, compliance and reputational risks.

Accordingly, the Draft Guidance seeks to provide broad regulatory expectations for managing risks related to models across their lifecycle. A ‘model risk’ is defined as the risk of adverse outcomes from a model arising from, among other things, the following:

• model errors, such as inappropriate specification, incorrect parameterization, flawed hypotheses and/ or assumptions, computational errors, inaccurate/ inappropriate/ incomplete data, inadequate controls or other issues in development, as well as inadequate validation;
• misapplication (i.e., improper/ unintended use or output misinterpretation); and
• time-suitability issues (i.e., when models become less fit or unsuitable over time).

The Proposed Framework

The Draft Guidance seeks to establish a regulatory architecture for model deployment in the financial sector, including for purposes of aligning India with emerging global practices. In this regard, the Draft Guidance represents a significant shift in AI/ ML governance and the use of other quantitative models by REs.

The Draft Guidance has been divided into separate chapters on governance, risk and lifecycle management, respectively, as well as a chapter on specific models. In general, the framework proposed under the Draft Guidance proceeds from a fundamental principle increasingly reflected in international regulatory approaches: i.e., responsibility for decisions cannot be delegated to algorithms. Boards and senior management remain ultimately accountable for the design, deployment, oversight and outcomes of models. REs should establish clear governance structures, maintain inventories, conduct independent validation, continuously monitor performance and implement effective controls throughout a model’s lifecycle. The proposed recommendation for kill switches and human intervention mechanisms reinforces the principle that REs should retain operational control over automated systems and remain capable of suspending or overriding model-driven decisions when risks materialize.

What is a model?

The Draft Guidance defines a ‘model’ as a system, whether developed internally, sourced from third-parties or a combination thereof, that:

• incorporates data, applies theoretical, empirical or judgement-based assumptions (i.e., the input component);
• uses statistical, mathematical, economic, financial or such other cognitive techniques (including AI/ ML) to analyze, interpret relationships and process inputs (i.e., the processing component); and
• produces results that are used for business or any other operations and decision-making (i.e., the output component).

The term “model,” thus, includes algorithms, analytics, interfaces, applications, decision-based rules and other computational tools which, by virtue of their use, have a material impact on decision-making in various business processes, irrespective of whether such tools are recognized as models by the RE.

For example, if a basic mathematical tool, such as a spreadsheet-based loan pricing calculator, is used by an RE to derive lending rates, customer margins or credit terms in a way that it takes inputs (e.g., borrower type, tenor, credit score, collateral value), applies processing logic (e.g., interest rate grids, risk-weighted spreads, margin formulae) and produces an output (e.g., final lending rate/ price) which affects business decisions, such a tool will be considered a model for purposes of the Draft Guidance. Such a broad definition of model would mean that even tools that do not rely on AI/ ML could be considered models under the Draft Guidance based on how they are used for decision-making processes by REs.

Governance

Since REs remain accountable for the outcomes of models they use (regardless of whether a model is developed internally, sourced from third parties or through a combination of both), the Draft Guidance requires them to establish a board-approved ‘Model Risk Management Framework’ (“MRMF”) covering all models (including AI/ ML). The MRMF should address, among other matters, model taxonomy, governance structures, the scope of model use, risk-tiering methodology, inventory and documentation standards, as well as policies covering the entire model lifecycle, including selection and development, validation, approval, deployment and monitoring, change management, business continuity and decommissioning (i.e., the process of retiring a model from active use).

The board should be responsible for overseeing the MRMF, including by (i) approving and periodically reviewing it (with appropriate delegation to the Risk Management Committee of the Board (“RMCB”) or other committees); (ii) approving the RE’s risk appetite and tolerance for model risk, informed by forward-looking scenario analysis and stress testing; and (iii) approving model risk management policies, including model risk-tiering policies.

The RMCB should oversee implementation and ongoing compliance with the MRMF. It should also review validation reports for high-risk or equivalent models and approve their deployment, periodically review model risk-tiering reports at least annually, oversee models approved with exceptions – along with third-party and AI models and review reports of breaches and other material concerns.

Senior management should: (i) be responsible for operationalizing the MRMF by establishing procedures and processes, and ensuring allocation of adequate human and technical resources, (ii) implement risk-based model tiering, (iii) maintain and regularly update the model inventory and documentation and (iv) periodically review MRMF policies/ processes and report to the RMCB.

Risk management

An RE should assess model risk continuously at both the individual-model and enterprise-wide levels and, where a model’s assessed risk exceeds its risk appetite, take timely measures such as enhanced controls, restrictions on use, remediation or decommissioning. It should also implement three lines of defence, involving the following:

1. model owners (i.e., individuals or functions responsible for (i) ensuring that a model’s design, assumptions, methodologies and documentation are aligned with its intended use and regulatory requirements, as well with the internal policies of the RE concerned, and (ii) coordinating across various stages of the model lifecycle) as the first line;
2. an independent model risk management and validation function as the second line; and
3. a robust and independent internal audit function as the third line.

Ongoing model performance testing should use both backward-looking and forward-looking approaches, including AI-specific evaluations where applicable, together with benchmarking where appropriate.

Risk-based tiering

Each RE should establish a risk-based model-tiering structure covering all models in its inventory, and review each model’s risk tier at least annually, or earlier where required under the MRMF or triggered by specific circumstances. The risk tier should guide (i) validation priorities, intensity, frequency and methodologies; and approval requirements, with high- or equivalent-risk models requiring RMCB approval and other models potentially subject to delegated approval; (ii) risk mitigation and controls; (iii) the scope of monitoring, reporting and review; (iii) inventory and documentation requirements; and (iv) business continuity planning.

Tiering should consider the model’s materiality, including its significance to business processes, impact on financial and operational outcomes, and potential consumer implications; its complexity, including difficulties in understanding and overseeing it, use of unstructured data and explainability (i.e., the property of a model to express important factors influencing its results, in a way that is understandable) challenges; and other relevant regulatory or supervisory considerations. Multiple factors should be assessed collectively so that one factor does not offset or dilute another. For example, low complexity should not disproportionately reduce the risk tier of a highly material model.

Inventory and documentation

In addition, an RE should maintain an accurate, comprehensive and current inventory of all active, inactive (including models under development) and decommissioned models, providing an overview of individual and enterprise-wide model risk, supporting management reporting and identifying model interdependencies. No model may be used, relied upon or deployed unless it is included in such inventory.

At a minimum, the inventory should record the following for each model:

• model owners);
• developers (i.e., individuals/ functions responsible for designing, developing, testing, training and documenting the model’s methodologies);
• validators (i.e., independent of model development/ ownership/ use, individuals/ functions responsible for carrying out model validation to ascertain whether it is fit, efficient and serves the intended purpose);
• approvers (i.e., individuals/ functions responsible for undertaking approval process and granting approval for model deployment);
• risk tier;
• intended use;
• upstream and downstream dependencies; and
• key observations from validation, monitoring and audit.

Decommissioned models should remain in the inventory for at least 10 years from decommissioning or from the date they cease to serve as a backup/ benchmark reference, whichever is later, or for any longer period required by applicable law. Comprehensive documentation should be maintained for all models, including third-party models, for at least the same period as their inventory retention requirement.

Consumer protection and grievance redressal

An RE should not use any model that harms consumers, and its grievance redressal mechanism should specifically address grievances arising from consumer-facing models.

Lifecycle management

Selection and development

The model lifecycle should begin with a structured selection and development process. Before developing a model, an RE should define and document the rationale, objectives and scope of its intended use, while assessing the costs and benefits of introducing or replacing existing processes, including additional risks, potential adverse outcomes, fairness, ethical considerations and bias. Model development should follow a systematic process aligned with its intended use and outputs, covering data collection, preprocessing and transformation, assessment of assumptions and limitations, model design and evaluation and refinement of performance. Both empirical and synthetic data used for development should comply with the RE’s data governance processes.

Validation

All models, including third-party models, should undergo independent validation by the RE both before and after deployment, following modifications in response to internal or external triggers, and periodically as specified in the MRMF. Validation should assess (i) inputs such as data, assumptions and limitations; (ii) conceptual and design soundness; (iii) performance; and (iv) alignment with intended use. Outcomes should be documented in accordance with the MRMF and related policies, and validation reports, including key findings and recommendations, should be submitted to the RMCB or delegated authority within three months of completion.

Approval

The RE should also maintain a formal model approval structure, including procedures for approving exceptions, specifying approval authorities and thresholds, additional requirements for models approved with exceptions and remediation timelines. All approval and exception decisions should be documented, including their rationale.

Deployment and ongoing monitoring

Model deployment and monitoring should be coordinated with relevant stakeholders, including information technology and data functions, and the RE should ensure that model outputs are replicated and remain stable in the production environment. All deployed models, including third-party models, should be continuously monitored to ensure that they remain aligned with intended outcomes, including determining whether modification, replacement or extension beyond the original scope is required. Models approved with exceptions should receive enhanced monitoring by the RMCB.

Change management

The RE should also maintain a structured change-management process specifying responsibilities for implementing and approving changes, ensure that changes are controlled and implemented at the enterprise level with mechanisms to recover from failed changes or unexpected results, and conduct a documented impact assessment before any model change to determine whether the model remains suitable for its intended use. Comprehensive records of changes, versioning and approvals should be maintained, and the RE should define criteria for a material change, the occurrence of which should trigger renewed validation and approval.

Business continuity management and decommissioning

Finally, business continuity and decommissioning should be integrated into the RE’s overall business continuity planning policy/ document. Continuity arrangements should address disruptions such as model unavailability, performance degradation or failure, and provide fallback mechanisms including manual intervention, substitution or backup arrangements. When a model is decommissioned, all relevant stakeholders should be informed in a timely manner to facilitate an enterprise-wide transition.

Specific models

Third-party models

The Draft Guidance imposes specific requirements for third-party models, under which an RE remains accountable for the outcomes of any third-party model it acquires, uses or relies upon at any stage of the model lifecycle. The MRMF applies to such models mutatis mutandis, with additional requirements for independent validation by the RE notwithstanding any validation, certification or assurance provided by the third-party provider, and enhanced oversight by the RMCB irrespective of the model’s risk tier. Before acquiring or using a third-party model, the RE should conduct due diligence covering, among other matters, the provider’s credibility, the model’s methodological soundness and limitations and the suitability and quality of the data used. Contracts governing third-party models should provide for (i) access to sufficient technical documentation to understand and validate the model’s design, configuration, assumptions and operation; (ii) audit rights for the RE and its supervisory authority, directly or through external experts; and (iii) appropriate continuity and exit arrangements.

Models using AI/ ML

Risk management

For AI/ ML models, the RE should define the scope of the model, including foundational and frontier AI models, and implement additional controls proportionate to their potential impact on customers, business operations and financial outcomes. It should assess whether risks can be adequately identified, measured, monitored and managed, and deploy such models only for use cases where the associated risks can be effectively controlled. Where third-party providers do not provide adequate information, the RE should identify the resulting risks and implement mitigants, including limiting use where necessary. AI model risk-tiering should additionally consider the extent of reliance on, and level of autonomy given to, model outputs in decision-making. For material third-party AI models, datasets and dependencies, the RE should consider risks arising from concentration among model providers, including supply-chain risk, limitations on independent validation, and provider-driven changes in model behavior or capabilities. AI models should also be tested under atypical and stressed scenarios, including edge cases, abnormal inputs, manipulation and adversarial conditions, with appropriate safeguards against behavioral vulnerabilities.

Further, REs should establish explainability and transparency thresholds for AI models, with higher thresholds for models used in material decision-making or having significant customer or operational impact. Where full explainability is not possible, enhanced validation and testing, output verification and corroboration, frequent validation, continuous monitoring, usage restrictions and other compensating controls should be applied. System-level controls or model-design features should mitigate hallucination risks, particularly in generative AI and customer-facing or decision-making applications. REs should identify and mitigate bias and discriminatory outputs, including through fairness assessments, recalibration or redesign and, where appropriate, constraining model complexity and feature selection. Models should not be overfitted to training data and should be tested using out-of-sample data and varied scenarios to ensure reliable generalization to real-world and evolving conditions. In addition, REs should guard against spurious correlations or unintended relationships, manage excessive or unexplained variation in outputs – including stochastic behavior and model uncertainty – through appropriate measures such as confidence scores and probability outputs, and address data risks including poor quality, non-representativeness, incompleteness and intellectual property breaches. Data and concept drifts should be monitored and addressed continuously.

Moreover, REs should establish structured challenge processes, including ‘red-teaming’ (i.e., a process for testing cybersecurity effectiveness pursuant to simulated attacks to help organizations identify vulnerabilities in their AI systems and improve security operations) or equivalent testing, particularly for customer-facing and generative AI models. Models capable of dynamic or automatic updates require enhanced controls, including clearly defining what may be updated automatically, providing strict justification for automatic updates, applying enhanced data-quality checks and conducting more stringent and frequent monitoring. AI models require enhanced documentation – reflecting their complexity, self-adapting characteristics and substantial reliance on training data – to ensure traceability, reproducibility and auditability.

Deployment controls

For AI model deployment, REs should ensure that deployment does not introduce vulnerabilities into the model or production environment, and should implement appropriate safeguards covering unauthorized access, cybersecurity risks and risks arising from external interfaces, application programming interfaces (APIs) and integration pipelines involving third-party components or systems. Customer- or externally-facing AI models, including generative AI models, require additional cybersecurity controls against prompt injection and adversarial inputs, limitations on session and context persistence, and detection of anomalous usage patterns. Users should receive appropriate disclosures and warnings about the fact that they are interacting with an AI/ ML-based system, together with information on its limitations, and should be given an option to switch to human assistance when requested.

Human oversight

Lastly, REs should establish robust human oversight for AI models, including automated decision-making applications. Required safeguards include (i) human-in-command arrangements, such as human-in-the-loop or human-on-the-loop mechanisms; (ii) mechanisms to override, suspend or deactivate models, including ‘kill-switch arrangements’; and (iii) periodic human review of model outputs and model-driven decisions to identify anomalies. Oversight should account for automation bias, excessive reliance on model outputs and decision fatigue. Personnel responsible for oversight should possess sufficient expertise and understanding of model functioning to effectively challenge, override or escalate concerns arising from model outputs. Human oversight arrangements – including decisions, interventions, overrides, incidents and near misses – should themselves be periodically reviewed and strengthened based on experience.

Comparison with Global Best Practices and Liability Issues

Internationally, AI in finance is treated as a high-risk application. The European Union’s Artificial Intelligence Act and General Data Protection Regulation (GDPR)-inspired frameworks emphasize human oversight, risk assessments, transparency and cybersecurity, but do not explicitly require a kill switch for all models. The European Central Bank (“ECB”) and regulators in the United Kingdom stress that AI cannot dilute board accountability. The Monetary Authority of Singapore (“MAS”) and the Hong Kong Monetary Authority (“HKMA”) similarly require strong governance, documented model-risk controls and customer disclosures, including, in some circumstances, the ability to opt out of AI-driven decisions, but do not impose blanket technical kill-switch mandates. In the United States, banking regulators, including the Office of the Comptroller of the Currency (OCC) and the Federal Reserve (Fed), have reinforced sound model-risk management, but have not specifically mandated kill switches.

The RBI’s approach parallels these principles but goes further in some respects, including in terms of customer disclosure requirements and the kill-switch requirement, which is generally not imposed in other jurisdictions. It implicitly adopts a view on “material contribution”: i.e., REs cannot escape liability if an AI error occurs, including by attributing responsibility on vendors. In addition, the Draft Guidance reinforces the principle of foreseeability – i.e., REs should be able to anticipate AI misbehavior.

However, the Draft Guidance remains ambiguous on resolving cross-border issues (e.g., if a foreign-sourced model causes harm) and does not explicitly allocate vendor liability under law. The framework’s emphasis on explainability and auditability (e.g., through traceable records and red-team testing) is in line with European Union/ ECB expectations, but India may need further clarity on how safe harbor or intermediary rules apply to AI outputs. For now, responsibility accrues to the RE deploying the model, with legal uncertainty being mitigated through stringent controls rather than revisions to existing liability doctrines.

Conclusion

The Draft Guidance provides a robust framework for governing and mitigating the risks associated with the deployment of models by REs centered around board responsibility and drawing on emerging global best practices. However, much of the framework’s success will lie in overcoming implementation challenges, including rising compliance costs, the shortage of expertise required for model validation and maintaining explainability and oversight as AI/ ML models become increasingly complex. The RBI may also need to coordinate with other regulatory authorities on cross-border AI issues. Sharing of industry best practices (e.g., the MAS’s guidelines (see here and here) or policies from Hong Kong (see here and here) – including the HKMA’s AI principles (seehere, here, and here)), may also help with learning and adoption. Importantly, the RBI may need to monitor actual outcomes, including by enforcing incident reporting (with defined thresholds), examining “near-miss” data, and adjusting expectations as AI-related technology evolves. Effective model risk governance, led by boards and implemented across the organization, will be important in managing AI-related liability and safety in the financial sector.

This insight has been authored by Aparna Ravi, Dr. Deborshi Barat and Manan Sheth from S&R Associates. They can be reached at [email protected], [email protected] and [email protected], respectively, for any questions. This insight is intended only as a general discussion of issues and is not intended for any solicitation of work. It should not be regarded as legal advice and no legal or business decision should be based on its content.