PSD3 och PSR: Det handlare faktiskt behöver ändra

Under PSD2 sattes de löpande uppförandereglerna — tidpunkt för återbetalning, bedrägeriansvar, klagomålshantering — av ett direktiv. Direktiv gäller inte direkt. Var och en av de 27 medlemsstaterna var tvungen att implementera PSD2 i sin egen nationella lagstiftning, och alla gjorde det med sin egen tidplan, sina egna luckor och sin egen lokala tolkning. En handlare som verkade i fem EU-länder verkade i praktiken under fem något olika regelböcker, trots att alla påstods implementera "samma" direktiv.

Det nya paketet delar upp arbetet på ett annat sätt. PSD3 förblir ett direktiv och täcker huvudsakligen licensiering, tillsyn och marknadstillträde för betalningsinstitut — sådant som påverkar din PSP:s regulatoriska status, inte din kassa. De uppföranderegler som faktiskt berör handlare — bedrägeriansvar, återbetalningsskyldigheter, autentiseringskrav, klagomålshantering — flyttas in i PSR, en förordning. Förordningar gäller direkt och identiskt i varje medlemsstat, utan något steg för nationell implementering och utan utrymme för lokala tolkningsegenheter.

Enligt juridisk analys av de överenskomna texterna är detta ett medvetet svar på det fragmenteringsproblem som PSD2 skapade — PSR är utformad för att ge handlare och PSP:er en enhetlig regelbok istället för 27 lokala varianter (Freshfields översikt av de överenskomna texterna). För handlare innebär det att den efterlevnadsgranskning du gör för din tyska enhet, när PSR börjar gälla, bör ge samma svar som granskningen för din irländska eller portugisiska enhet. Det är en genuin förenkling, men det innebär också att argumentet "den lokala tillsynsmyndigheten är förlåtande med det här" inte längre finns att falla tillbaka på.

PSD2:s ansvarsregler byggdes kring en ganska smal definition av en "obehörig" transaktion — en som kunden inte godkänt. Bedrägerier har utvecklats sedan då. Social engineering-bedrägerier, där en bedragare utger sig för att vara en bankanställd eller övertalar en kund att godkänna en överföring direkt, ger tekniskt sett upphov till en "godkänd" transaktion enligt det gamla ramverket, vilket historiskt lämnat kunden (och därigenom handlaren som förlitar sig på den betalningen) med mindre möjlighet till gottgörelse.

PSR utökar ansvaret i några riktningar som spelar roll för handlare:

• Spoofing-baserat bedrägeri — där en bedragare utger sig för att vara en PSP:s personal eller varumärke — flyttar mer ansvar över på betaltjänstleverantörer, i stället för att låta kunden bära förlusten.
• Underlåtenhet att erbjuda eller korrekt tillämpa strong customer authentication (SCA) lägger ansvaret på den part i kedjan som misslyckades med att tillämpa den korrekt, vilket omfattar acquirers och, i vissa flöden, handlare som kringgår autentisering.
• Långsam hantering av bedrägerianmälningar från en PSP kan i sig skapa ansvar, vilket är tänkt att driva banker och PSP:er mot snabbare hantering av bedrägerianmälningar istället för att behandla varje anspråk som en långdragen utredning.

För en handlare blir den praktiska effekten att bedrägeritvister i allt högre grad kommer att avgöras av bevis för vad som hände under autentiseringen, inte bara av om kunden säger att de inte godkände betalningen. Det gör dina autentiseringsloggar och SCA-utfallsdata till en del av ditt bevismaterial i tvister, inte bara en efterlevnadsjournal du sparar och glömmer bort.

En av de mest konkreta förändringarna för kassaflöden gäller att verifiera att namnet på ett konto faktiskt matchar den som betalaren tror att de skickar pengar till. Detta bygger på mekanismen Verification of Payee (VoP), som redan krävs för direkta överföringar (instant credit transfers) enligt EU:s förordning om direktbetalningar (Instant Payments Regulation), och det nya betalningspaketet utökar den logiken ytterligare över betaltjänster i stort.

I praktiken innebär VoP att betalarens bank kontrollerar kontohavarens namn mot IBAN innan en överföring slutförs, och flaggar en avvikelse — ett "no match" eller "close match" — till betalaren innan de bekräftar betalningen. Det riktar sig direkt mot bedrägerier med godkända push-betalningar (authorized push payment fraud), där en kund luras att överföra pengar till ett konto som inte tillhör den de tror.

För handlare påverkar detta alla flöden där en kund initierar en banköverföring för att betala dig — kontobaserade betalningsmetoder, betalningar initierade via open banking, eller något kassasteg där du visar dina egna mottagaruppgifter för att en kund ska slutföra en överföring:

• Det juridiska namnet som är registrerat på ditt handlarbankkonto måste exakt matcha det varumärke/handelsnamn som kunder ser på din kassasida, annars börjar kunder se avvikelsevarningar som ser ut som bedrägerisignaler även när allt är i sin ordning.
• Om du driver verksamhet under ett handelsnamn som skiljer sig från din juridiska enhets namn är det nu läge att antingen anpassa dem eller se till att din kassa tydligt förklarar avvikelsen innan en kund stöter på en VoP-varning mitt i betalningen.
• All intern dokumentation som listar dina avvecklingskontouppgifter för avstämningsändamål bör kontrolleras mot vad som faktiskt är registrerat hos din bank, eftersom en inaktuell uppgift kommer att visa sig som en avvikelse för varje kund som använder en överföringsbaserad metod.

Det här är ett fall där en femminuterskontroll — att bekräfta att ditt bankkontos registrerade namn matchar din butiks varumärke — förhindrar en våg av kundförvirring när VoP-liknande kontroller väl är brett i kraft.

PSD2 gav kontoförvaltande banker två alternativ för att exponera kontodata till tredje part: ett dedikerat API, eller ett reservgränssnitt byggt på deras befintliga kundvända onlinebankskärmar. I praktiken var reservgränssnitt ofta långsammare, mindre tillförlitliga och underhölls inkonsekvent, vilket gjorde kassaflöden baserade på open banking — pay-by-bank-alternativ, kontoinformation för riskbedömning och liknande funktioner — mindre pålitliga än kortbetalningar.

Det nya ramverket skärper detta. Banker kommer att möta tydligare, mer verkställbara krav kring prestandan för dedikerade gränssnitt — närmare paritet med tillförlitligheten i sina egna kundvända kanaler, med definierade förväntningar kring drifttid och svarstider snarare än den löst tillämpade standarden om "rimlig ansträngning" som präglade delar av PSD2-implementeringen (MoFo:s analys av PSD3/PSR-utvecklingen).

För handlare som erbjuder eller överväger pay-by-bank eller andra kontobaserade kassaalternativ spelar detta roll på två sätt:

• Färre misslyckade eller tidsutlösta auktoriseringsförsök bör innebära färre övergivna varukorgar vid överföringsbaserade betalningsmetoder, som historiskt underpresterat jämfört med kort i fråga om slutförandegrad, delvis på grund av gränssnittens tillförlitlighet.
• Om du förlitar dig på kontoinformationstjänster för riskbeslut — att verifiera kontoinnehav eller kontrollera saldon innan du skickar högvärdiga beställningar — bör de dataflödena bli mer konsekventa att bygga arbetsflöden kring, snarare än något du måste bygga återförsöks- och reservlogik för.

Ingenting av detta tar bort behovet av att testa din integration mot verkligt bankbeteende när reglerna väl är i kraft. Det innebär dock att den baslinjenivå av tillförlitlighet du testar mot bör förbättras.

Det är den del som ofta hoppas över i de flesta juridiska sammanfattningar. Här är vad som förändras på din sida av skrivbordet.

Dina PSP- och acquirer-avtal. Granska ansvarsfördelningsklausulerna i dina befintliga betaltjänstavtal. I avtal från PSD2-eran antog ansvarsformuleringarna ofta den gamla, snävare definitionen av "obehörig transaktion" och de gamla undantagsreglerna för SCA. När PSR:s ansvarsbestämmelser börjar gälla kan avtal som inte uppdaterats hänvisa till standarder som inte längre matchar lagen, vilket skapar oklarhet precis när du behöver klarhet — mitt i en tvist. Fråga din PSP direkt om deras standardavtal för handlare kommer att uppdateras för att återspegla PSR:s ansvarsfördelning, och få svaret skriftligt istället för att anta att det hanteras.

• Ditt kassaflöde. Tre konkreta förändringar att kontrollera:
• Bekräfta att det juridiska namnet knutet till ditt avvecklingskonto matchar din butiks varumärke, för att undvika onödiga VoP-avvikelsevarningar vid överföringsbaserade betalningsmetoder.
• Se till att ditt SCA-utmaningsflöde (3DS eller motsvarande) degraderas smidigt — en kund som avbryter ett köp därför att ett autentiseringssteg misslyckades tekniskt, snarare än att de avböjde det, är precis det scenario de nya ansvarsreglerna är utformade för att fånga, och du vill inte hamna på fel sida av det när en tvist granskas.
• Om du erbjuder pay-by-bank eller andra kontobaserade alternativ, planera att testa om slutförandegraderna när de nya kraven på API-prestanda är i kraft — de antaganden om tillförlitlighet som din reservlogik byggdes kring kanske inte längre är den begränsande faktorn.

• Din tvisteprocess. De bevis som avgör en bedrägeri- eller chargeback-tvist förändras. Där tvister från PSD2-eran ofta handlade om huruvida SCA tillämpades alls, kommer tvister i PSR-eran oftare att handla om hur den tillämpades, om en VoP-kontroll kördes och vilket resultat den gav, och hur snabbt en bedrägerianmälan eskalerades. Det innebär att:
• Ditt supportteam behöver tillgång till loggar över autentiseringsutfall, inte bara transaktionsstatus, när de svarar på en tvist.
• Din dokumentation för inlämning av bevis bör uppdateras för att inkludera VoP-resultat (match/no-match) som ett standardfält, när den datan väl finns i dina transaktionsuppgifter.
• Interna SLA:er för att eskalera misstänkta bedrägerianmälningar till din PSP bör skärpas, eftersom fördröjning i sig blir en ansvarsfaktor snarare än ett neutralt administrativt steg.

Förändringen från PSD2 till PSR handlar mindre om att helt nya skyldigheter dyker upp ur ingenstans och mer om att befintliga luckor täts.

Handlare som behandlat bedrägeriansvar, SCA och bevis i tvister som "vad den lokala banken nu säger" kommer att upptäcka att det svaret inte längre håller när samma förordningstext gäller i varje medlemsstat. Arbetet är administrativt — att uppdatera avtal, kassatexter och bevismallar — men det måste ske innan den generella tillämpningen, inte efter att den första tvisten enligt de nya reglerna avslöjar luckan.

Inget av detta kräver att du bygger om din kassa från grunden. Det kräver att du behandlar ditt PSP-avtal, dina registrerade kontouppgifter och dina bevismallar för tvister som levande dokument som behöver en granskning enligt en specifik tidplan — vilket är poängen med checklistan nedan.

Det exakta datumet för generell tillämpning beror på när Europeiska unionens officiella tidning publicerar sluttexten, men ordningsföljden är fastställd. Använd det här som en arbetstidplan snarare än en fast deadline, och bekräfta datumen när publiceringen i officiella tidningen är bekräftad.

• Till Q4 2026 — Publicering i officiella tidningen väntas (juni–juli 2026). När den publicerats, räkna ut ditt fasta datum för generell tillämpning, 21 månader senare, och sätt det i din efterlevnadskalender. Påbörja PSP-avtalsgranskningen nu istället för att vänta på deadline.
• Under 2027 — Bekräfta din PSP:s plan för att uppdatera handlarvillkoren för att återspegla PSR:s ansvarsfördelning. Granska ditt avvecklingskontos registrerade juridiska namn mot din kassas varumärke. Kartlägg vilka av dina kassaflöden som använder SCA och dokumentera nuvarande undantagslogik så att du kan jämföra den mot de slutgiltiga PSR-kraven.
• Tidigt 2028 — Testa din process för bevis i tvister från början till slut: kan ditt supportteam faktiskt hämta SCA-utfall och VoP-matchningsdata för en transaktion på begäran, eller kräver det ett utvecklingsärende? Åtgärda den luckan innan den testas av en pågående tvist.
• Vid generell tillämpning (uppskattningsvis mars–april 2028) — Bekräfta att uppdaterade PSP-avtal är undertecknade, att kassatexter återspeglar eventuella krav på mottagarnamn, och att din tvistedokumentation innehåller de nya bevisfälten. Behandla datumet för generell tillämpning som den punkt då allt ovan redan bör vara i drift, inte den punkt där du börjar.

Cost+ bygger på IC++ (Interchange Plus Plus)-prissättning just därför att vi tror att handlare fattar bättre beslut när komponenterna i en betalning — interchange, scheme fee och vårt pålägg — är synliga snarare än sammanbuntade. Samma princip gäller för regulatorisk förändring: ju tidigare du kan se vad som faktiskt förändras i ansvars- och beviskrav, desto mindre störande blir övergången. Om du vill diskutera hur din nuvarande kassa och tvisthantering ligger mot PSR-tidplanen, kontakta vårt team eller jämför din nuvarande avgiftsstruktur med den publicerade prissättningen för low-risk på vår webbplats medan du granskar avtal.