CFPB Section 1033 is the foundational rule that turns US open banking from a policy aspiration into a compliance obligation. After more than a decade of voluntary data-sharing arrangements held together by screen scraping and bilateral agreements, the Consumer Financial Protection Bureau finalized its rule under Section 1033 of the Dodd-Frank Act, establishing enforceable rights for consumers to access and share their own financial data. For engineers, compliance officers and data architects at covered institutions, the rule is not abstract. It specifies data types, authorization mechanics, interface requirements and third-party accountability in enough detail that existing data infrastructure may need substantial redesign. This breakdown covers what the rule actually demands, where the US framework diverges from the European PSD2 model, and what engineering teams need to prioritize heading into the 2026 compliance window.
What Section 1033 Actually Requires
The core obligation in the final rule is straightforward: covered data providers must make a defined set of consumer financial data available, upon consumer authorization, to the consumer and to authorized third parties through a developer interface. That interface must be accessible without requiring the consumer to share their login credentials with a third party.
The data scope the rule covers includes transaction data, account balance information, upcoming bill information, basic account terms and conditions, and information about the financial institution's products held by the consumer. The rule does not require institutions to expose internal models, credit scoring logic or proprietary underwriting data. The boundary matters because some early implementation discussions conflated open banking with open everything.
The prohibition on credential-based access is the mechanism that effectively kills screen scraping as a long-term data access model. Institutions that previously tolerated or facilitated screen scraping to avoid building developer interfaces lose that option under the rule. Third parties that currently aggregate data through credential harvesting must migrate to the authorized interface pathway. The CFPB has been explicit that a developer interface must be provided and that performance standards apply to that interface, not just its existence.
Performance standards in the rule are functionally framed: the interface must be available with the same availability and response time that the institution provides to its own consumer-facing products. If your mobile app serves transaction history in under 500 milliseconds with 99.9 percent uptime, your developer interface must meet comparable benchmarks. Institutions cannot build a technically compliant but deliberately degraded API to discourage third-party access.
Covered Data Providers and Compliance Thresholds
The final rule applies a tiered compliance timeline based on asset size and market position. The CFPB structured the phasing to prioritize the largest institutions, which already have the infrastructure capacity to build compliant interfaces, while giving smaller covered entities more time.
Depository institutions with more than 850 billion dollars in total assets and non-depository covered entities with more than 10 billion dollars in annual receipts face the earliest compliance deadlines, with the first tier required to be in compliance by April 2026. Subsequent tiers extend to smaller institutions on a schedule that runs through 2030 for the smallest covered depository institutions.
Credit unions are explicitly covered if they meet the asset thresholds. Prepaid card issuers, digital wallet providers and certain non-bank entities that hold or process covered financial data are also within scope depending on the nature of the product and the consumer relationship. Institutions below the smallest defined threshold are not currently required to comply, though the CFPB reserved the right to extend coverage through future rulemaking.
For compliance officers at mid-size regional banks and credit unions, the tiering means the 2026 window applies to tier one institutions but internal readiness assessments cannot wait for a later deadline to arrive. Vendor contracting, API design and authorization infrastructure take 12 to 24 months to build and test properly.
API Standards and the FDX Question
One of the most consequential architectural decisions in the CFPB's rule is what it chose not to do: prescribe a single mandatory API technical standard. The European PSD2 model required regulated institutions to implement interfaces conforming to technical standards issued by the European Banking Authority, creating regulatory technical standards that defined OAuth 2.0 flows, consent object schemas and error response formats in detail. The US rule takes a different path.
The CFPB designates recognized standard-setting bodies as the source of API technical standards and requires covered institutions to implement interfaces that conform to the output of a qualified standard setter. The Financial Data Exchange, known as FDX, is the most prominent candidate for that recognition and has already published the FDX API specification, which is built on OAuth 2.0, RESTful architecture and a defined financial data schema.
The FDX API specification as of the current version supports GET-based data retrieval across account types including bank accounts, investment accounts and insurance products. It defines consent receipt objects, data cluster permissions and revocation endpoints. Institutions building to the FDX standard today are building toward likely compliance, but the CFPB's standard-setter recognition process has not yet formally concluded, which creates residual uncertainty for institutions that want to lock in implementation choices now.
The practical risk of the market-driven standard approach is fragmentation. Under PSD2, a fintech connecting to 200 European banks encounters the same OAuth flows and consent schema at each one. Under the US framework, if multiple standard setters achieve recognition or if institutions implement FDX with material variations, third-party developers and data aggregators face a patchwork of interfaces that increases integration cost and reduces the consumer data portability the rule was designed to deliver.
Engineers building developer interfaces should track the FDX API specification versions actively, implement version negotiation in their APIs, and design schema validation layers that can accommodate minor variations without breaking third-party integrations. The Financial Data Exchange publishes its specification and certification requirements publicly. Institutions building toward compliance should also review NIST SP 800-53 security controls for API gateway design, particularly AC-3 access enforcement and SC-8 transmission confidentiality, which apply to any regulated data interface handling consumer financial information.
Consumer Authorization Flows and Token Architecture
The authorization mechanics in the rule are where implementation complexity concentrates. The rule requires that consumer authorization be obtained without credential sharing, that the authorization be scoped to specific data clusters, that the consumer can revoke authorization at any time through the data provider's interface, and that authorization windows cannot exceed 12 months without re-consent.
OAuth 2.0 with PKCE (Proof Key for Code Exchange) is the dominant implementation pattern for the redirect-based consent flow the rule implies. The data provider acts as the authorization server. The third party, called a data recipient in the rule's language, acts as the client. The consumer authenticates to the data provider directly, grants permission to a defined scope of data clusters, and the data provider issues a scoped access token to the data recipient.
Token architecture has to reflect the data cluster model. The rule defines data clusters including account information, transaction information and upcoming bill information as distinct scopes. Access tokens should encode cluster-level permissions, and the data provider's resource server must enforce those permissions on every API call. Issuing a broad token that grants access beyond the authorized clusters creates both a regulatory violation and a consumer trust failure.
The 12-month re-consent requirement creates a session management challenge that is different from standard OAuth token lifecycle management. Even if refresh tokens remain technically valid, the rule requires data providers to enforce the 12-month authorization window and prompt re-consent before continuing data access. Institutions need to build consent expiry tracking that is decoupled from token expiry and that triggers revocation when authorization windows close regardless of token validity.
Revocation must be accessible through the data provider's consumer-facing interface, not only through the third party's settings. A consumer should be able to log into their bank's app and see a list of all active third-party authorizations, the data clusters each authorization covers, the date the authorization was granted, and a revocation control for each one. This is a consent management UI and data model requirement, not just an API requirement. For guidance on how data ownership principles map to these consent models, the frameworks published by Own Your Data Inc. provide a useful conceptual foundation for compliance teams designing consumer-facing authorization interfaces.
Liability Shifts Compared to PSD2
The liability framework under the US rule differs meaningfully from PSD2 and represents one of the most significant areas of ongoing industry debate. Under PSD2, the liability structure is relatively clear: account servicing payment service providers and payment initiation service providers have defined liability for unauthorized transactions based on who holds the strong customer authentication burden at the moment of the transaction.
The CFPB's rule does not directly address payment initiation. Section 1033 governs data access, not payment execution. Liability for data breaches or unauthorized data access after a consumer has authorized a third-party data recipient shifts toward the data recipient once the data is delivered through the compliant interface. Data providers retain liability for breaches that occur within their own systems or interface layer, but the rule establishes that data providers are not liable for what authorized third parties do with data after it is lawfully accessed.
This is a meaningful departure from the legal uncertainty that has characterized aggregator relationships under the existing voluntary framework, where institutions sometimes argued residual liability for downstream data misuse even when they had no role in how the data was handled after delivery. The rule's liability allocation gives institutions cleaner legal boundaries but also means consumers' primary recourse for third-party data misuse shifts to the third party and to whatever consumer protection frameworks apply to that entity.
Data recipients that are not currently subject to CFPB supervision gain a new compliance exposure under the rule's third-party accountability provisions. The CFPB has made clear it views authorized third parties as having obligations under Section 1033 even if they are not themselves covered data providers.
Third-Party Obligations and Data Minimization
The rule imposes data minimization requirements on authorized third parties. Data recipients can only collect, use and retain data that is reasonably necessary to provide the product or service the consumer requested. They cannot retain data beyond what the service requires, cannot use consumer financial data for unrelated secondary purposes without separate authorization, and cannot sell or transfer data in ways that exceed the scope of the original consumer consent.
This is a direct regulatory constraint on the behavioral advertising and data brokerage models that some fintech data aggregators have relied on as secondary revenue streams. A budgeting app authorized to access a consumer's transaction data cannot sell that transaction data to a data broker or use it to build marketing profiles unrelated to budgeting without additional and explicit consumer consent.
For compliance officers at data aggregation platforms, the data minimization obligation requires a full audit of what data is collected through API access, what it is used for, how long it is retained and whether any downstream data flows constitute prohibited secondary use. The CFPB has signaled that it views the secondary use prohibition as a substantive enforcement priority, not a technical footnote.
Implementation of data minimization at the technical layer means API clients should request only the specific data clusters needed for the consumer-facing service, and platforms should implement data isolation that prevents transaction data accessed under a banking authorization from flowing into data pipelines used for unrelated product development. The MyDataKey implementation framework addresses practical patterns for scoped data access and retention policy enforcement that align with the rule's minimization requirements.
Implementation Priorities for Engineering Teams
For engineering teams at tier one and tier two covered institutions, the 2026 compliance window requires prioritization across several parallel workstreams.
The first priority is developer interface readiness. Institutions that lack a production-grade REST API exposing the defined data clusters need to build one. The interface must meet the performance parity standard, handle OAuth 2.0 authorization flows natively and support token introspection for scope validation on every request. API gateway selection should account for rate limiting, consumer-level access logging and anomaly detection, all of which are required for both compliance documentation and for meeting the CFPB's performance monitoring expectations.
The second priority is consent management infrastructure. This is not a feature that can be bolted onto an existing account management system at low cost. Consent records need to be durable, auditable, timestamped at the cluster level, linked to the specific third-party identity, and queryable in real time for revocation enforcement. Consent state changes must propagate to the API authorization server within a time window that prevents unauthorized access after revocation. This requires event-driven architecture between the consent management layer and the token issuance layer.
The third priority is third-party onboarding and vetting. The rule requires data providers to have a process for verifying that entities accessing the developer interface are legitimate authorized third parties and not credential-stuffing bots or fraudulent actors impersonating registered fintechs. Directory services, potentially operated through a recognized standard setter like FDX, are one mechanism. Dynamic client registration under RFC 7591 is another. Institutions need a defined onboarding process before they open their interface to external traffic.
Security controls should be aligned with PCI-DSS v4 requirements for API-level data transmission security, and with NIST SP 800-53 Revision 5 controls for access management and audit logging. SOC 2 Type II coverage should be extended to include the developer interface as an in-scope system component before the compliance deadline arrives.
CFPB Section 1033 is the most consequential structural change to US consumer financial data infrastructure in the post-Dodd-Frank era. The engineering work it requires is substantial, the compliance timeline is real, and the consumer data rights it codifies reflect a durable shift in how financial institutions must think about who owns the data relationship. Getting the architecture right in 2026 matters not just for compliance, but for the competitive position that open banking infrastructure will determine in the decade ahead.