TL;DR
- RBI’s draft Model Risk Management guidance defines a model as any system that takes inputs, applies quantitative logic, and produces outputs used for business decisions, regardless of what the institution calls it. Bureau cutoff rules, pricing spreadsheets, and vendor AI tools all qualify.
- The guidance’s key phrase, “irrespective of whether such tools are recognised as models by the RE,” means the institution’s own classification carries no regulatory weight. The three-part test is the only one that matters.
- Para 21 creates a use prohibition, not a documentation standard. Any model that qualifies under Para 7(3) but is not in the inventory cannot be used once the final guidance comes into force. This applies from day one of enforcement.
- The model inventory must carry specific fields for every model: owners, developers, validators, approvers, risk tier, intended use, dependencies, and key validation findings. These fields apply to vendor and third-party models as well as internally built ones.
- Decommissioned models must remain in the inventory for at least ten years. Institutions that deleted models and records when retiring them are already carrying a gap they cannot reconstruct.
Think of the last three quantitative decisions your institution made. A lending rate was set. A collection account was routed to an agent. A loan application was declined. For each one, ask: did a tool take an input, apply some logic to it, and produce an output that drove that decision?
If the answer is yes, that tool is a model under RBI’s draft guidance on Model Risk Management.
It does not matter whether the data science team built it. It does not matter what it runs on. It does not matter whether anyone in your institution has ever called it a model. Para 7(3) of the draft guidance defines a model as any system that incorporates data, applies quantitative techniques, and produces results used for business decisions. The guidance then adds a phrase that closes every instinctive objection in advance: the definition applies “irrespective of whether such tools are recognised as models by the RE.”
Most institutions that say they have 20 models have 150 to 300 by this definition. That arithmetic is not a statistic. It is a pattern observed across institutions when the Para 7(3) test is applied to every decision-supporting system in production. The count is almost always a surprise.
The phrase that ends the “it is just a spreadsheet” argument
Para 7(3) defines a model in three parts. The input component: the tool incorporates data and applies judgement-based assumptions. The processing component: it uses statistical, mathematical, economic, or financial techniques to analyse and interpret relationships. The output component: it produces results used for business decisions or operations.
The guidance then makes a specific point about awareness. It notes that tools with “a material impact on decision-making in various business processes” are included in the definition regardless of whether the RE recognises them as models. This is not an incidental observation. It is a deliberate signal that RBI has anticipated the “we did not know it was a model” defence and declined to accept it.
The spreadsheet illustration in Para 7(3) makes this concrete. A loan pricing calculator that takes borrower type, tenor, credit score, and collateral value as inputs, applies interest rate grids, risk-weighted spreads, and margin formulas, and produces a final lending rate is a model. The same spreadsheet used only for arithmetic is not. The line is whether the tool produces an output that affects a business decision. On the right side of that line, the format is irrelevant.
“It includes algorithms, analytics, interfaces, applications, decision-based rules, and other computational tools which, by virtue of their use, have a material impact on decision-making in various business processes, irrespective of whether such tools are recognised as models by the RE.”
— RBI Draft Guidance on Regulatory Principles for Model Risk Management, Para 7(3), June 2026
Where the hidden models live
The models a bank’s analytics team built and formally named are the visible ones. They are already in whatever register the institution maintains. The count problem comes from everything else.
Bureau cutoff rules. A rule that rejects any applicant with a bureau score below a threshold takes a score as input, applies a decision threshold, and produces a routing outcome that determines whether an application proceeds. It passes the three-part test. It is a model. Compliance teams who have maintained these rules as credit policy documents will need to revisit that classification.
Rate grids and pricing matrices. A tool that calculates customer interest rates from borrower type, tenor, credit score, and collateral value, then outputs a final lending rate through margin formulas and risk-weighted spreads, is the exact example RBI provides in the guidance itself. If the output affects what rate a borrower receives, the tool is a model.
Operational macros and VBA calculators. A collections team’s macro that calculates expected recovery by account, ranks accounts, and routes them to agents qualifies. The fact that an analyst built it in Excel for operational convenience does not change what it does.
Vendor-embedded scoring. A CRM platform that ranks customers by churn propensity contains an embedded model. A digital lending platform that generates an internal credit score before routing an application to a bureau carries a model inside it. The vendor built it. The institution uses it. Under Para 6 of the draft guidance, the regulatory principles apply to all models used by a regulated entity, regardless of origin.
AA-connected underwriting engines. The most current example in Indian lending. A fintech partner provides an underwriting engine that ingests Account Aggregator-sourced bank statement data, applies its model, and returns a credit recommendation. The institution takes the recommendation and routes the application. That engine is a model the institution is accountable for, even if it cannot inspect its internals.
Champion-challenger variants in production. When an institution runs two versions of a credit model simultaneously to compare performance, both versions qualify. Both require inventory entries. Most institutions count one.
Decommissioned models still referenced as benchmarks. If an older model’s output is used to calibrate or challenge a newer model, the older model has not been fully decommissioned. It is still in active reference use. It is a model, and it belongs in the inventory.
The rule that makes the count a compliance problem
Knowing you have more models than you counted would be a governance observation if Para 21 were a documentation requirement. Para 21 is a use prohibition.
The text reads: “It should ensure that no model is used, relied upon, or deployed unless it is part of inventory.”
On the day the final guidance comes into force, any tool that passes the Para 7(3) test and is not in the inventory cannot be used. Not until it is inventoried. The bureau cutoff rule that has been operating for six years and that nobody has ever called a model cannot be used on day one of enforcement if it has no inventory entry. This is a production risk, not a documentation project.
Para 22 sets the minimum fields the inventory must contain for every model: model owners, developers, validators, and approvers; risk tier; intended use; dependencies with upstream and downstream models; and key observations from validation, monitoring, and audit.
For models deployed years ago, some of these fields will require reconstruction. Owner and intended use can typically be established. Independent validator and validation observations often cannot, because the validation was never conducted by someone independent of the development team. That documentation gap requires either retrospective remediation or a validation programme that covers the existing portfolio before enforcement begins.
The 10-year sting for retired models
Para 23 of the draft guidance states that decommissioned models must remain in the inventory for at least ten years from the date of decommissioning, or from the date they cease to serve as a backup or benchmark reference, whichever is later.
Most institutions delete models when they retire them. The model’s files are archived or removed. The documentation follows. Para 23 means a model decommissioned today must remain in the inventory until 2035. A model retired in 2018 that an institution is only now learning must be inventoried requires records from eight years ago that may no longer exist in any recoverable form.
The window to reconstruct documentation from institutional memory is not infinite. The people who built a model in 2016 may have left. The business rationale that determined its scope may exist only in email chains. The more time passes, the harder reconstruction becomes. Starting the inventory sweep now is the only option for institutions that want to close this gap before an examiner finds it.
How to build the inventory in practice
The inventory build has four steps.
Step one: The discovery sweep
The goal is to find every tool that might qualify under Para 7(3) before applying the test. Interview four functions: the analytics and data science team for their formal model list, the operations team for every tool they use daily to make or route decisions, the technology team for every API call in production that returns a score or classification, and the vendor management function for every third-party platform with embedded scoring or decisioning. Cross-reference the results against production systems. The count from this sweep is the actual model count.
Step two: Apply the Para 7(3) test
For every tool identified, ask: does it take structured inputs, apply quantitative logic, and produce an output used in decisions? If yes to all three, it goes in the inventory. Borderline cases should be included with a documented rationale for the classification. Exclusions carry more examination risk than inclusions if the tool is later found to qualify.
Step three: Populate the Para 22 fields
For each model in the inventory, assign a named owner, document the intended use, record the developer and approver, and note the validation status honestly. If independent validation has not been conducted, note that specifically. An honest record of a gap is better governance than a gap with no record. This observation will surface anyway. It is better to surface it internally than to have an examiner surface it.
Step four: Tier every model
Para 17 to 20 require a risk tier for each inventoried model based on materiality, complexity, and regulatory considerations. The tier governs everything downstream: validation frequency and intensity, approval authority for deployment, monitoring scope, and documentation requirements. Para 20 is explicit that a low complexity score cannot disproportionately reduce the overall risk tier of a highly material model. The composite risk profile determines the tier.
Where iTuring fits in this process
Steps three and four of the inventory build are where most institutions stall. Populating Para 22 fields across a portfolio of 150 to 300 models manually, with accurate validation status, dependency mapping, and risk tier documentation for each, is a substantial operational undertaking. Keeping that inventory current after the initial build compounds the challenge.
iTuring’s Model Gov platform maintains a centralised inventory covering models built within the iTuring environment, models deployed through external frameworks (Python, R, SAS, PyTorch), and third-party models. Every entry in the inventory carries the Para 22 fields, along with the model’s version history, approval chain, and change log. When a model changes, the inventory updates. When a validation observation is recorded, it flows into the inventory record. The examination-ready documentation exists as a by-product of operation rather than as a pre-examination project.
For institutions beginning the inventory build for the first time, the iTuring readiness review produces a first-draft inventory that structures the Para 22 fields across the production portfolio and identifies where the validation gaps and documentation gaps lie.
The inventory is the foundation for everything that follows
Risk-based tiering, independent validation, RMCB approvals, change management, decommissioning records: every requirement in the guidance depends on the inventory being accurate, comprehensive, and current.
An institution that begins the tiering framework without a complete inventory will tier an incomplete model population. An institution that begins the validation programme without a complete inventory will validate the visible models and leave the invisible ones ungoverned. An institution that presents RMCB reporting without a complete inventory will present a governance picture that does not reflect its actual model risk exposure.
The inventory sweep is the prerequisite. Everything else follows from it.
If an RBI examiner walked into your institution tomorrow and asked to see the complete model inventory, how long would it take to produce it, and how confident would you be that it covered everything in production?
