Data providers such as banks and credit unions could soon be required to have structured application programming interfaces (APIs) for sharing customer data, while the fintechs and platforms that receive that data will have to meet their own standards regarding consent and data use. Together, these requirements are reshaping how financial data moves in the US. They push the industry away from screen scraping and towards permissioned, auditable data connections.

Below, we’ll discuss what Section 1033 entails. We’ll also go over how the open banking regulation splits obligations between data providers and third parties, and what businesses on either side of that relationship need to do to be in compliance.

Key takeaways

• Section 1033 gives customers a legal right to access their financial data and share it with third parties through structured, API-based connections rather than screen scraping.

• Banks, credit unions, fintechs, and data aggregators each carry distinct compliance obligations regarding data access and consent under the final rule.

• Businesses need to audit their current data-sharing methods, consent language, and vendor relationships well ahead of their applicable compliance deadlines.

What is the CFPB’s Section 1033?

Section 1033 is a provision of the Dodd-Frank Act that gives customers a legal right to access their own financial account data and share it with third parties of their choosing. A federal court issued a preliminary injunction that halted the enforcement of Section 1033 in 2025, and the rule is under review.

What consumer financial data rights does Section 1033 establish?

Section 1033 gives customers the right to access several categories of their own financial data and direct that data to a third party without going through their banks’ own interfaces. Here are some of those categories:

• Transaction history and account balances: Deposits, withdrawals, and payments going back at least 24 months

• Terms and conditions (T&Cs): Interest rates, fee schedules, credit limits, and more

• Account identity information: Basic information associated with accounts, such as names, email addresses, and phone numbers

• Bill payment and payment initiation details: Information tied to upcoming payments

Customers generally authorize this data sharing through the third party itself, and they can revoke that authorization at any point. Data providers must make revocation easy.

What are the main requirements for financial institutions and third parties under Section 1033?

The open banking rule enforcing Section 1033 sets different obligations for data providers and third parties. But they all work towards the same goal of enabling data to move through controlled, auditable channels rather than ad hoc work-arounds.

For data providers, the rule requires the following:

• Dedicated interfaces: Data providers have to build and maintain two separate interfaces—one for customers (e.g., a banking portal) and one for authorized third-party developers (e.g., an API).

• No fees: Data providers can’t charge customers or third parties to access covered data.

• Contact information: Data providers must supply certain information to customers and third parties, including contact information for questions about accessing covered data.

For authorized third parties, the obligations work in the other direction:

• Express consent: Third parties need to obtain explicit, specific consent from customers.

• Data use limits: Third parties can use the data only for the purpose the customer authorized.

• Duration limits: Authorization expires after one year, after which it must be renewed.

How does Section 1033 change the open banking environment?

The US has relied on screen scraping for over a decade: a customer hands over their bank login credentials to a third-party app and that app logs in and pulls data straight off the account page. It works, but it’s fragile. Bank site redesigns break it, security teams flag it as suspicious login activity, and the data that comes back is only as good as what happens to be visible on a web page that day.

Section 1033 pushes the whole model towards API-based access instead. Data providers have to expose structured endpoints that return the data fields the rule specifies so third parties stop depending on credential sharing and start depending on permissioned, limited connections. A revoked API permission is a clean cutoff in a way that a scraped login session usually isn’t since the third party never had the actual password to begin with.

What the shift toward API-based access means for data aggregators

Financial data aggregators (i.e., the companies that sit between banks and the fintech apps customers use) feel this change directly. Their businesses have been built on scraping infrastructure across bank sites, and the rule pushes them towards standardized APIs instead, which means less scraper maintenance.

What it means for fintech platforms

Fintech platforms that depend on aggregators for account verification, loan underwriting, or budgeting features will feel this shift even without touching the API layer themselves because the reliability and quality of what they receive changes along with it. Data that often used to arrive inconsistently will now arrive through a defined interface with defined fields. A platform that makes real-time decisions based on that data (e.g., approving a loan, flagging an account for review) needs that consistency as much as the legal requirement behind it.

What do businesses need to do to prepare for Section 1033?

Businesses on both sides of the data-sharing relationship, whether they’re building the interface or consuming data through one, have concrete work to do before their applicable deadlines, which are currently undetermined.

These are some of the steps they must take:

• Map current data-sharing methods: Identify every place the business currently sends or receives customer financial data through screen scraping, credential sharing, or informal API access. Flag which of those relationships fall under the rule’s scope.

• Review consent language: Authorization requests need to state their purpose clearly enough that a customer understands exactly what they’re agreeing to. This means generic “we need access to your account” language won’t hold up.

• Audit data retention practices: Data minimization requirements mean businesses need a real answer to how long they keep customer data and why.

• Evaluate third-party and vendor relationships: Businesses need to understand how their partners handle the data they receive.

• Confirm applicable compliance dates: Businesses must verify their specific timelines against current CFPB guidance. Deadlines are staggered by institution size, and they’ve shifted amid legal challenges.

Which tools can help support Section 1033 compliance?

Businesses don’t need to build API infrastructure or consent management from scratch. A few tool categories cover most of what the rule requires:

• Permissioned data access tools: Connect directly to financial institutions through APIs rather than screen scraping. This returns structured account and transaction data under a customer-authorized connection.

• Consent and authorization management systems: Track what a customer agreed to, when, and for what purpose. This matters given the rule’s requirements regarding plain language disclosure and easy revocation.

• Identity verification tools: Help data providers confirm that a request is coming from an authorized third party and not an impersonator. This is a real risk once account access shifts from a physical branch relationship to an API call.

The right combination depends on which side of the data relationship a business sits on and how much of its existing infrastructure already runs through APIs versus older integration methods. A business that already uses a payment provider for account verification or bank transfers likely has less to rebuild than one that still relies on manual document uploads or scraped login sessions.

How Stripe Financial Connections can help

Stripe Financial Connections is a set of APIs that allows you to securely connect to your customers’ bank accounts and retrieve their financial data, enabling you to build innovative financial products and services.

Financial Connections can help you:

• Simplify onboarding: Offer a seamless, instant bank account verification process that does not require manual identity and account verification.

• Access rich financial data: Retrieve comprehensive information about your customers’ bank accounts, including balances, transactions, and account details.

• Automate recurring payments: Enable your customers to securely link their bank accounts for recurring payments, improving payment success rates.

• Enhance risk management: Analyze customers’ financial data to make more informed decisions about credit, lending, and other financial products.

• Comply with regulations: Financial Connections helps you meet Know Your Customer (KYC) and Anti-Money Laundering (AML) requirements.

• Innovate with confidence: Build new financial products and services on top of the secure, reliable Financial Connections infrastructure.

Learn more about Financial Connections, or get started today.