CFPB 1033 Open Banking Rule: 2027 Compliance Guide

The CFPB's Section 1033 final rule landed in October 2024, and its compliance clock is already ticking. For the largest depository institutions — those holding more than $500 billion in assets — the deadline was April 1, 2026. For everyone else, the stagger runs through April 2030, depending on asset tier. That feels generous until you realise that tokenisation infrastructure, third-party authorisation frameworks, and secondary-use governance policies are not weekend projects.

This post is a practical compliance map. We cover the rule's data-sharing scope, the secondary-use limits that most legal teams are still underestimating, and the token-based authorisation architecture that satisfies the rule without creating new attack surfaces. If you are a compliance officer, CTO, or product lead at a bank, credit union, or fintech, this is the briefing you need before your next board presentation.

What Section 1033 Actually Requires

Section 1033 of the Dodd-Frank Act gave the CFPB authority to require financial institutions to make consumer financial data available to consumers and their authorised third parties. After more than a decade of inaction, the CFPB published its final rule on October 22, 2024, filling 594 pages in the Federal Register. Here is what it mandates at a structural level:

1. Covered data must be made available in a standardised, machine-readable format. Screen scraping is explicitly de-prioritised; the rule encourages — and effectively requires at scale — developer interfaces (APIs).
2. Covered institutions must not charge consumers or authorised third parties for access. Revenue models built on data-access tolls are dead.
3. Third-party access requires explicit, revocable consumer authorisation. Blanket terms-of-service consent does not satisfy this requirement.
4. Authorisation periods are capped at 12 months before re-authorisation is required, regardless of whether the consumer relationship with the third party continues.
5. Institutions must provide a consumer-facing interface for viewing and revoking all active third-party authorisations.

The covered data categories are broader than most institutions modelled in their gap analyses. They include transaction data, account balance and terms, upcoming bill payments, and — critically — information about financial products the consumer holds, including APRs, fee schedules, and reward balances.

The Secondary-Use Limits That Will Catch Teams Off-Guard

The data-scope provisions generate the most compliance chatter, but the secondary-use restrictions are where enforcement risk is actually concentrating. The final rule creates a sharp line between authorised use and prohibited secondary use.

Authorised third parties may use covered data only for the specific product or service the consumer requested. They may not:

• Target the consumer with advertising based on covered data
• Sell the data to any party, including data aggregators and analytics brokers
• Use the data to train models offered as a standalone commercial service
• Retain the data beyond the period necessary to deliver the authorised service

The rule's plain language: "A third party must not use, retain, or disclose covered data for any purpose other than to provide the product or service the consumer requested." — CFPB Final Rule §1033.421(a), October 2024.

This is a material operational constraint. Consider a payroll-advance fintech that also runs a credit-scoring subsidiary. Data collected under a 1033 authorisation for the payroll product cannot flow to the scoring subsidiary — even within the same corporate family — without a separate, product-specific consumer authorisation. The CFPB has signalled in its supplementary commentary that affiliate data sharing under Gramm-Leach-Bliley opt-outs does not satisfy this requirement.

Compliance teams should immediately audit every downstream data flow triggered by a third-party API call. Use a data-flow diagram, not a legal memo, as the audit artefact. The question is not "do we have consent?" but "does our consent cover this specific downstream use?"

The Compliance Tiers and What They Mean in Practice

The rule staggers compliance by institution size, measured in total assets:

• Tier 1 — $500B+: April 1, 2026 (already in effect)
• Tier 2 — $50B–$500B: April 1, 2027
• Tier 3 — $10B–$50B: April 1, 2028
• Tier 4 — $3B–$10B: April 1, 2029
• Tier 5 — Under $3B: April 1, 2030

If you are a Tier 2 institution — a regional bank or large credit union — your compliance window closes in under twelve months from today. The average enterprise API buildout for a core-banking integration runs 14–18 months, according to internal benchmarking from several core-processor vendors. That means Tier 2 institutions that have not broken ground on their developer interface are already behind schedule.

Fintech third parties face a different but equally urgent timeline. The rule applies to data recipients as well as data providers. If you are pulling consumer financial data under a 1033 authorisation, your authorisation management, secondary-use controls, and data-deletion workflows must be operational before your covered institution partners face their own deadline — because they will audit you before they go live.

Tokenisation Architecture: The Technical Core of Compliance

The rule does not mandate a specific technical standard, but it creates requirements that effectively dictate a token-based authorisation architecture. Here is why, and what that looks like in practice.

The 12-month re-authorisation cap means every access grant must be time-bound. Screen-scraping credentials and long-lived OAuth tokens with no expiry fail this requirement. The revocation interface requirement means your system must be able to invalidate a specific third-party's access without affecting any other party — ruling out shared secrets and credential-based approaches.

The architecture that satisfies all three constraints — time-bound, revocable, party-scoped — is a short-lived access token + refresh token pair, issued per third party per consumer, with a centralised revocation registry. In practice:

• Access tokens should have a TTL of 15–60 minutes. They are presented by the third party on each API call.
• Refresh tokens carry the 12-month authorisation window. When a consumer revokes authorisation, the refresh token is invalidated in the registry immediately; the short-lived access token expires naturally within its TTL.
• Scoped claims in the token payload define exactly which data categories the third party is authorised to retrieve. A payroll app authorised for transaction data cannot request reward balances, because that scope claim is absent from its token.
• Consent receipts should be cryptographically linked to the token issuance event, creating an audit trail that demonstrates the authorisation preceded the data access.

For institutions building on top of existing identity infrastructure, FAPI 2.0 (Financial-grade API) is the closest thing to a blessed standard. It layers Demonstrating Proof of Possession (DPoP) on top of OAuth 2.1, binding tokens to the client's cryptographic key material. A stolen token cannot be replayed by an attacker who does not hold the corresponding private key — a meaningful security upgrade over bearer-token architectures.

Data Minimisation at the API Layer

The secondary-use restrictions map directly to a technical requirement: your API must be capable of returning only the data the consumer authorised, not everything the institution holds. This sounds obvious until you examine most core-banking API wrappers, which return full account objects and expect the caller to filter. Under 1033, the filtering must happen server-side, before transmission, not client-side after receipt. Sending excess data and trusting the recipient to discard it is not compliant.

This has architectural implications:

• Response schemas must be dynamically scoped to the token's claims.
• Logging must capture what data was returned, not just what was requested.
• Data-residency rules for the logs themselves become a compliance input, especially for institutions with cross-border operations.

What Third Parties Must Build (And Fast)

If you are a fintech or data aggregator receiving data under 1033 authorisations, your obligations are symmetrical with the data providers'. The rule places the following requirements on authorised third parties:

• Maintain a public-facing policy describing data use, retention, and deletion practices, updated within 30 days of any material change.
• Delete covered data within a reasonable period after the consumer's authorised use concludes or authorisation is revoked — the rule does not specify a number of days, but the CFPB's commentary suggests 30 days as a safe harbour.
• Conduct annual third-party assessments to verify that sub-processors and downstream recipients comply with the secondary-use restrictions.
• Register with a recognised standard-setting body once the CFPB finalises its recognition framework — a process expected to conclude in late 2026 or early 2027.

The third-party registration requirement is worth watching closely. The CFPB has indicated it will recognise one or more industry bodies to maintain registries of compliant data recipients. The Financial Data Exchange (FDX) is the leading candidate, given its existing membership base and API standard. Being on a recognised registry will likely become a de facto prerequisite for institutions to share data with you — making non-registration a business continuity risk, not just a compliance one.

The Competitive Dimension: Why 1033 Is Also a Product Strategy Decision

Compliance framing can obscure the strategic signal. Section 1033, once fully operational, creates the United States equivalent of Europe's PSD2 open-banking regime — but with stronger secondary-use restrictions than the EU's own framework. That is not just a compliance burden; it is a structural change in who controls consumer financial data.

Institutions that build excellent developer interfaces will attract fintech partnerships. Those that build the minimum required — slow, poorly documented, rate-limited APIs — will technically comply while watching their most engaged consumers port their financial lives to apps built on top of competitors' more generous implementations. The Federal Reserve's 2026 Consumer Finance Survey found that 41% of US adults had connected at least one third-party financial app to a bank account — up from 33% in 2023. That number will only rise as 1033 makes connectivity more reliable and more trusted.

The institutions winning on this dimension are treating their 1033 developer interface as a product, not an infrastructure obligation. That means:

• Publishing developer documentation comparable to what Stripe or Plaid ships
• Offering sandbox environments with synthetic data for third-party testing
• Establishing SLA commitments for API uptime that go beyond the rule's minimum requirements
• Building a dedicated developer-relations function, even if it starts as a single hire

For deeper context on how open-banking API design intersects with consumer UX, see our earlier analysis on building financial products with the AtlasForge Financial API and our breakdown of real-time cash-flow intelligence on the platform.

Getting to Compliant: A Practical Checklist

Before your compliance deadline, your organisation needs to have completed or be actively tracking the following:

For covered institutions (data providers):

• Gap analysis against the rule's covered data categories — not just transactions, but product terms, rewards, and upcoming payments
• Developer interface (API) design complete, with FAPI 2.0 or equivalent token architecture
• Consumer authorisation and revocation interface live in online banking
• Third-party onboarding and vetting process documented and operational
• Data-minimisation controls implemented server-side on all covered endpoints
• Staff training completed for customer service teams who will field authorisation questions

For authorised third parties (data recipients):

• Secondary-use policy drafted and published
• Data-deletion workflow tested for all covered data categories
• Sub-processor inventory completed and secondary-use attestations collected
• FDX membership or equivalent standard-setting body registration initiated
• Consent receipt architecture linked to token issuance events
• 12-month re-authorisation prompts built into consumer-facing product flows

For a more detailed look at how data-access infrastructure maps to consumer spending visibility, our post on Safe to Spend 365 and real-time account intelligence covers the product-layer implications in depth.

What Comes Next

The CFPB's 1033 rulemaking is not finished. The agency has indicated that a second rulemaking phase will extend coverage to insurance products, mortgage data, and potentially payroll data — categories excluded from the October 2024 final rule. The recognition-body framework for third-party registries remains in proposed form. And litigation risk is non-zero: several banking trade groups have challenged the rule's scope in federal court, though preliminary injunctions have so far been denied.

The compliance-forward posture is to build to the final rule as written, assume the litigation fails, and architect your systems to accommodate expanded data categories in a future phase. Modular API design — where adding a new covered data category means adding a new endpoint and scope claim, not re-engineering the authorisation layer — is the hedge that costs the least and pays off the most.

AtlasForge Financial's AtlasForge Financial API is built from the ground up with 1033-aligned tokenisation, per-party scope enforcement, and consent-receipt logging. If you are a fintech building on covered data or an institution evaluating third-party API infrastructure, see how the API works in our developer documentation or reach out to our compliance engineering team to walk through your specific architecture. Compliance is a deadline; good infrastructure is a compounding asset.

Further reading

• Open Banking in 2027: UK Maturity vs US CFPB 1033 Reality
• CFPB Rule 1033 Explained: What Changes for US Fintechs in 2027
• Open Banking 2027: US vs EU vs UK Reality Check