PSD2 Open Banking: Present-Tense EU Framework

If your roadmap includes collecting from bank accounts, verifying IBANs before payouts, or reading transaction history without manual uploads, PSD2 open banking is the EU framework that makes those flows legal and interoperable today. It is not a product you buy — it is the rulebook that lets licensed providers connect your application to customer banks with consent. Teams that treat PSD2 as background noise often stall in procurement; teams that map it to one user story ship pay-by-bank checkout, verification, or affordability feeds in weeks through a provider rather than years of direct bank adapters.

PSD2 open banking: The EU payment-services framework that lets businesses offer pay by bank, account verification, and transaction-data features through regulated APIs — with customer consent and strong authentication — instead of building separate connections to every bank. Most B2B products integrate a licensed provider rather than holding permissions themselves.

What does PSD2 open banking mean for your product today?

You can launch bank-rail features in EU markets under rules that already apply — without waiting for PSD3. PSD2 (the revised Payment Services Directive, in force since 2018) requires banks to expose dedicated interfaces for payment initiation and account information when accessed by licensed third-party providers. For a payments or product lead, that translates into three buildable outcomes:

• Collect money — customer approves a bank transfer from checkout, an invoice link, or a platform payout flow
• Verify accounts — confirm the account holder and IBAN before first disbursement or seller onboarding
• Use transaction data — match inbound payments, run affordability checks, or reduce manual statement uploads

Your engineering team still integrates one provider API; PSD2 defines what banks must expose and how consent and authentication must behave. Coverage is never universal — institution-level success rates vary by country — but the framework is live across EU member states and underpins the provider market you evaluate in an RFP.

When you document scope for a shortlist, use the provider-matching form to filter on countries, use cases, and sandbox quality against the flows PSD2 already enables.

How do pay by bank and account verification work under PSD2?

Payment initiation moves money; account information reads data — each needs its own consent path and UX copy. Under PSD2, licensed payment initiation providers route customers through their bank's authorisation screen. After strong customer authentication, your backend receives confirmation you can map to orders, invoices, or ledger entries. Account information flows work similarly but return balances or transactions for verification, lending, or reconciliation — not a debit from the account.

Job to be done	What the customer experiences	What your ops team gets
Pay by bank checkout	Redirect to bank app, approve amount	Settlement or authorisation status via webhook
IBAN / account verification	Approve read-only access to account details	Match on name and account number before payout
Affordability or income check	Approve transaction history pull	Categorised inflows for credit or onboarding decisions

Mixing initiation and data in one confusing screen increases drop-off. Start with the flow that unlocks revenue — usually payment initiation for checkout — and add verification when onboarding or risk teams need it. For a deeper split, see AIS vs PIS in open banking.

According to the European Banking Authority's PSD2 review hub, ongoing supervision focuses on interface quality, fraud, and access — practical reasons to track provider per-bank performance, not only marketing coverage maps.

Who needs a licence versus a provider under PSD2?

Most B2B platforms integrate a licensed partner; only some payment institutions build direct bank links. PSD2 created regulated roles — including payment initiation and account information providers — that hold permissions from national supervisors. If you are a merchant, SaaS platform, marketplace, or lender, you typically contract with a provider that already holds those permissions rather than applying for your own licence.

Three common paths:

1. Provider integration (default) — You build UX and ledger logic; the provider holds PSD2 permissions and bank connectivity. Fastest route for most EU B2B teams.
2. Own licence — You become (or already are) a payment institution and may connect directly or mix partner coverage. Higher compliance load, more control over economics.
3. Hybrid orchestration — Enterprise PSPs route some banks through one provider and others through a second for coverage or failover. See build vs buy open banking before choosing this path for v1.

Banks that hold customer accounts act as account-serving payment service providers — the institutions your provider connects to. The ASPSP definition hub explains that role in plain language when legal or engineering teams ask who "the bank" is in an API diagram.

What consent and authentication rules affect your UX?

Customers must explicitly approve access, and high-risk actions require strong authentication — design copy and retry flows around that, not around directive article numbers. PSD2 mandates informed consent before payment initiation or account data access. Strong customer authentication (SCA) applies to many payment initiations — usually satisfied when the customer approves in the bank app. Account-information access may require periodic reconfirmation depending on scope and provider implementation; many teams already plan refresh nudges before data feeds silently fail.

Product implications:

• Clear consent screens — state what you will do (take a payment, read account details), not internal API names
• Mobile-first redirects — most EU customers authorise on phone; desktop-only flows hurt conversion
• Recoverable failures — insufficient funds, timeout, and user cancel need distinct messaging and retry paths
• Data retention — store only what GDPR and your use case require; verification often needs less history than affordability

These patterns are the same ones you test in open banking API integration sandboxes before production. PSD3 and the Payment Services Regulation will tighten some timelines — especially harmonised consent refresh for account data — but PSD2 rules remain operative until application dates confirmed after Official Journal publication.

How does bank coverage work in practice under PSD2?

Regulation requires interfaces; it does not guarantee every bank works for every use case on day one. Providers publish institution lists, but success rates differ by country, account type, and flow (initiation vs data). A German corporate account may behave differently from a French retail account in the same provider sandbox.

Coverage checklist for evaluation:

Question	Why it matters
Which banks cover 80% of your customer IBANs?	Concentration drives conversion more than total EU count
Does initiation work for business accounts in your markets?	Some rollouts start retail-only
Are webhooks consistent across banks?	Reconciliation depends on reliable status events
What happens when a bank API is down?	Fallback payment method or retry rules

UK teams operate under a parallel open banking regime (CMA order and UK standards) while still sharing much product vocabulary with EU PSD2 flows. Compare market-specific rules in open banking UK vs EU if you ship in both regions from one codebase.

How should you plan for PSD3 while PSD2 still applies?

Keep shipping on PSD2; run a parallel gap analysis for the PSR era — do not pause live flows for rules not yet in force. The EU's PSD3 package and Payment Services Regulation were politically agreed in 2025–2026, with formal adoption following the parliamentary calendar after the June 2026 session window. Until Official Journal publication and application deadlines pass, PSD2 remains the operative framework for certifications, contracts, and customer-facing copy.

Sensible planning steps:

• Audit provider roadmaps — ask how they track EBA technical standards on interface quality and fraud reporting
• Map consent refresh — especially if you rely on long-lived account-information feeds
• Revisit contracts — include flexibility for re-certification when banks upgrade interfaces
• Read the forward view — PSD3 open banking summarises timeline and PSR changes without replacing this present-tense PSD2 baseline

Engineering leads should treat PSD3 as an upgrade cycle on the same provider abstraction built for PSD2 — not a reason to defer pay-by-bank or verification pilots that already meet today's rules.

Frequently Asked Questions

What is PSD2 open banking?

PSD2 open banking is the EU legal framework that requires banks to provide API access for payment initiation and account information to licensed providers, with customer consent and strong authentication. It lets businesses offer pay by bank, account verification, and transaction-data features through regulated providers instead of proprietary bank integrations.

Is PSD2 still in force in 2026?

Yes. PSD2 remains the operative EU framework for open banking while the PSD3 directive and Payment Services Regulation move through adoption and transposition. Continue building and certifying against PSD2 requirements until your legal team confirms application dates for the new package in your member states.

Do merchants need a PSD2 licence to offer pay by bank?

Most merchants and platforms do not need their own licence. They integrate with a licensed payment initiation provider that holds PSD2 permissions and bank connectivity. You remain responsible for customer experience, accurate pricing, and GDPR-compliant data handling.

What is the difference between PSD2 and PSD3 open banking?

PSD2 is the current framework governing open banking APIs, consent, and licensing across the EU. PSD3 and the Payment Services Regulation update those rules — including stricter bank interface quality standards and harmonised consent refresh — on a timeline expected roughly 21 months after Official Journal publication once adoption completes. Your present-tense integrations stay valid through the transition if providers upgrade interfaces on schedule.

How does PSD2 relate to AIS and PIS?

PSD2 defines regulated access for payment initiation (moving money) and account information (reading balances and transactions). Products often start with payment initiation for checkout revenue and add account information when verification or affordability workflows require bank-sourced data. Each flow requires appropriate consent and UX.

What is an ASPSP in PSD2 open banking?

An ASPSP is the bank or payment institution that holds the customer's account and exposes the regulated interface your provider connects to. Coverage and performance depend on which ASPSPs your provider supports in each country — not on regulation alone.

How do you choose a PSD2 open banking provider?

Document one user story, list countries and banks that matter, run sandbox tests on initiation or data flows your product needs, and compare webhook reliability and support models — not only headline API pricing. When scope is written down, use structured provider matching to shortlist finalists before contract negotiation.

Conclusion

PSD2 open banking is the present-tense foundation for pay by bank, verification, and transaction-data features in EU markets — delivered through licensed providers, shaped by consent and authentication rules customers already recognise from bank apps. Map PSD2 to one outcome, validate institution-level coverage in sandbox, and keep PSD3 planning on a parallel track without delaying revenue flows that comply today. The teams that win treat regulation as context and coverage as the product decision that matters Monday morning.