Titoli digitali
Consegna contro Pagamento: Come Funziona il Regolamento Atomico
Come la consegna rispetto al pagamento coordina le parti di asset e liquidità di un trade, cosa elimina l’esecuzione atomica e quali rischi di liquidità, legali e operativi rimangono.
Aggiungi Securities.io alle tue fonti preferite su Google
Una transazione ha due promesse: consegnare l’attivo e consegnare il denaro. Se quelle parti si liquidano separatamente, una parte può adempiere mentre l’altra fallisce. Consegna contro pagamento le collega in modo che lo scambio si completi insieme — o non si completi affatto.
Sembra un problema di smart contract puro, ma la finalità legale, la custodia, la liquidità e la qualità dell’attivo di regolamento continuano a essere importanti. Il nostro introduzione ai smart contracts spiega il livello di codice.
Consegna contro pagamento, o DvP, collega il trasferimento di un titolo al trasferimento del pagamento in modo che una parte si completi solo se l’altra si completa. Su un registro programmabile, entrambe le modifiche di stato possono essere eseguite in una singola transazione atomica o tramite sistemi coordinati con finalità equivalente. Ciò può ridurre drasticamente il rischio principale — la possibilità che una parte consegni valore e non riceva mai il controvalore.
L’atomismo non significa che ogni rischio scompaia. L’attivo e il denaro di regolamento devono rappresentare rivendicazioni legalmente valide, le parti devono avere liquidità al momento richiesto, le transazioni possono fallire prima dell’esecuzione e la governance deve gestire interruzioni o errori. Il regolamento lordo istantaneo può ridurre l’esposizione al controparte aumentando al contempo le esigenze di finanziamento intraday rispetto al netting di molte obbligazioni prima.
Consegna contro Pagamento in un’unica vista
Leggi la sequenza Consegna contro Pagamento come una catena di prove anziché una riga di passaggi software. Ogni fase dovrebbe lasciare un record che il partecipante successivo possa verificare senza inventare fatti mancanti.
Chi è responsabile per Consegna contro Pagamento?
| Acquirente e venditore | Fornire istruzioni valide, attivi idonei e liquidità di regolamento sufficiente. |
|---|---|
| Piattaforma di trading o sistema di matching | Crea una transazione concordata con dati di regolamento coerenti. |
| Registro dei titoli | Mantiene l’attivo consegnabile e le sue restrizioni di proprietà. |
| Registro di contanti o di denaro di regolamento | Fornisce l’attivo di pagamento e definisce quando il trasferimento di denaro è definitivo. |
| Coordinatore di regolamento | Collega condizioni, timeout, gestione dei fallimenti e prove in entrambe le parti. |
Inizia la revisione alla finalità del record e lavora all’indietro. Il titolare finale o l’istituzione dovrebbe essere in grado di collegare la propria posizione alla decisione al bloccare entrambe le parti e alla prova accettata al accettare la transazione. Se quella catena si interrompe a un cruscotto o a un hash di transazione, il sistema ha dimostrato che il software è stato eseguito — non necessariamente che il diritto, il pagamento o il cambiamento di registro promesso siano eseguibili.
La mappa dei partecipanti rivela un secondo confine. Acquirente e venditore e coordinatore di regolamento possono lavorare all’interno dello stesso prodotto, tuttavia mantengono registri diversi e hanno doveri diversi. Esternalizzare un compito operativo non sposta automaticamente la promessa al cliente o l’obbligo di correggere un errore. Un design credibile nomina il proprietario di fallback prima di un fallimento, non dopo.
Per un test di stress realistico, combina invalidità dell’attivo con blocco della liquidità. Richiedi ai partecipanti di congelare lo stato corretto, preservare i diritti validi del titolare, ricostruire la sequenza e raggiungere un unico risultato rieconciliato. Tale esercizio esamina se Consegna contro Pagamento ha un percorso di recupero governato o solo un percorso efficiente e felice.
Le affermazioni commerciali su Consegna contro Pagamento dovrebbero essere tradotte in un confronto misurabile prima e dopo. Identifica il passaggio manuale, il ritardo di riconciliazione, il carico di capitale, il buffer di liquidità o la barriera di distribuzione che il design intende cambiare. Quindi conta ogni nuova dipendenza introdotta dal registro dei titoli, dal registro, dall’attivo di regolamento e dal processo di recupero. Un trasferimento più rapido non è automaticamente un ciclo di vita più economico se le eccezioni diventano più lente o più concentrate.
Infine, cambia un fatto nell’esempio pratico: ritarda settle atomically, rendi indisponibile il luogo di negoziazione o il sistema di matching, o contesta il record detenuto dal libro contabile di contanti o di denaro di regolamento. Un prodotto robusto dovrebbe produrre una risposta prevedibile basata su documenti e registri autorevoli. Se l’esito dipende da una telefonata non documentata, Delivery Versus Payment ha digitalizzato il percorso visibile lasciando il controllo decisivo fuori dal sistema.
Chiedi chi beneficia quando Delivery Versus Payment funziona come progettato e chi paga quando si verifica un finality conflict. I ricavi possono accumularsi su un’interfaccia o piattaforma mentre liquidità, servizio e esposizione legale rimangono presso un’altra istituzione. Seguire sia la tariffa sia l’allocazione delle perdite impedisce a un diagramma operativo attraente di nascondere la parte il cui bilancio rende credibile il prodotto.
Dove i registri di Delivery Versus Payment devono concordare
I saldi di Delivery Versus Payment rivolti al cliente, i registri token, i registri legali, i conti di custodia e i registri di contanti possono aggiornarsi in tempi diversi. Il prodotto è affidabile solo quando le sue regole spiegano quale record controlla e come ogni altro record è riconciliato con esso.
Come funziona Delivery Versus Payment
1. Accordo sul trade in Delivery Versus Payment
Un trade produce prima un’obbligazione accoppiata. Le parti concordano lo strumento, l’importo, il prezzo e i conti di regolamento. Gli errori in questa fase dovrebbero essere risolti prima che gli asset vengano bloccati; altrimenti, il settlement programmabile può eseguire un’istruzione errata ma internamente valida in modo molto efficiente.
2. Verifica degli asset in Delivery Versus Payment
Il sistema verifica che il venditore controlli titoli consegnabili e che l’acquirente controlli un pagamento accettabile. Verifica inoltre l’eligibilità, le sanzioni, le restrizioni di trasferimento e lo stato del conto. Un saldo token da solo è insufficiente se lo strumento legale è congelato o se il token di pagamento non è riscattabile al valore nominale.
3. Blocca entrambe le parti in Delivery Versus Payment
Entrambe le parti sono riservate. Su un singolo libro può usare un contratto intelligente atomico; tra libri può usare blocchi, trasferimenti condizionali, coordinatori fidati o finestre sincronizzate. Il design deve impedire a una delle parti di usare l’asset riservato altrove evitando blocchi indefiniti quando una controparte scompare.
4. Settle Atomically in Delivery Versus Payment
Il settlement cambia entrambi i registri di proprietà. Se tutte le condizioni sono soddisfatte, il titolo passa all’acquirente e il denaro passa al venditore in una sequenza indivisibile. Se una condizione fallisce o il tempo scade, nessun trasferimento è finale e gli asset riservati vengono rilasciati secondo regole note.
5. Registrazione della finalità in Consegna contro Pagamento
Successivamente, i sistemi registrano la finalità e riconciliano le posizioni. La disponibilità immediata può permettere all’acquirente di riutilizzare i titoli come garanzia e al venditore di riutilizzare i contanti, ma solo se custodi, sistemi di rischio e quadri legali riconoscono lo stesso stato finale. Altrimenti un ledger veloce crea un altro record che i sistemi a valle devono riconciliare.
L’economia di Delivery Versus Payment
DvP può ridurre l’esposizione principale, i buffer di garanzia e la riconciliazione, ma il design del settlement cambia la domanda di liquidità. Il settlement atomico lordo richiede che ogni trade sia finanziato all’esecuzione. Il settlement netto riduce le esigenze di finanziamento scontrando le obbligazioni ma lascia l’esposizione fino al ciclo netto. I mercati devono scegliere l’equilibrio appropriato anziché presumere che il settlement più breve sia sempre il più economico.
L’asset di settlement è importante economicamente. Il denaro della banca centrale minimizza l’esposizione creditizia ma potrebbe non essere disponibile su ogni piattaforma. I depositi tokenizzati portano esposizione bancaria e regole di rete; le stablecoin aggiungono rischio di emittente, riserva e rimborso. Il costo di bridging o pre-finanziamento di forme frammentate di denaro può compensare parte dell’efficienza ottenuta sul lato titoli.
Modalità di fallimento in Delivery Versus Payment
- Invalidità dell’attivo: Il token consegnato non trasferisce il diritto di sicurezza vincolante.
- Rischio di denaro: Il bene di pagamento perde il valore nominale o non può essere riscattato.
- Blocco di liquidità: Le parti hanno beni ma non al momento e al luogo esatti richiesti.
- Fallimento cross-ledger: Blocchi o messaggi divergono tra i sistemi di asset e di liquidità.
- Conflitto di finalità: Il completamento tecnico non è riconosciuto dalla legge o dai registri successivi.
Esempio pratico di Delivery Versus Payment
Un dealer acquista obbligazioni tokenizzate per 5 milioni di dollari utilizzando denaro tokenizzato di banca commerciale. Il contratto di regolamento verifica entrambi gli account approvati, blocca le obbligazioni e 5 milioni di dollari, quindi li trasferisce in un’unica operazione atomica. Il rischio principale è eliminato per quel trade. Tuttavia, il dealer aveva ancora bisogno di 5 milioni di dollari sulla piattaforma corretta in quel momento, e entrambe le parti rimangono esposte alla validità legale del registro delle obbligazioni e alla qualità creditizia del denaro bancario.
Prove dietro Delivery Versus Payment
Il Rapporto Economico Annuale 2026 del BIS esamina i sistemi monetari e finanziari tokenizzati, mentre il rapporto sulla tokenizzazione dell’IOSCO identifica regolamento, interoperabilità e certezza legale come vincoli pratici. Insieme mostrano perché l’esecuzione atomica è solo un livello di un design DvP sicuro.
Cosa sta cambiando in Delivery Versus Payment?
Le banche centrali e le infrastrutture di mercato stanno passando da dimostrazioni sandbox a piloti DvP a valore reale. L’attenzione si sposta verso il denaro di regolamento interoperabile, la finalità legale e la gestione della liquidità. Il lavoro del BIS nel 2025 e 2026 inquadra le riserve tokenizzate delle banche centrali, il denaro delle banche commerciali e i titoli come componenti di un sistema programmabile unificato piuttosto che catene isolate collegate da ponti fragili.
Domande da porre su Delivery Versus Payment
- Accordo di scambio provato da quale registro, e chi può correggerlo quando si verifica l’asset, la quantità, il prezzo, le controparti, gli account e il tempo di regolamento previsto.
- Verifica degli asset provato da quale registro, e chi può correggerlo quando si conferma che il venditore controlla titoli idonei e l’acquirente controlla denaro accettabile.
- Blocco di entrambe le parti provato da quale registro, e chi può correggerlo quando si riserva o si condizioni l’asset e il pagamento in modo che nessuno possa essere speso altrove.
- Regolamento atomico provato da quale registro, e chi può correggerlo quando si trasferiscono entrambe le pretese insieme o si rilascia nessuna quando le condizioni falliscono.
- Registrazione della finalità provato da quale registro, e chi può correggerlo quando si aggiornano i registri autorevoli e si rendono disponibili le posizioni completate per il riutilizzo.
Cosa leggere dopo Delivery Versus Payment
Segui la parte dei titoli in Come funzionano le transazioni con token di sicurezza, poi confronta gli asset di regolamento in Paxos spiegato. La sequenza di pagamento più ampia appare in pagamenti agenziali e tokenizzati.
Conclusioni su Delivery Versus Payment
DvP elimina il divario tra la consegna di un asset e la ricezione del pagamento. Non elimina le esigenze di finanziamento, le operazioni fallite, i controlli di identità, il rischio di custodia o l’obbligo che entrambe le parti siano legalmente finalizzate.
Fonti per Delivery Versus Payment
