What Changes for Your Integration Layer

PSD2 gave Europe's banks seven years to build open banking APIs. Most of that time was spent discovering what the directive left unspecified. Fallback interfaces that technically satisfied the letter of the rule while frustrating third-party providers. API performance that degraded under load with no defined consequence. Consent cycles that forced re-authentication every 90 days regardless of user experience cost. PSD3 and its companion regulation, the PSR, are not a light revision of this framework. They are a direct response to those gaps, and several of the changes land squarely on the integration layer your engineering team maintains today. 

The legislative package reached political agreement between the European Parliament and Council in November 2025, with compromise texts published in April 2026. Formal publication in the Official Journal is expected in the second half of 2026, after which most provisions apply roughly 21 months later — putting practical compliance deadlines around 2028, with Verification of Payee provisions following on a slightly longer runway. That sounds distant. For a bank running a multi-year system architecture, it is not. Decisions made in the next planning cycle about API gateway design, consent management, and monitoring infrastructure will determine whether 2028 is a controlled migration or a scramble. 

The Directive/Regulation Split Changes Where Rules Live 

PSD2 was a single directive, transposed into national law with meaningful variation across member states. That variation is precisely what PSD3 addresses. The new package splits into two instruments: PSD3 itself, a directive governing licensing, authorisation, and supervision (merging the previously separate payment institution and e-money institution regimes); and the PSR, a regulation that applies directly across all member states without national transposition. 

For your architecture team, this split matters practically. The PSR is where the open banking API obligations live — dedicated interface requirements, performance standards, Strong Customer Authentication rules. Because it's a regulation rather than a directive, there's no waiting for national implementing legislation and no risk of your jurisdiction's transposition diverging from a neighboring market's. If your bank operates across multiple EU jurisdictions, this is meaningfully good news: the API-facing rules should be identical everywhere, which simplifies a integration layer that previously had to account for country-specific quirks. 

Dedicated APIs Become Mandatory, Not Just Preferred 

Under PSD2, banks could theoretically maintain a fallback interface — often a modified customer-facing channel — alongside or instead of a dedicated API, provided certain exemption conditions were met. In practice, this created a two-tier open banking landscape: some banks built genuinely robust dedicated APIs, others maintained the bare minimum needed to qualify for a fallback exemption. 

The PSR closes this loophole. Dedicated APIs become mandatory for account servicing payment service providers, with the fallback/screen-scraping exemption pathway removed. This is a structural requirement, not a best-practice recommendation, and it has direct implications for any bank whose integration layer was built around meeting exemption criteria rather than around building a genuinely production-grade API. 

API Performance Gets a Parity Standard — With Real Ambiguity Attached 

This is the provision your engineering leadership should be tracking most closely. The PSR requires that dedicated APIs perform at a level of service equivalent to the bank's own customer-facing digital channels. That's a meaningful shift from PSD2's more generic non-discrimination language: it converts open banking API availability and latency from a compliance checkbox into an operational SLA tied directly to your retail or business banking channel's own uptime and response-time profile. 

Worth flagging honestly: the term "equivalent level of service" is not precisely defined in the current texts, and stakeholders across the industry have been pushing the EBA for clarification on what constitutes an acceptable response time. That ambiguity is a design risk, not a reason to wait. Banks that architect their API gateway and monitoring stack now to treat third-party API traffic with the same observability, alerting, and capacity planning rigor as customer-facing traffic will be positioned to meet whatever the eventual technical standard specifies. Banks that continue treating the open banking API as a secondary, lower-priority interface will be retrofitting under deadline pressure. 

Consent Cycles Extend — Reducing Re-Authentication Friction, Not Integration Load 

The AISP consent cycle extends from 180 days to 365 days under the new rules. On the surface this looks like a minor parameter change. Architecturally, it's a meaningful one: your consent management and SCA orchestration components were almost certainly built around a 90-to-180-day re-authentication cadence baked into session and token lifecycle logic. Extending that window reduces friction for end users and third-party providers, but it also means your consent state management needs to correctly handle longer-lived authorizations without introducing security gaps — stale consent that should have been revoked, or token refresh logic that assumes a shorter cycle than the one now in force. 

Verification of Payee Adds a New Real-Time Obligation 

Separate from the open banking API changes, the package introduces Verification of Payee — an IBAN-to-name matching check performed before payment execution, extending protections that already exist for instant credit transfers to a broader set of payment types. This is a new real-time integration point for most banks' payment initiation flow, and it applies on a slightly extended timeline relative to the core open banking provisions. If your PISP integration or payment orchestration layer doesn't already have a pattern for real-time third-party verification calls sitting in the critical path of payment execution, this is a design conversation to have well ahead of the deadline, not adjacent to it. 

What This Means for Your Architecture Now 

None of these provisions are final law yet — publication in the Official Journal is still pending, and national transposition of the directive elements will follow over the subsequent months. But the substance is politically settled, and the direction is clear enough to plan against. Banks that treat 2026 as the preparation year — auditing which parts of their current integration layer relied on PSD2's fallback exemption, stress-testing API gateway performance against customer-channel benchmarks, and reworking consent lifecycle logic ahead of the mandate rather than after it — will meet the eventual deadline as a scheduled migration. The alternative is discovering these gaps during a compliance audit with a hard deadline already in force. 

This is also worth noting separately: FIDA, the Financial Data Access Regulation proposed alongside PSD3 and PSR, remains in trilogue and would extend open-banking-style access to investments, pensions, insurance, and mortgages under a new category of data-sharing obligation. It is not yet part of the confirmed package, but it signals the direction European regulation is heading — open finance, not just open banking. Institutions building their PSD3 integration layer now have a reasonable opportunity to architect for that broader scope rather than treating it as a separate future project.