Short answer: the RBI’s draft Guidance on Regulatory Principles for Model Risk Management, 2026 is a consultation document, not a binding rule. It would apply to banks, NBFCs in the Base to Top Layers, All-India Financial Institutions, Asset Reconstruction Companies and Credit Information Companies. It defines a model broadly, so vendor-supplied scoring engines, AI and ML systems and even spreadsheet calculators can fall inside it. For vendor teams the headline is simple: outsourcing a model does not outsource the risk, and the regulated entity must validate it independently.
This sits alongside the RBI rules we have already covered, including the RBI NBFC outsourcing directions and the RBI cybersecurity directions. It extends third-party risk management from the vendor to the model the vendor runs. This is an operational reading of a draft, not legal advice.
What the Draft Says, and What Is Still Open
The draft is a consultation document. The text published by the RBI shows a placeholder date (“June xx, 2026”) and a placeholder reference number, and paragraph 64 states that a final version issued after public consultation will supersede Chapter 3 of the 2002 Guidance Note on Credit Risk Management. The text we reviewed states no comment deadline and no implementation timeline, and paragraph 2 notes that further AI-specific requirements may be issued later. We did not find a final version as of the date of this article. Paragraph numbers below refer to the draft and may change.
The definition in paragraph 7(3) is the part to read twice. A model is a system, “whether developed internally, sourced from third-parties, or a combination thereof,” that uses data and assumptions, applies analytical techniques including AI and ML, and produces outputs used in business decisions. It covers algorithms, applications and decision rules with a material impact, whether or not the entity labels them models. The draft cites a spreadsheet loan-pricing calculator as an example.
Why Vendor Models Are the Pressure Point
Paragraphs 45 to 48 deal with third-party models. The entity remains accountable for outcomes, must validate independently regardless of what the provider assures, and its Risk Management Committee of the Board (RMCB) oversees third-party models irrespective of tier. Contracts should give access to technical documentation and audit rights for the entity and its supervisor. Commentary on the draft by Vinod Kothari & Company reads this as saying that a vendor’s certification does not remove the duty to validate.
Most vendor registers record services, not models. A vendor providing credit scoring, fraud detection, collections prioritisation or a customer chatbot may be running several models inside one contract. The table maps the draft’s expectations to the evidence a vendor file would need. The “typical gap” column is our interpretation, not RBI text.
| Draft expectation | Evidence in the vendor file | Typical gap |
|---|---|---|
| Inventory of active, inactive and decommissioned models, with owner, tier, use and dependencies (paras 21-24) | Each vendor-run model listed, linked to the vendor record and any underlying model provider | Register lists the vendor, not the models inside the service |
| Risk-based tiering reviewed at least annually; materiality and complexity do not offset each other (paras 17-20) | Tier set per model and use case, with the annual review recorded | One vendor tier applied to every model the vendor supplies |
| Independent validation before and after deployment, after changes and periodically (paras 29-33) | Validation scope, validator, date, findings and the vendor documentation relied on | A certificate or model card treated as validation |
| Technical documentation and audit rights in contracts (paras 45-48) | Clauses naming documentation access and entity and supervisor audit rights | Standard SaaS terms that refuse access to model internals |
| Validation reports to the RMCB or delegated authority within three months of completion (paras 12, 33) | Dated submission trail from the vendor owner to the committee | No route from vendor management to the board committee |
Crest.Digital’s third-party risk management platform keeps contracts, evidence, tiering and follow-ups against a single vendor record, which is where model-level notes can sit.
Explore TPRM SolutionsWhat the Draft Asks of AI and ML Models
Paragraphs 49 to 63 address AI and ML directly. The entity sets explainability thresholds, higher for material decisions, and applies enhanced controls where full explainability is not possible. Controls must address hallucinations, bias and fairness, overfitting and data drift. Customer-facing AI needs a disclosure that the user is dealing with AI and an option to reach a human (para 59). Paragraph 60 calls for human oversight with override or kill-switch mechanisms.
When the AI is a vendor’s, each duty needs a counterpart in the contract and the evidence file. Who monitors drift, and who gets the alert? Can the vendor switch off a model on instruction? Is the underlying model provider disclosed? These are the questions in our pieces on the kill switch, autonomous AI controls internal audit must test and fourth-party AI models. A vendor’s ISO 42001 certificate needs a scope check before it is treated as supporting evidence.
Five Steps to Prepare Before the Final Version
Find the Models Inside Your Vendors
Ask each material vendor which of its services use models, including AI, and record them. Start from your AI inventory built from the vendor inventory.
Tier by Use, Not by Vendor
Rate each model on materiality and complexity separately, and review the tier at least annually, as the draft proposes.
Decide Who Validates
Name the independent validator for each vendor model and list the documentation it needs from the vendor. Do this before the contract is signed or renewed.
Add Contract Rights at Renewal
Seek technical documentation access, audit rights extending to the supervisor, change notices and model-provider disclosure. See our guide to contractual controls.
Route Evidence to the Board Committee
Give validation results and monitoring exceptions a path to the RMCB, and keep dated records. Evidence that ages in a folder is not oversight.
Worked Example: A Hosted Credit-Scoring Vendor (Illustrative)
This is a hypothetical scenario, not a customer case study. A mid-sized NBFC uses a fintech’s hosted scoring engine to pre-screen small-ticket loan applications. The vendor holds a SOC 2 report and supplies a short model summary. The NBFC’s vendor register shows one entry, tiered medium for data security.
Reading the draft, the team sees three problems. The scoring engine is a model with a material effect on credit decisions, so it needs its own tier. A SOC 2 report and a summary are not independent validation. And the contract gives no access to technical documentation. The team records the engine in a model inventory linked to the vendor, assigns a higher tier, asks the vendor for development documentation and performance data, and schedules validation by a party independent of the vendor. At renewal it adds documentation and audit-access clauses and a duty to notify retraining or provider changes. A named owner reports the result to the risk committee. The dependency check is the same one described in our SOC 2 report review guide.
Crest.Digital’s TPRM agents can track evidence expiry and vendor signals, and Voice AI for GRC can chase outstanding documents. People decide whether a validation is independent and sufficient.
Four Questions for Your Next Vendor Review
- Which models does this vendor run for us? A contract is not a model list.
- Who validates them, independently of the vendor? Certification is not validation.
- What can we see and audit? Documentation and audit rights belong in the contract.
- Who sees the result? Evidence must reach the board committee.
For wider context see the enterprise AI governance guide, the global regulatory compliance hub and our earlier look at RBI outsourcing guidelines.
Frequently Asked Questions
No. The document we reviewed is a draft issued for public consultation in June 2026 and carries a placeholder date and reference number. Paragraph 64 says a final version, issued after consultation, will supersede Chapter 3 of the 2002 Guidance Note on Credit Risk Management. As of October 25, 2026 we did not find a final version, so check the RBI website for the current status.
Paragraph 4 of the draft lists commercial banks including foreign banks, small finance banks, payments banks, local area banks, regional rural banks, urban and rural cooperative banks, NBFCs in the Base, Middle, Upper and Top Layers, All-India Financial Institutions, Asset Reconstruction Companies and Credit Information Companies.
It can. The draft defines a model as a system that uses data and assumptions, applies analytical techniques including AI and machine learning, and produces outputs used in decision-making, whether or not the entity calls it a model. It gives a spreadsheet loan-pricing calculator as an example that may qualify.
Not under the draft. Paragraphs 45 to 48 keep the regulated entity accountable for outcomes and require independent validation regardless of provider assurances. A SOC 2 report or ISO certificate can support the file but does not replace validation.
They address different questions. The outsourcing directions govern how you select, contract, monitor and exit a service provider. The draft model guidance asks whether the model the provider supplies is validated, explainable and monitored. A vendor delivering a scoring engine can fall under both, so keep one vendor file that evidences each.