Adverse action notice requirements under ECOA and the Fair Credit Reporting Act haven't fundamentally changed since their original passage. What has changed is the nature of the credit models those requirements now apply to — and the gap between what the regulations specify and what alternative data models actually produce is a real compliance challenge that most lenders using cash-flow underwriting haven't fully solved.
This article is about the practical compliance problem, not the regulatory overview. If you need the overview, the CFPB's 2022 circular on adverse action and algorithmic models is the most useful current guidance document. What I'm writing about here is what it looks like to actually implement compliant adverse action notices when your model's decline factors are things like "insufficient recurring payment consistency" or "cash-flow velocity below threshold" — not the standard bureau-derived codes your notice templates were built for.
What ECOA Requires (and Where Alternative Data Creates Friction)
ECOA and Regulation B require that when you take adverse action on a credit application — deny it, offer less favorable terms, or take adverse action on an existing account — you must provide the principal reasons for that decision. Specifically, Regulation B §1002.9 requires that the notice state the principal reasons or indicate that the applicant has the right to learn those reasons.
The key phrase is "principal reasons." Regulation B doesn't require you to disclose every factor in a complex model. It requires you to communicate the factors that most significantly drove the adverse decision — typically 2–5 reasons, in language the applicant can understand and potentially act on.
For bureau-based models, this is straightforward. Bureaus supply reason codes alongside scores — a standardized vocabulary of 20–30 factors (too many accounts recently opened, too high a proportion of revolving accounts to revolving limits, derogatory payment history, etc.) that have been in use for decades and have established interpretability. The reason code comes with the score output.
For alternative data models, there is no equivalent standardized reason code vocabulary. The adverse action reason for a decline based on cash-flow velocity analysis isn't "insufficient cash flow" — that's not specific enough. The applicant needs to understand what specifically about their financial behavior drove the decision. "Low average monthly inflow over the 12-month lookback period" is more specific. "Inconsistent recurring payment obligations in the prior 6 months" is more specific still. But are those statements interpretable to the average credit applicant, and are they actionable — meaning, does the applicant understand what they could change to receive a different outcome in the future?
The Interpretability Standard
The CFPB's 2022 circular addressed this directly in the context of complex algorithmic models. The guidance position is that lenders cannot use complexity as a shield — cannot claim that the model is too complex to produce meaningful reason codes. The expectation is that lenders build the interpretability infrastructure necessary to generate compliant adverse action notices regardless of model architecture.
For gradient boosting or similar tree-based models used in cash-flow underwriting, there are established techniques for generating per-decision feature importance scores — SHAP (SHapley Additive exPlanations) values being the most widely adopted. SHAP values assign each feature a contribution score for each individual prediction, telling you which features drove this specific decision for this specific applicant.
The compliance workflow we've built at Lendiro:
- Run the credit model and generate a decision (APPROVE / REVIEW / DECLINE).
- For DECLINE decisions, compute SHAP values to identify the top 3–5 features with the most negative contribution to the score.
- Map each top feature to a human-readable reason statement from a pre-approved reason code library.
- Surface those reason statements in the adverse action notice.
The reason code library is the piece that requires legal review and deliberate construction. You need reason statements that are (a) accurate translations of model features, (b) interpretable by a non-technical applicant, (c) actionable where possible, and (d) not inadvertently suggesting that the applicant's protected class characteristics drove the decision.
Building the Reason Code Library for Cash-Flow Features
Unlike bureau reason codes, which are standardized across vendors, cash-flow model reason codes are proprietary to each lender's model implementation. That means every lender using alternative data needs to build and maintain their own library. Here's how we've approached the mapping for the major feature categories:
Cash-Flow Velocity Features
Raw model feature: 12-month average monthly net inflow below threshold, with negative trend over last 6 months.
Reason code statement: "Monthly deposits into your bank account were insufficient to support the requested loan amount based on our analysis of your account activity."
What the applicant can do: the notice should specify that they may request the name of the data source (the bank account analysis) and contact information for disputing data accuracy — both required under FCRA Section 615 if a consumer report was used. For bank-permissioned data, the dispute pathway should be clearly stated.
Recurring Payment Consistency Features
Raw model feature: recurring obligation hit rate below threshold in the 9-month lookback window, with multiple missed payment periods detected.
Reason code statement: "Our analysis of your bank account activity identified a pattern of missed or delayed payments on regular monthly obligations."
Edge case: if the missed payments were due to a data gap (bank switched systems, account closed and reopened) rather than actual late payments, the applicant has a legitimate dispute. The reason code notice must include the data source and dispute contact.
Income Stability Features
Raw model feature: high coefficient of variation in monthly inflows over 24-month lookback, combined with recent 3-month inflow decline.
Reason code statement: "The income activity shown in your bank account was not sufficient or consistent enough to support the requested credit based on our underwriting standards."
Note: avoid language that says "unstable income" without qualification — this phrasing can be read as discriminatory toward gig workers or self-employed borrowers. Frame around "sufficient to support the requested credit" rather than characterizing the income itself.
FCRA Requirements When Bank Data Is a Consumer Report
Here's a nuance that a number of lenders using alternative data have gotten wrong: if you're pulling bank transaction data through a consumer reporting agency — which is what most open banking aggregators are, under the FCRA definition — then your adverse action notice must satisfy FCRA §615 in addition to Regulation B §1002.9.
FCRA §615 requires that the adverse action notice include: (a) the name, address, and phone number of the consumer reporting agency; (b) a statement that the agency didn't make the decision and can't explain why; and (c) notice of the right to obtain a free copy of the report and to dispute inaccurate information.
Whether your data provider qualifies as a "consumer reporting agency" under the FCRA is a legal determination that requires counsel — it's not a technical decision. But the general principle is that if a third party is compiling consumer information and furnishing it to you for credit eligibility purposes, the FCRA likely applies. Open banking aggregators frequently qualify. This matters because FCRA non-compliance on adverse actions is a well-litigated area with plaintiff-friendly fee-shifting provisions.
Audit Trail Requirements
Regardless of which regulatory framework governs your adverse action process, you need a complete audit trail: the model inputs used for each specific decision, the model output including reason codes, the notice text generated, and the date of notice delivery. This is both a regulatory requirement (ECOA record retention is 25 months for applications and 12 months for completed applications) and a practical defense in litigation.
For alternative data models, the audit trail has an additional requirement: you need to be able to demonstrate, for each adverse action, which data source produced the features that drove the decline. If the applicant disputes the accuracy of the underlying data, you need to trace the reason code back to specific account data from a specific time period — not just say "our model said so."
We're not saying that implementing this audit infrastructure is simple — it's not. Storing per-decision feature snapshots at production scale requires deliberate data architecture decisions. But it's not optional. A lender who builds a cash-flow underwriting model without the adverse action audit infrastructure is operating in regulatory exposure that the compliance benefit of alternative data doesn't offset.
Where Guidance Is Still Evolving
The CFPB's stance on adverse action explainability for complex models continues to develop. The 2022 circular established that model complexity doesn't excuse lenders from the explainability requirement, but it stopped short of prescribing specific techniques like SHAP. OCC guidance and FDIC guidance on model risk management (SR 11-7 and equivalent) address model interpretability from a risk management angle but don't specify adverse action mechanics.
The practical implication: lenders using alternative data should build their adverse action infrastructure to the interpretability standard the 2022 CFPB circular implies, document their methodology, and have legal review before going live. The regulatory environment around alternative data adverse action is not adversarial — regulators have expressed support for alternative data use to expand credit access — but they do expect that the fundamental consumer protections of ECOA and FCRA apply regardless of how novel the data or model is.
