PSD3 en PSR: wat ondernemers moeten aanpassen

Onder PSD2 werden de dagelijkse gedragsregels — terugbetalingstermijnen, fraudeaansprakelijkheid, klachtenafhandeling — vastgelegd via een richtlijn. Richtlijnen zijn niet rechtstreeks van toepassing. Elk van de 27 lidstaten moest PSD2 omzetten in nationale wetgeving, en elk deed dat met zijn eigen timing, zijn eigen lacunes en zijn eigen lokale interpretatie. Een handelaar die in vijf EU-landen actief was, opereerde in feite onder vijf licht verschillende regelboeken, ook al claimden ze allemaal "dezelfde" richtlijn te implementeren.

Het nieuwe pakket verdeelt het werk anders. PSD3 blijft een richtlijn en gaat vooral over vergunningverlening, toezicht en markttoegang voor betaalinstellingen — het soort zaken dat de regelgevingsstatus van uw PSP raakt, niet uw checkout. De gedragsregels die handelaren daadwerkelijk raken — fraudeaansprakelijkheid, terugbetalingsverplichtingen, authenticatie-eisen, klachtenafhandeling — verhuizen naar de PSR, een verordening. Een verordening geldt rechtstreeks en op dezelfde manier in elke lidstaat, zonder omzetting in nationale wetgeving of ruimte voor lokale varianten.

Volgens juridische analyses van de overeengekomen teksten is dit een bewuste reactie op het versnipperingsprobleem dat PSD2 creëerde — de PSR is ontworpen om handelaren en PSP's één uniform regelboek te geven in plaats van 27 lokale varianten (het overzicht van Freshfields over de overeengekomen teksten). Voor handelaren betekent dit dat de compliance-check die u voor uw Duitse entiteit uitvoert, zodra de PSR van toepassing is, dezelfde uitkomsten zou moeten opleveren als de check voor uw Ierse of Portugese entiteit. Dat is een echte vereenvoudiging, maar het betekent ook dat er geen "de lokale toezichthouder is hier soepel mee" meer als terugvaloptie is.

De aansprakelijkheidsregels van PSD2 waren gebouwd rond een vrij nauw begrip van een "niet-geautoriseerde" transactie — een transactie die de klant niet had goedgekeurd. Fraude heeft zich sindsdien verder ontwikkeld. Social engineering-fraude, waarbij een fraudeur zich voordoet als bankmedewerker of een klant overtuigt om een overboeking rechtstreeks te autoriseren, produceert onder het oude kader technisch gezien een "geautoriseerde" transactie, wat de klant (en daarmee de handelaar die op die betaling vertrouwt) historisch minder verhaalsmogelijkheden gaf.

De PSR breidt de aansprakelijkheid op een paar manieren uit die relevant zijn voor handelaren:

• Fraude op basis van spoofing — waarbij een fraudeur zich voordoet als medewerker of merk van een PSP — verschuift meer aansprakelijkheid naar betaaldienstverleners, in plaats van de klant het verlies te laten dragen.
• Het niet aanbieden of correct toepassen van sterke klantauthenticatie (SCA) legt de aansprakelijkheid bij de partij die daarin tekortschiet. Dat kan ook een acquirer zijn of, in bepaalde betaalprocessen, een ondernemer die authenticatie omzeilt.
• Trage afhandeling van fraudemeldingen door een PSP kan zelf aansprakelijkheid creëren, wat bedoeld is om banken en PSP's aan te sporen tot snellere afhandeling van fraudemeldingen, in plaats van elke claim als een langdurig onderzoek te behandelen.

Voor ondernemers betekent dit dat geschillen over fraude steeds vaker draaien om bewijs van wat er tijdens de authenticatie is gebeurd, en niet alleen om de verklaring van de klant dat de betaling niet was goedgekeurd. Authenticatielogboeken en SCA-resultaten worden daarmee bewijsmateriaal bij geschillen, niet alleen registraties voor conformiteitsdoeleinden.

Een concrete verandering in het afrekenproces is de controle of de rekeningnaam overeenkomt met de verwachte ontvanger. Dit bouwt voort op Verification of Payee (VoP), de begunstigdencontrole die onder de Europese verordening voor instantbetalingen al verplicht is bij instantoverboekingen. Het nieuwe pakket breidt dit principe uit naar betaaldiensten in het algemeen.

Bij VoP controleert de bank of de naam van de ontvanger bij de IBAN hoort. Als die niet of slechts gedeeltelijk overeenkomt, krijgt de betaler een waarschuwing vóór bevestiging. Dit helpt tegen fraude waarbij iemand wordt misleid om zelf geld over te maken naar een rekening van een ander dan de verwachte ontvanger.

Dit raakt elk betaalproces waarbij uw klant zelf een bankoverschrijving start: rechtstreekse rekeningbetalingen, betalingen via open banking of een afrekenstap waarin u uw bankgegevens toont:

• De wettelijke naam die geregistreerd staat op uw zakelijke bankrekening moet overeenkomen met de naam die klanten op uw betaalpagina zien. Anders kunnen zij waarschuwingen krijgen die op fraude lijken, ook wanneer er niets mis is.
• Als u onder een handelsnaam opereert die afwijkt van uw wettelijke entiteitsnaam, is dit het moment om deze op elkaar af te stemmen, of om ervoor te zorgen dat uw checkout het verschil duidelijk uitlegt voordat een klant tijdens de betaling een VoP-waarschuwing tegenkomt.
• Controleer ook of interne documenten voor de financiële aansluiting dezelfde bankgegevens bevatten als uw bank. Verouderde gegevens kunnen een waarschuwing veroorzaken bij iedere klant die via overschrijving betaalt.

Een korte controle van uw geregistreerde rekeningnaam en de naam in uw winkel kan veel verwarring bij klanten voorkomen zodra dergelijke controles breed worden toegepast.

PSD2 gaf rekeninghoudende banken twee opties om rekeninggegevens aan derden bloot te stellen: een dedicated API, of een fallback-interface gebouwd op hun bestaande klantgerichte onlinebankierschermen. In de praktijk waren fallback-interfaces vaak trager, minder betrouwbaar en inconsistent onderhouden, waardoor afrekenprocessen op basis van open banking — pay-by-bank-opties, rekeninginformatie voor risicoscoring en soortgelijke functies — minder betrouwbaar waren dan kaartbetalingen.

Het nieuwe kader verstrakt dit. Banken krijgen te maken met duidelijkere, beter afdwingbare verplichtingen rond de prestaties van dedicated interfaces — dichter bij gelijkwaardigheid met de betrouwbaarheid van hun eigen klantgerichte kanalen, met vastgelegde verwachtingen rond uptime en responstijden in plaats van de losjes gehandhaafde "redelijke inspanning"-norm die delen van de PSD2-implementatie kenmerkte (de analyse van MoFo over PSD3 en PSR).

Voor ondernemers die rechtstreekse bankbetalingen aanbieden of overwegen, is dit op twee manieren van belang:

• Minder mislukte of verlopen autorisatiepogingen zouden tot minder afgebroken bankbetalingen moeten leiden. Die hadden historisch een lager voltooiingspercentage dan kaartbetalingen, mede door de betrouwbaarheid van de interfaces.
• Gebruikt u rekeninginformatie bij risicobeoordeling, bijvoorbeeld om de rekeninghouder of het saldo te controleren vóór verzending van een dure bestelling? Dan zouden die gegevensstromen betrouwbaarder moeten worden, zodat minder herstelpogingen en uitwijkoplossingen nodig zijn.

Niets van dit alles ontslaat u van de noodzaak om uw integratie te testen tegen echt bankgedrag zodra de regels van kracht zijn. Het betekent wel dat de basisbetrouwbaarheid waartegen u test, zou moeten verbeteren.

Dit is het deel dat in de meeste juridische samenvattingen wordt overgeslagen. Dit is wat er aan uw kant verandert.

Uw PSP- en acquirercontracten. Bekijk de aansprakelijkheidsverdeling in uw bestaande betaaldienstenovereenkomsten. Bij contracten uit het PSD2-tijdperk ging de aansprakelijkheidstaal vaak uit van de oude, engere definitie van een "niet-geautoriseerde transactie" en de oude SCA-vrijstellingsregels. Zodra de aansprakelijkheidsbepalingen van de PSR van toepassing zijn, kunnen contracten die niet zijn bijgewerkt, verwijzen naar normen die niet meer overeenkomen met de wet — wat precies onduidelijkheid creëert op het moment dat u helderheid nodig heeft: tijdens een geschil. Vraag uw PSP rechtstreeks of hun standaard handelaarsvoorwaarden zullen worden bijgewerkt om de PSR-aansprakelijkheidsverdeling weer te geven, en vraag het antwoord schriftelijk in plaats van ervan uit te gaan dat het geregeld is.

• Uw afrekenproces. Drie concrete zaken om te controleren:
• Bevestig dat de wettelijke naam die aan uw uitbetalingsrekening is gekoppeld, overeenkomt met uw winkelbranding, om onnodige VoP-mismatchwaarschuwingen bij op overboeking gebaseerde betaalmethoden te voorkomen.
• Zorg dat uw SCA-verificatiestap (3DS of een vergelijkbare methode) technische fouten netjes opvangt. Een klant die afhaakt door een storing in de authenticatie is iets anders dan een klant die verificatie weigert. Dat onderscheid is relevant bij de beoordeling van aansprakelijkheid.
• Als u pay-by-bank of andere rekening-naar-rekening opties aanbiedt, plan om de voltooiingspercentages opnieuw te testen zodra de nieuwe API-prestatieverplichtingen van kracht zijn — de betrouwbaarheidsaannames waarop u uw fallback-logica heeft gebouwd, gelden mogelijk niet meer als bindende beperking.

• Uw geschillenafhandeling. Het bewijs dat een fraude- of chargebackgeschil beslist, verandert. Waar geschillen uit het PSD2-tijdperk vaak draaiden om de vraag of SCA überhaupt was toegepast, zullen geschillen in het PSR-tijdperk vaker draaien om hoe het werd toegepast, of er een VoP-controle is uitgevoerd en wat de uitkomst daarvan was, en hoe snel een fraudemelding werd geëscaleerd. Dat betekent:
• Uw klantenservice moet bij een geschil de authenticatieresultaten kunnen inzien, niet alleen de transactiestatus.
• Neem de uitkomst van de VoP-controle als standaardveld op in uw bewijssjablonen, zodra die informatie in uw transactiegegevens beschikbaar is.
• Interne SLA's voor het escaleren van vermoede fraudemeldingen naar uw PSP moeten worden aangescherpt, omdat vertraging zelf een aansprakelijkheidsfactor wordt in plaats van een neutrale administratieve stap.

De verschuiving van PSD2 naar PSR gaat minder over nieuwe verplichtingen die uit het niets opduiken, en meer over bestaande lacunes die worden gedicht.

Handelaren die fraudeaansprakelijkheid, SCA en geschilbewijs behandelden als "wat de lokale bank ook zegt", zullen merken dat dat antwoord niet langer standhoudt zodra dezelfde regelgevingstekst in elke lidstaat van toepassing is. Het werk is administratief — het bijwerken van contracten, checkoutteksten en bewijssjablonen — maar het moet gebeuren vóór de algemene toepassingsdatum, niet erna, wanneer het eerste geschil onder de nieuwe regels de lacune blootlegt.

Niets hiervan vereist het opnieuw opbouwen van uw checkout op een ander platform. Het vereist dat u uw PSP-contract, uw geregistreerde rekeninggegevens en uw sjablonen voor geschilbewijs behandelt als levende documenten die op een specifiek moment een controleronde nodig hebben — en dat is precies het punt van de checklist hieronder.

De datum waarop de regels algemeen gaan gelden, hangt af van de publicatie van de definitieve tekst in het Publicatieblad. Gebruik de onderstaande volgorde daarom als planningshulp en bevestig de data na publicatie.

• Vóór Q4 2026 — Publicatie in het Publicatieblad wordt verwacht (juni–juli 2026). Zodra dit is gepubliceerd, berekent u uw definitieve datum van algemene toepassing (21 maanden later) en zet u die in uw compliancekalender. Start nu al met de PSP-contractbeoordeling in plaats van te wachten op de deadline.
• Gedurende 2027 — Bevestig het plan van uw PSP om handelaarsvoorwaarden bij te werken zodat deze de PSR-aansprakelijkheidsverdeling weerspiegelen. Controleer de geregistreerde wettelijke naam van uw uitbetalingsrekening tegen uw naam en huisstijl bij het afrekenen. Inventariseer welke van uw afrekenprocessen SCA gebruiken en documenteer de huidige vrijstellingslogica, zodat u deze kunt vergelijken met de definitieve PSR-vereisten.
• Begin 2028 — Test het volledige proces voor bewijsmateriaal: kan uw klantenservice zelf de SCA- en VoP-resultaten van een transactie opvragen, of is hulp van het ontwikkelteam nodig? Los ontbrekende toegang op voordat een echt geschil ontstaat.
• Bij algemene toepassing (geschat maart–april 2028) — Bevestig dat bijgewerkte PSP-contracten zijn ondertekend, dat teksten bij het afrekenen eventuele vereisten voor de naam van de begunstigde weerspiegelen, en dat uw geschildocumentatie de nieuwe bewijsvelden bevat. Beschouw de datum van algemene toepassing als het moment waarop al het voorgaande al zou moeten draaien, niet als het startpunt.

Cost+ werkt met IC++ (Interchange Plus Plus)-prijzen precies omdat wij denken dat handelaren betere beslissingen nemen wanneer de onderdelen van een betaling — interchange, kaartnetwerkvergoeding, en onze marge — zichtbaar zijn in plaats van gebundeld. Hetzelfde principe geldt voor regelgevingsveranderingen: hoe eerder u kunt zien wat er daadwerkelijk verschuift in aansprakelijkheid en bewijsvereisten, hoe minder verstorend de overgang. Wilt u doorpraten over hoe uw huidige inrichting van uw afrekenproces en geschillenafhandeling aansluit op de PSR-tijdlijn, neem dan contact op met ons team of vergelijk uw huidige kostenstructuur met de gepubliceerde low-risk tarieven op onze site terwijl u uw contracten doorloopt.