What changed
FACT (Federal Register, CFPB, published 2026-05-01): the CFPB issued a final rule revising Regulation B subpart B, which implements Dodd-Frank section 1071. The rule amends coverage of certain credit transactions and financial institutions, the small business definition, inclusion of certain data points and how others are collected, and the compliance date. FACT (Federal Register, 2025-11-13): a proposed rule preceded it. FACT (Federal Register, 2025-10-02): the CFPB separately finalized an interim final rule extending the 1071 compliance dates set in the 2023 rule as amended by a 2024 interim final rule. INFERENCE: the net direction of the 2026 rule is narrowing/streamlining — the Bureau's own stated purpose is to 'streamline the rule, reduce complexity for lenders' — which means fewer covered institutions, not more.
Why now
HYPOTHESIS: a final rule that resets data points, coverage and the compliance date invalidates whatever half-built 1071 workflow a covered lender started under the 2023 rule, forcing a re-tooling decision in the next 6-12 months. That re-tooling window is the only moment a new vendor can displace an incumbent. FACT-LIMITED: the amended compliance date is not stated in the provided text and must be read from the rule itself — the entire urgency claim is unverified until that date is pulled. Given the CFPB extended dates once already (2025-10-02 rule), the base rate for further slippage is material.
Converging signals
Three things meet at one point: (1) a final rule defining who is covered; (2) a defined filer class — covered financial institutions originating small business credit above an origination-count threshold, including banks, credit unions, CDFIs, online lenders, MCA and equipment-finance firms; (3) a submission artifact — an annual small business lending application register of roughly 20-80 data points per application, collected under a statutory firewall separating demographic responses from underwriters, validated, and filed with the CFPB. INFERENCE (not stated in the provided text): the filing runs through a CFPB-operated platform analogous to the HMDA Platform. The data-point count and the firewall requirement come from the 1071 statutory/regulatory scheme, not from the abstract quoted here; treat exact counts as inference.
Customer pain
INFERENCE, not evidenced by any complaint or job posting in the input: a non-bank lender must add demographic questions to its application flow, store the responses behind a firewall from anyone who makes the credit decision, retain them for a year, assemble a machine-validated register, and file it. A bank with a core processor gets this bundled. An MCA shop running on a spreadsheet and a Zapier stack does not. The pain is that a firewall is an architecture requirement, not a form field — most small lenders' loan-origination stacks have no notion of a field the underwriter cannot see.
Who pays
The covered institution. Realistically the reachable buyer is the compliance officer or COO at a sub-$1B-asset credit union, a CDFI, or a non-depository small-business lender (MCA, equipment finance, revenue-based finance) — an institution too small to be an incumbent's account and too regulated to ignore the rule. NOT reachable: banks over a few billion in assets, who buy 1071 as a module from the vendor that already sells them HMDA and CRA.
Solved today
FACT (from the rule's own framing): the Bureau is amending 'how others are collected,' implying data is collected today under the 2023 rule's regime. INFERENCE on the market: the HMDA/CRA compliance vendor field pivoted into 1071 years ago — Ncontracts, Asurity's RiskExec, Wolters Kluwer, nCino, Baker Hill, Temenos, and the core processors (Fiserv, Jack Henry) all ship or announce 1071 modules. Below that tier, lenders use consultants, outsourced compliance firms, and Excel. I did not verify the current product state of any of these vendors from a cited source; treat every named competitor as an unverified inference.
Why current solutions are bad
For the target tail: incumbent tools are priced and sold for banks with a core-system integration, are bought through a vendor-management process, and assume a loan-origination system exists. A ten-person MCA funder has none of that. HYPOTHESIS: they are the segment currently unserved, and also the segment most likely to be exempted out entirely by the coverage cut this very rule makes — which is the central risk to the whole idea.
Proposed product
Two components, deliberately narrow. (1) An embeddable, hosted application-intake widget that presents the 1071 demographic questions, stores responses in a segregated store the lender's own staff cannot query, and returns only a non-identifying token to the lender's system — the firewall as a service, which is the part a small lender genuinely cannot build correctly. (2) A register assembler that joins the tokenized demographic responses with the lender's pricing and action-taken data, runs CFPB edit/validation rules, and produces the filing artifact. Do NOT build a submission robot against an unnamed CFPB portal on inference alone; build to the file format first, add direct submission only after confirming the platform exists and permits it.
MVP version
Ninety days, and the first thirty are not code. Thirty days: read the 2026-05-01 rule end to end, extract the actual amended compliance date, the final origination-count threshold, and the final data-point list; count covered non-bank institutions and confirm the tail is non-empty after the coverage cut. Only then: a single-tenant hosted intake widget (React + a Postgres store with row-level separation and an append-only audit log), a CSV/API ingest for the lender's application data, the CFPB edit-check ruleset, and a register export. No dashboards, no analytics.
30-day build
Kill-or-continue research sprint. Pull the rule, extract compliance date and threshold. Build a list of 100 named covered non-bank lenders and CDFIs from CDFI Fund award lists and state lender licensing rosters (public-records work — the founder's actual edge). Call twenty. Ask one question: who is assembling your 1071 register and what are you paying them? If fewer than five say 'nobody yet' or name a consultant billing hourly, stop. Concurrently, get a written scoping quote from two 1071 consultants — their fee is the price ceiling and the proof of existing spend.
60-day build
Build the firewall widget and edit-check engine against the final data-point list. Ship it as a paid pilot to three design partners at cost, in writing, with a clause that they become referenceable. Start SOC 2 Type I in parallel — not because it is required by law but because no lender's third-party-risk review will approve a vendor holding applicant demographic data without it, and that review is the real gate, not the sale.
90-day revenue plan
Convert two of three pilots to paid annual seats at $4,000-6,000, plus a per-register submission fee at filing season. Recruit the consultants met in month one as resellers: they keep the advisory fee, the software does the assembly, and they carry the trust the founder does not have. Realistic first revenue is month five, not month three — the pilot-to-paid step in regulated lending runs through a security review that no amount of demonstrated value shortcuts.
Distribution path
This is the weak dimension and it should be stated plainly. There is no self-serve channel. Trade associations (the small-business finance and equipment-leasing associations, CDFI coalitions), 1071 consultants as resellers, and direct outbound off a public-records-built list. The founder's stated strength is selling through demonstrated value rather than relationship sales, and this market buys almost entirely on relationship and vendor risk review. That is a real mismatch, not a solvable messaging problem.
Pricing hypothesis
$4,800/yr per institution for the widget plus assembler, plus $750 per register filed. The anchor is the consultant's hourly engagement, which is the existing spend the software undercuts. Do not price per application — it penalizes the customer for growing and invites a spreadsheet workaround.
Technical difficulty
Moderate on the surface, high in one specific place. The intake widget and validation engine are ordinary web work. The firewall — provably preventing the lender's own decision-makers from reading demographic responses, while still letting them run their business — is a genuine access-control and audit design problem, and it is the only part worth paying for. Getting it wrong exposes the customer to the exact liability they bought the product to avoid, and exposes the founder to it too.
Legal / regulatory risk
The founder becomes a service provider holding applicant nonpublic personal information for regulated financial institutions. That means GLBA safeguards obligations flowing through contract, state data-breach exposure, and standing in the customer's regulatory examination. This is not the FMCSA ELDT shape, where the founder passed a training certificate through a portal. Demographic credit-application data is a materially heavier custody than a course-completion record. HYPOTHESIS: this is survivable with SOC 2 and cyber insurance, and it is a moat once cleared — but it is a real cost and a real personal-liability surface, not a footnote.
Platform dependency
None in the deplatforming sense — the CFPB is a regulator, not a platform owner, and cannot revoke access commercially. But the dependency that matters is worse: the CFPB can amend the rule out from under the product, and per the input it just did, and per the 2025-10-02 extension rule it has moved the dates before. The product's addressable market is a variable the Bureau controls and has recently been shrinking.
Founder fit
Partial, and the lessons file's 0.80-confidence heuristic that government-portal mandates fit this founder best is doing more work here than it has earned. The shape matches: a rule compels a defined class to file, and software can charge per filing. The buyer does not match. FMCSA ELDT sold to training providers — unlicensed, unregulated, no vendor-risk committee, buying a $30 upload. This sells to supervised financial institutions whose purchasing runs through third-party-risk review, security questionnaires, and often a board-approved vendor list. The founder's profile explicitly avoids long trust cycles and deep enterprise software. A credit union's vendor onboarding is a long trust cycle wearing a small-company costume. The founder has operational credibility in industrial operations and public records; he has none in bank compliance, and in this market that is the thing being bought.
Breakout potential
Real if the firewall component becomes the standard the consultants build on. Modest otherwise. The expansion path — the same widget for HMDA, CRA, and state fair-lending reporting — is genuine, but every one of those markets is owned by the same incumbents, more deeply.
Final recommendation
CONDITIONAL — do not build; run the 30-day kill test first, and expect it to kill. The single decisive question is what the 2026-05-01 final rule does to the origination-count threshold and the definition of a covered financial institution. If the threshold rose such that the non-bank and small-bank tail is now largely exempt, this opportunity does not exist and no amount of product quality repairs it. If the tail remains covered AND the compliance date is inside eighteen months AND at least five of twenty called lenders name a consultant they are paying hourly, then it is worth the build — with the target narrowed hard to non-depository lenders (MCA, equipment finance, revenue-based finance) who have no core processor to buy from, and with SOC 2 Type I treated as a month-one line item rather than a month-six surprise. I am scoring founder_fit at 6, not the 8-9 the system's heuristic would assign to any government-portal mandate, because the heuristic was learned on FMCSA ELDT — a market of unregulated training providers — and does not transfer to supervised financial institutions with vendor-risk committees. The shape is right and the buyer is wrong, and the buyer is what determines whether a solo operator gets paid.
Next action
Read the full text of the 2026-05-01 final rule at federalregister.gov/documents/2026/05/01/2026-08494 and extract exactly three facts: the amended compliance date, the final origination-count threshold that defines a covered financial institution, and whether merchant-cash-advance and equipment-finance products remain covered credit transactions. Write those three facts down before writing any code. If the threshold exempts the tail, close this brief.