Open banking and Section 1033: customer choice, data access and an unsettled timetable

Customer choice and the current legal position

The CFPB’s compliance page, checked September 30, 2026, continues to report that the Personal Financial Data Rights Rule’s compliance dates were stayed by the court on October 29, 2025. It also describes the August 2025 advance notice of proposed rulemaking. A stayed compliance timetable is different from a final replacement rule. The rule text below is a reference framework, not an assertion that its original phased compliance deadlines are currently operative. [1]

Open banking is broader than a credit decision. With appropriate permission and usable connections, account data can support a consolidated financial view, comparison of services, payment workflows and applications for financial products. The economic issue is whether the customer can obtain a useful service at an acceptable total cost while understanding and controlling the data use. A bank can be both a source of data and a provider of services that use it.

Keep four different legal dates separate

The Federal Register published the final rule on November 18, 2024 and specified January 17, 2025 as its effective date. Its first original data-provider compliance phase was April 1, 2026, with later phases through April 1, 2030. The CFPB’s compliance page reports that the court stayed the compliance dates on October 29, 2025. Those facts can coexist: publication, effectiveness, phased compliance and a later stay are different events. [1][6]

The August 22, 2025 reconsideration advance notice is another separate event. It asks questions; it does not itself amend the operative text. Read the provisions below as the 2024 reference framework subject to the reported stay and reconsideration. This article does not claim that an original deadline is enforceable today or that a future replacement rule will preserve the same scope, fee prohibition or timetable. [5]

Scroll horizontally to see all columns.

What the 2024 framework actually covers

The CFPB’s final-rule summary centers on Regulation E accounts, Regulation Z credit cards and certain payment-facilitation products. Covered data include balances, transaction history, payment information, terms, upcoming bills and basic account verification. Specified exclusions protect confidential commercial information, information collected solely for fraud or anti-money-laundering purposes, and other protected data. Small depository institutions have a defined exemption. Scope must be tested against the rule rather than assumed from the label “fintech.” [2]

A standalone installment loan is not automatically a covered product merely because it is financial. Nevertheless, its lender may receive covered deposit-account data at a consumer’s direction. A practical product map should identify the legal entity, product, source account, requested fields, recipient and permitted use. That map is the foundation for procurement, privacy notices and data lineage.

Start with the customer task

The following are analytical use cases, not a claim that Section 1033 mandates each product or gives every provider unlimited access. Access to data is one step in a service; execution, customer authorization and other applicable obligations remain distinct.

For example, identifying recurring payments in an account may help a customer plan a switch, but seeing a payee in transaction history does not itself move that payment instruction or cancel the old arrangement. Likewise, an account-balance observation does not guarantee sufficient funds when a later payment settles.

Scroll horizontally to see all columns.

Interfaces, consent and downstream use

Section 1033.301 describes consumer and developer interfaces and prohibits charges for the interfaces or covered access requests under the 2024 framework. Those are provisions of the reference rule; the stayed timetable and reconsideration must accompany any implementation claim. [3]

Section 1033.421 limits third-party collection, use and retention to what is reasonably necessary for the requested service. It excludes advertising, cross-selling and selling covered data from that necessity standard. Collection authorization lasts no more than one year without reauthorization. Revocation must be straightforward and flow through relevant parties; security, accuracy and downstream contractual responsibilities also matter. [4]

Operationally, a consent screen is only the beginning. An effective implementation links consent to individual data pulls, derived features and downstream recipients. Revocation must stop collection at the actual collection service. Retention logic needs an explicit service or legal rationale rather than an indefinite “might be useful” default. Model features should remain reproducible for a past decision without enabling unauthorized new collection.

Design authorization as a traceable chain

Under §1033.401, authorization involves the consumer-requested service, the required disclosure and certification, and express informed consent through an electronically or otherwise signed disclosure. Section 1033.411 specifies the disclosure content, including the parties, service, data categories, duration and revocation method. Section 1033.431 addresses the aggregator’s role and certification. Outsourcing the connection does not erase the authorized third party’s responsibilities. These descriptions concern the reference rule, with the stayed schedule noted above. [7][8][9]

A practical design assigns one authorization identifier to the service, accounts, fields, recipients and permitted collection period. Link each retrieval to that record. Keep the authorization state separate from the model-decision record: permission can expire even though an earlier credit decision still requires an audit trail. A new marketing purpose should not inherit access merely because the same customer previously authorized underwriting.

Hypothetical lifecycle test: a customer authorizes an account connection for an installment application, receives a decision, and later revokes access. Test the customer interface, aggregator token, scheduled data pulls, vendor queues and downstream recipients. A success message on the website is not evidence that those systems stopped collection. The bank or lender should be able to show the final authorized pull and the blocked next attempt, with a documented reason for any data it continues to retain.

The reference rule distinguishes stopping collection from continued use or retention that remains reasonably necessary for the requested service. [4] Avoid both blanket assumptions: revocation is not permission to retain everything forever, but neither is it automatically an instruction to erase legally necessary decision records. Map each retained item to its purpose, applicable requirements, access restrictions and deletion schedule. Legal and privacy owners should resolve conflicts before production.

What reconsideration could change

The August 22, 2025 advance notice asks about representatives acting for consumers, fees to offset access costs, security concerns and privacy risks. An advance notice gathers input; it does not itself replace the final rule or establish a new fee schedule. [5]

The strongest provider concern is that infrastructure expense and fraud exposure can rise while others monetize the data. The strongest access concern is that pricing, restrictive interfaces or vague security objections can make portability nominal. These are competing policy considerations, not a finding that either side’s preferred design is correct. A defensible design documents security exceptions, measures failed requests and supports a change in commercial terms without rewriting the consent architecture.

The Unified Agenda entry for RIN 3170-AB39 places reconsideration at the proposed-rule stage and lists an estimated NPRM month of July 2026. An agenda target is not proof that a proposal was published, and a missed planning date is not a compliance deadline. The CFPB’s regulation-version index still lists January 17, 2025 as the current text in this check. Monitor the actual published proposal, final text and court orders rather than converting an agenda forecast into operative law. [10][11]

Worked example: coverage before model lift

Illustrative calculation, not observed performance: out of 10,000 eligible applications, 60% connect an account and 80% of those return sufficient history. Only 4,800 applications have usable data. A model evaluated solely on that subset cannot establish benefits for all applicants. Connected applicants may differ in income regularity, bank relationships, digital access or willingness to share.

Measure approval rate, early delinquency, fraud and contribution margin at a constant risk tolerance, with a credible comparison group. Separate gains from better risk ranking from gains caused simply by changing the cutoff. A 20-basis-point reduction in annual losses on a hypothetical $100 million portfolio is $200,000 before data, servicing, validation and implementation costs. If those costs exceed the benefit, more data can still produce worse economics.

A connected account is not a completed service

Hypothetical account-switching tool: of 10,000 interested customers, 6,000 connect an account, 4,500 obtain a usable recurring-payment review and 2,250 confirm that the selected instructions have been moved. Completion is 22.5% of the original group, even though the connection rate is 60%. The numbers are illustrative and do not measure the performance of any provider.

Analysis: evaluate where users stop and whether the tool reduces the work needed to finish their intended task. Better data coverage may help, but confusing instructions, missing payees and separate provider processes can remain barriers. Measure permission revocations, correction time, support expense and completion alongside API uptime. A technically successful connection is insufficient evidence of customer benefit or a profitable product.

Controls that remain useful across policy outcomes

Recommended ownership: product defines the consumer service; compliance maps permission and disclosures; information security reviews each connection; model risk validates derived features; operations owns failures and revocation. Vendor diligence should test field definitions, freshness, missing-history treatment, account ownership matching and deletion propagation. Contract promises need sampled technical evidence.

For credit decisions, access permission and model suitability are separate questions. Test whether volatile cash flows are interpreted correctly for seasonal workers and whether a broken connection is being treated as evidence of financial distress. Preserve understandable adverse-action reasons under applicable credit law. An applicant who declines optional sharing should have a defined alternative process where the product permits one.

Recommended dashboard: eligible-to-connected conversion, complete-history rate, stale-data rate, revocation completion time, disputed features, vendor incidents and outcomes by meaningful borrower cohort. None is a substitute for a legal scope analysis, but together they show whether the intended service works.

Separate API reliability, decision quality and commercial viability

Recommended service metrics have different denominators. Interface availability is not the same as successful authenticated access; successful access is not the same as a complete usable history; a complete history is not the same as correctly classified income. Measure each transition and its failure reason. A single “connection success” percentage can hide a lender discarding many connected applicants later in the process.

Use the earlier hypothetical 4,800 usable records from 10,000 applications. If a provider charges per attempted connection, per successful connection, or per ongoing refresh, the same apparent unit price can produce very different total cost. Model the fee basis, retries, duplicate accounts, support and renewal separately. Any assumed future access fee is a commercial scenario, not a claim that the stayed 2024 rule already permits such fees.

For cards, ongoing line management may require refreshed data and a clearly supported service purpose; for a one-time installment application, indefinite monthly collection may not be necessary. Make the use case explicit before designing retention or model retraining. Test the nonconnection path as carefully as the connected path, including alternative documents, customer explanations and fair-lending review. Data access can lower friction while adding a new exclusion mechanism for people whose accounts cannot connect.

The investment decision should be staged. Reusable authorization, lineage, security and exception handling can support several outcomes of reconsideration. Commitments that depend on a particular mandated interface, price or compliance deadline need explicit contingencies. Evidence of a final replacement rule or a court order changing the stay would alter the legal plan; measured coverage, incremental performance and total costs would alter the business case. Those are separate change triggers.

Separate the policy timetable from the product case

The current legal status should be updated when a controlling court action or final agency measure changes it. The CFPB notice checked for this revision continues to describe stayed compliance dates; proposed revisions and timetable estimates are not substitutes for an operative action. [1]

Analysis: evaluate each use case on its own completion rate, data quality, customer benefit and total cost. Lending may depend on better verification or decision performance; financial-management services may depend on coverage and correct categorization; account switching depends on completing changes outside the data connection. These distinct outcomes explain why one general adoption number cannot establish the value of open banking.

The case for investment strengthens when customers accomplish their chosen tasks more reliably, understand permissions and can correct errors without excessive friction. It weakens when fees, incomplete data or difficult revocation erase those gains. Durable product design and legal monitoring can proceed together without presenting the stayed timetable as a current launch deadline.

Sources

1. CFPB, Personal Financial Data Rights compliance resources; page modified January 6, 2026, checked September 30, 2026; reports October 29, 2025 stayOfficial sourceBack to text: ↑1↑2↑3
2. CFPB: October 2024 final-rule executive summaryOfficial source · PDFBack to text: ↑
3. 12 CFR 1033.301: interfaces and chargesOfficial textBack to text: ↑
4. 12 CFR 1033.421: third-party obligationsOfficial textBack to text: ↑1↑2
5. CFPB: August 22, 2025 reconsideration advance noticeOfficial sourceBack to text: ↑1↑2
6. Federal Register, Required Rulemaking on Personal Financial Data Rights, 89 FR 90838; November 18, 2024; original effective date January 17, 2025Official sourceBack to text: ↑
7. CFPB, 12 CFR 1033.401, third-party authorization; 2024 rule text checked September 27, 2026Official textBack to text: ↑
8. CFPB, 12 CFR 1033.411, authorization disclosure; 2024 rule text checked September 27, 2026Official textBack to text: ↑
9. CFPB, 12 CFR 1033.431, use of a data aggregator; 2024 rule text checked September 27, 2026Official textBack to text: ↑
10. OIRA/Reginfo, Personal Financial Data Rights Reconsideration, RIN 3170-AB39; Unified Agenda entry checked September 27, 2026; timetable is a planning estimateOfficial sourceBack to text: ↑
11. CFPB, all versions of 12 CFR Part 1033; January 17, 2025 listed as current regulation when checked September 27, 2026Official textBack to text: ↑