CFPB 1071 Small Business Lending and AI Agents: A Subpart B Playbook for the Firewall, the Data, and the Filing

The Rule Most Banks Underestimated Until It Was Almost Due

The CFPB's Small Business Lending Data Collection Rule under Section 1071 of Dodd-Frank added Subpart B to Regulation B at 12 CFR 1002.101 through 1002.114. It adds 81 reportable data points to every covered application from a small business and a hard architectural rule about who at the institution can see which of them. The compliance dates were pushed by court order and then again by an interim final rule, and the litigation status keeps shifting, but the institutions that won the extra time and used it to redesign their intake are in a better position than the ones that booked the relief as a permission slip to wait.

We work with banks and non-bank lenders that have to file. The lesson from the first cohort is that the rule is not the data-collection project people sold it as internally. It is an application-process redesign, with the AI agent sitting in the part of the workflow Subpart B specifically constrains.

What Subpart B Actually Requires

Section 1002.107 defines a covered application as an oral or written request for a covered credit transaction made by a small business under the institution's procedures used for credit decisions. Section 1002.108 lists the data the institution has to compile per application, which spans application identifiers, the credit type and purpose, the amount applied for and approved, action taken and reasons for denial, pricing information, and the demographic data about the applicant business and its principal owners. The institution then files an annual small business lending application register under 1002.109.

Two of those data categories carry the design weight. The demographic data, collected from the applicant under 1002.107(b), is the politically charged part: minority-owned, women-owned, and LGBTQI+-owned business status, plus the ethnicity, race, and sex of the principal owners. The action-taken and pricing fields are the part the agent has to populate from the system of record without inventing anything.

The Firewall Is the Sentence Most AI Designs Miss

Section 1002.110 is the part that decides how the agent has to be built. The institution must limit the access that any employee or officer involved in making any determination concerning a covered application has to the demographic responses, unless the institution determines it is not feasible to limit that access. If the institution relies on the infeasibility carve-out, it has to notify the applicants and the principal owners that the underwriter may have access to the demographic responses. There is no "we will trust our staff" version of this control.

For an AI agent, that sentence is the architecture. An agent that conducts the application intake, collects the protected-class responses under 1002.107(b), and then participates in any part of the credit decision is on the wrong side of the firewall. The same model context cannot do both. We design the intake and the decisioning as separate agents with separate data stores and separate logs, because a shared context that contains the demographic response is exactly what 1002.110 tells the institution not to give the decision-maker. If a customer chooses to keep the demographic question open until later, that is also part of the design: the rule lets the applicant decline to provide the information, and the agent records the decline rather than inferring.

We do not rely on the infeasibility notice as a default. It is a real provision and small institutions may legitimately use it, but every covered institution we have helped through this opted to build the firewall rather than disclose to applicants that their underwriter would see the protected-class data. The disclosure path is available; the customer-trust cost is not zero.

What the Intake Agent Does

The intake agent handles a covered application from the moment the applicant signals an inquiry into a small business credit product. It captures the structured fields the rule lists, asks the demographic questions in the language and format the rule's sample forms support, records refusals, timestamps the responses, and writes the data into a register-staging store the underwriting side cannot read. It also classifies the request to confirm it meets the covered-credit definition under 1002.103, because not every inquiry is a covered application, and counting an inquiry as an application when it is not is the symmetric error to missing one.

What the intake agent does not do is help the applicant pick a product or shape the application in a way that depends on the demographic answer. The rule's whole point is to break the link between the protected-class response and the credit decision, so any feature that closes that link is the violation. We make this a hard rule in the agent's policy: the demographic responses are written to the staging store and otherwise not available to the model for any subsequent turn.

The Action-Taken Fields and Why They Are a Logging Problem

The pricing, action-taken, and reasons-for-denial fields are not collected from the applicant. They come from the institution's own decision and have to be true to it. This is where the small-business register most often diverges from reality at filing time, because the systems that hold those fields were built before the rule and the data was never normalized to what 1002.108 requires.

The pattern we run is to write the relevant decision events directly to the register as they happen, rather than to reconstruct them from the loan origination system at year-end. When the underwriter takes the action, the action and its reason map straight into the data-point structure. The agent on the decisioning side does not generate denial reasons it cannot tie to the underwriter's basis. Reasons-for-denial that read like model output are a finding waiting to happen, because the institution has to be able to explain the basis if an applicant or a fair-lending examiner asks. We treat the denial-reason field the same way we treat an adverse action notice under Regulation B 1002.9: the basis is a human's, recorded, and the agent's role is to format and deliver, not decide.

Recordkeeping and the Question Asked First in an Exam

Section 1002.111 sets the recordkeeping duty: maintain evidence of compliance with Subpart B for at least three years after submission of the register. The 2023 Filing Instructions Guide breaks the register format down to the field level, and the institution's filing is mechanically validated against it. A miss on the firewall is a finding; a miss on the format is a refused filing.

What we hand to a covered institution is two parallel files. The intake file holds the application register data and the evidence that the demographic responses were collected per 1002.107(b), with timestamps, declines recorded, and the sample-form language the customer saw. The firewall file holds the access controls on the demographic store, the role assignments showing which decision-makers were blocked from the data, and the audit log proving they were. If the institution chose the infeasibility carve-out, that file also holds the applicant notice text and the dates it ran. Either an examiner asks for these or no one does, and the difference is whether the program is built around the rule or bolted onto it.

The Status of the Rule, Honestly

The compliance dates have moved more than once. The Texas Bankers Association v. CFPB litigation produced a stay, the Supreme Court's 2024 decision in CFPB v. Community Financial Services Association resolved the funding challenge, and the CFPB then revised the timelines and is now operating at reduced capacity. Whether enforcement on the original schedule is realistic is a separate question from whether the rule is on the books, and the rule is on the books. We tell customers to assume two things at once: the data-collection design is what an enforcer will ask about whenever an exam runs, and a private fair-lending claim does not need the CFPB to be at full strength to use the data the institution files against it. The institutions that put off the firewall question are not really gaining time; they are accruing the redesign cost at interest.

The Trade-Off

A clean Subpart B build slows the small-business application flow at the moment the intake agent has to ask the demographic questions and reroute around the firewall. The minute or two of customer time and the engineering work to keep the demographic data out of the decisioning context are real. The return is a filing the institution can defend, an intake design that does not create a fair-lending pattern, and the ability to onboard the next AI workflow on top of an application infrastructure that already separates collection from decision. We build the firewall once, on purpose, and stop carrying the rule as a project the institution dreads.