What Section 1033 Actually Is
The Consumer Financial Protection Bureau's final rule implementing Section 1033 of the Dodd-Frank Wall Street Reform and Consumer Protection Act is the closest the United States has come to a codified open banking mandate. The rule, finalized in late 2024 and now operative in 2026, gives consumers a legally enforceable right to access their own financial data in a usable form and to authorize third parties to access that data on their behalf.
The CFPB's authority comes from Section 1033 of Dodd-Frank, which states that covered persons must make available to consumers upon request data in the consumer's account or data associated with a product or service the consumer obtained from that covered person. The Bureau spent years developing the implementing rule, issuing a proposed rule in 2023 before finalizing its approach. The result is a regulation that is narrower than some advocates wanted and more demanding than some banks anticipated.
For engineers and compliance officers, the practical question is not what Congress intended in 2010 when Dodd-Frank passed. The question is what the final rule requires them to build, maintain and certify right now.
Who Counts as a Covered Data Provider
The rule applies to any entity that is a covered person under the CFPB's jurisdiction and that holds or controls covered data about a consumer who requests access. In practice, this means depository institutions offering checking accounts, savings accounts and credit cards fall squarely within scope. Non-bank payment platforms that hold consumer account balances are also covered. Mortgage servicers and student loan servicers fall into scope to varying degrees depending on how the CFPB applies its covered product definitions.
The rule does not apply to investment accounts held at broker-dealers registered with the SEC, nor does it reach data held purely by data aggregators who are themselves the downstream recipients. Data aggregators appear in the rule as third-party data recipients, subject to authorization and data use constraints, not as covered data providers with the affirmative disclosure obligation.
For a bank operating a digital platform, this distinction matters. The bank must provide the data. The fintech application accessing the data on a consumer's authorization must comply with the data use limitations the rule imposes on recipients. The two compliance obligations run parallel but are not identical.
Technical Requirements: APIs, Formats and Developer Portals
The CFPB rule does not name a specific API specification, but it is explicit that covered data providers cannot satisfy their obligation by providing PDFs, portal logins or screen-scraping tolerant interfaces. The data must be machine-readable and accessible through a developer-facing interface that third parties can programmatically consume.
In the US market, the Financial Data Exchange, commonly abbreviated FDX, has produced the dominant API specification that institutions are building toward. The FDX API is a REST-based, OAuth 2.0 authenticated interface with defined schemas for account data, transaction data and payment initiation permissioning. It is not mandated by name in the CFPB rule, but it is the standard that trade groups, large banks and fintech aggregators have converged on as satisfying the rule's technical intent.
The rule's technical obligations include:
- Providing a developer portal with publicly accessible documentation of supported endpoints, data schemas and authentication requirements.
- Maintaining API performance standards, specifically that the interface must respond at performance levels that are not materially worse than the covered data provider's own proprietary interface for the same data.
- Providing data in standardized formats, not institution-specific proprietary schemas that third parties cannot parse without custom integration work.
- Implementing token-based access so that consumer authorization can be granted and revoked without exposing primary account credentials.
The performance parity requirement is operationally significant. A bank cannot satisfy the rule by exposing a technically compliant API that throttles at 10 requests per minute while its own mobile application pulls the same data in real time. The rule explicitly prohibits designing the required interface in a way that unreasonably degrades access quality relative to the institution's own channels.
OAuth 2.0 with PKCE is the authentication baseline that FDX specifies, with token scopes mapped to specific data categories. A consumer authorizing a personal finance management application can grant read access to transaction history without granting access to account credentials or payment initiation capability. Scope granularity is not optional. It is the mechanism through which the rule's data minimization intent is operationalized.
Consumer Authorization Flows and Third-Party Access
The authorization framework in Section 1033 is the part that most directly affects product and engineering teams at both covered data providers and third-party applications. The rule requires that consumer authorization be explicit, informed and revocable.
Explicit authorization means a consumer must affirmatively consent to a third party accessing their data. Pre-checked boxes do not satisfy this standard. The authorization must identify which categories of data the third party will access, the purpose for which the data will be used and the duration of the authorization.
The rule limits authorization duration. Third parties cannot obtain indefinite standing authorization. The rule caps standard authorization periods and requires re-authorization after that period expires. This has direct implications for fintech applications that currently hold long-lived aggregator tokens. Those applications will need to build re-authorization UX flows and token refresh infrastructure that surfaces consent renewal to consumers at defined intervals.
Revocation must be possible at the covered data provider's interface, not only through the third-party application. This means banks must build authorization management dashboards where consumers can see all active third-party data access grants and revoke them individually. The third-party application cannot be the sole point of revocation control because it creates an obvious conflict of interest where the app has no incentive to make revocation easy.
From a data architecture perspective, covered data providers need a persistent authorization registry that maps consumer identifiers to active third-party tokens, records the scope of each authorization, enforces expiration logic and propagates revocation in near-real-time. That registry is not a trivial infrastructure component. It needs to be durable, auditable and capable of producing access logs that satisfy both the CFPB's requirements and the institution's own SOC 2 Type II and ISO 27001 audit obligations.
How This Compares to PSD2
European engineers and compliance officers who have worked under PSD2 and its associated Regulatory Technical Standards will find Section 1033 familiar in intent but different in structure. The comparison is worth working through in detail because institutions operating in both markets need to understand where their technical investments transfer and where they need parallel implementations.
PSD2 mandated a specific regulatory framework for two categories of third-party provider: Account Information Service Providers and Payment Initiation Service Providers. Those categories have defined licensing requirements under national competent authorities, defined liability rules for unauthorized transactions and defined API performance standards set by the European Banking Authority. The RTS on Strong Customer Authentication established specific technical requirements for multi-factor authentication in the authorization flow.
Section 1033 does not create a licensing regime for third-party data recipients. There is no US equivalent of the AISP or PISP authorization that a fintech must obtain before accessing consumer bank data. The rule instead imposes data use limitations on third parties and authorizes covered data providers to block access from third parties who do not agree to those limitations or who pose a credible security or privacy risk. The practical effect is that covered data providers must build their own third-party onboarding and vetting process, which is a compliance function PSD2 outsources to regulators.
On payment initiation, Section 1033 is explicitly not a payment rule. It covers data access. Payment initiation liability in the US remains governed by Regulation E and the Uniform Commercial Code. PSD2 Article 73 creates a direct liability path for unauthorized payments initiated by a compromised PISP. That pathway does not exist under Section 1033, which is a meaningful gap for consumers whose data is accessed by a third party that then initiates an unauthorized payment.
Strong customer authentication under PSD2's RTS requires at least two factors from the categories of knowledge, possession and inherence for account access and payment initiation. Section 1033 does not prescribe authentication factors at that level of specificity. It requires secure authentication but defers to existing bank security standards and the OAuth framework for implementation detail. Institutions that have already implemented PSD2-compliant SCA can leverage that infrastructure for Section 1033 authorization flows, but they should not assume the two regimes are technically equivalent.
Liability Gaps and What Engineers Must Understand
The liability architecture of Section 1033 is the area where the rule's limitations are most visible. PSD2 created explicit liability assignment rules. Section 1033 largely does not.
Consumers retain their existing Regulation E protections for unauthorized electronic fund transfers. They retain their rights under the Fair Credit Reporting Act for data that constitutes a consumer report. But Section 1033 does not create a new cause of action for consumers whose data is misused by an authorized third party after a valid authorization flow. If a consumer authorizes a budgeting app and that app later monetizes transaction data in ways that exceed the scope of the authorization, the consumer's remedies are under state privacy law, the FTC Act or contractual claims, not Section 1033 directly.
For engineers building third-party data pipelines, this means the risk surface is asymmetric. The covered data provider faces regulatory sanction for failure to provide the required interface. The third-party recipient faces data use limitation requirements, but enforcement against third parties for downstream misuse is less clearly defined in the rule itself.
Data retention limits are part of the rule's attempt to constrain third-party risk. Third parties may not retain covered data beyond what is necessary to provide the authorized service. They cannot use consumer financial data for secondary commercial purposes outside the authorized use case. The rule aligns with broader data minimization principles articulated in frameworks like NIST SP 800-53 and ISO 27701, but it does not prescribe specific retention periods in days or months. Institutions and their legal teams must operationalize data minimization into specific retention schedules that they can defend in examination.
Building Compliant Data Infrastructure
For a depository institution building toward Section 1033 compliance in 2026, the engineering work falls into three layers. Each layer has distinct ownership and distinct failure modes.
The first layer is the data availability layer. This is the internal pipeline that assembles covered data from core banking systems, card processors and loan servicing platforms into a unified, normalized representation. Many legacy banks hold transaction data across multiple systems of record that were never designed to produce a unified consumer-facing view. Building this layer requires data engineering investment that is entirely separate from the API surface the rule requires. Without a reliable internal data assembly pipeline, the API will be incomplete regardless of how well the interface itself is built.
The second layer is the authorization and access control layer. This encompasses the OAuth 2.0 authorization server, the token issuance and revocation infrastructure, the scope enforcement logic and the consumer-facing authorization management interface. This layer must be auditable. Every token issuance, every scope grant, every revocation and every data access event must be logged with enough granularity to support regulatory examination and consumer dispute resolution.
The third layer is the developer portal and third-party onboarding layer. The rule requires that covered data providers make documentation publicly available. That requirement is not satisfied by an internal API used only by pre-approved partners. The developer portal must be accessible without prior relationship, include complete schema documentation and provide sandbox access for integration testing.
Institutions that are building open banking infrastructure should review the CFPB's published examination procedures for Section 1033, the FDX API specification at fdx.org and NIST's guidelines on OAuth 2.0 security best practices documented in NIST SP 800-63. Cross-referencing the rule's technical requirements against the FDX conformance test suite is the most practical path to building a defensible compliance posture.
For a deeper look at how consumer data authorization models connect to broader data ownership frameworks, the team at Own Your Data Inc. has published foundational analysis on consent-based data sharing architectures. Implementation patterns for tokenized data access are available at mydatakey.org, which tracks how consumer-controlled key infrastructure can be applied to financial data contexts.
Section 1033 is not a theoretical policy document. It is an operational requirement with tiered deadlines, examination authority and the potential for enforcement action against institutions that fail to build compliant interfaces. The engineering work is substantial. The compliance timeline is active. The institutions that treat this as a data infrastructure project, not just a legal compliance checkbox, will be better positioned to meet both the letter and the operational intent of the rule.