PSD3 Open Banking: What EU Teams Should Plan Now

If you rely on bank APIs to collect payments, verify accounts, or pull transaction data, PSD3 open banking is the EU package that will reset your integration roadmap — even though most rules will not bite until roughly 2028. The European Parliament's ECON committee approved the final compromise texts on 5 May 2026, but the full plenary vote did not appear on the June 2026 Strasbourg agenda, pushing formal adoption toward July 2026 and Official Journal publication later in the summer. That gap between "politically agreed" and "in force" is exactly when product and engineering teams should map what changes for consent, API performance, fraud controls, and provider contracts.

PSD3 open banking: The EU's next payment-services framework — a Payment Services Regulation (PSR) that updates open-banking conduct rules directly across member states, plus a PSD3 directive that merges payment-institution and e-money licensing. For most B2B teams it means stricter bank API quality standards, clearer data-access rules, refreshed consent cycles, and stronger fraud obligations — applied on a ~21-month clock after Official Journal publication, not overnight.

For how account data and payment initiation differ today, see AIS vs PIS in open banking. For choosing a provider under the current PSD2 regime, see how to choose an open banking provider in the EU.

Where does PSD3 open banking stand in June 2026?

Politically agreed, not yet law. Trilogue negotiators reached a provisional deal in November 2025. COREPER endorsed the compromise texts on 22 April 2026, and the European Parliament's ECON committee confirmed them on 5 May 2026. The Legislative Train Schedule still lists formal Parliament and Council adoption as pending, with plenary expected after the June 2026 session window.

Practical read for payments leads:

• Substantive content is largely locked — ECON clearance is the last major committee gate before a simple-majority plenary vote.
• Your PSD2 integrations remain valid — do not pause live flows waiting for adoption.
• Engineering and procurement should start gap analysis now — EBA technical standards on API quality will follow publication on a separate clock.

If you need a provider shortlist while rules evolve, use the provider-matching form to compare coverage, webhooks, and sandbox quality against your markets — the regulatory frame is shifting, but launch criteria stay the same.

What is the difference between PSD3 and the PSR for open banking?

The PSR carries most day-to-day open banking rules; PSD3 handles who gets a licence.

Package	Legal form	What it changes for integrators
PSR (Payment Services Regulation)	EU regulation — applies directly in every member state	Open-banking interface quality, consent refresh, fraud and strong customer authentication, verification of payee, data-access clarity
PSD3 (Payment Services Directive)	Directive — transposed nationally	Merged payment-institution and e-money authorisation, safeguarding timelines, supervisory cooperation

Under PSD2 you already connect through licensed third-party providers (TPPs) or hold your own licence. That architecture survives. What shifts is how good bank APIs must be, how often you re-authenticate customers, and how banks justify restricting access — topics the PSR spells out more tightly than PSD2 practice allowed.

Open-banking interface quality

The PSR expects account-serving banks to run a dedicated interface for payment initiation and account information that performs at least as well as the bank's own channels, measured against harmonised KPIs. The European Banking Authority will publish technical standards after adoption — uptime, latency, and error-rate thresholds are not final in June 2026, but the direction is clear: marginal APIs that worked under PSD2 may need uplift.

For engineering teams, that means:

• Monitor provider SLAs today — if your aggregator already tracks per-bank success rates, keep that data; it becomes evidence in RFPs.
• Plan sandbox parity — providers that test against production-like latency will fare better when KPIs bind.
• Budget for re-certification — not because your product breaks on day one, but because bank-side upgrades can change error profiles.

See best open banking API providers for developers (2026) for evaluation dimensions that overlap with upcoming quality rules.

How will PSD3 open banking change consent and data access?

Customers will re-approve access on a fixed cadence, and banks need stronger reasons to block TPPs.

The agreed PSR text clarifies account-information scope and requires re-authentication every 180 days to keep consent current — a pattern many providers already implement, but now harmonised EU-wide. Banks that want to restrict third-party access must document specific justification, a stricter bar than informal friction some ASPSPs added under PSD2.

Outcome for your product:

• Churn workflows — build renewal nudges before day 180, not after data pulls fail silently.
• Onboarding copy — explain why periodic re-approval protects the customer; reduces drop-off at refresh.
• Fallback paths — when consent lapses, route users to re-link rather than showing empty dashboards.

Payment initiation consent rules remain separate from account-information refresh — your pay-by-bank checkout may not need the same 180-day loop as a lending affordability feed, but multi-product platforms should map both.

What should product teams do before PSD3 enters into force?

Run a structured gap analysis on six workstreams — the substance is known even if dates slip a month.

1. Provider and bank coverage

• Export success rates by bank and country for the last 90 days.
• Flag banks with rising latency or error spikes — they are early candidates for PSR-driven upgrades or outages during uplift programmes.

2. Consent and re-authentication UX

• Instrument drop-off at consent refresh.
• A/B test reminder timing (day 150 vs day 175) before rules harmonise the 180-day expectation.

3. Fraud and verification of payee

• Map outbound payment flows that will need verification of payee (VoP) checks — the PSR extends VoP obligations on a longer timeline than core open-banking provisions (roughly 27 months after entry into force for some VoP elements vs ~21 months for most PSR rules).
• Pair VoP with your existing IBAN confirmation logic — different signals, same operational goal: fewer misdirected funds.

4. Contracting

• Add PSR readiness clauses to provider MSAs: API KPI reporting, incident notification, and roadmap for EBA technical standards.
• Avoid locking multi-year pricing without a regulatory change review trigger.

5. Licensing path (if you hold or plan a licence)

• PSD3 merges payment-institution and e-money regimes — existing EMIs and PIs must re-apply within 27 months of entry into force under the agreed package.
• Most B2B platforms stay on TPP partners; if you operate your own licence, involve legal early.

6. Internal education

• Brief finance and support teams that PSD2 remains the operative frame until application day — customer-facing language should not promise "PSD3-compliant" features that are not testable yet.

When will PSD3 open banking rules actually apply?

Expect roughly 21 months after Official Journal publication for most PSR provisions — likely H1 2028 if OJ lands in mid-to-late 2026.

The European Parliament legislative train notes that negotiated texts still require formal Parliament and Council adoption before entry into force twenty days after Official Journal publication. Member states transpose PSD3 on a similar ~21-month horizon; selected VoP and licensing provisions run longer.

Timeline planners should use ranges, not single dates:

Milestone	Status (June 2026)	Typical next step
ECON committee confirmation	Complete (5 May 2026)	—
Plenary adoption	Pending (July 2026 session expected)	Simple-majority vote
Official Journal publication	Pending	Legal-linguistic review
PSR application (most rules)	Not started	~21 months post-OJ
VoP / some licensing rules	Not started	~27 months post-OJ

The EBA PSD2 review hub will publish implementing technical standards after the level-1 texts enter into force — watch for RTS on interface KPIs and fraud reporting.

Frequently Asked Questions

What is PSD3 open banking in plain terms?

PSD3 open banking is the EU's updated payment-services package: a Payment Services Regulation that modernises open-banking rules (API quality, consent, fraud, data access) and a PSD3 directive that updates licensing for payment and e-money institutions. For most businesses it changes how reliably bank APIs perform and how often customers must re-approve data access — not whether you can use open banking at all.

Has PSD3 been adopted yet?

No — as of June 2026 the package is politically agreed and cleared by the European Parliament's ECON committee (5 May 2026), but formal plenary adoption and Council sign-off are still pending. The June 2026 Strasbourg plenary agenda did not include the files; the next expected window is July 2026, followed by Official Journal publication.

Does PSD3 replace PSD2 immediately?

No. PSD2 remains the operative framework until the PSR applies — expected roughly 21 months after Official Journal publication if OJ lands in the second half of 2026. Continue operating and certifying under current PSD2 requirements until your legal team confirms application dates for your member states.

How does PSD3 open banking affect API providers and aggregators?

Providers must prepare for harmonised interface quality KPIs, clearer data-access rules, and stricter justifications when banks block TPPs. Aggregators that already publish per-bank performance data and support consent refresh flows will adapt faster. Evaluate providers on sandbox realism, webhook reliability, and roadmap transparency for EBA technical standards — not only today's feature checklist.

Will customers need to re-consent every 180 days?

For account information services, the agreed PSR requires re-authentication at least every 180 days to keep access valid — harmonising practices many firms already follow. Payment initiation flows may use different consent mechanics depending on the use case. Build renewal UX before mandates bite to avoid silent data gaps.

Do I need my own payment licence under PSD3?

Most platforms continue partnering with licensed TPPs and never hold a licence. PSD3 merges payment-institution and e-money authorisation regimes; existing licensed firms must re-apply within 27 months of entry into force. If you only consume APIs through a provider, your main action is contractual and technical readiness, not a new licence application.

How should I choose a provider during the PSD3 transition?

Shortlist on coverage, API performance, consent tooling, and regulatory communication — the same criteria that matter under PSD2, with added weight on published KPI reporting and PSR readiness roadmaps. Compare options through a structured evaluation rather than chasing marketing claims tied to rules not yet in force.

Conclusion

PSD3 open banking is no longer a consultation topic — ECON cleared the texts in May 2026, and only formal adoption and Official Journal publication stand between today's PSD2 world and a stricter, harmonised PSR era around 2028. The June 2026 plenary delay buys a few weeks, not years. Use that time to audit consent flows, provider SLAs, fraud controls, and contracts while your live integrations keep running. When banks uplift APIs to meet upcoming KPIs, teams that mapped gaps early will adapt without fire drills — and teams that ignored the timeline will discover bottlenecks under pressure.