AI Explainability Regulations for Banking: What RBI FREE-AI Pillar 3, EU AI Act Article 86, and SR 11-7 Require — and Why Your Explainability Method Matters for Examination

Four Regulators, Four Different Reasons to Explain the Same Decision

A single declined loan application can trigger four separate explainability obligations, and they don't ask for the same thing. The EU AI Act's Article 86 gives the customer a right to a meaningful explanation of the main decision factors, on request, potentially months after the decision. SR 11-7 asks your model validator to assess conceptual soundness, which means explaining the model's global logic, not any one decision. RBI's FREE-AI report pushes explainability as a design-time obligation aimed at customers, internal reviewers, and examiners simultaneously — three audiences, one explanation, which is harder than it sounds. DPDP Section 11 gives the customer a right to know what personal data was processed about them, which is a narrower ask than "why was I declined," but gets confused with it constantly in practice.

The practical failure mode I've seen most often: a bank builds one explanation template for the regulator and discovers at examination time that the same template doesn't satisfy the customer-facing plain-language requirement. You need one underlying explanation method that can be rendered three different ways, not three different explanation pipelines.

Why SHAP Beats LIME for Banking, and It's Not a Style Preference

SHAP and LIME solve different problems, and banking needs the one SHAP solves. SHAP values satisfy an efficiency property — they sum to the model's output — which means the number you hand an examiner is mathematically traceable back to the prediction, not an approximation fitted around it. LIME builds a local surrogate model around a single prediction with no guarantee it agrees with the model's global behavior, which creates a specific examination risk: a validator's global feature-importance assessment under SR 11-7 can contradict the individual explanation a customer received under Article 86, on the same model, for no good reason other than LIME's instability.

I have seen this exact inconsistency get raised as a validation finding — not a minor one. If your individual and global explanations can diverge by construction, you've built an audit problem into the architecture before the examiner even shows up.

What "No Black-Box AI" Actually Means in Practice

The practical reading for a CRO: if you cannot produce a plain-language reason for a declined application today, on demand, you are already exposed — not because a specific clause bans the model, but because every other explainability obligation on this page assumes you can. Treat the absence of a formal ban as a reason to move faster voluntarily, not as cover to wait for one.

The Audit Trail Requirement Hiding Inside Explainability

Separate from the explanation itself is the retention obligation: you need the feature values and their contribution preserved per decision, not regenerated after the fact from a model that may have since been retrained. Regenerating an explanation from today's model version for a decision made eighteen months ago is not a defensible answer to an examiner, because the model that made the decision no longer exists in that form. This is a Forensic Replay problem as much as an explainability problem, and most banks' logging was built for the former, not the latter.

Action Checklist: Making One Explainability Method Satisfy All Four Regulators

1. Standardize on SHAP (or an equivalent additive-attribution method) as the single explanation methodology feeding every downstream use — customer letters, validator reports, and examiner requests.
2. Retain per-decision feature attributions at inference time, tied to the exact model and system-prompt version in force, not computed retroactively.
3. Build three rendering templates off the one explanation method: plain-language for customers, statistical detail for validators, raw attribution data for examiners.
4. Stop citing a black-box prohibition that doesn't formally exist — cite the design principle instead, and get ahead of it anyway.
5. Run a quarterly check: pick five declined applications and confirm the customer-facing explanation and the validator's global feature-importance report agree on the dominant factor.