PSD3 en de Payment Services Regulation: wat de nieuwe EU-betaalregels van je software vragen.

Waarom PSD2 een opvolger krijgt

PSD2 is sinds 2018 de ruggengraat van het Europese betalingsverkeer. De richtlijn introduceerde Strong Customer Authentication, opende bankrekeningen voor derde partijen via open banking en gaf consumenten meer bescherming bij fraude. Maar na acht jaar praktijk zijn de tekortkomingen zichtbaar geworden.

Open banking bleef in veel lidstaten een papieren belofte: banken leverden API's op die traag, instabiel of functioneel beperkt waren. Fraudepreventie bleef gefragmenteerd — elke lidstaat interpreteerde de regels net anders. En nieuwe vormen van fraude, zoals authorised push payment (APP) fraude waarbij oplichters slachtoffers overtuigen om zelf geld over te maken, vielen buiten de bestaande aansprakelijkheidsregels.

De Europese Commissie besloot daarom PSD2 niet te repareren, maar te vervangen. Het resultaat is een pakket van twee wetten die samen het nieuwe fundament vormen: PSD3 en de Payment Services Regulation.

PSD3 en PSR: twee wetten, één pakket

Het belangrijkste structurele verschil met PSD2 is de opsplitsing in twee instrumenten. Dat is geen juridische subtiliteit — het bepaalt hoe snel en hoe uniform de regels in de praktijk landen.

• PSD3 is een richtlijn. Die gaat over vergunningverlening, toezicht en de fusie van de vergunningsregimes voor betaalinstellingen en e-geldinstellingen (de huidige EMD2 verdwijnt). Elke lidstaat moet PSD3 omzetten in nationale wetgeving, wat in de praktijk betekent dat er interpretatieverschillen blijven bestaan.
• De PSR is een verordening. Die bevat de inhoudelijke regels: Strong Customer Authentication, fraudepreventie, open banking, IBAN-naamcheck, consumentenbescherming en de rechten en plichten van betaaldienstverleners. Een verordening geldt direct en uniform in alle EU-lidstaten, zonder omzetting.

Die keuze voor een verordening is bewust. Onder PSD2 kon een Nederlandse bank andere SCA-uitzonderingen hanteren dan een Duitse, omdat elke lidstaat de richtlijn net anders implementeerde. De PSR maakt daar een einde aan: één set regels die overal hetzelfde werkt.

De tijdlijn

Het Europees Parlement en de Raad bereikten op 27 november 2025 een voorlopig politiek akkoord. Op 23 april 2026 publiceerde de Raad de definitieve compromisteksten. Daarna volgt de juridisch-taalkundige controle en pas dan de publicatie in het Publicatieblad van de EU. Op het moment van schrijven — eind augustus 2026 — is die publicatie er nog niet, en blijft PSD2 het geldende kader.

Zodra publicatie er wel is, loopt de klok als volgt:

• Twintig dagen na publicatie — inwerkingtreding van de PSR
• Achttien maanden na inwerkingtreding — de PSR wordt van toepassing, en lidstaten moeten PSD3 hebben omgezet in nationale wetgeving
• Vierentwintig maanden na inwerkingtreding — de IBAN-naamcheck en de bijbehorende aansprakelijkheid gaan in; die krijgen bewust een langere termijn omdat er systeemwijzigingen voor nodig zijn
• Bestaande vergunningen — huidige vergunningen van betaal- en e-geldinstellingen blijven een afgebakende periode geldig (vierentwintig maanden, verlengbaar tot dertig), mits de houder op tijd herauthorisatie onder PSD3 aanvraagt

Reken dus niet op een harde datum. Reken op een reeks termijnen die pas gaat lopen op de dag van publicatie — en houd er rekening mee dat die datum al een paar keer is opgeschoven.

De PSR geldt direct na de transitieperiode. PSD3 moet eerst door elk EU-land in nationale wetgeving worden omgezet — dat kan langer duren, maar de inhoudelijke regels uit de PSR wachten daar niet op.

Wat verandert er concreet?

1. Verification of Payee wordt universeel

De IBAN-naamcheck bestaat al voor eurobetalingen via de Instant Payments Regulation: bij een SEPA Instant-overboeking controleert de bank van de betaler of de naam en het IBAN van de begunstigde overeenkomen. Bij een mismatch krijgt de betaler een waarschuwing.

De PSR trekt dat breder: Verification of Payee wordt verplicht voor alle overboekingen, niet alleen instant payments en niet alleen in euro's. Dat betekent dat je software rekening moet houden met een extra stap in de betaalflow: de check kan een match, partial match of mismatch opleveren, en bij de laatste twee moet de gebruiker expliciet bevestigen dat hij wil doorgaan.

Die verplichting krijgt de langste aanlooptijd van het hele pakket: vierentwintig maanden na inwerkingtreding in plaats van achttien. Dat is geen uitstel maar erkenning dat banken en betaaldienstverleners er echte systeemwijzigingen voor moeten doorvoeren.

Voor je software betekent dat:

• Verwerk het VoP-resultaat als status in je betaalflow (match, partial match, mismatch)
• Log het resultaat en de gebruikersbeslissing voor je audit trail
• Houd er rekening mee dat een mismatch de conversie kan verlagen — toon duidelijke uitleg aan de gebruiker

2. Fraudeaansprakelijkheid verschuift naar de betaaldienstverlener

Onder PSD2 droeg de consument in veel gevallen de schade bij APP-fraude: hij had immers zelf op "bevestigen" gedrukt. De PSR draait die logica om. Als een betaaldienstverlener zijn fraudedetectie niet op orde heeft en een klant wordt opgelicht door iemand die zich voordoet als de PSP zelf (impersonatiefraude), draagt de PSP de financiële verantwoordelijkheid.

Concreet worden betaaldienstverleners verplicht om:

• Geautomatiseerde fraudedetectie in te zetten die anomalieën, gedragspatronen en apparaat-onregelmatigheden binnen milliseconden herkent
• De IBAN-naamcheck uit te voeren en de betaler te waarschuwen bij een mismatch — als de PSP dat nalaat en er fraude volgt, is hij aansprakelijk
• Slachtoffers van impersonatiefraude te vergoeden als de PSP niet kan aantonen dat zijn fraudepreventie adequaat was

Als je zelf een platform bouwt dat betalingen faciliteert, verschuift deze aansprakelijkheid indirect ook naar jou: je moet kunnen aantonen dat je de waarschuwingen van je PSP correct hebt doorgestuurd aan de eindgebruiker en dat je geen frauduleuze transactiepatronen hebt gemist.

3. Open banking krijgt tanden

PSD2 verplichtte banken om hun rekeningdata te delen via API's, maar stelde weinig eisen aan de kwaliteit van die API's. Het resultaat: trage endpoints, ongedocumenteerde wijzigingen en een fallback-mechanisme via screen scraping dat in de praktijk vaker nodig was dan gewenst.

De PSR pakt dat fundamenteel aan:

• Performance-pariteit: de open banking API moet dezelfde snelheid en beschikbaarheid leveren als het eigen online-bankierkanaal van de bank
• Geen fallback meer: het PSD2 screen-scraping-fallback verdwijnt, omdat de API-kwaliteit contractueel wordt afgedwongen
• Dashboard voor consumenten: elke bank moet een realtime dashboard aanbieden waarmee consumenten zien welke derde partijen toegang hebben tot hun rekeningdata en die toegang per partij kunnen intrekken
• Kwartaalrapportage: banken moeten elk kwartaal aan hun toezichthouder rapporteren over de performance en beschikbaarheid van hun open banking API's

Voor ontwikkelaars die open banking integreren, is dit goed nieuws: de API's worden betrouwbaarder en voorspelbaarder. Maar het betekent ook dat je geen fallback-scenario's meer hoeft te bouwen voor het geval de bank-API niet beschikbaar is — je mag er (eindelijk) van uitgaan dat die werkt.

4. SCA wordt verfijnd, niet verzwaard

Strong Customer Authentication (twee-factorauthenticatie bij betaaltransacties) blijft de norm. De PSR brengt geen fundamentele wijzigingen aan in de SCA-eisen, maar verfijnt het uitzonderingsframework:

• De drempelwaarde voor contactloze betalingen wordt geactualiseerd
• Transaction Risk Analysis (TRA) uitzonderingen worden beter geharmoniseerd
• De interactie tussen SCA en nieuwe authenticatiemethoden zoals passkeys en biometrie wordt verduidelijkt

Let op: Visa heeft aangekondigd zijn Digital Authentication Framework (DAF) 3DS-programma in september 2026 te beëindigen en over te stappen op Visa Payment Passkey. Dat staat los van de PSR, maar valt in dezelfde transitieperiode. Als je webshop of platform kaartbetalingen verwerkt via 3D Secure, is het verstandig om met je PSP te overleggen of de overgang naar de nieuwe Visa-standaard impact heeft op jouw integratie.

5. De commercial agent-vrijstelling wordt aangescherpt

Onder PSD2 konden marktplaatsen en platforms betalingen faciliteren zonder vergunning als ze optraden als "handelsagent" van de verkoper. Die vrijstelling werd ruim geïnterpreteerd en leidde ertoe dat sommige platforms feitelijk als betaaldienstverlener opereerden zonder het bijbehorende toezicht.

De PSR scherpt de commercial agent-vrijstelling aan: platforms die betalingen verwerken moeten nauwkeuriger beoordelen of ze onder de vrijstelling vallen of dat ze een vergunning nodig hebben. Als je een marktplaats of platform bouwt waar geld tussen partijen vloeit, is dit het moment om de juridische positie opnieuw te laten beoordelen.

Wat betekent dit voor jouw webshop of platform?

De impact hangt af van hoe je betalingen hebt geïntegreerd. Drie scenario's:

De relatie met andere EU-betaalwetgeving

PSD3 en de PSR staan niet op zichzelf. Ze werken samen met een reeks andere wetten die het Europese betalingslandschap hervormen:

• Instant Payments Regulation (2024): SEPA Instant is sinds oktober 2025 verplicht voor alle eurobetalingen. De PSR breidt de bijbehorende VoP-verplichting uit naar alle valuta's en alle soorten overboekingen.
• Wero/EPI: het Europese betaalinitiatief dat iDEAL vervangt, is gebouwd op SEPA Instant en profiteert van de betere API-infrastructuur die de PSR afdwingt.
• FIDA (Financial Data Access): waar PSD3/PSR gaat over betaalrekeningdata, regelt FIDA de bredere toegang tot financiële data (spaarrekeningen, hypotheken, verzekeringen). Samen vormen ze het open finance-framework van de EU.
• eIDAS 2.0 / EUDI Wallet: de Europese digitale identiteitswallet die eind 2026 beschikbaar wordt, kan op termijn een authenticatiemethode worden die onder SCA valt.

Wat kun je nu al doen?

De compliance-deadline ligt nog anderhalf jaar weg, maar de architectuurbeslissingen die je nu neemt bepalen hoe soepel die transitie verloopt. Vijf concrete stappen:

1. Inventariseer je betaalstromen. Welke betaalmethoden gebruik je? Faciliteer je betalingen tussen derden? Val je onder de commercial agent-vrijstelling? Documenteer dit zodat je een helder uitgangspunt hebt.
2. Controleer je audit trail. De PSR legt meer nadruk op aantoonbare fraudepreventie. Zorg dat je software elke transactie, elk VoP-resultaat en elke SCA-beslissing logt en dat die logs bewaard blijven.
3. Praat met je PSP. Vraag Mollie, Stripe of je andere betaalprovider naar hun PSD3/PSR-roadmap. Welke wijzigingen verwachten zij in hun API? Komen er nieuwe webhookstatussen? Wanneer publiceren ze hun migratiegids?
4. Beoordeel je platform-positie. Als je een marktplaats of platform bouwt waar geld tussen partijen vloeit, laat dan nu al juridisch toetsen of je onder de aangescherpte commercial agent-vrijstelling valt.
5. Volg de publicatie. Zodra de definitieve tekst in het Publicatieblad verschijnt, start de klok van achttien maanden. Abonneer je op de updates van je branchevereniging of toezichthouder.

Mijn kijk op PSD3 en de PSR

PSD3 en de PSR zijn geen revolutie. Ze zijn de correctie op wat PSD2 beloofde maar niet volledig waarmaakte: open banking wordt afdwingbaar, fraudeaansprakelijkheid komt te liggen bij de partij die er iets aan kan doen, en de IBAN-naamcheck wordt universeel. Dat is verstandige wetgeving, en het valt me op hoe weinig ophef erover is vergeleken met PSD2 in 2018.

Wat ik in de praktijk zie, is dat de meeste bedrijven zich zorgen maken over het verkeerde deel. De vraag die ik krijg is bijna altijd: "moeten we onze checkout aanpassen?" Meestal niet. Als je via Mollie of Stripe werkt, absorbeert je provider het leeuwendeel. De vraag die niemand stelt, is de vraag die er wél toe doet: kan ik straks aantónen dat mijn systeem het goed heeft gedaan? Want dat is wat de PSR echt verandert — de bewijslast verschuift. Niet de klant moet aantonen dat hij is opgelicht, de dienstverlener moet aantonen dat zijn preventie deugde.

Die verschuiving heeft één concrete consequentie voor software: je audit trail is geen administratieve luxe meer maar je verdediging. Elke waarschuwing die je aan een gebruiker toonde, elke bevestiging die hij gaf, elk fraudesignaal dat je van je PSP kreeg — als dat niet gelogd is, is het niet gebeurd. Dat is precies het soort ding dat je goedkoop inbouwt en duur achteraf repareert.

En als je een marktplaats of platform bouwt: laat die commercial agent-vrijstelling serieus toetsen. Ik heb te vaak gezien dat een platform "even" geld doorsluist en pas jaren later ontdekt dat het daarmee feitelijk betaaldienstverlener is geworden. Onder de aangescherpte regels wordt dat een duurder misverstand.

— Jasper

Zo helpt Coding Agency hierbij

Wij bouwen maatwerkapplicaties en platforms waar betaalstromen doorheen lopen — van webshops en abonnementsplatforms tot marktplaatsen met split payments. In de praktijk komt dat neer op: betaalflows die de statussen van je PSP volledig verwerken in plaats van alleen de gelukkige route, idempotente afhandeling van webhooks zodat een herhaalde melding nooit tot een dubbele boeking leidt, een audit trail die per transactie vastlegt wat er is getoond en beslist, en terugboekingen die netjes in je administratie landen.

Wil je weten wat PSD3 en de PSR concreet betekenen voor jouw webshop, platform of open banking-integratie? Neem contact op voor een vrijblijvend gesprek.

Bronnen: Norton Rose Fulbright, Arthur Cox en DLA Piper. Dit artikel is geen juridisch advies.