skip to content

Reason Codes and Model Cards

Turning an attribution into a sentence a customer or a regulator can act on: the top decline factors, the documented intended use, and the limits you admit before someone else finds them.

on this pageshow

questions

3

Why is an adverse-action notice saying 'your score was below the cutoff' inadequate?

level: middleimportance: must knowfreq 58%

answer

  1. the applicant has to be able to do something
  2. mechanism versus fact about the person
  3. could they dispute it if it were wrong?
  4. name the balance, not the score
  5. short ranked list, plain language, four

basics

~20 s

An adverse-action notice must name the specific facts about the applicant that drove the decline, such as a revolving balance at 78% of the limit. A score and a cutoff describe the mechanism, not the reason.

solid answer

~50 s

A score-and-cutoff sentence tells the applicant how the decision was computed, not why their file failed. It is unfalsifiable and unactionable: there is nothing to dispute and nothing to change. A usable reason names a fact about the applicant, in their language: `your revolving balance is 78% of your available credit limit`, `you have two accounts more than 60 days past due`, `your oldest credit account is 7 months old`. Those are specific, they can be checked against the bureau file and disputed if wrong, and at least some of them can be acted on. Practice under US credit rules is a short ranked list of the principal reasons, conventionally no more than four, sent within about 30 days of a completed application. Reasons must reflect the actual basis of that decision, not a generic disclosure list reused for everyone.

go deeper

for a junior

Be ready to state the difference in one line: a reason names a fact about the applicant, a score names the mechanism. Have one good example ready, with a number in it.

for a middle

Explain the path from a per-decision attribution to a customer-facing sentence: attribute, map to a pre-agreed reason-code taxonomy, rank, take the top few, fill in the applicant's own figures.

for a senior

Show the operational side — reproducing a notice years later from stored codes and model version, refusing model families that cannot meet the explanation bar, and keeping wording under compliance review rather than in code.

for a principal

Own the framing that explainability is a product constraint set before modelling begins, and be able to defend the accuracy you gave up by keeping consumer decisions on models whose reasons you can actually defend.

## The obligation behind the question When a lender declines a credit application, the applicant is owed an explanation. Under the US Equal Credit Opportunity Act and its implementing Regulation B, a creditor taking adverse action must notify the applicant, generally within about 30 days of receiving a completed application, and must either state the specific principal reasons for the decision or tell the applicant how to obtain them. Regulatory guidance treats long lists as unhelpful, so the industry convention is a ranked list of at most four principal reasons, written in plain language. That convention is the reason this leaf exists: the model produces a number, and something has to turn that number into four sentences a person can read. ## Why score-and-cutoff is not a reason `Your model score of 412 was below our approval cutoff of 500` is a true statement about the process. It is not a reason, for three separate defects. **It is not specific to the applicant.** Every declined applicant gets the same sentence with a different number. It carries no information about which facts in the file mattered. **It cannot be disputed.** A large share of the value of a decline reason is error correction: an applicant told `you have two accounts more than 60 days past due` can pull their credit report and, if that is wrong, dispute it and reapply. A score has no factual content to check. The applicant cannot tell whether the model saw bad data. **It cannot be acted on.** The applicant has no lever on the score itself. They have levers on the underlying facts: pay down a balance, let a delinquency age, close fewer accounts, wait for a thin file to thicken. The same defect appears in dressier disguises. `Our model assigned a low approval probability`, `the ensemble ranked your application below threshold`, and `you did not meet our credit policy` are all the mechanism restated. So is a raw internal feature name such as a utilization ratio field code, which is specific but not readable. ## What makes a reason actionable A good reason has four properties. 1. **It names a fact about the applicant**, drawn from the data the model actually used for this decision. 2. **It is stated in the applicant's vocabulary**, with the quantity attached where a quantity helps: `78% of your available credit limit` beats `high utilization`. 3. **It is the real driver**, ranked by how much it pushed this application toward decline, not chosen from a fixed list of convenient reasons. 4. **It is checkable** — the applicant can locate the same fact in their own records and challenge it if it is wrong. Actionable does not mean instantly fixable. `Your oldest credit account is 7 months old` cannot be fixed this week; the applicant cannot manufacture history. It is still a legitimate reason: it is specific, it is disputable if the bureau merged the wrong file, and it tells the applicant that time, not behaviour, is what is missing. Conflating actionable with fixable-today pushes teams toward reporting only the soft, changeable factors, which misrepresents the decision. ## Getting from a model to a sentence The pipeline has three stages, and the interview usually probes the seam between them. - **Attribution**: for this one application, how much did each input push the score toward the decline side? Any per-decision attribution method will do, provided it is deterministic and reproducible for the same input. - **Mapping**: each input, or each family of related inputs, maps to one entry in a pre-agreed reason-code taxonomy with fixed, reviewed customer-facing wording. The taxonomy is written by the business and compliance, not invented at scoring time by whichever engineer is on call. - **Selection and rendering**: rank the codes by contribution, take the top few, fill in the applicant's own numbers, and store the issued codes alongside the decision so the notice can be reproduced during an audit years later. The stored-codes step matters more than it sounds. If the notice cannot be regenerated because the model has since been retrained, you cannot defend the decision when it is questioned. ## Black boxes do not buy an exemption A common weak answer is that the model is a gradient-boosted ensemble, so specific reasons are impossible and the score sentence is the best available. The obligation attaches to the decision, not to the model class. If a model cannot be explained to the standard the decision requires, that is a constraint on which model may be deployed for that decision, not a licence to send an empty notice. This is the reason a lot of consumer-credit scoring stays on constrained, monotone models: explainability is a product requirement, priced in before modelling starts. ## What a strong answer sounds like Name the defect (mechanism versus factor), give one good and one bad sentence side by side, mention the ranked short list and the plain-language requirement, and add the dispute angle — that the reason exists partly so the applicant can catch bad data about themselves.

  • Is 'your oldest credit account is 7 months old' a valid reason if the applicant cannot change it quickly?
    Yes. Actionable means specific and checkable, not fixable this week. The applicant learns that a thin file, not behaviour, drove the decline, can dispute it if the bureau merged the wrong history, and knows that reapplying later is the path. Suppressing hard-to-change reasons in favour of soft ones misstates the actual basis of the decision.
  • The model is a gradient-boosted ensemble. Does that excuse a generic notice?
    No. The obligation attaches to the decision, not the model family. Per-decision attribution plus a fixed reason-code taxonomy gets specific reasons out of an ensemble. If a model genuinely cannot support the explanation the decision requires, that rules the model out for this use case — explainability is a product requirement priced in before modelling, not a post-hoc concession.
  • Why store the reason codes with the decision rather than regenerating them on demand?
    Because the model moves. If a notice is challenged eighteen months later, regenerating from the current model produces reasons that were never sent and may not match the decision made. Persisting the issued codes, the model version and the input snapshot makes the notice reproducible and the decision defensible in an audit.

Telling a declined applicant their score was too low is like a restaurant failing a health inspection and being told only that it scored under the pass mark, with no mention of the walk-in fridge.

saying these in an interview costs you the question

  • Treats the score and cutoff as the reason itself
  • Says a black-box model excuses a generic notice
  • Sends internal feature codes the applicant cannot read
  • Lists twenty contributing factors instead of a ranked few
  • Reuses one boilerplate reason list for every declined applicant
  • Reports only easily fixable factors and hides the real driver
  • Never persists the issued reasons with the decision

context

open as a page

What does a model card record about a model's intended use and training population?

level: juniorimportance: should knowfreq 44%

basics

~20 s

A model card is a short document shipped with a model stating what it is for, what it must not be used for, who and what the training data represented, how it performs on relevant subgroups, and its known limits.

open as a page

How do you rank adverse-action reason codes when correlated features split the attribution?

level: seniorimportance: nice to knowfreq 30%

basics

~20 s

Rank at the level of business reason codes, not raw features: map correlated inputs to one code and sum their contributions inside it. Add a deterministic tie-break so equal contributions produce the same order every run.

open as a page