PSD3 + PSR1: what bank CTOs need to plan before Q4 2026.

Payment Services Directive 3 + Payment Services Regulation 1: trilogue finalising 2026, transition window 2027-28. What changes vs PSD2, what's the practical roadmap for a tier-1 bank, and where Coreal sits in the transition. SCA evolution, open banking premium APIs, fraud liability shifts.

The 2026 transition window

The European Commission's review of PSD2 concluded that the directive had succeeded in some areas (it created the licensed PSP/EMI category, it enabled open banking) and failed in others (open banking adoption uneven, SCA implementation patchy, fraud rising despite stronger authentication). The proposed replacement comes in two parts:

1. PSD3 (Payment Services Directive 3) — directive replacing PSD2 (Directive (EU) 2015/2366). Authorisation, prudential supervision, and the harmonised regulatory landscape.

2. PSR1 (Payment Services Regulation 1) — regulation, directly applicable in member states, covering operational rules: SCA, open banking access, fraud liability, transaction-monitoring requirements.

The trilogue (final negotiation between Council, Parliament and Commission) is expected to finalise in late 2026. Transitional periods will likely extend into 2027-28 for full implementation, with some operational provisions binding earlier. The European Banking Authority has signalled draft RTS/ITS will publish in tranches throughout 2027.

This essay is the practical roadmap for what a tier-1 bank CTO needs to plan during this transition window — what changes, what's controversial in the draft, and where the implementation cost sits.

What changes vs PSD2 — the operational diff

1. SCA scope and exemptions tightened

PSD2's SCA framework (Article 97) had multiple exemption categories that became operationally useful: low-value transactions (Art. 16 of the RTS), trusted beneficiary (Art. 13), recurring payments (Art. 14), corporate payment (Art. 17), transaction risk analysis (Art. 18). The TRA exemption in particular let high-quality risk engines avoid friction on 80%+ of transactions.

PSR1's draft (as of 2026 trilogue position) tightens this in two ways:

• TRA exemption thresholds drop (proposed: €30 → €15 for "very low risk", scaling proportionally)
• Recurring payment exemption requires explicit per-transaction consent (current: blanket consent at mandate setup)
• The "trusted beneficiary" list maintenance shifts more burden to the bank (the customer can add but the bank's risk engine has to evaluate continuously)

Bank-side cost: re-tune the TRA model to lower thresholds. For most tier-1 banks this is a 2-4 quarter project including model retraining + regulator validation. Expect SCA friction to increase 12-18% on retail transactions in the first quarter post-PSR1 unless the bank pre-tunes.

2. Open banking — from access to monetisation

PSD2 mandated free access for licensed AISPs and PISPs. The commercial model that emerged: banks built compliant APIs, no revenue, AISPs/PISPs built businesses on free data.

PSR1 introduces a two-tier model:

• Tier 1 (mandated, free) — basic account information, transaction list, initiating payments. Same as PSD2.
• Tier 2 (commercial, paid) — advanced data products, premium SLAs, real-time push notifications, richer account aggregation. Banks can monetise.

This is the biggest commercial opportunity for banks in PSR1. Tier-2 APIs are a new revenue stream estimated at €200-400M/year for a tier-1 bank with 7M+ retail customers, if priced and packaged correctly.

Bank-side requirement: build a developer platform with metered API access, OAuth scopes for tier-2, billing infrastructure, and SLA management. Most banks don't have this infrastructure today — they have a tier-1 compliant API and nothing more.

This is one of the new product surfaces where we (Coreal) come in directly. The platform layer for a tier-2 monetisable API runs cleanly on Coreal's BPM + ledger + decision-journal infrastructure (same pattern as Wave-2 card-to-card).

3. Fraud liability shift to PSPs

Under PSD2 Article 74, an unauthorised transaction's loss falls on the bank unless the customer was grossly negligent. PSR1 expands this in two directions:

• Authorised push payment (APP) fraud liability shifts to PSPs in many cases. Currently, if a customer is socially engineered into approving a fraudulent payment, the bank's liability is limited. PSR1 increases PSP liability for APP fraud where the PSP "should have detected" the fraudulent pattern. The "should have detected" bar is the area still being debated in trilogue.
• PSP-to-PSP cooperation requirements on fraud detection. The receiving PSP has new obligations to share fraud signals with the sending PSP within tight timeframes (5 minutes for cross-border, 15 minutes for cross-bank within member state).

Bank-side cost: significant. APP fraud is currently 15-22% of total fraud losses for tier-1 EU banks; if liability shifts to the PSP, the loss line moves by €40-80M/year for a tier-1 bank. The mitigation is upstream — better fraud detection, faster receiving-side intervention, customer education.

The cross-PSP fraud-signal sharing requires new infrastructure. Coreal's payment-orchestration layer (part of the platform) integrates with the cross-PSP signal-sharing scheme that the EBA is defining.

4. Authorisation streamlining (PSD3)

PSD3 consolidates the PI (Payment Institution), EMI (Electronic Money Institution) and AISP/PISP categories into a more harmonised authorisation framework. The EMI/PI distinction loses some of its bite — both will operate under a similar capital-requirement and supervisory framework.

Bank-side impact: not significant for tier-1 banks (they already have full banking licences). Significant for fintech partners — the licence acquisition process for new PSPs gets faster, the dual-licensing pattern (PI+EMI to cover all payment services) becomes less common.

5. Direct supervision powers

PSR1 (being a regulation, not directive) gives EBA direct supervisory powers in certain cases, particularly for cross-border PSPs. Currently EBA coordinates through national competent authorities; PSR1 lets EBA take direct action on systemic PSP failures.

Bank-side impact: moderate. Tier-1 banks already deal with ECB SSM (Single Supervisory Mechanism), so a parallel EBA payment-side supervisor is more notification-burden than substance change.

What's in trilogue (not yet final)

The 2026 trilogue negotiations are still active on three points that affect implementation cost:

1. APP fraud liability "should have detected" standard. Council position: stricter — bank liable in most reasonable-suspicion cases. Parliament position: stricter still — bank liable unless can prove customer was grossly negligent. Commission position: middle ground. Most banks are budgeting for the Council position (most expensive); if Parliament wins, costs go up further.

2. Tier-2 API pricing rules. Council wants market-set pricing. Parliament wants regulated price ceilings to ensure fintech ecosystem doesn't get priced out. The outcome determines whether €200-400M tier-2 revenue projection holds.

3. SCA exemption recalibration timeline. Council wants 12-month transitional period for TRA model retuning; Parliament wants 6-month. The 6-month version forces tier-1 banks into emergency model-retraining mode.

The CTO's planning horizon should assume the strictest position on each, with the option to relax if trilogue lands more favourably. Worst-case planning costs nothing extra; surprise from a stricter-than-expected position costs quarters.

What a tier-1 bank CTO needs to plan in Q2-Q4 2026

Q2 2026 (now-ish)

• Inventory: all payment flows in scope. Most banks don't have a consolidated inventory; this is the first deliverable. Coreal partners get a pre-templated inventory format that aligns to PSR1's likely categories.
• TRA model audit: when was your transaction risk analysis model last retrained? What's its false-negative rate? If you can't answer in numbers, the model is not PSR1-ready.
• Open banking API architecture review: can you support tier-2 metering, OAuth scope expansion, SLA management? If not, what's the gap to closing it?

Q3 2026

• TRA model retraining initiated with the proposed PSR1 thresholds. 4-6 months of model + regulator validation.
• Tier-2 API product strategy. Pricing model. Packaging. Developer portal design. This is more product than engineering at this stage.
• Cross-PSP fraud signal architecture. Integration with whichever scheme the EBA finalises (signals point to a SWIFT-extended or EBA-Clearing-extended mechanism).

Q4 2026 (assuming trilogue finalises)

• PSD3 transposition impact assessment. Member-state transposition windows typically 18-24 months. Plan for early-2028 binding date.
• Customer communication strategy. APP fraud liability shift requires customer-side education campaign.
• Internal training. Compliance, risk, payment-ops teams.

Q1 2027

• PSR1 binding date likely lands here for the operational provisions (SCA, fraud, open banking). Direct effect.
• Tier-2 API beta to early developer partners.
• First fraud-signal cooperation cycles with peer banks.

Q3-Q4 2027

• Full PSR1 operational regime in production.
• Tier-2 API revenue line starting to materialise.
• Real APP fraud liability numbers visible in operating losses for the first time.

2028

• PSD3 transposition complete in all member states.
• Stable operating model under the new regime.
• First year of measurable tier-2 API revenue.

What Coreal partners get out of the box

For banks on a Wave-1 or Wave-2 engagement, the PSR1 readiness work fits naturally:

• The decision journal (architectural piece) already captures the audit trail PSR1 requires for SCA, fraud disposition, and AISP/PISP access.
• The payment orchestration layer integrates with the EBA's cross-PSP fraud-signal scheme out of the box (we ship the connector as the EBA finalises the spec).
• The BPM workflow engine can route APP-fraud-flagged transactions through the new mandatory cooperation flow with peer PSPs.
• The tier-2 API monetisation infrastructure — OAuth scope management, metering, billing, SLA tracking — is the same architecture as our pSEO integration pages demonstrate at scale.

For a bank starting PSR1 readiness with Coreal in Q3 2026, the operational gap to a Q1 2027 binding date is closeable. For a bank starting in Q1 2027, it's behind.

A note on PSD2 → PSD3 strategic shape

PSD2 was a directive that succeeded technically (it forced banks to expose APIs) and failed commercially (it gave the revenue stream to fintechs, not banks). PSD3 + PSR1 corrects this — Tier-2 monetisable APIs are a clear commercial corrective.

But the shift isn't automatic. Banks that built minimal-compliant PSD2 APIs (most of them) won't be ready for Tier-2 monetisation without significant infrastructure investment. Banks that built proper developer platforms in 2018-2020 (a small number — mostly the open-API enthusiasts: BBVA, Starling, OBE-active UK banks) have a 24-36 month head start.

The window for banks that didn't build properly in 2018 is now. Wave-1 in 2026, Wave-2 in 2027, Tier-2 revenue scaling in 2028-29. That's the only path that gets a tier-1 EU bank to meaningful API revenue by 2030.

The cost of staying compliant-only on PSD2 → PSR1 transition is low (€20-50M for the regulatory remediation alone). The cost of capturing the tier-2 opportunity is higher (€50-100M for proper platform investment) but unlocks the revenue line. The strategic question is whether the bank's board sees this as a regulatory burden or a commercial opportunity.

In our experience with tier-1 CEE banks, the boards that frame PSR1 as opportunity are running 18 months ahead of those that frame it as burden. By 2030 this will be visible in the operating margin difference.

Engagement-side note: PSD3/PSR1 trilogue is still active as of mid-2026. The positions I've described reflect the December 2025 / early 2026 negotiating texts; final positions may shift. For a PSR1 readiness review scoped to your specific payment-flow inventory, book a working session →. For the architectural foundation, see /platform and /solutions/banks.