CFPB Section 1033 Open Banking Rule Guide: Data Access and Security Status

The CFPB's Section 1033 rule turns consumer-permissioned data sharing in US banking into a regulated API relationship, but its compliance dates and several of its core choices are under reconsideration. The Personal Financial Data Rights rule, finalised by the Consumer Financial Protection Bureau in October 2024, requires banks, credit unions and card issuers to give consumers and authorised third parties access to account data through a developer interface, and it places purpose, duration and security limits on the fintechs and aggregators that receive it. This guide summarises who is covered, what the rule requires, where its status stands, and what it means for the API tokens, service accounts and AI agents that move the data. It is written for security architects, open banking platform owners and compliance leads at data providers, aggregators and fintechs. Status line: checked against the CFPB and Federal Register on 27 October 2026; the rule is in force on paper but stayed in litigation and subject to a reconsideration rulemaking, so check the official sources before acting. This page is not legal advice.

Key takeaways

• It is an API mandate with a screen-scraping exit. Covered data providers must run a developer interface that delivers standardised, machine-readable data, and allowing third parties to log in with consumer credentials does not satisfy the obligation.
• Third parties carry real duties. Authorised third parties must obtain express informed consent, limit use to what the consumer asked for, re-authorise at least yearly and run an information security programme under the GLBA Safeguards framework.
• The dates have moved and may move again. The final rule set tiered compliance dates from 1 April 2026 to 1 April 2030; a court order in Forcht Bank v. CFPB shifted them by 90 days and the CFPB has said it intends to propose a longer extension.
• Reconsideration targets security and privacy. The August 2025 advance notice asks about who may act as a consumer's representative, fees, data security threats and data privacy threats, so the security model in the 2024 text is not settled.
• Every connection is a non-human identity. Each aggregator and fintech connection runs on OAuth clients, access and refresh tokens and service credentials that need inventory, scoping, rotation and revocation, whatever the final dates turn out to be.

Scope: who and what is covered

The rule implements section 1033 of the Consumer Financial Protection Act of 2010 (Dodd-Frank Act Title X) and lives in 12 CFR part 1033. It was published in the Federal Register on 18 November 2024 (89 FR 90838) with an effective date of 17 January 2025. An earlier partial final rule of 11 June 2024 set the qualities a standard-setting body needs for CFPB recognition, and on 8 January 2025 the CFPB approved Financial Data Exchange, Inc. (FDX) as a recognised standard setter.

Covered data under 1033.211 is: transaction information (24 months of history is deemed sufficient), account balance, payment initiation information such as account and routing numbers (tokenised numbers are permitted), terms and conditions such as fee schedules, APRs and credit limits, upcoming bill information, and basic account verification information (name, address, email, phone and a truncated account identifier). 1033.221 sets limited exceptions to what must be made available.

The rule does not require data providers to initiate payments, and the CFPB declined to build a full liability framework into it, leaving Regulation E and Regulation Z error resolution and private network rules in place. GLBA, Regulation P and the FCRA continue to apply in their own right.

Key obligations

Data providers: the developer interface

• Make data available: provide covered data, in electronic form, to the consumer through a consumer interface and to authorised third parties through a developer interface (1033.201, 1033.301).
• No fees: data providers may not charge consumers or third parties for establishing or using the interfaces (1033.301(c)). Fees are one of the four questions in the reconsideration.
• Standardised format: the developer interface must deliver data in a standardised, machine-readable format; conformance to a consensus standard (such as one issued by a recognised standard setter) is an indicator of compliance (1033.311).
• Performance: the developer interface's proper response rate must be 99.5 percent or higher in each calendar month, excluding scheduled downtime, and responses must arrive within a commercially reasonable time (1033.311(c)).
• Access frequency: any limits on how often third parties may call the interface must not be unreasonable, must be non-discriminatory and must follow written policies (1033.311(d)).
• No credential sharing: letting a third party use consumer credentials to log in (screen scraping) does not meet the developer interface duty. In practice this pushes providers to token-based, OAuth-style authorisation.
• Authentication: for a third-party request the provider must authenticate both the consumer and the third party, confirm the third party followed the authorisation procedure, and identify the scope of data requested (1033.331).
• Risk-management denials: a provider may deny a third party access where granting it would conflict with policies designed to meet safety and soundness or GLBA section 501 information security standards. The denial must be tied to a specific risk and applied consistently; a third party's failure to show adequate information security is a sufficient basis (1033.321).
• Disclosure and records: providers publish interface information and keep written policies and procedures, with record retention requirements (1033.341, 1033.351).

Authorised third parties and aggregators

The security programme duty is the one most security teams will own. If your organisation is a fintech not already in scope of GLBA, the FTC Safeguards Rule becomes the baseline. See the GLBA Safeguards Rule Guide.

Timeline and current status

Compliance tiers as written in 1033.121: the rule text on eCFR still shows the original dates. The ANPR states that a court order stayed those dates by 90 days, making the first date 30 June 2026, and that the CFPB intends to propose a further extension. As at 27 October 2026 we found no proposed or final rule in the Federal Register that changes the dates, so treat any date below as provisional.

The reconsideration asks four questions: who may act as a consumer's "representative" (directly relevant to aggregators and to software acting for a consumer), how fees for consumer-driven requests should be assessed, the data security threats and costs of compliance, and the data privacy threats. Expect any revised rule to revisit the fee ban and possibly the third-party security model.

Enforcement and penalties

Section 1033 is a federal consumer financial law enforced by the CFPB under the Consumer Financial Protection Act, and the CFPB said it will supervise and enforce against third parties brought in through 12 CFR 1001.2(b), coordinating with the FTC and states. Under 12 U.S.C. 5565 a court or the CFPB may order relief including rescission or reformation of contracts, refunds, restitution, disgorgement, damages, public notification and limits on activities, plus civil money penalties. The statutory maximums per day of violation are:

• First tier: up to $5,000 per day for any violation of a law, rule or final order.
• Second tier: up to $25,000 per day for a reckless violation.
• Third tier: up to $1,000,000 per day for a knowing violation.

These are the base amounts in the statute. 12 CFR 1083.1 adjusts them for inflation; for penalties assessed after 15 January 2025 the maximums are $7,217, $36,083 and $1,443,275 per day respectively. While the litigation stay and reconsideration continue, enforcement of the compliance dates is uncertain; the practical exposure for most teams today is supervisory scrutiny of data security, contracts with aggregators, and GLBA or FTC Safeguards Rule enforcement, which applies regardless of section 1033.

What it means for AI agents and non-human identities

The rule never uses the phrase non-human identity, but its whole architecture runs on machine credentials. Moving from screen scraping to a developer interface replaces stored consumer passwords with OAuth clients, access tokens and refresh tokens held by third parties and aggregators. That is a security improvement, and it also creates a large estate of long-lived machine credentials across many organisations.

• Third party authentication is client authentication: 1033.331 requires the provider to authenticate the third party. Strong options are mutual TLS or private key JWT client authentication, as in the FAPI profiles, rather than shared client secrets. See the FAPI 2.0 Security Profile Implementation Guide and the mTLS Guide.
• Authorisation duration maps to token lifetime: the one-year collection limit and revocation duties mean refresh tokens must expire or be revoked at reauthorisation or revocation, and revocation must propagate to aggregators and downstream recipients. See the OAuth Refresh Token Rotation and Expiry Guide and the OAuth Token Introspection and Revocation Guide.
• Scope equals purpose limitation: the scope of data identified at authentication should be enforced as OAuth scopes or fine-grained authorisation details, so a token issued for account verification cannot pull 24 months of transactions.
• Aggregators concentrate tokens: one aggregator may hold tokens for millions of consumers across thousands of providers. Treat aggregator token stores as crown-jewel secrets with hardware-backed keys and strict access.
• AI agents as representatives: the ANPR question about who may act as a consumer's representative will decide whether an AI agent or the company running it can request data for a consumer. Until that is settled, design agent access as delegated, consumer-authorised, scoped and revocable, never using the consumer's credentials. See the Agentic Commerce Identity Guide and the OAuth Token Exchange and Delegation Guide.
• Internal service accounts: the provider's interface itself depends on service accounts that read core banking data. Those accounts sit behind every external call and need least privilege and monitoring.

Compliance steps

1. Establish your role and tier: decide whether you are a data provider, an authorised third party, an aggregator or more than one, and record your tier under 1033.121 or the small depository exclusion in 1033.111(d), with the asset or receipts calculation kept as evidence.
2. Track status monthly: assign an owner to watch the CFPB reconsideration page, the Federal Register and the Forcht Bank docket. Plan to the earliest plausible date but do not commit to fee or representative designs that the reconsideration may change.
3. Inventory current data sharing: list every screen-scraping connection, aggregator agreement, API client and token type in use today. For data providers, include traffic patterns that indicate credential-based access.
4. Design the developer interface: choose a consensus standard (FDX is the recognised standard setter), implement OAuth authorisation with strong client authentication, scopes aligned to covered data categories and published frequency policies.
5. Build availability measurement: instrument the 99.5 percent monthly proper response rate, scheduled downtime exclusions and response times before go-live, and test under load.
6. Write the risk-management denial policy: define the evidence you require of third parties (for example security attestations), the specific risks that justify denial and how you apply them consistently, so denials stand up to the 1033.321 test.
7. Third parties: rebuild consent and lifecycle: implement authorisation disclosures, purpose limits, annual reauthorisation, free revocation and downstream notification, then map each to a token or data lifecycle event.
8. Align the security programme: check the programme against the GLBA Safeguards framework or the FTC Safeguards Rule, including access controls, encryption and incident response, and cover secrets and tokens explicitly.
9. Retire screen scraping in phases: pilot interface access with a few aggregators, monitor parity, then restrict credential-based access with a published notice period and a rollback plan if the interface misses performance targets.

Decision guidance

• Large providers: build to the consensus standard now, because the interface, consent dashboards and monitoring take longer than any likely extension.
• Smaller providers near the threshold: confirm the exclusion calculation and rely on core or digital banking vendors for interface capability, but contract for performance reporting, token revocation and logs.
• Fintechs and aggregators: the security and consent duties are low-regret whatever happens to the dates. Prioritise token protection and revocation propagation over waiting for the final text.

Detection, measurement and framework mapping

Monitor the developer interface as a critical external API: client identities, token issuance and refresh volumes per client, failed client authentication, scope requests outside the authorised set, unusual pull volumes per consumer, and residual credential-based logins from aggregator IP ranges.

• Proper response rate: monthly, against the 99.5 percent floor.
• Active authorisations past 12 months without reauthorisation: target zero.
• Revocation propagation time: from consumer revocation to token invalidation at the provider and aggregator.
• Share of third-party traffic via the developer interface: versus screen scraping.
• Third-party clients using secret-based authentication: trending to zero in favour of mTLS or private key JWT.

Common failure patterns

• Treating the stay as a cancellation: the rule remains in the CFR; teams that stop work lose the long lead time the interface needs.
• Refresh tokens that never die: one-year authorisation on paper, but tokens that keep working because revocation and expiry were not wired into the token service.
• Revocation that stops at the provider: the consumer revokes in the bank app but the aggregator and downstream fintech keep cached data and active tokens.
• Shared client secrets for third parties: static secrets emailed during onboarding, never rotated, and reused across environments.
• Inconsistent denials: blocking a competitor's aggregator on vague security grounds while allowing others, which fails the specific-risk and consistency test.

Practitioner checklist

• Role, tier and exclusion analysis documented with the asset or receipts figures used.
• Named owner tracking the reconsideration, Forcht Bank litigation and Federal Register monthly.
• Inventory of all third-party data connections, aggregators, OAuth clients and token types.
• Developer interface design mapped to a consensus standard and to the covered data categories.
• Third-party client authentication by mTLS or private key JWT, not shared secrets.
• Token lifetimes tied to the one-year authorisation and to revocation, with downstream notification.
• 99.5 percent monthly response rate measured and reported.
• Written, consistently applied risk-management denial criteria.
• Security programme checked against GLBA Safeguards or the FTC Safeguards Rule, covering tokens and secrets.
• Phased screen-scraping retirement plan with rollback.

Standards and references

• Federal Register: Required Rulemaking on Personal Financial Data Rights (final rule)
• eCFR: 12 CFR Part 1033 Personal Financial Data Rights
• Federal Register: Personal Financial Data Rights Reconsideration (ANPR)
• CFPB: Personal Financial Data Rights Reconsideration
• CFPB: Personal Financial Data Rights
• Federal Register: Personal Financial Data Rights, Industry Standard-Setting
• CFPB: Approval of Financial Data Exchange as a standard setter
• eCFR: 12 CFR Part 1083 Civil Penalty Inflation Adjustments
• US Code: 12 U.S.C. 5565 Relief available

Related NHI Mgmt Group resources: Financial Services Cyber Regulation Map · GLBA Safeguards Rule Guide · FAPI 2.0 Security Profile Implementation Guide · API Keys vs OAuth Tokens Guide. This guide summarises the CFPB Personal Financial Data Rights rule and its status as at 27 October 2026 and is not legal advice.