PSD3 en PSR: wat handelaren daadwerkelijk moeten veranderen

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. Verordeningen zijn rechtstreeks en identiek van toepassing in elke lidstaat, zonder nationale omzettingsstap en zonder ruimte voor lokale opmaakverschillen.

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 (Freshfields' overzicht van 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 cliëntauthenticatie (SCA) legt de aansprakelijkheid bij de partij in de keten die hierin faalde, wat ook acquirers omvat en, in bepaalde flows, handelaren die authenticatie omzeilen.
• 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 een handelaar is het praktische effect dat frauduleuze geschillen steeds meer zullen draaien om bewijs van wat er tijdens de authenticatie is gebeurd, en niet alleen om de vraag of de klant zegt de betaling niet te hebben geautoriseerd. Dat maakt uw authenticatielogs en SCA-uitkomstgegevens onderdeel van uw geschilbewijs, niet slechts een compliance-vastlegging die u bewaart en vergeet.

Een van de meest concrete veranderingen voor checkoutflows betreft de verificatie dat de naam op een rekening daadwerkelijk overeenkomt met wie de betaler denkt geld naar te sturen. Dit bouwt voort op het Verification of Payee (VoP)-mechanisme dat al verplicht is voor instant credit transfers onder de Europese verordening instantbetalingen, en het nieuwe betalingspakket breidt die logica verder uit over betaaldiensten in het algemeen.

In de praktijk betekent VoP dat de bank van een betaler de naam van de rekeninghouder controleert tegen de IBAN voordat een overboeking wordt voltooid, en een mismatch — een "geen match" of "gedeeltelijke match" — terugmeldt aan de betaler voordat deze de betaling bevestigt. Dat is specifiek gericht op fraude met geautoriseerde push-betalingen, waarbij een klant wordt misleid om geld over te maken naar een rekening die niet is wie ze denken dat het is.

Voor handelaren raakt dit elke flow waarbij een klant een bankoverboeking initieert om u te betalen — betaalmethoden van rekening naar rekening, via open banking geïnitieerde betalingen, of elke checkoutstap waarbij u uw eigen begunstigdegegevens toont zodat een klant een overboeking kan voltooien:

• De wettelijke naam die geregistreerd staat op uw zakelijke bankrekening moet exact overeenkomen met de handelsnaam die klanten op uw checkoutpagina zien, anders krijgen klanten mismatchwaarschuwingen die aanvoelen als fraudesignalen, 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.
• Elke interne documentatie waarin uw settlement-rekeninggegevens staan voor reconciliatiedoeleinden, moet worden gecontroleerd tegen wat daadwerkelijk bij uw bank geregistreerd staat, want een verouderd gegeven komt naar boven als een mismatch bij elke klant die een op overboeking gebaseerde methode gebruikt.

Dit is een geval waarin een controle van vijf minuten — bevestigen dat de geregistreerde naam van uw bankrekening overeenkomt met uw winkelbranding — een golf van klantverwarring voorkomt zodra VoP-achtige controles breed van kracht zijn.

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 checkoutflows 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 (MoFo's analyse van de PSD3/PSR-ontwikkelingen).

Voor handelaren die pay-by-bank of andere rekening-naar-rekening checkoutopties aanbieden of overwegen, telt dit op twee manieren:

• Minder mislukte of verlopen autorisatiepogingen zou moeten betekenen minder verlaten winkelwagens bij op overboeking gebaseerde betaalmethoden, die historisch onder kaarten scoorden op voltooiingspercentage, deels door de betrouwbaarheid van de interface.
• Als u vertrouwt op rekeninginformatiediensten voor risicobeslissingen — het verifiëren van rekeninghouderschap of het controleren van saldi voordat u bestellingen met een hoge waarde verzendt — zouden die datastromen consistenter moeten worden om workflows op te bouwen, in plaats van iets waarvoor u retry-logica en fallback-afhandeling moet bouwen.

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 checkoutflow. Drie concrete zaken om te controleren:
• Bevestig dat de wettelijke naam die aan uw settlement-rekening is gekoppeld, overeenkomt met uw winkelbranding, om onnodige VoP-mismatchwaarschuwingen bij op overboeking gebaseerde betaalmethoden te voorkomen.
• Zorg dat uw SCA-uitdagingsflow (3DS of gelijkwaardig) soepel degradeert — een klant die een aankoop afbreekt omdat een authenticatiestap technisch faalde, in plaats van omdat hij deze weigerde, is precies het scenario waarop de nieuwe aansprakelijkheidsregels zijn gericht, en u wilt daarbij niet aan de verkeerde kant staan wanneer een geschil wordt beoordeeld.
• 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 geschillenproces. 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 supportteam moet toegang hebben tot authenticatie-uitkomstlogs, niet alleen de transactiestatus, wanneer het reageert op een geschil.
• Uw documentatie voor het indienen van bewijs moet worden bijgewerkt om VoP-match/geen-matchresultaten op te nemen als standaardveld, zodra die gegevens in uw transactiegegevens bestaan.
• 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 exacte datum van algemene toepassing hangt af van wanneer het Publicatieblad de definitieve tekst publiceert, maar de volgorde staat vast. Gebruik dit als een werktijdlijn in plaats van een vaste deadline, en bevestig data zodra de publicatie in het Publicatieblad is bevestigd.

• 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 settlement-rekening tegen uw checkoutbranding. Inventariseer welke van uw checkoutflows SCA gebruiken en documenteer de huidige vrijstellingslogica, zodat u deze kunt vergelijken met de definitieve PSR-vereisten.
• Begin 2028 — Test uw geschilbewijsproces van begin tot eind: kan uw supportteam daadwerkelijk SCA-uitkomsten en VoP-matchgegevens voor een transactie opvragen, of vereist dat een ticket bij engineering? Los die lacune op voordat een lopend geschil deze test.
• Bij algemene toepassing (geschat maart–april 2028) — Bevestig dat bijgewerkte PSP-contracten zijn ondertekend, dat checkoutteksten 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, scheme fee, en onze markup — 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 checkout- en geschilopzet 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.