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#

A platform’s EU payment backlog needs more than a PSD2-versus-PSD3 split. Current work also includes the Instant Payments Regulation and DORA where they apply. Identify the entity providing the service, then separate duties already applicable to that entity from the reform transition.

A marketplace using a PSP is not automatically a payment institution. Map who holds funds, accesses payment accounts, initiates transfers and serves the payment-service user. That determines who has the legal duty and what the platform must support through its integration and contracts.

• Implement current duties: Authentication, payee verification, customer remedies and incident reporting under their actual legal regimes.
• Prepare the transition: Translate the agreed reform direction into a versioned backlog, tied to adopted text and application dates.
• Resolve scope early: Confirm the provider entity, permitted service and customer-contract position before a live launch.

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.

Review status: 3 October 2026. The Parliament procedure files still list PSD3 and PSR as awaiting the Council’s first-reading position, with an indicative plenary date of 14 December 2026. That forecast is not an application deadline. Existing duties continue on their own timetable.

For each requirement, keep its legal source, applicable entity and service, deadline, owner and implementation evidence together. This lets engineering deliver the right change without turning every policy question into a separate integration project.

The PSD2 to PSD3 shift in plain terms#

The reform separates the proposed licensing and prudential directive, PSD3, from the proposed conduct regulation, PSR. Keep that structure distinct from today’s PSD2, its authentication standards, the instant-payment amendments and DORA.

The Commission published PSD3, COM(2023)366, and PSR, COM(2023)367, on 28 June 2023. A political agreement followed on 27 November 2025, and Parliament’s committee approved the negotiated texts on 5 May 2026. Political agreement and committee approval do not make every operating rule immediately applicable.

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.

Track adoption, Official Journal publication, application and any directive transposition separately. An internal build date can precede a legal application date, but it should be labelled as an implementation milestone.

Which duties are live, and what belongs to the reform transition?#

The practical control map has four legal tracks. A regulated PSP may have duties across several; a platform integration must make those duties operable without assuming the platform itself has the same authorization.

What is confirmed#

Some of the work often labelled “PSD3 readiness” is already due under other law. Treat beneficiary verification and incident reporting as current applicability questions, not items that can all wait for the reform.

The legislative record supports a clear chronology: proposals in June 2023, political agreement in November 2025 and committee approval in May 2026. Remove old Q1/Q2 2026 forecasts from customer promises and implementation gates.

Use the Parliament’s current procedure files for progress and the adopted legal instruments for operative dates. A forecast plenary sitting is useful for planning capacity, not for deciding when customer protections begin.

What is still uncertain#

Keep the transition backlog linked to the negotiated text, while reserving final implementation decisions for the adopted provisions and applicable timetable. In particular, distinguish:

• authorization and licensing changes for the actual provider
• conduct and fraud-liability changes affecting the relevant customer flow
• delegated technical standards and implementation details
• directive transposition and regulation application dates

For a marketplace relying on an exclusion such as the commercial-agent exemption, document the actual activity and current national interpretation. A proposed future change neither grants permission now nor removes the need to assess the existing flow.

A useful decision record names the instrument, article, applicable entity, service, customer type, country and deadline. Link it to the provider contract and implementation task. That is more useful than a generic “PSD3 compliant” label.

Build a now versus later control map#

Put live obligations in the current lane and reform-dependent changes in the transition lane. Each row needs its own scope and deadline; the reform is not a reason to defer another instrument’s requirement.

The map should join law to the actual payment flow: customer authorization, provider execution, beneficiary verification, dispute handling and incident response. Assign the legal duty to the responsible PSP or financial entity and the implementation task to the team able to deliver it.

How to run this map#

Review each row when its source, service or provider changes. For staged work, name the adoption or guidance event that changes the implementation decision. For live work, test the actual outcome rather than leaving it in a legal-tracking spreadsheet.

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.

Use feature flags and versioned rules for transition work, while maintaining current legal outcomes. A flag must not switch off a duty already applicable to the service.

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.

PSD2 became applicable in January 2018; the delegated SCA and secure-communication standards generally applied from 14 September 2019. Keep those dates distinct. Authentication scope and exemptions belong to the actual PSP and transaction, rather than a blanket rule for every contractor payout.

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#

Treat exemptions as provider-governed decisions under the applicable standards. Record the outcome the provider actually applied; an internal approval cannot create a legal exemption. Monitor customer friction alongside fraud and disputes so lower challenge rates do not hide deteriorating outcomes.

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#

Verification of payee is an existing Instant Payments Regulation duty for covered euro credit transfers, including regular transfers. The Article 5c dates are 9 October 2025 for PSPs in euro-currency Member States and 9 July 2027 in other Member States. It is not merely a future PSD3 feature.

Preserve the match result, warning and payer decision. A mismatch is not a mandatory prohibition on authorization. Non-consumer users submitting payment orders as a package can opt out and later opt in. Keep any stricter internal approval policy distinct from that legal service.

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#

Account-servicing PSPs and authorized account-information or payment-initiation providers have different access roles. Identify which one operates each interface. For your integration, keep a version inventory and classify consent, authentication, access and response failures so incidents reach the right provider.

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#

DORA applies from 17 January 2025 to covered financial entities. The EBA repealed its PSD2 major-incident reporting Guidelines from that date; other PSP types outside DORA can retain PSD2 incident duties. Map the entity first, then use the applicable reporting route and standards rather than the old guideline template by default.

Track when the entity became aware of an incident, its classification, affected services and customers, and the accountable reporting owner. A platform supplier may need to provide prompt incident information under contract without being the entity that files the regulatory report.

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#

The refund clock and the investigation clock can run in parallel. For an unauthorized transaction covered by PSD2 Article 73, the payer’s PSP must refund immediately and by the end of the following business day after awareness or notification, unless it has reasonable grounds to suspect fraud and reports them in writing to the national authority. Confirm applicable scope, national rules and any permitted non-consumer contract variation.

Put named decision rights on the record#

Give handlers a refund deadline, an authorized decision-maker and a route for genuine legal exceptions. Missing internal evidence does not by itself suspend an applicable remedy. Keep customer notification and provider response times available to both the refund and incident teams.

For example, suppose a consumer notifies the PSP on Monday of a covered unauthorized transfer. The team opens the investigation and works to the applicable next-business-day refund deadline; it does not make Friday’s risk meeting a prerequisite. If a lawful fraud-suspicion exception is used, retain its grounds and authority notification. These are assumed case facts, not an outcome for every dispute.

Require one evidence pack for every material case#

Collect the evidence in parallel with any applicable customer remedy:

A reviewer should be able to reconstruct the payment, but the customer remedy must follow its own legal timetable. Assign evidence recovery work without turning an incomplete internal file into an unauthorized delay.

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 social-engineering cases, determine whether the transaction was authorized, the applicable law and contract, and the provider’s duties. Keep the customer’s communications, warnings and beneficiary-change history. Do not import another jurisdiction’s APP reimbursement regime or a proposed reform rule into every EU case.

For technical failures, contain the defect and apply the relevant customer remedy. Assess incident-reporting criteria separately under the regime for the responsible entity; an individual dispute and a reportable operational incident are different decisions.

Use the applicable classification thresholds and reporting deadlines. Neither an isolated complaint nor a pattern of complaints automatically supplies the legal classification: connect the facts to the affected service, customer impact and relevant standards.

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.

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#

Use a monthly internal report to track whether current controls work and transition tasks are ready. This cadence is a management choice, not a universal EU monthly reporting duty. Report exceptions as well as successful execution.

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 lacks an owner, retain it as an open control gap and assign one. Removing the row would hide the problem.

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. Supporting records: authentication and verification outcomes, remedy timing, and incident classifications or submissions for the applicable entity.
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#

Join the report to real payment events and customer cases. A reduced challenge rate means little if unauthorized-payment remedies are late or beneficiary warnings are missing. Keep each result tied to its applicable flow and provider.

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.

Keep the current payment-service, instant-payment and resilience duties operating while preparing the reform transition. A reform tracker cannot substitute for the live controls.

1. Overbuilding around draft-era assumptions.

Do not design irreversible controls around details that are not yet final. 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.

Make the control map follow the payment flow#

Keep current duties operating and prepare the reform with named owners and versioned decisions. Verification, refunds and incidents each need their own legal basis and timing; grouping them all under “PSD3 later” creates avoidable gaps.

Start with one real payment flow and trace authorization, execution, verification, customer remedies and incident information. Where a responsibility changes hands, make the contract and operational record show who acts next.

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