The CFPB's final rule implementing Section 1071 of the Dodd-Frank Act is no longer a future compliance project for the largest covered financial institutions. With the first Tier 1 compliance date now reached, teams that originate 2,500 or more covered credit transactions annually are in active reporting territory. Tier 2 and Tier 3 institutions are watching closely and building toward their own deadlines.
What is easy to underestimate at this stage: the rule does not slot neatly into the existing HMDA control framework. Section 1071 shares surface-level similarities with Home Mortgage Disclosure Act reporting, but the data points, the firewall requirements, and the permissible use restrictions create their own compliance obligations. We went through the 23 data fields the rule requires covered institutions to collect and mapped them to the control families most likely to need revision.
What the Rule Actually Requires
Section 1071 requires covered financial institutions to collect and report data on small business credit applications from women-owned, minority-owned, and small businesses broadly. The rule covers applications for credit, not just approved extensions. That scope distinction matters for loan origination system configuration and for application intake workflows that historically only triggered data capture on approvals.
The 23 data points fall into four broad clusters: application-level identifiers (unique application number, application date, credit type, credit purpose), business-level characteristics (gross annual revenue, NAICS code, time in business, number of principal owners), applicant demographics (racial identification, sex/gender, ethnicity of principal owners), and action-taken fields (approval, denial with reasons, withdrawn, incomplete).
The firewall requirement is where institutions trip up. Personnel involved in credit decisions may not have access to collected demographic information. That is not simply a database-level permission control; it implicates how application intake staff route information, how underwriting review systems surface data, and how any integrated decisioning layer is architected.
Which Control Families Are Affected
Going through the obligation set, we see five control families that are most likely to need meaningful revision rather than minor updates:
Data Collection and Intake Controls
Most institutions have intake controls built around an approved/declined binary, with demographic data captured at point of sale for HMDA-covered mortgage applications. For Section 1071, the trigger is the application event itself, and the data collection obligation applies regardless of product type across covered credit. Controls governing when intake staff prompt for information, how voluntary collection of demographic data is recorded, and what happens when an applicant declines to provide demographics all need to be re-examined.
One community bank we spoke with had no documented procedure for the "applicant did not provide" response path for demographic fields. For HMDA, that gap had never surfaced in examination because examiners focus more on denial rate patterns than collection completeness. Under 1071's emphasis on underserved lending data, collection completeness is more directly in scope.
System Access and Firewall Controls
The firewall requirement means that access controls governing who can see demographic information within your loan origination system need to be formally documented and tested. This is not a new concept, but it is a new application for many commercial lending systems that were not built with the same demographic isolation architecture as consumer mortgage systems.
The critical control evidence requirement: the institution must be able to demonstrate that a credit decision maker who reviewed an application could not see the demographic fields at the time of decision. That means access log controls, permission scope documentation, and periodic review protocols. We are not saying institutions need to rebuild their systems; we are saying the existing access control audit trail needs to explicitly address demographic data isolation in the Section 1071 context.
Denial Reason Documentation
For denied applications, the rule requires the institution to report up to four reasons for denial from a defined list of 14 reasons. This aligns roughly with existing HMDA denial reason categories, but the list is not identical, and the requirement to report up to four reasons rather than a single primary reason is a substantive change for institutions whose underwriting workflow captures only a primary denial code.
Control gap here: underwriting decision workflows and the LOS configuration that drives denial reason capture likely need updating. If an underwriter enters a single denial reason and the system closes the workflow, the multi-reason capture requirement is not met. That gap will show up in CFPB examination as a data quality finding.
Record Retention Controls
The rule requires retention of Section 1071 data for three years from the date the data is submitted to the CFPB. This is distinct from the existing BSA/AML five-year retention baseline and from standard consumer loan file retention requirements. Mapping the 1071 data set to your existing retention schedule and confirming that the demographic data elements are stored in a location and format that survives your standard records disposition process is not glamorous work, but it is the kind of control gap that surfaces in examinations as a procedural deficiency.
Annual Reporting and Submission Controls
Section 1071 data must be reported to the CFPB annually, with submission by June 1 of the year following the calendar year covered. The submission format is specified by the CFPB's Filing Instructions Guide, which parallels the HMDA FIG structure but is not identical. Institutions that self-report HMDA often initially assume they can plug 1071 into the same workflow. The field mapping differences mean that assumption should be validated explicitly rather than presumed.
Where We See Compliance Teams Getting Stuck
The most common friction point we have seen in working through the rule is the NAICS code obligation. The rule requires institutions to collect the NAICS code for the business applying for credit. This is often not a field that exists in commercial loan applications today. Either the intake form does not ask for it, or when it does, there is no downstream validation or standardization step. A NAICS code field that accepts free-text entry and is not validated against the official NAICS list is a data quality exposure rather than a compliance control.
Gross annual revenue is a second friction point. The rule requires collection of gross annual revenue from the applicant, not from a third-party data source or a bank-verified figure. The "self-reported" nature is deliberate and is part of the fair lending data picture the CFPB is building. Controls that route this field through a bank-derived or bureau-derived revenue estimate rather than capturing what the applicant actually reported are misaligned with the obligation.
A Note on What Section 1071 Is Not
We want to be direct about one thing: Section 1071 is a data collection and reporting obligation, not a fair lending lending mandate on its own. The rule creates a data set that the CFPB and others will use to evaluate whether institutions are serving small businesses equitably. It does not, by itself, tell an institution it must change its lending criteria. Compliance teams that conflate the two end up either over-building around fair lending obligations that are handled elsewhere or treating the 1071 control build as purely administrative. Both mistakes are costly.
The control build for 1071 is primarily about data integrity: did you collect the right data, did the right people have access at the right time, can you report it accurately, and can you retain and produce it if examined. Those are system and process controls, not underwriting policy controls.
How We Are Tracking This in Regloom
When we built the 1071 obligation set into Regloom's regulatory mapping layer, we treated each of the 23 data fields as a discrete obligation and mapped them independently against control categories. The advantage of that granularity: when the CFPB issued its June 2025 implementation guidance clarifying the NAICS code collection procedure for non-profit business applicants, Regloom flagged it as a change specifically to the NAICS collection obligation and tagged it against the controls that address data collection procedures for that field. Without that level of obligation-to-control specificity, guidance like that tends to get filed as a general "1071 update" and either missed or duplicated across multiple control reviews.
The 1071 compliance calendar is also worth building as an explicit calendar artifact rather than treating it as a subset of existing HMDA workflows. The deadlines diverge at several points, and exam preparation for 1071 involves evidence sets that differ from HMDA in meaningful ways. Treating them as the same workflow is a good way to produce an examination response that falls short on one while looking complete on the other.