PSD2 Today, PSD3 and the PSR Tomorrow: What's Settled Law and What's Still Only Proposed?

Most payment firms are doing the regulatory equivalent of packing for a trip whose itinerary hasn't been confirmed.

PSD3 and the Payment Services Regulation are circulating in slide decks, vendor emails, and board memos as if they were already the rule. They are not. They are proposals the European Commission published in 2023. They are still moving through the EU legislative process. Nothing in them binds your firm today.

What binds your firm today is PSD2. The whole of it. And the practical risk in a regime mid-rewrite is not that you miss the new law. It is that you let the noise about the new law erode the discipline you owe under the current one.

So this piece draws one line and holds it. On one side, what PSD2 actually requires of you right now, traced to specific articles. On the other, what the Commission proposed in 2023 and what would change if it is adopted. Treat the first as obligation. Treat the second as planning input. Confusing the two is how firms end up out of compliance with the law that is actually in force.

What does PSD2 actually require of payment firms right now?

PSD2 is Directive (EU) 2015/2366. It is current, in-force law across the EU, transposed into national regimes. If you provide payment services in the Union, its obligations are live for you today.

Start with the front door. To operate as a payment institution you need authorisation, and Article 5 specifies what the application must contain. Not a vague gesture at "good governance" but a concrete list: a programme of operations, a three-year business plan, evidence of initial capital, a description of governance arrangements and internal control mechanisms, a procedure to monitor and follow up security incidents including an incident reporting mechanism, a process to file and restrict access to sensitive payment data, business continuity arrangements, and a security policy document with a detailed risk assessment. Article 5 also requires that the security and mitigation measures include those laid down in Article 95(1).

Initial capital is fixed, not negotiable, and it scales by what you do. Article 7 sets it at EUR 20 000 where you provide only money remittance, EUR 50 000 for payment initiation services, and EUR 125 000 for the core payment services in points (1) to (5) of Annex I. These are floors your capital must never fall below, not opening balances.

This is the part firms tend to underestimate: PSD2 is not primarily a payments-mechanics directive. A large share of it is an operational, security, and consumer-protection regime. That is the part that does not change just because a new proposal exists.

Which PSD2 obligations are the load-bearing ones — SCA, TPP access, incident reporting?

If you had to defend your PSD2 posture in front of a regulator tomorrow, four obligation clusters carry most of the weight.

Strong customer authentication. Article 97 requires a payment service provider to apply strong customer authentication where the payer accesses its payment account online, initiates an electronic payment transaction, or carries out any remote-channel action that may carry a risk of fraud. For electronic remote payment transactions, Article 97(2) goes further and requires authentication that dynamically links the transaction to a specific amount and a specific payee. The definition itself is in Article 4: an authentication based on two or more independent elements from the categories of knowledge, possession, and inherence, designed so that the breach of one does not compromise the others.

Operational and security risk management. Article 95 requires payment service providers to establish a framework with appropriate mitigation measures and control mechanisms to manage operational and security risks, and to maintain effective incident management procedures including detection and classification of major incidents. Article 95(2) adds an annual obligation: an updated, comprehensive assessment of those risks and of the adequacy of the controls, provided to the competent authority.

Incident reporting. Article 96 requires that, in the case of a major operational or security incident, the provider notifies the competent authority in its home Member State without undue delay. Where the incident may affect users' financial interests, the provider must also inform those users without undue delay, along with the measures they can take to mitigate the harm.

Third-party provider access. This is the open-banking machinery. Article 66 gives a payer the right to use a payment initiation service provider where the account is accessible online, and constrains both the PISP and the account servicing provider in detail: the PISP must never hold the payer's funds, must not store sensitive payment data, must not request data beyond what the service needs, and must identify itself securely on every initiation. Article 67 gives the analogous right to use an account information service provider, with its own constraints: explicit consent, access only to designated accounts, no requesting of sensitive payment data, and secure identification for each communication session.

Each of these terms — strong customer authentication, payment initiation service provider, account information service provider, operational and security risk — is a defined obligation with a defined article behind it. That is the standard your evidence has to meet.

How does PSD2 govern authorisation, safeguarding, and liability for unauthorised transactions?

Three more clusters round out the binding picture, and they are the ones most directly tied to consumer money.

Safeguarding. Article 10 requires a payment institution providing the services in points (1) to (6) of Annex I to safeguard all funds received from users or through another provider for executing payment transactions. The directive offers two routes. Either segregate the funds, never commingling them with anyone else's, depositing them by the end of the following business day in a separate account at a credit institution or investing them in secure, liquid, low-risk assets, insulated from other creditors' claims in insolvency. Or cover them with an insurance policy or comparable guarantee from an institution outside your group. Safeguarding requirements are not a footnote. They are the mechanism that protects users when a payment firm fails.

Liability for unauthorised transactions. Article 73 sets the provider's obligation plainly: in the case of an unauthorised payment transaction, the payer's provider refunds the amount immediately, and in any event no later than the end of the following business day after being notified, except where it has reasonable grounds to suspect fraud and reports those grounds to the national authority in writing. It must also restore the debited account to the state it would have been in.

The payer's exposure, and how SCA caps it. Article 74 limits the payer's own liability for losses from a lost, stolen, or misappropriated instrument to a maximum of EUR 50, with carve-outs. The provision that ties the whole security regime together is Article 74(2): where the payer's provider does not require strong customer authentication, the payer bears no financial loss unless they acted fraudulently. In other words, SCA is not just a control box to tick. Skipping it shifts the financial liability for fraud onto you.

And the technical detail underneath SCA and secure communication is not left to interpretation. Article 98 mandates regulatory technical standards, developed by the EBA, specifying the SCA requirements, the permitted exemptions, the security measures protecting users' credentials, and the common and secure open standards of communication between account servicing providers, PISPs, and AISPs. That is the legal hook for the RTS that govern how open banking actually works in practice today.

What did the Commission actually propose in 2023 — PSD3 and the PSR — and what is its status?

Here the register changes from "is" to "would."

In 2023 the European Commission published a package to revise the EU payment services framework. It has two main legislative instruments: a proposed third Payment Services Directive (PSD3) and a proposed Payment Services Regulation (PSR). The package was the Commission's response to its own review of how PSD2 performed in practice.

The structural intent is worth understanding even while the detail stays provisional. The proposal would move much of the conduct-of-business and consumer-protection content out of a directive and into a directly applicable regulation, while keeping authorisation and prudential supervision in a directive. The reasoning is that a directive has to be transposed by each Member State, which has produced uneven implementation of PSD2 across the Union. A regulation applies directly and is meant to reduce that fragmentation.

Now the part that matters most for your compliance posture: as of today this is a proposal, not law. It is still in the EU legislative process, where the text can change before adoption and again before application. No firm is obligated by PSD3 or the PSR. There is no in-force date you owe to right now. Anyone presenting specific PSD3 article numbers or a firm compliance deadline as settled is getting ahead of the legislative record. Plan against the direction of travel. Do not report against a draft.

What would change if PSD3 and the PSR are adopted, and what stays the same?

Keep the framing strict. Everything in this section is conditional. These are the themes the Commission proposed in 2023, described as intentions, not as current obligations.

If the package is adopted broadly as proposed, the direction is reinforcement rather than reversal:

→ The supervisory and conduct rules would be consolidated, with more of the consumer-facing requirements placed in a directly applicable regulation to reduce divergence between Member States.

→ The proposal signals continued and arguably strengthened emphasis on fraud prevention and strong customer authentication, building on the SCA regime PSD2 already established rather than discarding it.

→ Open-banking access for third-party providers would be retained and refined, addressing friction in the data-access arrangements that PSD2 introduced.

→ Authorisation and prudential elements would carry forward in directive form.

What stays the same is the load-bearing logic. A firm that today has genuine strong customer authentication, a working operational and security risk framework, disciplined incident reporting, sound safeguarding, and clean unauthorised-transaction handling is not building toward a regime that throws those away. It is building on the same foundations the proposal extends. The reconciliation work you do against PSD2 now is not wasted effort that a new law obsoletes. It is the substrate the proposed regime assumes you already have.

Why should you reconcile your PSD2 baseline now instead of waiting for the new regime?

Because "wait for the new law" quietly becomes "drift out of the current one."

The contrarian reading of a regime in transition is this: the transition is precisely when firms let their in-force compliance slip, on the theory that everything is about to be rewritten anyway. That theory is wrong on both counts. PSD2 is still fully enforceable today, and the proposed regime is not a clean break from it.

There is a concrete cost to deferring. If you cannot today produce, on demand, the evidence that your SCA covers every Article 97 trigger, that your Article 95 risk framework is real and assessed annually, that your Article 96 incident reporting actually fires without undue delay, and that your Article 10 safeguarding holds, then you have a present-tense exposure that no proposal protects you from. Article 74(2) makes part of that exposure financial and immediate: weak SCA shifts fraud losses onto you now, under current law, regardless of what PSD3 eventually says.

A clean PSD2 baseline is also the only honest input to PSD3 planning. You cannot assess the delta to a proposed regime if you do not have a precise, article-level map of where you stand under the current one. Gap analysis against a moving target requires a fixed starting point. The baseline is that fixed point.

How do you keep a transition-proof compliance baseline when the law is mid-rewrite?

The mechanism that survives a rewrite is the one that treats regulation as structured data rather than a static document you re-read every time the headlines change.

Here is what that looks like in practice. One organizational profile describes your firm once: what payment services you provide, where, at what scale, against what user base. From that profile, your applicable obligations are mapped deterministically against the regulation corpus, and every obligation is traced to a verbatim quote from the source legal text with article-level citation. Not a consultant's paraphrase of Article 97. Article 97 itself, linked to the control it drives.

That structure is what makes a transition survivable:

→ Your PSD2 obligations are pinned to specific articles, so "are we compliant" becomes a query against evidence, not a project that restarts every quarter.

→ When the proposed regime moves through the legislative process and is eventually adopted, you see the delta as clause-level changes against the source text. Only the obligations actually touched re-materialise. You do not re-map the entire framework from scratch.

→ Overlap with the rest of your stack — DORA's ICT risk obligations, GDPR's handling of payment data, NIS2 where it reaches — is resolved once, so you answer once and satisfy many rather than reimplementing the same control under four labels.

This is the difference between source-grounded compliance and the document-shuffling that legacy GRC calls compliance. No AI hallucinations about what PSD3 "requires," because PSD3 requires nothing yet, and the system will not assert an obligation that has no in-force source text behind it. What it gives you is a posture you can defend in front of a regulator, a board, or a plaintiff — built on the law that is actually in force, and ready for the law that is only proposed.

Answer once. Assess everything.

See your firm's current PSD2 obligations mapped to source articles, and where a proposed regime would touch them, at aegis-grc.com. Inside 60 minutes you'll see your exposure mapped to the obligations that actually apply to you. No call required.

FAQ: PSD2, PSD3, the PSR, and what's binding today

Is PSD3 in force? No. PSD3 and the Payment Services Regulation are proposals the European Commission published in 2023. They are still in the EU legislative process and bind no firm today. The in-force law for payment services in the EU is PSD2, Directive (EU) 2015/2366. There is no settled PSD3 application date to plan a compliance report against.

What is the difference between PSD3 and the PSR? They are two instruments in the same 2023 Commission package. As proposed, the directive (PSD3) would carry the authorisation and prudential supervision elements that each Member State transposes, while the regulation (PSR) would hold more of the directly applicable conduct and consumer-protection rules. The stated aim is to reduce the uneven implementation that a directive-only approach produced under PSD2. Both remain proposals until adopted.

Does strong customer authentication still apply under PSD2 today? Yes. Article 97 of PSD2 requires strong customer authentication when a payer accesses an account online, initiates an electronic payment, or takes a remote action that may carry fraud risk, with dynamic linking required for electronic remote payments under Article 97(2). Article 74(2) reinforces it financially: where a provider does not require SCA, the payer bears no loss unless they acted fraudulently. SCA is a live obligation now, independent of any future regime.

What happens to my PSD2 compliance work when PSD3 is adopted? On the proposed direction of travel, it is extended rather than discarded. The proposals build on PSD2's SCA, fraud-prevention, open-banking, and supervisory foundations. A firm with a clean, article-grounded PSD2 baseline holds the fixed starting point any PSD3 gap analysis needs. The reconciliation you do now is the substrate the proposed regime assumes, not throwaway work.