AI Governance · Credit Decisioning

AI Credit Decisioning Governance: What RBI Examiners Check and What Your Models Must Be Able to Prove

Credit decisioning AI is the highest-stakes AI deployment in banking — it directly affects customer financial inclusion, creates adverse action obligations, carries all five FREE-AI pillars as mandatory, and is the AI category most likely to be examined by RBI. This guide covers what governance credit AI must have before and after deployment.

AI Governance · Credit Decisioning

AI Credit Decisioning Governance: What RBI Examiners Check and What Your Models Must Prove

Credit decisioning AI is the highest-stakes AI system most Indian banks run. It decides who gets a loan, at what price, and how much — decisions that affect financial inclusion, trigger adverse-action obligations, and sit squarely inside RBI's emerging AI supervisory agenda . This guide covers the governance a credit AI system needs before and after deployment, and what an examiner actually pulls first.

Zytra Research Team · October 2026 · 9 min read

Why Credit Decisioning AI Draws the Most Regulatory Attention

Every bank using AI for credit approval, limit setting, or risk-based pricing has deployed its highest-governance-obligation AI system. Two RBI instruments now bracket this space: the FREE-AI Framework, published in August 2025 by the committee chaired by Prof. Pushpak Bhattacharya of IIT Bombay, and the Draft Guidance on Regulatory Principles for Model Risk Management issued in June 2026, which covers 11 categories of RBI-regulated entities and mandates board-approved MRM frameworks, model inventories, risk tiering, independent validation, and kill-switch mechanisms. Credit models sit at the intersection of both. The failure modes are visible to customers, the fairness stakes are direct — financial inclusion is a longstanding regulatory mandate under schemes like PMJDY and priority-sector-lending obligations, not just good practice — and the adverse-action explanation requirement creates a customer-facing test most banks have not actually rehearsed.

If you want the plain version: a declined loan applicant can ask why, in language they understand, and your model has to have an answer that holds up. Most banks discover their answer doesn't hold up during the first real examiner conversation, not before.

What Standard MRM Validation Misses in Credit AI

Your model risk management function already validates credit AI for statistical performance — that part works. What MRM sign-off typically does not check is whether the model has absorbed a proxy for a protected characteristic through a feature that looks innocuous on a variable-importance chart. Pincode correlates with historically caste-segregated settlement patterns in parts of India. UPI counterparty networks can encode religious community through merchant and remittance patterns. Neither shows up as "caste" or "religion" in the data dictionary, which is exactly the problem.

MRM also rarely checks adverse-action explanation quality from the customer's seat, not the model's. A SHAP output that lists "bureau_score_delta_6m" as the primary decline factor is correct and useless to someone who doesn't know what a bureau score delta is. And almost no bank's monitoring setup is built to catch fairness drift between periodic reviews — which means an examiner asking for last quarter's segment-level approval-rate gap is often the first time anyone in the bank has looked at that number since go-live.

The 6 Governance Requirements for Credit Decisioning AI

1. Risk classification. Credit decisioning AI is Critical or High tier — there is no lower bucket available. Critical: unsecured personal loans, credit cards, and primary credit-scoring systems. High: credit limit adjustment, pricing optimization, mortgage pre-qualification. The tier determines validation frequency and committee sign-off depth, so get this classification right before anything else.

2. Independent validation. Required before deployment and on eight defined re-validation triggers (model refresh, feature set change, population shift, performance degradation, regulatory change, among others). Validation covers discrimination power (Gini, KS), calibration (Brier score), population and characteristic stability (PSI, CSI), segment-level fairness testing, explainability documentation, and override-rate analysis, closing with a formal validation opinion.

A few practitioner notes on these metrics. Gini and KS tell you the model still ranks risk correctly in aggregate, but they say nothing about whether that ranking holds up inside a protected segment — a model can post a stable overall Gini while quietly degrading for rural applicants. Brier score catches miscalibration that Gini misses entirely: a model can rank-order perfectly and still be badly wrong about actual default probability, which matters when that probability feeds pricing. PSI and CSI thresholds commonly sit at 0.1 (watch) and 0.25 (investigate/retrain) in practice — those aren't regulatory numbers, they're industry convention, and plenty of validation teams get challenged by examiners for not documenting why they picked them. Override-rate analysis is usually the first thing an examiner pulls, because a high or rising override rate is the cleanest signal that underwriters don't trust the model — and if your own underwriters don't trust it, that's a hard thing to explain to someone from RBI.

3. Fairness testing. Segment-level false positive and false negative rate testing is mandatory, and in the Indian context that has to include proxy-variable testing specifically: pincode and surname as caste proxies, UPI counterparty patterns as a religion proxy, language of interaction as a community proxy, and device-interaction patterns as a disability proxy. An approval-rate deviation of more than 20% from the overall population average triggers mandatory investigation.

This is the single hardest conversation with an examiner, and it's worth being honest about why. RBI's financial-inclusion mandate under PMJDY and priority-sector obligations is real and well-established law. What is not yet settled is exactly how an examiner translates that mandate into a specific AI disparate-impact test — this is an interpretive, emerging area of supervisory practice, not a fixed checklist with a published pass/fail line. Treat any vendor or consultant who tells you there's a settled formula here with real skepticism; the honest position is "we test rigorously against the best available proxies and document our judgment calls," not "we comply with a defined standard."

4. Adverse action. The customer gets a plain-language explanation naming the primary decline factors. It must not expose model internals, must be accurate and actionable, and gets logged per decision for audit purposes.

5. Production monitoring. Monthly performance review, quarterly fairness review, continuous override-rate monitoring, and input drift monitoring, with alerts routed to the model owner and escalation to the Head of MRM on breach.

6. Financial inclusion. RBI's financial-inclusion mandate creates a real, standing obligation here — and the burden of proof sits with the bank to show it isn't creating disparate access for SC/ST communities, religious minorities, or rural customers. As noted above, the specific AI-examination methodology for this is still developing; the obligation to monitor and be able to answer for it is not in doubt.

What RBI Examiners Actually Check

Examiner Focus Area What Examiners Look For Common Gap
Feature review Full feature list with proxy-risk annotation for each feature Banks can't produce a feature-level proxy-risk assessment on request
Fairness testing evidence Segment-level FPR/FNR results, not just aggregate accuracy Fairness testing exists but only at approval-rate level, not error-rate level
Adverse action explanation quality Sample explanations a lay customer could actually act on Explanations cite model-internal variable names, not customer-understandable factors
Override rate documentation Trend over time, reasons captured, reviewed by someone senior to the underwriter Overrides logged but never analyzed in aggregate
Committee approval record Minutes showing the committee saw fairness and explainability evidence, not just performance metrics Committee approved on Gini/KS alone
Financial inclusion assessment Comparative access analysis across SC/ST, religious minority, and rural segments No standing analysis exists until the examiner asks for one

How Adverse Action Explanations Work at Three Levels

Customer level. Plain-language explanation of the primary decline factors, delivered promptly after the decision. We'd describe a prompt turnaround — commonly cited as around 30 days in industry practice — as sound internal policy aligned with RBI's fair-practices-code and grievance-redress expectations, rather than as a fixed statutory deadline specific to AI decisions; banks should set this as their own documented SLA, not assume it's externally mandated.

Regulatory level. This is where the model needs to produce a defensible technical explanation, not a customer-facing one. SHAP (SHapley Additive exPlanations) is the standard tool for this — it decomposes a decision into feature-level contributions in a mathematically consistent way, and it's reasonable to run it as your production explanation mechanism. Test it under production load, not just in a notebook: a SHAP computation that takes 10 seconds in a validation environment needs to run inside your decision SLA in production, commonly benchmarked at under 48 hours end-to-end including any manual review step.

Consistency level. If any part of the credit decision involves an LLM-assisted step — summarizing an application, drafting the adverse-action narrative, or flagging exceptions for human review — test that the LLM's behavior is consistent across repeated runs and across customer segments. This maps to the Fairness and Equity sutra in RBI's FREE-AI principles: an LLM that generates subtly different explanation quality for applicants by name, language, or writing style is a fairness problem even if the underlying credit decision is sound.

India-Specific Credit AI Governance: Why NBFC-MFI, SFB, and UCB Models Differ

A generic governance checklist misses that the proxy-variable risk profile changes by institution type, and examiners increasingly know this.

NBFC-MFIs lend through joint liability groups in rural and peri-urban India, so geography and group-composition features carry more caste and community signal than they do for a metro-focused bank — a pincode-level risk feature in an MFI model is doing more proxy work than the same feature in a private bank's urban card portfolio.

Small Finance Banks (SFBs) serve the underbanked by design and lean heavily on alternate data — utility payments, UPI transaction history, device data — which makes the UPI-counterparty religion-proxy risk and device-interaction disability-proxy risk more load-bearing than at a universal bank still mostly running on bureau data.

Urban Cooperative Banks (UCBs) often lend within a defined community or membership base tied to their founding charter, which means community affiliation can be structurally embedded in the customer base itself, not just in a data feature — a harder governance problem because the proxy risk sits in who applies, not only in what the model scores.

Other dimensions that matter specifically in India: regional-language applicants need NLP-based fairness testing on any LLM-assisted step, since explanation quality in Hindi, Tamil, or Bengali is not guaranteed to match English-language quality by default. PMJDY and Jan Dhan customer populations need explicit access monitoring given their policy priority status. And rural-versus-urban performance parity testing should be a standing quarterly report, not a one-time validation exercise, because rural data sparsity tends to degrade model calibration gradually rather than suddenly.

Action Checklist: Getting Credit Decisioning AI Examination-Ready

  1. Classify every credit AI system as Critical or High tier and confirm the validation cadence and committee sign-off level match that tier — don't let a "limit adjustment" model quietly stay unclassified.
  2. Build a feature-level proxy-risk register covering pincode, surname, UPI counterparty patterns, language, and device-interaction data, and review it at every model refresh, not just at initial deployment.
  3. Run segment-level FPR/FNR testing quarterly, not just aggregate approval-rate testing, and document the 20%-deviation investigation trigger with actual investigation records, not just the test results.
  4. Rewrite adverse-action explanations for a customer who has never seen a SHAP value — pilot them with real applicants or a consumer-facing team before an examiner does it for you — and set your own documented SLA for delivery speed instead of assuming an external deadline exists.
  5. Stand up override-rate analysis as a standing monthly report to the Head of MRM, since it's the first artifact most examiners request and the easiest one to have ready.

Zytra's risk taxonomy maps credit decisioning AI against all seven governance domains banks are examined on — model risk, fairness, explainability, data governance, third-party risk, operational resilience, and accountability — so gaps like these surface before an examiner finds them.

Deploy credit AI that satisfies RBI examination before the examiner arrives

Zytra governs your credit AI from pre-deployment classification through production fairness monitoring — including India proxy variable testing, adverse action explanation quality checks, and 48-hour examination evidence packs.