PSD3 and PSR for iGaming: Q2 2026 Texts and the Liability Shift

The provisional political agreement on PSD3 and PSR landed November 27, 2025. The Council's "I" Item Note dated April 17, 2026 endorsed the trilogue compromise, and the final compromise texts were published April 23, 2026. As of May 2026 the PSR scope, the article numbering, and the application clocks are locked in. What is not locked is when the Official Journal stamp falls and what the European Banking Authority delivers across the 22 PSR mandates and 18 PSD3 mandates fanning out from the regulation. For an iGaming operator running EU-licensed books, or for a Curacao-licensed book whose deposit volume routes through EU-domiciled PSPs, the Q2 2026 question is which roadmap items move now and which wait for the OJ stamp.

The SERP for "PSD3 PSR" is dominated by generic explainers from law firms and EMI consultancies pitched at compliance officers at payment institutions. None of them connect the article numbers to a casino deposit, a player chargeback, or an offshore-to-EU payment flow. This article does the iGaming-specific reading.

Where the PSD3 and PSR texts stand at May 2026

PSD3 is the directive that updates the licensing perimeter for payment institutions and EMIs and merges the two regimes. PSR is the directly-applicable regulation that carries the consumer-protection, fraud-liability, and open-banking rules iGaming operators care about. Both came out of the European Commission's June 2023 proposal package, hit a provisional political agreement on November 27, 2025 per William Fry's note and Norton Rose Fulbright's readiness analysis, and went through Council COREPER endorsement on April 22, 2026.

The Council published the final compromise texts the next day under three documents: PSD3 as ST-8222-2026-INIT, PSR as ST-8221-2026-INIT, and the "I" Item Note as ST-8220-2026-INIT, per Regulation Tomorrow's Council readout and Arthur Cox's compromise-text summary. Those numbers are the working-text references operators' counsel will quote at you for the rest of 2026.

What is not locked is the publication date in the Official Journal and the application clock that runs off it. The realistic publication window per the Norton Rose note and the Linklaters payments practice tracker is summer 2026, possibly slipping into September. The PSR enters into force 20 days after OJ publication and applies 18 months later, with the verification-of-payee provisions in Articles 50 and 57 applying 27 months after entry into force per Arthur Cox's reading of the final text. PSD3 transposition runs 21 months from entry into force.

The implication: Q2 2026 is a planning quarter, not an application quarter. The Article 59 reimbursement obligation does not bite the player's PSP today. What does change today is the technical-standards drafting work the EBA is publishing under its 2026 Work Programme, where roughly 40 of the 58 deliverables sit under PSR and PSD3 per PwC Legal's summary of the EBA Work Programme. If you wait for the OJ stamp to start your gap analysis, you have already missed the consultation windows on the technical standards that decide what reasonable looks like in operator-side fraud monitoring.

PSR Article 59 and the casino disputes that don't qualify

The headline change in PSR is Article 59, which mandates that the player's PSP fully reimburse the consumer for losses from PSP impersonation fraud, the pattern in which a fraudster pretends to be the victim's own bank or payment provider and tricks the consumer into authorizing a payment. Reimbursement runs within ten business days of notification or police-report receipt per A&O Shearman's analysis of the agreed text. The ten-day window is the most aggressive timeline in any major payment-fraud regime today.

Read the scope clause carefully. Article 59 is narrow. It covers spoofing where the fraudster impersonates the player's bank, not the iGaming book the player thinks they are depositing to. The European Parliament press release on the payment services deal is explicit that romance scams, investment scams, and purchase scams sit outside the mandatory reimbursement obligation.

That is the load-bearing point for an iGaming operator. The patterns that produce most chargeback volume in the segment are not in scope. A player who deposits to a fake casino, a purchase scam, does not get Article 59 reimbursement. A player who funds an account under romance-scam coercion does not get Article 59 reimbursement. A player who claims "I never authorized that casino deposit" while logged into their own bank app via their own credentials is making an unauthorized-transaction claim under Article 56, which is the same regime as PSD2 plus a tightening on the gross-negligence carve-out.

Where Article 59 does bite is the case where a fraudster spoofs the player's bank and pushes the player into authorizing a transfer that lands at the operator. In that flow the player's PSP refunds the player and may then look upstream for a recovery. The operator's PSP can be on the receiving end of an inbound suspicious-activity flag, a freeze, or a clawback request. Operators with weak deposit-side KYC and slow response on inbound bank queries will land in those flows more often than operators with mature controls.

The Article 56 unauthorized-transaction track tightens the screws on a different axis. Per EFRI's reading of the agreed text, the PSP can delay the standard next-business-day refund only if it has objectively justified reasons to suspect the payer was grossly negligent, with written justification within 15 business days. The bar to claim gross negligence is higher than under PSD2, and the documentation burden falls on the bank. Account-takeover-funded casino deposits sort under this regime: the player's PSP refunds, then chases the operator's PSP for cooperation in the recovery. Operators who do not log device fingerprints, deposit-pattern anomalies, and KYT signals for inbound funding will see their PSPs caught in those recovery loops without a defensible record.

PSR Article 83(3) and the mule-account two-confirmation lag

Article 83(3) introduces an EU-wide framework for sharing fraud data, specifically including IBANs of suspected mule accounts, between PSPs. The intent is good. The implementation has a built-in lag that should worry any compliance team running an iGaming book.

Per BioCatch's reading of the agreed text, unique identifiers can be shared between PSPs only after at least two customers have confirmed that a fraudulent transfer was made to that IBAN. The two-confirmation threshold is a privacy guardrail meant to stop a single false report from poisoning a clean account. It is also a reactive trigger that lags the speed at which a real mule cycle moves money.

iGaming is a known mule-laundering channel because the deposit-then-cashout flow can convert dirty inbound funds into laundered outbound funds at speed if the operator's KYT is thin. A mule who deposits at twenty operators, plays through a thin volume, and cashes out to a clean account closes the cycle in days. The PSR's two-confirmation rule means the upstream signal that this IBAN is a mule does not propagate until the second victim files. By the time the IBAN gets shared, the cycle is closed.

The practical operator answer: do not wait for the PSR's IBAN-sharing rail to do the work for you. Run KYT against inbound funding sources at deposit time, log the network-graph signal across players who share funding sources, and treat clusters of fresh accounts depositing from the same IBAN as a single risk event rather than as independent deposits. The PSR rail will help second-time around. The first cycle is what costs operators money.

The API mandate that reprices Trustly and Brite

PSR replaces the PSD2-era patchwork of dedicated interface plus fallback interface with a single mandatory dedicated API at every account-servicing PSP across the EU, with limited exemptions. Around 6,000 ASPSPs must offer an API that performs at parity with the bank's own customer interface, per the Ozone API explainer. The fallback-interface obligation goes away. Screen scraping is banned outright, per the same source.

The pricing rule is the part that reprices Trustly and Brite economics. Everything inside PSD2 scope (account information, payment initiation for standard credit transfers and SEPA Instant, balance check) must remain free to authorized TPPs and contract-free. ASPSPs are allowed to charge for "premium" APIs that cover services beyond PSD2 scope, such as dynamic recurring payments, payment guarantees, and richer account data feeds.

What this does to iGaming open-banking economics: the free PSD2 floor is preserved, so Trustly and Brite continue to access basic payment-initiation rails at zero per-call cost from the bank side. The lift comes on the premium tier. Dynamic recurring payments, the rail that lets a player set up a recurring deposit cap or auto-top-up, is explicitly outside PSD2 scope and explicitly chargeable under PSD3. Payment guarantees, the rail that lets the operator confirm a deposit has cleared before crediting the player's wallet, are similarly chargeable. Both are valuable to operators on retention metrics, and both move from "negotiated bilaterally with each bank" to "priced through the bank's premium API contract."

Brite's own PSD3 explainer frames the change as compatible with its model: it has built against the regulatory direction, and the consumer-permission dashboard mandate is build work, not a strategic break. Trustly has not published a comparable position piece in the same window. The structural read for both: the model survives, the differentiation premium that came from owning a niche API workaround narrows, and the competitive pressure shifts to coverage breadth, settlement speed, and KYT depth.

The mandatory consumer-permission dashboard is the build cost operators do not always price in. It sits at the bank, not at the open-banking PSP, but it changes the consumer's deposit experience: the player can revoke open-banking authorization for an iGaming book from inside their bank's app, separate from any cancellation flow at the operator. Operators that depend on default-on persistence of open-banking permission for retention will see attrition at the bank-app surface. Hard to quantify in advance; the right move is to instrument the deposit-permission lifecycle and treat revocation events as a CRM signal.

Curacao operators caught indirectly through the EU rail

The full Curaçao reform and Anjouan payment-access map is the sister analysis on the licensing side; this section is the EU-rail-side overlay.

The PSR regulates payment service providers, not gambling operators. A Curacao-licensed casino is not in itself captured by the regulation. The territorial pull comes from the EU-domiciled PSPs, banks, and EMIs that sit between the operator and an EU player, all of which are fully captured.

The mechanism: when an EU player makes a casino deposit, the player's PSP is the regulated entity that bears the new fraud-monitoring and consumer-protection duties. The operator's PSP, if EU-domiciled, is also captured. The operator itself, even on Curacao paper, sits at the receiving end of compliance pressure that runs through both PSP legs. Per Checkout.com's territorial summary and Ravelin's scope analysis, the regulation applies to PSPs based in the EEA and to anyone operating in the EU market through EEA rails.

What that translates to in practice for a Curacao book serving EU players:

• The EU-side card acquirer carries Article 59 monitoring duties and will tighten onboarding and ongoing diligence on offshore merchants whose chargeback patterns include any spoofing-adjacent vector. Margins compress for high-risk MIDs as the acquirer prices in the new liability tail.
• The open-banking PSP routing EU player deposits (Trustly, Brite) is subject to the consumer-permission dashboard and the unified API mandate. Operators relying on old contract terms with these vendors will be re-papered as the providers update their merchant agreements to reflect PSR obligations.
• The IBAN-sharing rail under Article 83(3) applies to EU PSPs sharing among themselves. A Curacao book whose deposit funnel cycles mule funds will see the receiving operator's bank-side controls tighten as the PSP-to-PSP signal pipe matures.
• Cross-jurisdictional dispute mechanics shift. A player's PSP that refunds an account-takeover-funded deposit under Article 56 will pursue a cooperation request through the operator's PSP regardless of where the operator is licensed.

The strategic read: Curacao licensing has been treated as a regulatory firewall against EU rules. PSR does not break the firewall directly, but it tightens the EU-side rails the operator depends on. The cost of EU player acquisition for a Curacao book rises across 2027 and 2028 as the PSR application clock runs out and EU PSPs reprice the offshore-merchant book. Operators planning EU-targeted growth on Curacao paper should model that compression now rather than after the OJ stamp.

The 2024 Curacao licensing reform that introduced direct GCB licenses for individual operators improves the document trail an EU PSP can underwrite against. The PSR does not give Curacao licensing parity with EU regulation, but it does reward operators whose paperwork passes EU PSP onboarding without exception flags. Books still operating on master-license sublicensees will face a tougher EU-rail underwriting check than books on direct GCB licenses, and that gap matters more under PSR than under PSD2.

Issuer, acquirer, and operator under the rebalanced chain

The user-facing question is who pays when something goes wrong. PSR rebalances the chain by adding new duties on the player's PSP without symmetrically tightening the operator side. The result is a triangle in which the issuer carries more direct liability, the acquirer absorbs upstream pressure through onboarding tightening, and the operator faces second-order pressure through both legs.

The honest read is that PSR is more protective for one specific narrow attack vector (PSP impersonation push fraud) and roughly neutral on the rest. The headline-driving claim that "PSD3 puts liability on the operator" is wrong on the regulation's face. The liability sits on the player's PSP. What an operator feels is the second-order tightening: the issuer that just refunded a player will be more aggressive at the cooperation request, the acquirer that just absorbed an inbound suspicious-activity ping will retest the merchant's KYC posture, and onboarding committees at both ends will be slower.

The UK regime is a separate case. The UK Payment Systems Regulator's APP-fraud reimbursement rule, which split liability 50/50 between the sending PSP and the receiving PSP from October 2024 per Freshfields' UK analysis, is structurally different from EU PSR. The EU does not mandate a 50/50 split. UKGC-licensed operators serving UK players already live under the UK regime; UKGC-licensed operators serving EU players will live under both. Anyone treating the UK regime as a preview of EU PSR economics is reading the wrong rulebook.

The roadmap from May 2026 to the transposition cliff

The application clocks turn the May 2026 status into a planning grid. Six work items, sequenced by when the trigger lands.

1. Pre-OJ (May to summer 2026): finish the PSR gap analysis. Map inbound deposit flows, the dispute-handling chain, KYT coverage, and the open-banking permission lifecycle against PSR Articles 50, 56, 57, 59, and 83. Identify the items that need a build rather than a contract change. Expect the EBA to release draft technical standards through Q3 2026; submit consultation responses where the operator side has standing.
2. OJ publication to entry-into-force (summer 2026 to early 2027): negotiate updated merchant agreements with EU-domiciled PSPs. Trustly, Brite, Adyen, Worldpay, Nuvei, and Paysafe will each issue updated terms. Read them line-by-line for new operator obligations on KYT data sharing, dispute cooperation, and consumer-permission dashboard interactions. Push back on terms that go beyond the regulation.
3. Entry into force to 18 months in (early 2027 to mid-2028): build out the deposit-side instrumentation. Device fingerprinting, KYT graph analysis, deposit-pattern anomaly detection, and dispute-cooperation logging are the hard infrastructure pieces. PSPs will ask for these in their cooperation requests; operators without them will be slower to respond and more likely to absorb the loss when the bank refuses to drop the recovery.
4. PSR application date (around late 2027): the bulk of PSR is now live. Article 59 reimbursement obligations bite issuers. Article 83(3) IBAN sharing matures into a working signal pipe. Operators with mature deposit-side KYT see fewer suspicious-activity flags routed to their PSP. Operators without it absorb the volume.
5. PSR Articles 50 and 57 application (around Q2 to Q3 2028): Verification of Payee is mandatory pre-transfer for all credit-transfer payments inside the EU. Operator-side build: handle close-match VOP responses on player deposit IBANs, build the player-prompt UI for re-verification, and route close-match cases through a manual review queue that does not block deposits at the 10-second SCT Inst SLA.
6. PSD3 transposition deadline (around mid-2028): national-law implementations land across member states. Expect divergence on the licensing perimeter for payment institutions and EMIs and on member-state options. Operators with multi-jurisdiction footprints should track the local transposition for each market they bank in.

The stack a Curacao-licensed book serving EU players runs against this roadmap is more compressed than for an EU-licensed book, because the EU-side PSPs reprice underwriting earlier than the regulation's formal application date. Operators planning to move volume to direct EU licensing during 2027 will get cleaner terms on the underwriting renewal cycle. Operators planning to stay on Curacao paper should price in EU-rail compression on blended fees as the new normal once PSR applies, with the largest hit landing on high-risk MIDs whose chargeback profile triggers Article 59 monitoring.

The Q2 2026 texts are locked. The OJ stamp is the next dated milestone. Operators that treat the gap between today and OJ as planning time, rather than as a license to wait, get cleaner terms on every renewal that runs through it.