PSD3 e PSR: cosa devono cambiare davvero gli esercenti

Con la PSD2, le regole di condotta quotidiane — tempistiche dei rimborsi, responsabilità per frode, gestione dei reclami — erano stabilite da una direttiva. Le direttive non si applicano direttamente. Ciascuno dei 27 stati membri ha dovuto recepire la PSD2 nel proprio diritto nazionale, e ognuno lo ha fatto con tempistiche proprie, lacune proprie e interpretazioni locali proprie. Un esercente attivo in cinque paesi UE operava, di fatto, sotto cinque regolamenti leggermente diversi, anche se tutti dichiaravano di attuare "la stessa" direttiva.

Il nuovo pacchetto suddivide il lavoro in modo diverso. La PSD3 resta una direttiva e riguarda principalmente le licenze, la supervisione e l'accesso al mercato per gli istituti di pagamento — questioni che riguardano lo status regolamentare del suo PSP, non il suo checkout. Le regole di condotta che toccano davvero gli esercenti — responsabilità per frode, obblighi di rimborso, requisiti di autenticazione, gestione dei reclami — passano nel PSR, un regolamento. I regolamenti si applicano direttamente e in modo identico in ogni stato membro, senza fase di recepimento nazionale e senza margine per interpretazioni locali.

Secondo l'analisi giuridica dei testi concordati, si tratta di una risposta deliberata al problema della frammentazione creato dalla PSD2 — il PSR è pensato per dare a esercenti e PSP un'unica disciplina uniforme, invece di 27 varianti locali (la panoramica di Freshfields sui testi concordati). Per gli esercenti, ciò significa che la verifica di conformità condotta per la sua entità tedesca dovrebbe, una volta applicato il PSR, produrre le stesse risposte della verifica condotta per quella irlandese o portoghese. È una semplificazione autentica, ma significa anche che non esiste più l'argomento "il regolatore locale è più tollerante su questo punto" a cui ricorrere.

Le regole sulla responsabilità della PSD2 erano costruite attorno a una nozione piuttosto ristretta di transazione "non autorizzata" — una transazione che il cliente non aveva approvato. La frode, da allora, si è evoluta. Le truffe basate su ingegneria sociale, in cui un truffatore si finge un dipendente bancario o convince un cliente ad autorizzare direttamente un trasferimento, producono tecnicamente una transazione "autorizzata" secondo il vecchio quadro normativo, il che storicamente lasciava al cliente — e di conseguenza all'esercente che si basava su quel pagamento — meno strumenti di tutela.

Il PSR estende la responsabilità in alcune direzioni rilevanti per gli esercenti:

• La frode basata su spoofing — in cui un truffatore si finge personale o brand di un PSP — trasferisce maggiore responsabilità sui fornitori di servizi di pagamento, invece di lasciare che sia il cliente ad assorbire la perdita.
• Il mancato offrire o applicare correttamente la Strong Customer Authentication (SCA) attribuisce la responsabilità alla parte della catena che non l'ha applicata correttamente, il che include gli acquirer e, in alcuni flussi, gli esercenti che eludono l'autenticazione.
• Una gestione lenta delle segnalazioni di frode da parte di un PSP può generare essa stessa responsabilità, un meccanismo pensato per spingere banche e PSP verso tempi di risposta più rapidi alle segnalazioni di frode, invece di trattare ogni reclamo come un'indagine lunga.

Per un esercente, l'effetto pratico è che le dispute per frode dipenderanno sempre più dalle prove di ciò che è accaduto durante l'autenticazione, non solo dal fatto che il cliente dichiari di non aver autorizzato il pagamento. Ciò rende i suoi log di autenticazione e i dati sugli esiti SCA parte delle prove nella disputa, non solo un registro di conformità da conservare e dimenticare.

Uno dei cambiamenti più concreti per i flussi di checkout riguarda la verifica che il nome registrato su un conto corrisponda effettivamente a chi il pagatore pensa di pagare. Questo si basa sul meccanismo di Verification of Payee (VoP), già richiesto per i trasferimenti istantanei ai sensi del regolamento UE sui pagamenti istantanei, e il nuovo pacchetto pagamenti estende questa logica in modo più ampio ai servizi di pagamento.

In pratica, la VoP significa che la banca del pagatore verifica il nome del titolare del conto rispetto all'IBAN prima che il trasferimento venga completato, segnalando al pagatore un'eventuale discrepanza — "nessuna corrispondenza" o "corrispondenza parziale" — prima che questi confermi il pagamento. È una misura mirata direttamente contro le frodi da bonifico autorizzato, in cui un cliente viene indotto a trasferire denaro a un conto diverso da quello che pensa.

Per gli esercenti, questo riguarda qualsiasi flusso in cui un cliente avvia un bonifico bancario per pagare — metodi di pagamento conto-a-conto, pagamenti avviati tramite open banking, o qualsiasi passaggio del checkout in cui vengono mostrati i dati del beneficiario affinché il cliente completi un trasferimento:

• Il nome legale registrato sul suo conto bancario esercente deve corrispondere esattamente al nome commerciale che i clienti vedono nella pagina di checkout, altrimenti i clienti inizieranno a vedere avvisi di discrepanza che sembrano segnali di frode anche quando non c'è nulla di sbagliato.
• Se opera con un nome commerciale diverso dal nome della sua entità legale, questo è il momento di allinearli oppure di far sì che il checkout spieghi chiaramente la discrepanza prima che il cliente incontri un avviso VoP a metà pagamento.
• Qualsiasi documentazione interna che elenca i dati del conto di liquidazione a fini di riconciliazione va verificata rispetto a quanto effettivamente registrato presso la sua banca, poiché un dato non aggiornato emergerà come discrepanza per ogni cliente che utilizza un metodo basato su bonifico.

È un caso in cui un controllo amministrativo di cinque minuti — confermare che il nome registrato sul conto bancario corrisponda al branding del suo negozio online — evita un'ondata di confusione tra i clienti una volta che i controlli in stile VoP saranno ampiamente in vigore.

La PSD2 offriva alle banche depositarie del conto due opzioni per esporre i dati del conto a terze parti: un'API dedicata o un'interfaccia di riserva basata sulle schermate di online banking già rivolte ai clienti. In pratica, le interfacce di riserva erano spesso più lente, meno affidabili e mantenute in modo incoerente, il che rendeva i flussi di checkout basati su open banking — opzioni di pagamento diretto da conto bancario, informazioni sul conto per il risk scoring e funzionalità simili — meno affidabili dei pagamenti con carta.

Il nuovo quadro normativo inasprisce questo aspetto. Le banche dovranno rispettare obblighi più chiari e più facilmente esigibili in materia di performance delle interfacce dedicate — più vicini alla parità con l'affidabilità dei propri canali rivolti ai clienti, con aspettative definite su tempi di attività e tempi di risposta, invece dello standard di "impegno ragionevole" applicato in modo poco rigoroso che ha caratterizzato parti dell'attuazione della PSD2 (l'analisi di MoFo sugli sviluppi di PSD3/PSR).

Per gli esercenti che offrono o stanno valutando opzioni di checkout basate su pagamento diretto da conto bancario o altre soluzioni conto-a-conto, questo conta in due modi:

• Meno tentativi di autorizzazione falliti o scaduti dovrebbero significare meno carrelli abbandonati sui metodi di pagamento basati su bonifico, che storicamente hanno avuto tassi di completamento inferiori a quelli delle carte in parte per problemi di affidabilità dell'interfaccia.
• Se si basa su servizi di informazione sui conti per le decisioni di rischio — verificare la titolarità del conto o controllare i saldi prima di spedire ordini di valore elevato — questi flussi di dati dovrebbero diventare più costanti, un elemento su cui costruire flussi di lavoro, invece di qualcosa per cui è necessario predisporre logiche di ritentativo e gestione dei fallback.

Nulla di tutto ciò elimina la necessità di testare la sua integrazione contro il comportamento reale delle banche una volta che le regole saranno in vigore. Significa però che la baseline di affidabilità su cui testa dovrebbe migliorare.

Questa è la parte che quasi tutti i riassunti giuridici saltano. Ecco cosa si sposta sul suo lato del tavolo.

I contratti con PSP e acquirer. Rivedere le clausole di allocazione della responsabilità nei contratti di servizi di pagamento esistenti. Nei contratti dell'era PSD2, il linguaggio sulla responsabilità presumeva spesso la vecchia definizione più ristretta di "transazione non autorizzata" e le vecchie regole di esenzione SCA. Una volta applicate le disposizioni sulla responsabilità del PSR, i contratti non aggiornati potrebbero fare riferimento a standard non più corrispondenti alla legge, creando ambiguità esattamente nel momento in cui ha bisogno di chiarezza — durante una disputa. Chieda direttamente al suo PSP se le condizioni standard per gli esercenti saranno aggiornate per riflettere l'allocazione della responsabilità del PSR, e ottenga la risposta per iscritto, invece di presumere che la questione sia già gestita.

• Il flusso di checkout. Tre cambiamenti concreti da verificare:
• Confermare che il nome legale associato al conto di liquidazione corrisponda al branding del negozio online, per evitare avvisi di discrepanza VoP non necessari sui metodi di pagamento basati su bonifico.
• Assicurarsi che il flusso di verifica SCA (3DS o equivalente) degradi in modo controllato — un cliente che abbandona un acquisto perché un passaggio di autenticazione è fallito tecnicamente, e non perché lo ha rifiutato, è esattamente lo scenario che le nuove regole sulla responsabilità sono pensate per intercettare, e non vorrà trovarsi nella posizione sbagliata quando una disputa viene esaminata.
• Se offre opzioni di pagamento diretto da conto bancario o altre soluzioni conto-a-conto, preveda di ritestare i tassi di completamento una volta in vigore i nuovi obblighi di performance delle API — i presupposti di affidabilità su cui ha costruito la sua logica di fallback potrebbero non essere più il vincolo determinante.

• Il processo di gestione delle dispute. Le prove che decidono una disputa per frode o un chargeback stanno cambiando. Se le dispute dell'era PSD2 dipendevano spesso dal fatto che la SCA fosse stata applicata o no, le dispute dell'era PSR dipenderanno più spesso da come è stata applicata, se è stato eseguito un controllo VoP e quale risultato ha restituito, e con quale rapidità è stata inoltrata una segnalazione di frode. Questo significa:
• Il suo team di supporto deve avere accesso ai log degli esiti di autenticazione, non solo allo stato della transazione, quando risponde a una disputa.
• La documentazione per la presentazione delle prove va aggiornata per includere i risultati di corrispondenza/non corrispondenza VoP come campo standard, una volta che questi dati esistono nei suoi registri delle transazioni.
• Gli SLA interni per l'escalation delle segnalazioni di sospetta frode verso il suo PSP dovrebbero diventare più stringenti, poiché il ritardo sta diventando esso stesso un fattore di responsabilità, e non più un passaggio amministrativo neutro.

Il passaggio dalla PSD2 al PSR riguarda meno l'apparizione di nuovi obblighi dal nulla e più la chiusura di lacune già esistenti.

Gli esercenti che hanno trattato la responsabilità per frode, la SCA e le prove nelle dispute come "quello che dice la banca locale" scopriranno che questa risposta non tiene più, una volta che lo stesso testo regolamentare si applica in ogni stato membro. Il lavoro è di natura amministrativa — aggiornare contratti, testi del checkout e modelli di prova — ma deve avvenire prima dell'applicazione generale, non dopo che la prima disputa sotto le nuove regole ha già rivelato la lacuna.

Nulla di tutto ciò richiede di ricostruire il checkout da zero. Richiede di trattare il contratto con il PSP, i dati del conto registrati e i modelli di prova per le dispute come documenti vivi, che necessitano di una revisione secondo un calendario preciso — è esattamente lo scopo della checklist qui sotto.

La data esatta di applicazione generale dipende da quando la Gazzetta Ufficiale pubblicherà il testo definitivo, ma la sequenza è fissa. La utilizzi come calendario di lavoro, non come scadenza rigida, e confermi le date una volta certa la pubblicazione sulla Gazzetta Ufficiale.

• Entro il quarto trimestre 2026 — è prevista la pubblicazione sulla Gazzetta Ufficiale (giugno–luglio 2026). Una volta pubblicata, calcoli la sua data precisa di applicazione generale a 21 mesi e la inserisca nel calendario di conformità. Inizi ora la revisione del contratto con il PSP, senza aspettare la scadenza.
• Nel corso del 2027 — confermi con il suo PSP i piani per l'aggiornamento delle condizioni per gli esercenti in linea con l'allocazione della responsabilità del PSR. Verifichi il nome legale registrato sul conto di liquidazione rispetto al branding del checkout. Mappi quali flussi di checkout utilizzano la SCA e documenti la logica di esenzione attuale, per poterla confrontare con i requisiti definitivi del PSR.
• Inizio 2028 — testi il processo di gestione delle prove nelle dispute dall'inizio alla fine: il suo team di supporto può effettivamente recuperare l'esito SCA e i dati di corrispondenza VoP per una transazione su richiesta, o serve un ticket per il team tecnico? Risolva questa lacuna prima che venga messa alla prova da una disputa reale.
• All'applicazione generale (stimata marzo–aprile 2028) — confermi che i contratti aggiornati con il PSP siano firmati, che il testo del checkout rifletta eventuali requisiti sul nome del beneficiario e che la documentazione delle dispute includa i nuovi campi di prova. Consideri la data di applicazione generale come il punto in cui tutto quanto sopra dovrebbe già essere operativo, non il punto da cui iniziare.

Cost+ applica un modello di prezzo IC++ (Interchange Plus Plus) proprio perché crediamo che gli esercenti prendano decisioni migliori quando le componenti di un pagamento — interchange, scheme fee e il nostro markup — sono visibili invece che raggruppate. Lo stesso principio vale per i cambiamenti normativi: prima riesce a vedere cosa sta cambiando davvero nella responsabilità e nei requisiti probatori, meno dirompente sarà la transizione. Se desidera parlare di come il suo attuale assetto di checkout e gestione delle dispute si allinea con la tempistica del PSR, contatti il nostro team oppure confronti la sua struttura di costi attuale con il pricing low-risk pubblicato sul nostro sito mentre rivede i contratti.