Open Banking
Regulatory frameworks requiring banks to share customer financial data with authorized third parties via secure APIs.
Key Takeaways
- Open banking requires banks to share customer financial data with authorized third parties through secure APIs, giving consumers control over who can access their information and enabling new services like account-to-account payments and real-time credit scoring.
- Regulatory frameworks drive adoption globally: PSD2 (EU, 2018), the Open Banking Standard (UK, 2018), and Section 1033 (US, finalized 2024 but currently paused) each mandate API-based data sharing while phasing out insecure screen scraping.
- Open banking and decentralized finance share the same composability philosophy: both break down walled gardens by letting third parties build on existing financial infrastructure, though open banking operates within a permissioned regulatory framework while DeFi is permissionless.
What Is Open Banking?
Open banking is a regulatory and technological framework that requires banks to make customer financial data available to authorized third-party providers (TPPs) through standardized APIs. Instead of financial data being locked inside a single bank's systems, customers can grant permission for fintechs, lenders, payment providers, and other services to access their account information, transaction history, and balances.
The core principle is data ownership: customers should control their own financial data and choose who can use it. Before open banking, switching banks or using third-party financial tools often meant manual data entry, PDF statements, or screen scraping (where third parties logged in with your credentials). Open banking replaces these approaches with secure, consent-based API access.
As of early 2026, over 78 countries have implemented some form of open banking regulation. The global open banking market is projected to exceed $48 billion in 2026, driven by expanding regulation, growing consumer adoption, and the rise of embedded finance use cases.
How It Works
Open banking relies on three participants: the customer (who owns the data), the bank (which holds the data), and the third-party provider (which accesses the data with permission). The flow follows a standardized pattern:
- The customer initiates a connection through a TPP's application
- The TPP redirects the customer to their bank's authentication page
- The customer authenticates using strong customer authentication (typically two factors)
- The customer reviews and grants consent for specific data access
- The bank issues an access token to the TPP
- The TPP uses the token to retrieve data via the bank's API
- The customer can revoke consent at any time
Authentication uses OAuth 2.0 and OpenID Connect, the same protocols that power "Sign in with Google" flows. The Financial-grade API (FAPI) profile adds security requirements specific to financial data, including mutual TLS and signed request objects.
API Standards
Three major standards define how open banking APIs work in practice:
| Standard | Region | Scope |
|---|---|---|
| Berlin Group (NextGenPSD2) | EU | Account information and payment initiation APIs for PSD2 compliance |
| Open Banking UK (OBIE) | UK | RESTful Read/Write APIs covering accounts, payments, and variable recurring payments |
| FDX (Financial Data Exchange) | US | Consumer-permissioned data sharing across banking, tax, insurance, and investment |
The Berlin Group framework covers over 75% of European banks. Open Banking UK's Read/Write API (v3.1.x) is implemented by all nine CMA-mandated UK banks. FDX connects over 130 million US consumer accounts and was recognized by the CFPB as the first official standard-setting body in January 2025.
Two Core Service Types
Open banking regulations define two categories of third-party access:
- Account Information Services (AIS): read-only access to account data, balances, and transaction history. Used for aggregation, budgeting, and credit assessment.
- Payment Initiation Services (PIS): the ability to initiate payments directly from a customer's bank account. This powers account-to-account payments at checkout without cards.
Example API Request
A typical Open Banking UK API call to retrieve account balances:
GET /open-banking/v3.1/aisp/accounts/{AccountId}/balances
Host: api.bank.example.com
Authorization: Bearer eyJhbGciOiJQUzI1NiIs...
x-fapi-financial-id: OB/2017/001
x-fapi-interaction-id: 93bac548-d2de-4546-b106
// Response
{
"Data": {
"Balance": [{
"AccountId": "22289",
"Amount": {
"Amount": "1230.00",
"Currency": "GBP"
},
"CreditDebitIndicator": "Credit",
"Type": "InterimAvailable",
"DateTime": "2026-05-08T06:06:06+00:00"
}]
}
}Regulatory Landscape
PSD2 and PSD3 (European Union)
The second Payment Services Directive (PSD2) came into force in January 2018, requiring EU banks to provide API access to authorized TPPs with customer consent. It introduced strong customer authentication (SCA), mandating at least two authentication factors for electronic payments.
The European Parliament and Council reached political agreement on PSD3 and a new Payment Services Regulation (PSR) in November 2025. Key changes include mandatory IBAN-name verification, expanded fraud protections, and SCA accessibility as a legal right. The PSR will apply directly across member states, while PSD3 requires national transposition by approximately Q2/Q3 2028.
Open Banking Standard (United Kingdom)
The UK's Competition and Markets Authority mandated open banking in 2016, requiring nine major banks to implement standardized APIs. The roadmap was completed in September 2024. Governance now sits with the Joint Regulatory Oversight Committee (JROC), comprising the FCA, PSR, CMA, and HM Treasury.
The UK is the most mature open banking market: 13.3 million active users as of March 2025 (40% year-over-year growth), with open banking payments accounting for 7.9% of all Faster Payments transactions.
Section 1033 (United States)
Section 1033 of the Dodd-Frank Act requires financial institutions to make consumer data available upon request. The CFPB finalized its implementing rule in October 2024, explicitly banning screen scraping in favor of API access. However, in May 2025, the CFPB itself asked the court to vacate the rule, stating it exceeded statutory authority. The agency issued an advance notice of proposed rulemaking in August 2025 to develop a revised version. Meanwhile, the industry standard FDX continues to operate, providing practical interoperability even as the regulatory framework evolves.
Other Markets
Open banking is expanding globally. Brazil's Central Bank mandates a comprehensive open finance framework covering banking, credit, insurance, and investment data. Australia's Consumer Data Right extends beyond banking into energy and telecommunications. India's RBI-backed Account Aggregator Framework processes over 1.2 billion API calls per quarter and is expected to become mandatory in 2026.
Use Cases
Account Aggregation
Personal finance apps use AIS APIs to pull account data from multiple banks into a single dashboard. Customers see all their balances, transactions, and spending patterns in one place. Before open banking, this required sharing bank login credentials with third parties through screen scraping: a significant security risk that open banking APIs eliminate.
Pay by Bank
Payment initiation APIs enable account-to-account payments at checkout. Customers pay directly from their bank account without entering card details. For merchants, this eliminates interchange fees and scheme fees charged by card networks, reducing payment costs significantly. In the UK, commercial variable recurring payments (VRPs) are expected to go live in Q1 2026 for utilities, financial services, and government payments.
Credit Assessment
Lenders use transaction data to assess creditworthiness in real time, moving beyond traditional credit scores. By analyzing actual income deposits, spending patterns, and account behavior, open banking enables faster loan approvals and serves borrowers who lack conventional credit history. This is particularly impactful for small business lending, where manual document collection previously slowed the process by weeks.
Payment Orchestration
Payment orchestration platforms integrate open banking as one of several payment rails alongside cards, real-time payment systems, and cryptocurrency. By routing transactions through the lowest-cost or fastest available rail, these platforms optimize for both merchant savings and customer experience. For a deeper look at how traditional payment rails compare, see the card network economics analysis.
Open Banking and Crypto: Shared Composability
Open banking and decentralized finance share a fundamental design philosophy: composability. Both break down monolithic financial systems into modular components that third parties can combine in new ways.
In open banking, standardized APIs let fintechs compose new products from existing bank infrastructure: a lending app reads transaction data from one bank and initiates a loan disbursement through another. In DeFi, composable smart contracts let protocols build on each other: a lending protocol reads collateral values from a price oracle and triggers liquidations through a decentralized exchange.
The key difference is permission. Open banking is permissioned: TPPs must obtain regulatory authorization and individual customer consent. DeFi is permissionless: anyone can build on any protocol without approval. This distinction shapes the tradeoffs. Open banking offers regulatory protection and dispute resolution but moves slowly. DeFi offers instant innovation but carries smart contract risk and lacks consumer safeguards.
Crypto payment systems like Spark sit at an interesting intersection. Like open banking, they enable programmable financial infrastructure with standardized interfaces. Like DeFi, they offer self-custody and reduced reliance on intermediaries. As open banking evolves toward broader "open finance" frameworks and stablecoin regulation matures globally, the boundary between traditional and decentralized financial infrastructure continues to blur.
Risks and Considerations
Security
API-based access is more secure than screen scraping, but it still creates risk. Every authorized TPP becomes a potential attack surface. Robust implementations require Financial-grade API (FAPI) security profiles, mutual TLS, and continuous monitoring. Banks must maintain API infrastructure while TPPs must protect stored tokens and customer data.
Consent and Privacy
Meaningful consent requires customers to understand exactly what data they are sharing, with whom, and for how long. In practice, consent screens can be complex and easy to click through without reading. Regulations increasingly require granular consent (specific data sets rather than blanket access) and easy revocation, but effective implementation remains a challenge across all markets.
Fragmented Standards
Each regulatory regime has its own API standard, creating complexity for companies operating across borders. A TPP that works with UK banks must implement different APIs for EU banks and yet another standard for US institutions. Harmonization efforts exist but progress slowly, increasing development costs for global fintech products. This fragmentation mirrors similar challenges in cross-border payments, where correspondent banking networks impose their own interoperability constraints.
Regulatory Uncertainty
The US experience illustrates the risk of regulatory shifts. The CFPB finalized Section 1033 in October 2024 and then asked the court to vacate its own rule seven months later. Companies that invested in compliance face uncertainty about future requirements. In contrast, the EU and UK provide more stable regulatory environments, but PSD3's multi-year implementation timeline means the full picture remains incomplete.
This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.