Picture an examination five years from now. A bank’s credit model has done something it should not have, and the supervisor has come to see how it was governed. The bank produces its Model Risk Management Framework, board approved. Its validation reports, signed. Its monitoring policy, versioned. Its committee minutes, complete. Every document the regulation asked for exists, is current, and is internally consistent.
And none of it can answer the only question in the room. What was actually operating on the day the decision was taken?
The binder describes a control environment. The examiner needs to know whether the controls ran. Between those two things sits the entire difference between a regulation that works and a regulation that produces paper, and that difference is what my feedback to the Reserve Bank of India was about.
On 24 June 2026 the RBI published its draft Guidance on Regulatory Principles for Model Risk Management and invited public comments until 24 July. I submitted mine on 22 July, in a personal capacity, no client, no employer, no commercial mandate. Six themes, each tied to the paragraphs it concerns, each with a concrete suggestion the drafting team can accept, adapt or reject with minimal effort. The full submission is attached with this essay, and now that the window has closed I want to explain what it says and why I bothered, because the why matters beyond banking and well beyond India.
Start with credit, because the draft has earned it
Regulatory comment has a bad habit of reading like a list of grievances. So let me be clear about something first. This is the best-aimed document I have seen a financial regulator produce on model risk in the AI era, and its best choice is its first one.
The draft defines a model by what it does, not by what it is made of. A spreadsheet that sets lending rates and a large language model face the same threshold question, namely what decisions does this influence and how material are they. That sounds like a technicality. It is the whole game. The incidents that reach consumers almost never announce themselves as coming from a recognised model. They come from the scoring widget a vendor bundled into the onboarding flow, the rule someone embedded in a workflow in 2019, the spreadsheet nobody calls a model because it is only a spreadsheet. A definition organised by technique would miss every one of them. A definition organised by decision impact catches them all, and the RBI chose the second. My submission names that choice first among the draft’s strengths, and the Bank should hold the line through finalisation, because pressure to narrow it will come.
Two more choices deserve naming. The draft puts model risk ownership at the board, where it belongs, and it treats AI as a matter of degree inside one framework rather than quarantining it in a separate regime. Anyone who has watched parallel rulebooks drift apart knows how much future confusion that second choice just prevented.
The one word the draft is missing
Nearly every operative paragraph of the draft requires that something be documented, recorded or reported. Here is the problem, and it is the spine of my entire submission. Documentation establishes that a control was designed. It does not establish that the control operated when a specific decision was taken.
A policy binder can be complete and current while the deployed model, its data and its approvals have quietly drifted away from everything the binder describes. When the examination comes, the supervisor will be comparing paper with paper. For traditional statistical models this gap is uncomfortable. For AI models it is fatal, because their behaviour changes with data, with versions, and with provider updates that arrive from outside, unannounced and technically compatible. The document describing the model you validated can be perfectly accurate about a model that no longer exists.
The word the draft needs is demonstrability. Records generated at or near the moment of the event they describe, protected against alteration, sufficient to reconstruct what the model was, what data and assumptions it relied on, and what approvals were in force when a given decision was taken. That is the submission’s Theme E, tamper-evident and independently verifiable records for validation outcomes, change logs, traceability and the oversight record, and it costs regulated entities almost nothing extra, because the systems that execute the decisions can produce those records automatically. The requirement changes only what counts as an answer. And because a claim like that invites the obvious retort, I noted in the submission that I have built a working reference implementation that produces such sealed, independently re-verifiable records, so the property can be evidenced today. The suggestion is practical, not aspirational, and it asks the Bank to adopt no proprietary method, since the property of verifiable integrity is available in commodity form from more than one source.
Six themes, one idea through six doors. A framework of this kind succeeds when a regulated entity can show, and an examiner can verify, that the controls it describes actually operated on the decisions that reached customers. Everything else in the submission is that sentence applied to a different paragraph.
What the doors open onto
Theme E is the spine above. The other five doors carry the argument outward, and they show how far it travels.
Oversight should be measured, not merely present — The human oversight paragraphs are among the strongest in the draft, and my submission says so. But as drafted, an entity could satisfy them by placing a human next to a decision with no evidence the human is exercising judgment. A reviewer who approves nearly everything provides the appearance of oversight while functioning as a liability sponge, and decades of automation research say that approval rates near one hundred percent signal rubber stamping, not excellence. I asked for quantitative oversight-effectiveness indicators reviewed by the risk committee, an override rate with unusually low values triggering review, a blind-acceptance indicator catching approvals with no sign of genuine engagement, review latency and reversal rates on human-approved cases. And one design rule beneath them all, recording a dissent should cost the reviewer no more than clicking approve, otherwise the mechanism is structurally biased toward agreement no matter who sits in the chair.
A kill switch needs somewhere to land — The draft requires override, suspension and deactivation mechanisms, including kill-switch arrangements, and that is welcome. But a switch that stops a model mid-process without a defined landing state converts a model incident into an operational outage, and the hesitation that possibility creates is precisely why such switches are not thrown in time. Declare the trigger conditions and the authority in advance, define the safe state the process falls back to, queue and hold, abstain, route to a human, and keep a tamper-evident record of every invocation. For models that update automatically, the deactivation authority should be able to revert to the last validated state, not merely stop the current one. A stop button nobody dares press is decoration.
Test the collisions, not just the attacks — The draft requires structured challenge including red teaming, and explainability thresholds for AI models. Both are right, and both need one more turn of the screw. Red teaming as practised today means adversarial testing, jailbreaks and prompt injection, which is necessary and structurally blind to the most common real-world failure of customer-facing models, the one where no rule is broken and no attacker is present. The Air Canada chatbot that invented a refund policy was a collision between two legitimate objectives, being helpful and respecting institutional authority. I asked that structured challenge expressly include behavioural testing of how the deployed system resolves conflicts between its legitimate objectives, and that explainability thresholds be expressed in verifiable terms rather than as unfalsifiable narrative.
The vendor asymmetry needs a standard artifact — The draft places the validation burden on the regulated entity while the information needed to discharge it sits with the vendor. Left alone, every bank negotiates documentation clauses by itself, every vendor answers a hundred differently worded questionnaires, and the equilibrium is thin disclosure that satisfies the contract and defeats the purpose. I proposed a standard inherited-risk disclosure that travels with any third party model, the provider’s residual-risk register, the conditions under which its assurances hold, and the foreseeable-reliance limitations. Call it a model risk inheritance statement. It gives due diligence a defined object, gives a small bank a fighting chance against a much larger vendor, and I asked that a provider-driven update be named expressly as a change-management trigger, because a silent capability change alters the model without any action by the entity.
Read the framework beside the data protection law — A credit model, a fraud engine, a collections assistant, each is at the same moment an activity of processing personal data under the DPDP Act, 2023, and the two regimes are two readings of the same system. The difference is procedural and it has teeth. This framework is proved at a periodic inspection on the supervisor’s initiative. The data protection regime reverses the burden of proof onto the fiduciary, makes the duty non-delegable so it cannot be contracted to a vendor, and arms its regulator with the production powers of a civil court. The same governance records this framework asks for are separately required, and separately provable, under law that already applies. I asked the Bank to acknowledge the intersection, because a single tamper-evident governance record can discharge both duties at once, and an entity that builds two parallel programmes is paying twice for one obligation and risking contradiction between its own files.
Why submit at all, and why publish this
I sent the feedback because comment windows are where regulation is actually written, and because the community that understands these failure modes is small and mostly does not write to central banks. The overlap between people who have watched an assumption decay inside a production model and people who read paragraph 42 of a draft guidance is not large. When a regulator gets the foundation this right, the useful response is not applause or critique from a distance. It is specific text, tied to specific paragraphs, that the drafting team can accept, adapt or reject with minimal effort.
I am publishing it because regulatory comment should be a public act. A submission that lives in a regulator’s inbox serves the drafting team. The same submission in the open serves everyone writing the next framework, in another sector or another country, and there will be many. Central banks and supervisors everywhere are drafting their versions of this document right now, and they are all facing the same fork, a documentation standard that audits binders or a demonstrability standard that audits reality.
The greater good argument is not abstract. Model-driven decisions decide who gets credit, at what price, whose claim is flagged, whose account is frozen. When those decisions go wrong, the dispute arrives years later, the people who built the model are gone, and the record is whatever the framework required it to be. A documentation standard means the customer’s dispute is answered by a binder. A demonstrability standard means it is answered by evidence of what actually ran. Effective regulation is the difference between those two answers, and it protects honest institutions just as much as it protects their customers, because an institution that can prove what it did is also an institution that cannot be falsely accused of what it did not do.
The draft ends by contemplating further AI-specific requirements to come. Whatever shape they take, the same test should travel with them, and for the growing share of models that process personal data, a second law is already asking the same question with the burden reversed. An institution that builds one tamper-evident governance record answers both, and an institution that builds two parallel binders has bought itself two costs and one seam. That is the direction all of this points. Regulation that can be verified, not just filed.
The Reserve Bank has written a strong draft. The distance from strong draft to enforceable standard is six themes and one changed word. Show, don’t file.
The full submission. All six themes with paragraph references, submitted to the Department of Regulation on 22 July 2026, are available here as submitted.
Download the full submission (PDF) →
Dr. Anandkumar Prakasam holds a PhD in Computer Applications and an LLB (Hons), is the author of a five-volume body of work on AI and data governance, and writes The Forensic Brief. The submission was made in a personal capacity and asks the Reserve Bank to adopt no proprietary method.
#TheForensicBrief #ModelRiskManagement #RBI #AIGovernance #BankingRegulation