PSD2 to PSD3 for Platform Operators: What to Implement Now, Stage for Later, and Escalate Early

What to implement now, what to stage, and what to escalate#

If you run a platform and need decisions now, start with one split. Decide what to implement immediately, what to keep reversible while PSD3 and the Payment Services Regulation (PSR) details are still unsettled, and what to escalate to specialist review before it hardens into product or policy.

This guide is for live operating decisions across compliance, risk, finance, ops, and engineering. It is not a headline recap of PSD2, PSD3, or open banking proposals. It is a control-focused way to sequence work while key details are still moving. As you read, sort each item into three buckets:

• Implement now for no-regret controls that improve evidence, ownership, monitoring, and decision quality.
• Stage for later where requirements are still draft-shaped or operating standards are not settled.
• Escalate early when interpretation could affect customer outcomes, market rollout, or multi-Member-State operations.

A practical checkpoint is to keep a short decision record for each material requirement with the owner, trigger, current interpretation, retained evidence, and next review date. If those fields are unclear, risk is already building.

Scope discipline matters. This article stays focused on payment-regulation operations under uncertainty and does not assume final PSD3/PSR legal text, enforcement dates, or transition timelines. It does not merge those topics with privacy or tax regimes. Keep GDPR controls and evidence separate from payments controls. If that workstream is active, a focused guide like GDPR for Marketplace Platforms: How to Handle Contractor and Seller Personal Data Compliantly is more useful than a combined policy.

Keep the same separation on tax. EU VAT e-commerce rules affect marketplaces and platforms across the supply chain. Platforms can be deemed suppliers for VAT in some cases, and record-keeping duties apply when facilitating goods and services. If you use OSS, treat it as an added filing layer, not a full replacement for domestic VAT returns. These regimes may connect operationally, but they still need separate ownership, records, and escalation paths, including VAT Cross Border Rulings requests in the participating EU country where you are VAT-registered.

The goal is disciplined sequencing. Make no-regret decisions now, keep draft-dependent changes versioned and reversible, and escalate where legal interpretation or customer impact makes a wrong call expensive. For another compliance stream with separate ownership and records, see FATCA Compliance for Marketplace Platforms: Identifying and Reporting Foreign Account Holders.

The PSD2 to PSD3 shift in plain terms#

Treat PSD2 as the baseline reference for this discussion. Treat PSD3 and the Payment Services Regulation (PSR) as the proposed upgrade path, not as a confirmed full reset of existing controls.

In plain terms, the Commission package, including COM(2023) 360 final and impact assessment SWD(2023) 230 final, identifies unresolved problems, asks how they persist without further action, and examines options to standardize customer data and interfaces and improve the quality of interfaces used for customer data sharing.

Operationally, plan for regulatory and process impact, but do not assume a fixed first-mover sequence across PSPs, platforms, or internal teams. If a PSP handles core functions, confirm exactly what the PSP owns, what your platform owns, and what records you can retrieve on demand for audit or disputes.

The impact assessment also signals implementation discipline through explicit monitoring and evaluation work and stakeholder consultation. Keep each material requirement mapped to a current owner, affected process, retained evidence, and next review date.

For a broader readiness view, read Prepare Your Payment Platform for Acquisition: Compliance, Technical, and Financial Readiness.

What is confirmed and what is still uncertain as of now#

The direction of reform is clear, but many operating details remain at draft stage. Treat the Commission package as a reason to prepare now, not as a basis for irreversible product or licensing decisions.

What is confirmed#

What is confirmed is the direction, not the final operating detail. The EU is introducing PSD3 and the Payment Services Regulation (PSR) as the next payment-services legislation. Its stated goals include stronger payment security, better customer protection, and improved conditions for competition and innovation.

This is beyond early discussion. The Commission proposed PSD3 and PSR in June 2024, and both the European Parliament and Council have produced draft texts. Final agreement among the Commission, Parliament, and Council is still pending.

One timing marker in the material is a final version expected in Q1 or Q2 of 2026. Treat that as a legislative expectation, not as a confirmed in-force date or a uniform operational deadline.

What is still uncertain#

Do not hard-code controls around draft-level items. The main unknowns are:

• exact conformance thresholds or test criteria
• final penalty mechanics
• country-specific transition windows
• final scope in draft-sensitive areas such as the commercial agent exemption

For platforms, that exemption point is a real scope risk. If scope tightens, some businesses may find it harder to provide payment services without a license.

Use a simple decision rule for each proposed control. Record whether it relies on PSD2 live law or PSD3/PSR draft text, note the document version, and set the next legal review date. If a requirement is still draft-level, prioritize reversible controls first, including evidence capture, configurable rules, exception logging, and update-friendly contract language.

Build a now versus later control map#

Make one hard split: implement PSD2-baseline controls now, and stage draft-dependent PSD3 and PSR controls for the final text. That turns legal uncertainty into a managed backlog instead of an excuse to delay.

A useful working map is to treat PSR as the likely home for day-to-day conduct rules and PSD3 as the likely home for licensing and prudential rules. At the same time, keep tightening the PSD2 controls already in scope since January 2018.

How to run this map#

The map only works if every row stays live. Each one needs a current status, named owner, source text version, and next legal review date. For staged items, record the exact draft version used and the trigger for build decisions, such as final legislative text, regulator guidance, or confirmed local implementation detail.

Prioritize SCA governance as a no-regret control. If your PSP says it handles SCA, retain evidence you can audit: the control description, exception logic, authentication challenge rates, and dispute investigation handling.

Keep fraud rates and dispute outcomes as KPIs, and store PSP due diligence records alongside them. Those records support oversight of outsourced payment activity regardless of how PSD3 or PSR drafting ends.

Common failure pattern#

The common mistake is to overbuild later-lane items while underbuilding now-lane controls. That is backwards. Immediate exposure is clearest in current SCA and fraud-monitoring controls, while incident records and API evidence quality affect how well you can demonstrate control performance.

For staged controls such as IBAN name verification, PAV variants, liability refinements, and refund edge cases, keep a short legal memo, test plan, and feature note ready. When final text lands, you update controlled records instead of reopening legal, risk, and engineering assumptions.

For a step-by-step walkthrough, see How to Build a Payment Compliance Training Program for Your Platform Operations Team. If you are turning this map into an implementation backlog, use the Gruv docs to align API events, ledger records, and reconciliation evidence with your control owners.

Tighten fraud and authentication controls before legal deadlines#

This is a now-control task, not something to defer until final text arrives. Make your PSD2-era authentication and fraud controls reliable, and make your decisions provable in disputes.

Strong Customer Authentication (SCA) has been part of the baseline since January 2018, so your minimum stack should stay live and aligned across three records: your SCA policy, your exemption governance rules, and the exception approval log for the PSPs executing payment activity.

If a PSP says it handles authentication, keep your own evidence anyway. Retain a current control description, the PSP due-diligence file, the approval trail for exception logic, and a report of pass or fail outcomes, challenge rates, and dispute handling.

The real test is consistency at event level. Teams get exposed when they can show a policy but cannot show which exemption was used, who approved it, whether the PSP applied it correctly, or what the customer experienced at that moment.

Make exemptions a governed decision, not a hidden setting#

Exemptions can reduce friction, but weak governance raises fraud and liability exposure. The reform direction remains fraud-focused, and one stated risk is higher liability exposure where SCA or fraud-monitoring standards are not applied. For platforms, exemption logic should not sit only in PSP defaults or engineering configuration.

Require Risk and Legal sign-off on exemption rules used by your PSPs, and keep a dated approval record whenever those rules change. Track fraud rates and dispute outcomes against those settings. If challenge rates fall while disputes or losses rise, treat that as a control problem, not just a conversion win.

Add an account verification path before payout errors scale#

Before payout errors multiply, build a separate account-verification path for beneficiary setup with documented mismatch handling. The point right now is control quality and reversibility while PSD3 and PSR details are still settling, not hard-coding one final legal implementation.

Document mismatch handling in plain operating terms. State when straight-through processing is blocked, who reviews the case, what additional evidence is acceptable, and when the payout remains blocked. Keep requirements versioned with test cases and sample mismatch scenarios so updates do not force a full rebuild.

Decide your friction-versus-loss tradeoff on purpose#

Do not leave this tradeoff to defaults. Tighter checks can reduce fraud, but they can also increase false positives, abandonment, support load, and payout delay. Regulatory changes may improve resilience while still creating real tradeoffs, so set and document a review cadence with Risk and Finance. Use each review to answer three questions:

• Which checks reduced confirmed fraud, not just alert volume?
• Which checks increased manual review, payout delay, or complaints?
• Which exemptions or mismatch rules created the highest dispute exposure by value?

The failure mode to avoid is simple: controls were enabled, but you cannot prove they were applied consistently when challenged. Tie each disputed case to the authentication result, exemption decision, fraud signals, customer communication record, and PSP response timeline. If that chain is slow or incomplete, fix evidence capture before tuning thresholds further.

For team design, see How to Build a Compliance Operations Team for a Scaling Payment Platform.

Fix your open banking API compliance posture#

Treat API compliance as an evidence and reliability control, not as a provider label. Under PSD2, the practical baseline is a standardised and reliable access interface to payment accounts using common and secure open standards of communication, alongside incident reporting and security measures. Your position is stronger when you can show how failures were identified, classified, and handled.

Use your adopted API specifications as operational touchpoints, not as legal pass or fail tests on their own. Your internal review should stay focused on version ownership, authentication behavior, error clarity, and whether production behavior matches partner expectations.

Track monitoring signals at connection level, not only in aggregate: availability trends, authentication outcomes, third-party access failure reasons, and transaction or device activity that helps identify unusual payment patterns. If account data is missing for a payout decision, you need event-level evidence, not just a global health percentage.

Make failure classes explicit so response and escalation stay consistent: authentication timeout, consent or access denial, unavailable endpoint, malformed response, and downstream partner outage. Without that split, support load rises and incident handling gets less reliable.

Tie API incidents to DORA governance now#

Align API incident classes with your operational-resilience governance now. PSD2 already includes incident-reporting expectations, and DORA raises the importance of structured ICT incident handling. Under Regulation (EU) 2022/2554, Article 21, the ESAs were tasked with assessing further centralisation, and a single EU reporting hub should not be assumed as already implemented.

Classify incidents in a way that can map cleanly to future reporting changes. The failure mode to avoid is treating API incidents as routine engineering noise when they affect regulated payment activity or decisioning.

Map dependencies before a payout path breaks#

If your treasury visibility or payout release logic depends on bank-access APIs, document the sequence: payout path, PSP or aggregator, API dependency, fallback data source, and accountable owner. That gives you a clear view of which incidents can block disbursements and which only delay reconciliation.

When a dependency can materially delay or stop payouts, keep it on the same control review track as other high-impact payment controls. The operating test is simple: can Ops quickly show impacted counterparties, the fallback decision, and the incident record for a real disruption event?

For related operating issues, see Platform Wallet Compliance: Float Rules Interest Bearing Accounts and State Regulations.

Set liability and reimbursement escalation rules before incidents happen#

Set reimbursement and liability escalation rules before disputes occur so customer outcomes and regulatory evidence stay consistent. Under PSD2, major operational or security incidents already require classification and reporting, so ad hoc refund decisions can create both conduct risk and reporting risk.

Put named decision rights on the record#

A policy is only usable when handlers know who can approve reimbursement, who can challenge it, and who signs off when facts are disputed. One practical operating split is this: Ops handles straightforward cases inside documented rules, Risk assesses fraud indicators and account activity, and Legal reviews cases with an unclear liability position, customer disclosure risk, or precedent impact. If a case may point to a wider control issue, attach it to the same incident record used for PSD2 Article 96 classification.

The revised EBA major-incident Guidelines, applicable from 1 January 2022, clarified the process and timeline for classifying major incidents. If reimbursement and incident teams work from different facts, you risk conflicting narratives across customer communication, PSP engagement, and internal reporting.

Require one evidence pack for every material case#

For any material reimbursement or liability dispute, require one evidence pack before the final decision:

The operating test is straightforward: a reviewer should be able to reconstruct the event sequence end to end without chasing multiple teams. If the SCA trail is missing or timestamps do not reconcile with the PSP timeline, treat the case as not decision-ready.

Split social engineering from control failure#

APP-style social engineering cases and technical control-failure cases often should not follow the same path. They may both end in reimbursement, but they call for different evidence weighting and different escalation ownership.

For APP-style cases, start with whether the payment appeared authorized under manipulation. Then review customer communications, warning surfaces, beneficiary-change context, and whether fraud escalation happened when it should have. Because final PSD3 and PSR liability details are not yet settled EU-wide, use joint Risk and Legal review and record the rationale for reimbursement, denial, or goodwill treatment.

For technical control failures, move faster on customer protection and defect containment, then assess whether the issue belongs in PSD2 incident reporting. If SCA was not applied where it should have been, or authentication or execution integrity appears to have failed, the same evidence pack should feed both case resolution and engineering remediation.

Do not escalate every dispute as a major incident. The EBA revised guidance came after assessing more than 6000 incident reports from 2018 and 2019 to reduce reporting burden and improve report meaningfulness. Use major-incident escalation for patterned failures, control breakdowns, or material customer impact, not for isolated complaints. As the EBA framed PSD2 review goals, your escalation design should support consumer protection.

We covered the audit-trail side in detail in Internal Payment Audit Trail for Platform Compliance.

Handle country and program variation without losing control#

A single rollout plan will not produce identical compliance outcomes across countries. The Payment Services Directive was built to support an EU single payments market and to make cross-border payments more comparable to national payments, but Member States can still apply or transpose rules differently. That creates legal uncertainty and regulatory-arbitrage risk. Keep one central policy, but expect local variance.

Keep one variance register and treat it as decision inventory#

Use one live jurisdiction variance register so local decisions stay controlled and auditable. It should capture each country or program difference that changes launch, authentication, reimbursement, reporting, or disclosures, with: jurisdiction, affected flow, decision question, interim decision, source reviewed, owner, review date, and evidence location.

The control test is simple: every live variance has a source and a review or expiry date. If either is missing, the exception is not controlled and can drift into side letters, inboxes, and tribal memory.

Know when variation becomes an escalation issue#

Decide escalation triggers before launch pressure forces rushed calls. Even under EU-wide payment initiatives, local application can differ in practice.

Do not blur payment rules with privacy or tax duties#

Payment, privacy, and tax regimes may use overlapping data, but they do different jobs and should not be merged into one control stream.

Do not assume one reporting stream covers another. Form 8938 is separate. One cited trigger example is aggregate specified foreign financial assets exceeding $50,000 for certain U.S. taxpayers, and if no income tax return is required for the year, Form 8938 is not required.

Keep the jurisdiction variance register under named ownership and review it regularly against live launches, policy deviations, and regulator-facing questions. Related reading: UK Online Safety Act Compliance for Marketplace and Platform Operators.

Build a monthly reporting checklist compliance leaders can actually use#

Once you know which controls are live, staged, or variable by country, your monthly report should show whether those decisions are working in real payment flows. It should not just list metrics. Keep it short, with named owners, internal thresholds, clear data sources, reviewers, and defined escalation paths. There is no grounded EU-mandated monthly template or fixed pass-rate target in this pack, so make your internal tolerances explicit and auditable.

Use one checklist that joins risk, operations, and engineering#

Use one checklist where every line answers five questions: what changed, who owns the threshold, where the data came from, who reviewed it, and where it escalates.

If a row has no threshold owner, remove it until ownership is assigned.

Build the evidence pack, not just the summary#

The summary is only credible if the evidence behind it is ready. Keep three layers together each month:

1. Board-ready summary: trend direction, open escalations, active policy deviations, and country or program variance with customer or liability impact.
2. Regulator-ready support: logs behind amber and red items, including SCA outcomes, AML/KYC case trails, open banking incident and monitoring records, and PCI DSS control evidence.
3. Signed deviation approvals: one controlled record per deviation with affected policy clause, temporary decision, scope, start date, review date, approver, and compensating checks.

Prefer evidence with event IDs, timestamps, reviewer names, and stable record locations over screenshots.

Tie the report back to how the platform actually moves money#

Report on the points where money movement and control quality meet. Track SCA outcomes, AML/KYC monitoring and reporting flow, open banking API auth and object-access failures, and PCI DSS control-test status as control signals.

Keep unresolved high-risk exceptions separate from the general support backlog, and review them by age, value, cause, and approval-record quality. If exceptions or manual overrides start to accumulate without clear approval records, escalate before the drift becomes hard to defend.

If you want a deeper dive, read Netherlands Payment Platform Compliance: DNB Licensing and PSD2 Implementation.

Common mistakes that create expensive rework#

Expensive rework often comes from sequencing and integration gaps, not just from moving quickly.

1. Waiting for PSD3 before fixing PSD2 control hygiene.

Treat PSD3 and the Payment Services Regulation (PSR) as direction while treating PSD2 controls as current operating requirements. If your team cannot quickly reconstruct a disputed payment path, that is current control debt, not future reform work.

1. Overbuilding around draft-era assumptions.

Do not design irreversible controls around details that are not final in this pack. Prefer reversible evidence capture and documented assumptions, then scale architecture decisions when legal and operational details are clearer.

1. Assuming PSPs cover accountability end to end.

PSPs are critical, but you still need clear internal ownership for payment operations. A common failure mode is discovering regulatory requirements late, after architecture and integration choices are already hard to unwind.

1. Merging compliance and integration planning into one blurred process.

Keep these workstreams connected but operationally distinct. Late regulatory discovery paired with architecture and integration gaps is a known rework trigger.

Conclusion#

The right move is disciplined sequencing: keep PSD2 controls live and auditable now, and stage draft-level PSD3 and PSR changes behind reversible decisions. Do not wait for perfect certainty, and do not hard-code speculative features too early.

Your baseline today is current-state PSD2 discipline, including Strong Customer Authentication (SCA) and common and secure communication (CSC). PSD2 has been in force since January 2018, while PSD3 and PSR timing and scope remain unsettled in this source set, with expectations pointing to the first half of 2026. Treat timing and final scope as dependencies to track, not assumptions to build against.

Publish a simple now-versus-later control map. For each control, name the legal basis or proposal status, the owner, the required evidence, and the escalation trigger. Start monthly evidence-based reporting now: SCA application and exemptions, fraud and dispute trends, documented PSP due diligence with monitored fraud and dispute outcomes, and API or access incidents where relevant.

Use strict reporting hygiene so gaps are explainable. A practical supervisory-style rule is that blank fields stay blank only when a datapoint is genuinely not applicable. Otherwise, add a comment that states whether the issue is scope, data quality, or control execution.

When legal text or local implementation is unclear, use explicit escalation checkpoints and document each interpretation decision with the date, owner, sources reviewed, and revisit trigger. Ambiguity is normal in payment-regulation change cycles. Undocumented decisions are the avoidable risk.

Before rollout, run a quick program-fit review to confirm market coverage, compliance gating, and escalation ownership with Gruv.