AI Credit Scoring Red Flags: A Model Audit Cheatsheet

For: Head of Credit or Chief Risk Officer at a mid-market NBFC or digital lender who just inherited an AI credit scoring model they didn't build and now needs to validate it before the next RBI audit or board review

If you've inherited an AI credit scoring model and have a regulatory review coming, run three audits before you look at AUC: check the top model features for legally impermissible proxies, compare live score distributions against training-time distributions, and verify that the denial reason codes surfaced to borrowers actually map to the features driving the score. High backtest accuracy will not save you on any of these — and each is now standard scrutiny in RBI inspections and fair lending reviews.

This is the cheatsheet. Use it before the auditor uses theirs.

The three failure modes accuracy metrics don't catch

Section 1: Feature-level red flags

Features that will get flagged

• Pincode / ZIP — geographic proxy for caste, religion, income class. High feature importance here is a near-certain audit finding.
• Device model or OS — proxies for income. iPhone vs. entry-level Android is a wealth signal masquerading as behavior.
• Employer name (raw string) — proxies for gender and religion depending on sector.
• First name / last name embeddings — direct proxy for religion, caste, region. If your NLP pipeline touches names, assume it's leaking.
• Mobile carrier — regional and income proxy in several markets.
• Time-of-application — can proxy for occupation type (gig vs. salaried) and indirectly for gender.

Quick check

1. Pull the top 20 features by SHAP or permutation importance.
2. For each, ask: could this feature correlate with a protected class in my geography?
3. Run a disparate impact test: approval rate for group A / approval rate for group B. Anything below 0.80 is the classic four-fifths rule failure and needs documentation.

Section 2: Explainability audit

What regulators actually want to see

The reason-code trap

Most inherited models have a decoupled reason-code layer: the ML model outputs a score, then a separate policy engine assigns reasons from a fixed list based on rules. Auditors are catching this. Ask your MLOps team to show, for 20 random denials, the SHAP values for that applicant next to the reason codes sent to the borrower. If they don't match, you have a fair lending disclosure problem, not just a technical one.

Section 3: Data drift and stability

Metrics to pull monthly

• Population Stability Index (PSI) on the score distribution: <0.1 stable, 0.1–0.25 investigate, >0.25 retrain.
• Characteristic Stability Index (CSI) per feature — same thresholds. This catches upstream data pipeline changes before they blow up the score.
• Approval rate drift vs. rolling 90-day baseline, segmented by product, channel, and geography.
• Score-to-default calibration: is a 700 today still defaulting at the rate a 700 defaulted at training time? Calibration decays faster than discrimination.

Red flag combinations

• Stable AUC + drifting approval rate = the model still ranks, but the cutoff is now wrong. Recalibrate, don't retrain.
• Stable approval rate + rising default rate = adverse selection or drift in a feature not in the model. Investigate channel mix.
• PSI spike in one feature only = data pipeline break, not model failure. Check the ETL before touching the model.

Section 4: Governance artifacts your audit will demand

• Model card with training data window, feature dictionary, and exclusion rationale for rejected features
• Bias testing report (disparate impact + equal opportunity metrics) at training and quarterly thereafter
• Champion/challenger logs if any A/B testing is running in production
• Override log: how often do humans override the model, and does the override rate vary by applicant group?
• Retraining trigger policy — written, not tribal knowledge
• Incident log for every score anomaly, pipeline break, or manual intervention

Section 5: 10-point pre-audit checklist

1. Can you produce the training dataset and its date range?
2. Are protected-class-proxy features documented and justified or removed?
3. Do you have SHAP or equivalent local explanations stored per decision?
4. Do borrower-facing reason codes derive from those explanations?
5. Is PSI monitored monthly with an escalation path?
6. Is score-to-default calibration reviewed quarterly?
7. Do you have a disparate impact report less than 90 days old?
8. Is there a written retraining trigger policy?
9. Are model overrides logged and analyzed by segment?
10. Is there a documented human-in-the-loop for edge cases and appeals?

If you can't answer yes to seven of ten, prioritize governance artifacts over model tuning. Auditors weight documented process heavier than marginal AUC.

What this cheatsheet is bad at

This won't help you build a scoring model from scratch, and it deliberately skips the deep MLOps tooling debate (Evidently vs. WhyLabs vs. rolling your own — pick one and use it consistently). It also assumes you already have the raw prediction logs and feature values stored per decision. If you don't, that's the first fix, before any audit prep. For teams working through both the model validation and the underlying data infrastructure, our work with Cashpo on KYC and AI credit scoring and broader AI Studio practice cover the pattern end-to-end.

Frequently Asked Questions

What's the difference between model validation and a fair lending audit?

Model validation checks that the model performs as intended — accuracy, stability, calibration. A fair lending audit checks whether outcomes are equitable across protected groups regardless of model intent. A model can pass validation and fail fair lending simultaneously, which is why disparate impact testing has to be a separate line item, not a sub-bullet under "model quality."

Do we need explainable AI (XAI) if we're using gradient boosting or neural networks?

Yes. Regulators including the RBI and CFPB have made clear that model complexity is not a defense against disclosure obligations. SHAP is the current practical standard for tree-based models; for neural networks, integrated gradients or LIME are common. The requirement isn't a specific technique — it's producing a defensible, per-decision explanation you can hand a borrower and a regulator.

How often should we retrain an AI credit scoring model?

Trigger-based rather than calendar-based. Retrain when PSI on the score exceeds 0.25, when calibration decays materially, or when the underlying portfolio mix shifts. Some lenders retrain quarterly regardless; others go 12+ months when their book is stable. What matters is that the trigger policy is written down and followed.

Can we use alternative data (telco, utility, social) without triggering bias findings?

You can, but each source needs its own disparate impact test and a documented rationale for why the signal is causally relevant to repayment rather than a proxy for demographics. Social graph features are the highest-risk category and are increasingly hard to defend. Telco and utility data tend to hold up better if properly tested.

Who should own model audit — Risk, Compliance, or Data Science?

Risk owns the outcome; Data Science owns the artifacts; Compliance owns the regulatory mapping. The failure mode is when Data Science self-audits with no independent review. At minimum, the person signing off on the model should not be the person who trained it. For a tailored assessment of your model governance setup, contact CodeNicely for a personalized review.