A rejected loan applicant receives the model's raw internals as their explanation — "your application scored -0.42 SHAP on feature emi_ratio" or "top negative contributor: bounce_rate_3m". The customer reads it as evasion, complains at the branch, then escalates to the lender's nodal officer and the ombudsman. The lender technically "gave reasons", yet the complaint file says the rejection was never explained — because for the reader, it was not.
An Indian lender wired its scoring model's explainer output straight into the rejection-letter template — engineering fields, feature names, signed contributions and all. Indian regulation expects lenders to tell borrowers the key reasons for rejection in terms the borrower can act on, and jargon does not qualify. The team had the right local-explanation machinery from 1.11; what never got built was the translation layer between explainer output and human sentence. Linked module: 1.11 (the adverse-action sentence).
Explainer output is a debugging artifact, addressed to the model's engineers. A SHAP value answers "how much did this feature push this score", in model units, against a baseline the customer has never heard of — three concepts a borrower cannot use. An adverse-action reason must answer a different question: what about MY situation drove the decision, and what would change it? Check the letter with the read-aloud test: hand it to a non-technical colleague and ask them to say, in their own words, why the customer was rejected and what the customer could do. If they cannot, the letter fails — whatever the maths behind it.
Build the translation layer. Take the top two or three drivers from the local explanation and render each as an adverse-action sentence in plain words with the customer's own numbers: "Your monthly EMIs would take 45% of your income; we approve when this stays under 35%." State the decision, the main reasons, and what would need to change, in the applicant's language where required. Ban the jargon list from customer letters — SHAP, feature, score, model, probability, coefficient, contributor — and have a credit officer read every template aloud before it ships. Re-issue the failed letter in this form; complaints usually end where comprehension begins.
Keep two artifacts for every decision the model makes: the engineer's explanation (full explainer output, archived for audit) and the customer's explanation (adverse-action sentences from a reviewed template library). Never let the first leak into the second. Add the banned-jargon list to the letter linter, and make the read-aloud test part of template review, with the reader chosen from outside the data team.
Q: "Your lending model rejects an applicant. The regulator says you must give reasons. What do you send?" Strong answer: distinguish the audit trail (full local explanation, stored) from the customer letter (top reasons as plain adverse-action sentences with the applicant's own numbers and what would change the outcome); mention the banned-jargon list and the read-aloud test; and note that "we gave the SHAP values" fails the requirement's purpose even where it meets its letter.