PSD2 and Open Banking

The European financial landscape has undergone a profound transformation over the past decade, driven by a single regulatory mandate: the Payment Services Directive 2 (PSD2). This comprehensive EU regulation, combined with the broader market movement toward Open Banking, has fundamentally reshaped how financial institutions, fintech companies, and third-party providers interact with consumer and business payment data. For IT decision-makers and digital transformation leaders, understanding PSD2 and Open Banking is no longer optional—it is essential to navigating modern financial services architecture, managing compliance risk, and capitalizing on innovation opportunities.

This guide provides an in-depth exploration of PSD2 and Open Banking: their origins, regulatory requirements, technical implementation, business implications, and future trajectory. Whether you are a CTO evaluating API integration strategies, a compliance officer assessing regulatory obligations, or a fintech founder building new payment services, this article will equip you with the knowledge to make informed decisions.

What is PSD2 and how does it work?

Origins and evolution — from PSD to PSD2

The Payment Services Directive (PSD), adopted in 2007, was the European Union’s first attempt to harmonize payment services regulation across member states. The original PSD established baseline rules for payment service providers, consumer protection standards, and cross-border payment processing. However, by the early 2010s, the payments landscape had changed dramatically. Mobile banking, online commerce, and fintech innovation had accelerated far beyond what the 2007 directive anticipated. Consumer expectations for seamless, real-time payments had risen. Fraud threats had evolved. The competitive landscape had fragmented.

In response, the European Commission proposed the revised Payment Services Directive 2 (PSD2), formally adopted as Directive 2015/2366/EU. PSD2 entered into force on 12 January 2016, giving EU Member States two years to transpose the directive into national law—a deadline that most nations met by January 2018. However, the most critical compliance requirement—Strong Customer Authentication (SCA)—did not become mandatory until 14 September 2019, providing an additional transition period for payment service providers to implement the necessary security infrastructure.

The evolution from PSD to PSD2 reflects a fundamental shift in regulatory philosophy: from static rule-setting to adaptive governance designed to foster innovation while protecting consumers and maintaining financial stability. Today, the European Commission is already developing PSD3, expected to further expand the scope of open finance and enhance consumer rights.

Core objectives and scope

PSD2 was designed to achieve four primary objectives, each addressing a distinct market failure or regulatory gap:

1. Create a more integrated and efficient European payments market. By harmonizing payment service rules across the European Economic Area (EEA), PSD2 eliminated fragmented national regulations that had previously hindered cross-border payment flows. This integration reduces friction for multinational enterprises and enables pan-European fintech platforms to scale efficiently.

2. Level the competitive playing field for payment service providers. The original PSD had created barriers to entry for non-bank payment providers. PSD2 explicitly recognizes new categories of payment service providers—Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs)—and grants them regulated access to customer bank accounts (subject to customer consent). This democratization of payment services has enabled thousands of fintech startups to launch innovative services that were previously impossible.

3. Enhance payment security and reduce fraud. PSD2’s Strong Customer Authentication requirement mandates that all online payment transactions must be verified using two independent authentication factors. This requirement has dramatically reduced payment fraud across the EEA, though it has also introduced operational challenges for merchants and consumers.

4. Protect consumer and business data. PSD2 establishes strict data governance requirements, mandating explicit consumer consent before any third-party provider can access account information. It also requires payment service providers to implement robust cybersecurity measures, report security incidents, and maintain operational resilience standards.

Geographic and sectoral applicability

PSD2 applies to all payment service providers operating within the European Economic Area (EEA), which includes all EU member states plus Iceland, Liechtenstein, and Norway. The directive also applies to UK payment service providers under specific post-Brexit arrangements, though the UK has begun developing its own Open Banking regulatory framework.

Payment service providers subject to PSD2 include traditional banks, payment institutions (licensed non-bank payment processors), electronic money institutions, and certain fintech companies. Third-party providers—AISPs and PISPs—must be registered with their national financial regulator and comply with PSD2 technical and security standards, even if they do not hold customer funds.

For businesses operating in Central and Eastern Europe (CEE)—including Slovakia, Czech Republic, and other EU member states—PSD2 compliance is mandatory. This has created both challenges and opportunities: financial institutions have had to invest significantly in API infrastructure and security protocols, while fintech companies have found new channels to innovate and compete.

What are the key components of PSD2 compliance?

Strong Customer Authentication (SCA)

Strong Customer Authentication (SCA) is arguably the most visible and operationally impactful requirement of PSD2. SCA mandates that all online payment transactions be authenticated using two or more independent elements from three categories: something you know (knowledge, such as a password or PIN), something you have (possession, such as a mobile phone or hardware token), and something you are (inherence, such as a biometric fingerprint or facial recognition).

The regulatory technical standards for SCA, published by the European Banking Authority (EBA) in March 2018, became mandatory on 14 September 2019. From that date forward, any payment service provider failing to implement SCA faced regulatory sanctions and liability for fraudulent transactions.

However, PSD2 and the EBA guidelines include several important exemptions from the SCA requirement, provided that payment service providers can demonstrate that the transaction falls into a low-risk category:

• Low-value transactions: Payments below €30 (though this threshold can be adjusted by individual member states)
• Recurring payments: Transactions where the payer has already authenticated the first payment in a series
• Merchant whitelisting: Payments to merchants that the customer has explicitly approved
• Payment-to-self: Transfers between accounts held by the same customer
• Trusted beneficiaries: Transfers to pre-approved recipients

These exemptions were essential to preventing SCA from paralyzing e-commerce and recurring subscription models. However, they have also created security vulnerabilities: fraudsters have exploited exemption loopholes, and payment service providers must implement sophisticated risk-based authentication systems to distinguish between low-risk transactions and potential fraud.

Beyond the basic two-factor requirement, PSD2 introduces the concept of dynamic linking for card-based transactions. Dynamic linking requires that the authentication process explicitly confirms the payment amount and payee details, preventing man-in-the-middle attacks where a fraudster intercepts a payment and modifies the transaction details after authentication.

Open Banking and API standards

While SCA addresses payment security, the Open Banking provisions of PSD2 address data access and interoperability. Article 4 of PSD2 requires that payment service providers make customer account information and payment initiation services available to authorized third-party providers via secure, standardized APIs. These APIs must comply with “common and secure open standards of communication.”

The EBA’s regulatory technical standards specify that these APIs must be:

• Standardized: Consistent across all payment service providers, enabling third-party developers to write code once and integrate with multiple banks
• Secure: Protected with encryption, mutual authentication, and access controls
• Reliable: Available 99.5% of the time (with documented SLAs)
• Performant: Capable of processing requests within defined response time windows

In practice, this has led to the emergence of Open Banking API standards such as the Open Banking Standard (UK), the Berlin Group NextGenPSD2 specification (Europe), and various national implementations. These standards define the technical structure of API requests and responses, authentication protocols, and data formats.

A critical aspect of Open Banking APIs is that they operate on a consent-based model. A third-party provider cannot access a customer’s account data without explicit, informed consent. The customer must be informed of exactly what data the TPP will access, for how long, and for what purpose. This consent is recorded in the customer’s bank account and can be revoked at any time.

Account Information Services (AIS) and Payment Initiation Services (PIS)

PSD2 recognizes two primary categories of third-party services that operate via Open Banking APIs:

Account Information Services (AIS): An AISP is a licensed third-party provider that can access a customer’s account information—transaction history, account balance, payment history—for the purpose of providing financial management, analytics, or advisory services. Examples include personal finance management apps (like Revolut or N26’s budgeting features), expense tracking applications, and financial analytics platforms. An AISP cannot initiate payments; it can only read account data.

Payment Initiation Services (PIS): A PISP is a licensed third-party provider that can initiate payments on behalf of a customer, directly from the customer’s bank account. Examples include fintech payment platforms (like Wise or Stripe’s payment links), invoice payment services, and alternative checkout solutions. A PISP can initiate payments but typically cannot read historical account data (though some implementations allow limited data access for fraud prevention).

Both AIS and PISP providers must be formally registered with their national financial regulator. In the EU, this is typically the national central bank or financial services authority. Registration requires demonstrating technical capability, security measures, governance structures, and financial soundness. Once registered, AIS and PISP providers gain the legal right to access customer bank accounts (subject to customer consent) and are subject to ongoing regulatory supervision.

How do Open Banking APIs enable financial data sharing?

API architecture and technical implementation

Open Banking APIs are built on standard web technologies: RESTful HTTP protocols, JSON data formats, and OAuth 2.0 authentication. This technical foundation was deliberately chosen to lower barriers to entry for fintech developers and ensure compatibility across diverse banking systems.

A typical Open Banking API flow works as follows:

1. Customer initiates a request: A customer uses a fintech app and clicks a button to “Connect your bank account.” The app redirects the customer to their bank’s login page (or an aggregator’s interface).

2. Customer authenticates and grants consent: The customer logs into their bank using their normal credentials. The bank then presents a consent screen showing exactly what data the third-party app will access, for how long, and for what purpose. The customer explicitly approves or denies the request.

3. Bank generates an authorization code: If approved, the bank generates a time-limited authorization code and redirects the customer back to the fintech app.

4. Third-party app exchanges code for access token: The fintech app uses the authorization code to request an access token from the bank’s API server. This exchange happens server-to-server, not through the customer’s browser, ensuring the app never sees the customer’s banking credentials.

5. Third-party app queries account data: The fintech app uses the access token to make API requests to the bank’s Open Banking API, retrieving account information, transaction history, or initiating payments as authorized.

6. Bank returns data and logs the access: The bank returns the requested data in a standardized JSON format and logs all API access for audit and compliance purposes.

This OAuth 2.0 flow ensures that the fintech app never gains direct access to the customer’s banking credentials. Instead, the bank acts as the trusted intermediary, issuing time-limited access tokens that can be revoked at any time.

From a technical perspective, banks have typically implemented Open Banking APIs using one of two approaches:

Approach 1: Direct API integration. The bank builds its own Open Banking API directly on top of its core banking system, exposing account data and payment initiation functions through standardized endpoints. This approach offers maximum control and customization but requires significant engineering investment.

Approach 2: API aggregation platform. The bank partners with a third-party API aggregation platform (such as Plaid, TrueLayer, or OpenBanking.org.uk) that sits between the bank’s legacy systems and third-party developers. The aggregation platform handles authentication, data normalization, and API standardization, reducing the bank’s engineering burden but introducing a dependency on the aggregator.

Many large European banks have adopted a hybrid approach: building core Open Banking APIs internally while also participating in industry-standard platforms to ensure broader ecosystem compatibility.

Consumer consent and data governance

A fundamental principle of PSD2 Open Banking is explicit, informed consumer consent. Before any third-party provider can access account data or initiate payments, the customer must be presented with clear information about:

• The identity of the third-party provider
• The specific data or functions being requested (e.g., “read transaction history for the past 90 days” or “initiate payments up to €5,000”)
• The duration of the consent (e.g., “for 90 days” or “until revoked”)
• The purpose of the data access (e.g., “to provide budgeting advice” or “to process invoice payments”)

This consent model differs significantly from the traditional “username and password” model, where a customer would hand over their banking credentials to a third-party app, granting it unlimited access indefinitely. PSD2’s consent model is far more granular and transparent.

Data governance under PSD2 also includes strict retention limits. Account Information Service Providers, for example, are typically permitted to retain transaction data for only 90 days after the customer’s consent expires. This prevents fintech companies from building permanent databases of customer financial history without ongoing consent.

Additionally, PSD2 aligns with the EU’s General Data Protection Regulation (GDPR), which provides customers with additional rights: the right to access their data, the right to correct inaccurate data, and the right to be forgotten (data deletion). These rights add another layer of complexity to data governance, requiring fintech companies and banks to implement robust data management and deletion procedures.

Security measures and fraud prevention

Open Banking APIs are high-value targets for cybercriminals. A compromised API could expose millions of customer transactions, balances, and personal financial data. Consequently, PSD2 mandates robust security measures:

Encryption: All API communications must be encrypted using TLS 1.2 (or higher) protocols. Sensitive data must be encrypted both in transit (between the API client and server) and at rest (stored on the bank’s systems).

Mutual authentication: Both the third-party provider and the bank must authenticate each other before exchanging data. This is typically achieved using digital certificates and mutual TLS (mTLS), preventing man-in-the-middle attacks.

Access controls: Access tokens issued by the bank must be limited in scope (specifying exactly which data or functions are accessible) and duration (expiring after a set period, typically 90 days). Banks must also implement rate limiting and anomaly detection to identify and block suspicious API usage patterns.

Transaction monitoring: For Payment Initiation Services, banks must monitor all payment initiation requests for signs of fraud or unauthorized access. This includes checking transaction amounts against historical patterns, verifying that the payee is consistent with the customer’s prior behavior, and flagging unusual cross-border or high-value transfers.

Incident reporting: If a bank or third-party provider experiences a security breach affecting Open Banking APIs, they must report the incident to their national financial regulator within a defined timeframe (typically 24 hours for serious incidents). The EBA publishes guidance on incident classification and reporting procedures.

Penetration testing and security audits: Banks and large third-party providers are required to conduct regular penetration testing and security audits of their Open Banking infrastructure, typically at least annually. These tests must be performed by independent security firms and documented for regulatory review.

What are the business implications of PSD2 and Open Banking?

Impact on financial institutions

For traditional banks, PSD2 has been a double-edged sword. On one hand, it has forced significant capital investment in API infrastructure, security systems, and regulatory compliance. European banks collectively spent billions of euros building Open Banking platforms, hiring specialized talent, and redesigning legacy systems to expose account data via APIs.

On the other hand, Open Banking has created new revenue opportunities. Banks can monetize their customer relationships and data through:

• API licensing fees: Charging third-party providers for access to Open Banking APIs
• Premium data services: Offering enhanced analytics, insights, and predictive services to fintech partners
• White-label solutions: Providing Open Banking infrastructure to smaller regional banks or fintech platforms
• Ecosystem partnerships: Building strategic alliances with fintech companies to expand service offerings and reach new customer segments

However, the most profound impact of PSD2 on banks has been competitive disruption. Fintech companies, armed with Open Banking APIs, have been able to launch innovative payment and financial management services without building their own banking infrastructure. This has accelerated the shift toward embedded finance, where financial services are embedded directly into non-financial apps (e.g., payment options in e-commerce platforms, budgeting tools in accounting software).

For banks operating in Central and Eastern Europe, PSD2 has also created an opportunity to compete on a level playing field with Western European financial institutions. A Slovak fintech company can now build services that integrate seamlessly with any EU bank, regardless of size or geography.

Opportunities for fintech and third-party providers

For fintech companies and third-party providers, PSD2 has been transformative. The regulatory requirement that banks expose Open Banking APIs has created a massive new market for innovative financial services:

Payment initiation services: Companies like Wise, Stripe, and Revolut have built billion-dollar businesses by offering alternative payment methods that leverage PSD2’s Payment Initiation Services. Instead of requiring customers to enter their bank details into a merchant’s website, customers can authenticate directly with their bank and authorize the payment in seconds.

Personal finance management: Apps like Emma, Money Dashboard, and Plaid have aggregated account data from thousands of banks via Open Banking APIs, enabling customers to see all their accounts in one place and receive personalized financial advice.

Credit scoring and lending: Fintech lenders have used Open Banking APIs to access real-time transaction data, enabling faster and more accurate credit decisions than traditional credit bureaus. This has democratized lending, making it easier for small businesses and individuals with limited credit history to access capital.

Invoice and bill payment: B2B fintech platforms have used Payment Initiation Services to simplify invoice payment workflows, enabling businesses to pay suppliers directly from their bank accounts without manual data entry or paper-based processes.

The regulatory requirement to support Open Banking has also lowered barriers to entry for startups. A fintech founder no longer needs to obtain a banking license to launch a payment service; they simply need to register as a Payment Initiation Service Provider and integrate with existing bank APIs.

Risk management and regulatory obligations

Despite the opportunities, PSD2 and Open Banking have introduced new risks and regulatory obligations that organizations must manage carefully:

Compliance burden: Organizations offering AIS or PISP services must obtain regulatory registration, implement technical standards, maintain security certifications, and report to regulators. For startups and small companies, this compliance overhead can be significant.

Operational risk: Open Banking APIs are critical infrastructure. If an API fails or performs poorly, it can disrupt the entire fintech service. Banks and third-party providers must implement robust monitoring, disaster recovery, and business continuity procedures.

Cybersecurity risk: Open Banking APIs are high-value targets for cybercriminals. A single breach could expose millions of customer records and lead to regulatory fines, lawsuits, and reputational damage. Organizations must invest heavily in security tools, threat monitoring, and incident response capabilities.

Data privacy and GDPR compliance: Third-party providers must comply with GDPR requirements for data processing, storage, and deletion. This is particularly challenging for companies that aggregate data from multiple banks and retain it for analytics purposes.

Regulatory evolution: PSD2 itself is evolving, and PSD3 is on the horizon. Organizations must stay abreast of regulatory changes and be prepared to adapt their technical and operational infrastructure accordingly.

How does PSD2 differ from Open Banking?

Regulatory vs. market-driven approaches

A common misconception is that PSD2 and Open Banking are synonymous. In fact, they are distinct but overlapping concepts:

PSD2 is a mandatory EU regulation. All payment service providers operating in the EEA must comply with PSD2’s requirements, whether they like it or not. Failure to comply results in regulatory sanctions, fines, and potential loss of operating licenses.

Open Banking is a market-driven movement. While PSD2 mandates that banks expose Open Banking APIs, the broader Open Banking movement extends beyond PSD2’s requirements. Open Banking encompasses voluntary initiatives by banks and fintech companies to share financial data and enable third-party innovation, even in jurisdictions where there is no regulatory mandate.

For example, the United Kingdom’s Open Banking initiative, which predates PSD2, required the nine largest UK banks to expose Open Banking APIs even before PSD2 became mandatory. Similarly, Australia and Singapore have launched Open Banking initiatives based on regulatory mandates but with different technical standards and scope than PSD2.

In essence, PSD2 is the European regulatory implementation of the broader Open Banking concept. It is the “how” and “what” of Open Banking in the EEA, specifying exactly which APIs must be exposed, which security standards must be met, and which third-party providers are authorized to access customer data.

Geographic scope and regional variations

PSD2 applies only to payment service providers operating in the EEA (EU member states plus Iceland, Liechtenstein, and Norway). Outside the EEA, Open Banking operates under different regulatory frameworks or market-driven initiatives:

• United Kingdom: Post-Brexit, the UK has developed its own Open Banking framework, which is broadly aligned with PSD2 but with some differences in technical standards and implementation timelines.
• Australia: The Consumer Data Right (CDR) framework mandates Open Banking for the four largest banks, with planned expansion to other financial institutions.
• Singapore: The Monetary Authority of Singapore (MAS) has promoted voluntary Open Banking initiatives, with specific API standards and security requirements.
• United States: The US has no comprehensive Open Banking mandate, though the Consumer Financial Protection Bureau (CFPB) has proposed Open Banking rules that would require banks to share customer data with fintech competitors.

For organizations operating across multiple geographies, this fragmentation creates complexity. A fintech company might need to implement PSD2-compliant APIs for EEA customers, UK Open Banking APIs for UK customers, and CDR-compliant APIs for Australian customers—each with different technical specifications, security requirements, and regulatory oversight.

What are the common misconceptions about PSD2 and Open Banking?

Misconception #1: PSD2 and Open Banking are the same thing

As explained above, PSD2 is the EU regulatory mandate for Open Banking. Open Banking is the broader market concept. They are related but distinct. Understanding this distinction is important for compliance and strategic planning.

Misconception #2: Open Banking is only for consumers

While Open Banking APIs are often marketed to consumers (e.g., personal finance apps), they are equally relevant for businesses. Payment Initiation Services are widely used by B2B fintech platforms to simplify invoice payment and cash flow management. Account Information Services are used by business intelligence platforms to provide real-time financial insights. Regulators and industry organizations are increasingly discussing Open Banking for SMEs and business customers, not just consumers.

Misconception #3: SCA exemptions make authentication optional

SCA exemptions (for low-value transactions, recurring payments, etc.) are conditional and risk-based. A payment service provider cannot simply decide to skip SCA for all low-value transactions; it must implement risk assessment systems to ensure that the transaction genuinely qualifies for exemption. If a payment service provider grants an exemption inappropriately and fraud occurs, the provider is liable for the fraudulent transaction. Exemptions are narrow and require careful implementation.

Misconception #4: Open Banking data sharing is inherently unsafe

While Open Banking does involve sharing customer financial data with third parties, PSD2’s consent-based model, encryption requirements, and access controls actually provide stronger protections than the traditional “password sharing” model that preceded it. When a customer grants consent to a third-party provider, they are granting access to a specific set of data for a limited duration, with the ability to revoke consent at any time. This is far more granular and transparent than handing over banking credentials to an app and hoping it doesn’t misuse them.

What is the future of Open Banking and PSD3?

PSD3 roadmap and expected changes

The European Commission has already begun the legislative process for PSD3, with formal proposals expected in 2024–2025 and implementation likely in 2025–2026. While PSD3 is still being negotiated, several key changes are anticipated:

Expanded scope beyond payments: PSD3 is expected to extend Open Banking principles to other financial products, including savings accounts, investment accounts, insurance products, and mortgages. This broader scope is sometimes referred to as “Open Finance.”

Enhanced consumer rights: PSD3 will likely strengthen consumer rights to access their own data and port their financial relationships to competing providers. This could include the right to download account data in standardized formats and the right to switch providers with minimal friction.

Stronger security and operational resilience: PSD3 will likely impose stricter cybersecurity requirements, including mandatory encryption standards, more frequent security audits, and faster incident response timelines.

Real-time payments as standard: PSD3 may mandate that all banks support real-time payment initiation, reducing settlement times from days to seconds.

Simplified authorization and authentication: PSD3 may introduce more flexible authentication methods, potentially reducing reliance on SCA exemptions by enabling risk-based authentication that is both secure and user-friendly.

Emerging trends in Open Finance

Beyond PSD3, several broader trends are shaping the future of Open Banking and Open Finance:

Embedded finance: Financial services are increasingly embedded directly into non-financial applications. A customer might apply for a loan while shopping on an e-commerce platform, or invest their savings through a budgeting app. Open Banking APIs enable this embedded finance model by allowing third-party apps to access financial data and initiate transactions on behalf of customers.

Real-time payments: Instant payment schemes (such as the EU’s SEPA Instant Credit Transfer) are becoming the standard, enabling 24/7 settlement of payments. This shift from batch processing to real-time settlement is fundamentally changing cash flow management and payment workflows.

Open data and financial transparency: Regulators and consumer advocates are pushing for greater transparency in financial services pricing and terms. Open Banking APIs could be extended to expose pricing data, enabling customers to easily compare financial products and switch providers.

Cross-border Open Banking: While PSD2 operates primarily within the EEA, there is growing interest in enabling Open Banking across borders. This could facilitate international payments, cross-border lending, and global fintech platforms.

Open Finance beyond banking: The Open Finance movement is expanding beyond payment banks to include insurance companies, investment firms, and pension providers. This broader scope could enable comprehensive financial management platforms that integrate banking, investing, insurance, and retirement planning in a single interface.

Conclusion

PSD2 and Open Banking represent a fundamental transformation in how financial services are delivered and regulated in Europe. For IT decision-makers, the implications are clear: Open Banking APIs are not a future technology—they are a present reality that must be understood, implemented, and managed carefully.

Whether you are a financial institution building Open Banking infrastructure, a fintech company integrating with bank APIs, or an enterprise evaluating how to leverage Open Banking for your business, a deep understanding of PSD2’s regulatory requirements, technical architecture, and business implications is essential.

If your organisation is navigating PSD2 compliance or planning Open Banking integration, Greyson’s consulting team can help you design a tailored strategy that balances regulatory requirements with business objectives, technical feasibility, and security considerations.

Frequently Asked Questions

What is PSD2 and how does it work?

PSD2 (Payment Services Directive 2) is an EU regulation that entered into force in January 2016 and became fully mandatory in September 2019. It requires banks to expose Open Banking APIs to authorized third-party providers, mandates Strong Customer Authentication for online payments, and establishes rules for Account Information Services and Payment Initiation Services. PSD2 aims to increase competition, enhance payment security, and protect consumer data across the EEA.

What is Open Banking and why does it matter?

Open Banking is the practice of sharing customer financial data and payment services via APIs, subject to explicit customer consent. It matters because it enables fintech innovation, improves competition in financial services, and gives customers greater control over their financial data. PSD2 mandates Open Banking in the EEA, but the concept is also being adopted globally in other jurisdictions.

What is Strong Customer Authentication (SCA) and why is it required?

SCA is a security requirement that mandates two-factor authentication for online payments: something you know (password), something you have (mobile phone), or something you are (biometric). SCA is required by PSD2 to reduce payment fraud and protect consumers. However, certain low-risk transactions (under €30, recurring payments, whitelisted merchants) are exempt from SCA.

How do Open Banking APIs work?

Open Banking APIs use OAuth 2.0 authentication to enable secure, consent-based access to customer account data. A customer grants consent to a third-party app, which then uses an access token to query the bank’s API for account information or initiate payments. The bank logs all API access for audit purposes and can revoke access tokens at any time.

What are the compliance requirements for PSD2?

PSD2 compliance requirements include: implementing Strong Customer Authentication for online payments, exposing Open Banking APIs to authorized third-party providers, obtaining explicit customer consent before sharing data, encrypting all API communications, conducting regular security audits, reporting security incidents to regulators, and maintaining operational resilience standards.

What is the difference between PSD2 and Open Banking?

PSD2 is a mandatory EU regulation that mandates Open Banking. Open Banking is the broader market concept of sharing financial data via APIs. PSD2 is the regulatory “how” and “what” of Open Banking in the EEA, while Open Banking is a global movement with different implementations in different jurisdictions.

How does PSD2 impact businesses and financial institutions?

For financial institutions, PSD2 requires significant investment in API infrastructure, security systems, and regulatory compliance. For fintech and third-party providers, PSD2 creates new opportunities to launch innovative payment and financial management services. For businesses, PSD2 enables faster, more secure payment processing and better access to financial data for decision-making.

What are the security risks of Open Banking?

Key security risks include API breaches that expose customer data, unauthorized access to account information, payment fraud via compromised payment initiation services, and third-party provider misuse of customer data. However, PSD2’s encryption requirements, access controls, and consent-based model provide robust protections against these risks if implemented correctly.

What are Account Information Services (AIS) and Payment Initiation Services (PIS)?

AIS providers access customer account data (transaction history, balance) to offer financial management and analytics services. PIS providers initiate payments on behalf of customers directly from their bank accounts. Both must be registered with financial regulators and comply with PSD2 security and consent requirements.

What is PSD3 and when will it be implemented?

PSD3 is the next evolution of PSD2, expected to expand Open Banking to savings, investment, and insurance products (Open Finance), strengthen consumer rights, enhance security requirements, and mandate real-time payments. PSD3 legislation is expected in 2024–2025, with implementation likely in 2025–2026.