TL;DR:

  • RBI’s June 2026 draft guidance is not final, but it defines “model” broadly enough that a spreadsheet-based pricing calculator can count.
  • The draft does not specify a log format, an immutability standard, or an examiner retrieval SLA for audit trails.
  • It does require versioned change logs, documented impact assessments, 10-year retention of decommissioned model documentation, and RMCB reporting within three months of independent validation.
  • Third-party and vendor AI models carry the same obligation, enforced through contractual audit access rights.
  • Model Governance gives institutions the mechanics: immutable audit trail, model inventory, maker-checker approval, that the draft leaves open.

RBI’s Draft Guidance Defines “Model” by Substance, Not by What Your Team Calls It

On June 24, 2026, the Reserve Bank of India released a draft guidance document (prid=63006) for public comment, with the comment period closing July 24, 2026. It is a draft. It is not a Master Direction, and it has not been notified as final regulation.

That matters because of what the draft reportedly does inside that unfinished status: it widens the definition of “model” well past what most risk teams currently track in their model inventory. The definitional language discussed below is drawn from legal-analysis summaries of the draft circulating among compliance advisors, not from a direct quotation of RBI’s own text, and no section number is cited here because that level of detail has not been independently verified against RBI’s published PDF. What is consistent across those summaries is the shape of the definition: it turns on what a tool does, not on what your team calls it.

For a bank, NBFC, or insurer building an inventory today, that’s the operative fact. A tool doesn’t need an “AI” label, a data science owner, or a formal deployment record to fall inside RBI’s scope. It needs to do a specific kind of work.

A Spreadsheet-Based Loan Pricing Calculator Meets the Draft’s Own Illustrative Bar for “Model”

Per the legal-analysis summaries, the draft’s test for what counts as a model is substance over form: any system that takes in data and applies theoretical, empirical, or judgment-based assumptions, using statistical, mathematical, economic, financial, or other cognitive techniques, including AI/ML, and produces a result that feeds into business operations or decisions, meets the definition. Whether the entity building or using it calls it a “model,” a “tool,” a “calculator,” or a “workaround” has no bearing on whether the obligation applies.

The illustrative example cited in those summaries is specific enough to be useful on its own: a spreadsheet-based loan pricing calculator meets this bar. So does a rule-based decision script sitting in a collections queue, a vendor-supplied credit score, or an AI/ML underwriting model built in-house. The common thread across all four is what the tool does, regardless of its architecture.

That has a direct consequence for a category of reader who has never thought of themselves as a model owner. Finance and actuarial teams routinely maintain pricing spreadsheets with embedded assumptions that drive pricing or approval decisions. Under this draft, that spreadsheet has a governance obligation attached to it, whether or not it has ever been entered into a model inventory, validated independently, or assigned a version history. The gap between what these teams believe they own and what RBI’s draft says they own is the real finding here, and it’s worth surfacing before any of the compliance mechanics that follow.

Infographic explaining how spreadsheets, scoring rules, and pricing calculators can qualify as models under RBI’s draft guidance, requiring inclusion in a model inventory with ownership, risk tier, and validation date.

The Draft Does Not Specify a Log Format, an Immutability Standard, or an Examiner Retrieval Timeline

Here is the honest limit of what the draft currently says, stated plainly rather than glossed over on the way to a product pitch.

The draft, as summarized in the legal analyses reviewed for this piece, does not prescribe a technical format for audit logs. It does not define what “immutable” means in engineering terms, whether that’s write-once storage, cryptographic hashing, or something else. It does not set a timeline for how quickly an institution must be able to produce a specific model’s audit trail when an examiner asks for it.

This is a genuine, structural gap in the draft as it currently reads, unlikely to be filled by a footnote. It means two institutions could both read the draft, both believe they are compliant, and arrive at two very different technical implementations, one of which might not survive an actual examination. Any institution building toward this draft right now is building against outcomes RBI has named, not a specification RBI has handed them.

What the Draft Does Require Reads Like an Audit Trail Even Without Using the Word

Set against that gap, the draft is specific about the outcomes it wants, even where it stays silent on the mechanics:

  • Enhanced documentation for AI/ML models, covering traceability, reproducibility, and auditability of how a model reaches its outputs.
  • Versioned change logs with documented approvals for any modification to a model in production, not just major rebuilds.
  • A documented impact assessment before any material model change goes live, evaluating what the change is expected to do to the model’s outputs and the decisions built on them.
  • Independent validation reporting to the Risk Management Committee of the Board (RMCB) within three months of that validation being completed, consistent with the reporting cadence covered in our earlier post on model validation timelines.
  • A minimum 10-year retention period for the documentation of decommissioned models, tied explicitly to model inventory retention requirements rather than framed as a standalone audit-trail rule.

Read together, these five requirements describe what an audit trail is supposed to accomplish: a reconstructable history of what a model was, how it changed, who approved each change, and how long that record has to survive after the model itself is retired. The draft asks for the outcome without naming the mechanism, which is exactly the gap institutions need to close on their own.

Vendor and Third-Party AI Models Carry the Same Governance Obligation, Closed Through Contract

Outsourcing a model’s build doesn’t outsource the obligation. Per the legal-analysis summaries, a regulated entity that sources an AI/ML model or scoring tool from a third-party vendor remains responsible for that model’s governance, and the draft expects this to be enforced contractually: the entity must be able to obtain technical documentation about the vendor’s model on demand, not just at onboarding.

For institutions running vendor-supplied credit scores, fraud models, or pricing engines, this closes a door many vendor contracts leave open today. A vendor relationship that doesn’t include audit access rights, on paper, leaves the regulated entity holding an obligation it has no contractual mechanism to satisfy. Reviewing vendor contracts for this specific gap is a near-term, low-cost step institutions can take before the draft is finalized.

Model Governance Turns RBI’s Outcome Requirements Into a System of Record

None of the above tells an institution which log format to build, what “immutable” should mean in their stack, or how fast their team needs to be able to pull a model’s history when asked. That’s the part left to the institution, and it’s the part Model Governance is built to answer.

Model Governance maintains an immutable audit trail for every model in production: every change, every approval, every validation event recorded in a form that can’t be altered after the fact. It keeps a single model inventory that covers internally built models, vendor-sourced models, and rule-based tools alike, so a spreadsheet-based pricing calculator and a full AI/ML underwriting model sit in the same governed record rather than in separate, informal tracking. And it enforces maker-checker approval on model changes, so the documented impact assessment the draft calls for has a system forcing it to happen rather than relying on a team remembering to do it.

To be clear about what this closes and what it doesn’t: RBI’s draft asks for traceability, reproducibility, auditability, and retention as outcomes. It does not specify immutability as a required engineering standard. Model Governance delivers immutability as iTuring’s own way of meeting those outcomes with confidence, backed by the platform’s own security posture, SOC 2 Type II and ISO 27001, which are iTuring’s certifications and not requirements RBI’s draft itself imposes.

Infographic outlining RBI’s model governance requirements, showing traceability, reproducibility, and ten-year retention alongside mechanisms such as decision-level logging, versioned code, and immutable storage.

What Sixteen Banks and Insurers Already Have in Place

Sixteen banks and insurers currently run iTuring.ai in production, across more than 200 live use cases, with models reaching production 97% faster than institutions report under legacy build cycles. That speed is real, and it’s also not the point of this post. Speed to production only holds up under examination if the documentation required at every stage, the change logs, the impact assessments, the validation reporting, moves at the same pace as the model itself. Governance has to run alongside speed, not get bolted on after the fact once a model is already live.