PSD3 and the PSR: what changes for banks after PSD2

What PSD2 already requires

PSD2, Directive (EU) 2015/2366, has applied since January 2018. It set the rules most European payments run on.

• Strong customer authentication. Two independent factors, from knowledge, possession and inherence, when a customer logs in online, starts an electronic payment or does anything remote that carries a risk of fraud. The requirement has been enforced since September 2019.
• Open banking by law. Banks must let licensed account information and payment initiation providers reach payment accounts with the customer's consent, and must treat their requests like the customer's own.
• A dedicated interface. Most banks meet the access obligation through an API. In practice, much of Europe built those APIs on the Berlin Group NextGenPSD2 standard.
• Refunds for unauthorised payments. A payment the customer did not authorise is refunded. A payment the customer authorised under deception falls outside those rules.

What PSD3 and the PSR change

The Commission proposed the package on 28 June 2023. It splits PSD2 in two. PSD3 is a directive on licensing and supervision, and member states transpose it into national law. The Payment Services Regulation holds the conduct rules banks work with every day, and as a regulation it applies directly, in the same words, in every member state. The texts below are politically agreed. They are not yet adopted or published in the Official Journal, so details can still move in final legal revision.

• Payee name checked before every transfer. The bank checks that the payee's name matches the IBAN before a credit transfer goes out. The Instant Payments Regulation already requires this for euro transfers. The PSR extends it to credit transfers generally. According to Parliament, a mismatch means the order is refused and the payer informed.
• Liability for impersonation fraud. If a fraudster posing as a bank employee persuades a customer to approve a payment, the bank refunds the full amount, provided the customer reports it to the police and informs the bank. A transaction a fraudster initiates or changes counts as unauthorised. A bank that fails to use the required fraud prevention tools carries the loss.
• Fraud data shared between providers. Payment service providers get a legal basis to share fraud-related information with each other. Online platforms that ignore notified fraudulent content become liable to the provider that refunded the victim.
• Permission dashboards. Customers get a dashboard to see, withdraw and re-establish every data access permission they have given to third-party providers.
• Dedicated interfaces that perform. The permanent fallback interface goes, and supervisors are expected to act without delay against interfaces that miss performance standards. Banks may not discriminate against payment initiation providers.
• SCA refined and accessible. The rules clarify when SCA applies, including for merchant-initiated transactions. Authentication methods must suit customers' needs and cannot depend on a smartphone alone.
• E-money folded in. E-money institutions become a category of payment institution, and PSD3 repeals the E-Money Directive alongside PSD2.
• Access for payment institutions. Payment institutions can join designated payment systems, and a bank that refuses a payment institution an account must explain why.

The dates

Formal adoption and publication are still pending.

Both texts enter into force 20 days after publication. Under the compromise texts, most PSR rules apply 21 months later, the same deadline member states have to transpose PSD3. The extension of payee verification follows at 27 months.

Where banks get stuck

The obligations are readable. The work sits in the systems that have to prove the bank did its part.

Fraud liability meets data sharing

Liability for impersonation fraud turns prevention into a balance sheet question. To defend a claim, the bank must show which checks ran, what the customer saw and what signals it held at the moment of payment. Sharing fraud information with other providers adds a second task: deciding what can be sent, to whom, under which legal basis.

API performance under supervision

PSD2 let many banks treat the dedicated interface as a compliance project. Without a permanent fallback, the API is the only door for third-party providers, and its availability and response times become a supervisory matter. An interface that lags the bank's own app is now a finding.

Permission dashboards across the estate

Consents often live in the API gateway, while the customer's view lives in the app. A dashboard that lets customers withdraw and restore access has to read and write the same record the interface enforces, in real time, for every provider.

SCA across every channel

Authentication rarely looks the same in mobile, web, branch-assisted and corporate channels. The PSR asks for methods that suit every customer, including those without a smartphone, and consistent rules on when SCA applies. That usually means one authentication policy behind every channel.

What it takes inside the platform

Readiness for PSD3 and the PSR is a property of the payment flow from the first screen to the posting.

• Checks in the flow. Payee verification, limits, AML screening and fraud rules run before a transfer executes, so a suspect order stops inside the bank.
• Evidence for every decision. Each payment carries an audit trail of what was checked, what the customer confirmed and who acted, ready for a refund dispute.
• One consent record. The API and the customer dashboard read the same permissions, so a withdrawal takes effect everywhere at once.
• An interface run like a product. The dedicated interface is monitored for availability and performance to the same standard as the bank's own channels.
• Authentication by policy. SCA methods, including options that do not rely on a smartphone, apply consistently in every channel.

Where ABC Tech fits

The ABC Tech core runs AML screening in every module before a transaction executes and writes an audit trail on every action, so each payment decision shows who acted and under which rule. Its PSD2 interfaces are built to the Berlin Group standard. ABC Tech Digital banking carries strong customer authentication built to PSD2, with biometrics, PIN and the ABC Tech Security Token, across mobile and web for retail and business customers on one platform and any core, with mandates, multi-signature and card controls and limits executed in the core. Through ABC Tech's partner Sumsub, the bank can add fraud and device signals to those checks.