Credit Limit Increases and the Explainability Requirement
Meridian Bank wants to replace its rule-based credit-limit increase programme for 1.2 million card customers. Today 6% of eligible customers receive an increase, with a 2.1% bad rate. A vendor offers a gradient-boosting model with 0.82 AUC and claims it can raise the acceptance rate to 14% at the same bad rate. The model uses 240 inputs, including ZIP code, number of cash advances, app sessions, merchant category spend and repayment history. It returns a score but no reason codes. The bank operates in a regulated market and must give customers specific adverse-action reasons when an increase is declined. Compliance is also concerned about proxy discrimination and wants to see fairness testing by age, region and disability status. The data science team proposes using SHAP values and dropping ZIP code. The vendor warns that removing ZIP will reduce AUC by about 0.03 and that SHAP explanations are not the same as regulatory reason codes. The programme owner asks how to decide whether the model is acceptable.
1. Evaluate the vendor's claim that the model can raise acceptance from 6% to 14% at the same bad rate. What validation would you require before believing it?
Read the worked answer
The claim is plausible but not yet evidence. A 0.82 AUC is a ranking measure; it does not establish that 14% acceptance can be achieved at the same 2.1% bad rate. The bank needs the vendor's score distribution and a threshold analysis on the bank's own population, because the vendor's sample may differ. Require an out-of-time validation on recent bank data, with the bad-rate definition, observation window and outcome window matched to the current programme. Compare acceptance at the same bad rate using a holdout, not a resubstitution result. Check calibration and confidence intervals; a 0.03 AUC drop from removing ZIP is not decisive if the model remains well ranked. Also test whether the uplift survives segment-level analysis and whether the model's inputs are available at decision time. Only a controlled pilot can confirm the business claim.
2. Assess the explainability and fairness proposal of SHAP plus dropping ZIP. Is it sufficient for a regulated adverse-action process? Justify your answer.
Read the worked answer
SHAP plus dropping ZIP is a good start but not sufficient for regulated adverse-action reasons. SHAP explains the model's score in feature terms; regulators often require specific, understandable reasons tied to the customer's situation, and a SHAP value on a complex derived feature may not meet that standard. Dropping ZIP reduces one obvious proxy, but region can still be proxied by merchant spend, app behaviour or cash advances, so fairness testing by age, region and disability status is still needed. I would require a documented feature inventory with lawful basis; adverse-action reason mapping tested on real declined cases; disparate-impact analysis with pre-agreed thresholds; human review for borderline or vulnerable customers; and model risk documentation. If the team cannot produce defensible reason codes, a simpler monotonic scorecard or a constrained model may be preferable, even at some AUC cost.
3. Recommend a governance and deployment decision. Include conditions, monitoring and human oversight.
Read the worked answer
Conditional approval for a pilot, not full deployment. Conditions: independent validation on bank data; a threshold chosen to preserve the 2.1% bad rate with confidence intervals; reason-code generation tested with compliance; fairness testing with a remediation plan; and a holdout control group to measure acceptance, bad rate and complaints. Deploy first as a shadow or limited pilot in one region, with human credit reviewers able to override. Monitor approval rates, bad rate, override rate, reason-code stability, input drift and complaints by segment. Define rollback triggers, for example a bad rate above an agreed cap or a statistically significant disparate impact. Governance should include model ownership, periodic review, vendor contract rights for validation and change notification, and clear accountability. The vendor's performance claim should not be accepted as a procurement fact.