Il 19 ottobre 2026, l’European Payments Council (EPC) ha annunciato SCARLET, acronimo di Strong Customer Authentication Acceptance Rulebook and Liability Framework for EUDIW Transactions. L’iniziativa intende definire uno schema europeo per consentire ai prestatori di servizi di pagamento (PSP), comprese le banche, di accettare l’European Digital Identity Wallet (EUDI Wallet) nell’autenticazione dei propri clienti.
L’EUDI Wallet è il portafoglio europeo di identità digitale previsto dal regolamento eIDAS, modificato nel 2024. Permetterà agli utenti di conservare e presentare dati identificativi e attestazioni elettroniche, utilizzandoli anche per accedere a servizi finanziari. Nel settore dei pagamenti potrà diventare uno strumento alternativo alle soluzioni di autenticazione oggi offerte dalle banche.
L’impiego del wallet introduce però un problema organizzativo. Quando l’autenticazione coinvolge una banca, un wallet fornito da un soggetto differente e, eventualmente, un esercente o un altro intermediario, occorre stabilire quali regole siano applicabili, chi debba verificare le informazioni e come vadano ripartite le responsabilità.
Scarlet nasce per affrontare queste questioni attraverso un insieme comune di regole tecniche, operative e contrattuali. L’EPC prevede di pubblicare il primo rulebook nel dicembre 2027, una tempistica che merita attenzione perché coincide con il periodo nel quale diventeranno applicabili gli obblighi europei di accettazione dell’EUDI Wallet da parte delle categorie di operatori privati individuate dalla normativa[1].
Indice degli argomenti
Perché nasce SCARLET e che cosa prevede l’iniziativa EPC
Una risposta alla richiesta della Commissione europea
Il progetto SCARLET è stato approvato dal Consiglio direttivo dell’EPC il 24 settembre 2026, prima dell’annuncio pubblico del 19 ottobre.
Che cos’è l’European Payments Council (EPC)
L’European Payments Council (EPC) è un’associazione internazionale senza scopo di lucro, costituita nel 2002 dal settore bancario europeo per contribuire all’armonizzazione dei pagamenti nell’area SEPA (Single Euro Payments Area). Riunisce prestatori di servizi di pagamento e loro associazioni, sviluppando e gestendo schemi comuni, tra cui quelli per i bonifici SEPA ordinari (SCT), istantanei (SCT Inst) e gli addebiti diretti (SDD). Gli schemi EPC sono utilizzati da migliaia di PSP europei. L’EPC non è un’istituzione dell’Unione europea e non esercita poteri legislativi o regolamentari. La sua funzione consiste nel definire regole operative, standard tecnici e framework contrattuali condivisi dagli operatori aderenti, nel rispetto della normativa europea.
La decisione risponde a un invito rivolto all’EPC da due direzioni generali della Commissione europea: DG CNECT, competente per le reti di comunicazione, i contenuti e le tecnologie, e DG FISMA, responsabile dei servizi finanziari e dell’Unione dei mercati dei capitali.
Lo sviluppo sarà affidato a una task force dell’EPC, in collaborazione con la Commissione europea e l’Autorità bancaria europea (EBA). Un gruppo multilaterale consentirà il coinvolgimento dei rappresentanti dell’ecosistema EUDI Wallet e degli altri operatori interessati.
L’EPC intende costruire uno scheme, ossia un sistema organizzato di regole comuni al quale possano aderire i soggetti coinvolti nell’autenticazione.
Il progetto comprende tre componenti. La prima riguarda il modello contrattuale e di business, con la definizione dei partecipanti, dei requisiti di adesione e dei rispettivi diritti e obblighi. La seconda concerne le regole funzionali e operative.
La terza riguarda le specifiche tecniche, che dovranno valorizzare il lavoro già svolto dalla Commissione europea attraverso l’Architecture and Reference Framework (ARF), la specifica TS12 e le sperimentazioni europee su larga scala.
La presenza del Liability Framework nella denominazione del progetto anticipa una delle sue finalità: definire un quadro condiviso di responsabilità per le interazioni tra i partecipanti.
Il comunicato non contiene ancora le relative disposizioni. Scarlet si trova nella fase di sviluppo e le regole effettive dovranno essere definite attraverso il lavoro tecnico e la successiva consultazione pubblica.
Un unico schema per migliaia di PSP e decine di wallet
L’EPC stima che il mercato europeo possa comprendere oltre 3mila prestatori di servizi di pagamento e almeno 27 fornitori di EUDI Wallet nell’Unione europea e nello Spazio economico europeo.
Le cifre sono utilizzate dall’organizzazione per rappresentare la complessità dell’ecosistema atteso, non costituiscono un censimento di operatori già collegati e pienamente operativi.
Il problema può essere compreso considerando una banca che voglia consentire ai propri clienti di autenticarsi attraverso diversi EUDI Wallet europei.
La banca dovrebbe essere in grado di riconoscere le attestazioni utilizzate per la SCA, verificare la correttezza delle risposte ricevute e assicurare che l’autenticazione soddisfi i requisiti applicabili al servizio richiesto.
Se ogni PSP definisse autonomamente le condizioni per utilizzare i diversi wallet, potrebbero emergere configurazioni tecniche, procedure di certificazione e accordi contrattuali difficilmente compatibili fra loro.
Gli standard europei dell’identità digitale forniscono una base tecnica comune. Rimane però necessario disciplinare il comportamento degli operatori finanziari che utilizzano quei meccanismi nei propri processi regolamentati.
Scarlet intende colmare questa distanza, riducendo il rischio che l’obbligo europeo di accettazione produca una molteplicità di implementazioni nazionali o proprietarie.
L’obbligo di accettazione dell’EUDI Wallet: che cosa prevedono eIDAS 2 e PSD2
L’articolo 5 septies e le condizioni dell’obbligo
Il regolamento (UE) 2024/1183 ha modificato il regolamento eIDAS, introducendo il quadro giuridico europeo dei portafogli di identità digitale[2].
Il calendario normativo distingue due passaggi.
Il primo riguarda gli Stati membri, chiamati a rendere disponibile almeno un EUDI Wallet entro il 24 dicembre 2026.
Il secondo concerne le parti private facenti affidamento sulla certificazione, comunemente definite relying parties. Sono i soggetti che utilizzano i dati e le attestazioni presentati dal wallet per consentire l’accesso a un servizio oppure effettuare una verifica.
L’articolo 5 septies, paragrafo 2, di eIDAS stabilisce un obbligo di accettazione per determinate relying parties private, escluse le microimprese e le piccole imprese. La disposizione si applica quando il diritto europeo o nazionale richiede un’autenticazione forte dell’utente per l’identificazione online oppure quando questa è prescritta contrattualmente.
Fra i settori espressamente contemplati figurano banche e servizi finanziari. L’accettazione deve avvenire su richiesta volontaria dell’utente.
La scadenza è collegata al termine di 36 mesi dall’entrata in vigore degli atti di esecuzione richiamati dalla disposizione. Gli atti pertinenti del 2024 sono entrati in vigore il 24 dicembre dello stesso anno, determinando il termine ordinario del 24 dicembre 2027[3].
È necessario evitare una lettura che trasformi automaticamente tale previsione in un obbligo indistinto per qualsiasi servizio bancario.
L’articolo 5 septies riguarda specificamente l’autenticazione forte dell’utente per l’identificazione online, alle condizioni stabilite dalla norma. Nel settore dei pagamenti opera anche una disciplina distinta, quella della Strong Customer Authentication prevista dalla PSD2.
L’EPC presenta Scarlet come lo strumento per favorire l’adempimento degli obblighi eIDAS da parte dei PSP. La relazione fra questi obblighi e le diverse fattispecie di autenticazione previste dalla disciplina dei pagamenti richiede però una lettura coordinata dei due quadri normativi.
Autenticazione del cliente e autorizzazione del pagamento
La direttiva (UE) 2015/2366, nota come PSD2, disciplina la Strong Customer Authentication (SCA), ossia l’autenticazione forte del cliente[4].
L’articolo 97 prescrive, fatte salve le esenzioni applicabili, che i PSP utilizzino la SCA quando il pagatore accede online al proprio conto di pagamento, dispone un’operazione elettronica oppure compie attraverso un canale remoto un’azione che può comportare un rischio di frode o altri abusi.
L’autenticazione si basa su almeno due elementi indipendenti appartenenti a categorie differenti: conoscenza, possesso e inerenza.
La conoscenza riguarda qualcosa che soltanto l’utente conosce, come una password. Il possesso riguarda uno strumento che l’utente detiene, mentre l’inerenza si riferisce a una caratteristica personale, come un dato biometrico.
Quando la SCA viene applicata a un pagamento elettronico a distanza, la PSD2 richiede anche il dynamic linking, o collegamento dinamico.
In base all’articolo 5 del regolamento delegato (UE) 2018/389, gli elementi di autenticazione devono consentire di associare l’operazione a un importo e a un beneficiario specifici. L’utente deve conoscere queste informazioni e il codice di autenticazione deve risultare invalidato se l’importo o il beneficiario vengono modificati[5].
Un’autenticazione corretta dell’identità del cliente non dimostra, da sola, che egli abbia autorizzato un determinato pagamento.
La distinzione è rilevante per l’EUDI Wallet. Per utilizzarlo nella SCA, il PSP deve poter verificare che la procedura soddisfi i requisiti della normativa sui pagamenti e, quando necessario, che l’autenticazione sia collegata ai dati dell’operazione.
Il wallet può svolgere un ruolo nel processo autorizzativo senza sostituire necessariamente gli strumenti e le infrastrutture attraverso cui il pagamento viene eseguito.
Dall’Architecture and Reference Framework a SCARLET: che cosa manca agli standard tecnici
TS12 e SCA Attestation: come un EUDI Wallet può autenticare un pagamento
Il lavoro tecnico europeo ha già definito un modello per utilizzare l’EUDI Wallet nella Strong Customer Authentication.
La specifica TS12, Specification of Strong Customer Authentication (SCA) Implementation with the Wallet, nella versione 1.0.1 del 30 gennaio 2026, descrive le strutture informative e le regole di elaborazione necessarie per supportare l’autenticazione secondo la PSD2[6].
Il modello utilizza un particolare tipo di attestazione, denominata SCA Attestation, rilasciata al wallet dal prestatore di servizi di pagamento.
L’attestazione permette di collegare crittograficamente il wallet a un determinato cliente e, quando previsto, a un conto di pagamento o a una carta gestita dal PSP.
Il processo può essere descritto attraverso due momenti.
- Nel primo, il PSP associa in modo sicuro il cliente e il suo wallet, verificando gli elementi necessari e rilasciando la SCA Attestation.
- Nel secondo, quando il cliente deve autenticarsi, il wallet presenta l’attestazione secondo la procedura prevista e produce una risposta crittograficamente verificabile.
Per i pagamenti soggetti a collegamento dinamico (ossia quelli a distanza, come nei contesi dell’e-Commerce), la richiesta comprende anche i dati dell’operazione. L’utente deve poterli visualizzare prima di confermare, mentre la risposta deve consentire di verificare l’associazione fra l’azione compiuta e la transazione.
La TS12 definisce, tra gli altri elementi, l’utilizzo di una prova crittografica denominata Key Binding JWT. Questa include riferimenti ai metodi di autenticazione impiegati e agli elementi necessari a collegare la presentazione ai dati della transazione.
La specifica contempla inoltre un identificativo univoco della presentazione, utilizzabile come codice di autenticazione nel modello descritto.
Tali meccanismi forniscono una base tecnica per soddisfare i requisiti della SCA. La loro effettiva conformità dipende dall’implementazione complessiva del processo, dalle verifiche svolte dal PSP e dalle condizioni operative adottate.
La TS12 precisa che le regole ulteriori per emittenti delle attestazioni e relying parties devono essere definite dai rulebook del settore finanziario.
È in questo spazio che si colloca SCARLET.
Due modelli di interazione: banca e soggetti terzi
La TS12 distingue due configurazioni operative.
La prima è denominata Issuer-requested flow. In questo scenario il wallet presenta la SCA Attestation al soggetto che l’ha emessa, generalmente la banca del cliente, oppure a un intermediario che agisce per suo conto.
Il modello può essere utilizzato quando il cliente accede al proprio conto o dispone un pagamento attraverso l’ambiente digitale della banca. Può anche intervenire dopo un reindirizzamento proveniente da un esercente o da un altro prestatore di servizi.
Dal punto di vista funzionale, il wallet assume un ruolo simile a quello di un autenticatore bancario (similmente a quanto avviene oggi con l’app della banca che, tramite un messaggio push, viene attivata nel momento in cui si rende necessario autorizzare la transazione di pagamento), pur utilizzando credenziali e protocolli previsti dall’ecosistema europeo.
La seconda configurazione è il Third-party-requested flow.
In questo caso la richiesta di presentazione proviene da un soggetto differente rispetto al PSP che ha emesso l’attestazione. Potrebbe trattarsi, per esempio, di un esercente oppure di un prestatore di servizi di disposizione di ordini di pagamento (PISP).
Il wallet interagisce direttamente con la terza parte, mentre le informazioni necessarie all’esecuzione dell’operazione devono raggiungere il PSP attraverso le infrastrutture di pagamento o di Open Banking applicabili.
Questa seconda configurazione introduce questioni ulteriori.
Il PSP che gestisce il conto deve poter riconoscere e verificare il risultato dell’autenticazione, pur non avendo necessariamente gestito direttamente l’interazione con il wallet.
Occorre stabilire quali attestazioni possano essere presentate a soggetti terzi, quali vincoli debbano essere rispettati e quali informazioni siano necessarie per consentire al PSP di effettuare i controlli previsti.
La TS12 contempla meccanismi tecnici utili, comprese le politiche di divulgazione associate alle attestazioni e la verifica delle richieste firmate. La configurazione delle relazioni tra gli operatori e le rispettive responsabilità rimane materia dei rulebook applicativi.
La possibilità di utilizzare il wallet per autenticare un pagamento presso un esercente rende particolarmente evidente l’utilità di regole condivise a livello europeo. Un PSP non potrebbe realisticamente concordare procedure proprietarie con ogni possibile esercente o intermediario dell’Unione.
Il Liability Framework: chi risponde se qualcosa va storto?
Le responsabilità del PSP previste dalla normativa sui pagamenti
Il riferimento alle responsabilità contenuto nella denominazione Scarlet merita un esame alla luce delle regole già vigenti.
La PSD2 stabilisce una disciplina specifica per le operazioni di pagamento non autorizzate.
L’articolo 72 attribuisce al PSP l’onere di dimostrare, in presenza di una contestazione dell’utente, che l’operazione sia stata autenticata, correttamente registrata e contabilizzata e che non sia stata compromessa da malfunzionamenti o altre carenze del servizio.
La stessa disposizione precisa che la mera registrazione dell’utilizzo di uno strumento di pagamento non costituisce necessariamente una prova sufficiente dell’autorizzazione dell’operazione da parte del pagatore.
L’articolo 73 disciplina invece il rimborso delle operazioni non autorizzate. Fatte salve le condizioni e le eccezioni previste, il PSP del pagatore è tenuto a rimborsare l’importo immediatamente e comunque entro la fine della giornata operativa successiva alla conoscenza o alla comunicazione dell’operazione.
Quando interviene un PISP, la direttiva contempla anche specifiche regole di responsabilità e di rivalsa fra il prestatore che gestisce il conto e il soggetto che ha avviato l’ordine di pagamento.
L’introduzione dell’EUDI Wallet non elimina queste disposizioni.
Se un cliente contesta un pagamento per il quale è stata impiegata una SCA Attestation, il PSP non può considerare automaticamente assolti i propri obblighi dimostrando semplicemente che il wallet ha prodotto una risposta.
Occorre verificare che l’autenticazione sia stata eseguita correttamente, che la prova ricevuta sia valida e che sussistano gli elementi richiesti per ricondurre l’operazione all’autorizzazione del pagatore.
Un Liability Framework contrattuale può disciplinare la ripartizione delle conseguenze economiche fra i partecipanti allo schema, ma non può, per questo solo fatto, modificare gli obblighi inderogabili che la normativa attribuisce al PSP nei confronti del cliente.
La ripartizione delle responsabilità tra i partecipanti allo schema
Il funzionamento della SCA attraverso l’EUDI Wallet coinvolge attività tecnicamente e organizzativamente distinte.
Il PSP può emettere la SCA Attestation, il wallet provider mette a disposizione la soluzione attraverso cui essa viene presentata e una relying party può richiederne l’utilizzo.
Un intermediario potrebbe gestire parte delle comunicazioni o delle verifiche e, se durante il processo si verifica un’anomalia, l’individuazione della responsabilità dipende dalla possibilità di ricostruire che cosa sia accaduto.
Si consideri un pagamento eseguito dopo la presentazione di una SCA Attestation. Il cliente lo contesta sostenendo di avere confermato un importo differente. La verifica dovrebbe consentire di stabilire quali dati siano stati trasmessi al wallet, quali informazioni siano state mostrate all’utente, quale prova crittografica sia stata prodotta e come sia stata convalidata dal soggetto che l’ha ricevuta.
Un ulteriore problema potrebbe riguardare la revoca o la scadenza dell’attestazione. In tal caso sarebbe necessario comprendere chi dovesse controllarne lo stato e se la verifica fosse stata effettivamente eseguita.
La TS12 prevede regole sulla validazione delle presentazioni e sulla registrazione nel wallet di determinate informazioni relative alle transazioni di autenticazione, comprese quelle non completate con successo.
Questa registrazione non risolve automaticamente le necessità probatorie del PSP, laddove la banca deve comunque poter disporre delle evidenze necessarie a dimostrare le attività svolte nell’ambito delle proprie responsabilità, anche quando una parte del processo viene eseguita da altri operatori.
La conservazione di tali evidenze deve essere coerente con gli obblighi normativi applicabili, con le finalità probatorie e con i principi di protezione dei dati personali. Non è possibile dedurre dalle sole specifiche TS12 un obbligo generalizzato di conservare integralmente ogni contenuto scambiato con il wallet.
Il futuro rulebook SCARLET potrebbe disciplinare aspetti quali le verifiche richieste ai partecipanti, le procedure di contestazione, la gestione delle anomalie e gli eventuali meccanismi di rivalsa contrattuale. Sono ambiti coerenti con l’obiettivo dichiarato dell’EPC, ancorché il comunicato del 19 ottobre non consenta ancora di attribuire al progetto regole specifiche su ciascuno di essi.
L’efficacia del Liability Framework dipenderà dalla capacità di collegare le responsabilità contrattuali alle attività che ogni partecipante può effettivamente controllare e documentare.
Banche, wallet provider e intermediari: quale modello operativo si prospetta?
La banca come emittente di attestazioni e parte facente affidamento
L’EUDI Wallet introduce per le banche una possibile duplicità di ruoli.
Come emittente, una banca può rilasciare attestazioni elettroniche relative a informazioni che conosce e che è legittimata a certificare. Nel modello della TS12, il PSP emette una SCA Attestation per associare il cliente e il wallet a una determinata relazione di pagamento.
Come relying party, la banca può richiedere e verificare dati o attestazioni presenti nel wallet per consentire al cliente di utilizzare un servizio.
I due ruoli comportano attività differenti.
- L’emissione richiede di verificare i presupposti per il rilascio, gestire la validità dell’attestazione e predisporre le procedure necessarie per la sua eventuale revoca.
- L’accettazione richiede invece di formulare correttamente la richiesta, verificare il soggetto che ha emesso l’attestazione, controllarne la validità e utilizzare il risultato secondo le regole applicabili al servizio.
Per una banca che intenda utilizzare il wallet in entrambi i ruoli, l’investimento può essere distribuito su processi differenti.
Le componenti necessarie a ricevere attestazioni potrebbero servire per l’identificazione dei clienti, l’onboarding digitale e determinati servizi di pagamento. L’emissione di credenziali può invece abilitare ulteriori servizi nei quali altre organizzazioni abbiano interesse a verificare informazioni bancarie.
Questa prospettiva non implica che le attestazioni impiegate per l’identificazione e quelle dedicate alla SCA siano intercambiabili. Infatti, la TS12 prevede caratteristiche specifiche per le SCA Attestation, proprio perché devono essere utilizzate in processi soggetti alla disciplina dei pagamenti.
Il possibile ruolo degli intermediari e degli aggregatori
L’ecosistema EUDI Wallet non richiede necessariamente che ogni banca sviluppi e gestisca autonomamente tutte le componenti tecniche.
Un intermediario potrebbe fornire servizi di connessione, predisposizione delle richieste, verifica delle attestazioni e gestione delle interazioni con i wallet.
La possibilità di ricorrere a intermediari trova un fondamento espresso nell’articolo 5 ter, paragrafo 10, del regolamento eIDAS.
La disposizione stabilisce che gli intermediari che operano per conto delle relying parties siano a loro volta considerati relying parties e non conservino dati relativi al contenuto della transazione. Si tratta di una prescrizione che influisce sulla progettazione dei servizi di aggregazione. L’intermediario deve poter svolgere le funzioni affidategli rispettando le limitazioni previste per il trattamento delle informazioni.
La disciplina europea contempla inoltre la registrazione delle relying parties e gli strumenti attraverso cui queste possono identificarsi nei confronti del wallet.
Il regolamento di esecuzione (UE) 2025/848 definisce i requisiti di registrazione e i certificati destinati alle parti facenti affidamento[7].
Il regolamento di esecuzione (UE) 2025/848
Il regolamento di esecuzione (UE) 2025/848: la registrazione delle relying parties
Adottato dalla Commissione europea il 6 maggio 2025, il regolamento disciplina la registrazione delle organizzazioni che intendono utilizzare l’EUDI Wallet per erogare servizi digitali, denominate wallet-relying parties.
Gli Stati membri devono istituire registri nazionali, accessibili pubblicamente anche attraverso interfacce informatiche (API), nei quali sono riportate le informazioni identificative delle relying parties, le finalità dichiarate di utilizzo del wallet e i dati che intendono richiedere agli utenti.
Il regolamento disciplina, inoltre, i certificati di accesso (Wallet Relying Party Access Certificates), che consentono alle relying parties registrate di autenticarsi nei confronti dei wallet, e i certificati di registrazione (Wallet Relying Party Registration Certificates), destinati a rappresentare gli utilizzi dichiarati e gli attributi richiedibili.
Fonte normativa: Regolamento (UE) 2025/848, testo consolidato.
Il successivo regolamento di esecuzione (UE) 2026/1730 ha aggiornato tali disposizioni, introducendo anche elementi relativi all’associazione fra un intermediario e la relying party per conto della quale opera[8].
L’architettura normativa consente di organizzare modelli di intermediazione, ma non elimina le responsabilità proprie degli operatori che utilizzano le attestazioni. Pertanto, una banca che si affidi a un gateway esterno deve poter distinguere le verifiche eseguite dall’intermediario, quelle che rimangono di propria competenza e le informazioni necessarie per documentare il corretto funzionamento del processo.
A questa disciplina si aggiungeranno, per l’utilizzo del wallet nella SCA, le regole contrattuali eventualmente introdotte da SCARLET. La registrazione come relying party, la partecipazione a uno schema EPC e l’adesione a un servizio di aggregazione sono qualificazioni differenti, che potranno coesistere ma non devono essere confuse.
Il regolamento di esecuzione (UE) 2026/1730
Il regolamento di esecuzione (UE) 2026/1730: intermediari e nuove specifiche tecniche
Adottato dalla Commissione europea il 15 luglio 2026, il regolamento modifica il precedente regolamento (UE) 2025/848, aggiornando le regole di registrazione delle relying parties e i requisiti tecnici dei relativi certificati.
Una modifica particolarmente significativa riguarda gli intermediari che operano per conto delle relying parties. Il regolamento introduce, tra le informazioni di registrazione, il riferimento all’associazione fra l’intermediario titolare del certificato di accesso e la relying party per conto della quale agisce.
Viene inoltre chiarito che le informazioni relative alle qualificazioni dichiarate dalle relying parties devono essere raccolte per finalità di trasparenza, senza introdurre una procedura di autorizzazione preventiva attraverso la registrazione.
Sul piano tecnico, il provvedimento aggiorna i riferimenti normativi applicabili a due categorie di certificati, introducendo specifiche ETSI dedicate.
ETSI TS 119 411-8 V1.1.1 (2025-10) disciplina le politiche di certificazione e i requisiti di sicurezza per i prestatori di servizi fiduciari che rilasciano i Wallet-Relying Party Access Certificates (WRPAC), utilizzati per autenticare le relying parties nelle interazioni con gli EUDI Wallet[9].
ETSI TS 119 475 V1.2.1 (2026-03) definisce i requisiti e i profili tecnici dei Wallet-Relying Party Registration Certificates (WRPRC), attraverso i quali vengono rappresentati gli attributi, le qualificazioni e le finalità di utilizzo dichiarate dalle relying parties, consentendo ai wallet di verificare la coerenza delle richieste di dati con quanto registrato[10].
Le nuove specifiche sostituiscono il precedente riferimento generale alla norma ETSI EN 319 411-1, introducendo requisiti dedicati all’ecosistema EUDI Wallet e favorendo l’interoperabilità dei certificati fra gli Stati membri.
Fonte normativa: Regolamento (UE) 2026/1730, allegati II e III.
Il caso italiano: il framework EUDIW Italia annunciato da BANCOMAT
Il 19 ottobre 2026, lo stesso giorno dell’annuncio di SCARLET, BANCOMAT ha presentato durante una Community Session la proposta di un framework EUDIW Italia, con l’obiettivo di promuovere un’infrastruttura condivisa per l’utilizzo dell’identità digitale europea.
L’iniziativa, approfondita in un articolo pubblicato su PagamentiDigitali il 19 ottobre 2026 a firma di chi scrive, prevede la costituzione di un gruppo di lavoro per definire un modello di intermediazione fra banche, emittenti di attestazioni elettroniche e relying parties[11].
BANCOMAT intende valorizzare le proprie competenze nella gestione dei circuiti di pagamento, proponendo un’architettura basata su due componenti principali.
Il Wallet Gateway Issuer supporterebbe l’emissione delle credenziali digitali, mentre il Wallet Gateway Verifier consentirebbe alle relying parties di richiedere e verificare le attestazioni presentate attraverso i wallet.
La proposta contempla anche una Trust Layer, destinata a sostenere le verifiche di fiducia, e un modello economico che potrebbe remunerare gli emittenti delle credenziali e l’intermediario attraverso commissioni corrisposte dai soggetti che utilizzano i servizi.
Scarlet e il framework EUDIW Italia presentano una possibile area di convergenza, ma hanno perimetri differenti.
Scarlet è progettato per definire regole comuni europee di accettazione dell’EUDI Wallet nella Strong Customer Authentication, comprese le condizioni contrattuali e la ripartizione delle responsabilità.
L’iniziativa BANCOMAT riguarda un’infrastruttura di intermediazione con un campo applicativo più ampio, che comprende l’identificazione bancaria, le attestazioni relative ai rapporti finanziari, l’autenticazione e possibili credenziali di pagamento.
La SCA potrebbe costituire uno dei casi d’uso del framework italiano.
Se il progetto BANCOMAT dovesse supportare l’autenticazione dei pagamenti attraverso l’EUDI Wallet, le sue componenti tecniche e contrattuali dovrebbero confrontarsi con le regole che Scarlet intende definire a livello europeo.
La relazione potrebbe assumere configurazioni differenti, a seconda delle condizioni di adesione allo schema EPC e del ruolo che quest’ultimo attribuirà agli intermediari.
Il comunicato EPC non documenta accordi o forme di coordinamento già definite con BANCOMAT. Sarebbe prematuro presentare le due iniziative come parti di un’unica architettura. La contemporaneità degli annunci consente però di individuare un tema industriale comune: evitare che lo sviluppo di soluzioni nazionali per l’EUDI Wallet produca nuovi perimetri chiusi, anziché infrastrutture capaci di interagire con l’intero ecosistema europeo.
Anche il rapporto fra le regole economiche dei due framework dovrà essere valutato. L’eventuale remunerazione dei servizi di intermediazione e di verifica delle credenziali richiede di identificare con precisione le prestazioni fornite, evitando sovrapposizioni fra corrispettivi applicati per attività differenti.
SCARLET tra PSD2 e PSR: le scelte di investimento delle banche
Due versioni per accompagnare il cambiamento normativo
L’EPC prevede uno sviluppo progressivo dello schema Scarlet.
La versione 1.0 sarà costruita tenendo conto della PSD2, degli attuali Regulatory Technical Standards (RTS) sulla SCA e delle altre disposizioni applicabili.
La versione 1.1 dovrà invece estendere il framework al futuro Payment Services Regulation (PSR), destinato a modificare il quadro normativo europeo dei servizi di pagamento.
La revisione della PSD2 è stata avviata dalla Commissione nel giugno 2023 attraverso due proposte legislative: una nuova direttiva, comunemente denominata PSD3, e un regolamento direttamente applicabile, il PSR.
Il 27 novembre 2025, Parlamento europeo e Consiglio hanno raggiunto un accordo politico sulla revisione. Alla data dell’annuncio SCARLET, il completamento dell’iter legislativo e la definizione delle relative scadenze applicative restano elementi da considerare nella pianificazione degli investimenti[12].
L’EPC indica per la versione SCARLET 1.1 l’obiettivo di consentire l’adeguamento dei partecipanti al nuovo quadro PSR nel periodo 2028-2029, preservando gli investimenti effettuati per la prima versione.
La continuità fra SCARLET1.0 e 1.1 costituisce dunque un obiettivo progettuale.
Non è ancora possibile stabilire quali componenti tecniche, contrattuali o certificative potranno essere mantenute senza modifiche. Per banche e PSP questo aspetto incide sulle strategie di investimento.
Un’infrastruttura sviluppata per soddisfare i requisiti attuali dovrebbe essere progettata tenendo conto dell’evoluzione regolamentare già prevedibile, limitando per quanto possibile la necessità di realizzare nuovamente componenti che svolgono le medesime funzioni.
Interoperabilità, costi di integrazione e sostenibilità economica
L’adozione di uno schema comune può ridurre alcune categorie di costo.
Una banca potrebbe evitare di definire e mantenere molteplici accordi bilaterali con diversi operatori, utilizzare procedure di integrazione condivise e beneficiare di specifiche comuni per le verifiche tecniche.
La standardizzazione può facilitare anche le attività di certificazione, quando i relativi requisiti siano definiti in modo da poter essere riutilizzati fra partecipanti differenti.
Questi benefici rimangono tuttavia condizionati alle modalità concrete di attuazione dello schema. SCARLET potrebbe richiedere attività di adesione, sviluppo, test, certificazione e gestione continuativa. Il comunicato EPC non specifica ancora eventuali quote di partecipazione, commissioni o condizioni economiche applicabili.
La valutazione della convenienza per un PSP richiederà di confrontare il costo complessivo di adesione e utilizzo con quello di soluzioni sviluppate direttamente o acquistate da intermediari specializzati. L’analisi deve inoltre distinguere i servizi di autenticazione dai servizi di verifica delle attestazioni utilizzate per altre finalità.
- Nel primo caso, l’investimento può essere considerato in relazione agli obblighi regolamentari, alla sicurezza e alla continuità dei processi di pagamento.
- Nel secondo, l’impiego delle credenziali potrebbe generare benefici economici specifici, per esempio riducendo alcune attività documentali o consentendo nuovi servizi basati sulla verifica di informazioni affidabili.
Le stesse infrastrutture possono concorrere a entrambi gli ambiti, ma la misurazione dei benefici deve rimanere distinta e l’eventuale ricorso a intermediari aggiunge un’ulteriore variabile.
Un aggregatore può ridurre i costi di integrazione sostenuti dal singolo PSP, ma il vantaggio dipende dalle tariffe richieste, dalle funzionalità effettivamente fornite, dalla possibilità di cambiare operatore e dal grado di interoperabilità con altre soluzioni.
Un sistema progettato per evitare la frammentazione dovrebbe limitare il rischio che la semplificazione tecnica si traduca in dipendenze commerciali difficili da superare. Lo sviluppo di SCARLET offre la possibilità di introdurre criteri comuni, ma la sostenibilità economica potrà essere valutata soltanto quando saranno disponibili informazioni sufficienti sui costi, sui volumi attesi e sugli obblighi effettivi dei partecipanti.
La tabella di marcia: il rulebook arriverà in tempo per l’obbligo europeo?
Il calendario pubblicato dall’EPC prevede una consultazione aperta nell’estate 2027 e la pubblicazione della prima versione del rulebook Scarlet nel dicembre dello stesso anno. L’entrata in operatività dello schema è prevista dopo un periodo dedicato allo sviluppo delle soluzioni, ai test, all’onboarding dei partecipanti e alla certificazione.
Nel comunicato l’EPC indica l’obiettivo di assicurare, attraverso questa sequenza, anche l’adeguamento dei PSP alle scadenze del quadro europeo sull’identità digitale.
La pianificazione presenta tuttavia una questione temporale. L’articolo 5 septies, paragrafo 2, del regolamento eIDAS stabilisce, nelle condizioni previste dalla disposizione, l’obbligo di accettazione degli EUDI Wallet entro il termine ordinario del 24 dicembre 2027.
La pubblicazione del rulebook SCARLET 1.0 è prevista per il medesimo mese.
Se lo schema dovesse diventare disponibile soltanto dopo un ulteriore periodo di implementazione e certificazione, i PSP non potrebbero affidarsi alla sua versione definitiva per completare preventivamente tutte le attività necessarie alla scadenza normativa.
L’annuncio non chiarisce ancora come questo possibile disallineamento sarà gestito.
È possibile che il lavoro tecnico anticipi la pubblicazione definitiva del rulebook, consentendo ai partecipanti di sviluppare e sperimentare le soluzioni sulla base di specifiche progressivamente consolidate. Tale possibilità, tuttavia, resta da verificare attraverso il futuro programma operativo dell’EPC.
Occorre anche distinguere due livelli di conformità.
- Il primo riguarda il rispetto dell’obbligo eIDAS, che deriva direttamente dalla normativa applicabile alle relying parties e non dipende dall’adesione a Scarlet.
- Il secondo concerne il rispetto delle regole dello schema EPC, una volta che queste saranno state definite e rese operative.
L’adesione a SCARLET potrebbe rappresentare un percorso di standardizzazione per l’adempimento regolamentare, ma il comunicato non stabilisce che costituisca l’unica modalità consentita per accettare l’EUDI Wallet.
Per le banche il problema consiste quindi nel pianificare gli investimenti senza attendere necessariamente la conclusione dell’intero processo di standardizzazione.
Le specifiche tecniche dell’ecosistema EUDI, comprese quelle dedicate alla SCA, forniscono già una base di lavoro. Le future disposizioni SCARLET dovranno essere considerate nella progettazione, soprattutto per gli aspetti che riguardano l’interoperabilità e le responsabilità contrattuali.
Conclusione: una regola comune può evitare nuovi confini nell’autenticazione europea?
L’iniziativa SCARLET nasce dall’esigenza di rendere utilizzabile l’EUDI Wallet nei servizi di pagamento secondo condizioni condivise fra operatori differenti.
Le specifiche europee hanno già delineato meccanismi per l’emissione e la presentazione delle SCA Attestation, comprese le funzionalità necessarie a collegare crittograficamente l’autenticazione ai dati delle operazioni. Il lavoro dell’EPC si concentra sulla dimensione settoriale: quali soggetti possano partecipare allo schema, quali obblighi assumano, come debbano operare e secondo quali regole siano gestite le rispettive responsabilità.
Il Liability Framework sarà uno degli elementi attraverso cui valutare la capacità dello schema di supportare l’adozione del wallet. Nel settore dei pagamenti la disponibilità di una prova crittografica non esaurisce gli obblighi del PSP. La prova deve essere verificata, correttamente associata all’operazione e utilizzabile quando occorre dimostrare il rispetto delle regole applicabili.
L’interazione con wallet provider e intermediari introduce nuovi rapporti contrattuali. La loro disciplina dovrà preservare la possibilità di attribuire le responsabilità in modo coerente con le attività svolte e con gli obblighi verso gli utenti.
Il progetto EUDIW Italia di BANCOMAT mostra, sul piano nazionale, come possano emergere infrastrutture di aggregazione e modelli economici per supportare l’emissione e la verifica delle credenziali.
La compatibilità di queste iniziative con un futuro schema comune europeo dipenderà dalle regole che saranno adottate e dalla possibilità di evitare sovrapposizioni o dipendenze incompatibili con l’interoperabilità.
Per i PSP, le scadenze regolamentari rendono necessaria una pianificazione che tenga conto degli standard già disponibili e dell’evoluzione ancora in corso.
Il risultato di SCARLETdovrà essere valutato anche rispetto a questa esigenza: consentire alle banche di investire oggi in soluzioni capaci di funzionare con wallet differenti e di adattarsi al futuro quadro normativo, senza dover ricostruire le proprie infrastrutture a ogni nuova versione dello schema.
Note
[1] European Payments Council, comunicato EPC267-26, “EPC launches SCARLET initiative to support consistent use of EU Digital Identity Wallets in payment authentication”, 19 ottobre 2026. Fonte ufficiale online
[2] Regolamento (UE) 2024/1183, che modifica il regolamento (UE) n. 910/2014 (eIDAS); in particolare articoli 5 bis, 5 ter e 5 septies del testo modificato (https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32024R1183 ).
[3] Regolamento di esecuzione (UE) 2024/2982 della Commissione, del 28 novembre 2024, relativo a protocolli e interfacce del quadro europeo di identità digitale (https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32024R2982 ). Regolamento di esecuzione (UE) 2024/2981 della Commissione, del 28 novembre 2024, relativo alla certificazione dei portafogli europei di identità digitale (https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32024R2981 ).
[4] Direttiva (UE) 2015/2366 (PSD2), in particolare articoli 72, 73 e 97. Fonte ufficiale online
[5] Regolamento delegato (UE) 2018/389, norme tecniche di regolamentazione per la SCA e la comunicazione sicura; articoli 4 e 5 (https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32015L2366 ).
[6] Commissione europea, “Specification of Strong Customer Authentication (SCA) Implementation with the Wallet”, TS12, versione 1.0.1, 30 gennaio 2026 (https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts12-electronic-payments-SCA-implementation-with-wallet.md ).
[7] Regolamento di esecuzione (UE) 2025/848, registrazione delle parti facenti affidamento sul portafoglio; testo consolidato all’11 agosto 2026 (https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:02025R0848-20260811 ).
[8] Regolamento di esecuzione (UE) 2026/1730 della Commissione, del 15 luglio 2026, recante modifica del regolamento (UE) 2025/848 (https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32026R1730 ).
[9] ETSI, “Policy and security requirements for Trust Service Providers issuing certificates; Part 8: Access Certificate Policy for EUDI Wallet Relying Parties”, ETSI TS 119 411-8 V1.1.1 (2025-10). Fonte ufficiale online
[10] ETSI, “Relying party attributes supporting EUDI Wallet user’s authorization decisions”, ETSI TS 119 475 V1.2.1 – 2026-03 (https://www.etsi.org/deliver/etsi_ts/119400_119499/119475/01.02.01_60/ts_119475v010201p.pdf ).
[11] Roberto Garavaglia, “BANCOMAT punta sul framework EUDIW Italia: identità digitale, pagamenti e nuovi modelli di ricavo”, PagamentiDigitali, 19 ottobre 2026.
[12] Commissione europea, DG FISMA, “Payment services”, documentazione sul processo di revisione PSD2/PSD3/PSR e sull’accordo politico del 27 novembre 2025.
Partecipa alla community