Regulation B's adverse action notice requirement is one of the most operationally concrete obligations in fair lending law. When a creditor denies an application or takes adverse action, it must provide the applicant with specific reasons. Not categories. Not scores. Specific, articulable reasons that a person could act on.
For decades, this requirement was relatively manageable because decisioning logic lived inside the lender's own system or in the scoring models provided by the credit bureaus, which came with pre-defined reason code libraries. When a third-party API makes the material decision — applying a model the lender does not own, running on a platform the lender does not control — the explainability requirement does not change, but the compliance architecture becomes more complex. Someone has to own the explanation. Someone has to produce the reason codes. Someone has to ensure they meet Regulation B's specificity standard.
The Regulation B Requirement, Precisely Stated
Section 1002.9 of Regulation B requires that a creditor provide written notice of adverse action within 30 days of receiving a completed application. The notice must include a statement of specific reasons for the action taken, or a disclosure of the applicant's right to receive a statement of reasons within 60 days.
The CFPB's official commentary to Regulation B is explicit that the reasons must be specific enough to allow the applicant to understand what aspect of their application or credit history drove the adverse action. "Lack of creditworthiness" is not sufficient. "Credit score below minimum threshold" is not sufficient. "Insufficient length of credit history" is sufficient. "Too many recent applications for credit" is sufficient.
Translating this standard to a cash-flow model: "Cash-flow score below minimum" is not sufficient. "Insufficient consistency of deposit income over the 24-month review period" is sufficient. "Recent non-sufficient funds events indicate cash-management risk" is sufficient. The distinction is not between long and short explanations — it is between explanations that reference a specific, observable characteristic and those that reference an opaque aggregate output.
Who Is Responsible When the Decision Lives in a Vendor API
The lender. Full stop.
This is not ambiguous under the current regulatory framework. The CFPB has stated clearly that the adverse action obligations under ECOA attach to the creditor — the entity making the credit decision. When that creditor uses a third-party model, the creditor must ensure that model's outputs are explainable and that the explanation reaches the applicant in a Regulation B-compliant form. The vendor's responsibility is contractual — to the lender — but the regulatory responsibility remains with the lender.
This has practical implications for vendor procurement. A lender that integrates a cash-flow decisioning API and cannot produce Regulation B-compliant adverse action reasons from that API's outputs is not in compliance, regardless of what the vendor contract says about the vendor's responsibilities. The question in an examination is whether the lender's adverse action notices met the standard — not whether the vendor promised they would.
Designing the Reason Code Architecture
The mechanism that makes API-embedded underwriting compatible with Regulation B adverse action requirements is a structured reason code library: a defined set of codes, each with a compliant plain-language description, that the API can return as output and the lender's system can map to the final adverse action notice.
A well-designed reason code library for a cash-flow decisioning API has several properties:
- Coverage of all decision factors. Every feature that the model can weigh negatively in a decline decision must have a corresponding reason code. If the model considers 15 features and only 8 have reason codes, the remaining 7 are effectively undisclosed decision factors — a Regulation B problem waiting for an examination.
- Specificity of description. Each reason code's description must pass the Regulation B specificity test. The description should reference an observable characteristic of the applicant's financial behavior that the applicant can understand and, where possible, improve.
- Prioritization logic. Most adverse action notices include three to five reasons. The model must have a documented method for selecting which reason codes to surface when more than five factors contributed negatively. Typically, the top reasons by feature contribution weight are selected, but the selection logic must be documented and consistent.
- Positive factor exclusion. Adverse action reason codes should reflect the factors that drove the adverse outcome, not the factors that the applicant does well. A reason code list that includes "strong income consistency" as a mitigating note is not compliant — adverse action notices explain the negative, not balance the positive.
A Practical Adverse Action Notice Scenario
Consider a small personal loan application processed by a fintech lender whose decisioning system calls a cash-flow API after the applicant connects their bank account. The API returns a decline recommendation with the following reason codes:
CF_NSF_02— Non-sufficient funds events present in the past six monthsCF_COV_04— Monthly fixed obligations exceed 65% of average monthly depositsCF_INC_07— High variability in monthly deposit amounts over the review period
The lender's adverse action notice generation system maps these to plain-language statements:
- "Your bank account history shows instances of non-sufficient funds within the past six months."
- "Your monthly recurring obligations represent a high proportion of your monthly income deposits."
- "Your monthly income deposits have shown significant variation over the review period."
Each statement is specific, references observable financial behavior, and gives the applicant actionable information. An applicant who reduces their fixed-obligation-to-income ratio over the following 12 months and reapplies should receive different feedback. That is the purpose the statute is designed to serve.
Model Documentation as a Regulatory Record
Adverse action reason code design is inseparable from model documentation. Examiners reviewing fair lending compliance will ask to see the model documentation for any algorithm used in credit decisions. That documentation must describe: what features the model uses, how those features are weighted, how the model's outputs are mapped to reason codes, and how the reason code selection logic works.
For a vendor API, this documentation must be provided by the vendor in a form sufficient for the lender to satisfy OCC Bulletin 2013-29 / SR 11-7 model validation requirements. A vendor that declines to provide model documentation on the grounds of proprietary concern is not a vendor whose model can be used in regulated credit decisioning. Model documentation does not require disclosing trade secrets; it requires disclosing the feature set, the reason code library, the validation methodology, and the performance metrics — all of which are necessary for the lender to meet its regulatory obligations.
The CFPB's Algorithmic Adverse Action Guidance
The CFPB issued guidance in 2023 reaffirming that adverse action reason requirements apply regardless of model complexity. The guidance was directed specifically at lenders using AI and machine learning models, making explicit that the opacity of a complex model does not excuse a lender from the obligation to provide specific adverse action reasons.
We're not saying complex models are incompatible with Regulation B compliance. Properly designed complex models — including ensemble methods and gradient boosting models commonly used in cash-flow underwriting — can produce well-defined, feature-attributed reason codes through SHAP values or similar attribution techniques. The technical capability exists. The question is whether the vendor has built it into the model architecture from the start or whether explainability has been bolted on as an afterthought. The difference matters significantly to both model quality and compliance durability.
Ongoing Obligation: What Changes When the Model Changes
A final compliance point that is frequently overlooked: adverse action notices must reflect the model that made the decision at the time it was made. When a decisioning vendor retrains the model — adjusting feature weights, adding new features, recalibrating thresholds — the reason code library may need to be updated accordingly. Lenders must ensure their vendor agreements include: (1) notification when the model is materially retrained, (2) documentation updates reflecting any changes to the reason code library, and (3) a model version field in the API response that allows the lender to identify which model version governed any given historical decision.
Without these provisions, a model retrain can silently change the adverse action reasons being generated for new decisions while historical records reflect a different model's logic — a documentation gap that creates compliance exposure in any examination that spans the retrain date.