Runbook di esercitazione#

Questo capitolo fornisce una traccia comune per esercitare simulatori e gateway. Ogni prova deve avere un obiettivo misurabile e produrre un verbale: cambiare stati a caso nella console non è un test.

Preparazione#

Compilare:

ID esercitazione:
Data e ambiente:
Owner:
Operatori:
Sistemi coinvolti:
Modalità: simulatore / stub / sandbox / reale controllato
Oggetti di partenza:
Scenario:
Risultato atteso:
Criterio di arresto:
Piano di ripristino:
Evidenze da raccogliere:

Verificare che l’ambiente non contenga dati o credenziali di produzione se si usano simulatori.

Baseline#

Prima di introdurre l’errore registrare:

• stato dei sistemi;
• stato degli oggetti interessati;
• saldi/posizioni;
• ultimo messaggio;
• ultimo evento;
• livello delle evidenze;
• eventuali riconciliazioni aperte.

Senza baseline non è possibile dimostrare l’effetto della prova.

Caso 1 — Happy path DvP#

Successo: una sola conseguenza cash, una sola consegna, riferimenti correlati, stato finale riconciliato.

Caso 2 — Fondi insufficienti#

1. Usare un pagatore con saldo simulato inferiore all’importo.
2. Tentare la riserva cash.
3. Verificare che la consegna non venga rilasciata.
4. Controllare codice/messaggio e assenza di ricevuta finale.
5. Ripristinare la provvista o annullare secondo runbook.

Successo: nessuna finalità cash e nessun trasferimento titoli.

Caso 3 — Provider offline prima dell’invio#

1. Impostare il sistema su Avaria.
2. Avviare l’operazione.
3. Verificare il fallimento prima della finalità.
4. Ripristinare il sistema.
5. Eseguire lookup/riconciliazione.
6. Applicare retry controllato.

Successo: nessun effetto duplicato e tentativo successivo collegato al precedente.

Caso 4 — Timeout con ricevuta tardiva#

Questo caso richiede uno stub o una sandbox capace di ritardare la risposta.

1. Inviare la richiesta.
2. Forzare il timeout del client.
3. Non eseguire immediatamente un secondo pagamento.
4. Acquisire la ricevuta tardiva tramite webhook o lookup.
5. Verificare la correlazione.
6. Chiudere il ciclo senza duplicare l’effetto.

Successo: la ricevuta tardiva viene acquisita una sola volta.

Caso 5 — Cash finalizzato, consegna fallita#

1. Portare il ciclo a cash finality.
2. Rendere indisponibile la consegna/rail.
3. Tentare la finalizzazione.
4. Verificare manual_review e cash_only.
5. Conservare la prova cash.
6. Eseguire il runbook di consegna correttiva o rimborso simulato.
7. Riconciliare.

Caso 6 — Paying agent parziale#

1. Creare un evento di servicing con più obbligazioni.
2. Accettare alcune istruzioni e lasciare altre pending o rejected.
3. Generare ricevute soltanto per gli importi pagati.
4. Verificare saldo residuo, codice di eccezione e stato dell’evento.
5. Completare o correggere.
6. Riconciliare lordo, imposte e netto.

Caso 7 — Documentazione fiscale mancante#

1. Associare uno stato documentale incompleto a un conto.
2. Simulare missing_tax_documentation o pending tax validation.
3. Verificare che l’importo interessato resti sospeso.
4. Aggiornare il riferimento documentale fuori dal dettaglio personale.
5. Ripresentare l’istruzione autorizzata.

Caso 8 — Avanzamento T0/T1/T2#

1. Generare un evento attestato T0.
2. Verificare hash e ID.
3. Usare Simula webhook T1/T2.
4. Sincronizzare.
5. Controllare la visibilità nell’Exchange.
6. Verificare che l’evento economico non cambi stato per il solo avanzamento probatorio.

Caso 9 — Log rail non attendibile#

Con uno stub EVM o fixture di test:

1. Presentare un log con chain ID errato, contratto non autorizzato o topic sconosciuto.
2. Verificare che non aggiorni mirror, posizioni o settlement.
3. Registrare l’incidente.
4. Conservare log grezzo e motivo del rifiuto.
5. Verificare che il cursor attendibile non salti eventi validi.

Caso 10 — Registro ricevente#

1. Preparare una transizione su uno strumento senza processi aperti.
2. Trasmettere il pacchetto integro.
3. Acquisire ricevuta accepted.
4. Ripetere la prova con hash alterato in un ambiente separato.
5. Verificare rejected e mancata migrazione.
6. Eseguire riconciliazione post-import sul destinatario.

Caso 11 — Fixing mancante o revisionato#

1. Selezionare uno strumento indicizzato.
2. Omettere il fixing della data richiesta.
3. Verificare che il calcolo non inventi un valore.
4. Pubblicare il fixing.
5. Eseguire il calcolo.
6. Pubblicare una revisione e verificare la procedura di correzione, senza riscrivere il risultato già finalizzato.

Raccolta delle evidenze#

Per ogni caso conservare:

• screenshot essenziali;
• request ID;
• identificativi degli oggetti;
• messaggi inviati/ricevuti;
• ricevute;
• stati prima/dopo;
• riconciliazione;
• log applicativi rilevanti;
• eventuale proof package;
• decisione finale.

Non includere segreti o dati personali nel verbale.

Chiusura#

Il report deve indicare: