AI Credit Scoring Governance: Validation, Disparate Impact Testing, Customer-Facing Explanation, and Why EU AI Act Classifies Credit AI as High-Risk

Credit scoring is the one AI use case where a single wrong decision has an immediate, individual, and often irreversible consequence — a declined loan, a higher rate, a lower limit — which is exactly why it draws the heaviest governance attention of any banking AI application. SR 11-7's model risk management, the EU AI Act's explicit high-risk classification, RBI's fairness and explainability expectations, and fair-lending law in every jurisdiction all converge on credit AI specifically. A bank that treats credit model governance like any other model's governance is under-investing in the one system where the stakes are highest and the regulatory attention is most concentrated.

Validation has to cover more than whether the model is accurate

Independent validation at Critical or High tier needs four things: conceptual soundness (is this methodology actually appropriate for a credit decision, not just statistically powerful), performance outcomes (Gini, KS statistic, PSI, and — the step most banks skip — lagged outcomes analysis comparing predictions against actual default behavior 12 to 18 months later), data governance (lineage, representativeness, feature documentation), and for ML models specifically, adversarial robustness and feature importance analysis. The lagged outcomes step is where validation programs most often cut corners, because it requires waiting over a year to know if last year's model was actually right — and a validation sign-off that skips it is approving a model on proxy metrics alone. For vendor-provided credit scoring models, treat the vendor's own validation report as informative, not sufficient; current RBI direction (and the draft extended model risk guidance reportedly under consultation, which this review cannot independently confirm in its final form) is trending toward requiring the bank to commission its own independent check regardless of what the vendor supplies.

Disparate impact testing: the 80% rule is a useful trigger, not a legal threshold in India

Standard testing covers gender, age, and geography; for an Indian book it has to extend to caste, religion, language, and disability proxies, because none of the standard variables will surface discrimination routed through a pincode or a surname pattern. The "80% rule" — a protected group receiving favorable outcomes at less than 80% of the highest-achieving group triggers investigation — comes from US EEOC employment-discrimination guidance, not Indian statute or a specific RBI numeric threshold, and should be used internally as an investigative trigger rather than cited to an Indian examiner as a legal bright line. For pricing fairness specifically, measure differential APR across equivalent creditworthiness profiles — a model can pass approval-rate parity and still fail on pricing, which is a distinct and separately testable failure mode.

SHAP, not LIME, for anything a customer or an examiner will see

SHAP values hold a mathematical consistency property between an individual explanation and the model's global behavior; LIME's local approximations don't carry that guarantee, and an individual LIME explanation can genuinely contradict what the model does on average — which is precisely the kind of inconsistency that turns a routine explainability review into an adverse examination finding. For a customer-facing credit denial, the top three to five contributing features with direction (what pushed the decision toward or away from approval) is the right level of detail — more than that buries the signal, less than that doesn't satisfy an explanation obligation in substance.

EU AI Act exposure applies to the decision, not the bank's postal address

Annex III explicitly lists credit scoring as high-risk AI, which means Article 9 risk management, Article 10 data governance documentation, Article 11 technical documentation, Article 12 logging, Article 15 accuracy and robustness testing, and Article 26 deployer obligations all apply to any credit decision affecting an EU resident — regardless of where the bank is headquartered. This catches Indian banks with EU lending operations off guard surprisingly often, because the assumption is that EU AI Act exposure requires an EU entity, when the actual trigger is the location of the person the decision affects.

DPDP Act exposure is about consent and purpose, not a penalty multiplier

Credit scoring models processing Indian residents' personal data need a valid consent or legitimate-use basis, and the Data Protection Board can impose penalties up to ₹250 crore per instance of non-compliance under the Act's Schedule. The DPDP Act also does not grant an automated-decision human-review right the way EU law does — frame the governance obligation around consent and access rights, not a review right the statute doesn't contain.

Action checklist for credit AI governance

1. Add lagged outcomes analysis (actual default versus predicted, at 12–18 month cohorts) to every credit model's validation cycle — don't sign off on proxy metrics alone.
2. Commission bank-side independent validation for every vendor-provided credit scoring model at Critical or High tier, regardless of the vendor's own attestation.
3. Run India proxy-variable disparate impact testing (caste, religion, language, disability) alongside standard demographic testing, and test pricing (APR differential) separately from approval-rate parity.
4. Replace LIME with SHAP for any explanation a customer, examiner, or board member will see.
5. Map EU AI Act obligations to every credit decision affecting an EU resident, regardless of where the lending entity or model is hosted.