Adverse action reason codes: from a model code to the letter

Adverse action reason codes are the short identifiers a credit decision engine emits to say which factors drove a decline — R14, R03, CP-4.2 — and on their own they tell an applicant nothing. Between the code and the letter sits a map: a table that turns each code into a sentence. Regulation B never mentions that table, and it is where most inaccurate denial letters are made, because the map is maintained by hand, versioned separately from the model that produces the codes, and changed by whoever happens to own the template. Adverse Action Notice Automation treats the map as something to be checked rather than trusted: every reason on every letter is traced back to the factor or policy rule that decided, and a notice is held when the words and the model's own documentation disagree.

What follows uses a fictional lender's sample data from the working prototype — a personal loan declined by a model called Personal Loan Score v7 — alongside the Official Interpretations to Regulation B, which are where the rules about reason selection actually live.

What are adverse action reason codes, and who writes the words?

A scoring model does not produce sentences. It produces a score and, alongside it, an ordered list of the factors that pushed the score down for this applicant — identified by code. A policy engine behaves the same way: a failed knockout rule arrives as an identifier and a measured value, not as prose. Somewhere downstream, a lookup turns each identifier into text the applicant will read, and a template drops that text into the letter.

Three different teams usually own the three pieces. Credit risk owns the model and its documentation. Compliance owns the letter and its approved wording. Technology owns the lookup. The code map is the seam, and nobody's control framework covers it: it is not a model under anyone's inventory, not a disclosure under anyone's template register, and not code under anyone's release process. It is a spreadsheet.

That matters because the map is doing legal work. The reasons printed on the letter are the creditor's statement under section 1002.9(b)(2), which "must be specific and indicate the principal reason(s) for the adverse action", and under the Official Interpretations they "must relate to and accurately describe the factors actually considered or scored by a creditor" (comment 9(b)(2)-2). Accuracy is a property of the mapping, not of the template.

How are the principal reasons chosen from a scoring model?

Regulation B does not prescribe a selection method, and it says so. Comment 9(b)(2)-5 offers two methods and blesses anything equivalent: "One method is to identify the factors for which the applicant's score fell furthest below the average score for each of those factors achieved by applicants whose total score was at or slightly above the minimum passing score. Another method is to identify the factors for which the applicant's score fell furthest below the average score for each of those factors achieved by all applicants. … Any other method that produces results substantially similar to either of these methods is also acceptable under the regulation."

Read carefully, both methods compare the applicant against a reference population, not against an abstract ideal. The first benchmark — applicants who just cleared the cutoff — is the more useful of the two, because it answers the question the applicant is actually asking: what separates me from someone who was approved. A method that ranks factors purely by their absolute contribution to this applicant's score can surface a factor that nearly every approved applicant shares, which is accurate arithmetic and a useless reason.

Two further constraints come from comment 9(b)(2)-4. The reasons "must relate only to those factors actually scored in the system", and "no factor that was a principal reason for adverse action may be excluded from disclosure". The second constraint is the one that bites on a model with correlated inputs: a lender that suppresses a factor because it is hard to explain, or because it looks bad in a letter, has excluded a principal reason. The same comment pre-empts the usual objection — the creditor "must disclose the actual reasons for denial (for example, 'age of automobile') even if the relationship of that factor to predicting creditworthiness may not be clear to the applicant".

Are credit score key factors the same as adverse action reasons?

No, and treating them as interchangeable is one of the most durable errors in consumer compliance. Key factors are an FCRA concept, defined as "all relevant elements or reasons adversely affecting the credit score of the particular individual, listed in the order of their importance based on their effect on the credit score" — the score here being the one from the consumer report, produced by the bureau's model, not the lender's. Principal reasons are an ECOA concept, and they describe the lender's own decision.

The Official Interpretations put the relationship beyond argument: "Disclosing the key factors that adversely affected the consumer's credit score does not satisfy the ECOA requirement to disclose specific reasons for denying or taking other adverse action on an application or extension of credit." The two lists appear on the same page, often within an inch of each other, and they may legitimately differ. A lender's custom model can weight a factor the bureau score barely notices; a bureau score can be dragged down by something the lender's policy ignores.

How many reasons belong on a letter, and where four comes from

Almost every lender prints up to four reasons, and almost every lender believes four is the legal maximum. It is not. Comment 9(b)(2)-1 says: "A creditor must disclose the principal reasons for denying an application or taking other adverse action. The regulation does not mandate that a specific number of reasons be disclosed, but disclosure of more than four reasons is not likely to be helpful to the applicant."

The difference is not academic. A hard limit of four, enforced by a template, will drop a fifth principal reason — and dropping a principal reason is a breach of comment 9(b)(2)-4, whereas printing five is at worst unhelpful. The sound design is a soft limit: rank the reasons, print four, and flag the case where a fifth is genuinely principal rather than silently truncating it. The FCRA cap of four key factors, five with inquiries, is a real cap, but it governs the score disclosure, not the statement of reasons.

Comment 9(b)(2)-3 relieves the lender of the opposite temptation: "A creditor need not describe how or why a factor adversely affected an applicant. For example, the notice may say 'length of residence' rather than 'too short a period of residence.'" Naming the factor is enough. Adding the applicant's own figure — eleven months, 87 per cent — is not required, but it is what turns a category into something the applicant can act on, and it is cheap when the figure is already in the trace.

What happens when a model version changes a code's meaning

This is the failure mode that produces the largest populations, and it leaves no trace on the letter. A scoring model is replaced. The new version reassigns a code: what was R14 under v6 becomes R38 under v7, and R14 now means something else. The decision engine starts emitting R14 for the new factor on the day v7 goes live. The map, approved for v6, keeps printing the v6 sentence.

Nothing errors. The letters look normal. In the working prototype's sample data the stale sentence was "insufficient credit" — a phrase carried over from the sample-form checklist — while model v7 had scored length of credit history, measured as an oldest account eleven months old, costing 41 points. Over thirty days the code was used 1,160 times.

Appendix C to Regulation B anticipated the shape of this failure forty years before anyone trained a gradient-boosted scorecard. "If the reasons listed on the forms are not the factors actually used, a creditor will not satisfy the notice requirement by simply checking the closest identifiable factor listed," it says, and gives the worked example of a lender that considers only bank references: its statement "should disclose 'insufficient bank references,' not 'insufficient credit references.'" A stale map does exactly what the appendix forbids, at scale and automatically.

The map, and the one line that no longer matches

Judgemental decisions, knockout rules and the grey band

Not every decline comes from a score, and the rules differ by component. Comment 9(b)(2)-6 requires that where a judgemental system is used, the reasons "relate to those factors in the applicant's record actually reviewed by the person making the decision". Comment 9(b)(2)-7 handles the combined case and is worth reading twice: "If a creditor denies an application based on a credit evaluation system that employs both credit scoring and judgmental components, the reasons for the denial must come from the component of the system that the applicant failed." Where the application lands in a grey band and a human assessment then declines it, "the reasons disclosed must come from both components".

Automatic denials have their own rule. Comment 9(b)(2)-8 provides that where a decision method "contains features that call for automatic denial because of one or more negative factors", such as a bankruptcy on file, the creditor "must disclose that specific factor". A knockout is therefore always a principal reason; it cannot be outranked by a model factor with a larger point contribution, because it is the thing that actually produced the decline.

This is why an override with no reason recorded is a hard stop rather than a nuisance. If an underwriter declined a file that the model would have approved, the reasons must describe what the underwriter looked at — and if nobody wrote it down, no amount of model explanation will produce a lawful letter. In the prototype those files surface in a queue of their own, sorted by days left on the clock, rather than being quietly filled from the score.

Keeping the map honest: version, approvals and a back-test

The CFPB's withdrawn 2023 circular described the right test in one sentence, and the sentence outlived the guidance: creditors "may not rely on the checklist of reasons provided in the sample forms … if those reasons do not specifically and accurately indicate the principal reason(s) for the adverse action", nor "rely on overly broad or vague reasons to the extent that they obscure the specific and accurate reasons relied upon" (Circular 2023-03, 89 FR 27361). That circular was withdrawn on 12 May 2025 along with dozens of others, which changed what the Bureau will cite and changed nothing about section 1002.9(b)(2) or the Official Interpretations it was summarising.

What a lender can do is make the map falsifiable. Pin it to a model version, so that a decision made by v7 can only use a map approved for v7. Require two approvals for a change — the model owner, who knows what the code means, and the compliance officer, who owns the letter. Re-trace a monthly sample from scratch, ignoring the map, and compare the result with what went out. And when a disagreement is found, scan the whole population that shares the code and version rather than reporting the sample.

What Adverse Action Notice Automation checks before a letter is drafted

In the prototype the checking agent compares the words for every reason code against the model's own documentation for the version that decided, and holds any notice whose words do not match. It never edits the map. New wording is proposed, and the model owner and the compliance officer both approve before the new version is used — in the sample data, map v7.1, after which the 214 held notices are rewritten with each applicant's own figure and checked again.

The analyst's side of this is one control. On the sample decline, pressing "rewrite from the factor" replaces "insufficient credit" with "length of credit history: oldest account 11 months", the margin note turns green at reading grade 5.2, and the two Regulation B checks that had failed — specific principal reasons, and reasons drawn only from factors the decision scored — pass. The letter moves from 12 of 14 rules met to 14 of 14. The credit decision is untouched, which is the point: nothing about the applicant's file changed, only the accuracy of the account given to her.

Map v7.1, approved by two people before any letter uses it

Reason accuracy and timeliness pull against each other on a 30-day deadline, which is why when the clock really starts is the companion question to this one, and why the parts a notice must carry are checked on the same screen. To see a decision traced to its reasons, start from Adverse Action Notice Automation.

Questions people ask

What is a reason code map?

The lookup table that turns each code emitted by a scoring model or policy engine into the sentence printed on a denial letter. It is usually maintained by hand and versioned separately from the model, which is why it goes stale. Regulation B never names it, but it is the thing that determines whether the statement of reasons accurately describes the factors actually scored, so it carries the legal risk of the letter.

How many reasons go on an adverse action notice?

Regulation B sets no number. The Official Interpretations say only that disclosing more than four "is not likely to be helpful to the applicant". Four is therefore a convention, not a cap, and a template that truncates at four can drop a principal reason, which the rules do forbid. The FCRA's limit of four key factors — five when inquiries are one of them — is a genuine cap, but it applies to the credit score disclosure, not to the statement of reasons.

Can a lender use a machine learning model if it cannot explain a decline?

The duty to give specific principal reasons applies whatever technology produced the decision, so a model whose declines cannot be described accurately cannot be used to decline. Post-hoc explanation methods approximate a model rather than report it, so the approximation itself has to be validated before its output becomes a reason on a letter. That trade-off is worked through separately in this series.

Are the reasons on a letter the same as the credit score factors?

No. The key factors describe the consumer report score, are supplied by the reporting agency with that score, and are ordered by their effect on it. The principal reasons describe the lender's own decision, including any policy rule or underwriter judgement that a bureau score knows nothing about. Printing the key factors alone does not satisfy the ECOA duty, even when every factor is accurate.

What should happen when a wrong reason is found on a sent letter?

Treat it as a population, not an incident. The same code and model version produced the same wording on every letter it touched, so the first step is to count them. The credit decisions usually stand; what is wrong is the account given of them. A corrected notice can then be drafted for each affected applicant, and whether those go out is a decision for the compliance officer, weighing the benefit of an accurate reason against the confusion of a second letter.

Who should approve a change to the words for a reason code?

At least two people with different knowledge: the model owner, who can say what the code measures in the version that is running, and the compliance officer, who owns what the letter claims. A single approver cannot check both halves. Recording both approvals, with the time, is what lets someone a year later reconstruct why a particular applicant was told what she was told.