Open Banking in the US: What Section 1033 and the CFPB Final Rule Mean for Banks and Fintechs

Key Takeaways

• The CFPB finalized its Section 1033 personal financial data rights rule in October 2024 and set a phased compliance timeline running from April 2026 through April 2030. The largest institutions hit their first compliance milestone in April 2026. The smallest in-scope institutions reach theirs in April 2030. Institutions below the asset threshold are exempt.
• The rule mandates that covered institutions make consumer-authorized financial data available through a developer interface, replaces screen scraping with API access, sets standards for consent and data security, and prohibits data holders from charging fees to consumers or authorized third parties for compliant access. The specific data scope covers transactions, account balances, terms, and bill-payment information for the covered account types.
• The comparison to PSD2 in Europe is useful but imperfect. PSD2 mandated APIs through banking regulators with a single technical standard converging through Berlin Group and Open Banking UK. Section 1033 mandates APIs through a consumer-protection agency with technical standards delegated to qualified industry standard-setting bodies (currently Financial Data Exchange). The US path produces more variation and slower convergence.
• The rule changes the operating shape for three constituencies. Large banks must build and maintain compliant developer interfaces at their cost. Mid-tier banks face a build-versus-buy decision under tight timelines. Fintechs and data aggregators lose the screen-scraping crutch but gain standardized data access with consent at scale.
• The political environment around the rule has been turbulent. Industry litigation and political shifts have produced uncertainty about whether the rule will survive in its current form. Institutions should plan to the published timeline while modeling sensitivity to potential rule changes. Treating the rule as either certain or doomed is the wrong posture.

The Decade-Long Arc of US Open Banking

For most of the past decade the US open-banking story was a non-story. Europe shipped PSD2 in 2018 with mandatory bank APIs and a regulatory technical standard. The UK shipped its Open Banking initiative the same year with a more prescriptive standard and a central directory. Australia, Brazil, and India built versions of the same pattern. The US response was that the market would handle it through the data aggregator ecosystem.

That market response produced a working system through screen scraping, with Plaid, MX, and Yodlee at the center. The user provided their bank credentials to the aggregator, the aggregator logged in as the user and scraped the data, and the fintech application consumed it. The pattern worked but carried three costs. It put bank credentials in third-party hands at scale. It produced an adversarial relationship between banks (who saw scraping as unauthorized) and aggregators (who saw banks as obstructing consumer rights). And it produced a data quality story that was uneven because the scraping logic broke whenever a bank changed its login flow.

The Dodd-Frank Act of 2010 contained Section 1033, which gave consumers a right to access their financial data. The provision sat dormant for over a decade because the CFPB never wrote implementing rules. The 2023 proposed rule, the 2024 final rule, and the 2026 first-wave compliance deadline are the long-deferred implementation of a statute that has been on the books since the Obama administration.

The interesting framing is that the US is arriving at open banking eight years after Europe through a different regulatory route. The shape of the implementation reflects that route. The CFPB is a consumer-protection agency rather than a banking regulator, which means the rule is anchored in consumer rights rather than in interbank technical standards. That distinction shapes everything downstream.

What Section 1033 Actually Mandates

The final rule (12 CFR Part 1033) applies to data providers covering deposit accounts, credit cards, payment accounts, and a defined set of related products. It requires data providers to do four things.

Make data available through a developer interface. Data providers must offer a machine-readable interface (commonly an API) that authorized third parties can use to retrieve consumer-authorized data. The interface must meet performance, availability, and security standards specified in the rule and in standards published by recognized standard-setting bodies.

Cover a defined data scope. Account identification and balance information, transaction history (the rule sets a 24-month minimum lookback for transactions, with detailed requirements for the data elements per transaction), terms and conditions, bill-payment information for the covered account types, and certain rewards and upcoming-bill information. The rule defines what must be provided in detail and what may be excluded.

Sunset screen scraping for covered data. Once a data provider has a compliant developer interface available, third parties must use it rather than screen scraping for the covered data. The rule provides exceptions for non-covered data and during specified transition windows, but the direction is clear: the long-run state is API access only.

Set rules around consent and authorization. The third party requesting data must obtain affirmative consumer consent, must use the data only for the purposes consented to, must enable revocation, and must reauthorize annually. The rule prohibits secondary use of the data for purposes unrelated to the consumer's request and requires deletion when authorization ends.

The rule also addresses fees: data providers cannot charge consumers or compliant third parties for the access mandated by the rule. This is the provision that the banking industry pushed back on most vocally during the rulemaking, because it locks the cost of API infrastructure on the data provider side.

The Compliance Timeline

The CFPB phased compliance by institution size. The published dates are:

The thresholds are defined by asset size for depository institutions and by receivables for credit-card issuers. The largest institutions are now past their compliance date. Anecdotal industry reports show uneven readiness: some large banks went live with compliant interfaces well ahead of the deadline using existing partnerships with the Financial Data Exchange, others crossed the deadline with interfaces still in private beta, and a handful are working under enforcement-discretion arrangements while remediation continues.

The interesting question for mid-tier banks is not whether the deadline applies. It is whether the rule will survive in its current form long enough to require the build. The political environment has been turbulent, with industry litigation challenging the rule and political shifts producing public commentary on whether the rule should be reconsidered. The posture that fits the uncertainty is to build to the published timeline while structuring the implementation so that a rule change does not strand the investment. That mostly means using widely-adopted standards (FDX) rather than CFPB-bespoke choices, so the interface remains useful even if the regulatory rationale changes.

How Section 1033 Compares to PSD2

The European Payment Services Directive 2 (PSD2) is the most-cited reference point for what open banking can look like. The comparison is useful but imperfect.

Two differences shape the operating story.

First, payment initiation. PSD2 mandated that banks expose APIs for both account information and payment initiation, which is what enabled the European A2A (account-to-account) payment ecosystem to grow. Section 1033 covers account data but not payment initiation in its initial scope. The CFPB has indicated that payment-related rules may follow but has not committed to a timeline. The US A2A payment story therefore depends more on FedNow, the RTP network, and private rails than on Section 1033 directly. The dynamics around FedNow and US real-time payments adoption are the right backdrop for that question.

Second, technical standards. PSD2 produced regional convergence through Berlin Group in continental Europe, STET in France, and Open Banking UK. Section 1033 explicitly delegates technical standards to qualified industry standard-setting bodies. Financial Data Exchange has been the dominant body and is widely treated as the de facto US standard, but the CFPB framework permits multiple qualified bodies in principle. The result is a more market-driven standard with less central coordination, which means slower convergence and more variation in the early years.

These differences make the US path neither better nor worse than Europe's. They make it different in ways that affect every implementation choice. The broader global payment rail story reflects the same theme: US payments infrastructure converges through markets rather than through mandates.

What Changes for Three Constituencies

Large Banks

The largest banks face the build at their own cost on the published timeline. The first-wave deadline has already passed. The work splits into three programs.

The API platform. A compliant developer interface meeting FDX specifications, with the performance, availability, and security requirements the rule mandates. Most large banks already had API platforms supporting aggregator partnerships; the rule formalized and standardized them.

The consent and authorization layer. A consumer-facing flow that meets the consent requirements (affirmative, revocable, time-bound, purpose-limited) and integrates with the bank's identity stack. This is often the harder build because it touches retail digital channels and customer-service workflows.

The data scope and quality work. The rule's data-scope requirements push banks to expose fields that historically lived in different systems with different quality profiles. Reconciling those systems behind a single uniform API has been a multi-year project for several institutions.

The interesting strategic question for large banks is whether to lean into the rule and build differentiated developer-experience products on top of the mandated interface, or to comply minimally and treat the API as a regulatory cost. Banks that lean in (Citi, JPMorgan, Capital One) are positioning to be preferred data providers in the aggregator routing decisions. Banks that comply minimally accept that they will be a commodity API in the aggregator catalog.

Mid-Tier Banks

Mid-tier banks face the rule on the 2027-2028 timeline with smaller engineering budgets and less existing API infrastructure. The decision is build, buy, or partner.

Build. Custom development on the bank's existing channels stack. The highest-cost option and the slowest, but the option that preserves the most control.

Buy. Implementation through a core-banking vendor or fintech-infrastructure vendor that has already built a compliant interface. Akoya, MX, Fiserv, Jack Henry, and several others are pitching turnkey 1033 solutions. The faster path and the lower upfront cost, but with vendor lock-in and shared infrastructure.

Partner. Joint development with peer institutions through shared utilities. This pattern has emerged in specific community-banking segments but has not yet scaled broadly.

For most mid-tier banks the buy path is the default because the engineering capacity to build does not exist and the published timeline does not allow for a multi-year build. The trade-off is that the bank's customer data flows through a third-party platform, which raises the same vendor-risk questions that BaaS and fintech partnerships raise more broadly.

Fintechs and Data Aggregators

For fintechs and aggregators the rule is mostly good news. Standardized API access replaces brittle screen-scraping logic. Consent flows are formalized. The legal ambiguity around accessing data without explicit bank authorization clarifies.

The trade-offs are three. The transition window between screen scraping and API access requires running both pipes in parallel, which adds engineering and operating cost. The consent and reauthorization requirements impose operational discipline that some products have not previously needed. And the data-aggregator role becomes more commoditized as APIs converge, which puts pressure on margins.

The strategic question for fintechs is which side of the value chain they sit on once the data flow is standardized. The pure aggregation business becomes a thinner-margin utility. The product layers built on top of the data (lending decisioning, account-opening, embedded finance, personalized financial management) capture more of the value. The broader API economy framing applies: the company that owns the interface to the consumer captures the rent, the company that owns the pipe runs at utility margins.

The Screen-Scraping Sunset

The rule does not ban screen scraping outright. It requires that once a data provider has a compliant developer interface, third parties must use it for the covered data. Screen scraping persists for non-covered data and during specified transition windows.

The practical effect is that screen scraping will fade across covered data over the compliance phase-in. The dynamic will be uneven. Large banks with mature developer interfaces will see scraping drop quickly as aggregators migrate to the API. Mid-tier and smaller banks will see scraping persist longer because their interfaces will go live later. The full transition will not complete until well into the 2030s for the long tail of small institutions.

The risk for fintechs is that the parallel-pipe phase produces a long period of higher engineering cost. Each bank moves to API on its own schedule. The aggregator must support both pipes for years. The cost is real and the value of the API endpoint to the aggregator is not always commensurate with the cost of building and maintaining it.

A Decision Framework by Entity Type

The framework reduces to four questions, answered by entity type.

Question one: Is the institution in scope, and on which deadline? Asset size or receivables determine the answer. Below the lowest threshold the institution is exempt and can defer the build indefinitely. Above the highest threshold the deadline has already passed and the conversation is about quality and enforcement risk.

Question two: Build, buy, or partner? Large institutions build. Mid-tier institutions almost always buy. Small in-scope institutions buy through the core-banking vendor or accept enforcement risk.

Question three: Differentiate or comply? A compliant API is the floor. A differentiated developer experience on top is the strategic option. The choice depends on whether the institution sees consumer-authorized data flow as a defensive cost or a competitive surface.

Question four: How exposed is the implementation to rule changes? Building to widely-adopted standards (FDX) reduces exposure to a rule reconsideration. Building to CFPB-bespoke specifications increases exposure. The hedging move is to stay close to the industry standard regardless of regulatory direction.

What This Means for the Open-Banking Stack in 2026

Section 1033 finally gives the US an open-banking framework. The phased timeline means the system will roll out over the next four years rather than at once. The political environment introduces uncertainty about whether the framework will hold in its current form. The right operating posture is to build to the published timeline while preserving optionality, anchor implementations on widely-adopted standards, and treat the API as a strategic surface rather than a compliance cost.

For banks the executive question is whether the institution is treating Section 1033 as the floor or as the start of a customer-data product strategy. For fintechs and aggregators the executive question is which layer of the value chain the business sits on once aggregation commoditizes. The decisions made over the next four years will shape the US financial-data landscape for the rest of the decade.

FAQ

What is Section 1033?

Section 1033 of the Dodd-Frank Act gives consumers a right to access their personal financial data held by covered institutions. The CFPB's October 2024 final rule implements this right through requirements that data providers offer a developer interface, follow consent rules, and replace screen scraping with API access for the covered data scope.

When does Section 1033 take effect?

The rule has a phased compliance timeline. The largest covered institutions had a compliance deadline of April 1, 2026. Tier-two institutions reach their deadline on April 1, 2027, with three additional tiers reaching their deadlines through April 1, 2030. Institutions below the lowest asset threshold are exempt.

How is Section 1033 different from PSD2 in Europe?

PSD2 was issued by a banking regulatory body and mandated APIs for both account data and payment initiation under a defined regulatory technical standard. Section 1033 was issued by a consumer-protection agency, covers account data but not payment initiation in its initial scope, and delegates technical standards to qualified industry bodies (currently Financial Data Exchange). The US path produces more variation across institutions and slower technical convergence.

Does Section 1033 ban screen scraping?

Not outright. The rule requires third parties to use a compliant developer interface once one is available for the covered data. Screen scraping persists for non-covered data and during transition windows. In practice screen scraping for covered data will fade as compliance phases in through 2030, with the long tail of small institutions persisting into the 2030s.

What should mid-tier banks do about Section 1033?

The 2027 and 2028 deadlines do not leave time for a multi-year custom build for most mid-tier banks. The default path is to buy a compliant implementation through a core-banking vendor or fintech-infrastructure vendor (Akoya, MX, Fiserv, Jack Henry have all positioned products). The build path is open to mid-tier banks with mature engineering organizations that see the data flow as a competitive surface rather than a compliance cost.

Related reading on FinTekCafe

• What Is FedNow? The US Real-Time Payments Rail
• Real-Time Cross-Border Payments: SWIFT, Wise, Ripple in 2026
• How Fintech Partnerships Actually Work: Banks, BaaS, and Distribution
• Banking as a Service: How Fintech Companies Become Banks Overnight
• Embedded Finance Explained: Why Every Company Wants to Be a Bank
• The API Economy: How Billion-Dollar Businesses Are Built on APIs