Open banking API development — the technical implementation of PSD2, PSD3, and equivalent open banking regulations — is one of the most consequential and complex API development programmes a financial institution undertakes. Getting the API design, security architecture, consent management, and developer experience right is the difference between open banking that drives new revenue streams and open banking that creates compliance cost with no business value. This guide covers the technical architecture, PSD2/PSD3 differences, and implementation roadmap for financial institution technology teams.
What Is Open Banking API Development?
Open banking API development refers to the design, implementation, and operation of standardised APIs that enable licensed third-party providers (TPPs) — fintechs, account aggregators, payment initiators — to access customer financial data and initiate payments, with explicit customer consent, through secure interfaces provided by account-holding banks and financial institutions.
PSD2 vs PSD3: What Changes and When
| Dimension | PSD2 (Current) | PSD3 (Coming 2026–2027) | Technical Impact |
|---|---|---|---|
| SCA (Strong Customer Auth) | 3DS2, FIDO2 for most transactions | Stronger fraud liability shift; SCA exemption rules tightened | Update authentication flows; higher SCA pass rates required |
| API Performance | No explicit latency SLA in regulation | Minimum API availability (99.5%) and latency SLAs proposed | SLA monitoring and enforcement; public API status pages required |
| Data Scope | Accounts, transactions, payment initiation | Expanded to include savings, investments, mortgages, pensions | Significant API scope expansion; new data models required |
| Consent Management | Per-institution consent | Portable consent across institutions proposed | Consent portability infrastructure; cross-institution consent linking |
| Developer Sandbox | Required but quality varies | Minimum sandbox quality standards proposed | Improved sandbox with synthetic data; automated testing suites |
Open Banking API Standards
- OBIE (Open Banking Implementation Entity) specification — most mature globally
- Read/Write API Specification v3.1.11 — accounts, payments, funds confirmation
- DCR (Dynamic Client Registration) for TPP onboarding
- FAPI 2.0 security profile — most secure open banking implementation globally
- Pan-European standard — adopted across most EU/EEA markets
- XS2A (Access to Account) interface specification
- STET (France), PolishAPI (Poland) are national variants
- Less prescriptive than UK standard — more implementation variation
- Financial Data Exchange — voluntary standard in US/Canada
- CFPB Rule 1033 (US) mandating open banking starting 2025
- OAuth 2.0 / OIDC-based consent and authorisation
- Less mature than EU/UK — significant implementation variance
- Financial-grade API (FAPI) 2.0 — the security standard all open banking should use
- PAR (Pushed Authorisation Requests) — prevents request tampering
- JARM (JWT Secured Authorisation Response Mode) — signed responses
- DPoP (Demonstrating Proof of Possession) — token binding to client
Technical Architecture: Open Banking API Platform
Deploy a dedicated open banking API gateway (Kong, Apigee, or AWS API Gateway with custom authorisers) that handles: mTLS certificate validation for TPP identity, OAuth 2.0 / OIDC authorisation server (Keycloak, ForgeRock, or purpose-built like Ozone), rate limiting per TPP, request/response logging for regulatory audit, and FAPI 2.0 security profile enforcement. This layer must be separate from your general API infrastructure for security isolation.
Build a dedicated consent management system that stores: customer identity, TPP identity, granted scopes, consent creation time, expiry, and revocation status. Consent must be queryable by customers (for the consent dashboard) and by the API (for authorisation decisions on every request). Design for consent portability from day one — PSD3 will require it. Our software development team builds consent management systems for EU, UK, and US open banking programmes.
Connect your open banking API to core banking account and transaction data. Use an abstraction layer that normalises core banking data to the relevant open banking schema (OBIE, NextGenPSD2, FDX) — this decouples your API from core banking system changes and enables multi-system aggregation. Cache account metadata aggressively; cache transaction data with short TTLs. Plan for 500ms P95 response time — core banking systems are often the bottleneck requiring dedicated integration optimisation.
Open banking API development requires expertise spanning regulatory compliance, financial-grade API security, core banking integration, and developer experience — a rare and complex combination. Our API integration and software development teams have built open banking platforms for banks and payment institutions across the UK, EU, and US. Book a free advisory session to scope your open banking API programme.