MSD0043 Credit Scoring Explainability

Design a credit scoring and underwriting system for a fintech lender using a deep learning model with explainability requirements for regulatory compliance. The system must predict the probability that a loan applicant will default, using features like credit history, income, debt-to-income ratio, employment data, and transaction patterns.

Unlike a pure accuracy-maximizing model, this system must produce per-application explanations that satisfy regulatory requirements (e.g., ECOA, GDPR right to explanation): the lender must tell an applicant which factors increased or decreased their score and by how much. The model must also avoid discriminatory bias across protected groups, handle the severe class imbalance of defaults, and deal with reject inference, since you only observe outcomes for approved loans.

How would you design this system? Cover the model architecture and feature engineering, the explainability approach (SHAP, integrated gradients, attention-based explanations), the fairness and bias mitigation strategy, how you handle reject inference and class imbalance, and how you evaluate both predictive performance and explanation quality.

Line-art scene: an applicant hands a loan application to an opaque scoring machine that returns a DECLINED score, while a regulator on the right demands the four principal reasons

The Problem: the model can decline an applicant in 20 milliseconds, but the law requires a specific, per-applicant reason, the outcome labels exist only for the people the old model already approved, and any accuracy gain that lands unevenly across groups is a legal liability rather than a win.

Answer

The design makes the scoring core explainable by construction instead of bolting an explainer onto a black box. A monotone additive neural network (a neural GAM with one learned shape function per feature) produces the log-odds as a sum of per-feature terms, so each factor’s contribution in score points falls out of the same forward pass that produced the score. A small transaction sequence encoder feeds the additive layer through a handful of named, bounded cash-flow factors, and those few factors are attributed with integrated gradients under a numerically verified completeness check. Two further decisions carry the compliance load: reject inference is solved primarily with a randomized exploration band just below the cutoff plus bureau performance on declined applicants, and fairness is handled by a documented less-discriminatory-alternative search, because group-specific cutoffs would be illegal disparate treatment in consumer credit.

(1) Explainable-by-Construction Core: a monotone neural GAM over bureau, income, and DTI features, with monotonicity constraints so higher utilization can never lower risk; a GRU over 12 months of transactions contributes 8 named cash-flow factors.
(2) Exact Attribution Contract: per-feature score-point deltas come from the additive decomposition, integrated gradients cover only the encoder factors, and every explanation is checked against completeness before the notice is issued.
(3) Reject Inference by Exploration: a randomized approval band on 1% of near-cutoff declines buys unbiased labels below the cutoff; statistical augmentation and bureau outcomes on declines supplement it but never replace it.
(4) Calibration Over Balance: class weighting during training followed by isotonic recalibration on an unweighted out-of-time holdout, because pricing and expected-loss accounting need a true probability, not a balanced classifier.
(5) Fairness by Search, Not by Threshold: proxy audits, a less-discriminatory-alternative model search, and adverse impact ratio monitoring with proxy group estimates; the search itself is the compliance artifact.
(6) One Versioned Artifact: model, monotonicity spec, explainer, and reason-code map ship and are hashed together, so a notice can never be produced by a version that did not make the decision.

Underwriting pipeline: application to point-in-time feature store to monotone additive scoring core to decision; the attribution engine hangs off the scoring core and feeds the adverse action notice, with a training store and a fairness and drift monitor on the bottom row

Figure 1: One request produces three artifacts that must agree: a calibrated probability, a decision, and a reason set derived from the same arithmetic that produced the probability.

Clarify Before Designing:
(1) Regulatory Scope: US only (ECOA/Reg B plus FCRA adverse action, up to four principal reasons), or also EU GDPR Article 22, which adds a right to human review and changes the automation design?
(2) Decision Autonomy: is the decline fully automated, or does a human underwriter own a review band where the model is only a recommendation?
(3) Product and Label Lag: what is the term and the performance definition (90 days past due within 12 months?), since that sets how stale the newest usable training vintage is?
(4) Volume and Latency: how many applications per day, and is the decision instant at point of sale or allowed to take minutes?
(5) Reject Data Access: can we pull bureau performance on declined applicants, and does an exploration budget for below-cutoff approvals already exist?
(6) Protected Attributes: are they collected (mortgage-style) or must disparity be measured with proxy estimates, which changes how much we can trust the fairness numbers?


Login to view more content


Log in to track your progress

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *