Open Banking and Consumer Data Rights: An Implementation Guide

Open banking stopped being a roadmap item the moment three major financial markets turned consumer data portability into a legal obligation. In the US, the CFPB's Section 1033 rule now carries phased compliance dates. In the UK, the nine largest banks have run on a regulator-mandated API standard since 2018 and are moving into a broader open finance regime. In the EU, PSD2 has governed account access since 2018, with a PSD3/PSR package moving through the legislative process to close known gaps.

For engineering and compliance leaders, the question is no longer whether to support third-party data access, but how to build one architecture that satisfies three legal regimes at once, each with its own consent rules, API expectations, and liability model. This guide covers what each regime requires and the patterns that hold up across all three.

Table of Contents

• Key Takeaways
• The Three Regulatory Regimes at a Glance
• United States: Section 1033 and the FDX Standard
• United Kingdom: From CMA Mandate to Open Finance
• European Union: PSD2 and the Road to PSD3
• Consent Management: The Architecture Regulators Actually Want
• API Standards and Interoperability
• Data Access Rights vs. Security: Where the Tension Lives
• Reference Architecture and Implementation Roadmap

Key Takeaways

• The CFPB finalized its Section 1033 Personal Financial Data Rights rule in October 2024, with compliance phased in over several years by institution asset size rather than a single effective date.
• UK Open Banking, built on PSD2's legal foundation but now overseen independently by the FCA and Payment Systems Regulator, is being extended into a broader Smart Data / open finance regime under the Data (Use and Access) Act 2025.
• PSD2 remains binding EU law today; the Commission's proposed PSD3 directive and companion Payment Services Regulation are still moving through the legislative process and would tighten dedicated-interface performance and reduce re-consent friction.
• Across all three regimes, the compliant technical pattern converges on the same shape: dedicated OAuth 2.0/FAPI-secured APIs, granular time-limited consent, and self-service revocation dashboards, not credential-based screen scraping.

The Three Regulatory Regimes at a Glance

Section 1033, UK Open Banking, and PSD2 reach similar outcomes through different legal routes. Section 1033 is a rulemaking under the Dodd-Frank Act, enforced by the CFPB against a defined set of data providers, phased by size. UK Open Banking began as a competition remedy: the CMA ordered the nine largest current account providers, the CMA9, to build a common API standard after finding poor data portability was suppressing switching. PSD2 is an EU directive transposed into national law, giving licensed account information and payment initiation providers a right to account access (XS2A) once a customer consents.

US compliance runs on a rulebook with phased deadlines, UK compliance on a standard the regulator effectively owns, and EU compliance on a directive implemented through dozens of different national APIs. Treat these as related but distinct programs.

United States: Section 1033 and the FDX Standard

Section 1033 of the Dodd-Frank Act has existed since 2010, giving consumers a right to their financial data in usable electronic form. What changed in October 2024 is that the CFPB finalized the Personal Financial Data Rights rule, operationalizing that right: covered data providers, including banks, credit unions, and card issuers, must make specified data available through secure standardized interfaces to authorized third parties, without charging for access.

Compliance dates are staggered by provider asset size, with the largest depository institutions facing the earliest deadlines and the smallest given the most runway or exempted. The rule has drawn legal challenges since finalization, so teams should confirm current status rather than assume the original schedule holds. It is technology-neutral, but FDX (Financial Data Exchange) has emerged as the dominant standard: its API specification, built on OAuth 2.0 and REST/JSON, is already in use across most large US banks and aggregators.

United Kingdom: From CMA Mandate to Open Finance

UK Open Banking is often cited as the most mature implementation globally. The CMA's 2017 retail banking market investigation found customers, particularly small businesses, were poorly served by an inability to switch providers using their own transaction data. The remedy: an order requiring the CMA9 to fund and build a common API standard, originally governed by the Open Banking Implementation Entity (OBIE).

The legal basis for third-party access is the UK's implementation of PSD2 through the Payment Services Regulations 2017, which survived Brexit as retained law. What has changed is governance: OBIE's functions are transitioning to a successor overseen jointly by the FCA and Payment Systems Regulator, guided by the Joint Regulatory Oversight Committee's roadmap for open finance. The Data (Use and Access) Act 2025, Royal Assent mid-2025, creates a Smart Data framework extending this portability beyond banking.

European Union: PSD2 and the Road to PSD3

PSD2 (Directive (EU) 2015/2366) has governed EU open banking since national transposition in 2018. Its XS2A provisions require account servicing payment service providers to give licensed account information service providers (AISPs) and payment initiation service providers (PISPs) access once the customer gives explicit consent, via a dedicated interface or a fallback route where one underperforms. Strong Customer Authentication rules, detailed in the RTS on SCA and Common and Secure Communication, mandate multi-factor authentication and a widely referenced 90-day re-authentication cycle.

PSD2's known weaknesses, inconsistent interface performance, re-consent friction, and gaps in fraud liability, are what the proposed PSD3 directive and companion PSR target. That package is still moving through the EU legislative procedure, so PSD2 remains operative law; build for PSD2 today while keeping architecture flexible enough to absorb PSR's changes.

Consent Management: The Architecture Regulators Actually Want

Despite different statutory language, all three regimes converge on the same consent principles: specific to a defined purpose and data scope, freely given and separable from other terms, time-limited with a clear expiry, and revocable at any time through a channel at least as easy as the one used to grant it.

In practice, a consent layer must record, for every grant, the data categories in scope, the requesting third party, the declared purpose, the expiry date, and an audit trail of grants, refreshes, and withdrawals. A single dashboard where customers see every active connection and revoke it in one action is table stakes in the UK, and increasingly expected elsewhere.

API Standards and Interoperability

Technical fragmentation is the biggest cost driver in cross-border programs. In the US, FDX's specification is the closest thing to a national standard, though the CFPB rule remains technology-neutral. In the UK, the OBIE-authored Open Banking Standard is near-universal among the CMA9. In the EU, no single standard is mandated; the Berlin Group's NextGenPSD2 framework is most widely adopted, but France's STET and Poland's own API standard remain in use, so aggregators maintain multiple country adapters.

Security is converging faster than data models. OAuth 2.0 flows paired with OpenID Connect and the FAPI (Financial-grade API) security profile now underpin UK Open Banking, are referenced in Berlin Group and FDX specifications, and are becoming default for any dedicated interface. Treat FAPI-aligned OAuth as the baseline and map jurisdiction-specific data models on top of it, not the reverse.

Data Access Rights vs. Security: Where the Tension Lives

Every regime expands access; every security team's job is to constrain it, so friction here is structural. The recurring failure mode we see in our experience: treating the regulatory minimum as the security ceiling. A bank implementing exactly the SCA re-authentication cadence PSD2 requires, and nothing more, typically has no additional signal to catch a compromised integration between events.

Data minimization is the other side of the coin. All three regimes frame access rights around data requested for a stated purpose, not blanket account access, yet interfaces are commonly built to expose broader scopes than a use case needs. Aligning scope granularity in the API layer with the purpose limitation already required in the consent layer closes a gap that shows up repeatedly in exams and fraud post-mortems alike.

Reference Architecture and Implementation Roadmap

A defensible architecture typically separates into four layers: an API gateway exposing FDX-, Open Banking-, or Berlin Group-shaped endpoints behind FAPI-profile OAuth 2.0; a consent and permissions service that is the system of record for every grant, scope, and expiry; a monitoring layer watching third-party call patterns against expected volumes; and a consent dashboard reading from that same permissions service.

For institutions starting out, map current data-sharing arrangements against the compliance dates in each jurisdiction, then build the consent and permissions service before the API gateway. Retrofitting granular consent onto an already-built API is harder than building the API against a consent model already in place.

Getting the architecture right matters beyond the compliance checkbox: every new consent-based data flow is also a new attack surface, and that same data typically feeds the models used to score fraud risk in real time. Teams building that layer should also look at how AI is being applied to fintech risk analysis and fraud detection, since the two systems are increasingly designed together. If your team is mapping Section 1033, UK Open Banking, or PSD2/PSR obligations onto a build plan, get in touch with our team to discuss a compliance and architecture assessment.

Frequently Asked Questions

Is Section 1033 already in effect for US banks?

The CFPB finalized the rule in October 2024, but compliance dates are staggered by asset size, with the largest institutions facing the earliest deadlines. The rule has also faced legal challenges since finalization, so institutions should confirm the current timeline rather than assume the original schedule holds.

Do UK Open Banking rules still depend on PSD2 now that the UK has left the EU?

Partly. The Payment Services Regulations 2017 that transposed PSD2 remain in force as retained UK law. Governance has since evolved independently under the FCA and Payment Systems Regulator, and the Data (Use and Access) Act 2025 extends the model into a broader Smart Data regime beyond banking.

What is the difference between PSD2 and the proposed PSD3/PSR package?

PSD2 is the current binding directive governing account access, strong customer authentication, and third-party licensing. PSD3 and the companion Payment Services Regulation are proposals still moving through the legislative process to improve interface performance and clarify fraud liability; PSD2 remains operative until adopted.

What API standard should a US fintech build to first?

FDX's specification is the standard most large US banks and aggregators are converging on ahead of Section 1033 compliance dates, and offers the most direct path to compatibility with likely integration partners.

How often does consent need to be refreshed under these regimes?

PSD2's SCA rules build in a widely referenced 90-day re-authentication cycle. The US and UK regimes do not copy that exact interval, but both require a defined expiry and an easy revocation path, so a consent architecture built around fixed, auditable expiry windows tends to satisfy all three with configuration changes, not redesign.