CFPB Rule 1033 Explained: What Changes for US Fintechs in 2027
The CFPB finalized Rule 1033 in October 2024. By 2027 every major US bank must expose free, real-time open-banking APIs. If you're a fintech founder, this rule will define the next decade of your industry.
What Rule 1033 actually mandates
The CFPB's Personal Financial Data Rights Rule (§1033) requires any US depository institution (banks, credit unions) with over $850M in assets to:
- Provide free, real-time access to a customer's transaction data via a standardized API
- Allow the customer to authorize any registered third party to access that data
- Allow revocation at any time
- Comply with a mandatory data standard (in practice, FDX)
For consumers, this means their bank data is theirs, portable across any app that supports the standard.
For fintechs, this means screen-scraping goes obsolete and the aggregator relationship becomes a commodity.
The phased timeline
| Compliance date | Applies to | Notes |
|---|---|---|
| April 1, 2026 | Largest banks (>$250B assets) | Chase, BofA, Wells, Citi, US Bank, PNC |
| April 1, 2027 | Banks $10B–$250B | ~50 mid-tier banks |
| April 1, 2028 | Banks $850M–$10B | ~1,500 community banks & credit unions |
| N/A | Under $850M | Not required (but many will voluntarily comply) |
What data must be exposed
At minimum, the API must return:
- Account balances
- Transaction history (24 months)
- Recurring payment schedules
- Terms of the account
- Consumer's basic identity info
Not included by default: investment holdings, loan collateral details, credit line utilization. Some banks may include these voluntarily.
The FDX standard
The rule doesn't mandate FDX explicitly, but the CFPB's implementation guide points to FDX as the reference standard. In practice, every major bank is building against FDX.
FDX v6.0 (released 2024) includes:
- OAuth 2.0 with PKCE for authorization
- REST/JSON payload structure
- Standardized entity schemas (Account, Transaction, Customer)
- Consent management endpoints (list, revoke)
- Notification API for consent changes
If you're building a fintech in 2026, familiarize yourself with FDX now. It will be the wire protocol for US open banking.
What changes for fintechs
1. Aggregator relationships shift.
Today: you pay Plaid $500–5,000/month to screen-scrape 10,000+ banks. Tomorrow: those banks expose direct APIs, and the aggregator's value is normalization + tail coverage.
Practical impact: aggregator pricing will decline 20–40% over 2027–2028. Some large fintechs will negotiate direct API access with banks and skip aggregators entirely (Robinhood already does this with Chase).
2. Data quality improves.
Screen-scraping mis-categorizes ~5–10% of transactions. Standardized APIs will have <1% miscategorization. Products that depend on accurate transaction data (Safe to Spend, cash-flow forecasting, credit underwriting) get materially better.
3. Latency drops.
Screen-scraping = 2–15 second refresh. Direct APIs = <500ms. Real-time features become the norm, not a premium tier.
4. Consent becomes an active problem.
Users can revoke access anytime. Your app must handle graceful degradation — an account disappearing mid-session isn't hypothetical anymore.
What could go wrong
Bank foot-dragging. Some banks will comply minimally. Expect incomplete implementations, missing endpoints, and slow bug fixes. Aggregators will still add value here.
API access limits. The rule allows "reasonable" rate limits. Banks will interpret this generously in their own favor. Expect 429 responses in production.
Fee shifting. The rule prohibits charging consumers or their authorized third parties directly. But banks may charge aggregators for "premium" access tiers (e.g., real-time balance vs. daily-refresh). Watch this closely.
Fraud vector expansion. Every new API is a new attack surface. Expect at least one major open-banking-related breach in 2027.
What fintechs should build in 2026
- Support FDX-native integrations alongside your aggregator. Some banks will expose APIs early — take advantage.
- Instrument consent flows. Every user-authorized data connection should have a "revoke access" button. Prepare for it.
- Reduce coupling to a single aggregator. Abstraction layer so you can swap Plaid → direct API without touching product code.
- Rebuild for lower latency. If your Safe to Spend calculation used to run nightly, run it real-time now. The infrastructure will support it.
How AtlasForge is preparing
Our platform already abstracts transport-level details. Partners see one consistent API for transaction data; underneath, we route to Plaid today and FDX-native endpoints as they roll out. When the industry migration happens, your integration code doesn't change.
Related reading:
Ready to build on AtlasForge?
Get sandbox API keys in 60 seconds — or install the Safe to Spend app.