Registro ricevente e transizione#

Il registro ricevente entra in gioco quando uno strumento e le relative scritturazioni devono essere trasferiti a un’altra infrastruttura. La transizione non consiste nel copiare un token: deve preservare strumenti, posizioni, eventi, servicing, vincoli e prove.

Quando usare la transizione#

La procedura può essere necessaria per:

• sostituzione del fornitore tecnologico;
• trasferimento a un altro responsabile del registro;
• migrazione del rail o dell’infrastruttura;
• cessazione del servizio;
• esercitazione di continuità;
• conversione verso un diverso regime di circolazione.

Non usare la transizione come scorciatoia per correggere una posizione o duplicare un ambiente.

Prerequisiti#

Prima di creare il pacchetto:

• nessun settlement aperto;
• nessuna rettifica pendente;
• stato dello strumento coerente;
• posizioni riconciliate;
• servicing aggiornato;
• identità e ruoli disponibili;
• destinatario identificato;
• base giuridica e data di efficacia definite.

La creazione del pacchetto congela lo strumento per la transizione e impedisce nuove operazioni incompatibili.

Contenuto del pacchetto applicativo#

Il pacchetto di transizione dello strumento include almeno:

instrument
positions
register events
servicing events
generated_at
package_hash

La continuità completa dell’intera piattaforma usa invece il pacchetto di continuity export descritto nel manuale Infrastruttura. I due oggetti non sono intercambiabili.

Hash e ricevuta#

Il registro ricevente deve:

1. ricevere il pacchetto;
2. ricalcolare l’hash sul contenuto canonico;
3. confrontarlo con package_hash;
4. accettare o rifiutare;
5. produrre una ricevuta propria.

La ricevuta deve contenere:

• receipt ID;
• transition ID;
• data di ricezione;
• hash ricevuto;
• stato accepted o rejected;
• reference del destinatario;
• messaggio o codice di errore.

Simulatore del registro ricevente#

Il simulatore:

• richiede che il sistema receiving_register sia online;
• deduplica per transition ID;
• ricalcola l’hash del pacchetto;
• restituisce accepted se coincide;
• restituisce rejected se non coincide;
• conserva la ricevuta e un messaggio di risposta.

Non verifica la capacità giuridica o operativa del soggetto ricevente: simula solo il contratto tecnico minimo.

Rifiuto#

In caso di rejected:

• lo strumento non deve essere marcato come migrato;
• il freeze non va rimosso senza decisione controllata;
• confrontare hash, schema, versione e contenuto;
• verificare che il destinatario abbia ricevuto l’archivio corretto;
• produrre una nuova versione solo se necessaria;
• conservare la ricevuta di rifiuto.

Non modificare il pacchetto già hashato mantenendo lo stesso identificativo.

Riconciliazione post-migrazione#

Il ricevente deve dimostrare almeno:

• stesso strumento e Master Record;
• stessa quantità complessiva;
• stesse posizioni per conto;
• stessi vincoli aperti;
• stesso ultimo evento;
• stessi servicing event rilevanti;
• corretta correlazione delle identità;
• continuità delle prove;
• eventuali nuovi identificativi mappati.

La ricevuta di acquisizione non sostituisce questa riconciliazione.

Dati non inclusi automaticamente#

Credenziali, password, sessioni, chiavi private e token non devono essere trasferiti dentro il pacchetto. Il ricevente deve predisporre il proprio IAM e le proprie chiavi, collegandoli alle identità e ai ruoli con procedura separata.

Esercitazione#

Una prova di transizione valida deve usare:

• ambiente destinatario pulito;
• trust anchor acquisito fuori banda;
• conteggi noti;
• operatori distinti;
• report delle differenze;
• criterio di rollback;
• decisione finale formalizzata.