Section 1033 compliance is the most operationally consequential financial regulation to land on data providers since PCI-DSS v4. The CFPB finalized the Personal Financial Data Rights rule under Section 1033 of the Dodd-Frank Act, and it does not ask banks, credit unions, and card issuers to update a policy document. It asks them to build and maintain machine-readable infrastructure that puts consumer data access into the hands of consumers and their authorized third parties. For engineering teams, compliance officers, and CISOs at covered institutions, the build is real, the timelines are firm, and the scope is wider than most initial assessments captured.
This article maps what data providers must actually construct, the compliance windows by institution size, and the architectural decisions that will determine whether a 1033 build holds up to CFPB examination.
What Section 1033 Actually Demands from Data Providers
The rule creates a legal right for consumers to access their own financial data in a usable electronic format and to share that data with authorized third parties. Data providers are the institutions that hold that data: depository institutions, credit card issuers, and other entities that hold transaction accounts or issue credit cards covered under the rule's scope.
The CFPB separated the obligations into three structural pillars. First, the developer interface: a machine-readable API that third-party data recipients can connect to programmatically. Second, the authorization and revocation system: a consumer-facing mechanism to grant and withdraw third-party access. Third, the data fields: a defined set of structured data elements that must be returned accurately and completely when a valid request arrives.
What the rule does not do is mandate a single technical standard for the API protocol. The CFPB referenced Financial Data Exchange standard-setting activity as the expected industry pathway, but the final rule leaves implementation protocol to data providers. That flexibility is real but it is not a loophole. A data provider that builds a technically compliant API that returns incomplete fields, degrades for third-party callers, or requires burdensome onboarding for third parties is not meeting the rule's practical access standard.
Compliance Timelines by Institution Size
The CFPB structured compliance dates on an asset-size waterfall. The logic: larger institutions already have API infrastructure, dedicated engineering capacity, and existing data-sharing relationships, so they face earlier mandatory compliance.
The compliance schedule as established in the final rule runs as follows:
- Depository institutions and credit card issuers with assets above $250 billion: compliance required in 2026, placing them in the first mandatory cohort.
- Institutions with assets between $10 billion and $250 billion: compliance required approximately one year after the largest cohort.
- Institutions with assets between $3 billion and $10 billion: an additional year of runway beyond the mid-tier cohort.
- Smaller depository institutions below $3 billion in assets: a longer tail, though the CFPB reserved the right to revisit exemption thresholds.
- Non-depository institutions covered by the rule: timelines align with asset equivalence tiers.
Institutions in the 2026 compliance window that have not begun engineering work on their developer interface are already behind. The build timelines for a compliant API with proper authorization flows, data field mapping, and third-party onboarding infrastructure routinely run 12 to 18 months for institutions starting from a legacy screen-scraping or batch-file baseline.
Building the Developer Interface: Technical Requirements
The developer interface is the API surface that covered data providers must expose to authorized third-party data recipients. The CFPB's requirements for this interface go beyond basic REST endpoint availability.
The interface must be machine-readable and return structured data in a format that a third-party application can consume programmatically. PDF exports, portal logins, and file download links do not satisfy this requirement. The interface must support third-party access without requiring the consumer to share their primary login credentials with the third party, which is the CFPB's core objection to legacy screen-scraping as a data access mechanism.
Performance standards matter here. The anti-evasion provision in the final rule means that a developer interface that responds at 200ms for the institution's own digital products but at 8,000ms for third-party callers is not a compliant developer interface regardless of whether the endpoint technically exists. Institutions will need to architect third-party API traffic with the same SLA discipline applied to consumer-facing services.
Onboarding for third parties must not be unreasonably burdensome. The CFPB flagged excessive onboarding fees, multi-month credentialing delays, and non-standard documentation requirements as the kind of technical and procedural friction that can constitute an anti-competitive barrier. Third-party data recipients that meet the CFPB's definition of an authorized third party must be able to access the developer interface without the data provider using that process as a gate.
Practical build components for the developer interface include: OAuth 2.0 authorization server implementation, token issuance and refresh logic, scoped permission grants tied to specific data clusters, rate limiting that treats third parties equivalently to internal clients, API versioning strategy for the long-term maintenance obligation, and monitoring instrumentation to demonstrate uptime and response-time parity in examination.
Authorization, Consent, and Revocation Infrastructure
The authorization layer is where most compliance teams underestimate the build scope. Section 1033 does not just require that consumers can authorize third-party access. It requires that consumers can see what they authorized, understand the scope of data being shared, and revoke that access through a mechanism the data provider controls and maintains.
This creates a consent management obligation that sits inside the data provider's own systems, not the third party's. Even if a fintech app has its own authorization flow and lets users disconnect the integration from the app side, the data provider must independently maintain a revocation interface where the consumer can terminate third-party access without needing to interact with the third party at all.
The authorization flow must disclose the scope of data being shared, the identity of the third party, and the duration of the authorization. The CFPB aligned with OAuth 2.0 scope parameters as the mechanism for expressing what data a given token can access. That means data providers need a scope taxonomy that maps cleanly to the mandatory data field clusters in the rule: transactions, account terms, balances, upcoming bill data.
Revocation must be immediate and effective. A consumer who revokes access at 9am cannot have their transaction data returned to the previously authorized third party at 9:05am because the token invalidation had a 24-hour propagation lag. Token lifecycle management, including real-time revocation propagation and audit logging of revocation events, is a core compliance control that examiners will test.
Mandatory Data Fields and Structured Formatting
The data field requirements in the final rule define the minimum information set that a compliant developer interface must return. Engineering teams mapping their existing data models to 1033 obligations frequently discover gaps, particularly in transaction categorization and upcoming bill data, two fields that require inference or enrichment logic the bank's core system may not produce natively.
The mandatory data field clusters under the final rule include:
- Transaction information: transaction amount, date, merchant name, merchant category code, transaction type (debit, credit, ACH, wire), and pending versus posted status.
- Account identity information: account number in a form usable for routing, account type, and basic account ownership identifiers.
- Account terms: interest rates, fees, credit limits where applicable, and agreement terms in machine-readable form rather than PDF attachment.
- Account balance information: current balance, available balance, and credit limit for applicable account types.
- Upcoming bill payment data: scheduled payment amounts, due dates, and autopay status where the institution has this data.
Payment initiation, the ability for third parties to actually move funds via the API, was explicitly deferred to a future rulemaking phase. Data providers building toward 1033 compliance should not treat payment initiation as part of the current build scope, though institutions that want to offer it voluntarily are not prohibited from doing so.
Data quality is a compliance obligation, not an engineering aspiration. The CFPB's language requires that returned data be accurate and complete. A developer interface that returns transaction data with merchant names stripped to generic identifiers or that omits pending transactions fails the completeness standard even if the API responds successfully from an uptime perspective.
Third-Party Authorization and Data Minimization Risk
Section 1033 places obligations on authorized third parties as well as data providers, but data providers carry residual risk from the third-party ecosystem they enable. Specifically, data providers must not provide data to third parties who have not met the authorization requirements the rule imposes.
The rule requires that third-party data recipients collect only the data necessary for the specific product or service the consumer requested. This data minimization obligation creates a verification challenge for data providers: they must have reasonable processes for ensuring that the third parties connecting to their developer interface have valid consumer authorization and are requesting only scoped data fields aligned with a disclosed purpose.
This pushes data providers toward third-party credentialing frameworks. Financial Data Exchange's technical standard, which the CFPB referenced throughout the rulemaking, includes a qualified recipient certification process that data providers can use to discharge part of this verification obligation. Institutions building their own bilateral credentialing processes will need documented onboarding criteria, purpose validation at the scope level, and ongoing monitoring for scope creep in API call patterns.
Institutions should also engage legal counsel on the interaction between 1033's authorization framework and existing Gramm-Leach-Bliley Act information-sharing obligations. The CFPB treated the two regimes as complementary rather than conflicting, but the practical question of whether a 1033-authorized data share satisfies GLBA exception requirements requires institution-specific legal analysis rather than a universal answer.
Treating Section 1033 as Infrastructure, Not a Project
The institutions that will struggle most with 1033 examination are those that staffed it as a one-time compliance project with a go-live date and then moved on. The rule creates ongoing obligations. The developer interface must remain performant, the authorization system must remain accurate, the data fields must remain complete, and the third-party onboarding process must remain accessible.
That means 1033 compliance lives in the engineering roadmap permanently. API versioning, data field updates as the CFPB expands scope in future rulemakings, token lifecycle management at scale, and quarterly performance audits against parity benchmarks are operational functions, not implementation milestones.
Compliance officers and engineering leads should build toward a 1033 compliance dashboard that tracks developer interface uptime, response latency parity between internal and third-party callers, active authorization counts and revocation latency, data completeness error rates by field cluster, and third-party onboarding cycle time. These are the metrics that CFPB examiners will ask for and that demonstrate a functioning compliance program rather than a built artifact.
At Own Your Data Inc., our research consistently finds that the institutions best positioned for 1033 compliance treat the developer interface as a core platform product managed by a dedicated API product team, not a compliance checkbox managed by a project manager. The policy framework that drives this regulation is articulated at length in CFPB's official Personal Financial Data Rights rulemaking documentation, and engineering teams benefit from reading the rule's preamble directly rather than relying on vendor summaries. The CFPB's official rulemaking materials provide the authoritative text. Implementation guidance from the Financial Data Exchange covers the technical standard in granular detail.
Section 1033 is the legal foundation for open banking in the United States. The compliance build is not a penalty for holding consumer data. It is the infrastructure layer that makes consumer data rights real. Data providers that build it well will have a durable competitive asset. Those that build it minimally will spend the next decade patching examination findings.