PSD2 Explained: Open Banking Rules for Fintechs

PSD2 — the Second Payment Services Directive — is the European Union's foundational legal framework governing payment services, open banking access, and consumer data rights across the EEA. It obliges banks to open their payment account infrastructure to licensed third parties and sets binding technical standards for authentication and security. For any fintech building on European payment rails, PSD2 is not optional background reading: it is the compliance baseline everything else depends on.

This guide is written for fintech product, engineering, and compliance teams who need a clear, accurate account of what PSD2 requires, where the hard problems lie, and how modern orchestration approaches reduce the operational cost of staying compliant. Whether you are licensing a new payment service, integrating bank APIs, or preparing for PSD3, the sections below give you the factual foundation to make informed decisions quickly.

What is PSD2?

PSD2 is Directive (EU) 2015/2366 of the European Parliament and of the Council, published in November 2015 and transposed into national law across EU member states by January 2018. It replaced the original Payment Services Directive (PSD1) of 2007, which had created a single payments market but had not anticipated the emergence of third-party app-based financial services. PSD2 was designed to fill that gap by giving new categories of regulated provider a legal right to access payment account data held by banks.

The directive rests on three structural pillars. First, it mandates that account-servicing payment service providers — primarily banks — grant access to payment accounts via dedicated interfaces for authorised third parties. Second, it introduces strong customer authentication as a binding technical requirement for electronic payments and account access. Third, it creates two new licence categories — account information service providers and payment initiation service providers — that must be authorised by a national competent authority before operating.

PSD2 fundamentally reordered the competitive dynamics of European retail banking. Institutions that had previously treated customer account data as proprietary were required to make it available on standardised terms. This legislative shift is what most practitioners mean when they refer to "open banking" in a European regulatory context, even though the directive itself does not use that phrase.

Who PSD2 applies to

PSD2 applies to any payment service provider operating within the EEA, regardless of where the provider is incorporated, provided the service is offered to users located in the EEA. The scope covers a wide range of entities: credit institutions, electronic money institutions, payment institutions, post office giro institutions, and the two new categories introduced by PSD2 itself.

Account Information Service Providers (AISPs) aggregate and display payment account data from one or more banks on behalf of a user. Payment Initiation Service Providers (PISPs) trigger payment transactions directly from a user's bank account. Both categories are collectively referred to as Third-Party Providers (TPPs). Account Servicing Payment Service Providers (ASPSPs) — typically banks and building societies — are the entities that hold the payment accounts and must provide API access to TPPs.

The territorial reach of PSD2 is broader than many teams initially assume. A fintech incorporated in the United States that offers payment initiation services to users in Germany is operating a regulated service under PSD2 and must hold the appropriate EEA authorisation or passport rights. Similarly, a platform that aggregates bank account data for business customers is almost certainly operating as an AISP, even if its primary product description makes no reference to financial services.

• Credit institutions (banks) acting as ASPSPs
• Electronic money institutions issuing stored value
• Licensed AISPs providing account aggregation
• Licensed PISPs initiating bank-to-bank payments
• TPPs passporting services across EEA member states
• Non-EEA firms servicing EEA-resident users

PSD2 core requirements

PSD2 imposes obligations across three broad domains: access, authentication, and authorisation. On access, ASPSPs must provide at least one dedicated interface through which TPPs can retrieve payment account information and initiate transactions. That interface must meet the technical standards set out in Commission Delegated Regulation (EU) 2018/389, commonly called the Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Open Standards of Communication (RTS on SCA & CSC).

On authentication, PSD2 requires strong customer authentication whenever a payment account is accessed remotely or an electronic payment is initiated. SCA must combine at least two independent elements drawn from the categories of knowledge, possession, and inherence. The RTS further specifies dynamic linking requirements, meaning the authentication code generated must be tied to the specific transaction amount and payee.

On authorisation, any entity offering account information or payment initiation services must be registered or licensed by a national competent authority and appear on the EBA's public register of payment institutions. Licensing requirements include fit-and-proper assessments of management, minimum capital thresholds, professional indemnity insurance for AISPs, and documented security policies. Firms that passport their licence across member states must notify both their home and host regulators.

• Dedicated API interface for TPP access to payment accounts
• Strong customer authentication with dynamic linking for payments
• AISP or PISP licence from a national competent authority
• Safeguarding or insurance obligations depending on licence type
• Incident reporting to competent authorities within prescribed timelines

Strong Customer Authentication (SCA) explained

Strong Customer Authentication is the mechanism PSD2 uses to verify that the person authorising a payment or accessing an account is who they claim to be. The RTS requires that authentication combines at least two elements from three defined categories: something the user knows (a password or PIN), something the user has (a registered device, smart card, or token), and something the user is (biometric data such as a fingerprint or facial scan). The two elements must be independent, meaning a breach of one does not compromise the other.

For payment transactions, SCA must also satisfy the dynamic linking requirement. The authentication code must be specific to both the amount of the transaction and the payee identifier. This prevents a man-in-the-middle attack from substituting transaction details after authentication. If any of those details change, a new authentication flow must be triggered.

PSD2 permits a set of defined exemptions where issuers and acquirers may apply SCA-free flows. Low-value contactless payments below €50, contactless cumulative limits, trusted beneficiary lists, recurring transactions of identical amount, and the transaction risk analysis (TRA) exemption for low-risk remote payments below defined fraud-rate thresholds are the most operationally significant. Issuers must still apply SCA if the acquirer requests an exemption but the issuer's fraud models flag the transaction as elevated risk.

• Knowledge factor: PIN, password, security question
• Possession factor: registered mobile device, hardware token, smart card
• Inherence factor: fingerprint, face recognition, voice pattern
• Dynamic linking: authentication code tied to amount & payee
• TRA exemption: available where issuer fraud rate is below RTS threshold

Open banking APIs under PSD2

PSD2 does not mandate a single API standard. Instead, it sets functional requirements — what the API must be capable of doing — and leaves market bodies to develop the technical specifications. In practice, the Berlin Group's NextGenPSD2 framework has become the most widely adopted specification across continental Europe, covering AIS (account information) and PIS (payment initiation) interface designs for both OAuth 2.0 and redirect-based consent flows.

Under the NextGenPSD2 framework, a TPP connects to an ASPSP's dedicated interface by first obtaining a qualified electronic seal certificate (QSEAL) or qualified electronic signature certificate (QWAC) from a qualified trust service provider. These certificates, issued under eIDAS, identify the TPP and its licence type to the ASPSP. The ASPSP validates the certificate in real time against the EBA register before granting API access. Consent is managed through a structured flow: the TPP requests consent, the ASPSP redirects the user for authentication, and upon successful SCA the ASPSP returns an access token scoped to the approved accounts and data types.

Despite the existence of the Berlin Group standard, implementation inconsistency across ASPSPs remains a significant operational problem. Banks have applied the specification differently, added proprietary extensions, or imposed non-standard rate limits. FinQub's compliance content addresses this directly: the practical challenge for fintechs is not understanding the standard on paper but managing deviation from it at scale across dozens of bank connections simultaneously.

PSD2 vs PSD3: what's changing

In June 2023 the European Commission published its legislative proposals for PSD3 and an accompanying Payment Services Regulation (PSR). The PSR is particularly significant because, unlike the current directive, a regulation takes direct effect in all member states without requiring national transposition. This is intended to eliminate the fragmentation that arose because member states implemented PSD2 differently.

The proposals tighten SCA rules, expand the scope of fraud liability for payment service providers, and significantly strengthen open banking data access rights. Under PSD3, ASPSPs would be required to provide a financial data access dashboard allowing users to manage consent centrally. The proposals also address the persistent API quality problem by introducing binding performance benchmarks and a dedicated supervisory framework for ASPSP interface compliance.

PSD3 is expected to enter the legislative trilogue process during 2024–2025, with transposition and application timelines likely extending into 2026 or beyond. Fintechs should treat PSD3 as a forward planning concern rather than an immediate compliance obligation, but teams building long-lived payment infrastructure should design their consent and API routing layers to accommodate the anticipated changes in data access scope and liability allocation.

PSD2 compliance challenges for fintechs

The formal requirements of PSD2 are reasonably well-defined; the operational reality of meeting them is considerably harder. Three categories of challenge recur most frequently in fintech teams building on PSD2 infrastructure.

API inconsistency is the most immediate technical problem. Even ASPSPs using the same Berlin Group specification produce interfaces that differ in error handling, consent scope modelling, token lifetimes, and rate limiting. A TPP connecting to fifteen banks must manage fifteen subtly different integration contracts. This raises the ongoing maintenance burden significantly and makes it difficult to build generic retry and fallback logic.

SCA friction imposes a measurable cost on conversion. Redirect-based SCA flows, which remain the dominant pattern, require users to leave the fintech's interface and complete authentication in a bank environment. Drop-off rates at this step are a known problem, and while decoupled authentication flows offer a better UX, not all ASPSPs support them. Designing exemption logic to maximise frictionless flows without exceeding fraud thresholds requires both technical precision and ongoing monitoring of acquirer and issuer fraud rate data.

Multi-jurisdiction licensing adds a further layer of complexity for fintechs scaling across the EEA. Passporting rights reduce the burden compared to obtaining separate licences in each country, but supervisory expectations, reporting formats, and incident notification procedures still vary at the national level. Teams that treat licensing as a one-time event rather than an ongoing compliance programme encounter difficulties during supervisory reviews.

• Inconsistent ASPSP API implementations despite shared specifications
• High SCA redirect abandonment rates affecting payment conversion
• Limited decoupled authentication support across European banks
• Variable national transposition creating divergent supervisory expectations
• eIDAS certificate procurement and rotation adding operational overhead
• Incident reporting deadlines requiring always-on monitoring capability

Orchestrating PSD2 compliance workflows

An orchestration layer sits between a fintech's product logic and the diverse set of ASPSPs, authentication providers, and consent repositories it must interact with. Rather than encoding bank-specific behaviour into each service or integration, orchestration externalises the routing, fallback, and policy enforcement logic into a single configurable layer. This architectural pattern significantly reduces the cost of maintaining compliance as bank APIs evolve and regulatory requirements change.

For SCA specifically, an orchestration layer can enforce exemption eligibility rules consistently at the point of payment initiation, select the appropriate authentication method based on the user's device and the ASPSP's supported flows, and handle step-up challenges without requiring changes to the core payment service. Consent lifecycle management — tracking expiry, renewal triggers, and revocation events across multiple ASPSPs — is similarly well-suited to orchestration because the state machine logic is uniform even when the underlying API calls differ.

TPP credential routing is another area where orchestration provides clear value. QWAC and QSEAL certificates must be presented correctly to each ASPSP, and certificate rotation events must propagate across all active connections without service interruption. An orchestration platform that abstracts credential management means engineering teams do not need to implement this logic independently for each bank integration. FinQub covers the design patterns for this approach in its broader compliance engineering content, with worked examples across common EEA bank connectivity scenarios.

PSD2 compliance checklist

The checklist below covers the principal obligations a fintech must address to operate as a licensed TPP under PSD2. It is not a substitute for legal advice specific to your jurisdiction and licence type, but it provides a structured starting point for a compliance gap analysis.

• Licensing: Obtain AISP or PISP authorisation from the appropriate national competent authority; register on the EBA payment institutions register; notify host state regulators if passporting.
• eIDAS certificates: Procure QWAC and QSEAL certificates from a qualified trust service provider; implement automated certificate rotation before expiry.
• SCA implementation: Implement SCA with at least two independent authentication factors; apply dynamic linking for all payment transactions; document exemption logic and monitor fraud rate thresholds.
• API readiness: Map each ASPSP integration against the applicable specification (Berlin Group or proprietary); implement fallback to redirect where decoupled flows are unsupported; test against ASPSP sandbox and production environments.
• Consent management: Build consent lifecycle tracking covering creation, scope, expiry, and revocation for each ASPSP; surface consent status to users on demand.
• Incident reporting: Establish monitoring capable of detecting major operational or security incidents within the RTS-prescribed detection window; implement reporting workflows to competent authorities within required timelines.
• Ongoing monitoring: Subscribe to EBA regulatory updates and national competent authority guidance; track PSD3 legislative progress; review API integration contracts against ASPSP change notices.

FinQub recommends treating this checklist as a living document rather than a one-time audit. PSD2 compliance is an operational programme: licensing renewals, certificate rotations, fraud rate reviews, and regulatory updates each require scheduled attention from both compliance and engineering functions.