Your rules engine is a model now

On 24 June 2026 the Reserve Bank issued a draft Guidance on Regulatory Principles for Model Risk Management, 2026 (Press Release 2026-2027/528), with public comments invited until 24 July. It remains in draft at the time of writing, and no implementation timeline has been announced — that is expected to arrive with the final guidance. Nothing below should be read as describing an obligation currently in force.

Source: the full text of the draft Guidance, Reserve Bank of India, Press Release 2026-2027/528, 24 June 2026. Paragraph references below are to that text. It is cited by press release number because the document reference on the draft is still a placeholder. This analyses the draft as issued, and will be updated when the final guidance is published.

It is still worth reading carefully now, for one reason: the definitional change in it is larger than the compliance burden, and it lands on systems most institutions do not currently think of as models at all.

The definition is functional, not technical

Earlier RBI material on model risk sat inside credit risk management, and the draft says plainly that the final Guidance, after public consultation, would supersede Chapter 3 on Credit Risk Models of the 2002 Guidance Note on Credit Risk Management (para 64). The instinct that follows is to scope this exercise to credit scorecards and PD models.

The draft does not permit that. Para 7(3) defines a model by function: a system that takes inputs, applies processing logic, and produces results used for decision-making. It expressly includes algorithms, analytics, interfaces, applications and decision-based rules which, by virtue of their use, materially affect decisions — irrespective of whether such tools are recognised as models by the RE. Third-party models are inside the same definition.

If it takes inputs, applies logic, and changes what happens to a borrower, it is a model — whatever your org chart calls it.

The draft makes the point with its own illustration, and it is a spreadsheet: a loan-pricing calculator is, in isolation, a basic mathematical tool — but where an institution uses it to derive lending rates, customer margins or credit terms, taking in borrower type, tenor, credit score and collateral value, it is a model. The distinction being drawn is not about sophistication. It is about consequence.

For a collections function specifically, that is a wider net than it first appears. The DPD bucketing logic. The rules deciding who gets a call versus a message. The allocation sheet that assigns accounts across agencies. The propensity score a vendor supplies. Each takes inputs, applies logic, and materially changes what happens to a borrower. Each is in scope on this reading.

Who it applies to

Substantially the whole regulated perimeter (para 4): commercial banks including foreign banks, small finance banks, payments banks, local area banks, regional rural banks, urban and rural cooperative banks, NBFCs across all layers, all-India financial institutions, asset reconstruction companies, and credit information companies.

Notably for collections, ARCs are named. So is every NBFC layer, not only the upper ones.

What it asks for

• A board-approved Model Risk Management Framework covering all models, internal or third-party (para 9), with high-risk models approved by the Risk Management Committee of the Board (paras 12(1) and 18(ii)).
• A living model inventory covering active, inactive and decommissioned models (para 21) — not a one-off stocktake, but a maintained record of what is running, who owns it, and what it does.
• Independent validation by the institution itself, expressly notwithstanding any validation, certification or assurance the vendor provides (paras 29 and 46(i)).
• Retention of decommissioned models in the inventory for at least ten years (para 23).

The inventory is the item most likely to be underestimated, because the draft does not treat it as a register kept for the auditor's benefit. Para 21 requires an institution to ensure that no model is used, relied upon, or deployed unless it is part of inventory. That is a gate on production rather than a record of it — and a gate is a materially different thing to build. It implies someone owns the entry, someone approves it, and a deployment that skips it is a control failure rather than a documentation gap.

The retention clock is subtler than it first reads, and the detail matters. The ten years run from the date of decommissioning or the date the model ceases to serve as a backup or benchmark reference, whichever is later. A model you retired two years ago but still run as a challenger benchmark has not started its clock at all. Institutions that keep old scorecards around for comparison — which is most of them, and is good practice — are holding models whose retention period has not yet begun.

The clause that matters if you buy software

Third-party models are in scope, and the draft is direct about where responsibility sits. Para 45 states that an institution acquiring, using or relying upon a third-party model, at any stage of its lifecycle, is accountable for its outcomes. The principle underneath that is simple: outsourcing the model does not outsource the risk.

Concretely, a regulated entity is expected to:

• Independently validate the vendor's model, notwithstanding any validation, certification or assurance the vendor provides (para 46(i)).
• Conduct due diligence before acquisition or use — the provider's credibility, the model's methodological soundness and its limitations, and the suitability and quality of the data behind it (para 47).
• Contract for technical documentation sufficient to understand the model's design, configuration, assumptions and operation — and sufficient to validate it (para 48).
• Contract for audit rights for the institution and its supervisory authority, directly or through external experts, together with continuity and exit arrangements (para 48).
• Put the model under enhanced oversight by the Risk Management Committee of the Board, irrespective of its risk tier (para 46(ii)) — a vendor model does not get to be low-risk enough to escape board-committee attention.

That fourth item is stronger than the phrase "audit rights" usually implies in a software contract. The draft asks for audit access not only for the institution but for its regulator. It is a fair thing to raise in a first commercial conversation, and a revealing one: a vendor comfortable with institutional audit but uneasy about regulator audit has told you something about what an audit would find.

This is the part worth raising with vendors early, because it is the part most likely to be unanswerable late. A vendor that cannot tell you which model version produced a given decision, what changed at the last retrain, or how its inputs have drifted since deployment, is a vendor whose model you cannot independently validate — and the obligation to validate is yours, not theirs.

The AI-specific controls

Where models are AI or ML systems, and particularly where they face customers, the draft adds a further set of expectations: explainability and transparency thresholds and behaviour testing under adversarial and edge conditions (para 54), structured challenge including red-teaming (para 55), controls against prompt injection and adversarial inputs, disclosure to users that they are interacting with an AI system and its limitations (para 59), human-in-command arrangements, override, suspension and kill-switch mechanisms, and periodic human review of model-driven decisions (para 60) — with explicit attention to automation bias, over-reliance on model outputs, and decision fatigue (para 61).

For anyone running or planning voice AI in collections, that list is the specification. It is worth designing against now rather than retrofitting, because several of those items — override paths, disclosure, transfer to human — are architectural rather than cosmetic.

The clause collections should read twice

Para 25 is two sentences long and easy to skim past. An institution should not use any model that harms consumers, and its grievance redressal mechanism should also address grievances arising from consumer-facing models.

In a collections context that is more demanding than it sounds. Answering a borrower's complaint about a contact they should not have received means tracing that contact back through whichever logic selected them, at whichever agency or channel made it, on the day it happened. Most institutions cannot currently do that — the allocation sheet, the dialer, the agency's own record and the complaint all live in different places, and nothing joins them.

Worth noting that the DPDP Rules land on the same requirement from the other direction: grievance redressal has to work even where the interaction was conducted by an agency rather than the lender. Two regimes, arriving separately, both asking an institution to trace a borrower complaint back to the decision and the channel that produced it.

What is reasonable to do while it is still draft

Not much, and that is a considered answer. Building a control framework against a draft that may change is how institutions end up with expensive machinery aimed at the wrong target.

The exception is the inventory. Knowing which systems in your collections stack take inputs, apply logic, and change borrower outcomes is useful whatever the final text says. It is a prerequisite for every other requirement — and, if the deployment gate survives into the final text, the thing every future release has to pass through. It takes real calendar time to assemble across business units and vendors, and it has independent value: most institutions discover during this exercise that several consequential decisions are being made by logic nobody currently owns.

The second no-regret move is contractual. If you are signing or renewing a vendor agreement now, the technical-documentation and audit-rights clauses are much easier to insert at signature than to negotiate afterwards under regulatory pressure.

The question to put to any vendor

Not "are you MRM compliant" — nobody is, and nobody can be, while the guidance is in draft and no timeline exists. Any vendor claiming otherwise is telling you something about their diligence rather than their controls.

The useful questions are narrower and answerable today:

• Which version of your model produced this specific decision?
• What changed at the last retrain, and when was it?
• How have the input distributions moved since deployment?
• Can I see the logic that fired on a given account — not just the output?
• Will you commit contractually to technical documentation, audit access for us and our regulator, and exit arrangements?

A vendor that can answer those has the evidence base an independent validation needs. A vendor that cannot will make that validation your problem to solve without them.

One last thing worth holding in view. Para 2 notes, referring to Utkarsh 2029, that further requirements applicable to AI models may be issued later. Whatever the final text of this guidance says, it is unlikely to be the last word — which argues for building the evidence base rather than the specific control, because the evidence base is what every version of this will ask for.