La diffusione di smart contract, infrastrutture DLT e servizi di pagamento automatizzati rende necessario separare fenomeni spesso descritti con la medesima parola: programmabilità.
La distinzione decisiva non riguarda soltanto la tecnologia utilizzata, ma soprattutto il punto nel quale opera la regola: la moneta, l’ordine di pagamento, il workflow applicativo o l’infrastruttura di regolamento.
Indice degli argomenti
1. I pagamenti condizionali come categoria generale
I pagamenti condizionali costituiscono la categoria generale delle operazioni nelle quali l’avvio, l’esecuzione, il regolamento o il rilascio dei fondi dipendono dal verificarsi di una o più condizioni predefinite. L’elemento caratterizzante non è una particolare tecnologia, bensì il collegamento funzionale tra un evento, una verifica o una prestazione e il trasferimento monetario che ne consegue.[1]
Le condizioni possono avere natura temporale, contrattuale, documentale o fattuale. Possono consistere, ad esempio, nel raggiungimento di una scadenza, nella consegna di un bene, nel completamento di una milestone, nell’accettazione di una prestazione, nella produzione di un documento o nel superamento di una soglia. La condizione può essere verificata dalle parti, da un intermediario, da una piattaforma tecnologica oppure da una fonte esterna di dati.
La condizione può riguardare la moneta oppure il processo di pagamento. Da questa alternativa discendono due fattispecie distinte. La moneta programmabile incorpora la regola nello strumento monetario; il pagamento programmabile applica invece la regola a una specifica disposizione o sequenza operativa, lasciando invariata la natura della moneta trasferita.
Nella terminologia istituzionale dell’Eurosistema, l’espressione “pagamenti condizionali” ha progressivamente sostituito “pagamenti programmabili”, così da evitare la sovrapposizione con la moneta programmabile.
Nel presente articolo (la prima parte di una mini serie dedicata a questi temi specifici, a firma dello stesso autore), tuttavia, il termine pagamento programmabile è utilizzato per indicare la forma automatizzata del pagamento condizionale: la verifica della condizione e l’attivazione della disposizione sono affidate, integralmente o parzialmente, a regole eseguibili automaticamente.
2. Moneta programmabile: vincoli incorporati nello strumento
La moneta programmabile è uno strumento monetario nel quale sono incorporate regole relative al suo utilizzo. I vincoli possono riguardare le categorie di beni o servizi acquistabili, i soggetti legittimati a riceverla, il territorio di impiego, l’importo spendibile o il periodo di validità. La condizione non governa soltanto una singola disposizione: accompagna lo strumento e può continuare a produrre effetti nei trasferimenti successivi.
Un possibile terreno applicativo, da esaminare con cautela e ferma la compatibilità con la disciplina dell’emissione e dei servizi di pagamento, è rappresentato dalla moneta elettronica tokenizzata. Il regolamento MiCAR definisce l’electronic money token (EMT) come un crypto-asset che mira a mantenere un valore stabile facendo riferimento a una valuta ufficiale; qualifica inoltre gli EMT come moneta elettronica e riconosce al detentore un diritto di rimborso al valore nominale.[2]
L’EMT è trasferibile e conservabile elettronicamente mediante DLT o tecnologia analoga. Il MiCAR definisce la DLT come la tecnologia che consente il funzionamento di registri distribuiti e descrive il registro distribuito come un archivio di informazioni condiviso e sincronizzato tra nodi attraverso un meccanismo di consenso.[3]
In un’architettura tokenizzata, una medesima unità potrebbe attraversare più soggetti di una filiera e conservare regole condivise di utilizzo. La programmabilità non si esaurirebbe quindi nel rapporto bilaterale tra un pagatore e un beneficiario, ma potrebbe disciplinare la circolazione del valore lungo una sequenza di trasferimenti fra produttore, fornitore, distributore e altri partecipanti.
3. Fungibilità universale e fungibilità funzionale
L’incorporazione di vincoli può incidere sulla fungibilità, perché unità denominate nello stesso valore nominale possono offrire possibilità di impiego differenti. La criticità, tuttavia, non deve essere considerata in termini assoluti. Occorre distinguere la fungibilità universale, propria di uno strumento accettabile senza restrizioni nel mercato generale, dalla fungibilità funzionale o locale, che può realizzarsi all’interno di un ecosistema i cui partecipanti condividano le medesime regole.
Se tutti i soggetti di una filiera concordano di utilizzare lo stesso EMT per uno scopo comune e accettano vincoli identici, le unità possono risultare pienamente intercambiabili all’interno del circuito. In tale ambito la limitazione della spendibilità non è necessariamente percepita come un difetto, ma può costituire la caratteristica che rende lo strumento funzionale al processo economico condiviso.
Ciò non elimina la differenza rispetto alla moneta liberamente spendibile. Al di fuori dell’ecosistema, lo strumento può essere accettato da un numero inferiore di soggetti o essere utilizzabile per finalità più ristrette. È dunque più rigoroso affermare che la condivisione dei vincoli attenua o relativizza il problema della fungibilità, senza trasformare automaticamente una fungibilità circoscritta in fungibilità generale.
L’analisi deve inoltre distinguere i vincoli uniformi dell’intero circuito dalle regole differenziate applicate a singole unità o classi di token. Nel primo caso può conservarsi una sostanziale intercambiabilità tra gli utilizzatori ammessi; nel secondo, la frammentazione delle condizioni può produrre categorie monetarie economicamente non equivalenti.
4. I pagamenti programmabili sono tecnologicamente neutrali
Il pagamento programmabile è una disposizione la cui esecuzione viene attivata automaticamente al verificarsi di condizioni predeterminate. La regola opera sull’ordine, sull’autorizzazione o sul workflow applicativo; una volta effettuato il trasferimento, il beneficiario riceve moneta che non conserva i vincoli della precedente operazione.
La programmabilità del pagamento non dipende intrinsecamente dall’infrastruttura di regolamento. Può essere realizzata mediante fondi detenuti presso una banca commerciale, moneta elettronica, moneta tokenizzata o moneta di banca centrale. Blockchain e smart contract possono ampliare il livello di automazione, ma non costituiscono requisiti definitori.
4.1 Forme tradizionali di programmabilità temporale
Addebito diretto SEPA (SDD)
Nel SEPA Direct Debit (SDD) il beneficiario-creditore presenta la collection sulla base del mandato rilasciato dal debitore e secondo la scadenza concordata nel rapporto sottostante. Il beneficiario governa operativamente la presentazione dell’incasso, ma non può essere descritto come titolare di un potere illimitato di determinare unilateralmente la data: la due date deve essere coerente con il contratto o con le condizioni concordate tra le parti.[4]
Nello schema ordinario, due date, data di addebito e data di settlement coincidono, salva l’applicazione delle regole previste per giorni non operativi, ritardi, indisponibilità dei fondi o ulteriori controlli. La programmabilità riguarda dunque la collection e il relativo calendario, mentre il valore incassato è normalmente costituito da moneta di banca commerciale.[5]
L’SDD costituisce un esempio utile perché separa chiaramente il titolo autorizzativo — il mandato — dalla presentazione della collection e dal successivo regolamento. La condizione temporale è incorporata nel processo, non nelle unità monetarie accreditate al beneficiario.
Bonifico SEPA con data futura (SCT)
Nel SEPA Credit Transfer (SCT) programmato è il pagatore a richiedere che l’esecuzione inizi in una data futura. La PSD2 consente all’utente e al prestatore di concordare che l’esecuzione dell’ordine inizi in un giorno specifico, al termine di un periodo determinato o quando il pagatore abbia messo i fondi a disposizione del prestatore.[6]
Il rulebook SCT traduce tale possibilità nella Requested Execution Date: l’ordinante può trasmettere anticipatamente l’istruzione e indicare la data futura dalla quale deve iniziare il ciclo di esecuzione. Anche in questo caso la programmazione incide sull’ordine e non modifica la natura dei fondi trasferiti.[7]
4.2 La Request-to-Pay come orchestrazione del processo
Lo schema SEPA Request-to-Pay (SRTP) amplia il livello di orchestrazione, ma non costituisce di per sé un pagamento né uno strumento di pagamento. È una funzionalità di messaggistica mediante la quale il beneficiario richiede al pagatore di avviare un pagamento; l’accettazione può essere seguita da un trasferimento immediato o futuro, mentre il processo di pagamento rimane esterno allo schema SRTP.[8]
Lo SRTP opera quindi nel workflow precedente alla disposizione. Può trasportare le informazioni commerciali, coordinare richiesta e risposta e predisporre il successivo pagamento. Diventa una componente di un pagamento programmabile quando è integrato con regole che, dopo l’accettazione o al verificarsi di ulteriori condizioni, determinano automaticamente l’inoltro dell’ordine.
4.3 Programmabilità temporale e programmabilità condizionale
Questa neutralità emerge già da strumenti tradizionali nei quali la disposizione viene eseguita in un momento o secondo una sequenza stabiliti anticipatamente. Tali fattispecie rappresentano forme di programmabilità temporale o seriale, meno complesse dei pagamenti subordinati a una consegna o a una milestone, ma sufficienti a dimostrare che la programmabilità precede la diffusione della DLT.
5. Rischi comuni alla moneta e ai pagamenti programmabili
5.1 Errori di esecuzione, responsabilità e contestazioni
L’affidabilità dei dati, la correttezza del codice, la responsabilità per l’errata esecuzione, la gestione delle contestazioni, la reversibilità delle operazioni, la sicurezza informatica e la ripartizione dei ruoli non riguardano soltanto i pagamenti programmabili. Le stesse problematiche si presentano anche quando la logica condizionale è incorporata nella moneta.[9]
Ciò che cambia è il punto nel quale il rischio si manifesta. Nel pagamento programmabile l’errore incide, in prima battuta, sull’avvio o sull’esecuzione di una specifica disposizione. Nella moneta programmabile può alterare direttamente le possibilità di utilizzo dello strumento e propagarsi nei trasferimenti successivi.
5.2 Affidabilità dei dati e ruolo degli oracoli
Particolare rilievo assume l’oracolo, ossia il componente che attesta alla rete il verificarsi di eventi esterni: la consegna di una merce, il raggiungimento di un prezzo, l’esito di una verifica documentale o un’altra circostanza non osservabile direttamente dal registro. Un dato inesatto o manipolato può attivare una disposizione non dovuta oppure applicare erroneamente un vincolo alla moneta.[10]
La DLT non rende automaticamente affidabile l’informazione ricevuta dall’esterno. Essa può rendere verificabile e condivisa l’esecuzione della regola dopo l’acquisizione del dato, ma la qualità dell’input continua a dipendere dalla fonte, dalla governance dell’oracolo, dai meccanismi di controllo e dall’eventuale presenza di fonti alternative.
5.3 Governance tecnica e operativa
La disciplina europea delle infrastrutture DLT riconosce espressamente la necessità di regole sul funzionamento del registro, sulla partecipazione dei nodi validatori, sulla gestione dei conflitti e dei rischi, nonché di presidi informatici e cyber capaci di assicurare continuità, disponibilità, affidabilità e sicurezza, compresa l’affidabilità degli smart contract impiegati.[11]
6. Settlement: velocità e integrazione sono concetti diversi
6.1 Verifica della condizione, esecuzione e regolamento
La differenza tra moneta programmabile e pagamento programmabile non può essere ridotta ai tempi di settlement. Un pagamento su infrastruttura tradizionale può essere regolato secondo cicli differiti oppure in pochi secondi; una transazione su DLT può raggiungere la finalità con tempi variabili in funzione del consenso, della configurazione dei validatori e delle regole del protocollo.
Occorre distinguere almeno tre momenti: la verifica della condizione, l’inizio dell’esecuzione dell’ordine e il regolamento finale. Una condizione può maturare dopo settimane, mentre il trasferimento successivo può essere istantaneo; viceversa, una regola può attivarsi immediatamente ma il settlement seguire un ciclo più lungo.
6.2 Integrazione, atomicità e finalità
Il vero profilo distintivo è il grado di integrazione tra condizione, trasferimento dell’attività monetaria e finalità del regolamento. Quando regola e asset risiedono nello stesso ambiente, l’operazione può essere configurata in modo unitario e, in determinate architetture, atomico. Quando la regola opera su una piattaforma e la moneta viene trasferita su un sistema esterno, il processo dipende dal raccordo fra i due ambienti.[12]
Nel modello ibrido, lo smart contract non può garantire da solo la capienza del conto, l’accettazione dell’ordine, il superamento dei controlli del PSP o il completamento del settlement. L’equivalenza con una transazione interamente on-chain può aumentare mediante prenotazione o segregazione dei fondi, infrastrutture istantanee, conferme affidabili e meccanismi di sincronizzazione; non deriva però dal solo fatto che il trigger sia registrato su DLT.
La finalità del regolamento indica il momento dal quale il trasferimento è incondizionato, opponibile e irrevocabile secondo le regole applicabili. Essa non coincide necessariamente con il momento nel quale l’utente impartisce l’ordine né con quello nel quale l’interfaccia mostra una conferma preliminare.[13]
7. Smart contract e Payment Initiation: il modello ibrido
7.1 Lo smart contract come motore della condizione
Un pagamento programmabile può essere orchestrato anche da uno smart contract. In uno scenario ibrido, un oracolo comunica il verificarsi dell’evento; lo smart contract applica la regola e, attraverso un’interfaccia, trasmette a un prestatore abilitato il comando necessario ad avviare una Payment Initiation. Il regolamento continua ad avvenire sul sistema di pagamento esterno e nella moneta prevista dal rapporto di conto.
7.2 Consenso, autenticazione e ruolo dei PSP
Lo smart contract non diviene per ciò solo un prestatore di servizi di pagamento. La PSD2 riconosce il diritto del pagatore di utilizzare un payment initiation service provider, ma richiede il consenso del pagatore e attribuisce al PISP specifici obblighi di identificazione e comunicazione sicura con il prestatore che gestisce il conto.[14]
L’automazione senza un nuovo intervento dell’utente è quindi difendibile soltanto quando esista a monte un consenso o mandato compatibile con la struttura dell’operazione e con le regole di autenticazione applicabili. In mancanza, lo smart contract potrebbe predisporre o richiedere l’ordine, ma non necessariamente determinarne il perfezionamento automatico.
Il quadro tecnico sulla strong customer authentication e sulle comunicazioni sicure impone presidi sulla generazione dei codici, sul collegamento dinamico a importo e beneficiario, sul monitoraggio delle transazioni, sulla protezione delle credenziali e sugli standard di comunicazione fra ASPSP e prestatori terzi. Per le operazioni ricorrenti sono inoltre previste regole specifiche sull’autenticazione della prima disposizione o della serie.[15]
7.3 Garanzie e limiti del modello ibrido
Questa architettura può offrire predeterminazione della regola, tracciabilità, auditabilità e automazione paragonabili, per alcuni profili, a quelle di un sistema tokenizzato. Al contempo, la programmabilità rimane circoscritta alla disposizione: i fondi accreditati al beneficiario non diventano moneta programmabile e conservano la fungibilità propria dell’attività monetaria utilizzata.
8. DLT, centralizzazione e modello di fiducia
8.1 Grado di decentralizzazione e resilienza
L’impiego di una DLT introduce la possibilità di distribuire registrazione, validazione e controllo tra più nodi. Il grado di distribuzione dipende tuttavia dalla configurazione concreta: una rete permissionless, una rete permissioned e una rete consortile presentano regole di accesso, meccanismi di consenso e assetti di governance differenti.
Una rete distribuita può ridurre la dipendenza da un singolo operatore e consentire al servizio di proseguire nonostante il malfunzionamento di alcuni nodi. Non è però corretto dedurre che ogni DLT elimini il single point of failure o sia necessariamente più sicura di un’infrastruttura centralizzata. Anche i sistemi tradizionali possono essere replicati e ridondati; una rete DLT può inoltre conservare componenti centrali, subire guasti correlati o dipendere da un unico gestore di certificati, oracoli, gateway o aggiornamenti.[16]
La sicurezza dipende dalla pluralità e indipendenza dei validatori, dal quorum, dalla separazione dei poteri, dalla gestione delle chiavi, dalla qualità del codice, dalla ridondanza e dalle procedure di emergenza. La DLT sposta e redistribuisce alcune forme di fiducia, ma non le elimina.
8.2 Sistemi centralizzati, distribuiti e ibridi
Nei sistemi centralizzati la fiducia è prevalentemente concentrata nel prestatore o nell’infrastruttura che verifica ed esegue l’ordine. Nei sistemi distribuiti è ripartita tra protocollo, validatori, governance, smart contract e oracoli. Nei sistemi ibridi, infine, è suddivisa tra l’ambiente nel quale opera la regola e quello nel quale avviene il settlement.[17]
Il vero elemento distintivo non è quindi la blockchain in quanto tale, ma il modello di allocazione della fiducia e del controllo. La domanda rilevante è chi possa validare l’evento, modificare la regola, arrestare o correggere il processo, accedere ai dati, assumere la responsabilità dell’errore e garantire il completamento del trasferimento.
9. Una tassonomia multidimensionale
La classificazione dei pagamenti condizionali non dovrebbe limitarsi all’alternativa tra moneta programmabile e pagamento programmabile. Per descrivere correttamente un caso d’uso occorre considerare almeno quattro variabili.
1. La collocazione della regola: La condizione può essere incorporata nella moneta, nell’ordine di pagamento, nel workflow precedente alla disposizione o in uno smart contract esterno.
2. L’attività utilizzata per il settlement: Il valore trasferito può essere moneta di banca commerciale, moneta elettronica, EMT, moneta di banca centrale o un’altra attività ammessa dall’infrastruttura.
3. Il rapporto tra ambiente della regola e ambiente del settlement: Regola e asset possono risiedere sullo stesso registro oppure essere separati e collegati mediante API, gateway o altri meccanismi di interoperabilità.
4. Il modello di fiducia: Validazione e controllo possono essere concentrati presso un soggetto, distribuiti tra più partecipanti o ripartiti tra componenti centralizzate e decentralizzate.
Questa impostazione consente di evitare equivalenze improprie. Una moneta può essere tokenizzata senza essere programmabile; un pagamento può essere programmabile senza utilizzare una DLT; una rete distribuita può includere componenti centrali; un sistema centralizzato può essere ridondato e resiliente. Programmabilità, tokenizzazione, decentralizzazione e velocità del settlement sono variabili correlate, ma autonome.
Conclusioni
I pagamenti condizionali rappresentano il quadro generale nel quale una condizione governa il trasferimento monetario. La moneta programmabile incorpora la regola nello strumento e può applicarla lungo trasferimenti successivi; il pagamento programmabile applica invece la regola a una disposizione o a un workflow, preservando la natura e, di regola, la fungibilità della moneta trasferita.
Le problematiche di affidabilità dei dati, responsabilità, sicurezza, contestazione e governance attraversano entrambe le fattispecie. La differenza risiede nel punto in cui la regola produce effetti e nel modello infrastrutturale attraverso il quale sono allocati fiducia, validazione e controllo.
Appendice – Tassonomia essenziale
I termini sono definiti esclusivamente nel significato assunto nel presente articolo.
Addebito diretto / SDD:Schema nel quale il beneficiario presenta una collection sulla base di un mandato del debitore, secondo una due date concordata.
ASPSP Account Servicing Payment Service Provider: prestatore che gestisce il conto di pagamento del cliente.
Atomic settlement: Regolamento nel quale più trasferimenti collegati si completano congiuntamente oppure non si completano affatto.
Blockchain: Modello di DLT nel quale gli aggiornamenti sono raggruppati in blocchi collegati mediante tecniche crittografiche.
Blockchain consortile: Rete governata e validata da un insieme selezionato di organizzazioni indipendenti.
Blockchain permissioned: Rete nella quale accesso, scrittura o validazione sono riservati a soggetti autorizzati.
Blockchain permissionless: Rete nella quale la partecipazione non richiede, in linea generale, l’autorizzazione preventiva di un gestore centrale.
Collection: Istruzione di incasso presentata dal creditore nell’ambito di uno schema di addebito diretto.
Condizionalità intrinseca: Condizione incorporata nello strumento monetario e capace di accompagnarne gli utilizzi successivi.
Condizionalità transazionale: Condizione riferita a uno specifico ordine o processo di pagamento, i cui effetti normalmente cessano con l’esecuzione.
CSM Clearing and Settlement Mechanism: meccanismo utilizzato dai PSP per lo scambio, la compensazione e/o il regolamento delle operazioni.
DLT Distributed Ledger Technology: Tecnologia che consente il funzionamento e l’uso di registri condivisi e sincronizzati tra più nodi.
EMT Electronic money token: Crypto-asset che mira a mantenere un valore stabile facendo riferimento a una valuta ufficiale ed è qualificato dal MiCAR come moneta elettronica.
Finalità del regolamento: Momento dal quale il trasferimento è incondizionato, opponibile e irrevocabile secondo le regole applicabili.
Fungibilità: Intercambiabilità tra unità dello stesso valore nominale senza differenze rilevanti nelle possibilità di impiego.
Fungibilità funzionale o locale: Intercambiabilità effettiva delle unità all’interno di un ecosistema i cui partecipanti condividono le medesime restrizioni.
Mandato SDD: Autorizzazione mediante la quale il debitore consente al creditore di presentare addebiti diretti e al proprio PSP di eseguirli.
Meccanismo di consenso: Regole e procedure con cui i nodi concordano la validità degli aggiornamenti del registro.
Moneta programmabile: Strumento monetario nel quale sono incorporati vincoli relativi a impiego, destinatari, territorio, importo o durata.
Oracolo: Componente che fornisce a uno smart contract informazioni relative a eventi esterni al registro.
Pagamento condizionale: Operazione nella quale avvio, esecuzione, regolamento o rilascio dei fondi dipendono da condizioni predefinite.
Pagamento programmabile: Forma automatizzata di pagamento condizionale nella quale la verifica della condizione attiva la disposizione, senza modificare la moneta trasferita.
Payment Initiation: Servizio o processo mediante il quale viene avviato un ordine di pagamento sul conto del pagatore.
PISP Payment Initiation Service Provider: Prestatore abilitato a iniziare un pagamento su richiesta e con il consenso del pagatore.
Programmabilità temporale: Esecuzione dell’ordine in una data futura o secondo una periodicità prestabilita.
PSP Payment Service Provider: Soggetto autorizzato a prestare servizi di pagamento.
Requested Execution Date: Data futura indicata dall’ordinante per l’avvio del ciclo di esecuzione di un SCT.
SCT SEPA Credit Transfer: Schema per bonifici in euro nell’area SEPA.
SCT Inst SEPA Instant Credit Transfer: Schema per bonifici in euro eseguiti e resi disponibili in tempi molto brevi.
Settlement: Trasferimento del valore e regolamento delle posizioni generate dall’operazione.
Single point of failure: Componente la cui indisponibilità o compromissione può impedire l’erogazione del servizio complessivo.
Smart contract: Codice eseguibile che applica automaticamente regole predeterminate quando ricorrono gli input richiesti.
SRTP SEPA Request-to-Pay: Schema di messaggistica che consente al beneficiario di richiedere al pagatore l’avvio di un pagamento.
Tokenizzazione:Rappresentazione digitale di un valore o diritto mediante token trasferibili e registrabili elettronicamente.
Trust boundary: Punto di raccordo nel quale dati, istruzioni o responsabilità passano tra componenti o soggetti con diversi presidi di fiducia.
Trust model: Assetto attraverso il quale fiducia, validazione, controllo e responsabilità sono distribuiti tra i partecipanti al sistema.
Note
[1] Banca centrale europea, Summary of collected inputs from MAG members – Cross-currency and conditional payments, 24 febbraio 2023, p. 4, ove i conditional payments sono descritti come pagamenti impartiti automaticamente al verificarsi di condizioni predefinite e si precisa che la precedente denominazione era programmable payments, https://www.ecb.europa.eu/euro/digital_euro/timeline/profuse/shared/pdf/ecb.degov230224_item21summaryinputconditionalcrosscurrency.en.pdf.
[2] Regolamento (UE) 2023/1114 del Parlamento europeo e del Consiglio, del 31 maggio 2023, relativo ai mercati delle cripto-attività (MiCAR), articoli 3, paragrafo 1, punto 7, 48, paragrafo 2, e 49, paragrafi 2-4, ELI: http://data.europa.eu/eli/reg/2023/1114/oj.
[3] Regolamento (UE) 2023/1114, cit., articolo 3, paragrafo 1, punti 1-6, che definisce DLT, registro distribuito, meccanismo di consenso, nodo di rete DLT e crypto-asset.
[4] European Payments Council, SEPA Direct Debit Core Scheme Rulebook 2025, versione 1.1, 5 ottobre 2025, sezioni 4.3.1, 4.5.4 e 4.6.4, pp. 29, 38 e 48, https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf.
[5] European Payments Council, SEPA Direct Debit Core Scheme Rulebook 2025, cit., sezioni 4.3.1 e 4.3.4, pp. 29-31; direttiva (UE) 2015/2366, cit., articolo 83, paragrafo 3.
[6] Direttiva (UE) 2015/2366, cit., articolo 78, paragrafo 2.
[7] European Payments Council, SEPA Credit Transfer Scheme Rulebook 2025, versione 1.1, 5 ottobre 2025, sezione 4.2.1, p. 26, https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf.
[8] European Payments Council, SEPA Request-to-Pay Scheme Rulebook, versione 4.0, 29 novembre 2024, sezioni 1.1 e 1.2, p. 9, https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC014-20%20v4.0%20SEPA%20RTP%20Scheme%20Rulebook.pdf.
[9] Direttiva (UE) 2015/2366 del Parlamento europeo e del Consiglio, del 25 novembre 2015, relativa ai servizi di pagamento nel mercato interno (PSD2), in particolare articoli 64, 73, 89-92 e 101-102, ELI: http://data.europa.eu/eli/dir/2015/2366/oj; regolamento (UE) 2022/858 del Parlamento europeo e del Consiglio, del 30 maggio 2022, relativo a un regime pilota per le infrastrutture di mercato basate sulla tecnologia a registro distribuito, considerando 8, 9, 39-41 e articolo 7, ELI: http://data.europa.eu/eli/reg/2022/858/oj.
[10] Banca centrale europea, The potential impact of DLTs on securities post-trading harmonisation and on the wider EU financial market integration, settembre 2017, p. 130, voce Oracle, https://www.ecb.europa.eu/paym/groups/ami/shared/pdf/201709_dlt_impact_on_harmonisation_and_integration.pdf.
[11] Regolamento (UE) 2022/858, cit., considerando 39-41 e articolo 7, paragrafi 2-4, relativi alle regole di funzionamento della DLT, alla partecipazione dei nodi validatori, alla gestione dei rischi e ai presidi informatici e cyber, inclusa l’affidabilità degli smart contract.
[12] Banca centrale europea, The potential impact of DLTs on securities post-trading harmonisation and on the wider EU financial market integration, cit., p. 46, sulle implicazioni di rischio operativo del raccordo tra tecnologie DLT e non DLT; regolamento (UE) 2022/858, cit., considerando 2.
[13] Direttiva 98/26/CE sul carattere definitivo del regolamento, articoli 3 e 5, ELI: http://data.europa.eu/eli/dir/1998/26/oj; Banca centrale europea, Payments and markets glossary, voce «Final settlement».
[14] Direttiva (UE) 2015/2366, cit., articoli 64 e 66, relativi al consenso del pagatore e all’accesso al conto di pagamento nell’ambito dei servizi di disposizione di ordine di pagamento.
[15] Regolamento delegato (UE) 2018/389 della Commissione, del 27 novembre 2017, che integra la PSD2 con norme tecniche di regolamentazione sull’autenticazione forte del cliente e sugli standard aperti di comunicazione comuni e sicuri, in particolare articoli 1-5 e 14, ELI: http://data.europa.eu/eli/reg_del/2018/389/oj.
[16] Banca centrale europea, The potential impact of DLTs on securities post-trading harmonisation and on the wider EU financial market integration, cit., pp. 92-95, che invita a non attribuire alla DLT, in astratto, l’eliminazione di ogni single point of failure e distingue tra guasti indipendenti, correlati e componenti centrali della rete.
[17] Regolamento (UE) 2022/858, cit., articolo 7, paragrafi 2-4; Banca centrale europea, The potential impact of DLTs on securities post-trading harmonisation and on the wider EU financial market integration, cit., pp. 15-18 e 94-95, sulle differenze tra modelli DLT, meccanismi di consenso, ruoli dei partecipanti e governance.
Partecipa alla community