CFPB Section 1033 — U.S. open banking rule

CFPB 1033 (Section 1033 of the Dodd-Frank Act, operationalized by the CFPB's Personal Financial Data Rights Rule finalized October 2024) is the U.S. open-banking rule. It requires financial institutions to make consumers' financial data available to them and to third parties they authorize, through developer interfaces, without charging for access.

This page covers what 1033 requires, its complicated timeline status, what it means for fintechs and banks, and how evidence infrastructure supports 1033-era compliance.

What Section 1033 requires

The final rule establishes that covered financial institutions must:

• Make consumers' transaction, account, and authorization data available on request, in a machine-readable format.
• Support developer interfaces (APIs) for authorized third parties — no screen scraping, no credential sharing.
• Authenticate requests through standards-based mechanisms (FAPI, OAuth 2.0 profiles).
• Not charge consumers or authorized third parties for access to the covered data.
• Maintain data-accuracy obligations and support revocation of third-party access by consumers.
• Participate in a supervised industry standard-setting body for technical interoperability.

The complicated status

The final 1033 rule was published in the Federal Register in October 2024. Implementation was tiered by institution size, with compliance dates staged between 2026 and 2030.

Subsequent legal challenges have resulted in stays and remands affecting specific provisions and timelines. Industry groups, large financial institutions, data aggregators, and fintechs have filed competing briefs. The specific enforceable requirements and dates are in active flux — verify the current regulatory posture at the CFPB and through counsel before making architectural decisions tied to specific deadlines.

What is durable: the direction of travel toward standards-based open banking in the U.S. is set. Even if specific 1033 provisions shift, the underlying market and technical pattern — consumer-authorized data sharing via developer APIs rather than screen scraping — is where the industry is going. Architecturally, the right answer is to prepare for it.

Who 1033 applies to

The rule targets "data providers": entities that hold covered consumer financial data. This includes:

• Banks and credit unions offering deposit accounts
• Card issuers (credit cards, charge cards)
• Digital wallet providers
• Certain other consumer financial services (the rule defines specific product scope)

It also creates obligations for "authorized third parties" — typically fintechs and data recipients — around data use, retention, and consumer consent.

What this means for fintechs

Fintechs accessing consumer banking data have operated through aggregators (Plaid, Finicity, MX) that built their own consumer-consent flows and data access patterns. 1033 formalizes much of that pattern in regulation:

• Direct API access replaces screen scraping — the aggregator business model shifts from "build the pipe" to "normalize and enrich the standardized pipe."
• Consent management becomes central — fintechs need auditable records of consumer consent, its scope, and its revocation.
• Data-use obligations formalize — the purposes for which you can use consumer financial data are constrained by the scope of the consent you collected.
• FCRA obligations when data is used for credit — using open-banking data to inform credit decisions triggers separate FCRA compliance obligations.

What this means for banks

For banks and credit unions subject to 1033 as data providers:

• Build or buy standards-compliant developer interfaces (FAPI-aligned APIs supporting the required data categories).
• Operate consumer consent flows that meet the rule's requirements around clarity, granularity, and revocability.
• Maintain audit trails of every data disclosure request and every consumer authorization — individually tied to the authorized third party.
• Plan for concentration-risk management across authorized third parties.

The core compliance-evidence pattern is the same as for other regulated workflows: structured, timestamped, queryable records that demonstrate the consent framework operated as designed.

Evidence infrastructure for 1033

1033-era compliance rests heavily on evidence: which consumer authorized what access, to whom, for what purpose, when, and whether/when they revoked it. The data-provider side must produce this as evidence on demand; the third-party side must demonstrate compliance with consent scope.

Specific artifacts:

• Consent records per consumer per third-party per data category per time range
• Access logs showing which authorized third party accessed what data on what date
• Revocation records and the downstream enforcement actions they triggered
• Data-retention enforcement records (when were records purged, under what rule)
• Breach and incident records where consumer-authorized data was involved

How FinQub supports 1033 compliance

FinQub's orchestration across banking data aggregators (Plaid, Finicity, MX) and its unified audit trail provide evidence infrastructure relevant to 1033 in three ways:

• Consent tracking — every data-access request tagged with the consumer consent record that authorized it.
• Access audit — every aggregator call logged with timestamp, data category, and consent reference to the hash-chained audit trail.
• Revocation enforcement — when a consent is revoked, FinQub stops routing requests to aggregators on that consent. The enforcement action is logged.

FinQub does not make 1033 compliance determinations. Whether a specific consent framework meets 1033 requirements remains the responsibility of the data provider or third party, their legal counsel, and their regulators. What FinQub provides is the evidence infrastructure required to demonstrate compliance as the regulatory environment stabilizes.

Practical next steps

1. Track the current CFPB 1033 regulatory posture closely — specific dates and requirements remain in flux.
2. Regardless of 1033's exact implementation timeline, prepare for standards-based open banking: FAPI-aligned APIs, structured consumer consent, auditable data-use records.
3. For fintechs using aggregators: formalize consent records and access logs at the orchestration layer rather than per-aggregator.
4. For banks and credit unions: evaluate build-vs-buy for developer interfaces; the build cost is significant and the compliance burden is ongoing.