PSD2 and Open Banking
The EU directive and UK regulatory framework that mandated API access to bank accounts for third parties — creating the technical infrastructure for open banking ecosystems.
The Payment Services Directive 2 (2015/2366/EU), effective January 2018, required banks and payment service providers to open access to customer account data and initiate payments through APIs to licensed Third Party Providers (TPPs) — Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs). PSD2 Article 98 delegated technical standards to the EBA, which produced the Regulatory Technical Standard (RTS) on Strong Customer Authentication (SCA) and Common and Secure Open Standards of Communication (CSC). PSD2 mandated SCA for online payments and account access, requiring at least two of three authentication factors (knowledge, possession, inherence). The RTS requires banks to provide dedicated interfaces (APIs) for TPP access or to adapt their customer interface (with a fallback mechanism). Exemptions from SCA include low-value transactions (<€30), trusted beneficiaries, and corporate payments with dedicated payment processes. The Berlin Group NextGenPSD2 framework and the STET API specification are the two major technical standards for PSD2 API implementation in Europe.
The engineering reality of PSD2 Open Banking is that the standard is fragmented. Unlike a single mandated API specification, PSD2 led to multiple competing API frameworks across Europe (Berlin Group, STET, UK Open Banking standard, Polish API). The UK implemented Open Banking independently from PSD2 through the Competition and Markets Authority (CMA) Order 2017, which mandated the UK Open Banking Implementation Entity (OBIE) standard (now OpenBankingLtd) for the nine largest UK banks. The OBIE standard uses Financial-grade API (FAPI) 1.0 security profile, which mandates MTLS client authentication, Proof Key for Code Exchange (PKCE), and structured consent objects. SCA implementation — the authentication mechanism — is technically complex: banks must support app-to-app redirects, decoupled authentication flows, and embedded flows, each with different UX and security properties. Consent management — tracking granular user consent for different data scopes with defined expiration and revocation capabilities — requires a consent management service that is a non-trivial system component.
PSD2 is being superseded by PSD3 and the Payment Services Regulation (PSR) proposed by the European Commission in 2023, which will replace the PSD2 Directive with a directly applicable Regulation. PSD3/PSR introduces enhanced open banking rights, improved data access rights, stronger SCA requirements, and clearer liability allocation for fraud. The UK's diverging path — the Joint Regulatory Oversight Committee (JROC) roadmap and Payments Vision 2033 — is extending UK Open Banking through Variable Recurring Payments (VRP), premium APIs, and open finance (extending beyond bank accounts to investments, pensions, insurance). For API implementations, this creates an ongoing versioning challenge: the Berlin Group NextGenPSD2 framework is at version 1.3.x while UK OBIE has released successive versions. Financial institutions must support multiple API versions during transition periods while managing TPP developer experience.
We implement PSD2 and UK Open Banking APIs using the appropriate regional standard (Berlin Group NextGenPSD2 for EU, OBIE for UK), built on FAPI 1.0 security profiles with MTLS, PKCE, and structured consent. Our SCA implementations support all mandated authentication flows — redirect, app-to-app, decoupled — with a unified authentication service that manages SCA challenge issuance and verification across channels. We build consent management services with full lifecycle management: consent creation, scope tracking, usage logging, expiration enforcement, and TPP-initiated and customer-initiated revocation, all with audit trails meeting PSD2 recordkeeping requirements.
Compliance-Native Architecture Guide
Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.