PSD2 for software teams
How the EU's second Payment Services Directive shapes login and checkout with strong customer authentication, opens bank accounts to licensed third parties, and sets who pays when a payment was not authorised.
What PSD2 is
Directive (EU) 2015/2366 on payment services in the internal market (Payment Services Directive 2)
PSD2, Directive (EU) 2015/2366, is the EU law on payment services. Member states have applied it since 13 January 2018. Its security rules, including strong customer authentication, apply under technical standards in Delegated Regulation (EU) 2018/389, in force since 14 September 2019.
For software teams it does three big things. It requires strong customer authentication (SCA) for logins and payments, with set exemptions. It gives licensed account information and payment initiation providers the right to access payment accounts, which is the legal base of open banking in the EU. And it sets refund and liability rules for unauthorised payments.
As a directive, PSD2 works through national laws, such as the Payment Services Regulations 2017 in the UK, which still apply there after Brexit. A Payment Services Regulation and PSD3 have been agreed to replace it, but are not yet in force.
Who it applies to
Payment service providers
Banks, payment institutions and e-money institutions that run payment accounts, issue cards, acquire payments or move money in the EU.
Account information and payment initiation providers
Licensed third parties that read account data or start payments through banks' interfaces, such as budgeting apps and pay-by-bank checkouts.
Merchants and platforms
Not regulated by PSD2 directly in most cases, but their checkout must support SCA through their payment provider, and some platform models need a licence or an exemption.
Cash payments, most payments through commercial agents acting only for one side, limited networks such as some store cards, and payments where neither provider is in the EU are outside or only partly inside PSD2. Exemptions are narrow, so check the specific model with your payment provider or advisor.
Key requirements, and what they mean for the build
Each row links the official text. Read the source for the exact wording before you rely on it.
Strong customer authentication
Payment providers apply SCA when a payer accesses an account online, starts an electronic payment, or does anything remotely that could imply a risk of fraud. SCA uses two independent elements from knowledge, possession and inherence.
Use your provider's SCA flow, such as 3-D Secure for cards or the bank's app, and design login and checkout so the challenge step fits without losing the user.
Dynamic linking
For remote payments, the payer sees the amount and payee, the authentication code is specific to that amount and payee, and any change invalidates it.
Never change the amount or payee after authentication. If the basket changes, authenticate again.
Source: Delegated Regulation (EU) 2018/389: RTS on strong customer authentication, EUR-Lex
SCA exemptions
Providers may skip SCA in set cases, such as contactless payments up to EUR 50, low-value remote payments up to EUR 30 within cumulative limits, transaction risk analysis for low-risk payments, and account data viewed through an AISP within 180 days of the last SCA.
Exemptions are the provider's decision. Pass the data they need for risk analysis, and handle a challenge whenever an exemption is refused.
Source: Delegated Regulation (EU) 2022/2360: amended 90-day exemption, EUR-Lex
Payment initiation and account information access
Payers have the right to use licensed payment initiation and account information providers. AISPs act only with the user's explicit consent and keep credentials safe.
Record consent with scope and expiry, show users which accounts are connected, and let them revoke access in one step.
Bank access interfaces
Banks with online accounts provide at least one interface for licensed third parties, and a contingency plan if a dedicated interface fails.
If you build for a bank, monitor API availability and response times against the rules. If you consume bank APIs, handle outages and re-consent cleanly.
Source: Delegated Regulation (EU) 2018/389: RTS on strong customer authentication, EUR-Lex
Refunds for unauthorised payments
The payer's provider refunds an unauthorised payment immediately, and no later than the end of the next business day, unless it suspects fraud and tells the authority. The payer may bear up to EUR 50 for a lost or stolen instrument, with exceptions.
A dispute flow with time stamps, and authentication evidence stored for every payment so authorised and unauthorised can be told apart.
Operational and security risk
Providers run a framework to manage operational and security risks with incident procedures, assess those risks at least yearly, and report major incidents without undue delay.
Fraud monitoring, incident runbooks and security reporting built into operations, aligned with DORA for firms it covers.
Engineering controls for PSD2
How the rules change the way the software is designed.
- 01
SCA-ready flows
Login and checkout designed around the challenge step, with fallbacks when an exemption is refused or a device is new.
- 02
Authentication evidence
For each payment, which factors were used, when, on which device, and the amount and payee they were bound to.
- 03
Consent records
Account access consent with scope, accounts, expiry and revocation, visible to users.
- 04
Risk data for exemptions
Device, behaviour and transaction data passed to the provider so low-risk payments can skip a challenge.
- 05
Disputes and refunds
A claim flow with the next-business-day clock built in, and evidence to support each decision.
- 06
Credential safety
Bank credentials never stored or seen by the app. Access goes through tokens from the bank's interface.
- 07
Interface monitoring
Availability and response times of bank APIs tracked, with alerts and contingency paths.
- 08
Fraud monitoring
Transaction monitoring that feeds risk analysis, flags suspicious payments and supports fraud reporting.
Key dates
- 13 January 2018Member states apply PSD2.
- 14 September 2019The SCA and secure communication standards apply.
- 25 July 2023Account data viewed through an AISP needs SCA only every 180 days, not every 90.
In November 2025 the Parliament and Council agreed a Payment Services Regulation and a third Payment Services Directive (PSD3) to replace PSD2, with stronger fraud rules such as a payee name check. They are not law until formally adopted, so check their status before planning around them.
Checked against the official sources on 2026-10-25.
21 OceanLab product builds cite PSD2
Counted from our published case studies: a build counts when PSD2 is in the list of rules it was built for.
Lotse - Open Banking Aggregator Operations Console
Designed and built a clickable operations console for a Hamburg account information service provider that connects fintechs to German bank accounts under PSD2: bank connector health, incidents, and every consent from grant to the 180-day re-authentication.
Keystep - Digital Bank Onboarding with ID, Liveness and Risk-Based Review
An onboarding platform for an Irish digital bank: applicants open a EUR current account from their phone with ID and selfie liveness checks, and a staff console lets onboarding and financial crime teams review the cases the rules cannot decide, through to an issued Irish IBAN.
Financia - Personal Finance Console with AI Cashflow Insights
Built a personal finance dashboard that ingests transactions across accounts, attributes spend by category, surfaces AI cashflow insights, and runs a live budget tracker with goal setting - shipped from clickable AI prototype to production in 10 weeks.
Écluse - Subscription Tracker That Finds, Cancels and Checks Every Recurring Charge
Designed and built a clickable subscription tracker for a Lyon consumer app company: it finds the recurring charges in a member's bank accounts, explains which French consumer rule lets them leave, writes the cancellation letter or email, and watches the account until the charges really stop.
Rastro - Corporate Cards and Spend Management with IVA-Ready Receipts
Designed and built a clickable spend-management platform for a Valencia fintech that gives Spanish SMEs company cards: budgets and card controls checked at authorisation, every transaction matched to its receipt, IVA marked recoverable or not from the invoice type, and a keyboard-driven review queue that turns card spend into bookable entries.
Kladde - AI Bookkeeping for German Freelancers and Small Firms
Designed and built a clickable AI bookkeeping product for German freelancers, sole traders and small GmbHs: a bank feed with a suggested booking and confidence score on every payment, a receipt inbox that validates e-invoices and checks §14 UStG fields, and a VAT advance return previewed box by box and submitted through ELSTER.
Every build that cites PSD2
- Almendro - Hotel booking engine
- Écluse - Subscription tracker
- Financia - Budget & spending tracker
- Hut to Hut - Mountain hut booking
- Keystep - Digital bank onboarding
- Kirbu - Resale marketplace
- Kladde - SME bookkeeping with AI
- Kranich - Donation checkout
- Lotse - Open banking aggregator
- Mjera - Product configurator
- Pasje - Card issuing & controls
- Pontje - eSIM onboarding
- Posodi - Rental marketplace
- Postigo - Click & collect
- Rastro - Corporate cards & spend
- Sailings - Island ferry booking
- Slenkstis - Rental applications
- Stožiar - EV charging app
- Tartera - Headless storefront
- Tessera - Gym & class booking
- Voltone - Car sharing app
Check your product
Other frameworks and industries
Build with PSD2 in mind from day one
Project build
We design and build the system as one project. It starts with a clickable prototype your team tries before any production code is written. Pay per milestone (outcome-based) or hourly at $30-50/hr, depending on role and seniority.
Embedded engineers
Our engineers join your team on a flexible monthly retainer. Part-time is fine and it runs month to month, with hours that overlap the US, UK and Europe, the Middle East, and Australia and Asia. Outcome-based or $30-50/hr.
PSD2 questions
Does SCA apply to every card payment?
No. It applies when the payer starts an electronic payment, and the standards allow exemptions such as low-value and low-risk payments. Payments started by the merchant rather than the payer, such as some subscriptions, are handled differently, so ask your payment provider how it treats them.
Who decides whether an exemption applies?
The payment provider, usually the card issuer or the bank. A merchant can ask for an exemption through its acquirer, but the issuer can still require a challenge, so checkout must handle both.
Do we need a licence to build a budgeting app?
Reading bank data on a user's behalf is an account information service, which needs registration. Many apps instead work with a licensed provider that holds the registration and offers the bank connections as a service.
Does PSD2 still apply in the UK?
The UK implemented PSD2 through the Payment Services Regulations 2017, which still apply, with UK changes made since. UK rules and FCA guidance now develop separately from the EU.
How does OceanLab approach PSD2 on a build?
We design login and checkout around SCA from the first prototype, keep consent and authentication evidence on every payment, and plan for exemptions being refused. The builds below list PSD2 in the rules they were built for.
Official sources
- Directive (EU) 2015/2366 (PSD2), EUR-Lex
- Delegated Regulation (EU) 2018/389: RTS on strong customer authentication, EUR-Lex
- Delegated Regulation (EU) 2022/2360: amended 90-day exemption, EUR-Lex
- UK Payment Services Regulations 2017, legislation.gov.uk
- European Parliament: payment services deal (PSR and PSD3), 27 November 2025
