PSD2 Explained: SCA, 3DS, Open Banking, and PSD3

PSD2 explained: an overview of EU payment rules

PSD2 is the second Payment Services Directive. It replaced the first PSD framework across the European Union. The psd2 directive aimed to make payments safer, fairer, and more open.

The eu psd2 framework covers banks, payment firms, merchants, and users. It applies to many electronic payments across the European Economic Area. Each country places the directive into local law.

PSD2 also supports open banking. Approved firms can access bank accounts with user consent. They can then start payments or show account data.

The EU PSD2 directive sets the main legal rules. National regulators handle local oversight and enforcement.

• Safer online payments
• More choice among payment firms
• Clearer rights for payment users
• Secure access to bank account data

The law does not force every provider to use one payment journey. It sets a shared floor. Providers can build different services above that floor.

Why PSD2 matters to merchants and users

PSD2 addressed gaps in older payment rules. Online shopping had grown fast. Mobile payments and new bank services also needed clear rules.

Its main goals include payment security, market competition, and consumer protection. The law also supports new services around bank accounts. This can give users more ways to pay.

Merchants face practical changes under PSD2. They must review checkout flows, payment data, and refund steps. They also need clear records for disputes and failed checks.

Users gain stronger rights when payments go wrong. They receive more information about fees and payment timing. They can also report unauthorised payments through their provider.

PSD2 does not remove all payment risk. It shifts more risk toward firms with weak controls. Good payment design still matters.

Area	What changes
Security	Many online payments need two-factor checks
Competition	Approved firms can build services around bank accounts
Consumer rights	Users gain clearer refund and dispute rights
Access	Banks must support safe access for approved providers

PSD2 SCA requirements and payment checks

Strong Customer Authentication, or SCA, is central to PSD2. It applies to many online payments and account actions. The psd2 and sca rules seek to stop account theft.

SCA uses at least two separate proof types. These types come from knowledge, possession, and inherence. A password shows knowledge. A phone shows possession. A fingerprint shows inherence.

The factors must work independently. A stolen password should not unlock every other factor. The check may also link to the payee and payment amount.

Factor	Example	Risk point
Knowledge	Password or passcode	It can be guessed or stolen
Possession	Phone or security key	The device can be lost
Inherence	Fingerprint or face scan	Biometric checks need care

What is PSD2 SCA in practice? It is a risk check before a payment goes through. The bank or payment firm decides how to run it.

PSD2 SCA compliance needs more than a login screen. Firms must map each payment path. They must test failed checks and keep proof of each decision.

Some payments may qualify for PSD2 SCA exemptions. Low-value payments can qualify in set cases. Trusted payees may also qualify. Low-risk checks can support another exemption.

The provider makes the final choice. A merchant cannot assume that every payment will avoid SCA. The payment flow must handle both approval and challenge.

3-D Secure adds a card check for online payments. In 3ds psd2 terms, it helps banks support SCA during card checkout. 3ds2 psd2 flows can send more data for risk checks.

Many merchants call this psd2 3d secure or psd2 3ds. A bank may approve a low-risk payment without a prompt. A higher-risk payment may ask the user for another factor.

3DS, recurring payments, and merchant-initiated transactions

Card payments need careful flow design under PSD2. The first payment may need a user check. Later charges can follow a different path.

Merchant initiated transactions PSD2 rules can apply to later charges. These charges happen without the user taking part at that moment. The first payment often sets the terms and gains user approval.

Examples include a saved card charge or a fixed subscription payment. The merchant must keep a link to the first approved payment. The bank still decides whether to accept the charge.

Merchants should not label every repeat charge as merchant initiated. A new amount, payee, or payment setup may need fresh user action. The payment firm can explain the right code for each flow.

• Mark the first payment and later charges clearly
• Keep records of user approval
• Send the right payment data to the bank
• Handle a new SCA request when risk changes

Implementing PSD2 starts with a payment flow map. List one-off payments, subscriptions, refunds, and account actions. Then match each flow with its likely SCA path.

Good testing should include lost devices and failed challenges. It should also cover bank declines and expired approvals. Clear fallback steps reduce lost sales.

Third-party providers and open banking

PSD2 lets approved third-party providers connect to bank accounts. These firms need the right licence or an approved agent link. National regulators check their status and conduct.

Payment initiation services can start bank payments for users. Account information services can show data from several banks. Both services need clear user consent.

The bank must not block a valid request without a sound reason. The provider must protect data and limit access. Users should know what data they share and for how long.

APIs, or application programming interfaces, help these firms connect. Secure APIs support data sharing between systems. Weak access controls can expose account data.

• Check the provider's legal status
• Read the access scope before consent
• Review the consent period
• Remove access when it is no longer needed

Marketplaces need extra care. A marketplace may collect funds, split payments, and pay sellers. It must know which firm holds each payment role.

The psd2 marketplaces question often turns on control and flow. The legal answer depends on the service model. A payment partner can help define duties.

Consumer protection under PSD2

PSD2 gives users stronger protection against unauthorised payments. In many cases, the provider must refund the amount quickly. The user should report the payment without undue delay.

A provider may refuse a refund after fraud or serious user carelessness. It must show facts that support its claim. Local law may add further rights.

Users should check account alerts often. They should report unknown payments at once. Fast notice can limit further loss.

Providers must give key payment details in a clear form. These details can include fees, timing, and exchange rates. Clear terms help users spot errors.

Merchants also need a sound refund process. A refund does not replace the rules for an unauthorised payment. Teams should keep both paths separate.

PSD2 RTS and regulatory duties

Regulatory Technical Standards, or RTS, add detail to the main law. The psd2 regulatory technical standards cover secure checks and communication. They help turn broad rules into working controls.

The psd2 rts framework supports secure customer checks. It also sets rules for communication between banks and third parties. Providers must show that their controls work in practice.

The European Banking Authority RTS guidance gives a trusted view of these rules. Firms should compare its guidance with local regulator notices.

Implementing PSD2 requires named owners and clear records. Teams should track payment paths, exemptions, and challenge results. They should review changes when banks or payment tools change.

1. Map each payment and account flow
2. Assign the right SCA treatment
3. Test exemptions and fallback paths
4. Keep evidence for each decision
5. Review local regulator guidance

PSD2 date, deadline, and future PSD3 changes

The original PSD2 date was 13 January 2018. EU states needed local laws by then. SCA rules took effect later through staged national enforcement.

There was no single PSD2 deadline for every merchant. The timing varied by country, provider, and payment type. Merchants should check their local regulator and payment partner.

PSD3 is being developed as a later update to the payment rule set. The EU plans stronger fraud controls and more consistent supervision. The final shape and start date can change during the law process.

Firms should treat PSD3 as a planning issue, not a reason to delay PSD2 work. Clean payment maps and good records will still help. Strong access controls will also remain useful.

This PSD2 summary gives the main answer. The law affects security, access, refunds, and payment design. Each firm must match its flow to the rules that apply.