RBI Just Redefined What Counts as a 'Model'
I spent the last few days reading RBI's draft model risk guidance. The headline is not AI. It is that RBI just redefined what counts as a 'model,' and a pricing spreadsheet now qualifies.
I spent the last few days reading RBI’s draft Guidance on Regulatory Principles for Model Risk Management, 2026. I went in expecting another AI circular. I came out convinced it is something bigger.
Read it closely and the message is plain. If a model, rule, calculator, algorithm, AI system, third-party tool, or decision workflow materially influences a business decision, the regulated entity must know it, own it, validate it, monitor it, and explain it. That one sentence reorders the question every lending CRO is asking.
The conversation stops being “are we using AI safely?” and becomes “can we prove governance over every system that influences a lending decision?”: credit scorecards, BRE rules, pricing calculators, bureau models, alternate-data models, AI copilots, third-party APIs, co-lending decision flows, collections models, and customer-facing AI. All of it.
- RBI defines “model” by what it does, not how it was built. A pricing spreadsheet or a BRE rule can be a “model” if it shapes pricing, eligibility, approval, rejection, or collections.
- Model risk is no longer a data-science problem. It is a board, risk, compliance, credit, technology, vendor, and operations problem: seven functions, one discipline.
- NBFCs are explicitly in scope across the scale-based layers. Base, Middle, Upper, Top: expectations rise with size and systemic importance.
- Digital lenders will be asked for evidence. Even when the bank or NBFC is the regulated entity, the app, the LSP, and the co-lending partner have to show their work.
- Readiness beats waiting. Build the inventory, assign owners, tier by risk, and assemble a board pack, before the regulator, the auditor, or the board asks.
- The winners will not be the lenders with the most AI. They will be the ones who can prove control over AI, models, rules, vendors, and decisions.
This runs long by design: it is three guides in one. Find your situation below, read that path first, and use the “back to the guide” links to jump around.
Or jump to: What RBI is asking · Why “model” changes everything · Where to start · Who should own it · The 10-question test · Where Lokta fits
What is RBI actually asking for?
Most coverage of this draft will file it under “AI regulation.” That is the smaller half of the story. The bigger half is a definition.
RBI defines “model” so broadly that the system’s pedigree stops mattering. What matters is whether it moves a decision. A spreadsheet that prices a loan and a deep-learning underwriting model are, for governance purposes, the same kind of object.
That single move is what makes this guidance load-bearing. It draws a line around every system that influences a lending decision and says: this is now governed territory. You own it, you validate it, you monitor it, and (the part most stacks cannot do today) you can explain it.
And it is not a light tweak to existing rules. Once final, the guidance is set to supersede the credit-risk-model chapter of a guidance note that has stood since 2002. The bar that governs how lenders build and run decision models just moved for the first time in over two decades, and it moved to cover far more than credit models.
Why does RBI’s definition of “model” change everything?
Because it relocates model risk out of one team and spreads it across the whole org. A spreadsheet-based pricing calculator, a BRE rule, or a decisioning workflow becomes a “model” if it affects pricing, eligibility, approval, rejection, collections treatment, or customer outcomes. The moment that is true, model risk management stops being something the data-science team owns in a corner.
- The data-science model and the BRE rule sit under the same expectation: owner, risk tier, validation, monitoring, explainability.
- The pricing calculator and the deviation matrix stop being “just how we work” and become decision assets the auditor can ask about.
- The third-party API and the co-lending decision flow are in scope even though someone else built them, because they move your customer’s outcome.
What does this mean if you’re a bank?
For banks, the direction is unambiguous. Model risk has to become a formal governance discipline with a Board-approved framework behind it: taxonomy, inventory, risk tiering, ownership, validation, approval, monitoring, change management, exception management, third-party models, AI/ML controls, human oversight, business continuity, and decommissioning.
The Board and Risk Management Committee will need real visibility into high-risk models, validation reports, exceptions, breaches, third-party models, and AI models. The shift is from model usage to model accountability: every material decisioning system becomes visible to governance, and for each one, someone has to answer a fixed set of questions.
Who owns it? What is its intended use? What is the risk tier? Who validated it, and who approved it? What changed recently? Is it monitored? What exceptions exist? Can it be suspended or overridden, and can its output be explained? If the bank cannot answer these for a credit model, a pricing engine, a fraud score, or a third-party API, that system is a finding waiting to happen.
This becomes part of enterprise risk governance, internal audit, model validation, and board reporting, not a data-science deliverable. The framework is approved at the Board, owned by the CRO, and evidenced by everyone whose system touches a decision. A policy document is not the deliverable. The evidence is.
What does this mean if you’re an NBFC?
Do not read this as bank-only thinking. The draft explicitly applies to NBFCs across all four scale-based layers: Base, Middle, Upper, and Top. One caveat worth being precise about: it does not write a separate rulebook for each layer. It applies one set of principles to all of them, to be implemented “commensurate with the nature, scale and complexity” of the entity and the materiality of its models. That proportionality clause is what makes the same expectation land differently depending on where you sit.
What does this mean if you’re a digital lender?
Digital lenders should pay the closest attention, because they operate through the most complex chains: digital lending apps, lending service providers, partner banks or NBFCs, co-lending arrangements, bureau APIs, account-aggregator data, alternate-data underwriting, BRE engines, fraud models, AI assistants, and customer-communication workflows.
Here is the nuance to be honest about: this draft does not name digital lenders, lending apps, or LSPs anywhere. Its regulated entities are banks, NBFCs, and the like. The pull-through is structural, not explicit. The draft makes the regulated entity accountable for third-party models at every stage of the lifecycle, requires it to independently validate them “notwithstanding any validation, certification, or assurance provided by the third-party provider,” and demands audit rights written into the contract. So even when the bank or NBFC partner is the regulated entity, the digital lender, the LSP, or the co-lending partner is the one that has to produce the evidence the partner is now on the hook to show. That is where vendor reviews and AI adoption get harder at once.
Which models or rules influenced eligibility and pricing? Which partner owns which decision? Which third-party APIs influenced the outcome? In a co-lending stack, “the model” is rarely one thing: it is a chain, and you have to be able to draw it.
What data was used? What changed in the decision logic, and when? Where was human oversight applied? The partner’s auditor will ask, and “the vendor handles that” is no longer an answer the regulated entity can accept.
Can the decision be explained? Can a customer grievance be traced back to a specific model, rule, or workflow? The lender who can prove governance faster is the easier one to partner with: model-risk readiness becomes a commercial advantage, not just a compliance cost.
Where should you start?
Do not wait for the final version. Start with readiness. Six moves get a lender from “we have policies” to “we have evidence”, and the first one is the one most stacks quietly skip.
Models, BRE rules, calculators, scorecards, spreadsheets, AI agents, prompts, APIs, vendor tools, co-lending workflows, manual overrides. If it affects eligibility, pricing, approval, rejection, treatment, collections, or risk monitoring, it goes in the inventory. The draft is blunt about this: no model should be used, relied upon, or deployed unless it is part of the inventory, and decommissioned models stay in it for at least ten years.
Every asset needs a business owner, a model or rule owner, a technology owner, a validator, an approver, and (if third-party) a vendor owner. No owner means no accountability.
Tier by materiality, consumer impact, financial impact, complexity, explainability, autonomy, third-party dependency, AI/ML usage, and regulatory sensitivity. High-risk assets earn stronger validation, approval, monitoring, and committee oversight.
Which high-risk models and rules do we use? Which are validated? Which have exceptions? Which changed recently? Which third parties influence decisions? What incidents or overrides exist? If you cannot produce this quickly, you have a readiness gap.
LSPs, bureau and data providers, AI, model and BRE vendors, KYC/AML providers, co-lending partners. For each: what decision do they influence, what data do they use, do we have audit rights, and what is the fallback if their model behavior changes?
Before AI scales in a lending workflow, define the use case, data access, customer impact, autonomy level, human oversight, explainability threshold, hallucination controls, bias and fairness checks, prompt and API security, escalation path, and kill switch. The safest AI strategy in lending is not “move fast.” It is “move with evidence.”
Who should own model risk management?
The mistake would be to say “this belongs to data science.” It does not. Model risk management needs an operating model where ownership is shared but unambiguous: each function owns one thing, and one of them owns the frame.
| Function | What it owns | The one thing it answers |
|---|---|---|
| Board / Risk Management Committee | Oversight: approves the framework, reviews high-risk models, monitors exceptions. | Are we seeing the evidence, or just the policy? |
| CEO / MD | Enterprise accountability: keeps this from becoming a checklist buried in one department. | Is this owned across the org, or parked in a corner? |
| CRO / Chief Risk Officer | The framework: the primary executive owner where model, credit, operational, third-party, AI, and consumer risk meet. | Does the framework actually hold under audit? |
| Compliance | Regulatory interpretation, evidence readiness, RBI mapping, policy alignment. | Can we show the regulator what they will ask for? |
| Credit policy / business | The actual decision logic: scorecards, policy rules, eligibility criteria, pricing, deviation matrices. | Is the logic we run the logic we documented? |
| Technology / CTO | System integration, audit logs, access controls, APIs, versioning, evidence capture from source systems. | Can we capture the evidence at source, automatically? |
| Data science / analytics | Model development documentation, assumptions, limitations, validation support, performance evidence. | Do we know each model’s limits, and monitor for them? |
| Internal audit | Independent review of whether the framework is actually working. | Would this survive a review we did not run ourselves? |
| Vendor / partnership teams | Evidence from third parties, LSPs, co-lending partners, outsourced technology providers. | Can our partners show their work when we ask? |
The draft gives this a spine. Three lines of defence: model owners first, an independent model-risk and validation function second, internal audit third. The operating model that works wraps the executive layer around that spine and keeps it short to state: the CRO owns the framework, Compliance owns readiness, the business owns decision logic, Technology owns evidence capture, and the Board owns oversight.
Can your team pass the 10-question readiness test?
Here is the test I would run against any bank, NBFC, or digital lender today. Ask your team these ten questions. Every “no” is a piece of work that should already be on someone’s desk.
Take the readiness assessment
Answer the ten questions below and get your readiness tier plus a tailored action list for every gap. Nothing stored: it scores in your browser.
- Do we have a complete inventory of all models, rules, calculators, AI tools, and third-party decision systems?
- Do we know which ones affect customers?
- Do we know which ones are high-risk?
- Do we know who owns each one?
- Can we show validation evidence?
- Can we show approval evidence?
- Can we explain what changed in the last quarter?
- Can we identify third-party and co-lending dependencies?
- Can we show human oversight and override records?
- Can we produce a Board / Risk Committee evidence pack this week?
If the honest answer to most of these is “no,” that is not a failing grade. It is a starting line, and the lenders who start now will be the ones who look ready when the final version lands.
Where does Lokta fit?
I am not neutral here, so let me be direct about why this guidance matters to what we are building.
The real message from RBI is not really about models. It is about trust in automated and semi-automated decision-making. In lending, decisions are increasingly made through a chain: rules, models, data providers, partner systems, APIs, and AI tools. RBI is asking regulated entities to make that chain visible, explainable, controlled, and auditable. That is exactly the property a deterministic core with audit-by-design is built to give you: every decision references the policy version it cleared, every action is logged with actor and evidence, and AI runs above the ledger, never as the ledger.
We built the rails a lot of the industry runs on (Apache Fineract) and went on to build and scale a commercial lending platform on those foundations. Lokta is what we would build if we started today, governed from the ground up. So we are working on Lokta RBI Model Risk Management: a question-led, evidence-first control plane that helps banks, NBFCs, and digital lenders see what evidence they have, what is missing, who owns each gap, and what can be shown to the Board or Risk Committee, across every model, every rule, every agent, and every vendor dependency that influences a lending decision. Not just the AI models. Not just the credit models. All of it.
The first goal is simple: RBI readiness for every lending decision system. If that is the problem on your desk, start with the 10-question test above. And if you want to go deeper, talk to the team.
Where do you stand against RBI’s 2026 model-risk draft?
Ten questions mapped to the draft, for NBFCs, fintech lenders, and banks. Scored on screen, nothing stored. Or join the waitlist for Lokta RBI Model Risk Management.
Frequently asked questions
What does RBI's draft model risk management guidance actually cover?
RBI's draft Guidance on Regulatory Principles for Model Risk Management, 2026 covers any model, rule, calculator, algorithm, AI system, or third-party tool that materially influences business decisions. The regulated entity must know it, own it, validate it, monitor it, and explain it. In lending that sweeps in credit scorecards, business-rule-engine logic, pricing calculators, bureau and alternate-data models, collections models, co-lending decision flows, and customer-facing AI. The shift is from "are we using AI safely?" to "can we prove governance over every system that influences a lending decision?" It is a governance discipline, not a data-science checklist.
Does RBI's model risk guidance apply to NBFCs and digital lenders?
Yes. The draft explicitly includes NBFCs across RBI's scale-based framework (Base, Middle, Upper, and Top layers), so the depth of model-risk expectation scales with size, complexity, and systemic importance. Digital lenders are pulled in through their partners: even when the regulated entity is the bank or NBFC, the digital lending app, lending service provider, or co-lending partner will increasingly be asked to produce evidence of which models and rules shaped a decision. Smaller NBFCs should start with visibility (a complete inventory) before standing up a large model-risk function.
Is a spreadsheet or BRE rule a "model" under RBI's draft guidance?
It can be. RBI defines "model" by what a system does, not by how it was built. A spreadsheet-based pricing calculator, a business-rule-engine rule, or a manual deviation matrix becomes a model the moment it influences pricing, eligibility, approval, rejection, collections treatment, or customer outcomes. That is the most consequential line in the draft: model risk management stops being only a machine-learning concern and becomes a board, risk, compliance, credit, technology, vendor, and operations concern. If it moves a customer outcome, it needs an owner, a risk tier, and audit-ready evidence.
How should a lender start preparing for RBI model risk management?
Do not wait for the final version. Start with readiness. Build one inventory of every system that influences a lending decision: models, BRE rules, calculators, scorecards, spreadsheets, AI agents, prompts, APIs, vendor tools, co-lending workflows, and manual overrides. Assign an accountable owner to each. Tier them by materiality and consumer impact. Then assemble a board and risk-committee evidence pack: what is high-risk, what is validated, what changed, which third parties influence decisions, and what needs remediation. If your team cannot produce that pack this week, that gap is your starting point.
Read next:
- The Loan Book That Learns: the self-improving book is exactly the kind of continuous policy testing RBI now wants governed, not just shipped.
- AI in Lending: Why a Deterministic Core: the architecture that makes “explain every decision” a property of the system, not a scramble before an audit.
- Ten Things Your LMS Needs to Do in 2026: maker-checker on AI actions and policy-version attribution, read as procurement requirements.
- RBI’s proposed revolving-credit restriction: what a term-loans-only draft would change about how NBFCs design, book and service credit.
Sources
- RBI draft Guidance on Regulatory Principles for Model Risk Management, 2026
- RBI NBFC FAQ and scale-based classification
- RBI Digital Lending FAQ
Chandramouli C S is a co-founder of Lokta. He has spent more than two decades across technology, go-to-market, and enterprise AI (building machine-learning and GenAI systems, and serving as an independent director) and reads draft RBI guidance line by line, because the definition of “model” is where the next three years of lending compliance gets decided.
