Modello di integrazione e terminologia#

CertiExch coordina processi che attraversano sistemi diversi, ma non assume automaticamente il ruolo dei soggetti esterni. Il contante resta presso banche e prestatori di pagamento; la fiscalità resta presso intermediari e sostituti d’imposta; le chiavi del rail restano nel signer o nel presidio di custodia; le attestazioni qualificate restano nel perimetro CertiSigma; custodia, dati di mercato e reporting restano presso i rispettivi provider.

Questo manuale serve a distinguere con precisione ciò che il sistema simula, ciò che riceve, ciò che verifica e ciò che produce effetti nel registro.

Il principio operativo#

CertiExch prepara una richiesta
→ il sistema esterno la riceve o la esegue
→ restituisce un riferimento e uno stato
→ CertiExch verifica correlazione e coerenza
→ aggiorna il processo interno
→ conserva ricevuta ed evidenze

Il passaggio decisivo è sempre la verifica della risposta. La disponibilità tecnica del provider non basta a dimostrare che un’operazione sia stata eseguita, né una risposta generica può sostituire una ricevuta riferita alla specifica istruzione.

Sei termini da non confondere#

Termine	Significato operativo
Simulatore	Componente locale che riproduce stati ed esiti per esercitazione. Non prova un fatto avvenuto presso un soggetto reale.
Stub	Endpoint o componente ridotto usato per verificare il contratto tecnico. Può non riprodurre l’intero comportamento del provider.
Sandbox	Ambiente esterno di prova gestito dal provider. Usa il suo contratto tecnico, ma non produce normalmente effetti economici reali.
Provider reale	Sistema qualificato e contrattualizzato che esegue o attesta la funzione esterna.
Conferma esterna	Messaggio riferito a una specifica operazione, autenticato e verificato prima dell’acquisizione.
Evento autoritativo	Evento che modifica lo stato riconosciuto dal registro o chiude una fase del processo secondo regole approvate.

Cosa resta autoritativo#

Per la configurazione ordinaria di CertiExch:

il registro CertiExch resta fonte di verità per strumenti, conti, posizioni, vincoli ed eventi registrati;
il provider monetario è fonte della conferma sulla gamba cash;
il paying agent è fonte delle ricevute di pagamento e dei risultati fiscali di propria competenza;
il provider di indici è fonte del fixing acquisito;
il registro ricevente è fonte della ricevuta di presa in carico del pacchetto di transizione;
il rail DLT esterno è un livello interoperabile e non sostituisce il registro, salvo un diverso modello formalmente approvato;
CertiSigma prova integrità e sequenza delle evidenze, ma non decide la titolarità o la finalità economica.

Richiesta, ricevuta ed effetto#

Ogni integrazione deve rendere distinguibili almeno tre oggetti:

Istruzione o richiesta: ciò che CertiExch chiede al provider.
Ricevuta o risposta: ciò che il provider dichiara di aver ricevuto, accettato, eseguito o rifiutato.
Effetto interno: la transizione che CertiExch applica dopo le verifiche.

Esempio per la gamba monetaria:

cash instruction
≠ provider acknowledgement
≠ cash finality confirmation
≠ finalità complessiva DvP

L’acknowledgement dimostra soltanto che la richiesta è stata ricevuta. La finalità richiede la conferma prevista dal contratto operativo.

Identificativi e correlazione#

Ogni scambio deve conservare identificativi stabili:

request ID CertiExch;
idempotency key;
identificativo dell’oggetto interno;
riferimento del provider;
eventuale receipt reference;
timestamp di invio e ricezione;
hash del payload quando previsto;
evidence ID.

Non creare manualmente riferimenti “simili” a quelli del provider. Un riferimento mancante, duplicato o non correlabile deve produrre un’eccezione, non un completamento presunto.

Stati dei sistemi#

La console usa tre stati sintetici:

Stato	Significato per l’esercitazione
`online`	Il simulatore accetta le funzioni previste.
`degraded`	Il sistema è raggiungibile ma alcune capacità possono essere limitate o incerte.
`offline`	La funzione esterna deve essere considerata indisponibile.

Nel mondo reale lo stato deve essere più granulare. Un provider può consentire letture ma non scritture, accettare istruzioni ma non produrre ricevute, oppure rispondere con ritardi. La qualificazione deve quindi avvenire per capability, non con un unico semaforo.

Confine dei dati#

Prima di collegare un provider, classificare i dati scambiati:

pubblici;
riservati di operazione;
personali o pseudonimizzati;
fiscali;
credenziali e segreti;
materiale crittografico;
evidenze e ricevute.

Le credenziali, le chiavi private e i token non devono comparire nei payload di business, nei log applicativi, negli export di continuità o nei manuali di esercitazione.

Regola di fail-closed#

In pre-produzione e produzione, una configurazione incompleta deve impedire l’avvio della capability interessata. Non sostituire automaticamente un provider reale non disponibile con il simulatore.

Prima di usare questo manuale#

Per ogni esercitazione annotare:

ambiente;
provider selezionato;
modalità simulata, sandbox o reale;
dati utilizzati;
attori autorizzati;
risultati attesi;
criterio di successo;
procedura di pulizia o reset;
evidenze da conservare.

Questa dichiarazione evita che uno stesso screenshot o una stessa ricevuta vengano interpretati fuori dal contesto nel quale sono stati prodotti.