Accesso, ruoli e quadro generale#
Il Client intermediario è l’applicazione operativa del partecipante. È separato dal Core CertiExch: conserva lavorazioni, wallet e dati locali del partecipante e usa le API per trasmettere al registro soltanto gli oggetti necessari.
Questo manuale segue ciò che vede un utente reale. Quando una funzione non compare, la causa più frequente è il ruolo assegnato, il partecipante collegato all’utenza o lo stato dell’oggetto.
Prima dell’accesso#
L’utenza deve essere associata a un partecipante e ad almeno un ruolo client. I ruoli principali sono:
| Ruolo | Operazioni tipiche |
|---|---|
client_admin | Tutte le funzioni del client e gestione organizzativa locale |
arranger_user | Composer, dossier, strategia di lancio, pre-collocamento e collocamento |
dealer_user | Pre-collocamento, RFQ, quote, wallet e servicing |
investor_user | Consultazione, interesse, sottoscrizione, RFQ e posizione locale |
custody_user | Wallet, quadratura, lifecycle e integrazione API |
demo_switcher | Cambio del partecipante soltanto negli ambienti dimostrativi autorizzati |
Accesso#
- Aprire l’ingresso del Client intermediario.
- Inserire le credenziali dell’utenza client.
- Verificare nel quadro generale il nome del partecipante attivo.
- Controllare il ruolo operativo e le voci di menu disponibili.
- In caso di ruolo errato, uscire e contattare l’amministratore delle identità; non usare l’utenza di un collega.
Le sessioni hanno una scadenza per inattività e una scadenza assoluta. Se una pagina rifiuta un comando dopo un lungo periodo, ricaricare la pagina, autenticarsi di nuovo e ripetere l’operazione solo dopo aver verificato che il primo invio non sia già stato registrato.
Come leggere il quadro generale#
Il quadro generale riassume:
- profilo del partecipante;
- pratiche di onboarding e rinnovi;
- mandati attivi;
- dossier e relative versioni;
- campagne esposte;
- collocamenti;
- RFQ e operazioni;
- posizioni e wallet;
- eventi di servicing;
- lotti di crediti accessibili.
I contatori sono indicatori di lavoro, non una contabilità ufficiale. Per un dato autoritativo aprire la funzione specifica e controllare identificativo, stato, versione e timestamp.
Stati ricorrenti#
| Stato | Interpretazione pratica |
|---|---|
draft | Lavorazione modificabile, non presentata |
submitted | Inviata al Core e in attesa di istruttoria |
under_review | Presa in carico da un operatore del Core |
approved | Approvata per il passaggio successivo |
rejected | Respinta; leggere la motivazione e creare una nuova versione se ammesso |
suspended | Temporaneamente bloccata |
closed | Processo terminato |
manual_review | Eccezione che richiede intervento umano, senza automatismi distruttivi |
Regola operativa generale#
Prima di premere un comando che trasmette dati al Core:
- controllare il partecipante attivo;
- controllare l’emittente o la controparte;
- verificare lo stato corrente;
- leggere eventuali warning;
- conservare il riferimento prodotto;
- evitare il doppio invio.
Le richieste mutative usano token CSRF nella WebUI e idempotenza nelle API. Se il browser mostra un errore di rete, verificare l’esito nella lista prima di ripetere.
Separazione dei dati#
Il Client può conoscere il dettaglio del cliente finale e la ripartizione dei wallet. Il Core riceve invece la posizione aggregata sul conto di registrazione e attestazioni coerenti con il processo. I dati fiscali individuali, le credenziali e i segreti API non devono essere copiati nelle note libere.