PSD3 og PSR: Det handlende faktisk skal ændre

Under PSD2 blev de daglige adfærdsregler — tidspunkt for refusion, svindelansvar, klagebehandling — fastsat af et direktiv. Direktiver gælder ikke direkte. Hver af de 27 medlemslande skulle implementere PSD2 i deres egen nationale lovgivning, og det gjorde de med hver deres tidsplan, hver deres huller og hver deres lokale tolkning. En handlende, der drev virksomhed i fem EU-lande, opererede i praksis under fem lidt forskellige regelsæt, selv om de alle hævdede at implementere "det samme" direktiv.

Den nye pakke deler arbejdet anderledes. PSD3 forbliver et direktiv og dækker primært licensering, tilsyn og markedsadgang for betalingsinstitutter — den type ting, der påvirker din PSP's regulatoriske status, ikke din checkout. De adfærdsregler, der reelt berører handlende — svindelansvar, refusionsforpligtelser, krav til autentificering, klagebehandling — flytter ind i PSR, en forordning. Forordninger gælder direkte og identisk i alle medlemslande, uden nationalt implementeringsskridt og uden plads til lokale særheder i lovgivningen.

Ifølge juridiske analyser af de vedtagne tekster er dette et bevidst svar på den fragmentering, PSD2 skabte — PSR er designet til at give handlende og PSP'er ét ensartet regelsæt i stedet for 27 lokale varianter (Freshfields' oversigt over de vedtagne tekster). For handlende betyder det, at den compliance-gennemgang, du foretager for din tyske enhed, skal give de samme svar som gennemgangen for din irske eller portugisiske enhed, når PSR gælder. Det er en reel forenkling, men det betyder også, at der ikke længere er et "den lokale tilsynsmyndighed er lempelig med dette"-argument at falde tilbage på.

PSD2's ansvarsregler var bygget op omkring en ganske snæver idé om en "uautoriseret" transaktion — en, kunden ikke godkendte. Svindel har udviklet sig siden da. Social engineering-svindel, hvor en bedrager udgiver sig for en bankmedarbejder eller overtaler en kunde til direkte at godkende en overførsel, producerer teknisk set en "autoriseret" transaktion under den gamle ramme, hvilket historisk har efterladt kunden (og i forlængelse heraf den handlende, der er afhængig af betalingen) med mindre mulighed for at søge oprejsning.

PSR udvider ansvaret i flere retninger, der har betydning for handlende:

• Spoofing-baseret svindel — hvor en bedrager udgiver sig for en PSP's personale eller brand — flytter mere ansvar over på betalingstjenesteudbydere i stedet for at lade kunden bære tabet.
• Manglende tilbud om eller korrekt anvendelse af Strong Customer Authentication (SCA) placerer ansvaret hos den part i kæden, der ikke anvendte den korrekt, hvilket omfatter acquirers og, i visse flows, handlende der omgår autentificering.
• Langsom håndtering af svindelanmeldelser hos en PSP kan i sig selv skabe ansvar, hvilket skal motivere banker og PSP'er til hurtigere sagsbehandling af svindelanmeldelser i stedet for at behandle hver klage som en langvarig undersøgelse.

For en handlende betyder det i praksis, at svindeltvister i stigende grad vil afhænge af dokumentation for, hvad der skete under autentificeringen, ikke kun af, om kunden siger, de ikke godkendte betalingen. Det gør dine autentificeringslogs og SCA-udfaldsdata til en del af dit tvistbevismateriale, ikke bare en compliance-registrering, du opbevarer og glemmer.

En af de mest konkrete ændringer for checkout-flows involverer at verificere, at navnet på en konto faktisk matcher, hvem betaleren tror, de sender penge til. Dette bygger videre på mekanismen Verification of Payee (VoP), som allerede er krævet for øjeblikkelige kreditoverførsler under EU's forordning om instant payments, og den nye betalingspakke udvider denne logik yderligere til flere betalingstjenester.

I praksis betyder VoP, at betalerens bank kontrollerer kontohaverens navn mod IBAN'en, før en overførsel gennemføres, og markerer en uoverensstemmelse — et "no match" eller "close match" — tilbage til betaleren, før de bekræfter betalingen. Det er direkte målrettet mod svindel med autoriserede push-betalinger, hvor en kunde bliver ført bag lyset til at overføre penge til en konto, der ikke er den, de tror.

For handlende påvirker dette ethvert flow, hvor en kunde initierer en bankoverførsel for at betale dig — konto-til-konto-betalingsmetoder, open banking-initierede betalinger, eller ethvert checkout-trin, hvor du viser dine egne betalingsmodtageroplysninger, som kunden skal bruge til at gennemføre en overførsel:

• Det juridiske navn, der er registreret på din erhvervsbankkonto, skal nøjagtigt matche det handelsnavn, kunderne ser på din checkout-side, ellers vil kunderne begynde at se uoverensstemmelsesadvarsler, der ligner svindelsignaler, selv når alt er i orden.
• Hvis du opererer under et handelsnavn, der er forskelligt fra dit juridiske enhedsnavn, er det nu tid til enten at bringe dem i overensstemmelse eller sørge for, at din checkout klart forklarer forskellen, før en kunde rammer en VoP-advarsel midt i betalingen.
• Al intern dokumentation, der lister dine afregningskontooplysninger til afstemningsformål, bør kontrolleres mod, hvad der faktisk er registreret hos din bank, da en forældet registrering vil vise sig som en uoverensstemmelse for hver kunde, der bruger en overførselsbaseret metode.

Dette er et tilfælde, hvor en fem-minutters administrativ kontrol — at bekræfte, at din bankkontos registrerede navn matcher din butiksbranding — undgår en bølge af kundeforvirring, når VoP-lignende kontroller er bredt indført.

PSD2 gav kontoførende banker to muligheder for at give tredjeparter adgang til kontodata: et dedikeret API eller en fallback-grænseflade bygget på deres eksisterende kundevendte netbank-skærme. I praksis var fallback-grænseflader ofte langsommere, mindre stabile og vedligeholdt inkonsekvent, hvilket gjorde open banking-baserede checkout-flows — pay-by-bank-muligheder, kontooplysninger til risikoscoring og lignende funktioner — mindre driftssikre end kortbetalinger.

Den nye ramme skærper dette. Banker vil stå over for tydeligere, mere håndhævelige forpligtelser omkring performance på deres dedikerede grænseflader — tættere på niveau med driftssikkerheden i deres egne kundevendte kanaler, med definerede forventninger til driftstid og svartider frem for den løst håndhævede "rimelig anstrengelse"-standard, der har kendetegnet dele af PSD2-implementeringen (MoFo's analyse af udviklingen inden for PSD3/PSR).

For handlende, der tilbyder eller overvejer pay-by-bank eller andre konto-til-konto-checkout-muligheder, har dette betydning på to måder:

• Færre mislykkede eller timeoutede autorisationsforsøg bør betyde færre forladte indkøbskurve på overførselsbaserede betalingsmetoder, som historisk har underperformet i forhold til kort på gennemførelsesrate, delvist på grund af grænsefladepålidelighed.
• Hvis du er afhængig af kontooplysningstjenester til risikobeslutninger — verificering af kontoejerskab eller kontrol af saldi før forsendelse af ordrer med høj værdi — bør disse datastrømme blive mere konsistente at bygge arbejdsgange omkring, i stedet for noget du skal bygge retry-logik og fallback-håndtering til.

Intet af dette fjerner behovet for at teste din integration mod reel bankadfærd, når reglerne er trådt i kraft. Det betyder, at det pålidelighedsniveau, du tester mod, bør forbedres.

Det er den del, der bliver sprunget over i de fleste juridiske resuméer. Her er, hvad der ændrer sig på din side af bordet.

Dine PSP- og acquirer-kontrakter. Gennemgå ansvarsfordelingsklausulerne i dine eksisterende betalingstjenesteaftaler. Under PSD2-æra-kontrakter antog ansvarssproget ofte den gamle, snævrere definition af "uautoriseret transaktion" og de gamle SCA-fritagelsesregler. Når PSR's ansvarsbestemmelser gælder, kan kontrakter, der ikke er opdateret, referere til standarder, der ikke længere matcher lovgivningen, hvilket skaber tvivl netop når du har brug for klarhed — midt i en tvist. Spørg din PSP direkte, om deres standard handlendevilkår vil blive opdateret for at afspejle PSR's ansvarsfordeling, og få svaret på skrift i stedet for at antage, at det er håndteret.

• Dit checkout-flow. Tre konkrete ting at kontrollere:
• Bekræft at det juridiske navn, der er knyttet til din afregningskonto, matcher din butiksbranding, for at undgå unødvendige VoP-uoverensstemmelsesadvarsler på overførselsbaserede betalingsmetoder.
• Sørg for at dit SCA-udfordringsflow (3DS eller lignende) fejler blødt — en kunde, der opgiver et køb, fordi et autentificeringstrin fejlede teknisk, snarere end fordi de afviste det, er nøjagtigt det scenarie, de nye ansvarsregler er designet til at fange, og du vil ikke stå på den forkerte side af det, når en tvist bliver vurderet.
• Hvis du tilbyder pay-by-bank eller andre konto-til-konto-muligheder, planlæg at genteste gennemførelsesrater, når de nye API-performance-forpligtelser er trådt i kraft — de pålidelighedsantagelser, du byggede din fallback-logik omkring, er måske ikke længere den bindende begrænsning.

• Din tvistproces. Det bevismateriale, der afgør en svindel- eller chargeback-tvist, ændrer sig. Hvor PSD2-æra-tvister ofte afhang af, om SCA blev anvendt overhovedet, vil PSR-æra-tvister oftere afhænge af hvordan det blev anvendt, om en VoP-kontrol blev kørt og hvilket resultat den gav, og hvor hurtigt en svindelanmeldelse blev eskaleret. Det betyder:
• Dit supportteam skal have adgang til autentificeringsudfaldslogs, ikke bare transaktionsstatus, når de svarer på en tvist.
• Din dokumentation til indsendelse af bevismateriale bør opdateres til at inkludere VoP match/no-match-resultater som et standardfelt, når disse data findes i dine transaktionsregistre.
• Interne SLA'er for eskalering af mistænkte svindelanmeldelser til din PSP bør skærpes, da forsinkelse i sig selv bliver en ansvarsfaktor snarere end et neutralt administrativt trin.

Skiftet fra PSD2 til PSR handler mindre om, at nye forpligtelser dukker op ud af det blå, og mere om, at eksisterende huller lukkes.

Handlende, der har behandlet svindelansvar, SCA og tvistbevis som "hvad den lokale bank nu siger", vil opleve, at det svar ikke længere holder, når den samme forordningstekst gælder i alle medlemslande. Arbejdet er administrativt — opdatering af kontrakter, checkout-tekst og bevisskabeloner — men det skal ske før den generelle anvendelse, ikke efter at den første tvist under de nye regler har afsløret hullet.

Intet af dette kræver, at du genopbygger din checkout på en ny platform. Det kræver, at du behandler din PSP-kontrakt, dine registrerede kontooplysninger og dine skabeloner til tvistbevis som levende dokumenter, der skal gennemgås på en bestemt tidslinje — hvilket er formålet med tjeklisten nedenfor.

Den præcise dato for generel anvendelse afhænger af, hvornår EU-Tidende offentliggør den endelige tekst, men rækkefølgen er fastlagt. Brug dette som en arbejdstidslinje snarere end en fast deadline, og bekræft datoerne, når offentliggørelsen i EU-Tidende er bekræftet.

• Inden Q4 2026 — Offentliggørelse i EU-Tidende forventes (juni–juli 2026). Når den er offentliggjort, beregn din faste dato for generel anvendelse 21 måneder senere, og sæt den i din compliance-kalender. Start gennemgangen af PSP-kontrakten nu i stedet for at vente til deadline.
• Gennem 2027 — Bekræft din PSP's plan for opdatering af handlendevilkår for at afspejle PSR's ansvarsfordeling. Gennemgå det registrerede juridiske navn på din afregningskonto mod din checkout-branding. Kortlæg hvilke af dine checkout-flows der bruger SCA, og dokumenter den nuværende fritagelseslogik, så du kan sammenligne den med de færdige PSR-krav.
• Tidligt 2028 — Test din tvistbevisproces fra start til slut: kan dit supportteam faktisk hente SCA-udfald og VoP-matchdata for en transaktion på anmodning, eller kræver det en udviklingsopgave? Løs dette hul, før det bliver testet af en reel tvist.
• Ved generel anvendelse (anslået marts–april 2028) — Bekræft at opdaterede PSP-kontrakter er underskrevet, at checkout-teksten afspejler eventuelle krav til betalingsmodtagernavn, og at din tvistdokumentation inkluderer de nye bevisfelter. Betragt datoen for generel anvendelse som det tidspunkt, hvor alt ovenstående allerede bør køre, ikke det tidspunkt, hvor du begynder.

Cost+ kører på IC++ (Interchange Plus Plus)-prissætning, netop fordi vi tror på, at handlende træffer bedre beslutninger, når komponenterne i en betaling — interchange, scheme fee og vores markup — er synlige i stedet for sammenblandet. Det samme princip gælder for lovændringer: Jo tidligere du kan se, hvad der reelt ændrer sig i ansvars- og bevismæssige krav, desto mindre disruptivt bliver overgangen. Hvis du vil tale om, hvordan din nuværende checkout- og tvistopsætning stemmer overens med PSR-tidslinjen, kontakt vores team, eller sammenlign din nuværende gebyrstruktur med den offentliggjorte low-risk-prissætning på vores side, mens du gennemgår kontrakter.