The Change the Draft Never Tells You to Notice
A draft, not yet law
On 24 June 2026, the Reserve Bank of India released a draft Guidance on Regulatory Principles for Model Risk Management. Comments closed 24 July. No final circular has issued, and this piece reads the draft as a draft throughout.
It is also, clause for clause, the most serious regulatory attempt yet at describing what a model is and how a lender should own one. That is what makes it worth arguing with.
What the draft calls a model
Paragraph 3 defines a model as a system with three parts: an input, built from data and assumptions; a processing step, using statistical or cognitive techniques including AI; and an output, used for a business decision. The draft's own illustration is a spreadsheet loan pricing calculator: borrower type, tenor, credit score, and collateral value go in; a fixed set of formulas runs; a lending rate comes out.
The same inputs always take the same path through it, and a decision-based rule engine with many branches instead of one straight line still fits this shape: every branch was written by a person, so the full set can be enumerated and tested before anything goes live.
Paragraph 21 requires that no model be used unless it is in an inventory, and paragraph 22 requires that inventory to record the model's owner, developer, validator, approver, risk tier, intended use, and its dependencies with other models. None of that is hard to satisfy for a rule engine: the entry simply lists every branch the system can take, whether or not a given file walks all of them, the same way a scorecard's entry lists every feature it could weight.
Two runs, one agent
Take an illustrative case: a workflow that drafts credit memos. On one file, it extracts data from a scanned bank statement, pulls a bureau score, runs a fraud-signal check, and assembles a narrative. On another file, cleaner and smaller, the model itself, reading the statement, judges the fraud check unnecessary and skips it, a call nobody wrote a rule for in advance.
The inventory question here is no harder than it was for the rule engine: list extraction, the bureau pull, and the fraud check as steps the system is capable of calling, whether a given file uses all three or not.
What the inventory entry cannot tell you is whether this particular judgment call, on this particular document, was ever exercised during validation. A rule engine's branches are finite and were all written by a person, so pre-deployment testing can walk every one of them and be done with it. A model's judgment over a scanned document was not written by anyone, and there is no fixed list of documents to test it against.
Testing without a finite target
Paragraph 30 lists what re-triggers validation: deployment, modification, an internal or external trigger, or periodic review. Paragraph 42 asks the regulated entity to define its own threshold for what counts as a material change. For the rule engine, this is already complete. Every branch was enumerated and tested in advance, so a new file walking an already-validated branch is not a change, and paragraph 30 is right to leave it alone.
For the model exercising judgment on an undocumented case, testing across many files cannot claim the same completeness, because the input is not a finite set of branches to walk. A thousand test files, or a hundred thousand, do not close an open set the way four branches close a decision tree. Volume of testing is not the same thing as coverage when there is no fixed denominator to have covered.
What the draft already handles
To be precise about what the draft does anticipate: paragraph 52 already requires tiering to weigh a model's autonomy and the extent of reliance placed on its outputs, assigned once to the object and reviewed at least annually, not recomputed per file. Paragraph 54(7) already requires ongoing monitoring for data drift and concept drift. Paragraph 55 already requires red-teaming, specifically for models with customer interaction or generative capabilities.
RBI has not missed the open-ended input problem. Chapter V.B is built for exactly it, not by trying to enumerate every case in advance but by watching production behavior over time and probing it deliberately. What is missing is not a control. It is a wire between two controls that already exist: nothing in the text says a finding from drift monitoring or red-teaming is supposed to feed back into paragraph 42's definition of a material change.
The wire that isn't there yet
The draft is candid about its own scope. Paragraph 2 notes that further requirements specific to AI models may follow. Chapter V.B already carries the controls a judgment-driven system needs: drift monitoring, red-teaming, confidence scoring. What it does not carry is an instruction to read those controls' findings back into Chapter III.
Paragraph 42 leaves each regulated entity to define its own threshold for a material change. For a system that composes its path from a model's judgment rather than a rule table, that definition has to include something paragraph 42 does not spell out on its own: production behavior, or a red-team finding, landing outside what the original validation sample covered. Paragraph 56 makes this explicit for a model that updates its own weights. Nothing makes it explicit for a model whose weights never move but whose judgment meets a document type it was never tested against.
Write that threshold into the MRMF before an examiner asks why it was missing, not after a red-team exercise turns up a case nobody had validated. Whoever owns that definition, in the sense paragraph 22 means by owner, is doing the actual work Chapter III and Chapter V.B were meant to do together.