Open Banking and PSD3

PSD2 opened the door. PSD3 is widening it — and changing the frame entirely. 

While the final legislative timeline for PSD3 continues to evolve through the European Parliament, the direction of travel is clear enough to act on. Banks that wait for full regulatory certainty before assessing their infrastructure readiness will find themselves compressing difficult technical decisions into short implementation windows. The institutions positioning well now are not guessing at outcomes — they are making deliberate choices about what to build, what to defer, and what to evaluate before the obligation arrives. 

This article is for the leaders making those choices: not the engineers who will implement them, but the COOs, managing directors, heads of compliance, and business architects who need to understand what PSD3 means for their technology strategy without needing to read the technical specifications themselves. 

What PSD3 Actually Changes 

PSD2 established the principle that banks must provide third-party providers access to customer account data via APIs, with customer consent. PSD3 extends that principle in three directions that carry meaningful technical consequence. 

Broader data scope. 

Where PSD2 focused on payment accounts, PSD3 moves toward open finance — drawing in savings accounts, investments, loans, and insurance data within a single consent framework. The API surface a bank must expose increases significantly. 

Stronger authentication requirements. 

PSD3 tightens Strong Customer Authentication rules, addressing ambiguities in PSD2 that allowed inconsistent implementation across member states. The exemption thresholds are narrowing, and the evidentiary requirements for dynamic linking — tying an authentication event to a specific transaction — are becoming more demanding. 

New consent and liability models. 

PSD3 introduces more granular consent management obligations and shifts certain liability positions in dispute scenarios, particularly around authorised push payment fraud. Banks will need to demonstrate that consent was captured, stored, and honoured in ways that are auditable on demand. 

Each of these changes has a technology implication. None of them can be addressed with a configuration change or a policy update alone. 

The Engineering Implications — In Business Terms 

For non-technical leaders, the key translation is this: PSD3 compliance is not a legal project with a technology component. It is a technology project with a legal deadline. 

API surface expansion means that systems currently serving a narrow set of approved third-party integrations will need to be re-architected to support a broader data estate at production-grade reliability and security. Banks running internal APIs that were not designed for external consumption — common in institutions that implemented PSD2 on a minimum viable basis — will face the largest gap. An API gateway layer that can enforce rate limiting, authentication, versioning, and audit logging at scale is not optional infrastructure here; it is the compliance mechanism. 

SCA strengthening requires changes to authentication flows that may touch mobile applications, web banking interfaces, and backend identity services simultaneously. The dynamic linking requirements in particular — where the authentication must cryptographically reference the specific payee and amount — need to be embedded at the transaction layer, not bolted on at the authentication layer. Institutions using FIDO2-based authentication are better positioned here; those still relying on SMS OTP face a more substantive remediation path. 

Consent and audit obligations demand that every consent grant, modification, and revocation is captured as a durable, queryable event — not simply a state change in a database. This is where streaming infrastructure matters: in a Kafka-based architecture, consent events flow as an immutable log that can be replayed, audited, and reported against without reconstructing state from transactional records. Banks without this kind of event architecture will find consent auditability expensive to retrofit. 

What to Decide Now 

The regulatory timeline gives some room, but the infrastructure decisions do not have the same flexibility. Three questions are worth resolving in the near term. 

Is your API layer production-ready for open finance scope?  

Not theoretically — in practice. Can it handle the authentication, rate limiting, versioning, and monitoring requirements that a broader data scope will demand? If the honest answer is that it was built to satisfy PSD2 minimum requirements and has not been revisited, that assessment needs to happen now, not when an implementation deadline is confirmed. 

What is your SCA gap against PSD3 expectations?  

A compliance team review of current authentication flows against the draft PSD3 SCA requirements will surface whether remediation is incremental or structural. The answer significantly affects resourcing and timeline estimates. 

Do you have event-level auditability for consent?  

Pull a test case: can your team reconstruct the full consent history for a given customer, including all grants, modifications, and revocations, in response to a regulatory inquiry today? If that requires manual investigation across multiple systems, PSD3's consent obligations will require infrastructure change, not process change. 

What Can Reasonably Be Deferred 

Not every decision needs to be made before the regulation is final. UI/UX changes to consent journeys, third-party developer portal design, and detailed SLA commitments to TPPs are all areas where finalised regulatory text will provide specificity that current drafts do not. 

The deferral risk to manage is assuming that infrastructure decisions fall into the same category. They do not. An API gateway re-architecture or a Kafka-based event log implementation is a multi-quarter programme — not something that can be initiated once a transposition deadline is published. 

Evaluating Infrastructure Readiness 

The practical question for business leaders is not "do we understand PSD3?" It is "do we know what our current infrastructure can and cannot do — and does our technology leadership have a clear view of the gap?" 

Banks with modern, API-first architectures and event-driven data layers are largely building on foundations that PSD3 aligns with. Banks whose core infrastructure was designed for a pre-open banking world — even if PSD2 compliance has been achieved — are likely carrying technical debt that PSD3 will make visible. 

That assessment is worth commissioning independently of the legislative timeline. 

OceanoBe works with banks and financial institutions across Europe to evaluate and implement the infrastructure changes that open banking and open finance regulation demands — from API gateway architecture to event-driven consent management built on Kafka. If you are beginning that assessment, we are a useful conversation to have early.