Open Banking in 2027: UK Maturity vs US CFPB 1033 Reality
The UK has a five-year head start in open banking. The US is finally catching up — but the path runs through a contested CFPB rule, a fragmented state landscape, and builders who can't afford to wait.

The phrase 'open banking' means something fundamentally different depending on which side of the Atlantic you're standing on. In the United Kingdom, it describes a mature, regulator-enforced ecosystem that processed more than 11.7 billion API calls in 2024 alone, according to Open Banking Limited's annual report. In the United States, it still describes — awkwardly, hopefully — a future that is technically mandated but practically contested.
For fintech builders, compliance teams, and product managers working in 2027, the gap between these two realities is not just an academic curiosity. It's a capital allocation decision. Whether you're designing a data aggregation layer, scoping a payments product for the EU, or trying to figure out what CFPB 1033 actually requires of you by when — the answers are genuinely different, and the stakes are high enough to get them right.
The UK Benchmark: What Regulatory Maturity Actually Looks Like
The UK's open banking framework was born out of a Competition and Markets Authority (CMA) order in 2017, not a voluntary industry handshake. The nine largest UK banks — the 'CMA9' — were mandated to build and maintain standardised APIs that allow licensed third parties to access customer account data and initiate payments, with explicit customer consent.
By 2025, the framework had expanded beyond that original mandate into what regulators now call 'open finance,' covering mortgages, pensions, and insurance products under the Financial Conduct Authority's broader Consumer Duty framework. More than 8 million UK consumers and small businesses were using open banking-powered products as of Q4 2025, per the FCA's Financial Lives survey.
The lessons for US builders are structural, not just aspirational:
- Liability frameworks matter more than API specs. The UK resolved disputes between data holders and third-party providers through clear FCA arbitration pathways. In the US, liability for data breaches during screen-scraping versus API access remains murkily litigated.
- Standardisation enabled competition. Because UK banks used a common API standard (OBIE's Read/Write API spec), a startup could write once and reach all nine major banks. US aggregators still negotiate bilateral agreements or rely on Finicity/Plaid network effects.
- Consumer trust followed enforcement, not education. Britons didn't adopt open banking because they understood it — they adopted it because the products it powered (instant account verification, variable recurring payments) were simply better than the alternative.
CFPB 1033: Where the US Rule Actually Stands in 2027
The Consumer Financial Protection Bureau finalised its Personal Financial Data Rights rule — commonly called the Section 1033 rule — in October 2024, under 12 CFR Part 1033. The rule establishes a legal right for consumers to access and share their financial data with authorised third parties, and it requires data providers (banks, credit unions, card issuers) to make that data available via developer-accessible interfaces.
Key implementation dates: Depository institutions with more than $500 billion in assets were required to comply by April 1, 2026. Institutions with assets between $250 billion and $500 billion faced a October 2026 deadline. Smaller institutions have staggered timelines running through 2030.
But 'finalised' has not meant 'settled.' Since the rule's publication in the Federal Register, at least two banking trade groups filed legal challenges arguing the CFPB overstepped its Dodd-Frank authority in mandating specific API performance standards. As of Q1 2027, one challenge is still pending in the Sixth Circuit. The CFPB itself, operating under a restructured leadership following the 2025 political transition, has issued two no-action letters signalling it will deprioritise enforcement against data providers that demonstrate 'good-faith compliance efforts' — language specific enough to exploit and vague enough to worry about.
For practical purposes, this means:
- Large banks are building compliant APIs — JPMorgan Chase, Bank of America, and Wells Fargo all announced developer portal launches in H1 2026 meeting the 1033 performance standards.
- Mid-tier banks are watching the litigation before committing engineering resources.
- Fintechs and data aggregators remain caught between two worlds: screen-scraping relationships that violate the spirit of 1033, and API agreements that often impose data-use restrictions the rule was designed to prohibit.
The CFPB's official 1033 rule page remains the authoritative source for current compliance deadlines and the full text of the rule.
PSD3 and the European Dimension
While American regulators debated, the EU moved. The European Commission published its PSD3 (Payment Services Directive 3) proposal in June 2023, and the directive was formally adopted by the European Parliament in early 2026. Member states have until mid-2027 to transpose it into national law — meaning implementation timelines vary by country, with Germany, France, and the Netherlands expected to hit transposition deadlines on schedule, while Southern European markets may slip into early 2028.
PSD3 is materially more ambitious than its predecessor PSD2, which, despite mandating open banking APIs, was plagued by inconsistent implementation — a 2023 European Banking Authority report found that fewer than 40% of PSD2 API calls succeeded without fallback to screen-scraping.
PSD3's key upgrades for builders:
- Mandatory 'dashboard' consent management: Consumers must be able to revoke third-party data access through their bank's own interface, not just through the third-party app. This shifts UX responsibility partly onto data holders.
- Stronger liability allocation: Banks can no longer disclaim liability for API downtime beyond defined SLA windows (99.5% monthly uptime minimums are codified).
- Open finance groundwork: PSD3 is explicitly designed to interoperate with the incoming Financial Data Access (FIDA) regulation, which extends data portability to investment accounts, insurance, and crypto-asset portfolios.
- Improved Strong Customer Authentication (SCA) rules: The SCA exemption thresholds are raised and clarified, reducing friction in low-risk transactions that frustrated merchants under PSD2.
For US companies with European operations or expansion plans, PSD3 is not optional reading. The European Central Bank's payments monitoring page tracks progress across member state implementations.
What US Builders Should Actually Do Right Now
Given the litigation uncertainty around 1033 and the staggered implementation timeline, the temptation is to wait for 'clarity.' That is the wrong call. Here's why, and what to do instead:
Build to the rule, not to the litigation outcome. The 1033 rule's core requirements — machine-readable API access, standardised data fields covering account balances, transactions, and payment initiation — represent the minimum viable infrastructure for competitive data products regardless of how the Sixth Circuit rules. Banks that are already compliant will prioritise partnerships with fintechs that meet the same standard.
Negotiate data access agreements that mirror 1033 restrictions. The rule prohibits data holders from imposing conditions on data use that aren't 'reasonably necessary' for security — meaning restrictions on selling consumer data to third parties or using it for targeted advertising are likely prohibited. Include language in your aggregator contracts that tracks this standard, so you're not locked into agreements that become illegal in 2028.
Map your European customers to PSD3 timelines by jurisdiction. Don't assume all EU markets comply simultaneously. Build a compliance calendar that distinguishes between Germany (likely Q3 2027), Italy (likely Q1 2028), and others. This is operational, not philosophical.
Invest in tokenised consent infrastructure now. Both 1033 and PSD3 centre consumer consent as the legal basis for data sharing. Products that make consent legible, revocable, and auditable — not buried in terms of service — will win regulatory goodwill and consumer trust simultaneously.
The Aggregator Wars and What 1033 Changes
Open banking in the US has been, for the past decade, substantially a story about Plaid, MX, Finicity (now part of Mastercard), and Akoya competing for bilateral data access agreements with financial institutions. The 1033 rule doesn't eliminate aggregators — but it materially shifts their value proposition.
Pre-1033, an aggregator's core moat was its network of negotiated agreements and its ability to maintain screen-scraping fallbacks. Post-1033, the API access is legally guaranteed (at least for large banks), which means the moat shifts toward:
- Data normalisation and enrichment (transaction categorisation, merchant identity resolution)
- Permissioning infrastructure (consent management, audit trails, user dashboards)
- Reliability and uptime SLAs that exceed the regulatory minimums
- International coverage — 1033 says nothing about Canadian or European accounts, so cross-border data orchestration remains a differentiated capability
For builders integrating aggregation into their products, this transition is actually an opportunity. Commoditised raw data access means more price competition among aggregators — and more leverage for product teams negotiating contracts. See our developer documentation for how the AtlasForge Financial API handles normalised transaction data across both 1033-compliant and legacy data sources.
The Consumer Experience Gap Nobody Talks About
Regulatory frameworks aside, the most underappreciated gap between the UK and US open banking ecosystems is the consumer experience of data sharing itself.
In the UK, a consumer authorising a third-party app sees a standardised consent flow — bank-branded, with specific data categories listed, and a defined expiration date for access. The FCA mandated this UX. In the US, consent flows vary dramatically: some apps still ask for bank login credentials directly; others use OAuth-style redirects that look like phishing attempts to less-technical users; a few have invested in bank-branded experiences.
This isn't just a UX problem. It's a trust problem that directly impacts conversion rates, fraud exposure, and long-term consumer adoption. The 1033 rule begins to address this by requiring 'developer interfaces' (APIs) rather than credential-based access — but it does not prescribe a consent UX standard the way the UK did. Industry groups including the Financial Data Exchange (FDX) are working on voluntary standards, but voluntary is doing a lot of work in that sentence.
For product teams: investing in transparent, legible consent flows is not a compliance checkbox. It's a conversion rate and retention driver. Our Safe to Spend 365 product was designed around exactly this principle — every data connection the user authorises is surfaced with plain-language descriptions of what's shared, when access expires, and a one-tap revocation path.
What the Next 18 Months Decide
The period from mid-2027 through end-2028 will likely define the shape of open banking in both markets for the following decade. Several inflection points are worth tracking:
- Sixth Circuit ruling on the 1033 challenge: Expected late 2027. An adverse ruling would not void the rule but could force the CFPB to repropose with narrower API performance standards — delaying mid-tier bank obligations by 12–18 months.
- EU FIDA adoption: The Financial Data Access regulation, paired with PSD3, is expected to reach final vote by Q4 2027, cementing open finance obligations across investment and insurance verticals.
- FDX API standard adoption rate: If the major US banks voluntarily adopt FDX v2.0 (published January 2027) before smaller institutions are required to comply with 1033, it could de facto solve the standardisation problem — or it could create a two-tier system that disadvantages community banks.
- UK's 'Smart Data' expansion: The UK's Data (Use and Access) Bill, passed in 2025, gives the government powers to extend open banking-style obligations to telecoms, energy, and mortgage data. How quickly this rolls out will determine whether the UK retakes a global leadership position in open finance infrastructure.
For US fintech builders, the strategic imperative is not to wait for regulatory certainty — it is to build infrastructure that is compliant with 1033 as written, compatible with PSD3 for any European exposure, and flexible enough to absorb the standardisation decisions that the next 18 months will force. The builders who treat compliance as architecture rather than legal overhead will ship faster and partner more easily with banks that are themselves navigating the same uncertainty.
If you're evaluating how to connect your product to 1033-compliant data sources today, explore the AtlasForge Financial API — built to support both FDX-standardised feeds and legacy aggregator fallbacks, with full consent audit logging included. Or start with how we approach financial data transparency on the platform overview.
Ready to build on AtlasForge?
Get sandbox API keys in 60 seconds — or install the Safe to Spend 365 app.
