Open Banking and PSD3: What Developers Need to Know in 2026
The Evolution from PSD2 to PSD3
PSD2 cracked open the banking monopoly on customer data. PSD3 is finishing the job. The European Commission's proposed Payment Services Regulation (PSR) and Financial Data Access (FIDA) framework expand open banking from payments into investments, insurance, pensions, and lending. For developers building fintech products, this means new APIs to integrate, new consent flows to build, and new business models to unlock. If you built on PSD2, PSD3 changes the rules. If you haven't started, now is the time - the regulation creates a standardized framework that reduces integration complexity while dramatically expanding the addressable market.
PSD3 Key Changes for Developers
FIDA (Financial Data Access): The biggest shift. FIDA extends open banking beyond payment accounts to savings, investments, insurance policies, pensions, and crypto assets. Banks and financial institutions must provide API access to this data with customer consent. This creates entirely new product categories - think holistic financial dashboards, automated portfolio rebalancing across providers, or insurance comparison tools with real policy data.
Mandatory API performance standards: PSD2's biggest pain point was unreliable bank APIs. PSD3 mandates 99.5% uptime, sub-second response times, and dedicated API interfaces that perform at least as well as the bank's own customer-facing channels. Banks that fail to meet these standards face penalties, eliminating the passive resistance that plagued PSD2 adoption.
Enhanced Strong Customer Authentication: SCA requirements evolve with new exemptions for trusted beneficiaries, recurring transactions, and low-risk payments identified by transaction risk analysis. The delegation model allows payment service providers to perform SCA on behalf of the issuing bank, reducing friction in checkout flows.
Liability framework overhaul: Clear liability rules for unauthorized transactions, including cases involving social engineering fraud. Payment providers must reimburse customers within 24 hours and can only charge back merchants with clear evidence of merchant fault. This changes how you architect dispute handling systems.
Account-to-Account Payments: Bypassing Card Networks
A2A payments are the sleeper revolution in PSD3. When a customer pays directly from their bank account to a merchant's account, both parties skip card network fees entirely. Visa and Mastercard typically charge 1.5-3% per transaction. A2A costs a fraction of that. For high-volume merchants processing millions in payments, the savings are substantial.
The technical challenge is building A2A payment experiences that match the convenience of card payments. Instant payment rails like SEPA Instant (settling in under 10 seconds) make this viable. Your payment initiation service needs to handle bank selection, redirect-based SCA flows, real-time payment confirmation, and fallback handling when instant payments fail. The UX must be seamless - any additional friction compared to card payments kills adoption. Build a bank selection screen with auto-detection based on the user's country, cache frequently used banks, and implement payment status polling with webhooks for confirmation.
API Standards: Berlin Group vs UK Open Banking
Two major API standards dominate. The Berlin Group's NextGenPSD2 specification is used across the EU and covers account information, payment initiation, and fund confirmation. UK Open Banking has its own specification, more prescriptive and arguably better designed, but limited to the UK market. PSD3 is pushing toward harmonization, but today you need to support both if you're building pan-European products.
In practice, even within the Berlin Group standard, each bank implements the API differently - different authentication flows, different data formats, different error codes. This is why aggregators like Plaid, TrueLayer, and Tink exist. For most startups, integrating through an aggregator is the pragmatic choice. You get normalized data, pre-built bank connections, and SCA flow handling. Build direct bank integrations only if you're processing enough volume with specific banks to justify the maintenance cost, or if you need capabilities that aggregators don't expose.
Building GDPR-Compliant Consent Flows
Granular consent: PSD3 requires consent to be specific to data types and purposes. A user might consent to sharing transaction history but not account balances, or share data for budgeting but not for marketing. Your consent management system needs to capture, store, and enforce these granular permissions across all data access points.
Dashboard and revocation: Users must be able to view all active consents and revoke any consent instantly. When consent is revoked, data access must stop immediately and any cached data must be deleted within 24 hours. Build consent dashboards as a core feature, not an afterthought.
Consent renewal: Financial data consent expires after 90 days and must be actively renewed - no auto-renewal. Design your re-consent flow to be low-friction: remind users before expiry, explain the value they get from sharing data, and make the renewal process one-click where possible.
Audit trails: Maintain immutable logs of every consent grant, modification, and revocation. These logs must be available for regulatory audit and customer requests. Include timestamps, the specific data scope consented to, and the purpose for which consent was granted.
Security Requirements: SCA, Certificates, and eIDAS
PSD3 builds on the security foundation of PSD2 but adds significant requirements. Strong Customer Authentication still requires two of three factors (knowledge, possession, inherence), but the implementation options expand. Behavioral biometrics - analyzing typing patterns, device handling, or navigation behavior - can now count as an inherence factor, enabling invisible authentication that reduces user friction.
Certificate-based mutual TLS authentication using eIDAS qualified certificates remains mandatory for all API access. Your systems need to handle certificate rotation, revocation checking via OCSP, and certificate chain validation. Build certificate management into your deployment pipeline - expired certificates are the number one cause of open banking API outages. Consider using a certificate management service that handles renewal automatically and alerts well before expiry.
Implementation Architecture
Aggregation layer: Abstract bank-specific differences behind a normalized API. Whether you build this yourself or use a third-party aggregator, your application code should never deal with bank-specific formats. Define a canonical data model for accounts, transactions, and payments that maps to all supported banks.
Consent service: Build a dedicated microservice for consent management. It handles consent capture, storage, enforcement, expiry, and revocation. Every data access request passes through the consent service to verify that active, valid consent exists for the specific data type and purpose.
Token vault: Store bank access tokens and refresh tokens in an encrypted vault with strict access controls. Implement automatic token refresh and handle token revocation gracefully. Never expose bank tokens to client-side code.
Event-driven updates: Use webhooks and polling to keep financial data current. Implement intelligent sync strategies - high-value accounts might sync every hour, dormant accounts daily. Cache data locally to reduce API calls and improve response times, but respect consent boundaries on cached data.
Related Articles
Building on Open Banking?
I help fintech teams architect open banking integrations that are compliant, scalable, and ready for PSD3 - from API design to consent management.
Let's Talk Architecture