Payment Services Directive 2 — formally Directive (EU) 2015/2366 — is the European Union's principal legislative instrument governing payment services across the European Economic Area. In force since January 2018, it mandates Strong Customer Authentication for electronic transactions, compels account-holding banks to expose APIs to licensed third parties, and establishes two new regulated entity classes: Account Information Service Providers and Payment Initiation Service Providers. This article covers scope, SCA mechanics, Open Banking architecture, exemptions, and the forthcoming PSD3/PSR transition expected in late 2026.
Directive (EU) 2015/2366 — universally abbreviated PSD2 — was adopted by the European Parliament on 25 November 2015 and replaced the original Payment Services Directive (2007/64/EC, known as PSD1) with effect from 13 January 2018. It is transposed into national law across all EU member states and, through separate regulation, applies to the EEA. In the United Kingdom, PSD2 was onshored as the Payment Services Regulations 2017 (SI 2017/752) and remains in force pending domestic reform.
The directive governs any natural or legal person that executes payment transactions, issues payment instruments, or acquires payment transactions commercially within the EEA. Its material scope covers credit transfers, direct debits, card-based payments, and money remittance conducted in any currency where at least one payment service provider (PSP) is located within the EEA — the so-called "one-leg-out" transactions introduced by PSD2 to close a loophole present in PSD1.
PSD2 distinguishes carefully between several regulated activities. Traditional PSPs — credit institutions, electronic money institutions (EMIs), and payment institutions (PIs) — were already regulated under PSD1. PSD2 added two entirely new licence categories: the Account Information Service Provider (AISP), which aggregates read-only account data from one or more payment accounts held at Account Servicing PSPs (ASPSPs) with the explicit consent of the account holder; and the Payment Initiation Service Provider (PISP), which initiates a payment order from a user's account held at an ASPSP at the user's request, without the PISP ever holding the funds.
The term "Open Banking," while not used verbatim in the directive text, describes the structural consequence of PSD2's access-to-account (XS2A) provisions, which legally oblige ASPSPs to grant AISPs and PISPs access to payment account data via dedicated interfaces (APIs) or, as a fallback, through modified customer interfaces. PSD2 is complemented by Commission Delegated Regulation (EU) 2018/389 — the Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Open Standards of Communication (RTS on SCA & CSC), which defines the technical and security requirements in granular detail. These standards are enforced by national competent authorities (NCAs), in most EU states the central bank or financial supervisory authority.
PSD2 operates through three interlocking mechanisms: access-to-account (XS2A) obligations, Strong Customer Authentication (SCA), and a licensing and passporting regime for third-party providers (TPPs).
Access to account (XS2A). Any bank or EMI that offers a consumer or business a payment account — an ASPSP — must make that account accessible to licensed TPPs. In practice, this means maintaining a dedicated API conforming to a recognised Open Banking standard (such as the Berlin Group's NextGenPSD2 framework or the UK Open Banking Standard). The API exposes two functional endpoints: an account-information endpoint for AISPs and a payment-initiation endpoint for PISPs. ASPSPs must publish sandbox environments 6 months before go-live and are prohibited from placing unnecessary obstacles on TPP access. Where an API is unavailable or underperforming, TPPs may request a contingency fallback.
Strong Customer Authentication (SCA). SCA is required whenever a payer initiates an electronic payment, accesses an account online, or carries out any remote action that may imply fraud risk. SCA demands authentication using at least two independent factors from the following three categories: something the user knows (a PIN or password), something the user has (a registered device or hardware token), and something the user is (biometric verification). The two factors must be independent such that compromising one does not compromise the other, and the resulting authentication code must be dynamically linked to the specific transaction amount and payee for electronic remote payments — so-called dynamic linking.
Exemptions. The RTS on SCA defines several risk-based and transaction-based exemptions that ASPSPs and acquirers may apply: contactless payments below €50 (cumulative €150); low-value remote transactions below €30 (cumulative €100 or five consecutive transactions); trusted beneficiaries whitelisted by the payer; recurring transactions of identical amount to the same payee; corporate inter-company payments via dedicated payment processes; and the Transaction Risk Analysis (TRA) exemption, which permits SCA to be bypassed for remote card-not-present transactions below specified thresholds, conditional on the PSP maintaining fraud rates beneath reference levels published in the RTS (0.13% for transactions up to €100, 0.06% up to €250, 0.01% up to €500).
TPP lifecycle. A fintech wishing to act as an AISP or PISP applies to its home-state NCA, passes a fit-and-proper assessment, demonstrates professional indemnity insurance or a comparable financial guarantee, and receives registration (AISP) or authorisation (PISP). The authorisation may then be passported across the EEA under standard PI/EMI passporting procedures, enabling pan-European service provision without separate licences in each jurisdiction — a critical advantage for fintechs building multi-country products.
PSD2's primary instrument is Directive (EU) 2015/2366 itself, supplemented by the SCA/CSC Regulatory Technical Standards in Delegated Regulation (EU) 2018/389. Enforcement responsibility rests with NCAs: for example, the De Nederlandsche Bank (DNB) in the Netherlands, the Autorité de Contrôle Prudentiel et de Résolution (ACPR) in France, and the National Bank of Belgium (NBB) in Belgium. The European Banking Authority (EBA) coordinates supervisory convergence, maintains the EBA Register of payment and e-money institutions, and publishes binding Guidelines on PSD2 topics including fraud reporting, incident notification, and SCA application.
PSD2 imposes specific obligations on all PSPs: segregation of client funds (safeguarding), transparent pricing and information disclosures, maximum liability rules for unauthorised transactions (€50 payer liability cap), prohibition on surcharging for standard payment instruments (extended from PSD1), and mandatory reporting of major operational or security incidents to the NCA within prescribed timeframes.
PSD3 and PSR transition. The European Commission published its proposals for PSD3 and a directly-applicable Payment Services Regulation (PSR) in June 2023. Unlike PSD2 — a directive requiring national transposition — the PSR would take effect uniformly across all member states without transposition, eliminating fragmentation. Key changes include strengthened Open Banking API performance standards, enhanced fraud liability provisions (particularly for impersonation fraud), improved access to payment systems for non-bank PSPs, and new rules on financial data access (part of the broader Financial Data Access framework under FIDA). Adoption and entry into force of PSD3/PSR is currently anticipated in late 2026, though the legislative timeline remains subject to co-legislator negotiation. Fintechs should begin gap analysis now, particularly regarding API performance benchmarks and the revised SCA rules expected to rationalise exemption frameworks.
PSD2 simultaneously creates opportunities and imposes compliance burdens. Understanding both dimensions is essential for any fintech building in the European payments space.
Licensing pathway. A firm providing only account aggregation — pulling read balances and transaction history into a dashboard — qualifies as an AISP, which requires registration (a lighter-touch process than full authorisation) and professional indemnity insurance. A firm initiating payments on behalf of users — including account-to-account (A2A) payment products — needs PISP authorisation, which carries capital requirements and a more intensive supervisory review. A firm issuing payment instruments or holding user funds requires a full EMI or PI licence. Fintechs often layer services; a product that both aggregates accounts and initiates payments needs dual registration and authorisation.
SCA implementation. SCA is not merely a checkbox — it directly affects conversion rates. Research consistently shows that poorly implemented SCA friction increases cart abandonment in e-commerce. Best practice involves intelligent exemption logic: applying TRA exemptions at the maximum permissible threshold, implementing trusted-beneficiary flows for repeat purchases, and using 3D Secure 2 (3DS2) protocol for card payments, which passes contextual data to issuers to facilitate frictionless authentication where risk is low.
API connectivity. TPPs connecting to ASPSP APIs must manage a fragmented landscape: hundreds of banks across the EEA implement Open Banking APIs to varying quality standards. Aggregator middleware providers (sometimes called TPP-as-a-service or Open Banking aggregators) normalise this connectivity into a single integration. Fintechs should assess API coverage, uptime SLAs, and fallback procedures before selecting an aggregator.
Fraud liability. Under PSD2, the default position for unauthorised transactions is that the PSP bears the loss, subject to the €50 payer contribution for gross negligence scenarios. PISPs bear specific liability for unauthorised or incorrectly executed payment initiations. Robust fraud monitoring, transaction screening, and real-time anomaly detection are not optional — they are commercially necessary and regulatorily expected. The forthcoming PSR is expected to extend liability to scenarios of authorised push payment (APP) fraud, bringing EU rules closer to the UK's mandatory reimbursement regime.
Data and consent. AISPs may only access account data with the explicit, granular consent of the account holder, which must be refreshable at 90-day intervals under the RTS. Data minimisation principles under GDPR apply in parallel, restricting AISPs from processing data beyond what is necessary for the consented purpose.
Codego is a European Banking-as-a-Service infrastructure provider operating under an NBB electronic-money distribution licence, with Codego Europe SIA advancing through the EMI authorisation process and pan-EU passporting across 12 countries. The platform is built on a PSD2-native architecture: every programme launched on Codego's core banking stack inherits SCA-compliant authentication flows from day one, with 3DS2 processing integrated at the card processing layer for both Visa and Mastercard schemes.
For fintechs building licensed payment products, Codego's white-label bank and card issuing solutions include built-in SCA orchestration, dynamic-linking for remote transactions, and configurable TRA exemption logic — reducing the engineering overhead of PSD2 compliance substantially. Native EU IBAN issuance across six countries with SEPA Instant connectivity enables PISPs to offer real-time account-to-account payment products that leverage PSD2's XS2A provisions directly.
BIN sponsorship under both Visa and Mastercard — documented in the BIN sponsorship glossary entry — means partners access scheme rails with SCA obligations already handled at the programme level, with Apple Pay and Google Pay provisioned within 24 hours. Fintechs can scope their PSD2 compliance posture and product configuration via the Codego self-service portal. To discuss how your programme fits within the PSD2 framework and what licensing steps apply, visit the programme enquiry page.