- Section 1033 of Dodd-Frank gives consumers the right to access and share their financial data. The CFPB’s implementing rule, finalized in October 2024, is currently stayed pending litigation and active agency reconsideration, but the underlying statutory obligation has never gone away.
- The rule divides entities into two camps: data providers (banks, credit unions, card issuers, payment app operators) who must make data available, and authorized third parties (fintechs, aggregators, apps) who may access it under strict use-limitation and security rules.
- Even with the rule stayed, compliance timelines already triggered for the largest institutions, and the CFPB has signaled it will reissue a revised rule. Companies that treat this as dead are reading the situation wrong.
- The practical work for fintechs is not waiting on the CFPB. It is aligning now with the Financial Data Exchange (FDX) API standard, auditing third-party data use agreements, and selecting aggregators that are building 1033-conforming access.
- This guide maps obligations by entity type, shows what the timeline looks like given current legal status, and names the vendors doing the compliance-enabling infrastructure work.
Section 1033 compliance covers any US entity that holds or accesses consumer financial data. Data providers, primarily banks and card issuers above $850 million in assets, face the earliest mandatory deadlines once a final rule takes effect. Authorized third parties, including fintechs and aggregators, must comply with data-use limitations and security requirements regardless of which side of the transaction they sit on. The CFPB’s October 2024 rule is stayed and under reconsideration as of mid-2025, but the statutory right established by Dodd-Frank is active law. Building for 1033 now, using FDX-aligned APIs and written data access agreements, is the correct posture.
What Is Section 1033, and Why Does It Apply to Fintechs Too?
Section 1033 of the Dodd-Frank Wall Street Reform and Consumer Protection Act, codified at 12 U.S.C. 5533, requires “covered persons” to make available to consumers, on request, the data held on their financial accounts. That includes transaction history, account balances, upcoming bills, and other information in electronic, usable form. Congress passed it to end the era of banks treating customer data as a proprietary asset the bank could hold hostage.
Most fintech operators read that and assume the obligation falls entirely on the banks. That reading is incomplete. The CFPB’s implementing rule creates a parallel obligation for authorized third parties, the fintechs, apps, and aggregators that receive consumer data through data provider interfaces. Those third parties must limit data use to what is reasonably necessary to provide the consumer’s requested product or service. They cannot sell the data. They cannot use it for targeted advertising. They must maintain written data access agreements and meet baseline security standards. A personal finance app, a payroll platform using bank verification, or an embedded lending product that ingests transaction data is an authorized third party under this framework.
The statutory obligation also reaches payment app operators. A company running a consumer-facing payment or money-transfer product is likely a data provider under the rule, not just a recipient. If your product holds account balance information or transaction records for consumers, you are probably in the provider column, not the recipient column, and the two carry different obligations. Getting that categorization wrong is one of the most common early-stage compliance mistakes in fintech, a pattern covered in more detail in our breakdown of compliance mistakes that can destroy fintech startups.
What Is the Current Legal Status of the CFPB 1033 Rule?
The CFPB finalized the Personal Financial Data Rights rule in October 2024. Within weeks, a federal court stayed the rule in response to litigation brought by banking industry trade groups. As of mid-2025, the rule remains stayed, and the CFPB has publicly indicated it intends to initiate a reconsideration process, which may result in a revised or narrowed final rule.
A stay is not a repeal. The underlying statutory text in Dodd-Frank is untouched. The CFPB retains the authority and, under the statute, the obligation to issue a rule. Industry participants who treat the stay as a signal to stand down are making a bet on the reconsideration producing a dramatically weaker rule, or on Congress acting to eliminate the rulemaking authority entirely. Neither outcome is a reasonable base case.
The more useful framing: the stay creates time, not an exit. Companies that use that time to build FDX-aligned interfaces, audit their data use practices, and negotiate proper third-party data access agreements will have substantially less work to do when a revised rule takes effect. Companies that wait will face compressed timelines with no runway.
Who Does the CFPB 1033 Rule Apply To? Obligations by Entity Type
The rule draws a bright line between data providers and authorized third parties. Where a company falls determines what it must build, what it must document, and when it must comply.
| Entity Type | Examples | Primary Obligation Under 1033 | Compliance Category |
|---|---|---|---|
| Depository institutions (large) | Banks and credit unions with assets above $850 million | Provide developer-accessible interfaces (APIs); allow consumer-permissioned data access; no fees to consumers or third parties for data transfer | Data Provider, Tier 1 |
| Depository institutions (mid-size) | Banks and credit unions with assets $77 million to $850 million | Same interface and access obligations, later compliance date | Data Provider, Tier 2 |
| Depository institutions (small) | Institutions below $77 million in assets | Exempt from developer interface requirement under the current rule framework | Data Provider, Exempt |
| Credit card issuers | Any card issuer regardless of size | Must provide card account data through developer interfaces | Data Provider |
| Payment app and wallet operators | Consumer-facing digital wallets, P2P payment apps, prepaid account issuers | Must make consumer payment and balance data available; treated as data providers | Data Provider |
| Fintechs accessing consumer data | PFM apps, budgeting tools, lending platforms, expense management, payroll verification tools | Must be authorized third parties with written agreements; limited to data necessary for the specific product; cannot sell data or use for targeted ads | Authorized Third Party |
| Data aggregators | Plaid, MX, Finicity, Akoya | Operate as both authorized third parties (accessing provider data) and, in some configurations, as data providers themselves; must maintain security standards | Aggregator, dual-role |
The payment app and wallet category catches many fintech founders off guard. If your product is the place a consumer’s money lives, even temporarily, you are likely a data provider. That means you must build or maintain a developer interface, not just consume one.
What Are the Section 1033 Compliance Deadlines?
The October 2024 final rule established a tiered compliance schedule based on asset size. Because the rule is currently stayed, these dates are not yet enforceable. They remain the reference point for when obligations would take effect once a final rule, whether the current one or a revised version, becomes effective.
| Entity Group | Asset / Size Threshold | Original Compliance Date in Final Rule | Current Status |
|---|---|---|---|
| Depository institutions, Tier 1 | Assets above $850 million | April 1, 2026 | Stayed. Clock paused pending litigation outcome or revised rule. |
| Depository institutions, Tier 2 | Assets $77 million to $850 million | April 1, 2027 | Stayed. |
| Depository institutions, small | Below $77 million | Exempt from developer interface requirement | No date set. |
| Credit card issuers, large | Credit card plans with more than 1 million open accounts | April 1, 2026 | Stayed. |
| Credit card issuers, smaller | Fewer than 1 million open accounts | April 1, 2027 | Stayed. |
| Authorized third parties | All, regardless of size | Effective at rule effective date | Stayed. Obligations apply from day one of any revised effective date. |
Under the rule’s text, authorized third parties carry no grace period. The CFPB’s final rule at 12 C.F.R. § 1033 specifies that data-use limitations and security requirements for authorized third parties take effect on the same date the rule becomes operative, there is no phase-in for the recipient side of the transaction. A fintech that has not audited its data agreements and vendor contracts before that date will be out of compliance from day one.
What Specific Data Must Data Providers Make Accessible?
The rule specifies the categories of covered data that must be made available through developer interfaces. Understanding the scope matters because building an interface that covers only some categories is not compliant.
- Account balance information, including current balances and available credit
- Transaction information, including pending transactions and transaction history
- Upcoming bill payment information, where the data provider holds it
- Basic account verification information (account and routing numbers, account type)
- Terms and conditions of the account
- Information about the consumer’s identity as held by the provider
The rule explicitly does not require providers to share proprietary data, data derived through their own analysis, or information not directly related to the covered account. That carve-out matters for institutions that have built credit scoring or behavioral models on top of raw transaction data. The model output is not covered. The underlying transaction data is.
On the interface side, the rule prohibits providers from requiring screen-scraping as the primary access method. Providers must offer a developer interface, meaning a proper API. Screen scraping is not banned outright, but it cannot be the method a provider gates third parties to. That distinction is why the FDX API standard, the industry-developed open standard already in use across hundreds of financial institutions, has become the de facto technical baseline for 1033 compliance work.
The FintechSpecs 1033 Readiness Audit: Four Checks Before You Build
Before engaging any vendor or starting API development, companies benefit from running what we call the FintechSpecs 1033 Readiness Audit: a four-check framework that surfaces the actual compliance gaps before anyone writes a line of code. It applies whether you are a data provider building an interface or an authorized third party building on top of one.
Check 1: Entity Classification
Determine with legal counsel whether your product is a data provider, an authorized third party, or both. Payment app operators frequently discover they sit in the provider column despite thinking of themselves as pure software companies. The classification drives everything else.
Check 2: Data Inventory
Map every consumer financial data point your product holds, accesses, or passes to a third party. For each data type, confirm whether it falls within covered data categories under the rule and identify who holds the primary provider relationship for that data. Gaps in this inventory become compliance gaps under the data minimization and use-limitation requirements.
Check 3: Agreement Audit
Pull every data access agreement, terms-of-service clause, and vendor contract that touches consumer financial data. Under the rule, authorized third parties must have written data access agreements with data providers before accessing data. If you are consuming aggregator APIs, the agreement must flow through properly. Verbal understanding and legacy API keys without formal agreements do not satisfy this requirement.
Check 4: Secondary Use Review
For every data set your product receives, document the stated product or service the consumer requested and verify that your actual data use does not exceed what is reasonably necessary for that purpose. This is where fintechs most commonly fail the standard. Using bank-verified income data to underwrite a loan is within scope. Passing that same data to a third party for audience segmentation or re-marketing is not, the rule’s use-limitation provisions prohibit repurposing consumer financial data for any purpose beyond the specific product or service the consumer authorized, regardless of what a broad terms-of-service might say. Regulators have been clear that general consent language does not substitute for purpose-specific authorization.
What Do Authorized Third Parties Specifically Need to Do?
The rule places substantive obligations on authorized third parties, not just obligations to hold a written agreement. The requirement framework runs deeper than most fintech legal teams have absorbed.
Permissioned access only. Third parties may only access data after obtaining consumer authorization. That authorization must be informed, specific to the product or service the consumer is requesting, and revocable. Blanket consent buried in a terms-of-service is not authorization under the rule.
Data use limitation. According to the CFPB’s rule text, third parties are limited to using data that is “reasonably necessary to provide the consumer’s requested product or service.” The rule explicitly bans using consumer financial data for targeted advertising, selling data to third parties, or cross-using data across unrelated products without fresh authorization.
No fees. The rule prohibits data providers from charging consumers or third parties fees to access or transfer data. Conversely, authorized third parties cannot condition data access on consumers paying fees.
Security standards. The rule requires third parties to maintain written policies and procedures for information security that meet a standard consistent with the size and complexity of the third party and the sensitivity of the data accessed. There is no prescriptive checklist in the rule. In practice, SOC 2 Type II certification is the operational baseline most providers and aggregators are requiring in their access agreements.
Annual re-authorization. Consumer authorization does not run indefinitely. Third parties must re-obtain consumer authorization at least annually, and must honor consumer requests to revoke access.
If your product is built on an aggregator like Plaid, MX, or Finicity (now part of Mastercard), the aggregator’s infrastructure handles parts of the data provider relationship, but your data-use obligations as the authorized third party sit with you, not the aggregator. The aggregator cannot absorb your use-limitation liability. That is the single most important clarification for fintechs currently outsourcing their “open banking compliance” entirely to their data infrastructure provider.
For a deeper comparison of how these aggregators differ in their API architecture and 1033 readiness posture, see our breakdown of Plaid, MX, and Finicity as open banking API options.
Which Vendors Help With Section 1033 Compliance?
The vendor field for 1033 compliance work breaks into three distinct categories: data aggregators providing 1033-conforming access infrastructure, compliance automation platforms helping document and audit the obligations, and API standardization infrastructure supporting FDX conformance. These are different problems requiring different tools.
Data Aggregators Building 1033-Conforming Access
Plaid has publicly committed to FDX API support and operates a developer interface product that positions as 1033-aligned. Its core business is connecting fintechs to financial institution data, which makes it both an authorized third party itself and the infrastructure layer for thousands of other authorized third parties. Plaid’s data access agreements cover the contractual layer, but your product’s data-use practices remain your own obligation.
MX markets 1033 compliance readiness as a direct product feature. Its platform includes data access management tools designed around the consumer-permissioning model the rule requires. MX has participated actively in FDX standards development. It tends to be stronger for financial institutions building consumer-facing data portability into their own products, as opposed to pure third-party access use cases.
Finicity, now operating under Mastercard’s open banking brand, provides FDX-aligned bank data access and has existing relationships with a large number of US financial institutions. Its data connectivity is particularly strong for mortgage and lending verification use cases where income and employment verification through bank data is the primary need.
Akoya is a bank-consortium-backed aggregator that positions explicitly on 1033 compliance, operating as what it describes as a permissioned data network designed to replace screen-scraping entirely. Its institutional backers include many of the largest US banks, which gives it direct API relationships that smaller aggregators access through screen scraping. Akoya’s model aligns closely with the kind of developer interface access the rule contemplates.
Stripe Financial Connections operates in this space for Stripe-adjacent companies. It provides direct bank data access for account verification and balance checks. Its 1033 positioning is narrower than the full-service aggregators, focused on the verification use case rather than the broad transaction data access that PFM or lending underwriting products require. For a detailed look at how Stripe Financial Connections compares to Plaid specifically, our side-by-side analysis covers the tradeoffs for each use case.
Compliance Automation Platforms
TrustArc, Osano, and OneTrust provide consent management and data governance infrastructure that maps to 1033’s authorization and data-use documentation requirements. None of them are 1033-specific products, but their consent audit trails, data flow mapping, and vendor agreement management capabilities address real gaps in the authorized third party obligation set. OneTrust has published specific guidance on financial services data rights that aligns with the 1033 framework.
Ncontracts and similar bank compliance automation platforms serve the data provider side, helping financial institutions document interface performance, manage third-party access agreements, and maintain audit trails. For fintech products operating as payment app providers in the data provider column, these tools handle the operational compliance workflow that the rule requires institutions to maintain.
For compliance automation tools that span the broader fintech regulatory stack, including 1033, BSA/AML, and consumer protection obligations, the FintechSpecs list of compliance automation tools for US fintech startups covers the category in detail.
FDX API Infrastructure and Certification
The Financial Data Exchange (FDX) organization maintains the open API standard that the CFPB pointed to as the model for developer interface requirements in the 1033 rulemaking. FDX membership gives financial institutions and fintechs access to the standard specifications, testing tools, and certification resources. Membership is not a compliance checkbox in itself, but building to FDX API specifications is the closest the market has to a technical safe harbor for the developer interface requirement.
Apiture and Fiserv provide FDX-conforming open banking infrastructure to financial institutions, particularly community banks and credit unions that lack internal engineering capacity to build compliant developer interfaces. For fintechs partnering with smaller institutions, the question of whether that institution has FDX-conforming infrastructure is a practical due diligence item, not just a regulatory one. If your data provider partner is still serving data through screen scraping, your access is both operationally fragile and potentially non-conforming once the rule takes effect.
What Does 1033 Mean for Fintechs That Use Banking-as-a-Service Partners?
BaaS arrangements add a layer of complexity to the 1033 entity mapping. When a fintech operates a consumer-facing product through a sponsor bank and BaaS middleware, the consumer’s account is legally held at the bank, but the fintech controls the product experience and often holds the data. The sponsor bank is the data provider. The fintech may be an authorized third party under the data provider’s interface, or it may be the entity the consumer interacts with in a way that makes it functionally responsible for the interface even though the bank holds the underlying account.
The CFPB has not issued specific guidance letters or enforcement actions addressing BaaS-specific entity classification under 1033, it remains an open interpretive question under the current rule framework. The practical answer, until guidance arrives, is to draft your BaaS contract to specify explicitly which entity bears 1033 data provider obligations and how the developer interface is operated and maintained. If your BaaS partner cannot answer that question, it is a gap in their compliance posture. The broader dynamics here connect to the compliance and structural pressures covered in the state of BaaS in 2026, where regulatory scrutiny of sponsor bank arrangements has made these contract terms increasingly consequential.
Frequently Asked Questions About Section 1033 Compliance
What is Section 1033 of Dodd-Frank?
Section 1033 of the Dodd-Frank Act, codified at 12 U.S.C. 5533, gives consumers the right to access and share their financial data held by financial institutions and other covered persons. It requires covered entities to make that data available in electronic, usable form on consumer request. The CFPB issued an implementing rule in October 2024 that translates this statutory right into specific technical and operational requirements for data providers and authorized third parties. That rule is currently stayed pending litigation.
Is the CFPB 1033 rule dead because of the court stay?
No. The stay suspends enforceability of the implementing rule while litigation proceeds, but it does not repeal the underlying statutory authority in Dodd-Frank. The CFPB has signaled it will issue a revised rule. The consumer data access right established by Congress in 2010 has never been eliminated. Companies building financial products should treat the stay as a delay in the compliance clock, not as a signal to stop preparing.
Do fintechs have to comply with 1033, or is it just for banks?
Both. Banks and other financial institutions are data providers with interface-building obligations. Fintechs that access consumer financial data through those interfaces are authorized third parties with their own compliance obligations under the rule. Those third-party obligations include data-use limitations, written access agreements, security requirements, and annual consumer re-authorization. A fintech that collects bank data to power its product and assumes the bank bears all 1033 responsibility is misreading the rule.
What is the FDX API and why does it matter for 1033?
The Financial Data Exchange (FDX) API is an open standard for consumer-permissioned financial data sharing developed by a consortium of financial institutions, fintechs, and aggregators. The CFPB’s 1033 implementing rule pointed to FDX-style developer interfaces as the model for what data providers must build. While FDX conformance is not explicitly mandated in the rule text, building to FDX specifications is the closest the industry has to a technical baseline for the developer interface requirement. Most major aggregators, including Plaid, MX, and Akoya, support FDX API access.
What data use is prohibited for authorized third parties under Section 1033?
The CFPB’s rule prohibits authorized third parties from using consumer financial data for purposes beyond what is reasonably necessary for the specific product or service the consumer requested. Explicit prohibitions include selling consumer data to third parties, using data for targeted advertising, and reusing data across unrelated products without fresh consumer authorization. These restrictions apply even if the consumer technically consented to broad data use in a terms-of-service agreement. The required authorization must be specific and informed, not buried in boilerplate.
What happens if a data provider still uses screen scraping after the rule takes effect?
Under the 1033 rule, screen scraping cannot be the primary or exclusive method through which data providers grant third parties access to covered data. Data providers must offer a developer interface, meaning a proper API. The rule does not ban consumers from using screen-scraping-based tools, but it does require providers to offer an API alternative. Providers who respond to third-party access requests solely by allowing screen scraping would not satisfy the developer interface requirement once the rule is in effect.
Can data aggregators handle 1033 compliance on behalf of fintechs?
Aggregators can handle significant portions of the data provider access obligation, particularly the technical interface and connection infrastructure. What they cannot do is absorb the authorized third party obligations that sit with the fintech itself. Data-use limitations, consumer authorization practices, written agreement requirements, and security standards for the fintech’s own systems remain the fintech’s responsibility. Using Plaid, MX, or any other aggregator does not transfer those obligations to the aggregator.
What should a fintech do right now, given the rule is stayed?
Use the stay productively. Run the entity classification exercise to confirm whether your product is a data provider, an authorized third party, or both. Audit all existing data access agreements for language that aligns with the written agreement requirement. Map every consumer data flow and document the product or service purpose for each data type you collect or use. Select aggregator partners that are FDX-aligned. When a revised rule takes effect, authorized third party obligations apply immediately with no grace period. The companies that have done this work will spend the rule-effective day confirming compliance, not scrambling to build it.
The 1033 Misconception That Will Cost Fintechs the Most
The widespread belief that Section 1033 is a bank problem, or that court litigation has made it irrelevant, is producing a specific and predictable failure mode. Fintechs are deprioritizing agreement audits, skipping data-use documentation, and selecting aggregator partners without asking about FDX conformance. When a revised rule drops, those companies will discover they are authorized third parties with zero compliant agreements, zero documented consumer authorization practices, and vendors who cannot answer questions about their own interface standards.
The authorized third party obligation set is not technically demanding. Written agreements, use-limitation documentation, and annual re-authorization workflows are operational tasks, not engineering marathons. What makes them hard is that they require decisions about how your product actually uses data, not just how it claims to. Fintechs that have not examined secondary data use honestly, and the share that have is smaller than most compliance teams would admit, will find the use-limitation audit genuinely disruptive to how their data sharing arrangements are currently structured.
The right posture is neither panic nor complacency. The statutory right is real, the rulemaking will produce an enforceable rule, and the core obligations for third parties are known well enough to act on now. Entity classification, agreement audit, data inventory, secondary use review: those four steps constitute the entire pre-rule compliance runway a fintech needs. The companies that run them before the revised rule takes effect will find 1033 manageable. The companies that do not will find it expensive.
