Accesso, ruoli e responsabilità#
L’Infrastruttura CertiExch governa gli oggetti centrali: partecipanti, strumenti, posizioni, settlement, servicing, rettifiche, continuità e gateway. Non è un pannello tecnico generico. Molte azioni producono effetti operativi o autoritativi e sono quindi protette da ruoli, permessi e controlli maker-checker.
Ruoli principali#
| Ruolo | Responsabilità prevalente | Vincolo |
|---|---|---|
registry_admin | Amministrazione complessiva del registro | Uso eccezionale e tracciato |
registry_operator | Operazioni ordinarie su registro, settlement e servicing | Non approva le proprie operazioni maker-checker |
registry_controller | Controllo, rettifiche, continuità e approvazioni | Checker distinto dal maker |
compliance_officer | Registrazione, mandati, compliance e ammissioni | Non dispone liberamente posizioni o cash |
market_supervisor | Pre-collocamento, emissione, Exchange e settlement | Opera nel perimetro di mercato |
servicing_operator | Record date, pagamenti, covenant e riconciliazioni | Non gestisce fiscalità individuale |
continuity_operator | Export, verifica e richieste di restore | Restore applicativo richiede checker |
key_custodian | Materiale e rotazione delle chiavi | Non muta fatti finanziari |
authority_observer | Consultazione per autorità | Sola lettura |
auditor | Evidenze e controlli trasversali | Sola lettura |
technical_maintainer | Salute tecnica, provider e diagnostica | Nessuna mutazione giuridica |
simulator_operator | Stati dei simulatori in ambienti ammessi | Nessun uso in produzione |
Accesso#
- Aprire l’ingresso Infrastruttura CertiExch.
- Autenticarsi con l’utenza personale.
- Verificare ruolo e ambiente.
- Controllare che il menu mostri soltanto le aree autorizzate.
- Leggere eventuali avvisi di health, maintenance o provider degradati.
Permessi e visibilità#
La mancata presenza di un pulsante può dipendere da:
- permesso non assegnato;
- oggetto in stato incompatibile;
- necessità di checker;
- ambiente che vieta simulatori o restore;
- partecipante/strumento sospeso;
- condizione esterna non soddisfatta.
Non chiedere di “sbloccare il pulsante” senza prima identificare quale regola impedisca l’azione.
Maker-checker#
Le operazioni più sensibili richiedono due persone distinte. Nella baseline sono incluse almeno:
- approvazione della sostituzione wallet;
- autorizzazione del restore;
- approvazione delle rettifiche del registro;
- conferma della rotazione della chiave di registro.
Il maker prepara e motiva; il checker verifica dati, evidenze e impatto. Lo stesso attore non può ricoprire entrambi i passaggi.
Read-only reale#
authority_observer, auditor e technical_maintainer sono bloccati dalle mutazioni anche lato server. Se un utente read-only riesce a visualizzare un form mutativo, non usarlo e segnalarlo come difetto di autorizzazione.
Separazione dei piani#
- Registro: titolarità, posizioni, vincoli, eventi.
- Cash: banca o provider monetario esterno.
- Wallet cliente: intermediario.
- Fiscalità individuale: intermediario o sostituto d’imposta.
- Prova: provider CertiSigma e evidence store.
- Rail DLT: rappresentazione interoperabile, salvo diversa qualifica.
Profilo pilot e profilo infrastruttura completa#
La matrice dei ruoli descrive funzioni, non impone una persona diversa per ogni riga. In un pilot o presso un operatore compatto, la stessa organizzazione può assegnare più ruoli a utenti diversi o, per funzioni non confliggenti, allo stesso utente. Restano separati gli atti che richiedono maker-checker, la custodia delle chiavi e le funzioni di controllo incompatibili con l’operatività.
Nel profilo completo, registro, mercato, servicing, sicurezza, continuità e audit possono essere affidati a unità distinte. La configurazione scelta deve essere documentata in una matrice locale che indichi titolare, sostituto, escalation e segregazioni effettive. Il manuale usa i nomi funzionali anche quando, nel pilot, più funzioni sono svolte da un gruppo ristretto.