Adverse Action Reason Codes

Reason codes must be presented in descending order of importance, listing the factors that most significantly contributed to the adverse decision first.

• The top reason typically accounts for the largest marginal contribution to the negative outcome
• Ordering is derived from feature attribution values (e.g., SHAP values) rather than arbitrary ranking
• FCRA requires disclosing the principal reasons — typically 2-4 factors — not an exhaustive list of all model inputs
• Example: A credit denial might list 'Delinquency on existing accounts' before 'Length of credit history' because the former had greater predictive weight

Reason codes must translate technical model features into plain, actionable language that a consumer can understand and address.

• Raw feature names like utilization_ratio_3m_avg become 'Proportion of credit lines used in the last 3 months'
• Codes should avoid jargon, acronyms, or model-specific terminology
• Each code must describe a specific behavior or condition, not a vague category
• Example: Instead of 'High risk score,' use 'Too many recent credit inquiries'
• The consumer should be able to identify concrete steps to improve their standing

Reason codes must clearly differentiate between factors that negatively impacted the decision and those that were merely present but neutral or positive.

• Only adverse factors should appear as reason codes — listing positive factors alongside negatives creates confusion
• A feature may be highly important to the model but not adverse if its value was favorable
• Example: A high income is important to the model but should never appear as a denial reason
• Systems must implement logic to filter attribution values to only those features where the instance value moved the prediction toward denial

Reason codes must remain consistent under small perturbations of input data to maintain consumer trust and regulatory defensibility.

• If a minor change in one feature causes a completely different set of reason codes, the explanation lacks robustness
• Techniques like integrated gradients or averaging over local perturbations improve stability
• Regulatory examiners may test for explanation consistency by submitting near-identical applications
• Example: A $50 difference in reported income should not swap 'Income insufficient' for 'Debt-to-income ratio' as the top reason

Each reason code must be fully traceable to the underlying model logic, feature values, and attribution computation for regulatory examination.

• The algorithmic audit trail must link each code to: the specific feature, its instance value, its attribution score, and the method used to compute that score
• Model risk management teams require deterministic reproduction of reason codes from archived model artifacts
• Discrepancies between reason codes and counterfactual analysis (e.g., 'What if this feature changed?') can indicate explanation failure
• Example: An examiner should be able to verify that 'Number of recent address changes' was indeed the second-most adverse factor for a specific application

Internal model features must map to standardized regulatory reason codes that satisfy jurisdiction-specific disclosure requirements.

• FCRA Appendix C provides model forms for adverse action notices in credit decisions
• ECOA (Equal Credit Opportunity Act) requires specific formatting and content for credit-related adverse actions
• Financial fraud models may need to map anomaly scores to BSA/AML suspicious activity report categories
• A single internal feature may contribute to multiple regulatory codes — systems must handle this many-to-many mapping
• Example: A model feature for 'Velocity of wire transfers' might map to both 'Unusual transaction frequency' and 'Potential structuring activity'

Concise, human-readable statements—typically the top 3–5 features driving a specific decision—that provide the primary reasons for a model's adverse action. In fraud detection, a reason code might state: 'Transaction amount exceeds typical profile by 4.2x' or 'Device location inconsistent with cardholder address.' These codes bridge the gap between opaque model outputs and regulatory requirements under FCRA and ECOA, giving consumers actionable insight into denial decisions.

A method that identifies the minimal changes to input features that would alter a prediction to a desired outcome. For adverse action reporting, counterfactuals answer: 'What would need to change for this transaction to be approved?' Examples include:

• 'If the transaction amount were below $500 instead of $1,247, the score would drop below threshold'
• 'If the device had 30+ days of history instead of 2 hours, risk would be acceptable' These explanations are highly intuitive for consumers and satisfy CFPB guidance on actionable denial reasons.

A comprehensive, chronological record of the data, model parameters, decisions, and logic used for a specific transaction. For each adverse action, the audit trail captures:

• The exact model version and feature values at inference time
• The top reason codes generated and their SHAP value magnitudes
• The decision threshold applied and any override logic This provides full traceability for regulatory review under SR 11-7 and OCC model risk management guidelines, ensuring every denial can be reconstructed and justified.

A model inspection technique that measures the decrease in model performance when a single feature's values are randomly shuffled. While SHAP provides local explanations for individual adverse actions, permutation importance offers global insight into which features the model relies on most:

• Breaks the relationship between the feature and the true outcome
• A large performance drop indicates high dependence
• Helps validate that reason codes align with intuitively important fraud indicators This technique is critical for model governance teams auditing whether reason codes reflect genuine fraud signals rather than spurious correlations.

A structured, short document accompanying a trained model that provides essential information on intended use, evaluation results, limitations, and ethical considerations. For fraud models generating adverse action reason codes, model cards document:

• The intended use case and approved decision contexts
• Fairness evaluations across protected demographic segments
• Known limitations of the reason code generation methodology
• Adverse impact test results to demonstrate FCRA/ECOA compliance Model cards increase transparency for regulators and internal audit teams reviewing automated denial systems.