When a lender declines an application, the applicant deserves a meaningful reason, and supervisors expect the lender to be able to explain how automated decisions are made. Reason codes are where model explainability meets the customer.

What makes a good reason code

A good reason code is faithful to the model, understandable to a non-specialist, actionable where possible and consistent across similar cases. "Insufficient credit history" is useful; "feature_47 contributed -0.21" is not.

From feature contributions to reasons

Tree-based models such as gradient-boosted decision trees support exact local feature attribution methods, including TreeSHAP. These attributions show how much each feature moved an individual score relative to a baseline. Reason codes can then be derived by:

  1. Grouping related features into business concepts, such as utilisation or income stability
  2. Aggregating attributions within each group
  3. Selecting the groups that contributed most negatively to the outcome
  4. Mapping each group to a reviewed, plain-language description

Keep policy and model reasons distinct

Many declines are driven by policy rules rather than model scores, such as minimum age or maximum exposure. Record which component drove the outcome so explanations remain accurate.

Govern the taxonomy

Treat the reason-code taxonomy as a controlled artefact: version it, review wording with compliance and customer teams, and test that each model release still maps cleanly to it. Explanations that drift silently are a governance failure, even if the model itself is sound.