Scoring a borrower the bureau cannot rank? The eight steps, what data you may lawfully use, and why every decline needs a stored reason: Alternative Credit Scoring: How to Build It →
Wondering what happens when an AI agent initiates the payment? What is known about NPCI’s Unified Agent Protocol, the liability question nobody has answered, and what to do now: Agentic Payments: How to Prepare →
Every tool for this module, how to use each one, what it costs, the best combinations and three recommended builds: Governance Build Sheet →
What model risk actually is
Model risk is the risk of loss from a model being wrong, or from a model being used for something it was never built for.
Two halves, and the second one causes more damage:
- The model is wrong. Bad data, bad assumptions, overfitting, drift.
- The model is used wrongly. Built for one population and applied to another. Built as a ranking tool and used as a decision. Built for one product and reused for a second because it was there.
Most model failures in financial services are the second kind. The model works exactly as designed, on a problem it was not designed for, and nobody noticed because the output still looked reasonable.
Three lines of defence
The governance structure every regulator expects, and the reason it exists.
| Line | Who | Owns |
|---|---|---|
| First | The team that built and uses the model | Development, documentation, monitoring, day-to-day use |
| Second | Independent validation and risk | Challenging the model — conceptual soundness, testing, approval |
| Third | Internal audit | Whether the first two actually did their jobs |
The word doing the work is independent. A validator who reports to the model owner is not a second line. This is the single most common structural failure in model governance at smaller firms, and it is visible immediately on an organisation chart.
What AI can and cannot do here
| Task | How well AI does it |
|---|---|
| Draft model documentation from code and artefacts | Very well. Documentation is the bottleneck; this genuinely helps. |
| Generate test cases and adversarial inputs | Very well. Underused. |
| Summarise a validation report for a committee | Well. |
| Detect drift and anomalies in production | Very well — this is a statistical task, not a generative one. |
| Explain a model’s behaviour | Partially. Post-hoc attribution approximates; it does not reveal. |
| Validate a model | No. Validation is a judgement with a named person behind it. |
| Approve a model for production | No. Accountability cannot be delegated to a model. |
There is an obvious recursion here: if you use AI to help govern AI, that tool is itself a model and belongs in the inventory. Firms consistently forget this, and it is exactly the kind of gap an examiner enjoys finding.
The structural fact: scope is now enormous
Model governance used to mean credit scorecards and market risk models. That is no longer the scope anyone is working to.
The RBI released its Draft Guidance on Regulatory Principles for Model Risk Management on 24 June 2026 for public consultation. Its scope is deliberately broad:
- Eleven categories of regulated entity — commercial banks, NBFCs, payments banks, asset reconstruction companies, credit information companies, co-operative banks, All-India Financial Institutions and others
- All models, not only credit or market risk
- Third-party models explicitly — buying a model does not outsource the accountability
- AI and ML, generative AI, agentic AI, and rule-based systems
That last line matters. A rules engine is a model. A vendor fraud score is a model. An LLM drafting customer replies is a model. If it produces an output that informs a decision, it is in scope.
Status at time of writing: the 2026 MRM guidance is a DRAFT under consultation, with comments reportedly due 24 July 2026, and final guidance to follow. Separately, RBI has been reported to be considering a broader AI framework covering training data, localisation, third-party platforms and regulatory reporting. Verify the current position before designing to any specific provision.
The model inventory
Everything in model governance depends on knowing what models you have. Most firms discover, when asked, that they do not.
# If you build one thing from this module, build this.
# An examiner's first question is "show me your model inventory".
# The second is "is it complete", and that one is harder.
model:
id: MDL-0042
name: unsecured_personal_loan_pd
version: 3.4.2
type: gradient_boosted_classifier # or: rules_engine | llm | vendor_score
purpose: >
Estimates 12-month probability of default for unsecured personal
loan applicants aged 21-58 in tier 1-2 cities.
# SCOPE OF VALID USE - the field that prevents the most common failure
approved_use:
products: [personal_loan_unsecured]
population: "age 21-58, tier 1-2, income > 25k/month"
decision_role: "input to policy layer; NOT the decision"
prohibited_use:
- "any product other than the one listed"
- "populations outside the training distribution"
- "as a standalone approve/decline decision"
risk_tier: high # drives validation depth and review cadence
tier_rationale: "directly determines customer credit outcomes"
ownership:
business_owner: head_of_credit
technical_owner: ds_lead
validator: mrm_team # MUST NOT report to either owner above
approved_by: model_risk_committee
approved_on: 2026-02-18
next_review: 2026-08-18
data:
training_period: 2022-01 .. 2025-06
features: 47
feature_registry_ref: FR-0042
protected_attributes_used: none
proxy_testing_done: true
dependencies:
upstream_models: [MDL-0011_bank_statement_parser]
downstream_consumers: [credit_policy_engine_v11]
third_party_inputs: [bureau_score, aa_cashflow_features]
controls:
explainability_method: TreeSHAP-exact
reason_codes_mapped: true
kill_switch: KS-0042 # see Advanced lane
fallback_on_disable: "policy rules only, tighter thresholds"
monitoring:
psi_threshold: 0.25
performance_metric: gini
alert_owner: ds_lead
last_drift_review: 2026-05-01The field that prevents the most failures
approved_use and prohibited_use. Model risk is more often misuse than error, and misuse happens because nobody wrote down the boundary.
A PD model built on salaried urban applicants gets quietly applied to a new self-employed rural product because it exists and the numbers come out. Without an explicit scope statement, there is nothing to violate — and nothing for a reviewer to catch.
Completeness is the hard part of an inventory, not format. The models that go missing are the ones nobody calls models: a spreadsheet that prices a product, a SQL rule that flags accounts, a vendor score consumed through an API, a prompt template that drafts customer communications. All of them are in scope under the RBI draft.
Risk tiering
Governance effort should be proportionate to consequence. Uniform treatment produces the worst of both outcomes.
def risk_tier(m):
"""Tiering decides how much governance a model gets. Tier everything
the same and you either over-govern trivia or under-govern the
things that matter. Usually both."""
score = 0
# 1. Consequence for the customer - weighted heaviest
if m["affects_customer_directly"]: score += 3
if m["decision_type"] in ("credit", "aml", "fraud_block",
"account_closure", "pricing"):
score += 3
if m["automated_without_human_review"]: score += 2
# 2. Scale
if m["decisions_per_month"] > 100_000: score += 2
elif m["decisions_per_month"] > 10_000: score += 1
if m["value_at_risk_inr"] > 100_000_000: score += 2
# 3. Opacity and control
if m["model_class"] in ("deep_learning", "llm", "ensemble"): score += 1
if m["is_third_party"]: score += 2 # less visibility
if not m["explainability_available"]: score += 2
# 4. Regulatory exposure
if m["regulatory_reporting_input"]: score += 2
if score >= 9: return "high" # full independent validation,
if score >= 5: return "medium" # 6-monthly review, kill switch
return "low" # lighter touch, annual review
# NOTE the +2 for third-party. A vendor model is HIGHER risk, not lower,
# because you cannot inspect it. Firms consistently tier these down
# because "the vendor validated it". The vendor validated it for their
# population, not yours.Third-party models are higher risk, not lower
Note the positive weighting for vendor models. Firms almost always tier these down, reasoning that the vendor validated it.
The vendor validated it on their population, for their use case, at a point in time you cannot see. You cannot inspect the training data, you may not know when it changes, and you have no visibility into its failure modes. The RBI draft addresses this directly through vendor accountability expectations: buying a model transfers the build effort, not the responsibility.
Independent validation
Validation is not testing. The first line tests. The second line challenges.
1. PROPOSE business problem, why a model, what if we do nothing
| -> register in inventory HERE, not after build
|
2. DEVELOP data, features, training, internal testing
| -> documentation written DURING, never after
|
3. VALIDATE INDEPENDENT second line
| - conceptual soundness: is this the right approach?
| - data quality and representativeness
| - performance on holdout AND on segments
| - benchmark against a simple challenger
| - stability, sensitivity, edge cases
| - bias and proxy testing
| - documentation adequacy
| -> validator can REJECT. If they cannot, it is not validation.
|
4. APPROVE named committee, recorded decision, conditions attached
|
5. DEPLOY shadow mode -> limited volume -> full
| -> kill switch tested BEFORE go-live, not after
|
6. MONITOR drift, performance, segment outcomes, override rates
|
7. REVIEW scheduled by risk tier; triggered by drift or incident
|
8. RETIRE decommission, archive, record what replaced it
THE GATE PEOPLE SKIP
Step 3, for models that "are not really models" - a rules engine, a
vendor score, an LLM writing customer text. The RBI draft puts all
of those in scope explicitly. So does common sense: they all produce
outputs that affect customers.What a real validation covers
| Dimension | The question |
|---|---|
| Conceptual soundness | Is a model the right tool here at all, and is this the right kind of model? |
| Data | Is the training data representative of the population it will score? Is the outcome definition correct? |
| Performance | Out-of-time as well as out-of-sample. By segment, not just overall. |
| Benchmark | How much better than a simple challenger — logistic regression, or the existing rules? If the gain is small, the added opacity may not be worth it. |
| Stability | Does small input variation produce large output variation? |
| Bias | Outcome differences by group, and proxy testing on every feature. |
| Implementation | Does the production code compute what the notebook computed? Training-serving skew is a validation finding, not an engineering detail. |
| Documentation | Could a competent stranger reproduce this in two years? |
The benchmark test is the one most likely to produce an uncomfortable answer. If a gradient-boosted model beats logistic regression by a point of Gini, you have taken on explainability burden, drift risk and validation cost for a marginal gain. Sometimes that is worth it. The point is to make the trade explicitly rather than by default.
FREE-AI: from principles to controls
The RBI-constituted committee released its Framework for Responsible and Ethical Enablement of Artificial Intelligence on 13 August 2025 — seven guiding sutras and 26 recommendations across six pillars.
| Pillar | What it means operationally |
|---|---|
| Infrastructure | The compute, data and platform foundations AI runs on — including where they physically sit |
| Policy | Board-approved AI policy, acceptable use, and the boundaries of autonomous action |
| Capacity | Skills and understanding — including whether your board can meaningfully challenge what it approves |
| Governance | Model inventory, tiering, validation, approval, accountability |
| Protection | Customer outcomes, fairness, data protection, security |
| Assurance | Monitoring, audit, evidence — ongoing rather than at approval |
The framing that matters: this is a corporate governance discipline, not a technology compliance discipline. It belongs in enterprise risk management alongside credit and operational risk, not in a separate AI workstream that reports to engineering.
Practical consequence for a small fintech: you will not build six pillars. What you can build is an inventory, a tiering rule, a named independent reviewer, a kill switch and a monitoring dashboard. That is a defensible programme at seed stage, and it maps onto the pillars when someone asks.
The registry
Frameworks and standards to map against
Verified May 2026Tooling
Verified May 2026Registry reflects what was publicly visible in May 2026. The Indian position in particular is actively developing — the MRM guidance was in consultation and a broader AI framework was reported under consideration. Track RBI publications directly rather than relying on any secondary summary, including this one.
A prompt for assessing your governance readiness
You are a model risk officer who has been through regulatory
examinations of AI governance in Indian financial services.
My situation:
- Entity type: [NBFC / bank / payments / unregulated fintech partnering
with a licensed entity]
- Models in production: [list them, including rules engines, vendor
scores, spreadsheets that price things, and any LLM features]
- Team size and whether anyone is independent of model development:
[describe honestly]
- Current governance: [describe, or "none"]
Give me:
1. A complete list of things in my description that ARE models under
the RBI draft MRM scope but that I probably do not think of as
models.
2. A risk tier for each, with the reasoning.
3. The minimum viable governance programme for my size - what to build
first, second and third, and what I can defensibly defer.
4. Who must be independent of whom, and how to achieve that in a small
team without hiring.
5. What independent validation should cover for my highest-tier model
specifically.
6. What evidence an examiner would ask for, and what I should start
retaining now.
7. The three gaps most likely to be found if I were examined next month.
Be specific and realistic about what a small team can actually do.
Flag where the draft guidance is not yet final and where I should take
formal advice.Explainability that survives scrutiny
The question a regulator asks is not "can you explain the model". It is "can you explain this decision, to this customer, in terms they can act on, reproducibly".
| Approach | What it gives you | Where it fails |
|---|---|---|
| Inherently interpretable models logistic regression, decision trees, EBMs | The model IS the explanation. No approximation. | Some accuracy cost, usually smaller than assumed |
| SHAP / attribution | Per-decision feature contributions | Approximation, not mechanism. Unstable across retrains and among correlated features. |
| Surrogate models | A simple model approximating a complex one | Explains the surrogate, not the original. The gap is rarely measured. |
| Counterfactuals | "What would have changed the outcome" | Genuinely useful for customers; can suggest changes that are not actionable |
| Documentation and design | Why this approach, what it assumes, where it should not be used | Nothing — this is the most durable form of explainability and the most neglected |
The option people skip
Explainable boosting machines and similar glass-box approaches often land within a point or two of gradient boosting on tabular financial data, while being directly interpretable. Given what post-hoc explainability costs in validation effort, stability risk and regulatory argument, that trade deserves to be evaluated rather than assumed away.
The benchmark discipline from the validation section applies here too. If your complex model beats an interpretable one by a small margin, the honest question is whether that margin justifies the governance burden — and the answer is sometimes no.
Documentation is explainability
The most durable explanation is not an attribution plot. It is a document stating what the model was built to do, on what data, under what assumptions, with what known limitations and where it must not be used. Attribution methods change; that document is still readable in five years.
Bias testing as a programme
A one-off fairness check before launch is not a bias programme. Populations shift, and a model that was balanced at approval can drift.
What to run, and when
| Test | Question | Cadence |
|---|---|---|
| Outcome disparity | Do approval rates differ materially by group? | Monthly |
| Error disparity | Are false positives or false negatives concentrated in one group? | Quarterly |
| Proxy strength | Does any feature predict a protected attribute well? | At development, and on every feature addition |
| Feature ablation | Does removing a suspect feature change outcomes materially? | When a proxy is flagged |
| Intersectional | Does a combination of attributes fare worse than either alone? | Annually — and this is where problems hide |
The data problem is unavoidable and must be resolved deliberately: testing for disparity generally requires holding the protected attribute, while data minimisation says you should not. Some jurisdictions permit collection specifically for fairness testing. Resolve it with counsel, and record the decision — because "we did not test" is not a defence, and neither is "we could not".
When a disparity appears
Investigate before adjusting. A disparity can reflect genuine differences in the underlying population, a proxy feature, a label bias inherited from historical decisions, or a sampling artefact. These require different responses, and applying a fairness constraint to a measurement artefact makes the model worse without making it fairer.
Monitoring and the kill switch
Approval is a moment. Assurance is continuous. The RBI draft is explicit that institutions should be able to override, suspend or deactivate models, including through kill-switch arrangements.
# The RBI draft envisages mechanisms to override, suspend or deactivate
# models, including appropriate kill-switch arrangements.
# A kill switch that has never been exercised is a design document.
class ModelKillSwitch:
"""Disabling a model is not deleting it. It is routing around it
to a defined fallback that must itself be safe to operate."""
def __init__(self, model_id, fallback, authorised_roles):
self.model_id = model_id
self.fallback = fallback # what happens instead
self.authorised = authorised_roles # who may pull it
self.state = "active"
def disable(self, actor, role, reason, ticket):
assert role in self.authorised, f"{role} not authorised"
assert reason and ticket, "reason and ticket are mandatory"
self.state = "disabled"
audit_log({
"event": "model_disabled", "model_id": self.model_id,
"actor": actor, "role": role, "reason": reason,
"ticket": ticket, "fallback": self.fallback,
"at": utcnow(), "auto": False,
})
notify(["model_risk_committee", "cro", "business_owner"])
def auto_disable(self, trigger, metric, value, threshold):
"""Automatic triggers must exist AND must alert a human.
A model that silently disabled itself at 3am is an incident
nobody investigated."""
self.state = "disabled"
audit_log({"event": "model_auto_disabled", "trigger": trigger,
"metric": metric, "value": value, "threshold": threshold,
"at": utcnow(), "auto": True})
page_oncall()
AUTO_TRIGGERS = {
"score_distribution_shift": "PSI > 0.35 on the output distribution",
"input_null_spike": "any feature null rate > 3x baseline",
"upstream_dependency_down": "a required data source unavailable",
"volume_anomaly": "decision volume outside 5x historical band",
"approval_rate_jump": "approval rate moves > 15pp in 24h",
}
# THE FALLBACK IS THE HARD PART
# "Disable the credit model" -> then what? Decline everyone?
# Approve everyone? Fall back to rules with tighter thresholds?
# Decide this at design time, write it in the inventory, and TEST IT
# in production during a low-volume window. Once a quarter.Design the fallback, then rehearse it
"Disable the model" is only half a plan. The other half is what happens instead, and it must be safe to run for as long as the outage lasts.
Test it in production during a low-volume window, on a schedule. A kill switch exercised for the first time during an incident is an untested code path being run under pressure by someone who has not done it before.
Governing third-party and generative models
Two categories that break traditional model risk assumptions, and both are explicitly in scope.
Vendor models
You cannot inspect the training data, the architecture may change without notice, and the vendor validated it for a different population. What you can do:
- Contractual rights to performance data, change notification and validation evidence
- Your own benchmark on your own population, before adoption and periodically after
- A challenger you control, run in parallel, so degradation is visible
- Version pinning where offered, and treating a vendor version change as a change requiring review
- An exit path — the same blast-radius thinking as Module 08
Generative and agentic systems
Traditional model risk assumes a fixed input space, a measurable output and a stable error distribution. Generative systems have none of those.
What transfers: inventory, tiering, scope of approved use, monitoring, kill switch, human oversight.
What needs adapting: evaluation becomes a maintained eval set rather than a holdout metric; drift includes the provider silently changing the model beneath you; and the failure mode is fluent wrongness rather than a degraded score.
An agentic system that takes actions is a model with an execution path. Tier it accordingly, constrain what it can do rather than what it is told, and log every action it takes — not merely what it was asked. The RBI draft naming agentic AI explicitly means this is a supervisory expectation, not an internal engineering preference.
The evidence file, and where this closes
1. "Show me your model inventory."
-> complete, current, with owners and tiers
2. "How did you decide this model is high risk?"
-> documented tiering rule, applied consistently
3. "Who validated it, and who do they report to?"
-> independence on an org chart, not in a policy
4. "Show me the validation report."
-> conceptual soundness, benchmark, segments, bias, implementation
5. "Who approved it, when, and on what conditions?"
-> committee minutes, named individuals, conditions tracked
6. "How do you know it still works?"
-> monitoring dashboard with thresholds and a named alert owner
7. "Show me the last time a threshold was breached and what happened."
-> this is the real test. A programme with no incidents in two
years has either perfect models or no monitoring.
8. "This customer was declined on 14 March. Why?"
-> decision record: inputs, model version, policy version, score,
reason codes, any override and by whom
9. "Show me a model you disabled, and the fallback you used."
-> kill switch exercised, not merely documented
10. "Which of your models are third-party, and how do you assure them?"
-> the question most firms answer worst
RETENTION
Keep validation reports, approvals, monitoring history and decision
records for at least the life of the model plus the applicable
regulatory retention period. Archive on retirement; do not delete.Question seven is the one that separates a real programme from a documented one. Thresholds that have never been breached usually mean thresholds set where nothing could breach them.
Where this closes
This module governs every other module in the section. The identity extraction model in Module 01, the PD model in Module 02, the fraud scorer in Module 03, the screening thresholds in Module 04, the matching tolerances in Module 05, the support agent in Module 06, the suitability envelope in Module 07 — all of them are in the inventory, all of them get tiered, and all of them need an owner, a validator and a kill switch.
The Build Playbook covers how to sequence all of this for a company that does not yet exist.
Illustrative throughout. Model governance in a regulated entity requires board-approved frameworks and genuine independence, neither of which can be improvised from a web page. The RBI MRM guidance was in draft at the time of writing — verify the final position before building to any specific provision, and take formal advice on what applies to your entity type.
Sources
Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are industry reporting.
- officialRBI draft Guidance on Model Risk Management, 2026 — the definition of a model, tiering, three lines of defence and the kill switch. Draft. www.rbi.org.in
- officialRBI FREE-AI committee report, 13 Aug 2025 — the seven sutras, 26 recommendations and six pillars. www.rbi.org.in
- officialNIST AI Risk Management Framework — the Govern / Map / Measure / Manage structure. www.nist.gov
- officialFederal Reserve SR 11-7 — the supervisory articulation of validation and effective challenge. www.federalreserve.gov
Tooling, pricing and cost sources for this module are on its build sheet: sources →
Checked September 2026. Regulation in this area is actively developing; the date is part of the claim.
Ask an AI about this page
Opens your assistant with this page as the source, and a question rather than a summary. It will ask what you are building before it answers.
Nothing is sent from here. The link carries only this page’s title and address.