PSD2 is the European Union’s revised Payment Services Directive, and it changed digital payments by combining stronger security rules with regulated access to bank accounts for licensed third parties. It is one of the most important regulations behind modern “open banking” in Europe. For banks, fintechs, merchants, analysts, and students, PSD2 matters because it affects competition, customer experience, fraud control, compliance, and payment economics.

1. Term Overview

• Official Term: PSD2
• Full Name: Revised Payment Services Directive / Second Payment Services Directive
• Common Synonyms: EU PSD2, Revised PSD, Payment Services Directive 2
• Alternate Spellings / Variants: PSD II, Directive (EU) 2015/2366, Payment Services Directive 2
• Domain / Subdomain: Finance / Government Policy, Regulation, and Standards
• One-line definition: PSD2 is an EU payments regulation that governs payment services, customer rights, security standards, and regulated third-party access to payment accounts.
• Plain-English definition: PSD2 is a rulebook that tells banks, payment firms, and fintechs how electronic payments should work more safely and more competitively, especially when customers want apps or other providers to access their bank data or start payments from their accounts.
• Why this term matters:
• It is central to European digital payments.
• It created the regulatory foundation for much of open banking.
• It introduced Strong Customer Authentication, or SCA.
• It affects banks, merchants, fintechs, payment processors, and consumers.
• It influences costs, fraud controls, API strategy, and business models.

2. Core Meaning

At its core, PSD2 is about making payments safer, more transparent, and more competitive.

Before rules like PSD2, banks often controlled customer account access more tightly, payment services were less standardized across Europe, and digital innovation could be slowed by fragmented national practices. PSD2 tried to solve that by updating the older payments framework for an era of smartphones, e-commerce, APIs, and fintechs.

What it is

PSD2 is a regulatory framework for payment services in the EU. It sets rules for:

• payment institutions and certain other payment service providers
• customer rights and information disclosures
• security and authentication standards
• access to payment accounts by licensed third parties
• supervisory and compliance obligations

Why it exists

PSD2 exists to address several policy goals at once:

• improve consumer protection
• reduce fraud in electronic payments
• encourage innovation in payments
• increase competition against incumbent banks
• create a more harmonized payments market across Europe

What problem it solves

PSD2 addresses problems such as:

• inconsistent payment rules across countries
• weak or uneven electronic payment security
• bank control over customer account data and payment initiation
• limited competition in payment services
• poor transparency around charges, rights, and liability

Who uses it

PSD2 is relevant to:

• banks
• payment institutions
• e-money institutions
• fintechs
• merchants
• API providers
• regulators
• treasury teams
• investors analyzing banks and fintechs
• students and candidates preparing for finance or compliance interviews

Where it appears in practice

You see PSD2 in practice when:

• a budgeting app connects to your bank account
• an online merchant offers bank-to-bank checkout
• a bank asks for two-factor authentication during payment
• a fintech applies for authorization as an AISP or PISP
• a regulator reviews a firm’s operational security or incident reporting

3. Detailed Definition

Formal definition

PSD2 is the Second Payment Services Directive of the European Union, officially adopted as Directive (EU) 2015/2366, which revised the earlier payments framework and set rules for payment services in the internal market.

Technical definition

Technically, PSD2 is a market conduct and operational rulebook for payment services. It defines:

• categories of payment services
• licensing and authorization expectations for certain providers
• rights and obligations of payment service users and providers
• access-to-account rules for licensed third-party providers
• security requirements, especially SCA and secure communication
• supervisory and reporting expectations

Operational definition

Operationally, PSD2 means that firms in scope must be able to answer questions like:

• Are we a regulated payment service provider?
• Do we need authorization or registration?
• Are we an account-servicing PSP, such as a bank holding customer payment accounts?
• Must we provide API access to licensed third parties?
• Are we applying SCA correctly?
• Are our fraud, authentication, complaints, and incident controls compliant?

Context-specific definitions

EU / EEA context

In the EU and wider EEA implementation context, PSD2 is a legally important payments directive that national laws transpose and supervisors enforce.

UK context

In the UK, PSD2 concepts continue through the local post-Brexit legal and supervisory framework, but the UK’s open banking ecosystem also depends heavily on separate competition remedies and local regulatory architecture. In other words, UK open banking is related to PSD2-style ideas, but not identical to EU PSD2 in a simple one-to-one way.

Global usage

Globally, people often use “PSD2” as shorthand for regulated open banking plus strong payment authentication. That broader usage is informal. Outside Europe, many jurisdictions have similar goals but not PSD2 itself.

4. Etymology / Origin / Historical Background

“PSD” stands for Payment Services Directive. The “2” means it is the second major version of that EU framework.

Historical development

1. PSD1 era

The first Payment Services Directive aimed to create a more integrated European payments market and set baseline rights and obligations for payment services.

2. Rise of digital payments and fintech

As mobile banking, online commerce, app-based finance, and new payment startups grew, PSD1 became too narrow. It did not fully reflect:

• smartphone-era customer behavior
• fintech innovation
• API-based services
• growing cyber and fraud risks
• demand for easier cross-bank access

3. PSD2 adoption

PSD2 was adopted in 2015 to modernize the rules.

4. National implementation

EU member states transposed PSD2 into national law, with the main application phase beginning in 2018.

5. SCA and secure communication standards

A major milestone came with the Regulatory Technical Standards on Strong Customer Authentication and secure communication, which made PSD2 much more concrete in day-to-day implementation.

6. Open banking era

Over time, PSD2 became widely associated with:

• account aggregation apps
• payment initiation services
• bank APIs
• embedded finance
• account-to-account payment models

How usage changed over time

Originally, people discussed PSD2 mainly as a payments directive. Later, it became popularly known as the regulation behind open banking. Today, professionals often discuss PSD2 in relation to:

• API quality
• fintech competition
• fraud prevention
• customer experience
• the future transition toward newer EU payment reforms

Important milestones

Milestone	Significance
PSD1	First EU-wide payment services framework
PSD2 adoption	Updated rules for digital payments and competition
National transposition	Practical legal effect across member states
SCA RTS implementation	Stronger security and concrete technical requirements
Open banking rollout	Banks and TPPs moved from concept to live APIs and services
PSD3 / PSR proposals	Signal that the framework is still evolving

Caution: The future relationship between PSD2 and later EU reforms should always be verified using the latest official legal status in your jurisdiction.

5. Conceptual Breakdown

PSD2 is easier to understand if you break it into its main building blocks.

Scope and regulated actors

• Meaning: PSD2 defines who is in scope and what counts as a payment service.
• Role: It determines which firms need authorization, registration, or compliance systems.
• Interactions: This connects to licensing, reporting, security, and customer rights.
• Practical importance: A firm must know whether it is a bank, payment institution, e-money institution, AISP, PISP, or another regulated entity.

Payment service users and payment service providers

• Meaning: PSD2 distinguishes between customers using services and firms providing them.
• Role: It allocates rights, obligations, and liability.
• Interactions: Consumer protection rules depend on whether the customer is a payer, payee, consumer, or business user.
• Practical importance: Contracts, complaints handling, and dispute processes depend on these definitions.

Account-servicing PSPs and third-party providers

• Meaning: The bank or institution holding the payment account is often called the ASPSP. Third-party providers include firms such as AISPs and PISPs.
• Role: PSD2 requires regulated access between these parties when the customer consents and the request is in scope.
• Interactions: This is where APIs, authentication, consent, and secure communication all meet.
• Practical importance: It is the operational heart of PSD2-driven open banking.

AISP: Account Information Service Provider

• Meaning: An AISP accesses account information, with permission, to show balances, transaction history, and related data.
• Role: It enables services such as personal finance management, multi-bank dashboards, and cash flow tools.
• Interactions: AISPs rely on ASPSP interfaces and customer consent.
• Practical importance: AISPs cannot simply “scrape” data without regard to rules; they operate as regulated participants.

PISP: Payment Initiation Service Provider

• Meaning: A PISP initiates a payment from the customer’s bank account to a merchant or recipient.
• Role: It creates an alternative to some card-based or wallet-based flows.
• Interactions: PIS relies on bank connectivity, SCA, customer approval, and secure messaging.
• Practical importance: Merchants may use PIS to reduce costs, improve settlement visibility, or support account-to-account payments.

Strong Customer Authentication (SCA)

• Meaning: SCA generally requires authentication using at least two independent elements from:
• knowledge: something the user knows
• possession: something the user has
• inherence: something the user is
• Role: It reduces fraud in electronic payments and account access.
• Interactions: SCA is central to payment initiation, account access, exemptions, and customer experience.
• Practical importance: If poorly implemented, it increases checkout friction; if properly implemented, it improves security without destroying conversion.

Secure communication and APIs

• Meaning: PSD2 pushed institutions toward secure interfaces for third-party access, typically APIs.
• Role: APIs replace or reduce dependence on less reliable access methods.
• Interactions: API performance affects AISP uptime, PISP conversion, consent flows, and complaints.
• Practical importance: “Compliance done badly” often shows up as unstable APIs, poor developer support, and weak service quality.

Customer rights and transparency

• Meaning: PSD2 requires clearer information on fees, execution, and rights.
• Role: It strengthens trust and dispute handling.
• Interactions: These rules connect with unauthorized transaction handling, complaints, and refunds in relevant cases.
• Practical importance: Legal wording, onboarding screens, and transaction disclosures matter.

Security, incident management, and operational risk

• Meaning: PSD2 is not just about customer-facing rules; it also addresses operational security.
• Role: Firms must manage security incidents, authentication controls, and service continuity.
• Interactions: This overlaps with cyber risk, fraud monitoring, governance, and supervisory reporting.
• Practical importance: For a bank or fintech, PSD2 is both a product rule and a control framework.

Liability and disputes

• Meaning: PSD2 helps determine who bears responsibility when a payment is unauthorized or goes wrong.
• Role: It protects users while setting obligations for providers.
• Interactions: Liability often depends on whether authentication was properly applied and whether the customer acted fraudulently or with gross negligence.
• Practical importance: Legal teams, operations teams, and customer service teams all need PSD2 literacy.

6. Related Terms and Distinctions

Related Term	Relationship to Main Term	Key Difference	Common Confusion
PSD1	Earlier version of the same regulatory family	PSD1 was the original framework; PSD2 expanded scope, security, and third-party access	People think PSD2 is totally new rather than a revision
Open Banking	Practical ecosystem often associated with PSD2	Open banking is broader than PSD2 and may also come from competition law or local standards	Many assume PSD2 and open banking are identical
SCA	Major requirement under PSD2	SCA is one part of PSD2, not the whole regulation	People use “PSD2” when they really mean “SCA”
AISP	Regulated role created/recognized under PSD2	AISPs access account data but do not initiate payments	Often confused with PISPs
PISP	Regulated role under PSD2	PISPs initiate payments; they are not simply data aggregators	Often confused with AISPs
ASPSP	Bank/account provider in PSD2 ecosystem	The ASPSP holds the payment account and exposes access in scope	Some think only fintechs are regulated under PSD2
SEPA	European payments infrastructure / scheme environment	SEPA concerns payment scheme standardization; PSD2 is a legal/regulatory framework	People treat SEPA and PSD2 as the same thing
PCI DSS	Card data security standard	PCI DSS is an industry security standard, not an EU payments directive	Security obligations under PSD2 are mistaken for PCI rules
GDPR	EU data protection law	GDPR governs personal data protection; PSD2 governs payment services and account access	PSD2 “consent” is often wrongly treated as the same as GDPR consent in every respect
PSD3 / PSR	Proposed or evolving successor reforms	They aim to update or replace parts of PSD2 architecture	People may assume PSD2 has already disappeared everywhere
UK Open Banking	UK implementation ecosystem related to PSD2-style goals	UK open banking also relies on CMA remedies and domestic governance	Many assume UK and EU frameworks are identical
Account Aggregation	A use case under or enabled by PSD2	Aggregation is an application, not the regulation itself	The app experience is confused with the legal framework

7. Where It Is Used

PSD2 is not relevant in every finance subfield equally. It is strongest in payments, banking, fintech, and regulation.

Finance

PSD2 appears in financial services strategy, fintech business models, payment economics, digital onboarding, and fraud governance.

Banking / Lending

Banks must manage:

• API access for regulated third parties
• account access authentication
• fraud controls
• customer complaints
• operational resilience in payment channels

Lenders and digital credit providers may also use PSD2-based account data, where permitted, to improve cash flow analysis and affordability checks.

Policy / Regulation

This is PSD2’s main home. It is a regulatory framework used by:

• ministries and legislatures
• financial conduct regulators
• central banks or competent authorities
• competition and market-structure analysts

Business operations

Businesses encounter PSD2 when they:

• accept online payments
• connect ERP or treasury systems to bank data
• automate reconciliation
• use account-to-account checkout flows
• manage payment fraud and checkout conversion

Reporting / Disclosures

PSD2 affects:

• terms and conditions
• customer disclosures
• complaints data
• incident reporting
• internal compliance reports
• control documentation

Analytics / Research

Researchers and analysts study PSD2 through:

• fraud trends
• API uptime
• payment method conversion
• fintech adoption
• market competition effects
• bank and fintech earnings implications

Stock market / Investing

Listed banks, processors, and fintech firms may be affected by PSD2 through:

• payment-margin pressure
• infrastructure spending
• API and compliance costs
• new revenue models
• better or worse customer retention
• open banking adoption trends

Accounting

PSD2 is not an accounting standard. However, it affects accounting indirectly through:

• payment fee expense analysis
• dispute provisioning
• transaction reconciliation
• compliance cost allocation
• treasury cash visibility

8. Use Cases

Title	Who is using it	Objective	How the term is applied	Expected outcome	Risks / Limitations
Personal finance aggregation app	Fintech AISP	Show all bank accounts in one place	Accesses account data with customer permission through regulated connectivity	Better money management and customer convenience	Consent expiry, API downtime, privacy concerns
Bank-to-bank e-commerce checkout	Merchant and PISP	Offer lower-cost payment option	PISP initiates payment directly from customer account	Potentially lower acceptance cost and faster confirmation	Conversion friction, bank coverage gaps, customer trust issues
Fraud reduction in online payments	Bank or merchant PSP	Reduce unauthorized payment risk	Applies SCA and transaction risk controls	Lower fraud losses and stronger compliance posture	Poor UX can reduce sales
Corporate cash management dashboard	Treasury platform or bank	Consolidate balances across banks	Uses permitted account-information connectivity for visibility	Better liquidity planning and reconciliation	Data latency, multi-country complexity
Credit or underwriting support	Lender or fintech	Improve financial analysis	Uses customer-authorized account data for income/cash flow review	Better risk assessment	Legal basis, data quality, fairness concerns
Open-banking product strategy	Retail bank	Retain customers and stay competitive	Builds APIs, consent journeys, and partner channels	New ecosystem revenue and better customer engagement	Compliance cost and partner risk

9. Real-World Scenarios

A. Beginner scenario

• Background: A customer uses a budgeting app and wants to see two bank accounts in one dashboard.
• Problem: The app cannot legally and safely access the bank data without a proper framework.
• Application of the term: Under PSD2, a licensed AISP can access account information if the customer gives the required permission and the bank provides compliant access.
• Decision taken: The customer authorizes the connection through the bank’s authentication flow.
• Result: The app can display balances and transactions from both accounts.
• Lesson learned: PSD2 helps customers use third-party financial tools without giving away bank passwords informally.

B. Business scenario

• Background: An online retailer wants to reduce payment processing costs.
• Problem: Card acceptance is reliable but expensive, and settlement visibility is limited.
• Application of the term: The retailer adds a PISP-powered bank payment option under PSD2-style open banking connectivity.
• Decision taken: It offers the method as an alternative at checkout and improves SCA messaging.
• Result: Some customers switch to account-to-account payments, reducing average payment costs.
• Lesson learned: PSD2 can create business value, but only if user experience is well designed.

C. Investor / market scenario

• Background: An equity analyst is valuing a listed European payments company.
• Problem: The analyst must decide whether open-banking payments are a threat or an opportunity.
• Application of the term: The analyst studies PSD2-related trends such as PIS adoption, API quality, fraud costs, and merchant acceptance.
• Decision taken: The analyst adjusts revenue-growth assumptions and margin outlook based on likely payment mix changes.
• Result: The valuation model better reflects structural industry change.
• Lesson learned: PSD2 is not just a compliance issue; it can alter competitive dynamics and equity narratives.

D. Policy / government / regulatory scenario

• Background: A national regulator sees rising complaints about account-access failures.
• Problem: Consumers cannot reliably use licensed third-party apps across several banks.
• Application of the term: The regulator reviews whether ASPSPs are providing secure and effective access as required and whether incident management is adequate.
• Decision taken: Supervisory scrutiny increases, and remediation plans are demanded.
• Result: API reliability improves over time.
• Lesson learned: PSD2 enforcement quality matters as much as the text of the law.

E. Advanced professional scenario

• Background: A multi-country bank operates in several EU markets and partners with fintechs.
• Problem: It has different local API implementations, uneven SCA outcomes, and rising support costs.
• Application of the term: The bank performs a PSD2 operating-model review covering access flows, authentication orchestration, incident reporting, and consent management.
• Decision taken: It standardizes API governance, upgrades authentication logic, and creates common KPIs.
• Result: Better compliance, lower error rates, improved partner satisfaction, and fewer operational escalations.
• Lesson learned: PSD2 excellence requires legal, technical, product, and risk teams to work together.

10. Worked Examples

Simple conceptual example

A customer wants a personal finance app to read transaction data from a bank account.

1. The app is a licensed or properly registered account-information provider.
2. The customer chooses to connect the bank account.
3. The bank authenticates the customer.
4. The customer authorizes access.
5. The app receives permitted account information.

Key point: PSD2 makes this access regulated and structured rather than informal or opaque.

Practical business example

A merchant wants an alternative to card checkout.

1. It integrates a PISP.
2. At checkout, the customer selects “Pay from bank.”
3. The customer is authenticated by the bank.
4. The payment is initiated from the bank account.
5. The merchant receives payment confirmation and fulfills the order.

Business effect: The merchant may gain lower fees or better bank-payment visibility, but success depends on smooth user experience.

Numerical example

A merchant processes 20,000 online orders per month with an average order value of €40.

Option 1: Card-only model

• Card fee = 1.7% of order value + €0.15
• Fee per order = ( €40 \times 1.7\% ) + €0.15
• Fee per order = ( €0.68 + €0.15 = €0.83 )

Total monthly card cost:

• ( 20,000 \times €0.83 = €16,600 )

Option 2: Mixed model with PSD2-enabled PIS

Assume:

• 30% of orders shift to PIS
• PIS fee = €0.35 per transaction
• Remaining 70% stay on cards

PIS orders:

• ( 20,000 \times 30\% = 6,000 )

Card orders:

• ( 20,000 – 6,000 = 14,000 )

PIS cost:

• ( 6,000 \times €0.35 = €2,100 )

Card cost for remaining orders:

• ( 14,000 \times €0.83 = €11,620 )

Total mixed monthly cost:

• ( €2,100 + €11,620 = €13,720 )

Monthly savings:

• ( €16,600 – €13,720 = €2,880 )

Interpretation: If customers adopt the bank-payment option, the merchant could save €2,880 per month in this simplified example.

Caution: Actual economics depend on provider pricing, refunds, fraud, conversion rates, dispute costs, and geography.

Advanced example

A bank monitors API performance for third-party access over a 30-day month.

• Total minutes in month = 43,200
• Downtime = 130 minutes

API availability:

• ( \frac{43,200 – 130}{43,200} \times 100 = 99.70\% )

Now assume:

• 500,000 API requests
• 482,500 successful responses

Success rate:

• ( \frac{482,500}{500,000} \times 100 = 96.5\% )

Interpretation: Availability may look strong, but a 96.5% success rate might still create real customer friction for AISPs and PISPs. Compliance is not just “system up or down”; it is also about effective service quality.

11. Formula / Model / Methodology

PSD2 itself is not a financial ratio or formula. It is a regulatory framework. However, firms often use operational metrics and decision models to manage PSD2 compliance and commercial performance.

Key operating metrics

Formula Name	Formula	Meaning of Variables	Interpretation	Sample Calculation	Common Mistakes	Limitations
API Availability	( \frac{\text{Total Time} – \text{Downtime}}{\text{Total Time}} \times 100 )	Total Time = period measured; Downtime = unavailable time	Higher is better	( \frac{43,200-130}{43,200}\times100 = 99.70\% )	Ignoring degraded service that is not full downtime	Availability alone does not show user experience
Payment Initiation Success Rate	( \frac{\text{Successful PIS Transactions}}{\text{Initiated PIS Transactions}} \times 100 )	Successful = completed/confirmed; Initiated = attempted	Measures operational checkout quality	( \frac{9,300}{10,000}\times100 = 93\% )	Counting retries as new failures without context	Does not show why failures happen
SCA Abandonment Rate	( \frac{\text{Abandoned During Authentication}}{\text{Transactions Challenged}} \times 100 )	Abandoned = customer drops off; Challenged = sent to auth step	Lower is generally better	( \frac{1,200}{8,000}\times100 = 15\% )	Blaming SCA for issues caused by poor checkout design	Some industries naturally see different rates
Fraud Loss Rate	( \frac{\text{Fraud Loss Value}}{\text{Transaction Value}} \times 100 )	Fraud Loss Value = value lost to fraud; Transaction Value = total processed value	Lower is better, but compare by channel	( \frac{24,000}{12,000,000}\times100 = 0.20\% )	Mixing attempted fraud with actual loss	Must be segmented by channel and use case
Payment Cost Savings	Old Cost – New Cost	Old Cost = prior payment cost; New Cost = revised cost	Positive value means savings	€16,600 – €13,720 = €2,880	Ignoring conversion loss or refunds	Commercial, not legal, measure

Analytical method for PSD2 readiness

If you are not calculating a ratio, a good PSD2 methodology is:

1. Identify role in ecosystem – bank / ASPSP – AISP – PISP – merchant using a provider – software platform
2. Map regulated activities – account access – payment initiation – customer authentication – complaint handling
3. Assess control environment – security – consent – API performance – incident reporting
4. Measure customer outcomes – success rate – drop-off – complaints – fraud
5. Review legal and supervisory alignment – national law – regulator guidance – current implementation status

12. Algorithms / Analytical Patterns / Decision Logic

PSD2 is mostly a rules-and-controls framework, not an algorithmic trading or chart-pattern concept. Still, several decision frameworks are highly relevant.

SCA decision tree

• What it is: A logic flow that checks whether a transaction or account access event requires SCA, is out of scope, or may qualify for an exemption.
• Why it matters: It balances fraud control and customer convenience.
• When to use it: In payment orchestration, checkout design, and fraud-rule engines.
• Limitations: Exemptions are technical and supervisory treatment can vary; firms must verify current rules.

Typical logic:

1. Is the event in PSD2 scope?
2. Is it account access or payment initiation?
3. Is it out of scope or exempt?
4. If not, apply SCA.
5. Log evidence and monitor performance.

Consent lifecycle framework

• What it is: A process for issuing, storing, refreshing, and revoking account-access consent.
• Why it matters: Poor consent handling creates legal, UX, and operational risk.
• When to use it: AISP and data aggregation services.
• Limitations: Customer permission under PSD2 must also be handled consistently with data-protection obligations.

Typical stages:

1. capture customer intent
2. authenticate customer
3. record scope and duration
4. access only permitted data
5. renew or expire access
6. support revocation and audit trails

TPP onboarding and access control logic

• What it is: A bank’s process for verifying whether a third party is properly authorized or registered and technically eligible for access.
• Why it matters: It prevents unauthorized entities from using PSD2 interfaces.
• When to use it: ASPSP gateway management and partner access control.
• Limitations: Registry checks, certificate management, and local supervisory requirements can be operationally complex.

Incident triage framework

• What it is: A way to classify PSD2-related outages, fraud spikes, authentication issues, or access failures.
• Why it matters: Regulatory incidents may require escalation and reporting.
• When to use it: Operational risk, compliance, and cyber response teams.
• Limitations: Severity definitions vary by organization and applicable guidance.

13. Regulatory / Government / Policy Context

PSD2 is fundamentally a regulatory topic, so this section is central.

EU / EEA core framework

PSD2 is an EU directive that member states transpose into national law. In practice, this means:

• the high-level framework is European
• the legal form in force is usually national legislation implementing PSD2
• supervision is carried out by national competent authorities
• European-level bodies, including the EBA, shape technical standards and guidance

Major regulatory themes under PSD2

Licensing and authorization

Certain firms providing payment services, account information services, or payment initiation services may need authorization or registration, depending on the activity and jurisdictional details.

Access to accounts

Banks or other account-servicing PSPs must enable properly regulated third parties to access in-scope payment accounts, with customer permission and secure communication.

Strong Customer Authentication

SCA is one of PSD2’s most visible requirements. It generally requires at least two independent authentication elements, and remote electronic payments often require additional protections such as dynamic linking.

Consumer protection

PSD2 addresses:

• information disclosures
• execution and charges transparency
• complaint handling
• unauthorized transaction treatment
• rights and responsibilities of payment users and providers

Operational and security risk

Firms are expected to maintain sound security controls and manage incidents.

Regulators and institutions involved

Depending on country and structure, PSD2 may involve:

• central banks
• financial conduct regulators
• prudential supervisors
• data protection authorities
• competition authorities in adjacent open-banking questions

UK position

After Brexit, the UK retained and adapted parts of the PSD2-style payments framework through domestic law and supervision. However, UK open banking is also shaped by separate competition remedies and domestic institutions. So:

• the UK remains highly relevant in PSD2-style discussions
• but the EU and UK frameworks should not be treated as identical

EU reform path beyond PSD2

The EU has been working toward a newer package commonly discussed as PSD3 and a Payment Services Regulation. Their purpose is broadly to fix weaknesses seen under PSD2, reduce fragmentation, and update fraud, data, and open-banking rules.

Important: Verify the current legal status, transition timetable, and applicability in your jurisdiction before relying on any PSD2 summary.

US comparison

The US does not have PSD2. It has a different legal structure with more fragmented federal and state oversight, card-network significance, bank-fintech contracting models, and evolving consumer-data-rights developments.

India comparison

India does not use PSD2, but it has achieved some similar functional outcomes through a different architecture, including:

• RBI-led payment regulation
• UPI ecosystem development
• Account Aggregator framework for consent-based data sharing
• strong local digital identity and payment rails

Taxation angle

PSD2 is not primarily a tax framework. Any tax impact is indirect, such as:

• treatment of payment fees
• compliance cost deductibility
• cross-border service structuring

Tax analysis should be verified separately.

Accounting standards angle

PSD2 is not an accounting standard like IFRS or Ind AS. Its accounting relevance is indirect through fee classification, provisions for disputes, compliance spend, and system implementation cost treatment.

Public policy impact

PSD2 is important because it tries to balance:

• innovation
• competition
• consumer protection
• cyber resilience
• data control
• market integration

14. Stakeholder Perspective

Student

A student should view PSD2 as a landmark payments regulation linking law, technology, and banking. For exams, understand the big ideas: open banking, AISP/PISP, SCA, customer rights, and market competition.

Business owner / merchant

A merchant sees PSD2 as both a compliance influence and a commercial opportunity. It can affect checkout flows, payment costs, customer authentication friction, and bank-payment options.

Accountant / finance controller

An accountant cares less about the legal theory and more about practical effects:

• payment fee analysis
• reconciliation quality
• dispute handling
• cash visibility
• controls over payment-related data and systems

Investor

An investor looks at PSD2 through strategy and valuation:

• Will banks lose payment margins?
• Will fintechs gain market share?
• Is account-to-account payment adoption improving?
• Are fraud and compliance costs rising or falling?

Banker / lender

A bank sees PSD2 as a structural shift. It creates:

• compliance cost
• operational burden
• cybersecurity obligations
• partnership opportunities
• pressure to modernize infrastructure

A lender may also use PSD2-enabled data for credit analysis, where permitted.

Analyst

A payments or equity analyst uses PSD2 to assess:

• business-model durability
• unit economics
• customer acquisition
• conversion rates
• API quality
• regulatory risk

Policymaker / regulator

A policymaker sees PSD2 as an instrument for:

• market integration
• competition policy
• innovation
• consumer protection
• system security

15. Benefits, Importance, and Strategic Value

Why it is important

PSD2 matters because it changed the structure of digital payments in Europe. It is one of the clearest examples of regulation creating both compliance obligations and new business opportunities.

Value to decision-making

PSD2 helps firms make better decisions about:

• payment-method strategy
• authentication design
• fintech partnerships
• customer data flows
• fraud controls
• product roadmaps

Impact on planning

Banks and fintechs must plan for:

• authorization
• API architecture
• operational resilience
• legal documentation
• customer communication
• incident governance

Impact on performance

Commercially, PSD2 can improve:

• payment acceptance choices
• bank-data access
• product innovation
• customer convenience
• cash visibility

But it can also hurt performance if implementation is poor.

Impact on compliance

PSD2 makes firms formalize:

• roles and permissions
• security controls
• authentication flows
• access logging
• complaints handling
• third-party access management

Impact on risk management

Good PSD2 implementation improves:

• fraud prevention
• security oversight
• access control
• auditability
• accountability

16. Risks, Limitations, and Criticisms

Common weaknesses

• uneven API quality across institutions
• inconsistent implementation across countries
• customer confusion during authentication
• operational failures in third-party access
• legal complexity around consent and data use

Practical limitations

PSD2 does not automatically guarantee:

• smooth user experience
• instant innovation
• zero fraud
• perfect interoperability
• equal adoption across all banks and merchants

Misuse cases

• treating PSD2 as a marketing label without true compliance
• overcollecting data beyond service need
• pushing bank-payment methods without customer trust or UX readiness
• misclassifying services to avoid regulation

Misleading interpretations

A common mistake is to think PSD2 means “banks must share everything with everyone.” That is false. Access is limited, regulated, and dependent on permissions, scope, and lawful operation.

Edge cases

Edge cases include:

• corporate accounts and specialized payment flows
• cross-border service models
• exemptions and out-of-scope scenarios
• interaction with data-protection law
• incident-reporting thresholds and local supervisory expectations

Criticisms by experts and practitioners

Professionals have criticized PSD2 for:

• API fragmentation
• implementation delays
• uneven bank readiness
• too much friction from some SCA journeys
• not solving all fraud problems, especially newer scam patterns
• creating compliance cost without equal business returns for all participants

17. Common Mistakes and Misconceptions

Wrong Belief	Why It Is Wrong	Correct Understanding	Memory Tip
PSD2 is a global law	It is mainly an EU framework, with related UK and EEA relevance	Other countries may have similar systems, but not PSD2 itself	“EU rule, global influence”
PSD2 and open banking are exactly the same	Open banking is broader than one directive	PSD2 is a major legal driver, not the entire concept	“PSD2 powers part of open banking”
PSD2 only matters to banks	Merchants, fintechs, software firms, and customers are affected too	It changes the whole payment ecosystem