Under the EU's new Payment Services Regulation, a bank's open banking API counts as down once five consecutive requests get a server error or no answer within 30 seconds. The same text makes the payer's bank refund a scam payment if it cannot prove that both its own systems and the payee's bank ran transaction monitoring. Neither rule turns up in most of the pages ranking for "PSD3 vs PSR".
Those pages have a second problem. Several still quote the 2023 proposal: an 18-month transition, 365-day reauthentication for account information services, publication in the first half of 2026. The Council's final compromise texts of 17 April 2026 (documents 8221/26 for the PSR and 8222/26 for PSD3) say 21 months and 180 days. As of today neither text has reached the Official Journal.
This guide works from those texts. Article numbers may still shift during legal-linguistic review, but the mechanics are settled.
What Is the Difference Between PSD3 and the PSR?
The split follows the legal instrument. PSD3 is a directive, so each member state transposes it into national law. The PSR is a regulation and applies directly, with no national rewrite.
| PSD3 (Directive) | PSR (Regulation) | |
|---|---|---|
| Covers | Authorisation, capital, safeguarding, supervision | Conduct, fraud, open banking, SCA, access to payment systems |
| Replaces | PSD2 licensing rules and the E-Money Directive (EMD2) | PSD2 conduct rules and the SCA RTS model |
| National variation | Yes, via transposition | Minimal |
| Who reads it | Compliance and licensing teams | Engineering, fraud and product teams |
PSD3 folds e-money into the payment institution regime, so EMIs become payment institutions that also issue e-money. Initial capital runs from €40,000 to €250,000 depending on the services a firm provides. It also amends the Settlement Finality Directive, which lets non-exempt payment institutions join designated payment systems directly rather than through a sponsor bank.
The engineering work sits almost entirely in the PSR.
When Do PSD3 and the PSR Apply?
The timeline so far:
- 27 November 2025: provisional trilogue agreement.
- 17 April 2026: Council publishes the final compromise texts.
- 5 May 2026: the European Parliament's ECON committee approves them.
- Now: the Parliament's Legislative Observatory lists an indicative plenary date of 14 December 2026 for the second-reading vote.
| Provision | Applies from |
|---|---|
| Most of the PSR; PSD3 transposition deadline | Entry into force + 21 months |
| Art 50 (payee name check on all credit transfers) and Art 57 (liability for it) | Entry into force + 27 months |
| Art 85a (no repeat SCA for recurring credit transfers) | Entry into force |
| Existing PIs and EMIs must be reassessed | By entry into force + 27 months, or suspended |
My estimate: if the December plenary holds and publication follows in early 2027, most of the PSR applies around the end of 2028 and the name-check extension in spring 2029. That sounds generous until you notice the main EBA RTS on SCA, dedicated interfaces and monitoring is due a year after entry into force. You will build against standards that arrive with about nine months to spare.
What Does the PSR Require From Open Banking APIs?
PSD2 left most interface detail to an RTS and to national regulators. The PSR moves it into Articles 35 to 45, in the regulation itself.
Is There a Mandatory EU Open Banking API Standard?
No. Article 35 requires a dedicated interface based on "CEN/ISO or equivalent" recognised standards, which Berlin Group, STET and the UK Open Banking standard can all claim. The obligations sit around the spec rather than in it:
- free technical documentation, with a public summary
- at least two months' notice of changes to the specification
- a testing facility that uses no real customer data
- error messages that explain the cause
- quarterly published statistics on availability and performance, set against the bank's own customer channels
When Is a Dedicated Interface Legally "Unavailable"?
This is the most useful number in the regulation for anyone running a TPP. Article 38(1) presumes unavailability when five consecutive requests receive server errors or no response within 30 seconds. Planned downtime needs a month's notice and should normally fall between 00:00 and 06:00.
If your AIS or PIS client logs status and latency per request per ASPSP, you can prove a presumed outage from your own data. Put a circuit breaker on that exact threshold and keep the evidence when it trips.
The standing fallback interface from the PSD2 RTS is gone. Under Article 39, a national authority can still exempt a bank, allowing it to offer its customer interface instead or, "where justified", no dedicated interface at all. Pages saying "fallback abolished" miss that exemption.
What Must the Open Banking Permission Dashboard Show?
Article 43 makes the bank build a dashboard inside its own app or website. It covers account information consents and payment initiation consents for multiple or recurring payments. One-off payment consents stay off it. For each consent it must show:
1. the TPP's name 2. the account accessed 3. the purpose 4. validity period and grant date 5. data categories shared 6. the dates on which data was actually accessed
Users can withdraw one TPP or all of them, free of charge, and re-establish a withdrawn consent within 48 hours. The bank keeps a two-year record of withdrawn and expired consents. After a withdrawal the TPP must stop using the data and delete it without undue delay, but not before 48 hours have passed, because the user may undo it. Both sides must push consent changes to each other "without undue delay".
That last requirement is an event API that nobody has specified yet. A TPP needs a consent state machine with a withdrawn_pending_deletion state and a 48-hour timer, and it has to receive withdrawals from the bank rather than finding out through a 401 on the next poll.
Which Open Banking Obstacles Does Article 44 Ban?
Article 44 lists twelve prohibited obstacles. The ones that change flows:
- making the user type an IBAN manually inside the bank's domain
- restricting initiated payments to the user's existing beneficiary list
- accepting only domestic account identifiers
- adding more SCA steps than the bank's own journey, or extra screens in a redirect or decoupled flow
- not supporting every authentication method the bank offers its own customers
- requiring two SCAs in a payment-initiation-only flow
Does the PSR Change 90-Day Reauthentication for AIS?
Yes, and this is where EU and UK flows diverge. Under PSR Article 86, the bank applies SCA only on a TPP's first access to an account. After that, the account information provider applies SCA at least every 180 days, using its own SCA or the bank's.
The UK went a different way in 2022. Under the FCA's PS21/19, the bank applies SCA once and the TPP then asks the customer to reconfirm consent every 90 days, with no SCA involved. An aggregator covering both markets therefore needs two re-consent schedules: a 90-day reconfirmation screen in the UK and a 180-day SCA event in the EU. For the EU event it also has to decide whether to build its own SCA or send the user back to the bank.
Who Pays for Payment Fraud Under the PSR?
The PSR spreads liability across four articles.
Article 50 extends payee name checking, already live for euro credit transfers under the Instant Payments Regulation since 9 October 2025, to all credit transfers, and applies at the 27-month mark. It copies the IPR model, where the payer is warned and can still proceed. The Parliament's press release said the bank would "have to refuse" a mismatched payment. The article text does not say that. The response codes and timing are covered in my Verification of Payee API guide. Article 59 covers impersonation fraud. If someone posing as the consumer's own bank, using channels attributed to that bank, manipulates them into paying, the bank refunds in full, provided the consumer promptly told the bank and reported it to the police. Within 15 business days the bank either refunds or justifies refusal on grounds of fraud or gross negligence, and the burden of proof is on the bank. There is no cap. Someone impersonating a courier, a tax authority or a romance interest is not covered. Article 83 is the one I'd lose sleep over. The payer's bank must monitor before execution, and the payee's bank must monitor before funds are made available. If the payer's bank cannot show evidence that both did, it refunds the payer. Each bank therefore needs a record of its own monitoring decision, plus a way to obtain proof of the payee bank's, per transaction. No scheme message carries that today. Article 83a makes fraud data sharing mandatory. Data should be pseudonymised where possible, retention is capped at five years, behavioural biometrics are excluded, and a bank may not offboard a customer on shared data alone.Article 51 adds user-set spending limits. By default a remote request to raise a limit waits four hours, which the user can opt out of, and a blocked instrument must be reassessed within two business days.
For breaches of the open banking, fraud and SCA chapters, member states must allow maximum fines of at least 10% of annual turnover for legal persons.
PSR vs UK APP Fraud Reimbursement: Which Covers More?
The UK has run mandatory authorised push payment (APP) reimbursement since 7 October 2024. Comparing the two is the quickest way to see how narrow the EU refund is.
| EU PSR (Art 59) | UK APP reimbursement | |
|---|---|---|
| Scam types covered | Impersonation of the victim's own PSP only | All APP scam types |
| Cap | None | £85,000 per claim |
| Deadline | 15 business days to refund or justify | 5 business days, 35 with stop-the-clock |
| Conditions | Prompt notice to the PSP plus a police report | Consumer standard of caution; optional £100 excess |
| Who pays | The consumer's own PSP | 50:50 between sending and receiving PSP |
| Rails | All payment transactions in scope of the PSR | Faster Payments and CHAPS |
| Status | Not yet in the Official Journal | Live; 89% of claim value reimbursed in Q1 2026 |
The UK scheme is broader, faster and capped. The EU refund is narrower, slower and uncapped. The EU makes up for that with Article 83, which has no direct UK equivalent, so a bank that skipped monitoring can end up paying for a scam type Article 59 would never have covered.
The UK also gives banks a brake the EU does not. Since 30 October 2024, SI 2024/1013 has let a UK PSP delay an outbound payment until the end of the fourth business day after receipt where it has reasonable grounds to suspect fraud.
Does PSD3 Apply in the UK?
No. The UK left before PSD3 was proposed and is reforming its own regime separately. HM Treasury's Modernising Payment Services Regulation consultation, published 14 July 2026, closes on 6 October 2026. It proposes to:
- keep the perimeter and core protections in legislation and move technical detail into the FCA rulebook
- revoke the SCA provisions so the FCA can write outcomes-based rules
- not merge e-money and payment institutions. It splits issuing and acquiring into separate activities and keeps e-money issuance as its own activity, the opposite of PSD3
- bring UK-issued qualifying stablecoins inside the payments perimeter
- create a statutory right of access for variable recurring payments
- lay an Open Banking statutory instrument under the Data (Use and Access) Act 2025 by the end of 2026
For scale: Open Banking Limited's July 2026 figures show 2.936 billion successful API calls at 99.54% success and 330ms average response. The commercial layer is in my VRP API guide.
My Prediction: SCA Is Where EU and UK Payments Split for Good
This is opinion. UK and EU payments rules have shared one skeleton since Brexit: PSD2 and the SCA RTS. These two reforms end that. The EU is writing more SCA into law, with new triggers for remote token creation, spending-limit increases and credential changes, plus mandatory non-smartphone methods under Article 88. The UK is taking SCA out of legislation altogether.
By 2029 I expect "SCA required?" to be a per-jurisdiction policy lookup in any serious payments stack rather than a shared library call. Firms that hard-coded PSD2's exemption logic will rewrite it twice. Keep SCA decisions as configuration keyed by jurisdiction, product and consent type, and log the rule version that made each decision.
What This Means for Payment Engineers in the EU and UK
1. Instrument your TPP client against Article 38 now. Log status and latency per ASPSP per request, and alert on five consecutive failures or 30-second timeouts. The evidence will be worth something the day the regulation applies. 2. Model consent withdrawal as a state, not a delete. Add a 48-hour pending state, handle re-establishment, and plan for a push channel from banks. 3. Split AIS re-consent by market. 90-day reconfirmation for the UK, 180-day SCA for the EU, and decide who performs the EU SCA. 4. Store monitoring decisions per transaction as evidence you can hand over, not only as a fraud score. Article 83 turns missing evidence into a refund. 5. Don't assume the identifier is an IBAN for name checks. Article 50 reaches non-euro and non-SEPA credit transfers. 6. Don't merge your PI and EMI licensing models on the assumption that the UK will follow PSD3. The Treasury consultation keeps them separate. 7. Answer the Treasury consultation before 6 October if you run UK flows. Its question on agentic payment consent and liability needs engineers, not only lawyers.
UK safeguarding has its own ledger rules, covered in my CASS 15 reconciliation guide. More of my payments work is at Tom Wang.