Banking API Standards: Section 1033, FDX, and ISO 20022

Banking API standards are the shared technical specifications and legal rules that let banks, credit unions, and third-party financial apps exchange customer account data through secure, structured digital connections. They replaced an earlier era in which consumers handed over their bank login credentials so an app could scrape data from the screen. In their place is a token-based system where a fintech app receives limited, time-bound permission to see specific account information, and the consumer’s password never leaves the bank.

The standards exist on two layers. Regulators in the EU, UK, and United States set the legal requirement that banks must open access. Industry bodies then publish the technical specifications, covering data formats, security protocols, and messaging structures, that banks and app developers actually implement.

The Laws That Require Open Access

Open banking did not emerge voluntarily. In every major market, regulators forced banks to open their systems to outside developers, and the resulting legal frameworks differ in scope and enforcement.

European Union

Directive (EU) 2015/2366, known as PSD2, is the legal foundation for open banking across the EU. It requires banks to give authorized third-party providers access to customer payment accounts, enabling account information services that show consumers all their finances in one place and payment initiation services that let consumers authorize payments directly from their bank accounts through third-party apps.¹ PSD2 leaves penalties to each member state, requiring only that they be “effective and proportionate.”

In November 2025, the European Parliament and Council reached a provisional agreement on PSD3 and a new Payment Services Regulation. The update shifts significant fraud liability onto payment service providers, requiring them to verify that a payee’s name matches their account identifier before processing a payment.² As of early 2026, the agreement still awaits formal adoption.

United Kingdom

The UK launched its open banking initiative in 2017 after the Competition and Markets Authority ordered the nine largest retail banks to open customer data using secure, standardized protocols and to fund an independent entity to develop the technical specifications.³ The result was a unified set of read-and-write API standards that any fintech could use to connect to major banks through a single interface.

United States

In the United States, the Consumer Financial Protection Bureau finalized its Personal Financial Data Rights rule in October 2024, implementing Section 1033 of the Dodd-Frank Act. The statute requires covered financial institutions to make transaction data and other account information available to consumers in electronic form upon request.⁴ The implementing regulation at 12 CFR Part 1033 translates that right into detailed technical and operational duties for banks, credit unions, and certain nondepository institutions.⁵

A central goal of the rule is eliminating credential-based screen scraping. The final rule prohibits data providers from letting third parties access developer interfaces using consumer credentials, citing security, privacy, and accuracy risks.⁶ Banks must offer structured API-based access instead. Violations fall under the CFPB’s civil money penalty authority, with tiers running from $5,000 per day for any violation up to $1,000,000 per day for knowing violations.⁷

When Section 1033 Applies to Your Bank

The CFPB designed a phased rollout tied to asset size:

April 1, 2026: depository institutions with $250 billion or more in total assets, and nondepository institutions with $10 billion or more in receipts.
April 1, 2027: depository institutions with $10 billion to $250 billion in assets, and smaller nondepository institutions.
April 1, 2028: depository institutions with $3 billion to $10 billion in assets.
April 1, 2029: depository institutions with $1.5 billion to $3 billion in assets.
April 1, 2030: depository institutions with more than $850 million but less than $1.5 billion in assets.

Community banks and credit unions with less than $850 million in assets are exempt from the requirement to build and maintain a third-party developer interface.⁸

There is a major caveat. In October 2025, the U.S. District Court for the Eastern District of Kentucky stayed the compliance deadline while the CFPB reconsidered aspects of the rule. As of early 2026, the April 1 deadline for the largest institutions is not being enforced. The timeline above reflects the regulation as written; institutions and consumers should watch the ongoing litigation before treating any date as final.

What Third-Party Apps Can and Can’t Do With Your Data

The Section 1033 framework places strict guardrails on what a third-party app can do once it has access. A third party qualifies as “authorized” only by certifying that it will satisfy specific obligations around collecting, using, and retaining covered data.⁹

Third parties can only collect and use data that is “reasonably necessary” to provide the service the consumer actually requested. The rule explicitly bars three common monetization practices: targeted advertising, cross-selling other products, and selling the data outright. Authorization also expires after one year. The third party must obtain fresh consent to keep accessing the account, and consumers can revoke access at any time, which triggers a notification to the bank.⁵ If you stop using an app, its access lapses within a year even if you forget to disconnect it manually.

The Financial Data Exchange Standard

The CFPB sets the legal requirements. The Financial Data Exchange, or FDX, provides the technical specification that most U.S. institutions use to comply. FDX operates as a consortium of over 200 financial institutions, fintechs, and data aggregators, and the CFPB has recognized it as a standard-setting body for open banking in the United States.¹⁰

The FDX API specification defines the data formats, endpoints, and security requirements that member institutions implement. The current stable release is version 6.5, launched in late 2025, which expanded data clusters for tax reporting, insurance, and investment information beyond deposit and credit card accounts. The specification incorporates FAPI 1.0 as a certification requirement, with migration toward FAPI 2.0 underway.

A shared standard is what makes the ecosystem workable. A developer builds one integration against the FDX specification and can connect to any institution that implements it. Without a common standard, that developer would need to build and maintain separate integrations for every bank, which is how things worked in the screen-scraping era.

How Banking APIs Move Data

Banking APIs follow the REST architectural style, which uses standard internet commands (GET to retrieve data, POST to submit it) to move information between servers. REST replaced older approaches like SOAP, which required heavy coding and significant processing overhead. The lighter design lets developers build financial integrations faster, and connections scale under load.

Data traveling through these connections is formatted using JSON, a text-based structure built on simple attribute-value pairs. A bank balance comes through as something like "availableBalance": 1523.47 rather than buried in proprietary markup. JSON is easy for machines to parse and readable when a developer needs to debug why an app is showing the wrong number.

The CFPB’s final rule reinforces this architecture by requiring data providers to make information available through a “developer interface” that follows standardized formats.⁶

Security and Authorization Protocols

OAuth 2.0

OAuth 2.0 is the foundation of how banking APIs handle authorization. Rather than requiring you to hand your bank password to a third-party app, OAuth issues a digital token that grants limited access to specific account data for a set period. The app never sees your credentials. If the token is compromised, your login remains safe, and the bank can revoke the token without forcing a password change.¹¹

OpenID Connect

OpenID Connect adds an identity layer on top of OAuth 2.0. Where OAuth answers whether an app is allowed to access data, OpenID Connect answers whether the person requesting access is who they claim to be. The bank performs the authentication and passes a verified identity confirmation back to the app.¹²

FAPI 2.0

Standard OAuth 2.0 was not designed for the threat environment financial APIs face. The Financial-grade API (FAPI) 2.0 security profile closes those gaps by layering additional requirements on top of OAuth 2.0 and OpenID Connect.¹³ Key protections include:

Sender-constrained tokens. Every access token is cryptographically bound to the client that requested it. A stolen token is useless to an attacker because they cannot prove they are the legitimate sender.
Pushed authorization requests. All authorization parameters are sent directly from the client to the bank’s server before the user is redirected, preventing tampering in transit.
Short-lived authorization codes. Codes expire within 60 seconds and cannot be reused.
Mutual TLS or DPoP. Both the client and server authenticate each other cryptographically, not just the server to the client as in standard HTTPS.

FAPI 2.0 requires every request to go through pushed authorization and rejects any authorization request that does not. Authorization codes can only be used once, and the specification mandates PKCE with the S256 challenge method to prevent code interception.¹⁴

ISO 20022 for Message Content

REST and JSON handle the transport layer. ISO 20022 governs the content of financial messages themselves. It is a global standard that defines the structure, meaning, and vocabulary of financial data exchanged between institutions, with a central dictionary of business terms and a modeling methodology that works independently of any particular technical format.¹⁵

The practical difference is data richness. Older messaging formats like SWIFT’s MT messages had limited character fields that forced institutions to abbreviate or omit payment details. ISO 20022 messages carry structured fields for tax information, beneficiary details, payment purpose codes, and other metadata that older formats could not accommodate. When every message follows the same schema, receiving institutions can automate validation, route payments faster, and run fraud detection across consistent data fields.

As of November 2025, ISO 20022 became the exclusive standard for SWIFT cross-border payments, replacing the legacy MT format entirely. Payment instructions still sent in the old format are automatically converted to ISO 20022.¹⁶

If Something Goes Wrong: Your Liability for Unauthorized Transfers

When money moves without your permission, federal law caps your exposure based on how quickly you report the problem. The Electronic Fund Transfer Act, implemented through Regulation E, sets three liability tiers:

Reported within two business days: liability is capped at $50 or the amount of the unauthorized transfer, whichever is less.
Reported after two business days but within 60 days: liability can increase to $500, covering unauthorized transfers that occurred between the two-day and 60-day windows.
Reported after 60 days: you could be liable for the full amount of any unauthorized transfers that occurred after the 60-day period, with no cap.

The 60-day clock starts when your bank sends the periodic statement showing the unauthorized activity.¹⁷ The statute carves out exceptions for extenuating circumstances like extended travel or hospitalization, which can extend the reporting window to whatever is reasonable under the circumstances.

1
EUR-Lex. Revised Rules for Payment Services in the EU
2
European Parliament. Payment Services Regulation – Legislative Train Schedule
3
GOV.UK. Millions of Customers Benefit as Open Banking Reaches Milestone
4
Office of the Law Revision Counsel. 12 USC 5533 – Consumer Rights to Access Information
5
eCFR. 12 CFR Part 1033 – Personal Financial Data Rights
6
Consumer Financial Protection Bureau. Required Rulemaking on Personal Financial Data Rights
7
Office of the Law Revision Counsel. 12 US Code 5565 – Relief Available
8
Consumer Financial Protection Bureau. 12 CFR 1033.121 – Compliance Dates
9
Consumer Financial Protection Bureau. Required Rulemaking on Personal Financial Data Rights
10
Financial Data Exchange. Financial Data Exchange
11
Internet Engineering Task Force. RFC 6749 – The OAuth 2.0 Authorization Framework
12
OpenID Foundation. How OpenID Connect Works
13
OpenID Foundation. Open Banking, Open Data and Financial-grade APIs
14
OpenID Foundation. FAPI 2.0 Security Profile
15
ISO20022. About ISO 20022
16
Swift. ISO 20022 – Standards
17
Office of the Law Revision Counsel. 15 USC 1693g – Consumer Liability