MIGRATION PREPARATION SCHEDULE T2S PROJECT Versione 1.0 1 Sommario 1 GESTIONE DEL DOCUMENTO 5 1.1 Cronologia del documento 1.2 Acronimi ed abbreviazioni 1.3 Documentazione di riferimento 5 5 6 2 OBIETTIVO DEL DOCUMENTO 7 3 PANORAMICA DEL PROCESSO DI MIGRAZIONE A T2S 8 3.1 3.2 3.3 3.4 3.5 3.6 4 5 6 Pianificazione della migrazione Attori coinvolti Composizione della prima finestra Composizione della seconda finestra Composizione della terza finestra Composizione della quarta finestra 8 9 11 14 15 16 PIANO DELLE ATTIVITA’ DI MIGRAZIONE 18 4.1 Attività e Synchronisation Point 18 MIGRAZIONE DEI DATI STATICI 25 5.1 Introduzione alla migrazione dei dati statici 5.2 Consegna ai clienti dei dati necessari per la configurazione in T2S 5.2.1 Dati dei Servizi di pre-settlement 5.2.2 Dati dei Servizi di Liquidazione 5.2.3 Dati dei Servizi di regolamento estero (DVP Cross-Border) 5.2.4 Dati dei Servizi di gestione accentrata emittenti ed intermediari 5.3 Conferma da parte dei clienti dei dati di configurazione forniti da Monte Titoli 5.4 Trasferimento dei dati ufficiali di configurazione al sistema di test 5.5 Pre-Migration Dress Rehearsal 5.6 Frozen Period 5.7 Go – live dei dati statici in T2S 5.8 Finestra di contingency per il caricamento dei dati statici 25 26 29 30 31 31 33 35 35 36 37 37 VARIAZIONI ALLE MODALITA’ DI PARTECIPAZIONE AI SERVIZI DI MONTE TITOLI 38 6.1 Modifica del soggetto pagatore 6.1.1 Modifica del soggetto pagatore nell’ ambito del servizio di gestione accentrata 6.1.2 Modifica del soggetto pagatore nell’ ambito del servizio di liquidazione 6.2 Modifica del soggetto liquidatore e della tipologia di adesione alla CCP 6.2.1 Modello operativo “A” o Modello di marginazione lordo 6.2.2 Modello operativo “B” o Modello di marginazione netto 39 39 39 40 42 53 7 8 9 T2S USER TESTING & MIGRATION TESTING 74 7.1 7.2 7.3 7.4 74 74 75 77 Introduzione User Testing: attori coinvolti User Testing Migration Testing GESTIONE DEGLI ACCESS RIGHT IN T2S (solo per DCP) 78 8.1 Introduzione alla gestione dei diritti di accesso a T2S 8.2 Concetti e definizioni principali 8.2.1 User Function 8.2.2 Privilegi 8.2.3 Secured Object 8.2.4 Secured Group 8.2.5 Ruolo 8.2.6 User 8.2.7 Data Scope 8.3 Configurazione degli access rights in T2S 8.3.1 Configurazione utenti 8.3.2 Configurazione privilegi 8.3.3 Configurazione ruoli 8.4 Processo di assegnazione degli access rights in T2S 8.4.1 Access rights a livello di Party 8.4.2 Access rights a livello di utenti 8.5 Gestione decentralizzata degli access rights in T2S 78 79 79 80 81 81 81 81 81 84 84 85 85 86 87 89 89 ALLEGATO A: DETTAGLIO DATI STATICI PER T2S 9.1 Introduzione 9.2 Party 9.3 Technical address network service link 9.4 Associazione di default negoziatore/liquidatore e relativi conti di regolamento: (LIQDEF) 9.5 Associazione Negoziatore/GCM/Liquidatore del GCM (CCPNEG) 9.6 Eccezione per mercato dell’ associazione negoziatore/liquidatore (LIQNEG) 9.7 Struttura dei conti per il servizio di gestione accentrata 9.8 Coordinate per il regolamento contante operazioni DVP 9.9 Pagamenti relativi alle corporate action in T2S 9.10 Pagamenti relativi alle corporate action in T2 91 91 93 96 97 101 104 107 111 117 123 10 Allegato B – Effetti sulle operazioni delle variazione della modalità di adesione alla CCP e/o cambio del soggetto liquidatore 129 11 Allegato C – Access Rights per DCP 129 1 GESTIONE DEL DOCUMENTO 1.1 Cronologia del documento Data Versione Dettagli 09/04/2014 1.0 - 1.2 Acronimi ed abbreviazioni Nome Descrizione ATIE Anagrafe Titoli Impediti ed Estratti BAU Business As Usual BIC Bank Identifier Code CB Central Bank CCP Central Counter Party CMB Credit Memorandum Balance CMS Collateral Management System CSD Central Securities Depository DCA Dedicated Cash Account DCP Direct Connected Participant DV Data Valuta DVP Delivery Versus Payment ECB European Central Bank FIS Flussi Informativi Standardizzati FOP Free Of Payment GCM General Clearing Member GUI Graphical User Interface HW Hardware ICM Individual Clearing Member ICP Indirect Connected Participant ISD Intended Settlement Date MT Monte Titoli MWE Migration Week End MWEDR Migration Week End Dress Rehearsal NSP Network Service Provider OTC Over the Counter PB Payment Bank 5 PMDR Pre Migration Dress Rehearsal PMSP Pre - Migration Synchronisation Point RBAC Role Based Access Controls RCC Regolamento Corrispettivi Clienti RTGS Real Time Gross Settlement SAC Securities Account SME System Maintain Entity SNB Saldo Netto Bilaterale SP Synchronisation Point SW Software T2S Target 2 Securities UDFS User Detailed Functional Specifications UHB User Handbook VAN Value Added Network 1.3 Documentazione di riferimento Documento di riferimento Fonte Istruzioni Servizio X- http://www.montetitoli.it/area- TRM download/normativa/expressii/istrxtrm28102013senza.pdf Istruzioni al Servizio di Gestione per Accentrata Intermediari ed http://www.montetitoli.it/areadownload/normativa/gestioneaccentrata/istruzga08072013clean.pdf Emittenti Migration Weekend Playbook T2S User Documento del gruppo di lavoro “T2S/MT Testing & Migration” pubblicato nell’ apposita sezione documentale di MT-X Detail Functional http://www.ecb.europa.eu/paym/t2s/pdf/UDFS_v1_2_1.pdf?02dbde 3be45b2d0bf5a5afcf4de34f36 Specifications T2S User Hand Book http://www.ecb.europa.eu/paym/t2s/pdf/User_Handbook_v1.0.pdf? cc76cbb67593fe9e8b489e733a315bea 6 2 OBIETTIVO DEL DOCUMENTO L’obiettivo di questo documento è descrivere nel dettaglio l’insieme di attività e processi che prevedono un coinvolgimento diretto del cliente o la sincronizzazione con lo stesso nel percorso di migrazione a T2S, con riferimento alla migrazione dei dati statici del cliente. In particolare, si dettagliano le attività che prevedono l’intervento del cliente, specificandone modalità, tempistiche e contributo previsto, nell’ambito nel piano delle attività di migrazione definito a livello di Eurosistema e di Monte Titoli. L’insieme delle attività preparatorie della migrazione si riferisce principalmente ai tre mesi che precedono l’avvio di T2S ed è applicabile solo alla prima finestra di migrazione. Le finestre successive saranno trattate in un documento successivo. In particolare, l’obiettivo del documento “Migration Preparation Schedule” è quello di fornire una panoramica completa relativamente a: Identificazione dell’insieme di attività preparatorie da finalizzarsi in vista della migrazione a T2S e che prevedono un attivo coinvolgimento/interazione del/col cliente; Definizione dell’insieme di Pre-Migration Synchronisation Point (PMSP) definiti a livello di Eurosistema e di quelli aventi natura prettamente bilaterale, delineati tra Monte Titoli ed i propri clienti; Migrazione dei dati statici: o descrizione e gestione del processo di migrazione a T2S e nei nuovi sistemi legacy di Monte Titoli; o descrizione degli elementi informativi necessari per la configurazione dei clienti nei nuovi ambienti legacy di Monte Titoli ed in T2S; approccio al reperimento degli elementi di configurazione necessari per la migrazione dei dati statici e gestione del processo in caso di informazioni indispensabili a Monte Titoli ma non pervenute dai clienti; Definizione del “Frozen period” volto ad evitare eventuali variazioni ai dati statici di configurazione; Analisi di dettaglio dei possibili scenari di variazione alle modalità di partecipazione ai servizi di Monte Titoli ammesse durante la migrazione a T2S; Introduzione alla fase di testing della migrazione per la prima wave di migrazione a T2S; Introduzione alla gestione degli access rights in T2S ed in Monte Titoli (valido solo per clienti DCP). 7 3 3.1 PANORAMICA DEL PROCESSO DI MIGRAZIONE A T2S Pianificazione della migrazione Il processo di migrazione verso la nuova piattaforma T2S è organizzato in quattro diverse finestre di migrazione (c.d. migration waves), attualmente pianificate secondo lo schema sotto riportato. Ogni singola finestra di migrazione è suddivisa in tre fasi distinte. Con particolare riferimento alla prima finestra di migrazione, si noti la schedulazione dettata dall’Eurosistema e definita secondo quanto segue: 1. Fase di pre-migrazione: periodo antecedente il weekend di migrazione; 2. Fase di migrazione: weekend di migrazione a T2S vero e proprio; 3. Fase di stabilizzazione: periodo, conclusa la fase due, di verifica della nuova piattaforma T2S. Wave 1 2 3 4 Fase di pre- Weekend di Fase di migrazione migrazione stabilizzazione 24 marzo 2015 – 19 giugno 2015 – 22 giugno 2015 – 19 giugno 2015 22 giugno 2015 27 luglio 2015 04 gennaio 2016 – 25 marzo 2016 – 28 marzo 2016 – 25 marzo 2016 28 marzo 2016 25 aprile 2016 14 giugno 2016 – 09 settembre 2016 – 12 settembre 2016 – 09 settembre 2016 12 settembre 2016 17 ottobre 2016 03 novembre 2016 – 03 febbraio 2017 – 06 febbraio 2017 – 03 febbraio 2017 06 febbraio 2017 13 marzo 2017 8 3.2 Attori coinvolti La tabella proposta di seguito fornisce un elenco dei diversi attori coinvolti nel processo di migrazione verso la nuova piattaforma T2S, a prescindere dalla specifica finestra di migrazione alla quale gli stessi prendono parte. È bene specificare che ogni singolo soggetto partecipa al processo di migrazione alla piattaforma T2S a seconda dello specifico ruolo che ricopre. Con particolare riferimento alle Banche Centrali, nel nuovo panorama designato dall’introduzione della piattaforma T2S, le stesse possono ricoprire quattro differenti ruoli, ovvero: 1. Owner del sistema Real Time Gross Settlement, garantendo: La connessione degli attuali sistemi RTGS Target 2 alla piattaforma T2S; Il costante monitoraggio della liquidità in T2S nonchè il trasferimento della stessa da/verso Target 2 (liquidity transfer orders); La gestione dei Dedicated Cash Accounts (DCA) in T2S. 2. Gestore della liquidità, garantendo: La connessione dei sistemi di Collateral Managament System (CMS) a T2S; La gestione delle configurazioni necessarie per attivare i processi di collateralizzazione in T2S; L’ offerta di collaterale in T2S; La riconciliazione dei movimenti derivanti dalle operazioni di collateralizzazione in T2S con il CMS. 3. System Entity, garantendo: La definizione e la gestione dei propri dati statici in T2S quali, ad esempio: Party, DCA. 4. Settlement Agent, garantendo: La definizione di ogni singola Banca Centrale come soggetto partecipante di un CSD; La gestione del link tra i propri conti titoli ed i DCA; L’esecuzione del regolamento di operazioni di politica monetaria in T2S. Per maggiori dettagli informativi si rimanda alla sezione “key documents” sul sito di ECB, contenente la principale documentazione relativa a T2S, http://www.ecb.europa.eu/paym/t2s/about/keydocs/html/index.en.html 9 di cui al link: Si precisa che alcune Banche Centrali, come descritto nelle successive tabelle, supporteranno solo alcuni dei quattro ruoli precedentemente descritti. ATTORI DESCRIZIONE Insieme dei CSD che prendono parte a una specifica finestra di migrazione. Migrating CSD Il processo di migrazione a T2S avviene coinvolgendo simultaneamente le Banche Centrali Nazionali ed i soggetti clienti dei CSD (CSD participant) Insieme delle Banche Centrali che prendono parte a una specifica finestra di migrazione. Il processo di migrazione a T2S avviene coinvolgendo simultaneamente i CSD nazionali e le payment bank. Come precedentemente descritto, si ricorda che le Banche Centrali possono migrare alla nuova piattaforma T2S assumendo Migrating CB uno o più ruoli, descritti in apertura al paragrafo 3.2 e di seguito elencati: Owner del sistema RTGS Gestore della liquidità System Entity Settlement Agent CSD che operano in T2S come SME, ovvero come “Securities Maintaining Entities” degli strumenti finanziari dei quali sono Issuer SME CSD o Techical Issuer I CSD participant, ovvero i clienti dei CSD. È possibile distinguere due differenti tipologie di CSD participant, ovvero: CSD participant (DCP/ICP) DCP: soggetti che interagiscono direttamente con la piattaforma T2S in modalità A2A o U2A ICP: soggetti che integagiscono con la piattaforma T2S attraverso i CSD Le Payment Bank, ovvero i soggetti clienti delle Banche Centrali. È possibile distinguere due differenti tipologie di Payment Bank: Payment Bank DCP: soggetti che interagiscono direttamente con la piattaforma T2S per la componente cash in modalità A2A (DCP/ICP) o U2A ICP: soggetti che interagiscono con la piattaforma T2S attraverso le Banche Centrali 10 Network Service Provider (NSP) Comprendono i due VAN (Value Added Network) di T2S, ovvero “SIA/Colt” e “SWIFT” così come DL (Dedicated Link) che fornisce “CoreNet” Operatori del sistema RTGS connessi alla piattaforma T2S, come RTGS Operator ad esempio il “T2S Operator” Soggetto dell’ Eurosistema che supporta tutte le attività di T2S Operator produzione della nuova piattaforma T2S I successivi paragrafi e le corrispondenti tabelle riportano un elenco dei diversi attori coinvolti in ogni finestra di migrazione, con indicazione del ruolo con il quale ogni soggetto vi prende parte. Si specifica tuttavia che il contenuto potrebbe subire variazioni a seconda di quanto definito a livello di Eurosistema. Per informazioni di maggior dettaglio e per gli ultimi aggiornamenti circa la composizione ed i ruoli assunti dai diversi attori, si invita a fare riferimento alla documentazione disponibile nell’ apposita sezione di T2S sul sito della ECB (cfr. link di seguito): http://www.ecb.europa.eu/paym/t2s/progplan/html/index.en.html 3.3 Composizione della prima finestra SOGGETTO TIPOLOGIA COMMENTO CSD che opera solo come “Securities Clearstream Banking Maintaining SME CSD Entity” dei dati statici migrati alla piattaforma T2S CSD che opera solo come “Securities Euroclear Belgium Maintaining SME CSD Entity” dei dati statici migrati alla piattaforma T2S CSD che opera solo come “Securities Euroclear France Maintaining SME CSD Entity” dei dati statici migrati alla piattaforma T2S CSD che opera solo come “Securities Euroclear Netherlands Maintaining SME CSD Entity” dei dati statici migrati alla piattaforma T2S CSD che opera solo come “Securities Iberclear Maintaining SME CSD Entity” dei dati statici migrati alla piattaforma T2S LuxCSD CSD che opera solo come “Securities SME CSD 11 SOGGETTO TIPOLOGIA COMMENTO Maintaining Entity” dei dati statici migrati alla piattaforma T2S CSD che opera solo come “Securities VP Securities Maintaining SME CSD Entity” dei dati statici migrati alla piattaforma T2S CSD Bank of Greece in fase di migrazione a T2S CSD Depozitarul Central in Malta Stock Exchange fase di in fase di CSD Bank of Greece Bank Centrali ta'Malta Banca d'Italia in regolamento e delle relative attività a Migrazione completa del sistema di regolamento e delle relative attività a T2S fase di migrazione a T2S SIX SIS Migrazione completa del sistema di T2S migrazione a T2S CSD Monte Titoli in regolamento e delle relative attività a T2S migrazione a T2S CSD Migrazione completa del sistema di Migrazione completa del sistema di regolamento e delle relative attività a T2S fase di Migrazione del sistema di regolamento migrazione a T2S e EUR e delle relative attività a T2S CB in fase di migrazione Copertura totale dei quattro diversi ruoli a T2S delle Banche Centrali in T2S CB in fase di migrazione Copertura totale dei quattro diversi ruoli a T2S delle Banche Centrali in T2S CB in fase di migrazione Copertura totale dei quattro diversi ruoli a T2S delle Banche Centrali in T2S Copertura parziale dei quattro diversi Banca Nationala a Romaniei CB in fase di migrazione ruoli delle Banche Centrali in T2S. In a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi Banco de Portugal CB in fase di migrazione ruoli delle Banche Centrali in T2S. In a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi Deutsche Bundesbank CB in fase di migrazione ruoli delle Banche Centrali in T2S. In a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” 12 SOGGETTO TIPOLOGIA COMMENTO Copertura parziale dei quattro diversi NBB CB in fase di migrazione ruoli delle Banche Centrali in T2S. In a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi Banque de France CB in fase di migrazione ruoli delle Banche Centrali in T2S. In a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi De Nederlandsche Bank CB in fase di migrazione ruoli delle Banche Centrali in T2S. In a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi Banco de Espana CB in fase di migrazione ruoli delle Banche Centrali in T2S. In a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi Banque centrale Luxembourg du CB in fase di migrazione ruoli delle Banche Centrali in T2S. In a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi Oesterreichische CB in fase di migrazione ruoli delle Banche Centrali in T2S. In Nationalbank a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi Danmarks CB in fase di migrazione ruoli delle Banche Centrali in T2S. In Nationalbank a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi Suomen Pankki CB in fase di migrazione ruoli delle Banche Centrali in T2S. In a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi Banka Slovenije CB in fase di migrazione ruoli delle Banche Centrali in T2S. In a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Eesti Pank CB in fase di migrazione 13 Copertura parziale dei quattro diversi SOGGETTO TIPOLOGIA COMMENTO a T2S ruoli delle Banche Centrali in T2S. In particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi Lietuvos Respublikos CB in fase di migrazione ruoli delle Banche Centrali in T2S. In centriniu banku a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi Magyar Nemzeti Bank CB in fase di migrazione ruoli delle Banche Centrali in T2S. In a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” Copertura parziale dei quattro diversi Narodna banka Slovenska CB in fase di migrazione ruoli delle Banche Centrali in T2S. In a T2S particolare in qualità di: “System Entity” e “RTGS System Owner” 3.4 Composizione della seconda finestra SOGGETTO Euroclear Belgium Euroclear France Euroclear Netherlands Interbolsa NBB - SSS NBB TIPOLOGIA CSD in COMMENTO fase di migrazione a T2S CSD in in fase di in fase di in regolamento e delle relative attività a Migrazione completa del sistema di regolamento e delle relative attività a T2S fase di migrazione a T2S CSD Migrazione completa del sistema di T2S migrazione a T2S CSD regolamento e delle relative attività a T2S migrazione a T2S CSD Migrazione completa del sistema di Migrazione completa del sistema di regolamento e delle relative attività a T2S fase di migrazione a T2S Migrazione completa del sistema di regolamento e delle relative attività a T2S CB in fase di migrazione Copertura totale dei quattro diversi ruoli a T2S delle Banche Centrali in T2S 14 SOGGETTO Banque de France De Nederlandsche Bank Banco de Portugal Wave 1 3.5 TIPOLOGIA COMMENTO CB in fase di migrazione Copertura totale dei quattro diversi ruoli a T2S delle Banche Centrali in T2S CB in fase di migrazione Copertura totale dei quattro diversi ruoli a T2S delle Banche Centrali in T2S CB in fase di migrazione Copertura totale dei quattro diversi ruoli a T2S delle Banche Centrali in T2S CSD e CB già migrati nella prima CSD e CB finestra di migrazione Composizione della terza finestra SOGGETTO TIPOLOGIA Clearstream Banking CSD fase di migrazione a T2S CSD Keler Hungary in COMMENTO in LuxCSD in fase di OeKB in fase di VP Lux in regolamento e delle relative attività a Migrazione completa del sistema di regolamento e delle relative attività a T2S fase di migrazione a T2S CSD Migrazione completa del sistema di T2S migrazione a T2S CSD regolamento e delle relative attività a T2S migrazione a T2S CSD Migrazione completa del sistema di Migrazione completa del sistema di regolamento e delle relative attività a T2S fase di migrazione a T2S Migrazione completa del sistema di regolamento e delle relative attività a T2S Migrazione dei sistemi di regolamento CSD VP Securities in fase di migrazione a T2S EUR nonchè dei sistemi di regolamento DKK che si prevede migreranno nel 2018 CB in fase di migrazione Copertura totale dei quattro diversi ruoli a T2S delle Banche Centrali in T2S CB in fase di migrazione Copertura totale dei quattro diversi ruoli Luxembourg a T2S delle Banche Centrali in T2S Magyar Nemzeti Bank CB in fase di migrazione Copertura totale dei quattro diversi ruoli Deutsche Bundesbank Banque centrale du 15 SOGGETTO TIPOLOGIA COMMENTO a T2S delle Banche Centrali in T2S Oesterreichische CB in fase di migrazione Copertura totale dei quattro diversi ruoli Nationalbank a T2S delle Banche Centrali in T2S Wave 1-2 CSD e CB migrati a T2S 3.6 CSD e CB già migrati nelle prime due wave di migrazione Composizione della quarta finestra SOGGETTO TIPOLOGIA CSD CDCP Slovakia CSD Eesti CSD of Lithuania Euroclear Finland BNY Mellon CSD Banco de Espana Suomen Pankki Banka Slovenije di in CSD in fase di in fase di in fase di in fase di in Migrazione completa del sistema di regolamento e delle relative attività a Migrazione completa del sistema di regolamento e delle relative attività a Migrazione completa del sistema di regolamento e delle relative attività a T2S fase di migrazione a T2S CSD regolamento e delle relative attività a T2S migrazione a T2S CSD Migrazione completa del sistema di T2S migrazione a T2S CSD regolamento e delle relative attività a T2S migrazione a T2S CSD Migrazione completa del sistema di T2S migrazione a T2S Vaartpaberikeskus KDD Slovenia fase migrazione a T2S Iberclear AS in COMMENTO Migrazione completa del sistema di regolamento e delle relative attività a T2S fase di migrazione a T2S Migrazione completa del sistema di regolamento e delle relative attività a T2S CB in fase di migrazione Copertura totale dei quattro diversi ruoli a T2S delle Banche Centrali in T2S CB in fase di migrazione Copertura totale dei quattro diversi ruoli a T2S delle Banche Centrali in T2S CB in fase di migrazione Copertura totale dei quattro diversi ruoli a T2S delle Banche Centrali in T2S 16 CB in fase di migrazione Copertura totale dei quattro diversi ruoli a T2S delle Banche Centrali in T2S Lietuvos Respublikos CB in fase di migrazione Copertura totale dei quattro diversi ruoli centriniu banku a T2S delle Banche Centrali in T2S CB in fase di migrazione Copertura totale dei quattro diversi ruoli Slovenska a T2S delle Banche Centrali in T2S Wave 1-3 CSD e CB migrati a T2S Eesti Pank Narodna banka 17 CSD e CB già migrati nelle prime tre finestre di migrazione 4 PIANO DELLE ATTIVITA’ DI MIGRAZIONE La migrazione a T2S è suddivisa in più fasi: attività preparatorie: fra queste sono incluse, a puro titolo di esempio, la preparazione degli ambienti HW e SW, l’attivazione dei canali di comunicazione; premigrazione o migrazione dei dati statici: è finalizzata al caricamento, in ambiente di produzione, dei dati statici relativi a strumenti finanziari, partecipanti e conti titoli necessari al buon funzionamento del nuovo sistema di regolamento T2S. Si tratta di un vero e proprio passaggio in produzione dei suddetti dati statici; collaudo delle attività di migrazione; collaudo delle attività ordinarie di custody e di regolamento a seguito della simulazione del weekend di migrazione; fine settimana di migrazione o migrazione dei dati dinamici (operazioni): questa attività rappresenta il momento ove si completa il il vero e proprio passaggio a T2S ed avviene durante il cosiddetto week end di migrazione. Al fine di controllare il corretto avanzamento delle attività di tutte le parti coinvolte, nonché garantirne il giusto allineamento, sono stati definiti alcuni Synchronisation Points (SP) che si applicano alle varie fasi del progetto. A seconda della natura degli stessi, l’ ECB distingue: synchronisation points bilaterali: coinvolgono solo un CSD/CB e l’ Eurosistema; synchronisation points multilaterali: coinvolgono più attori, inclusi i clienti dei rispettivi CSD/CB. Al fine di garantire il successo del processo di migrazione nel suo complesso, Monte Titoli definisce, oltre ai punti di sincronizzazione stabiliti a livello di Eurosistema, momenti addizionali di allineamento con i propri clienti [4.1]. 4.1 Attività e Synchronisation Point Sono qui elencate le principali attività e S.P. che prevedono, direttamente o indirettamente, il coinvolgimento dei clienti in funzione della migrazione a T2S. Il seguente piano di migrazione potrebbe subire variazioni ed essere sottoposto a successive ridefinizioni sulla base della pianificazione stabilita dall’Eurosistema unitamente a tutti gli altri attori partecipanti alla prima finestra di migrazione a T2S. 18 Monte Titoli provvederà a dare tempestiva e circostanziata informativa di queste eventuali variazioni tramite gli usuali canali di comunicazione con i clienti. Si noti altresì che alcune delle attività elencate sono di pertinenza dei soli clienti DCP e pertanto possono essere ignorate dai clienti ICP. N DESCRIZIONE S.P. ATT. SOGGETTO SCADENZA X DCP 24/02/2014 X ECB Marzo 2014 X MT X MT X DCP 31/10/2014 X DCP 14/11/2014 Binding declaration per aderire come DCP 1 I clienti devono comunicare a Monte Titoli la loro volontà (dichiarazione vincolante) di partecipare come DCP alla piattaforma T2S Distribuzione casi di test per la certificazione dei DCP 2 L’ Eurosistema distribuisce ai partecipanti diretti alla piattaforma T2S la lista dei casi di test per la certificazione dei DCP Distribuzione di contratti e membership form – draft version 3 Data prevista per la pubblicazione della 15/05/2014 bozza della documentazione contrattuale ai clienti da parte di Monte Titoli Distribuzione casi di test per l’autorizzazione 4 Monte Titoli distribuisce ai partecipanti la lista dei casi di test per il processo di Settembre 2014 autorizzazione Registrazione presso i NSP Ogni partecipante DCP deve completare 5 l’apposita registrazione presso i NSP attraverso i rispettivi CSD/CB per l’ambiente di collaudo Richiesta 6 assegnazione dei certificati/token Per accedere all’ ambiente di collaudo in funzione dell’inizio dei test di connettività 7 Distribuzione di contratti, istruzioni e membership form 19 N DESCRIZIONE S.P. Data prevista per la pubblicazione finale del ATT. SOGGETTO SCADENZA X MT 15/12/2014 nuovo set contrattuale ai clienti da parte di Monte Titoli Test di connettività I DCP sono tenuti ad eseguire i suddetti test Dal per connettersi all’ambiente di collaudo T2S 8 di Community. X Gli ICP sono coinvolti negli opportuni test di connettività con MT direttamente Clienti 03/12/2014 (DCP/ICP) al 27/02/2015 in ambiente di collaudo T1. Configurazione dei DCA e CMB Le payment bank che offrono ai propri 9 clienti servizi di regolamento del contante e/o client collateralisation devono X X PB Entro 20/02/2015 opportunamente autorizzare i clienti stessi all’ utilizzo dei propri DCA (creazione CMB) Primo Dress Rehearsal di pre migrazione Esecuzione del primo Dress Rehearsal full 10 Dal di pre migrazione su dati statici relativi a X titoli e partecipanti in ambiente di collaudo di Community, che corrisponde MT all’ 23/02/2015 al 27/02/2015 ambiente di collaudo T1 di Monte Titoli Primo Dress rehearsal di pre migrazione: debriefing I clienti sono invitati ad inviare a Monte Titoli 11 i loro feedback relativi al risultato del primo dress rehearsal nonché a riportare eventuali MT X X DCP problemi o criticità relativi ai dati statici Dal 03/03/2015 Al 07/03/2015 migrati in T2S e direttamente visibili nella nuova piattaforma Processo di registrazione presso i NSP Ogni partecipante DCP che prende parte ad 12 una particolare wave di migrazione deve completare l’ apposita registrazione presso i X DCP 27/02/2015 X DCP 02/03/2015 NSP attraverso i rispettivi CSD/CB per l’ambiente di produzione 13 Richiesta dei certificati/token per 20 N DESCRIZIONE S.P. ATT. SOGGETTO X DCP SCADENZA accedere all’ ambiente di produzione 14 Test di certificazione per i DCP Inizio del Community testing 15 partecipanti sono 2015 CSD I CSD, le Banche Centrali ed i rispettivi soggetti Entro marzo chiamati X a prendere parte al Community Testing CB Clienti 02/03/2015 (DCP/ICP) Test di connettività per la prima finestra di migrazione I DCP sono tenuti ad eseguire i suddetti test 16 Clienti per connettersi all’ ambiente di produzione X di T2S. (DCP/ICP) Gli ICP sono coinvolti negli opportuni test di connettività con MT direttamente Dal 20/03/2015 al 03/04/2015 in ambiente di produzione (MT T1) Termine per la conferma dei dati di membership per la produzione 17 Scadenza per la conferma a Monte Titoli dei dati di membership dei clienti per X l’ Clienti (DCP/ICP) 20/03/2015 ambiente di produzione Dress Rehearsal del MWE I clienti sono chiamati a partecipare per le attività di loro competenza e ad acquisire i risultati derivanti 18 all’esecuzione del migrazione delle e MT dalle prove relative fine settimana relative attività di X di regolamento (in ambiente di Community di Dal 17/04/2015 Clienti al (DCP/ICP) 20/04/2015 MT Dal T2S e nel corrispondente ambiente di collaudo T1 di MT) MWE Dress Rehearsal: debriefing I clienti sono invitati a riportare a MT l’esito 19 della simulazione del weekend di migrazione nonchè particolari criticità e X X rischi legati anche alle loro attività “interne” 23/04/2015 Clienti Al (DCP/ICP) 24/04/2015 di migrazione 20 Go-live dei dati statici nell’ ambiente di produzione di T2S e nei sistemi legacy di 21 X X MT Dal 27/04/2015 N DESCRIZIONE S.P. ATT. SOGGETTO MT SCADENZA al Caricamento di tutti i dati statici e delle 04/05/15 relative applicazioni nel nuovo ambiente di produzione T2S e nei nuovi sistemi legacy di Monte Titoli Finestra di contingency per il caricamento dei dati statici in ambiente Dal di produzione di T2S 21 Periodo di buffer nel caso in cui dovessero X X MT emergere criticità legate al processo di 05/05/2015 al 11/05/15 caricamento e migrazione dei dati statici in T2S 22 Dichiarazione di corretta esecuzione dei test di certificazione X X ECB DCP 15/05/2015 Dichiarazione di corretta esecuzione dei 23 test di autorizzazione X I clienti dichiarano a Monte Titoli la corretta Clienti (ICP/DCP) 15/05/2015 esecuzione dei test di autorizzazione MWE dress rehearsal 1 Prima esecuzione delle prove generali del 24 MT fine settimana di migrazione con tutti i dati X di produzione. Saranno protagonist tutti i soggetti coinvolti Dal 15/05/2015 Clienti al (DCP/ICP) 18/05/2015 nella prima wave di migrazione a T2S Business day testing 1 Durante il business day testing si richiedere ai 25 clienti di immettere transazioni Dal ed operare esattamente come se fossero in X Community produzione. Queste prove si realizzano 18/05/2015 al 20/05/2015 nell’ambiente di collaudo T1 Monte Titoli collegato all’ambiente T2S di Community MWE Dress Rehearsal 1: debriefing I clienti sono invitati ad inviare a MT i loro 26 feedback relativi al risultato del Dress Rehearsal ed a riportare eventuali problemi o criticità emerse durante l’esecuzione del Dress Rehearsal stesso 22 MT X X Dal 21/05/2015 Clienti al (ICP/DCP) 22/05/2015 N DESCRIZIONE S.P. ATT. SOGGETTO SCADENZA MWE Dress rehearsal 2 Seconda esecuzione delle prove generali 27 MT del fine settimana di migrazione con tutti i dati di produzione. Clienti Saranno protagonisti tutti i soggetti coinvolti (DCP/ICP) nella prima wave di migrazione a T2S Business day testing 2 ai clienti di immettere transazioni 29/05/2015 al 01/06/2015 Dal Durante il business day testing si richiedere 28 Dal ed X Community operare esattamente come se fossero in 01/06/2015 al 03/06/2015 produzione MWE Dress rehearsal 2: debriefing I clienti sono invitati ad inviare a Monte Titoli i loro feedback relativi al risultato del MT secondo Dress rRehearsal ed al colloquio 29 con la nuova piattaforma T2S nonché riportare eventuali problemi o criticità X X (ICP/DCP) emerse. L’esito positivo del suddetto Clienti Dal 04/06/2015 al 05/06/2015 Dress Rehearsal potrebbe rappresentare un esito positivo ad uno degli entry criteria a T2S. Dichiarazione di corretta esecuzione del Dress Rehearsal del MWE 30 Clienti I clienti sono chiamati a dichiarare la X X corretta esecuzione del Dress Rehearsal (ICP/DCP) Entro 06/06/2015 del fine settimana di migrazione Migrazione dall’ ambiente di collaudo legacy PI all’ambiente T2 di MT I clienti, ove applicabile, sono chiamati a migrare i loro ambienti di collaudo di preproduzione 31 disconnettendoli dal vecchi ambiente di collauto PI di Monte Titoli ed a connettere gli stessi al nuovo ambiente di collaudo T2 di MT (pre produzione). In aggiunta i DCP devono connettere i loro sistemi legacy direttamente all’ ambiente di pre-produzione di T2S. 23 Clienti X 15/06/2015 (DCP/ICP) N DESCRIZIONE S.P. ATT. SOGGETTO Dal T2S GO-LIVE 32 SCADENZA ESECUZIONE DEL FINE SETTIMANA DI X MIGRAZIONE A T2S X TUTTI 19/06/2015 al 22/06/2015 Il passaggio in produzione a T2S (Migration Week End - MWE), di cui all’ultimo elemento della tabella precedente e noto anche come processo di migrazione dei dati dinamici, è descritto in dettaglio nel documento “Migration Weekend Playbook”. 24 5 MIGRAZIONE DEI DATI STATICI 5.1 Introduzione alla migrazione dei dati statici Con migrazione dei dati statici si intende la migrazione dei dati di configurazione dei partecipanti e degli strumenti finanziari presenti negli attuali sistemi legacy di Monte Titoli verso i nuovi sistemi legacy di produzione e versoT2S. Monte Titoli, in linea col piano strategico di migrazione alla piattaforma T2S definito a livello di Eurosistema, caricherà i dati statici a partire da circa un mese e mezzo prima (27 aprile 2015) rispetto alla data di avvio di T2S (22 giugno 2015). Successivamente al caricamento tali dati statici saranno gestiti secondo criteri BAU fino all’avvio di T2S. Nello specifico, per ciò che concerne i dati statici dei partecipanti si applicano i criteri descritti al paragrafo 5.6, mente per i nuovi strumenti finanziari sarà Monte Titoli ad inserirli parallelamente sia nel vecchio ambiente che nel nuovo sistema. Le ragioni per le quali Monte Titoli procederà al caricamento dei dati statici a partire dal 27 aprile 2015 risultano essere le seguenti: Evitare rifiuti da parte della piattaforma T2S relativamente a Settlement Instruction con data regolamento antecedente, durante il weekend di migrazione (fail); Minimizzare il rischio intrinseco al processo di migrazione anche attraverso una gestione separata delle attività da svolgersi nel periodo di premigrazione a T2S; Dedicare un tempo adeguato all’attività di caricamento dei dati statici fondamentali per il corretto funzionamento della nuova piattaforma di regolamento e dei servizi di Monte Titoli. Nel lasso temporale che precede il weekend di migrazione a T2S, Monte Titoli ed i suoi clienti sono direttamente coinvolti in una serie di specifiche attività preparatorie per la definizione del nuovo insieme di dati necessari per la configurazione dei clienti in T2S e per la migrazione dei dati statici (informazioni riguardanti i partecipanti, i conti titoli nonché gli elementi di configurazione ad essi correlati) che popolano gli attuali sistemi legacy. In sintesi, il processo relativo alla migrazione dei dati statici si svolge secondo i seguenti passi: 1. Consegna ai clienti dei dati necessari per la configurazione in T2S 2. Conferma da parte dei clienti (e/o settlement agent/agenti pagatori) dei dati di configurazione forniti da Monte Titoli 3. Trasferimento dei dati ufficiali di configurazione al sistema di test 4. Pre-Migration Dress Rehearsal 25 5. Inizio Frozen Period 6. Go – live dei dati statici in T2S 7. Finestra di contingency per il caricamento dei dati statici Si fornisce di seguito una rappresentazione grafica dei principali step caratterizzanti il processo di migrazione dei dati statici in T2S, che saranno oggetto di approfondimento nei successivi paragrafi. 5.2 Consegna ai clienti dei dati necessari per la configurazione in T2S In data 15 dicembre 2014, Monte Titoli fornirà ai propri clienti una fotografia dei dati di configurazione presenti negli attuali sistemi di produzione, adattati alla luce delle informazioni necessarie per T2S. Questi dati, fino ad oggi raccolti mediante Bit-Club e/o gli appositi moduli di Partecipazione quali ad esempio la Scheda Dati Operativi, saranno disponibili e accessibili mediante un’interfaccia web che consente ai clienti di prenderne visione ed eventualmente modificarli oppure inserirne di nuovi. L’accesso a questo strumento avverrà tramite le credenziali di accesso a MT-X già in possesso dei clienti. I clienti che ne fossero sprovvisti, sono invitati a farne richiesta direttamente a Monte 26 Titoli indirizzando la richiesta all’ufficio Client Support ([email protected]) che sarà in grado di fornire anche ulteriori informazioni in merito all’utilizzo dello strumento. Si ricorda che tale strumento sarà poi utilizzato anche a regime, in sostituzione dell’attuale BitClub e della Scheda Dati Operativi, per la gestione dei dati di configurazione dei vari servizi. A tempo debito ne sarà, altresì, reso disponibile un manuale d’uso. Qualora il cliente dovesse richiedere una variazione dei dati di configurazione a valere sull’attuale sistema di produzione, e dunque con le attuali modalità, a partire dal 15/12/2014 e fino al termine ultimo a disposizione per le modifiche del 20/03/2015, sarà sua cura riportarla anche nel nuovo ambiente di produzione mediante lo strumento web, affinchè venga presa in carico anche al fine della migrazione a T2S. Affinché il processo di migrazione dei dati statici in T2S possa avvenire con successo, permettendone dunque il go-live ed il caricamento nei nuovi sistemi legacy di Monte Titoli ed in T2S, Monte Titoli dovrà presentare in maniera analitica ai clienti l’insieme di informazioni necessarie per la configurazione degli stessi in T2S. Infatti, l’introduzione di T2S richiede elementi informativi differenti e talvolta aggiuntivi rispetto a quelli attualmente in essere nei sistemi di Monte Titoli. Come illustrato nel seguente schema, Monte Titoli procede alla migrazione dei dati in base all’origine dell’elemento informativo. In particolare, l’insieme di informazioni attualmente esistenti nei sistemi legacy di Monte Titoli verrà migrato sulla base di specifiche regole di mappatura che definiscono le modalità di traduzione delle informazioni dall’attuale sistema Monte Titoli a T2S. 27 Esistenti nei sistemi Monte Titoli Identificazione regole di mappatura Elementi informativi Obbligatoriamente comunicate dai clienti Nuove informazioni Richieste per le caratteristiche di T2S Assegnate di default da Monte Titoli Tale approccio è volto a garantire maggiore efficienza al processo di preparazione alla migrazione in quanto limita l’intervento dei clienti alle eventuali modifiche dei soli valori di default assegnati da Monte Titoli e/o all’inserimento dei soli dati nuovi richiesti alla luce delle caratteristiche e peculiarità di T2S. In questo secondo caso, qualora non sia possibile l’assegnazione di valori predeterminati, è indispensabile che siano i clienti stessi a provvedere ad una puntuale comunicazione degli elementi informativi necessari per la loro configurazione. Le informazioni attualmente non presenti nei sistemi legacy di Monte Titoli, e richieste da T2S, risultano essere le seguenti: Coordinate per il regolamento del contante di operazioni DVP e/o per l’insieme di operazioni di autocollateral da associare al conto titoli Coordinate per i pagamenti relativi ai Titoli di Stato Coordinate per pagamenti relativi alle Corporate Action da effettuarsi in T2S Più in dettaglio, i dati presentati tramite l’interfaccia web sono relativi alla configurazione dei seguenti servizi: Servizi di pre-settlement Servizio di regolamento Servizio di regolamento estero (DVP Cross Border) Servizio di gestione accentrata (emittenti ed intermediari) 28 Le configurazioni relative ai servizi FIS, RCC saranno proposte nello strumento web per completezza di informazione, nonostante non si preveda subiscano alcuna variazione in quanto non direttamente impattate dalla migrazione alla nuova piattaforma T2S. 5.2.1 Dati dei Servizi di pre-settlement Per ciò che concerne le configurazioni relative al servizio di pre-settlement (X-TRM), troverete a seguire tutti gli elementi informativi di dettaglio inerenti a: 1. Associazione Negoziatore/Liquidatore, con l’indicazione del liquidatore di default e relativi conti di regolamento, di default e non (LIQDEF); 2. Associazione Negoziatore/Liquidatore relativamente sia ai mercati garantiti sia non garantiti come eccezione rispetto alla (LIQDEF) in base a Provenienza e Mercato di Negoziazione (LIQNEG); 3. Associazione Negoziatore/General Clearing Member/Liquidatore per i soli mercati garantiti (CCPNEG). Nello strumento web messo a disposizione, i dati di cui sopra sono presentati dal punto di vista rispettivamente del: soggetto negoziatore soggetto liquidatore Il soggetto liquidatore avrà quindi la visibilità di tutte le configurazioni dei partecipanti (negoziatori) dai quali è stato designato come liquidatore. Sono inoltre fornite, pur non essendo impattate da T2S, anche le configurazioni per il regolamento delle operazioni provenienti dal mercato EuroTLX, Hi-MTF e EuroMOT che include anche il segmento ExtraMot sui sistemi esteri Euroclear e Clearstream (ICSD). Con particolare riferimento all’Associazione Negoziatore/Liquidatore di cui al precedente elenco, si specifica che con T2S l’associazione attualmente esistente tra soggetto negoziatore e soggetto liquidatore, oggi comprensiva dei soli soggetti che sono indiretti alla liquidazione, comprende anche la configurazione dei soggetti che partecipano alla liquidazione (associazione con se stessi). Per “liquidatore di default” si intende l’associazione negoziatore/liquidatore che il sistema di presettlement adotta in assenza di indicazioni in merito al liquidatore e/o al conto titoli da parte del negoziatore al momento di istruire un’operazione. 29 Poichè oggi in X-TRM sono quasi sempre presenti per uno stesso soggetto due differenti configurazioni, una relativa alla liquidazione lorda e un’altra relativa alla netta, potrebbero verificarsi situazioni, anche se rare, nelle quali le due differiscono. In presenza di tale scenario, Monte Titoli le comunica entrambe attraverso lo strumento web dedicato ed il cliente è invitato ad indicare quale delle due configurazioni deve essere utilizzata in T2S. In particolare, si chiede che il cliente: 1. inserisca la configurazione prescelta impostando come sistema di regolamento il valore “T2S”; 2. chiuda le due configurazioni per i due sistemi obsoleti, impostandone la data di chiusura al 19 giugno 2015. Infine, tra gli elementi di configurazione forniti ai clienti, Monte Titoli garantisce piena visibilità anche delle seguenti informazioni: elenco delle funzioni sottoscritte e relative modalità di comunicazione; elenco dei soggetti ai quali è stato conferito mandato operativo per X-TRM, con indicazione di dettaglio delle funzioni delegate nonché del relativo profilo abilitato; i soggetti deleganti hanno visibilità di tutti i soggetti ai quali hanno conferito mandato per una data funzione e per ciascuno dei codici CED a loro assegnati. Viceversa i soggetti assegnatari potranno vedere tutti i mandati ricevuti per ciascuna funzione e per ciascun CED assegnatario; elenco dei soggetti che hanno conferito PoA (Power of Attorney) contrattuale per XTRM. Il conferimento del PoA contrattuale impone, direttamente o indirettamente, una doppia conferma anche da parte dei soggetti ai quali è stata conferito il PoA in relazione ai dati di configurazione forniti da Monte Titoli. Infatti, qualora non sia stata conferito PoA contrattuale, i dati di membership saranno acquisiti e considerati validi se inviati dal cliente stesso. Nel caso in cui sia stata conferito PoA contrattuale, i soggetti ai quali è stato conferito PoA sono tenuti a confermare i dati di membership necessari per le relative configurazioni in T2S. 5.2.2 Dati dei Servizi di Liquidazione I clienti sono tenuti a fornire per ciascun conto titoli detenuto le coordinate del conto contante T2S (DCA) associato, al fine di consentire il regolamento DVP delle operazioni. 30 Il cliente deve indicare se intende utilizzare o meno la funzionalità di auto-collateralizzazione valorizzando l’apposito indicatore. Analogamente il cliente indica, valorizzando apposito indicatore, se le operazioni istruite a valere sul dato conto, in assenza di specifica indicazione all’interno della stessa istruzione, debbano essere considerate come “Hold” o “Released” dal sistema (cfr. paragrafi “Struttura dei conti per il Servizio di gestione accentrata” e “Coordinate per il regolamento contante di operazioni DVP”). Si noti che, dal momento che la definizione dei conti DCA è di competenza delle Banche Centrali, le coordinate del conto DCA non sono note a priori a Monte Titoli e pertanto devono essere fornite a Monte Titoli direttamente dal cliente. Le suddette configurazioni si riferiscono al servizio di Liquidazione presso la piattaforma T2S. Il regolamento presso gli ICSD delle operazioni provenienti da mercato, quali ad esempio EuroMOT e le corrispondenti configurazioni non subiscono variazioni rispetto a quelle attualmente registrate in Bit-Club. 5.2.3 Dati dei Servizi di regolamento estero (DVP Cross-Border) Il servizio di regolamento estero, come specificato nelle corrispondenti “Istruzioni del Servizio”, copre i trasferimenti di strumenti finanziari emessi dal CSD estero fra un partecipante Monte Titoli ed un partecipante ad un sistema di regolamento esterno a T2S (a riguardo si invita a consultare il documento nell’ apposita sezione documentale: http://montetitoli.it/area- download/normativa/istrregesteromaggio2012.pdf). Per ciò che concerne tale servizio non si evidenziano, al momento, variazioni e necessità di informazioni aggiuntive e specifiche per T2S rispetto a quelle attualmente in essere in Bit-Club. Si specifica che, tuttavia, l’intero set di informazioni relative al servizio di regolamento estero saranno anch’esse disponibili e visualizzabili attraverso il web tool. 5.2.4 Dati dei Servizi di gestione accentrata emittenti ed intermediari Le configurazioni relative al servizio di gestione accentrata riguardano la struttura dei conti dei partecipanti Monte Titoli in T2S (cfr. tabella 4.7). Con riferimento a quest’ultima, si specifica che tutti i conti titoli validi alla data di migrazione dei dati statici, indipendentemente dal fatto che abbiano saldo o meno e dall’eventuale esistenza di blocchi operativi, saranno definiti e configurati in T2S. 31 Saranno inoltre fornite indicazioni in merito ai mandati operativi in essere ed ai canali di comunicazione utilizzati dai clienti. In corrispondenza di ciascun conto titoli, sia esso intermediario od emittente, sarà indicata la banca pagatrice e le relative coordinate di pagamento per ciascuna tipologia di operazione, di cui alla tabella sottostante. Si specifica che lo schema proposto di seguito gestisce anche la specifica fattispecie di banca pagatrice per emittente utilizzata successivamente in fase di assegnazione dell’incarico da parte del soggetto emittente: In T2S, Monte Titoli offrirà ai propri clienti la possibilità di indicare il sistema di pagamento sul quale operare, T2S ovvero T2, per ciascuna tipologia di operazione. A seconda delle diverse esigenze di business, i clienti avranno infatti la facoltà di scegliere se configurare i pagamenti relativi alle corporate action in T2 o T2S, fatta eccezione per: pagamenti relativi ai “Titoli di Stato”, effettuati unicamente nel sistema di pagamento T2S; “Pagamento Corrispettivi RCC”, ove è previsto il pagamento solo in T2, in linea con quanto previsto dalle prassi di Harmonization Custody. In ogni caso Monte Titoli riporterà le configurazioni in vigore in T2 al momento della migrazione a T2S per tutte le tipologie di pagamento diverse dalle operazioni scaturite dal pagamento su Titoli di Stato. 32 Ne consegue che il cliente dovrà fornire per tempo a Monte Titoli, in corrispondenza di ciascuno dei propri conti titoli, le coordinate relative al conto cash ad esso associato, in particolare: Codice BIC della Banca Centrale in cui è detenuto il conto cash; Codice BIC (Party BIC) della Payment Bank a cui è intestato il conto cash; Identificativo del DCA; Identificativo del Credit Memorandum Balance (CMB) assegnato al/i conto/i titoli per il regolamento del contante. Per informazioni di maggior dettaglio circa il contenuto informativo dei principali dati di configurazione, si faccia riferimento all’allegato presente al punto 9.8 (Coordinate per pagamento contante operazioni DVP). 5.3 Conferma da parte dei clienti dei dati di configurazione forniti da Monte Titoli Nel lasso temporale che va dal 15 dicembre 2014, data di consegna ai clienti dei dati necessari per la configurazione dei clienti, al 20 marzo 2015, i clienti sono tenuti a: 1 prendere visione degli elementi di configurazione di cui al capitolo 5.2; 2 variare, se del caso, gli elementi di configurazione di cui al punto 1; 3 chiudere, se del caso, gli elementi di configurazione ritenuti non più necessari in T2S; 4 inserire, se del caso, gli elementi di configurazione da utilizzare dal momento della partenza di T2S; 5 accettare eventuali incarichi di liquidatore e/o agente pagatore. Tali attività sono necessarie al fine di predisporre e confermare la correttezza dei dati di configurazione che saranno successivamente migrati da Monte Titoli a T2S come dati di produzione. In particolare, in tale fase il cliente è tenuto a prendere attenta visione del set di informazioni fornitegli e valutarne la correttezza/esaustività nonché fornire puntuale conferma degli elementi di configurazione condivisi. Qualora il cliente abbia demandato parte della sua operatività a soggetti terzi, quali soggetti pagatori piuttosto che settlement agent, anche questi ultimi sono chiamati ad intervenire e confermare/modificare i dati in relazione ai rispettivi ruoli assunti. Si specifica che, nella situazione in cui il cliente o settlement agent/soggetto pagatore non facciano pervenire, entro le scadenze previste, alcuna comunicazione di variazione o 33 accettazione rispetto alle informazioni di configurazione a loro fornite, Monte Titoli assumerà come validi, qualora esistenti, i valori di default assegnati e precedentemente comunicati. Per ciò che concerne tutti gli elementi di configurazione “nuovi” poiché caratteristici di T2S e non attualmente presenti nei sistemi legacy di Monte Titoli, i clienti sono obbligatoriamente tenuti a darne comunicazione. Data la criticità di questi elementi informativi, qualora il cliente non dovesse comunicarli in tempo utile per la migrazione, Monte Titoli applicherà le seguenti configurazioni di default: Coordinate per pagamenti di Corporate Action: Monte Titoli assume valido il set di informazioni definito nell’ ambito del progetto Harmonisation Custody, ovvero le coordinate T2 in essere nel momento della migrazione; Coordinate per pagamento su Titoli di Stato: con riferimento all’obbligatorietà di questo dato, per il pagamento in T2S, qualora i clienti abbiano fornito le informazioni riguardo le coordinate per il regolamento contante per operazioni DVP e per l’insieme di operazioni di autocollateral in associazione al conto titoli ma non le coordinate per il pagamento di proventi relativi ai Titoli di Stato, si assume per queste ultime il medesimo valore comunicato per le coordinate DVP; Coordinate per il regolamento contante per operazioni DVP e per l’insieme di operazioni di autocollateral in associazione al conto titoli: con riferimento all’obbligatorietà di questo dato, qualora i clienti abbiano fornito informazioni relativamente alle coordinate per il pagamento su Titoli di Stato, ma non le coordinate per il pagamento di operazioni DVP, si assume per queste ultime il valore comunicato per le coordinate relative ai pagamenti sui Titoli di Stato; Coordinate per il regolamento contante per operazioni DVP e per l’insieme di operazioni di autocollateral in associazione al conto titoli e coordinate per pagamenti relativi ai Titoli di Stato. ATTENZIONE: nel caso in cui dette coordinate non dovessero essere comunicate dal cliente, lo stesso si troverà nell' impossibilità di regolare operazioni DVP e/o di effettuare operazioni di autocollateral e non potrà ricevere i proventi derivanti da pagamenti effettuati su Titoli di Stato. In questo caso si avranno inoltre i seguenti effetti: o durante il weekend di migrazione tutte le istruzioni DVP oggetto di migrazione che fanno riferimento ad un conto titoli senza alcuna associazione ad uno o più 34 conti contante DCA saranno automaticamente respinte dalla nuova piattaforma T2S e pertanto risulteranno non migrate. Queste operazioni dovranno essere nuovamente istruite dai clienti stessi come operazioni FoP fino alla comunicazione a Monte Titoli di una valida e corretta coordinata contante. o l'ammontare dovuto al cliente relativamente al pagamento su Titoli di Stato rimarrà sul conto contante di Monte Titoli fino a quando il cliente stesso non provvederà a comunicare a Monte Titoli le informazioni relative alle coordinate per i pagamenti su Titoli di Stato. Eventuali operazioni di pagamento effettuate da Monte Titoli in via amministrativa saranno addebitate al cliente secondo le tariffe vigenti al momento. 5.4 Trasferimento dei dati ufficiali di configurazione al sistema di test In data 20 febbraio 2015 Monte Titoli esporterà i dati ufficiali di configurazione opportunamente confermati o impostati dai clienti (e/o settlement agent/soggetto pagatore) mediante la piattaforma web per le attività di membership e li traferirà nel sistema di collaudo per poter effettuare le prove generali del processo di migrazione dei dati statici (Pre-Migration Dress Rehersal). I clienti che hanno una cardinalità di conti elevata potranno limitarsi ad inserire nello strumento web di configurazione fino alla data del 19 febbraio 2015 le principali casistiche di gestione; non è necessario quindi inserire tutti i dati di produzione. 5.5 Pre-Migration Dress Rehearsal In data 23 febbraio 2015, Monte Titoli eseguirà una prova di Dress Rehearsal nell’ambiente di collaudo di Community sull’insieme di dati statici opportunamente confermati/modificati dal cliente e/o settlement agent/soggetto pagatore e prelevati dall’ambiente di produzione. Si specifica che l’esecuzione del Pre-Migration Dress Rehearsal non richiede alcuna partecipazione attiva dei clienti ma sarà eseguito unicamente da Monte Titoli. La corretta esecuzione del test di Pre-Migration Dress Rehearsal rappresenta un pre requisito per Monte Titoli per l’esecuzione del test di Migration Weekend Dress Rehearsal. Lo strumento di configurazione dei dati statici via web sarà a questo punto disponibile anche in ambiente di collaudo e consentirà ai clienti di impostare configurazioni per eventuali test che potranno poi essere riportate nell’ambiente di produzione. 35 Immediatamente dopo la conclusione del dress rehearsal di pre-migrazione, dal 3 marzo 2015 al 7 marzo 2015, Monte Titoli prevede un momento di debriefing con i propri partecipanti, con l’obiettivo di valutare l’ output del test nonché analizzare potenziali criticità e problematiche emerse. 5.6 Frozen Period La scadenza del 20 marzo 2015 costituisce per i clienti il termine ultimo per l’aggiornamento dei dati di configurazione che saranno utilizzati per l’effettiva migrazione a T2S. Coerentemente con quanto descritto in precedenza, a partire dal successivo 21 marzo 2015, Monte Titoli non accetterà più alcuna modifica alle configurazioni che saranno utilizzate per il caricamento iniziale nell’ambiente di produzione. Si noti che tali limitazioni si applicano a tutti i servizi erogati da Monte Titoli con particolare riferimento ai dati che afferiscono direttamente al nuovo sistema T2S. Dal 21 marzo 2015 al 27 aprile 2015 Monte Titoli verificherà la consistenza dei dati al fine di garantire il successo della migrazione degli stessi e del successivo weekend di migrazione. Nell’evenienza di operazioni societarie quali ad esempio le fusioni, è bene precisare che queste costituiscono anche in condizioni ordinarie operazioni che richiedono un certo tempo e un’adeguata analisi per poter essere completate con successo. A maggior ragione se previste in prossimità di una migrazione epocale come quella qui descritta alla piattaforma T2S debbono essere considerate e pianificate con maggior anticipo e maggior cura e non possono essere considerate come operazioni BAU. Eventuali nuovi emittenti di strumenti finanziari che avessero esigenza di registrarsi presso Monte Titoli perché intenzionati ad emettere nuovi strumenti in questo “frozen period” sono invitati a completeare le pratiche di registrazione in tempo utile ovvero prima del 21 marzo al fine di ridurre al minimo gestioni eccezionali che potrebbero introdurre problemi durante la fase di migrazione in quanto appunto situazioni gestite in modo non ordinario e quindi non collaudabili. Si specifica che non è previsto alcun allineamento automatico fra gli ambienti da parte di Monte Titoli, ma gli stessi devono essere apportati direttamente dal cliente secondo criteri differenti in relazione all’esigenza di voler alimentare l’ambiente di test piuttosto che di produzione, o entrambi. Alla luce di quanto detto, si possono verificare i seguenti scenari: 36 Caso 1: variazione apportata a cura del cliente in doppio, sia in ambiente di produzione che di test; Caso 2: variazione apportata dal cliente solo in ambiente di test. In tal caso gli elementi di configurazione inseriti non saranno presenti in ambiente di produzione, ovvero non saranno migrati a T2S e nei nuovi sistemi anagrafici di Monte Titoli. Il cliente potrà, quindi, fruire della variaizone apportata esclusivamente per finalità di collaudo; Caso 3: variazione apportata solo in ambiente di produzione. In tal caso la configurazione inserita sarà quindi migrata a T2S e nei nuovi sistemi legacy di Monte Titoli. Eventuali variazioni alle configurazioni richieste nei vecchi ambienti legacy di Monte Titoli, se ritenute necessarie anche per T2S, dovranno essere riportate a carico del cliente in ambiente di produzione e/o di collaudo a seconda delle esigenze sopra illustrate. 5.7 Go – live dei dati statici in T2S Durante la fase di pre-migrazione, l’ECB richiede che tutti i dati statici siano caricati nell’ambiente di produzione T2S e nei propri sistemi legacy e successivamente gestiti/alimentati secondo criteri BAU. Alla luce del piano di migrazione di Monte Titoli alla piattaforma T2S, il go-live dei dati statici avrà luogo a partire dal 27 aprile 2015 per un periodo di circa cinque giorni lavorativi. A partire da tale data, tutti i dati statici di Monte Titoli saranno presenti nel nuovo ambiente di produzione di T2S così come nei nuovi sistemi legacy di Monte Titoli. 5.8 Finestra di contingency per il caricamento dei dati statici Il periodo che va dal 5 all’ 11 maggio 2015 sarà utilizzato da Monte Titoli per completare le attività di migrazione dei dati statici, nel caso in cui le stesse dovessero prolungarsi a causa di situazioni impreviste non individuate nelle precedenti fasi di collaudo. 37 6 VARIAZIONI ALLE MODALITA’ DI PARTECIPAZIONE AI SERVIZI DI MONTE TITOLI Per consentire ai clienti di adottare le modalità di partecipazione che meglio si confanno alle specifiche esigenze di business della nuova piattaforma di regolamento T2S ed al contempo contenere i rischi operativi legati al processo di migrazione stesso, andiamo ora ad illustrare le variazione delle modalità di partecipazione ai servizi consentite da Monte Titoli all’atto della partenza della nuova piattaforma (Migration Week End). Qualora il cliente sia interessato a modificare le proprie modalità di partecipazione ai servizi di Monte Titoli in concomitanza con la migrazione alla piattaforma T2S, si suggerisce di prendere accuratamente nota delle conseguenze che queste modifiche comportano. Nei successivi paragrafi sono descritte in dettaglio le casistiche di variazione ammesse e non ed i relativi impatti sui dati dinamici (operazioni X-TRM). È bene sottolineare che, in caso di cambiamenti ammessi, questi saranno effettivi dal lunedì 22 giugno 2015, ma dovranno essere opportunamente comunicati dai clienti a Monte Titoli dal 15 dicembre 2014 al 20 marzo 2015. Fra le variazione alle modalità di partecipazione ai servizi sono incluse l’ attivazione e/o il recesso da uno o più servizi. Le variazioni alle operazioni X-TRM conseguenti ad una variazione anagrafica determinano il contenuto del flusso informativo G56 dei soggetti coinvolti rispetto ai diversi ruoli (ad esempio liquidatore o General Clearing Member). Di seguito si analizzeranno le seguenti categorie di variazione: Cambio del soggetto pagatore per il servizio di gestione accentrata e/o per il servizio di liquidazione Cambio del soggetto liquidatore per le operazioni OTC e/o provenienti da mercati non garantiti Cambio del soggetto liquidatore per i mercati garantiti e/o cambio della tipologia di adesione alla controparte centrale 38 6.1 Modifica del soggetto pagatore 6.1.1 Modifica del soggetto pagatore nell’ ambito del servizio di gestione accentrata E’ consentita la modifica del soggetto pagatore per la gestione accentrata nel periodo a cavallo del weekend di migrazione e segue le medesime logiche di variazione attuali. Si noti che, coerentemente con quanto definito nell’ambito del progetto Harmonisation Custody (cash distribution), per i pagamenti relativi alle corporate action con data valuta a partire dal lunedì ed il martedì successivi al weekend di migrazione, il nuovo soggetto pagatore riceverà i messaggi previsionali/definitivi come segue: 6.1.2 Modifica del soggetto pagatore nell’ ambito del servizio di liquidazione E’ consentita la modifica del soggetto pagatore per il regolamento delle operazioni contro pagamento nel corso del weekend di migrazione, in quanto operazione non critica. Poiché da un punto di vista della piattaforma X-TRM, il soggetto pagatore potrebbe risultare presente nelle operazioni, è necessario che vi sia coerenza con le configurazioni statiche impostate; alternativamente il sistema assume il dato impostato per default. Si precisa che la variazione del soggetto pagatore si applica anche alle istruzioni fail, cioè alle istruzioni in attesa di regolamento con ISD antecedente al weekend di migrazione a T2S. La variazione del soggetto pagatore per il regolamento ha un’influenza diretta sul calcolo del saldo contante e del purchasing power del soggetto pagatore. 6.2 Modifica del soggetto liquidatore e della tipologia di adesione alla CCP A seconda del tipo di operazioni presenti in X-TRM al momento della migrazione, e quindi delle configurazioni cliente che ne consentono il corretto trattamento, la variazione del soggetto liquidatore si può applicare: 1. alle sole operazioni OTC e/o provenienti da mercati non garantiti 2. alle operazioni provenienti da mercati garantiti ed ai conseguenti saldi netti bilaterali 39 Nel primo caso, per effetto della variazione, il liquidatore precedente non troverà più nell’informativa X-TRM le operazioni soggette a variazione mentre le medesime saranno disponibili nell’informativa del nuovo liquidatore. Nessun impatto invece sull’informativa destinata al negoziatore. Nel secondo caso, per la variazione del soggetto liquidatore in presenza di operazioni provenienti dai mercati garantiti, si premettono di seguito alcuni schemi riassuntivi delle casistiche che si verificano in X-TRM a seconda delle modalità di partecipazione dei vari attori alla liquidazione e alla controparte centrale e che si possono distinguere in: 1. modello ‘A’ o modello di marginazione lordo, valido per il mercato equity (cfr. 6.2.1) 2. modello ‘B’ o modello di marginazione netto, valido per il mercato bonds (cfr. 6.2.2) Per elementi di maggior dettaglio si prega di fare riferimento al documento contrattuale “Istruzioni del Servizio X-TRM” pubblicato sul sito web Monte Titoli. La possibilità di ammettere od escludere variazioni di configurazione ai dati statici relativamente alla tipologia di adesione alla CCP e alle modalità di partecipazione alla liquidazione del partecipante alla CCP e/o del negoziatore è strettamente legata non solo alla variazione di configurazione in senso stretto ma anche alle modalità di calcolo del saldo netto bilaterale. L’analisi proposta di seguito dettaglia tutti i possibili passaggi da una casistica ad un’altra, descrivendone lo scenario e le possibili conseguenze ed impatti sui dati dinamici (indicazione dei dati oggetto di modifica sulle operazioni e sui saldi netti bilaterali) e sui soggetti coinvolti. Per una più efficace comprensione si consiglia di consultare parallelamente anche il documento di cui al capitolo 10. (“Variazioni tipologia di adesione alla CCP e cambio liquidatore”). Si noti che gli scenari descritti ai paragrafi il cui titolo è evidenziato con il colore: Grigio: descrivono casistiche attualmente presenti nel sistema Verde: descrivono fattispecie attualmente non presenti nei sistemi Monte Titoli, ovvero le casistiche 2, 3B e 5B dettagliate nei successivi paragrafi. Si specifica che i suddetti scenari di variazione vengono riportati per completezza di analisi. Inoltre, nelle tabelle che seguono, le casistiche contrassegnate con il simbolo: √: indicano variazioni alla tipologia di adesione alla CCP e/o delle modalità di partecipazione alla liquidazione del partecipante alla CCP e/o del negoziatore considerate ammissibili 40 √ indicano variazioni ammissibili con variazione del soggetto emittente (codice CED) dell’ operazione X : indicano variazioni non ammissibili. Monte Titoli ammette la variazione del Partecipante Generale (GCM) e/o del soggetto liquidatore, purché ciò non comporti la creazione ex-novo o l’eliminazione di un’operazione XTRM al momento della migrazione. Inoltre, non sono ammesse variazioni che, direttamente o indirettamente, prevedono il cambiamento della controparte centrale coinvolta nella transazione (da LCH SA a CC&G e viceversa). Per entrambi i modelli operativi («Modello di marginazione lordo - A» e «Modello di marginazione netto - B») ogni singolo soggetto ha la visibilità delle operazioni a seconda dello specifico ruolo che ricopre e del tipo di abilitazione assegnata dal soggetto negoziatore. 41 6.2.1 Modello operativo “A” o Modello di marginazione lordo Di seguito viene fornito uno scherma riassuntivo dei vari casi presenti nel modello operativo A: Il seguente schema riporta, a titolo di esempio, un’istanza per ciascun caso indicando il soggetto in capo al quale si costruisce il saldo bilaterale. La seguente tabella riassume i differenti scenari di passaggio da un caso all’altro fra quelli sopra descritti. Il passaggio da un caso all’altro è rappresentato di volta in volta da un cambio di liquidatore e/o un cambio di partecipazione alla Controparte Centrale. 42 Caso 1 Caso 2 Caso 3 Caso 4 Caso 5 Caso 1 Caso 2 Caso 3 Caso 4 Caso 5 n.a. √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ Nel modello di marginazione lorda (Modello A) il soggetto obbligato nei confronti della controparte centrale è il GCM o ICM (a parte il caso 2) quindi il saldo netto bilaterale creato è relativo alle posizioni del soggetto negoziatore nei confronti della controparte centrale. Ne consegue che in tutti i casi di variazione ammessa il soggetto che ricopre il ruolo di negoziatore non avrà alcun impatto sull’informativa X-TRM. Passaggio dalla casistica 1 alla casistica 3 SCENARIO Il negoziatore passa da diretto ad indiretto alla liquidazione Il negoziatore non è più partecipante diretto alla CCP ma si avvale di un aderente generale CONSEGUENZE Il soggetto negoziatore, sia in qualità di liquidatore “uscente” e di aderente individuale, non ha più visibilità delle proprie operazioni Il soggetto liquidatore/GCM “entrante” (del negoziatore) ha visibilità delle operazioni del soggetto negoziatore che prima aderiva direttamente alla liquidazione I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB: o liquidatore o conto di regolamento Passaggio dalla casistica 3 alla casistica 1 SCENARIO 43 Il negoziatore passa da indiretto a diretto alla liquidazione Il negoziatore passa da una modalità di adesione indiretta alla CCP a diretta CONSEGUENZE Il soggetto liquidatore “uscente”, in qualità anche di GCM, non ha più la visibilità delle operazioni del soggetto negoziatore il soggetto liquidatore “entrante”, che è anche negoziatore ed aderente individuale, divenendo diretto ha piena visibilità di tutte le proprie operazioni a prescindere dal ruolo I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB: o liquidatore o conto di regolamento Passaggio dalla casistica 1 alla casistica 4 SCENARIO Il negoziatore passa da diretto alla liquidazione ad indiretto (si avvale di un soggetto liquidatore) Il negoziatore mantiene una modalità di adesione diretta alla CCP CONSEGUENZE Il soggetto negoziatore, nel ruolo di liquidatore “uscente”, non ha più la visibilità delle proprie operazioni il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto negoziatore che prima aderiva direttamente alla liquidazione I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB: o liquidatore o conto di regolamento Passaggio dalla casistica 4 alla casistica 1 44 SCENARIO Il negoziatore passa da indiretto alla liquidazione a diretto Il negoziatore mantiene una modalità di adesione diretta alla CCP CONSEGUENZE Il soggetto liquidatore “uscente” non ha più la visibilità delle operazioni del soggetto negoziatore il soggetto liquidatore “entrante”, che è anche negoziatore ed aderente individuale, divenendo diretto ha piena visibilità di tutte le proprie operazioni a prescindere dal ruolo I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB: o Liquidatore o conto di regolamento Passaggio dalla casistica 1 alla casistica 5 SCENARIO Il negoziatore passa da diretto ad indiretto alla liquidazione Il negoziatore non è più diretto alla CCP ma si avvale di un aderente generale alla CCP (Il soggetto negoziatore deve avere come liquidatore il soggetto liquidatore del GCM) CONSEGUENZE Il soggetto negoziatore, nel ruolo di liquidatore “uscente”, non ha più la visibilità delle proprie operazioni Il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto negoziatore che prima aderiva direttamente alla liquidazione L’aderente generale ha piena visibilità delle operazioni del negoziatore, a causa dell’ adesione indiretta alla CCP I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB: o liquidatore o conto di regolamento 45 Passaggio dalla casistica 5 alla casistica 1 SCENARIO Il negoziatore passa da indiretto a diretto alla liquidazione Il negoziatore passa da un’adesione indiretta alla CCP ad un’adesione diretta CONSEGUENZE Il soggetto liquidatore “uscente” non ha più la visibilità delle operazioni del soggetto negoziatore Il soggetto liquidatore “entrante”, che coincide con il negoziatore, ha piena visibilità delle proprie operazioni L’aderente generale “uscente” non ha più la visibilità delle operazioni a causa dell’ adesione diretta alla CCP del negoziatore. L’aderente individuale (ovvero il negoziatore) ha piena visibilità delle proprie operazioni a causa dell’ adesione diretta alla CCP. I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB: o liquidatore o conto di regolamento Passaggio dalla casistica 3 alla casistica 4 SCENARIO COMBINATO SCENARIO 1 Il soggetto negoziatore passa da un’adesione indiretta alla CCP ad un’adesione diretta ma mantiene il medesimo soggetto liquidatore. SCENARIO 2 Il soggetto negoziatore passa da un’adesione indiretta alla CCP ad un’adesione cambia il soggetto liquidatore. CONSEGUENZE SCENARIO 1 L’ aderente generale “uscente” perde la visibilità dei saldi del negoziatore Il negoziatore acquisisce la visibilità dei proprio saldi anche in qualità di ICM 46 diretta e Il soggetto liquidatore continua ad avere la stessa visibilità sulle operazioni del negoziatore rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo. Solo il campo relativo all’aderente generale è oggetto di modifica sull’ operazione SCENARIO 2 Il negoziatore acquisisce visibilità dei proprio saldi anche in qualità di ICM L’ aderente generale “uscente” perde la visibilità delle operazioni del negoziatore anche nel suo ruolo di liquidatore “uscente” Il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto negoziatore anche nel ruolo di soggetto liquidatore dell’ aderente individuale. I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB o soggetto liquidatore o conto di regolamento Passaggio dalla casistica 4 alla casistica 3 SCENARIO Il negoziatore passa da un’adesione diretta alla CCP ad una partecipazione indiretta alla CCP CONSEGUENZE Il GCM “uscente” non ha più la visibilità dei saldi del soggetto negoziatore Il GCM “entrante” ha la visibilità dei saldi del soggetto negoziatore Il soggetto liquidatore continua ad avere la stessa visibilità sulle operazioni del negoziatore rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo. Solo il dato relativo all’aderente generale è oggetto di modifica sull’ operazione Passaggio dalla casistica 3 alla casistica 5 SCENARIO COMBINATO SCENARIO 1 Il negoziatore mantiene il medesimo soggetto liquidatore cambiando il GCM liquidatore del negoziatore deve coincidere con il soggetto liquidatore del GCM) 47 (il soggetto SCENARIO 2 Il negoziatore cambia GCM e contestualmente cambia anche il soggetto liquidatore. Si noti che il soggetto liquidatore del negoziatore deve coincidere con il soggetto liquidatore del GCM. CONSEGUENZE SCENARIO 1 Il soggetto GCM “uscente” perde la visibilità delle operazioni del soggetto negoziatore ma la mantiene in qualità di liquidatore Il GCM “entrante” acquisisce la visibilità dei saldi del soggetto negoziatore Solo il campo relativo all’aderente generale è oggetto di modifica sull’ operazione SCENARIO 2 Il soggetto liquidatore e GCM “uscente” perde la visibilità delle operazioni del soggetto negoziatore Il liquidatore e GCM “entrante” acquisisce la visibilità delle operazioni del soggetto negoziatore I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB o soggetto liquidatore o conto di regolamento Passaggio dalla casistica 5 alla casistica 3 SCENARIO Il negoziatore cambia il GCM utilizzando il proprio soggetto liquidatore CONSEGUENZE Il GCM “uscente” non ha più la visibilità dei saldi del soggetto negoziatore Il GCM “entrante” ha la visibilità dei saldi del soggetto negoziatore Il soggetto liquidatore continua ad avere la stessa visibilità sulle operazioni del negoziatore rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo. Solo il dato relativo all’aderente generale è oggetto di modifica sull’ operazione 48 Passaggio dalla casistica 4 alla casistica 5 SCENARIO COMBINATO SCENARIO 1 Il soggetto negoziatore passa da diretto ad indiretto alla CCP Il soggetto negoziatore non cambia il suo soggetto liquidatore in quanto già risulta essere il liquidatore del nuovo GCM SCENARIO 2 Il soggetto negoziatore passa da diretto ad indiretto alla CCP Il soggetto negoziatore cambia il suo soggetto liquidatore che risulta essere il medesimo soggetto liquidatore del GCM CONSEGUENZE SCENARIO 1 Il ICM “uscente” non ha più la visibilità dei saldi del soggetto negoziatore Il GCM “entrante” ha la visibilità dei saldi del soggetto negoziatore Il soggetto liquidatore continua ad avere la stessa visibilità sulle operazioni del negoziatore rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo. Solo il dato relativo all’aderente generale è oggetto di modifica sull’ operazione SCENARIO 2 Il soggetto liquidatore “uscente” non ha più la visibilità delle operazioni del soggetto negoziatore Il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto negoziatore che prima aderiva direttamente alla liquidazione . L’aderente generale “nuovo” ha piena visibilità dei saldi del negoziatore, interponendosi direttamente con la CCP. L’aderente generale “uscente” non ha più la visibilità dei propri saldi operazioni. I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB: o liquidatore o conto di regolamento 49 Passaggio dalla casistica 5 alla casistica 4 SCENARIO Il negoziatore passa da un’adesione indiretta alla CCP ad una partecipazione diretta Il negoziatore cambia il soggetto liquidatore CONSEGUENZE Il soggetto liquidatore “uscente” non ha più la visibilità delle operazioni del soggetto negoziatore Il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto negoziatore Il GCM “uscente” non ha più la visibilità dei saldi del soggetto negoziatore il negoziatore, nel ruolo di ICM “entrante” ha la visibilità dei proprio saldi I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB: o liquidatore o conto di regolamento Passaggio dalla casistica 3 alla casistica 3 SCENARIO Cambia il soggetto liquidatore che è anche aderente generale CONSEGUENZE Il soggetto liquidatore “uscente” non ha più la visibilità delle operazioni del soggetto negoziatore Il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto negoziatore anche nel ruolo di soggetto liquidatore dell’ aderente generale Essendovi coincidenza tra il soggetto liquidatore e l’aderente generale, la view del GCM è la medesima rispetto a quella del soggetto liquidatore (di cui sopra). I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB: 50 o soggetto liquidatore o conto di regolamento Passaggio dalla casistica 4 alla casistica 4 SCENARIO Cambia il soggetto liquidatore ma non le modalità di partecipazione alla CCP (diretta) CONSEGUENZE Il soggetto liquidatore “uscente” perde la visibilità delle operazioni del soggetto ha visibilità delle operazioni del soggetto negoziatore il soggetto liquidatore “entrante” piena negoziatore I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB o soggetto liquidatore o conto di regolamento Passaggio dalla casistica 5 alla casistica 5 SCENARIO COMBINATO SCENARIO 1 Cambia l’aderente generale ma non è prevista alcuna variazione del soggetto liquidatore (dell’aderente generale e del liquidatore del soggetto negoziatore), in quanto il liquidatore del nuovo GCM è lo stesso del precedente GCM. SCENARIO 2 Cambia l’ aderente generale. Inoltre è prevista una variazione del soggetto liquidatore del negoziatore che deve utilizzare il liquidatore del nuovo aderente generale. CONSEGUENZE SCENARIO 1 Il “nuovo” GCM ha visibilità delle operazioni del negoziatore, essendo il nuovo soggetto chiamato ad interporsi con la CCP Il “vecchio” GCM non ha più la visibilità delle operazioni del negoziatore 51 Il soggetto liquidatore dell’ aderente generale e del negoziatore continua a mantenere la visibilità delle operazioni in essere rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo Solo il dato relativo all’aderente generale è oggetto di modifica sull’ operazione SCENARIO 2 Il “vecchio” soggetto liquidatore del GCM e del negoziatore non ha più la visibilità delle operazioni del soggetto negoziatore Il “nuovo” soggetto liquidatore del GCM e del negoziatore ha più piena visibilità delle operazioni del soggetto negoziatore Il “nuovo” aderente generale avrà visibilità delle operazioni del negoziatore, essendo il nuovo soggetto chiamato ad interporsi con la CCP. Il clearing member “uscente” perde la visibilità sulle operazioni del negoziatore. I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB o soggetto liquidatore o conto di regolamento 52 6.2.2 Modello operativo “B” o Modello di marginazione netto Di seguito viene fornito uno scherma riassuntivo dei vari casi presenti nel modello operativo B o modello di marginazione netto: La seguente tabella riassume i differenti scenari di passaggio da un caso all’altro fra quelli sopra descritti. Il passaggio da un caso all’altro è rappresentato di volta in volta da un cambio di liquidatore e/o un cambio di partecipazione alla Controparte Centrale. Il seguente schema riporta, a titolo di esempio, un’istanza per ciascun caso indicando il soggetto in capo al quale si costruisce il saldo bilaterale. 53 Passaggio dalla casistica 1 alla casistica 3A SCENARIO il negoziatore passa da diretto ad indiretto alla liquidazione Il negoziatore non è più diretto alla CCP (aderente individuale) ma si avvale di un aderente generale (conto del negoziatore uguale al conto del GCM) CONSEGUENZE Il soggetto negoziatore, sia in qualità di liquidatore “uscente” che di aderente individuale, non ha più visibilità delle proprie operazioni, che non vede più né come emittente né come controparte Il soggetto liquidatore/GCM “entrante” ha visibilità delle operazioni del soggetto negoziatore che prima aderiva direttamente alla liquidazione I seguenti campi sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento o codice del soggetto intestatario del SNB I seguenti campi sono oggetto di modifica sul SNB: o emittente o tipo negoziazione (in alcuni casi) o liquidatore o conto di regolamento Passaggio dalla casistica 3A alla casistica 1 SCENARIO 54 Il negoziatore passa da una partecipazione indiretta alla liquidazione a diretta Il negoziatore passa da un’ adesione indiretta alla CCP a diretta CONSEGUENZE Il soggetto liquidatore “uscente”, anche in qualità di GCM, non ha più la visibilità delle operazioni del soggetto negoziatore Il soggetto liquidatore “entrante” , che è anche negoziatore e ICM , ha piena visibilità di tutte le proprie operazioni a prescindere dal ruolo I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB: o emittente o tipo negoziazione (in alcuni casi) o liquidatore o conto di regolamento Passaggio dalla casistica 1 alla casistica 4 SCENARIO Il negoziatore passa da diretto alla liquidazione ad indiretto (si avvale di un soggetto liquidatore) Il negoziatore mantiene la modalità di adesione diretta alla CCP CONSEGUENZE Il soggetto liquidatore “entrante” (del negoziatore e dell’aderente generale) ha piena visibilità delle operazioni del soggetto negoziatore che prima aderiva direttamente alla liquidazione Il soggetto negoziatore, nel ruolo di liquidatore “uscente”, perde la visibilità diretta sulle sue operazioni I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB: o liquidatore o conto di regolamento 55 Passaggio dalla casistica 4 alla casistica 1 SCENARIO Il negoziatore passa da indiretto alla liquidazione a diretto Il negoziatore mantiene una modalità di adesione diretta alla CCP CONSEGUENZE Il soggetto liquidatore “entrante” , che è anche negoziatore ed aderente individuale, ha piena visibilità di tutte le operazioni a prescindere dal ruolo Il soggetto liquidatore “uscente” non ha più la visibilità delle operazioni del soggetto negoziatore I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB: o liquidatore o conto di regolamento Passaggio dalla casistica 1 alla casistica 5A SCENARIO Il negoziatore non è più diretto alla CCP ma si avvale di un aderente generale Il negoziatore passa da diretto alla liquidazione ad indiretto avvalendosi dello stesso liquidatore del GCM. Si specifica che il conto del negoziatore è uguale al conto del clering member. CONSEGUENZE Il soggetto negoziatore, nel ruolo di liquidatore “uscente”, non ha più la visibilità delle proprie operazioni Il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto negoziatore che prima aderiva direttamente alla liquidazione L’aderente generale ha piena visibilità dei saldi bilaterali creati a suo nome I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB: o liquidatore 56 o conto di regolamento o emittente o tipo negoziazione (in alcuni casi) Passaggio dalla casistica 5A alla casistica 1 SCENARIO Il negoziatore passa da indiretto alla liquidazione a diretto Il negoziatore passa da un’adesione indiretta alla CCP ad un’adesione diretta CONSEGUENZE Il soggetto liquidatore “uscente” non ha più la visibilità delle operazioni del soggetto negoziatore Il soggetto liquidatore “entrante”, che coincide con il negoziatore, ha piena visibilità delle proprie operazioni L’aderente generale “uscente” non ha più la visibilità delle operazioni a causa dell’ adesione diretta alla CCP del negoziatore. Il negoziatore, nel ruolo di aderente generale "entrante" , ha piena visibilità delle proprie operazioni a causa dell’ adesione diretta alla CCP. AI saldi bilaterali creati in capo all’aderente generale si sostituisce il negoziatore I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB: o liquidatore o conto di regolamento o emittente o tipo negoziazione (in alcuni casi) Passaggio dalla casistica 2 alla casistica 3B SCENARIO COMBINATO SCENARIO 1 Il negoziatore passa da diretto alla liquidazione ad indiretto mantenendo lo stesso GCM. Il liquidatore deve utilizzare due conti diversi per il soggetto negoziatore e per il GCM. SCENARIO 2 57 Il negoziatore passa da diretto ad indiretto alla liquidazione e contestualmente cambia l'aderente generale. Il liquidatore deve utilizzare due conti diversi per il soggetto negoziatore e per il GCM. CONSEGUENZE SCENARIO 1 Il soggetto negoziatore continua a vedere le proprie operazioni ma non più nel ruolo di liquidatore “uscente” Il soggetto liquidatore “entrante” del negoziatore ha piena visibilità delle operazioni del soggetto negoziatore che peraltro già vedeva in qualità di GCM I seguenti campi sono oggetto di modifica sull’ operazione: o soggetto liquidatore o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): o liquidatore o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o conto di regolamento SCENARIO 2 Il soggetto negoziatore continua a vedere le proprie operazioni ma non più nel ruolo di liquidatore “uscente” Il soggetto GCM “uscente” perde visibilità delle operazioni del negoziatore Il soggetto GCM “entrante”, anche nel ruolo di liquidatore del negoziatore, ha piena visibilità delle operazioni del soggetto negoziatore I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o conto di regolamento o aderente generale I seguenti dati sono oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): o liquidatore o conto di regolamento o emittente o la controparte I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): 58 o emittente o liquidatore o conto di regolamento o controparte Passaggio dalla casistica 3B alla casistica 2 SCENARIO COMBINATO SCENARIO 1 Il negoziatore passa da indiretto alla liquidazione a diretto e cambia l' aderente generale. Si specifica che l’aderente e suo liquidatore coincidono SCENARIO 2 Il negoziatore passa da indiretto alla liquidazione a diretto e ma non cambia l' aderente generale. Si specifica che l’aderente e suo liquidatore coincidono CONSEGUENZE SCENARIO 1 Il soggetto liquidatore “uscente” del negoziatore non ha più la visibilità delle operazioni del soggetto negoziatore Il negoziatore, nel ruolo di soggetto liquidatore “entrante”, ha piena visibilità delle proprie operazioni Il “nuovo” aderente generale, che coincide con il soggetto liquidatore del GCM, ha piena visibilità delle operazioni del negoziatore a causa dell’adesione indiretta alla CCP I seguenti dati sono oggetto di modifica sull’ operazione: o aderente generale o soggetto liquidatore o conto di regolamento o codice soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): o liquidatore o conto di regolamento o la controparte I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o emittente o liquidatore o conto di regolamento 59 SCENARIO 2 Il soggetto liquidatore “uscente” del negoziatore non ha più la visibilità delle operazioni del soggetto negoziatore Il negoziatore, nel ruolo di soggetto liquidatore “entrante” ha piena visibilità delle proprie operazioni I' aderente generale, che coincide con il soggetto liquidatore del GCM, continua ad avere la medesima visibilità delle operazioni del negoziatore I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): o liquidatore o conto di regolamento Passaggio dalla casistica 2 alla casistica 5B SCENARIO Il negoziatore passa da diretto a indiretto alla liquidazione e cambia GCM. Il nuovo liquidatore del negoziatore e del GCM deve utilizzare conti diversi CONSEGUENZE Il negoziatore mantiene la visibilità delle proprie operazioni ma la perde in qualità di liquidatore “uscente” Il GCM “uscente” non ha più visibilità delle operazioni del negoziatore Il “nuovo” soggetto liquidatore del negoziatore e dell’aderente generale, ha piena visibilità delle operazioni del soggetto negoziatore e del nuovo GCM Il “nuovo” aderente generale avrà visibilità delle operazioni del negoziatore, essendo il nuovo soggetto chiamato ad interporsi con la CCP I seguenti dati sono oggetto di modifica sull’ operazione: o aderente generale o soggetto liquidatore o conto di regolamento o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): o liquidatore o conto di regolamento o controparte 60 I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o emittente o conto di regolamento Passaggio dalla casistica 5B alla casistica 2 SCENARIO Il negoziatore passa da indiretto a diretto alla liquidazione e cambia GCM CONSEGUENZE Il soggetto negoziatore, che coincide con il liquidatore “entrante”, ha piena visibilità delle proprie operazioni ma non in qualità di liquidatore del GCM Il liquidatore “uscente” non ha più la visibilità delle operazioni del soggetto negoziatore Il “nuovo” aderente generale, che coincide con il suo liquidatore ha piena visibilità delle operazioni del negoziatore a causa dell’adesione indiretta alla CCP. I seguenti dati sono oggetto di modifica sull’ operazione: o aderente generale o soggetto liquidatore o conto di regolamento o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): o liquidatore o conto di regolamento o controparte I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o emittente o conto di regolamento Passaggio dalla casistica 3A alla casistica 4 SCENARIO COMBINATO SCENARIO 1 Il negoziatore passa da un’adesione indiretta alla CCP ad una partecipazione diretta mantenendo come liquidatore quello del precedente GCM SCENARIO 2 61 Il negoziatore passa da un’adesione indiretta alla CCP ad una partecipazione diretta e contestualmente si avvale di un nuovo liquidatore CONSEGUENZE SCENARIO 1 Il negoziatore acquisisce visibilità dei propri saldi in qualità di ICM Il GCM “uscente” perde visibilità dei saldi del negoziatore ma ne mantiene la visibilità in qualità di liquidatore Il soggetto liquidatore continua ad avere la stessa visibilità sulle operazioni del negoziatore rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo. I seguenti dati sono oggetto di modifica sull' operazione o aderente generale o codice soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o emittente o tipo negoziazione (in alcuni casi) SCENARIO 2 Il negoziatore acquisisce visibilità dei propri saldi in qualità di ICM Il GCM “uscente” perde visibilità dei saldi del negoziatore anche nel suo ruolo di liquidatore “uscente” Il “nuovo” soggetto liquidatore del negoziatore, che è ICM, ha piena visibilità delle operazioni I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento o codice soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o emittente o tipo negoziazione (in alcuni casi) o liquidatore o conto di regolamento 62 Passaggio dalla casistica 4 alla casistica 3A SCENARIO Il negoziatore passa da un’adesione diretta alla CCP ad una partecipazione indiretta alla CCP. CONSEGUENZE Il ICM “uscente” non ha più la visibilità dei saldi del soggetto negoziatore Il GCM “entrante” ha la visibilità dei saldi del soggetto negoziatore Il soggetto liquidatore continua ad avere la stessa visibilità sulle operazioni del negoziatore rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo. I seguenti dati sono oggetto di modifica sull' operazione o aderente generale o codice del soggetto intestatario del SNB Solo il dato relativo all’aderente generale è oggetto di modifica sull’ operazione I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o emittente o tipo negoziazione (in alcuni casi) Passaggio dalla casistica 3A alla casistica 5A SCENARIO COMBINATO SCENARIO 1 Il negoziatore cambia il GCM mantenendo il medesimo soggetto liquidatore SCENARIO 2 Il negoziatore cambia GCM e contestualmente cambia anche il soggetto liquidatore che deve coincidere con quello del GCM CONSEGUENZE SCENARIO 1 Il soggetto liquidatore del negoziatore mantiene la visibilità delle operazioni del soggetto negoziatore ma la perde in qualità di GCM “uscente” il GCM “entrante” acquisisce la visibilità delle operazioni del soggetto negoziatore I seguenti dati sono oggetto di modifica sull’ operazione: o aderente generale 63 o codice del soggetto intestatario del SNB SCENARIO 2 Il “vecchio” soggetto liquidatore del negoziatore perde la visibilità delle operazioni il liquidatore “entrante” acquisisce la visibilità delle operazioni del soggetto negoziatore Il GCM “uscente” perde la visibilità delle operazioni del soggetto negoziatore Il GCM “entrante” acquisisce la visibilità delle operazioni del soggetto negoziatore I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o emittente o liquidatore o conto di regolamento Passaggio dalla casistica 5A alla casistica 3A SCENARIO Il negoziatore cambia il GCM utilizzando il proprio soggetto liquidatore CONSEGUENZE Il GCM “uscente” non ha più la visibilità dei saldi del soggetto negoziatore Il GCM “entrante” ha la visibilità dei saldi del soggetto negoziatore Il soggetto liquidatore continua ad avere la stessa visibilità sulle operazioni del negoziatore rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo. I seguenti dati sono oggetto di modifica sull’ operazione o aderente generale o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o Emittente Passaggio dalla casistica 3B alla casistica 5B SCENARIO COMBINATO SCENARIO 1 64 Il negoziatore cambia GCM mantenendo lo stesso liquidatore che utilizza due conti distinti per il negoziatore ed il GCM SCENARIO 2 Il negoziatore cambia GCM e contestualmente cambia anche il soggetto liquidatore che utilizza due conti distinti per il negoziatore ed il GCM CONSEGUENZE SCENARIO 1 Il soggetto liquidatore del negoziatore mantiene la visibilità delle operazioni del soggetto negoziatore ma la perde in qualità di GCM “uscente” Il GCM “entrante” acquisisce la visibilità delle operazioni del soggetto negoziatore I seguenti dati sono oggetto di modifica sull’ operazione o aderente generale o codice del soggetto intestatario del SNB Solo il campo relativo all’emittente è oggetto di modifica sul SNB (operazione tra aderente generale e CCP): Solo il campo relativo all’emittente è oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): SCENARIO 2 Il “vecchio” soggetto liquidatore del negoziatore perde la visibilità delle operazioni del soggetto negoziatore anche in qualità di GCM “uscente” Il liquidatore “entrante” acquisisce la visibilità delle operazioni del soggetto negoziatore Il GCM “entrante” acquisisce la visibilità delle operazioni del soggetto negoziatore I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): o liquidatore o conto di regolamento o controparte I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o emittente o liquidatore 65 o conto di regolamento Passaggio dalla casistica 5B alla casistica 3B SCENARIO Il negoziatore cambia il GCM utilizzando il proprio soggetto liquidatore utilizzando due conti distinti CONSEGUENZE Il GCM “uscente” non ha più la visibilità dei saldi del soggetto negoziatore Il GCM “entrante” ha la visibilità dei saldi del soggetto negoziatore Il soggetto liquidatore continua ad avere la stessa visibilità sulle operazioni del negoziatore rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo. I seguenti dati sono oggetto di modifica sull’ operazione o aderente generale o codice del soggetto intestatario del SNB Solo il dato relativo alla controparte è oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): Solo il dato relativo alla controparte è oggetto di modifica sul SNB (operazione tra aderente generale e CCP) Passaggio dalla casistica 4 alla casistica 5A SCENARIO COMBINATO SCENARIO 1 Il soggetto negoziatore passa da diretto ad indiretto alla CCP SCENARIO 2 Il soggetto negoziatore passa da diretto ad indiretto alla CCP e cambia il suo soggetto liquidatore utilizzando quello del GCM CONSEGUENZE SCENARIO 1 Il ICM “uscente” non ha più la visibilità dei saldi del soggetto negoziatore Il GCM “entrante” ha la visibilità dei saldi del soggetto negoziatore Il soggetto liquidatore continua ad avere la stessa visibilità sulle operazioni del negoziatore rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo. I seguenti dati sono oggetto di modifica sull' operazione 66 o aderente generale o codice soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB: o emittente o tipo negoziazione (in alcuni casi) SCENARIO 2 Il soggetto liquidatore “uscente” non ha più la visibilità delle operazioni del soggetto negoziatore Il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto negoziatore che prima aderiva direttamente alla liquidazione . L’aderente generale “nuovo” ha piena visibilità dei saldi del negoziatore, interponendosi direttamente con la CCP. L’aderente generale “uscente” non ha più la visibilità dei propri saldi operazioni. I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento o codice del soggetto emittente del SNB I seguenti dati sono oggetto di modifica sul SNB: o emittente o tipo negoziazione (in alcuni casi) o liquidatore o conto di regolamento Passaggio dalla casistica 5A alla casistica 4 SCENARIO COMBINATO SCENARIO 1 Il negoziatore cambia il soggetto liquidatore Il negoziatore passa da un’adesione indiretta alla CCP ad una partecipazione diretta SCENARIO 2 Il negoziatore passa da un’adesione indiretta alla CCP ad una partecipazione diretta CONSEGUENZE SCENARIO 1 Il soggetto liquidatore “uscente” non ha più la visibilità delle operazioni del soggetto negoziatore 67 Il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto negoziatore Il GCM “uscente” non ha più la visibilità dei saldi del soggetto negoziatore Il negoziatore, nel ruolo di ICM “entrante” ha la visibilità dei proprio saldi I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB: o emittente o tipo negoziazione (in alcuni casi) o liquidatore o conto di regolamento SCENARIO 2 Il soggetto liquidatore continua ad avere la stessa visibilità sulle operazioni del negoziatore rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo. il GCM “uscente” non ha più la visibilità dei saldi del soggetto negoziatore il negoziatore, nel ruolo di ICM “entrante” ha la visibilità dei proprio saldi I seguenti dati sono oggetto di modifica sull’ operazione: o aderente generale o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB: o emittente o tipo negoziazione (in alcuni casi) Passaggio dalla casistica 2 alla casistica 2 SCENARIO Il soggetto negoziatore continua a partecipare direttamente alla liquidazione Il soggetto negoziatore cambia l’aderente generale che è anche liquidatore del GCM CONSEGUENZE Il soggetto liquidatore del negoziatore, che continua a coincidere col negoziatore stesso, ha la totale visibilità totale delle proprie operazioni I seguenti dati sono oggetto di modifica sull' operazione o aderente generale 68 o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): o liquidatore o conto di regolamento o controparte I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o emittente o liquidatore o conto di regolamento Passaggio dalla casistica 3A alla casistica 3A SCENARIO Il negoziatore cambia il soggetto liquidatore e aderente generale tra loro coincidenti CONSEGUENZE Il soggetto liquidatore “uscente” non ha più la visibilità delle operazioni del soggetto negoziatore Il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto negoziatore anche nel ruolo di soggetto liquidatore dell’ aderente generale essendovi coincidenza tra il soggetto liquidatore e l’aderente generale, la view del GCM è la medesima rispetto a quella del soggetto liquidatore (di cui sopra). I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB: o emittente o liquidatore o conto di regolamento Passaggio dalla casistica 3B alla casistica 3B SCENARIO Il negoziatore cambia il soggetto liquidatore che è anche aderente generale. Il liquidatore utilizza conti diversi 69 CONSEGUENZE Il soggetto liquidatore “uscente” non ha più la visibilità delle operazioni del soggetto negoziatore Il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto negoziatore anche nel ruolo di soggetto liquidatore dell’ aderente generale Essendovi coincidenza tra il soggetto liquidatore e l’aderente generale, la view del GCM è la medesima rispetto a quella del soggetto liquidatore (di cui sopra). I seguenti dati sono oggetto di modifica sull’ operazione: o o soggetto liquidatore o aderente generale o conto di regolamento codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): o liquidatore o conto di regolamento o controparte I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o emittente o liquidatore o conto di regolamento Passaggio dalla casistica 4 alla casistica 4 SCENARIO Cambia il soggetto liquidatore ma non le modalità di partecipazione alle CCP (diretto) CONSEGUENZE Il soggetto liquidatore “uscente” perde la visibilità delle operazioni del soggetto negoziatore Il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto negoziatore Seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB: o liquidatore 70 o conto di regolamento Passaggio dalla casistica 5A alla casistica 5A SCENARIO COMBINATO SCENARIO 1 Cambia l’aderente generale mantenendo l'attuale soggetto liquidatore. SCENARIO 2 Cambia l’ aderente generale ed il soggetto liquidatore. CONSEGUENZE SCENARIO 1 Il “nuovo” aderente generale ha visibilità delle operazioni del negoziatore, essendo il nuovo soggetto chiamato ad interporsi con la CCP Il “vecchio” aderente generale non ha più la visibilità delle operazioni del negoziatore Il soggetto liquidatore dell’ aderente generale e del negoziatore continua a mantenere la visibilità delle operazioni in essere rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo I seguenti dati sono oggetto di modifica sull’ operazione: o aderente generale o codice del soggetto emittente dell’ operazione Solo il dato relativo all’emittente è oggetto di modifica sull’ SNB SCENARIO 2 Il “vecchio” soggetto liquidatore del negoziatore e dell’aderente generale non ha più la visibilità delle operazioni del soggetto negoziatore Il “nuovo” soggetto liquidatore del negoziatore e dell’aderente generale ha piena visibilità delle operazioni del soggetto negoziatore Il “nuovo” aderente generale avrà visibilità delle operazioni del negoziatore, essendo il nuovo soggetto chiamato ad interporsi con la CCP. Il clearing member “uscente” perde la visibilità sulle operazioni del negoziatore. I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB: o emittente 71 o liquidatore o conto di regolamento Passaggio dalla casistica 5B alla casistica 5B SCENARIO COMBINATO SCENARIO 1 Cambia l’aderente generale mantenendo l'attuale soggetto liquidatore che utilizza due conti distinti per il negoziatore ed il GCM SCENARIO 2 Cambia l’ aderente generale ed il soggetto liquidatore che utilizza due conti distinti per il negoziatore ed il GCM. CONSEGUENZE SCENARIO 1 Il “nuovo” aderente generale ha visibilità delle operazioni del negoziatore, essendo il nuovo soggetto chiamato ad interporsi con la CCP Il “vecchio” aderente generale non ha più la visibilità delle operazioni del negoziatore Il soggetto liquidatore dell’ aderente generale e del negoziatore continua a mantenere la visibilità delle operazioni in essere rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane il medesimo Solo il dato relativo all’aderente generale è oggetto di modifica sull’ operazione I seguenti dati sono oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): o controparte o conto di regolamento I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o Emittente o conto di regolamento (in alcuni casi) SCENARIO 2 Il “vecchio” soggetto liquidatore del negoziatore e dell’aderente generale non ha più la visibilità delle operazioni del soggetto negoziatore Il “nuovo” soggetto liquidatore del negoziatore e dell’aderente generale ha piena visibilità delle operazioni del soggetto negoziatore Il “nuovo” aderente generale ha visibilità delle operazioni del negoziatore, essendo il nuovo soggetto chiamato ad interporsi con la CCP Il clearing member “uscente” perde la visibilità sulle operazioni del negoziatore. 72 I seguenti dati sono oggetto di modifica sull’ operazione: o soggetto liquidatore o aderente generale o conto di regolamento o codice del soggetto intestatario del SNB I seguenti dati sono oggetto di modifica sul SNB (operazione tra negoziatore e suo aderente generale): o liquidatore o conto di regolamento o controparte I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e CCP): o emittente o liquidatore o conto di regolamento 73 7 7.1 T2S USER TESTING & MIGRATION TESTING Introduzione L’obiettivo del presente capitolo è fornire una panoramica generale delle differenti fasi dello User Testing e Migration Testing che implicano, direttamente od indirettamente, il coinvolgimento dei clienti, siano essi partecipanti Directly Connected Participant (DCP) o Indirectly Connected Participant (ICP). 7.2 User Testing: attori coinvolti Le seguenti tabelle propongono un elenco degli attori coinvolti nella preparazione ed esecuzione della fase di User Testing con specifica indicazione delle responsabilità in capo ad ognuno. SOGGETTO Eurosistema RESPONSABILITA’ Gestione della preparazione della fase di User Testing Coordinamento e supporto all’esecuzione dello User Testing Partecipazione alla preparazione della fase di User Testing CSD Partecipazione attiva all’esecuzione delle varie fasi di test Banche Centrali Coordinamento delle attività di testing (preparazione ed esecuzione) con le rispettive Community CSD Participant Partecipazione attiva all’esecuzione delle fasi di test relative al Payment Bank Community ed al Business Day 74 7.3 User Testing Lo User Testing di T2S prevede l’ esecuzione di cinque differenti fasi di collaudo. Con riferimento alle fasi di testing sintetizzate sopra, si noti che la partecipazione diretta dei clienti è prevista a partire dalla fase di Community. Durante il Community ed il Business Day testing i clienti sono chiamati ad eseguire i collaudi secondo quanto indicato nel Piano delle Prove. 75 In particolare, durante la fase di Business Day testing, i clienti sono tenuti a partecipare alle prove generali di Migration Weekend e, per i tre giorni successivi, ad operare in ambiente di collaudo come se stessero operando direttamente in produzione. I nuovi ambienti di collaudo che Monte Titoli mette a disposizione per l’esecuzione dei test e per le fasi di passaggio in produzione dei dati statici con il relativo timing sono sinteticamente illustrati di seguito: Ambiente Ambiente legacy MT T2S T2 Interoperability Note Disponibile Disponibile da fino a Utilizzato solo da Monte Titoli. Messo a disposizione 11/06/2015 dei clienti da Monte Titoli come T2 Pre-Prod. nuovo ambiente di pre 12/06/2015 Data aperta 05/01/2015 11/06/2015 12/06/2015 Data aperta 15/12/2014 20/03/2015 21/03/2015 11/06/2015 produzione in sostituzione di PI. Utilizzato da Monte Titoli e dai clienti T1 Community per i connettività collaudi e di funzionali durante le fasi di Community e Business day testing. Utilizzato da Monte Titoli e dai clienti per il passaggio in T1 Produzione produzione a T2S (Migration Week End) e le successive attività BAU. Utilizzato per la sola gestione T3 n.a. dei dati statici di produzione tramite piattaforma web. Accessibile solo via internet. Connesso T3 Produzione produzione all’ambiente di T2S di per consentire la migrazione dei dati statici. 76 7.4 Migration Testing Il Migration Testing si suddivide nelle medesime fasi in cui è suddiviso lo User Testing. I clienti non sono direttamente coinvolti nella fase di Bilateral e Multilateral migration testing. L’ obiettivo della fase di Migration Testing è quello di assicurare che i CSD e le CB coinvolte nella prima finestra di migrazione a T2S e le rispettive comunità finanziarie siano effettivamente pronti a migrare i propri sistemi legacy alla nuova piattaforma T2S, rispettando le deadline e i synchonisation point definiti a livello comunitario ed in maniera bilaterale tra Monte Titoli ed i propri clienti. Durante la fase di migration testing i differenti soggetti coinvolti, coerentemente col proprio ruolo ricoperto, sono chiamati a: Verificare che gli strumenti, query e report aggiuntivi richiesti per la fase di migrazione a T2S siano adeguati a supportare la migrazione a T2S; Eseguire il caricamento dell’intero set di dati relativi alle attività di pre migrazione e di migrazione con l’obiettivo di assicurarsi che i dati stessi siano conformi agli standard di T2S; Verificare i dati già migrati alla nuova piattaforma attraverso reports di riconciliazione; Verificare che la sequenza di attività da eseguire sia durante la fase di pre migrazione che di migrazione in senso stretto sia adeguata e correttamente compresa da tutti gli attori coinvolti; Verificare che le attività programmate possano essere eseguite nel rispetto della schedulazione definita, soprattutto durante il weekend di migrazione a T2S; Verificare l’adeguatezza dei processi e delle procedure di contingency. Per maggiori dettagli si invita a far riferimento alla documentazione di seguito riportata: Dedicated Info Session "T2S User Testing and Migration: an urgent matter“ http://www.ecb.europa.eu/paym/t2s/governance/sessions/html/mtg21.en.html T2S Programme Plan – Project Phases – User Testing http://www.ecb.europa.eu/paym/t2s/progplan/html/index.en.html T2S Programme Plan – Project Phases – Migration http://www.ecb.europa.eu/paym/t2s/progplan/html/index.en.html#week 77 weekends 8 GESTIONE DEGLI ACCESS RIGHT IN T2S (solo per DCP) Si prega di notare che il seguente paragrafo è di interesse esclusivo dei clienti DCP. Infatti i clienti che optano per una connessione indiretta (ICP) alla piattaforma T2S attraverso Monte Titoli non sono tenuti ad effettuare alcuna attività relativa alla gestione dei diritti di accesso alla piattaforma T2S. Alla luce di quanto detto, i clienti ICP possono considerare il contenuto del presente paragrafo a scopo meramente illustrativo e conoscitivo. Prima di addentrarci nella spiegazione tecnica delle modalità e delle logiche alla base del processo di assegnazione e gestione dei diritti di accesso a T2S è bene specificare che, qualora il cliente decida di adottare una connessione diretta alla piattaforma T2S, è chiamato a gestire un processo preparatorio ad hoc relativo all’assegnazione degli access right in T2S. Quest’ultimo consta in una serie di azioni di seguito sintetizzate e riportate nella tabella di cui al 4.1: Piano delle attività e Synchronisation Point di premigrazione: 1. Il cliente DCP è tenuto a richiedere a Monte Titoli la configurazione e predisposizione di un utente amministratore. Sarà quest’ultimo, in quanto utente al quale i privilegi sono concessi in prima istanza, a riassegnarli internamente ad altri soggetti. In maniera speculare, il cliente DCP dovrà chiedere anche alla Banca Centrale di riferimento l’assegnazione di un utente amministratore per la gestione di tutti i diritti di accesso relativi a quanto di competenza della Banche Centrali Nazionali; 2. I DCP sono chiamati ad eseguire il processo di registrazione presso i Network Service Provider. Infatti, ogni partecipante DCP che partecipa ad una particolare finestra di migrazione deve completare l’apposita registrazione presso i NSP attraverso i rispettivi CSD/CB per l’ambiente di produzione; 3. I clienti DCP dovranno provvedere a richiedere specifici certificati/token per l’accesso al sistema T2S secondo criteri e regole dettate dal NSP scelto dal cliente. 8.1 Introduzione alla gestione dei diritti di accesso a T2S La gestione del processo di assegnazione degli access rights in T2S segue la struttura gerarchica del modello delle Party dettato dalla nuova piattaforma T2S. 78 Infatti, la struttura delle Party in T2S si sviluppa secondo una struttura gerarchica articolata su tre diversi livelli, ove è possibile distinguere: Party di I livello, ovvero il T2S Operator posto al vertice della struttura gerarchica; Party di II livello, ovvero il CSD e la CB; Party di III livello, ovvero i clienti del CSD (CSD participant) ed i clienti delle CB (Payment Bank). Il processo di assegnazione di ruoli e privilegi segue la struttura gerarchica descritta nello schema di cui sopra, in base al quale ogni soggetto è responsabile dell’ assegnazione di ruoli e privilegi agli utenti facenti parte delle categorie poste ad un livello sottostante della struttura gerarchica. Alla luce di quando detto, il T2S Operator è direttamente responsabile dell’ assegnazione di ruoli e privilegi ai CSD e CB che, conseguentemente, provvederanno ad assegnare i relativi ruoli e privilegi ai CSD Participant e Payment Bank. 8.2 Concetti e definizioni principali Al fine di agevolare la comprensione dei meccanismi alla base dell’ assegnazione di ruoli e privilegi, si fornisce di seguito una lista dei principali concetti e definizioni alla base della gestione degli access rights in T2S. 8.2.1 User Function I messaggi XML e le funzionalità della GUI rappresentano le modalità attraverso le quali un utente può interagire con T2S, rispettivamente in modalità A2A e U2A. 79 Sulla base del set di messaggi XML e delle funzionalità offerte dalla GUI, è possibile definire il set di «T2S user function» per gli utenti (ad esempio l’ invio di una istruzione di regolamento, creazione di una Party, etc), sia in modalità A2A che U2A. 8.2.2 Privilegi Un privilegio identifica la capacità di innescare le differenti «T2S user functions» e rappresenta l’elemento basilare per l’assegnazione dei diritti di accesso agli utenti. A seconda del loro ambito di applicazione, i privilegi possono essere distinti in: Privilegi di sistema: si riferiscono a «T2S user function» non applicabili a specifici dati statici o dinamici (esempio: una query per la valutazione dello status attuale della fase del settlement day); Privilegi oggetto: si riferiscono a «T2S user function» applicabili a specifici dati statici o dinamici (esempio: una funzionalità che mostra specifiche informazioni di un securities account). I privilegi di sistema vengono assegnati secondo un approccio top-down, come si evince dalla rappresentazione grafica di cui di seguito: I privilegi oggetto, a differenza della precedente categoria, vengono assegnati secondo un approccio top down e/o trasversale: 80 c 8.2.3 Secured Object Un “secured object” è un dato statico (party, titoli, securities account e T2S DCA) sul quale viene concesso un specifico privilegio-oggetto. 8.2.4 Secured Group Un «secured group» è un insieme omogeneo di «secured objects» (ad esempio, un gruppo di party o di securities account). 8.2.5 Ruolo Un ruolo può essere definito come un insieme di privilegi. 8.2.6 User Un utente è un soggetto o un’applicazione che interagisce con T2S attraverso le «T2S user function» disponibili. 8.2.7 Data Scope Alla luce della struttura gerarchica definita da T2S e descritta nella sezione introduttiva del seguente documento T2S definisce, per ogni singolo privilegio, il cosiddetto default data scope, ovvero l’ ambito predefinito di dati statici o dinamici ove il singolo utente può abilitare le funzioni di T2S. In particolare: Gli utenti del T2S Operator hanno visibilità sulla totalità di dati statici e dinamici e possono agire sui diversi oggetti statici e dinamici dei loro partecipanti solo in circostanze eccezionali e sulla base di specifici accordi con gli stessi; 81 Gli utenti del CSD e delle CB hanno visibilità sulla totalità di dati statici e dinamici appartenenti alla medesima entità legale; Gli utenti del CSD participant e le Payment Bank hanno visibilità sull’ insieme di dati statici e dinamici che risultano essere, direttamente ed indirettamente, legate alla medesima Party. Dal grafico proposto di seguito si evince come gli utenti X, Y e Z (posti ad un differente livello gerarchico del modello di Party in T2S) rientrino in un diverso default data scope. In particolare: L’ utente X, essendo un soggetto partecipante del CSD Part.B, acquisisce di default il data scope del CSD Part.B. Si noti che il data scope include anche il SAC2 in quanto unico conto titoli del CSD Part.B. Utente X non può inviare istruzioni di regolamento riferite ad altri conti titoli in T2S; L’utente Y del CSD1 acquisisce di default il data scope circostanziato nell’ area blu che include anche i conti titoli SAC1 e SAC2 poiché i suddetti conti titoli appartengono al CSD participant (quindi CSD Part.A e CSD Part.B) del CSD1. L’utente Y non può inviare istruzioni di regolamento riferite ad altri conti titoli in T2S che non facciano parte del suddetto data scope (cfr. area blu del grafico); L’utente Z del T2S Operator, essendo al primo livello della struttura gerarchica del modello delle Party in T2S, acquisisce di default un data scope (area verde) che include tutti i conti titoli in essere in T2S. Il default data scope può essere esteso o ridotto a seconda delle specifiche esigenze di business. 82 I due successivi paragrafi propongono due esempi rispettivamente di estensione e riduzione del default data scope. ESTENSIONE DEL DEFAULT DATA SCOPE Il seguente grafico mostra come l’ utente X, ovvero il soggetto cliente del CSD Part.B, acquisisce il data scope di default del CSD Part.B, inclusi tutti i conti titoli facenti parte della suddetta area (in questo caso il SAC2). A causa dell’ estensione del data scope, lo stesso utente X vede estendere l’ambito predefinito di dati statici o dinamici anche al conto titoli 5 (SAC5). RIDUZIONE DEL DEFAULT DATA SCOPE Il seguente grafico mostra come l’ utente X, ovvero il soggetto cliente del CSD Part.D, acquisisce il data scope di default del CSD Part.D, inclusi tutti i conti titoli facenti parte della suddetta area (in questo caso il SAC4 e SAC5). A causa della riduzione del data scope, lo stesso utente X vede ridurre l’ambito predefinito di dati statici o dinamici al solo conto titoli 4 (SAC5) e perde la visibilità sul conto titoli 5 (SAC5). 83 8.3 Configurazione degli access rights in T2S Si propone di seguito una breve descrizione dei principi alla base dell’ assegnazione di ruoli e privilegi ai diversi T2S Actors. 8.3.1 Configurazione utenti LINK TRA UTENTI E PARTY Ogni nuovo utente è direttamente collegato alla relativa Party. Infatti, attraverso il collegamento diretto con la Party interessata, ciascun utente eredita il default data scope della Party a cui è associato. Tuttavia, vi sono delle specifiche situazioni che costituiscono eccezione alla regola generale precedentemente descritta, ad esempio: Il “T2S Administrator” crea un nuovo soggetto amministratore di un CSD e di una CB; Il soggetto amministratore di un CSD crea un nuovo soggetto amministratore per uno dei suoi partecipanti; Il soggetto amministratore di una CB crea un nuovo soggetto amministratore per una sua payment bank. Si specifica che il legame tra un utente e la propria Party non può essere oggetto di modifica. PARTY ADMINISTRATOR 84 Ogni Party deve avere almeno un “Party administrator”, ovvero un utente al quale i privilegi sono concessi con la possibilità, a sua volta, di riassegnarli ad utenti e soggetti nell’ ambito del proprio default data scope. 8.3.2 Configurazione privilegi Ogni privilegio, successivamente alla sua prima creazione, è disponibile solo ed esclusivamente al soggetto amministratore del T2S Operator. Ciò implica che i soggetti amministratori di tutte le altre Party diversi dal T2S Operator non possono, a loro volta, concedere tali privilegi ai propri utenti. Un privilegio diventa disponibile a soggetti amministratori diversi dall’ amministratore del T2S Operator solo dopo che lo stesso privilegio è stato concesso alla relativa Party di riferimento. Da questo momento in poi, ogni singolo amministratore di una Party può concedere, a sua volta, i relativi privilegi. Alla luce di ciò, il processo di articola in due fasi: 1. STEP 1: privilegio concesso dal T2S Operator al CSD e CB. Dunque lo stesso risulta essere disponibile solo al soggetto amministratore del CSD/CB 2. STEP 2: privilegio concesso dal soggetto amministratore di un CSD/CB ai propri utenti (CSD/CB vs CSD participant/CB) 8.3.3 Configurazione ruoli I ruoli possono essere assegnati ad altri ruoli, utenti e partecipanti. Si noti che il processo di assegnazione dei ruoli in T2S (supportato dal modello gerarchico 1 RBAC descritto nel documento degli UDFS di T2S) è strettamente legato al concetto stesso di privilegio. Infatti: Nel momento in cui si concede un ruolo ad un utente, il soggetto in questione eredita tutti i privilegi assegnati a quello specifico ruolo; Nel momento in cui si concede un ruolo ad una Party , la stessa eredita tutti i privilegi assegnati a quello specifico ruolo. 1 RBAC: Role Based Access Controls (Ferraiolo, D.F., and Kuhn, D.R.1992) 85 Seguendo il medesimo processo logico di assegnazione di uno specifico ruolo, lo stesso può essere rimosso da altri ruoli, utenti e party. Infatti, specularmente rispetto a quanto descritto in precedenza, nel momento in cui un ruolo associato ad un utente o Party viene rimosso, lo stesso perde, conseguentemente, tutti i privilegi ad esso associati. 8.4 Processo di assegnazione degli access rights in T2S Affinché un party administrator possa assegnare privilegi agli utenti facenti parte della medesima party, gli stessi devono essere stati preventivamente assegnati alla party stessa. Alla luce di quanto detto, il seguente schema illustra gli step necessari per l’assegnazione del privilegio P agli utenti del CSD o della CB (ovvero Party A). In particolare, come si evince dal grafico di cui sopra: 1. L’utente X, essendo un Party administrator del T2S Operator, ha la facoltà di concedere il privilegio P alla Party A; 2. L ‘utente Y, essendo Party administrator del Party A ha, a sua volta, la facoltà di concedere il privilegio P a tutti gli user facenti parte del medesimo livello gerarchico (ovvero User Y1 ed User Y2). 86 Il medesimo processo logico si applica ogni qual volta un CSD o una CB proceda con l’assegnazione dei rispettivi ruoli e privilegi ai propri partecipanti, ovvero ai CSD participant e Payment Bank. Il seguente grafico illustra gli step per l’assegnazione del privilegio P dal CSD ai CSD participant e dalla CB alle Payment Bank: Il grafico evidenzia i tre differenti step da seguire per l’assegnazione del privilegio P: 1. L’utente X, essendo un Party administrator del T2S Operator, ha la facoltà di concedere il privilegio P alla Party A (ovvero al CSD o CB); 2. L ‘utente Y, essendo Party administrator del Party A ha, a sua volta, la facoltà di concedere il privilegio P alla Party B (ovvero CSD participant o Payment Bank) 3. L’utente Z, essendo Party administrator del Party B, ha la facoltà di assegnare il privilegio P ai suoi utenti (nell’ esempio di cui sopra Z1 e Z2). Inoltre si noti che l’utente Y1, in quanto party administrator della Party A, può a sua volta assegnare il privilegio P agli utenti Y1, purchè siano soggetti facenti parte capo al medesimo Party. Alla luce di quanto detto, si noti che il processo di configurazione degli access rights in T2S può innescarsi a livello di Party o a livello di singolo utente. 8.4.1 Access rights a livello di Party Per ciò che concerne la configurazione degli access rights a livello di Party, si noti che il soggetto amministratore del T2S Operator è colui in capo al quale spetta l’ onere di assegnare il set predefinito di ruoli e privilegi al CSD e della CB. Il seguente grafico ne propone un esempio: 87 Successivamente, i soggetti Party administrator di ogni CSD e CB hanno, conseguentemente, la possibilità di assegnare un set predefinito di ruoli e privilegi a tutti i propri partecipanti, siano essi CSD Participant o Payment Bank. 88 8.4.2 Access rights a livello di utenti Successivamente la configurazione degli access rights a livello di Party, ogni singolo party administrator può, a sua volta, concedere access rights ai singoli user, assegnando gli appropriati ruoli e privilegi a tutti gli utenti che fanno capo al medesimo Party. 8.5 Gestione decentralizzata degli access rights in T2S Come precedentemente descritto, la gestione degli access rights in T2S riflette in toto il modello della relazione esistente tra le party in T2S, sviluppato ed articolato su tre differenti livelli gerarchici. Si propone di seguito uno schema che sintetizza le principali attività in capo al T2S Operator, CSD/CB e CSD Participant/PB relativamente alla gestione degli access rights, in linea con la struttura gerarchica e decentralizzata delle Party in T2S. 89 Per maggiori dettagli informativi si faccia riferimento alla documentazione resa pubblica dalla ECB a seguito di un workshop tenutosi lo scorso luglio 2012 a Francoforte sul tema degli access rights:http://www.ecb.europa.eu/paym/t2s/governance/extmtg/html/mtg43.en.html Per informazioni di ulteriore dettaglio vi invito a consultare la documentazione tecnica resa disponibile dalla ECB nell’ apposita sezione documentale. In particolare: T2S User Detailed Functional Specifications (UDFS): http://www.ecb.europa.eu/paym/t2s/pdf/UDFS_v1_2_1.pdf?02dbde3be45b2d0bf5a5afcf4de 34f36 T2S User Handbook (UHB): http://www.ecb.europa.eu/paym/t2s/pdf/User_Handbook_v1.0.pdf?cc76cbb67593fe9e8b48 9e733a315bea 90 9 ALLEGATO A: DETTAGLIO DATI STATICI PER T2S 9.1 Introduzione Questo capitoli si prefigge l’obiettivo di rendere noto ai clienti, siano essi partecipanti diretti (DCP) o indiretti (ICP) alla piattaforma T2S, l’insieme di informazioni necessarie a Monte Titoli per la configurazione in T2S, con indicazione delle corrispondenti modalità e regole di migrazione adottate da Monte Titoli. Tale visione è puramente logica e tutti i dettagli pratici per la configurazione saranno illustrati nel manuale d’uso del web tool per la configurazione dei dati statici. Al fine di razionalizzare l’intero insieme degli elementi di configurazione forniti da Monte Titoli ai propri clienti, si è scelto di raggrupparle nei seguenti schemi logici: 1. Informazioni relative al Party in T2S 2. Informazioni relative al Technical Address network service link 3. Associazione Negoziatore/Liquidatore e relativi conti di regolamento (LIQDEF) 4. Associazione Negoziatore/General Clearing Member/Liquidatore del General Clearing Member (CCPNEG) 5. Eccezione per mercato dell’ associazione Negoziatore/Liquidatore (LIQNEG) 6. Struttura dei conti per il Servizio di gestione accentrata 7. Coordinate per il regolamento contante di operazioni DVP 8. Coordinate per i regolamenti relativi alle corporate action in T2S 9. Coordinate per i pagamenti relativi alle corporate action in T2, con indicazione degli elementi di configurazione necessari nel caso in cui il soggetto si avvalga o meno di una banca tramite in T2. Inoltre, al fine di agevolare la lettura delle tabelle proposte, si fornisce di seguito una breve descrizione delle diverse colonne che compongono le tabelle stesse, le quali risultano così articolate: “N.” = numero d’ordine del dato “Nome colonna” = nome del dato o della colonna “Formato” = formato del dato o della colonna “Descrizione “ = descrizione e significato del dato/colonna “Commenti” = eventuali commenti aggiuntivi e necessari. Non si applica alle prime due tabelle. 91 “Dati esistenti in MT [AS-IS]” = indica eventuali dati attualmente in essere nei sistemi Monte Titoli con identificazione delle regole di mappatura delle dette informazioni e modalità di traduzione delle stesse in T2S. In particolare: o Il valore “X” indica che il valore relativo al dato in questione è attualmente presente nei sistemi legacy di Monte Titoli o Il valore “n.a.” indica che il valore relativo a quel dato non è presente nei sistemi di Monte Titoli ma è specifico della nuova piattaforma T2S “Nuovi Dati in T2S”, i quali possono essere: o “assegnati di default da MT” = valore assegnato di default da Monte Titoli in fase di migrazione al dato di interesse; o “Forniti obbligatoriamente dal Cliente” = il valore da assegnare al dato deve obbligatoriamente essere fornito dal cliente. In assenza di comunicazione del dato in questione da parte del cliente, Monte Titoli non può procederne alla migrazione. In particolare, si riporta di seguito il significato logico delle tre opzioni contenute nella colonna “New Data in T2S”: o “n.a”: quando il dato è assegnato di default da Monte Titoli e non è prevista alcuna possibilità di modifica da parte del cliente; o “ammesse possibili variazioni”: quando il dato è assegnato di default da Monte Titoli ma è prevista la possibilità per il cliente di apportare modifiche al campo stesso rispetto a quanto valorizzato da Monte Titoli; o “obbligatorio”: quando il dato, non facendo parte del set informativo conosciuto da Monte Titoli, deve essere obbligatoriamente comunicato dal cliente. Queste sono le infomazioni "nuove", tipicamente richieste dall'avvento di T2S (esempio: indicazione del Network Service, identificativo conto DCA, identificativo CMB, etc...). Si noti che le righe evidenziate in “giallo” indicano che il contenuto è ripreso da tabelle/schemi precedenti e pertanto non si applicano le considerazioni riguardo ai valori da assegnare o assegnati in quanto già trattati. Tutte le righe evidenziate in giallo in una data tabella costituiscono un unico elemento informativo che può essere sostituito in toto ove appunto già inserito in precedenza. 92 9.2 Party La tabella proposta di seguito riporta l’insieme di informazioni necessarie a Monte Titoli per la configurazione dei clienti e riferibili al nuovo concetto di PARTY introdotto con l’ avvento della nuova piattaforma T2S. Nuovi dati in T2S N. Dati esistenti in MT Nome colonna Formato Descrizione [AS-IS] 1 2 Parent BIC Tipologia CHAR (11) di partecipante BIC della System Entity responsabile del party Possibili valori: Classificazione delle party: CSDP CSDP=CSD Participant ECSD ECSD = External CSD X X Assegnati di default Forniti obbligatoriamente da MT dai clienti MOTI IT MM XXX n. a. Valori assegnati di n. a. default da MT Ammesse Data di attivazione del Party. La 3 Data di apertura DATE stessa deve necessariamente essere maggiore o uguale 27/04/2015 al variazioni nel caso in cui il Data X impostata Monte 27/04/15 Titoli da Party assegnato di Default al da MT non coincidesse con le esigenze del cliente e dovesse variato 93 possibili pertanto essere Momento a decorrere quale il Party 4 Data di chiusura DATE dal non risulta essere più attivo. La stessa Ammesse X Null deve necessariamente essere possibili variazioni per le ragioni su esposte superiore alla data di apertura. Ammesse possibili variazioni in relazione alle necessità di setup del CMB 5 Party BIC CHAR (11) BIC del PARTY X Valore assegnato di e/o di matching. default da MT In ogni caso almeno un valore deve presente Valore esistente in MT 6 Long Name VARCHAR (350) Indicazione estesa della denominazione del Party X assegnato sulla base del nome della Legal n.a. Entity Valore esistente in MT 7 Short Name VARCHAR (35) Indicazione abbreviata della denominazione del Party X assegnato sulla base del nome della Legal Entity 94 n.a. essere 8 Indirizzo VARCHAR (70) 9 Numero civico VARCHAR (16) Codice 10 di avviamento VARCHAR (16) postale 11 12 13 Città Provincia VARCHAR (35) o Stato Codice Paese del VARCHAR (35) CHAR (2) Indirizzo del Party Indicazione X specifica del numero civico riferito al Party Codice di avviamento postale del Party Indicazione della città del Party Indicazione della provincia o Stato del Party Indicazione del codice del Paese X X X Valore esistente in MT n.a. X X I clienti ICP non devono inserire/variare Valorizzato Si applica ai soli clienti DCP. 14 Technical Address VARCHAR (256) Indicazione address del technical della (distinguished name). party nulla in questo dato. inizialmente da Monte n. a. Titoli con un valore fittizio tipo “valore da assegnare” Obbligatorio per i soli clienti DCP. Questo è un nuovo dato specifico di T2S per consentire la connessione diretta alla piattaforma T2S 95 9.3 Technical address network service link La seguente tabella è di interesse per i soli clienti DCP. I clienti ICP possono ignorare quanto qui descritto ai fini della loro migrazione a T2S. Si noti che la tabella di cui al capitolo 9.2. riporta al capo numero 14 l’ informazione riferita al “Technical Address”. Gli elementi informativi di cui ai campi 3 e 4 della seguente tabella consentono, invece, di designare un’associazione tra i technical address ed il corrispondente network service provider del quale il cliente si avvale. Nuovi dati in T2S Dati esistenti in N. Assegnati di Assegnati di default default da MT da MT MT Descrizione Assegnati di default da MT [AS-IS] 1 Parent BIC CHAR (11) 2 Party BIC CHAR (11) 3 4 Technical Address Network Service BIC della System Entity responsabile del Party BIC del party Incazione del VARCHAR (256) address Forniti obbligatoriamente dai clienti X X Cfr. Tabella 9.2Party technical della Party n. a (distinguished name) VARCHAR (35) n. a 96 n. a. Obbligatorio 9.4 Associazione di default negoziatore/liquidatore e relativi conti di regolamento: (LIQDEF) New data in T2S Dati N. Nome Colonna Formato Descrizione Commenti esistenti in Assegnati di MT default da MT Forniti obbligatoriame nte dai clienti [AS-IS] Sistema di liquidazione. Può essere in X-TRM sono quasi assegnato uno dei sempre presenti per seguenti valori: uno stesso soggetto 1 Sistema Dal momento che oggi di liquidazione due configurazioni, configurazione una relativa lorda e netta di liquidazione Express l’altra T2S: se II Netta: per lorda relativa netta, coincidono verificarsi alla e alla potrebbero delle configurazione situazioni nelle quali i netta due valori differiscono Lorda: per 97 In caso di valori “Netta” e “Lorda” X n.a. ci si aspetta che uno dei due sia chiuso configurazione lorda Indicazione del tipo di negoziazione. Può assumere uno dei seguenti valori: 2 Tipo negoziazione P T BLANK=se X Assegnato di default da MT Ammesse possibili variazioni valgono P e T contemporane amente 3 4 Codice BIC del negoziatore Codice CED del negoziatore Indicazione del Tali codice del saranno fornite da MT BIC informazioni soggetto qualora esistenti nei negoziatore propri archivi Indicazione del codice del CED Valori X Codice CED Valori X soggetto del Indicazione n.a. default da MT assegnati di n. a. default da MT negoziatore 5 assegnati di X del 98 Valori Ammesse liquidatore codice CED del assegnati di possibili default da MT variazioni della Valori Ammesse quale assegnati di possibili default da MT variazioni Identificativo Ammesse soggetto liquidatore L’indicazione Flag Indicatore 6 liquidatore di default del (SI/NO) permette identificare di se X il liquidatore è quello di default o meno Indicazione data 7 nella Inizio associazione inizia liquidatore associazione della quale l’ del negoziatore con il Si noti che la data è sempre quella di X regolamento (SD) liquidatore Indicazione data 8 Fine associazione liquidatore nella termina associazione l’ del negoziatore con il Si noti che la data è sempre quella X di regolamento (SD) liquidatore 9 Codice del conto Indicazione X del 99 regolamento codice del conto di regolamento secondo la codifica conto possibili assegnato da variazioni MT del CSD Indica se il conto di regolamento 10 Indicatore conto di default è quello di default o no per quella data combinazione X di Tipo negoziazione/ liquidatore Indicazione 11 Inizio associazione conto data nella della Valori Ammesse quale assegnati di possibili default da MT variazioni inizia X l’associazione conto Indicazione 12 Fine conto associazione data nella della quale termina X l’associazione conto 100 9.5 Associazione Negoziatore/GCM/Liquidatore del GCM (CCPNEG) New data in T2S Dati esistenti in N. Nome Colonna Formato Descrizione Commenti MT Assegnati di Forniti default da obbligatoriame MT nte dai clienti [AS-IS] Sistema di liquidazione. Può essere assegnato uno dei seguenti valori: 1 Sistema di liquidazione T2S: oggi in X-TRM sono quasi se sempre presenti per stesso soggetto due lorda e netta di configurazioni, una Express relativa alla II Netta: liquidazione lorda e per l’altra relativa configurazione netta, netta verificarsi Lorda: per alla potrebbero delle situazioni nelle quali 101 Cfr9.4: uno configurazione coincidono Dal momento che Associazione di X n.a. default negoziatore/liqu idatore e relativi conti di regolamento: (LIQDEF) 2 3 configurazione i lorda differiscono Specificazione Tipo valori del Valori tipo di negoziazione negoziazione due X “proprietà” o “terzi” Indicazione del Codice BIC del codice del negoziatore soggetto BIC default da MT Valori X 4 Indicazione del Codice CED del codice del negoziatore soggetto Valori X Provenienza Indica la provenienza di X mercato 6 7 Mercato di negoziazione Codice della CCP CED Indicazione mercato del di X negoziazione Indicazione assegnati di default da MT negoziatore 5 assegnati di default da MT negoziatore CED assegnati di del X codice CED della 102 Valori Ammesse assegnati di possibili default da MT variazioni Valori Ammesse assegnati di possibili default da MT variazioni Valori Ammesse assegnati di possibili CCP Codice CED dell’ 8 aderente del GCM 10 11 12 X Indicazione del codice del CED X soggetto liquidatore del GCM Codice del conto di regolamento Data CED generale Codice CED del liquidatore codice del dell’aderente generale 9 Indicazione inizio validità Data fine validità Indicazione default da MT variazioni Valori Ammesse assegnati di possibili default da MT variazioni Valori Ammesse assegnati di possibili default da MT variazioni del Ammesse codice del conto di X possibili regolamento variazioni Indicazione della data inizio di X validità Indicazione Valori Ammesse assegnati di possibili default da MT variazioni Ammesse della X data di fine validità possibili variazioni 103 9.6 Eccezione per mercato dell’ associazione negoziatore/liquidatore (LIQNEG) New data in T2S N. Nome Colonna Formato Descrizione Sistema Commenti Dal essere assegnato uno dei 1 Sistema se lorda e netta di liquidazione Express II coincidono in MT di [AS-IS] da MT default Forniti obbligatoria mente dai clienti che oggi in X-TRM sono quasi sempre per uno stesso soggetto due T2S: configurazione di momento presenti seguenti valori: Assegnati di liquidazione. Può Dati esistenti Netta: configurazioni, una relativa alla liquidazione lorda e l’altra relativa netta, per potrebbero verificarsi delle situazioni nelle quali i netta due per configurazione 104 n.a. alla configurazione Lorda: X differiscono valori 9.4Tabella: Associazione di default negoziatore/liq uidatore e relativi conti di lorda Specificazione del 2 Tipo negoziazione tipo di X negoziazione 3 Codice BIC del negoziatore del Codice CED codice del soggetto del negoziatore X del Codice CED codice del soggetto del liquidatore del codice del soggetto X 6 Codice del regolamento conto da assegnati di default da Valori X liquidatore Indicazione default MT Indicazione CED assegnati di Valori negoziatore 5 da MT Indicazione CED default Valori negoziatore 4 assegnati di MT Indicazione BIC regolamento: Valori assegnati di default da MT Identificativo del codice del conto di X conto T2S regolamento assegnato secondo la codifica da MT 105 (LIQDEF) del CSD 7 Provenienza Indica la provenienza di Valori X mercato 8 9 Mercato negoziazione Data inizio validità di assegnati di default da MT Indicazione mercato Valori del di X negoziazione default da MT Indicazione della data inizio di assegnati di Valori X validità assegnati di default da MT Valori 10 Data fine validità Indicazione della data di fine validità X assegnati di default MT 106 da Ammesse possibili variazioni Ammesse possibili variazioni Ammesse possibili variazioni Ammesse possibili variazioni 9.7 Struttura dei conti per il servizio di gestione accentrata New data in T2S Dati N. Nome Colonna Formato Descrizione BIC 1 Parent BIC CHAR (11) della Entity Commenti esistenti in MT di [AS-IS] da MT System responsabile Assegnati X del Party default Forniti obbligatoria mente dai clienti MOT IT MM XXX Cfr.9.2 Valore Indicazione del BIC 2 Party BIC CHAR (11) del Party al quale è X associato il conto 3 Codice ABI depositario del di default da MT Indicazione del codice del ABI soggetto owner del Valore X Securities account assegnato di default da 4 T2S Account ID n.a. MT Valore Codice TabellaParty assegnato identificativo del conto in T2S n.a. assegnato di default da MT 107 Non ammesse variazioni Identificativo 5 Codice del conto Securities del Account secondo la codifica Valore X ABI n.a. dell’ operatività del soggetto. Può ricoprire Ruolo di default da MT Specificazione 6 assegnato uno dei Valore X seguenti ruoli: emittente intermediario assegnato di default da n.a. MT Indicazione del tipo conto. Può assumere uno 7 8 dei seguenti valori: Tipo conto Tipo Collateral Conto P: proprietà T: terzi L: liquidatore X Indicazione del tipo conto collateral. 108 Ammesse assegnato possibili di default da variazioni ma MT non attese Valore X Può assumere uno Valore assegnato di default da n. a. dei seguenti valori: G: giver R: receiver MT Il tipo conto collateral deriva dalla partecipazione ad XCOM ed è assegnato a seconda della configurazione attualmente presente. 9 Data di apertura del securities account Indicazione della Deve Valore essere data di apertura del maggiore o uguale conto titoli al 27/04/2015 X assegnato di default da MT Ammesse possibili variazioni Non sono Deve 10 Data di chiusura del securities account Indicazione della attese necessariamente data di chiusura del essere successiva conto titoli alla data di apertura del conto titoli variazioni a X Null meno che il securities account non venga chiuso 109 dopo la data di go-live I conti con blocco Può assumere uno dei seguenti valori di 11 Blocco Operativo operativo, indipendentemente dal fatto che siano default: con o senza saldo, S = si N = no Valore X assegnato di default da verranno definiti e n.a MT configurati a livello di T2S Indicazione indicatore and 12 Hold/Release Indicator dell’ di Release. assumere uno Hold Può dei seguenti valori: H= Hold R=Released Ammesse n.a. RELE possibili variazioni 110 9.8 Coordinate per il regolamento contante operazioni DVP New data in T2S N. Nome Colonna Formato Descrizione BIC 1 Parent BIC CHAR (11) della Entity Commenti Dati esistenti Assegnati di Forniti in MT default da obbligatoriame [AS-IS] MT nte dai clienti System responsabile X del Party Indicazione del BIC 2 Party BIC CHAR (11) del Party al quale è X associato il conto 3 4 T2S Account ID Codice identificativo X del conto in T2S Codice ABI del Indicazione del depositario codice del ABI X 111 Cfr. 9.7 Tabella Struttura dei conti per il servizio di gestione soggetto owner del accentrata Securities account Identificativo 5 Codice del conto Securities del Account X secondo la codifica ABI Indicazione del tipo conto. Può assumere uno 6 Tipo conto dei seguenti valori: P: proprietà T: terzi L: liquidatore Specificazione 7 Ruolo X dell’ operatività del soggetto. Può ricoprire uno dei X del X seguenti ruoli: 8 Codice ABI del emittente intermediario Indicazione 112 Valore n.a. soggetto codice pagatore soggetto pagatore se anche ABI del assegnato di default da partecipante MT Monte Titoli Indicazione del BIC 9 CB Parent BIC CHAR (11) n.a. della CB owner del Party L’informazion Indicazione del BIC 10 PB Party BIC CHAR (11) n.a. della PB owner del n.a. conto DCA e è relativa Il all’identificati fornire vo T2S del obbligatoriament DCA [che si e l’Identificativo basa su due T2S del DCA su livelli: due livelli (BIC deve della della CB + BIC CB+BIC della PB) e la della PB] non PB è disponibile confermare a MT 113 BIC cliente deve n. a . L’informazion 11 Identificativo conto DCA e è relativa Il all’identificati fornire Identificativo T2S del vo T2S del obbligatoriament DCA che è utilizzato DCA [che si e basa su due T2S del DCA su livelli: due livelli (BIC per i pagamenti in associazione n.a. al conto titoli BIC cliente deve l’Identificativo della della CB + BIC CB+BIC della PB) e la PB della non PB] deve confermare è disponibile a MT Identificativo T2S del n. a. Credit Memorandum Balance 12 Identificativo CMB assegnato Il L’informazion dal proprietario del n. a. DCA che è utilizzato e relativa per i pagamenti in all’identificati associazione vo T2S del al CMB non è conto titoli 114 cliente deve fornire obbligatoriament e l’Identificativo T2S del CMB disponibile a MT Indicazione del link di default. Assume valore pari a “True” 13 Default Link BOOLEAN quando il conto DCA è utilizzato come conto di default per il regolamento del contante in T2S 14 15 Data inizio validità del link Data fine validità del link Indicazione Si specifica che per un dato securities account ci può essere uno e un solo link di default n. a. n. a. Mandatory n. a. 22/06/2015 Mandatory ad un conto DCA, tutti i link con altri DCA saranno NON di default della data di inizio validità del link Indicazione della Nessun data di fine validità n. a. del link valore per significare 115 n.a. data aperta Se assume “true”, T2S utilizzare 16 Collateralisation Link conto BOOLEAN valore può Assegnato questo titoli da MT sulla per operazioni di auto- X collateral fatte salve tutte le altre base Ammesse dell’attuale possibili flag di self variazioni collateralizati condizioni on necessarie Se assume “true”, T2S valore può usare il link tra il 17 Cash Settlement Link Valore securities account ed BOOLEAN il T2S DCA per il regolamento della gamba della cash X assegnato di default da MT settlement instruction. 116 Ammesse possibili variazioni 9.9 Pagamenti relativi alle corporate action in T2S Al fine di facilitare le attività di configurazione del cliente questo schema sarà popolato con valori predefiniti non significativi che il cliente deve provvedere a sostituire con valori significativi. New data in T2S Dati esistenti N. Nome Colonna Formato Descrizione Commenti in Assegnati di default MT MT [AS-IS] BIC 1 Parent BIC CHAR (11) della Entity da Forniti obbligatoria mente dai clienti System responsabile X del Party Indicazione del BIC 2 Party BIC CHAR (11) del Party al quale è X associato il conto 3 4 Codice T2S Account ID Codice ABI depositario identificativo del conto in T2S del Indicazione del codice del ABI soggetto owner del X Cfr. tabella 9.7Struttura dei X conti per il servizio di gestione accentrata Securities account 117 Identificativo 5 Securities Codice del conto del Account secondo la codifica X ABI Indicazione del tipo conto. Può assumere uno 6 dei seguenti valori: Tipo conto P: proprietà T: terzi L: liquidatore Specificazione 7 dell’ operatività del soggetto. Può ricoprire Ruolo X uno dei X seguenti ruoli: emittente intermediario Indicazione del BIC 8 CB Parent BIC CHAR (11) n.a. L’informazion della CB owner del e Party all’identificativ 118 relativa o Indicazione del BIC 9 PB Party BIC CHAR (11) della PB owner del n.a. conto DCA T2S del DCA [che si fornire basa su due obbligatoriam livelli: ente BIC della CB+BIC l’Identificativo della PB] non T2S del DCA è su due livelli a disponibile MT che pertanto valore 10 Identificativo conto DCA per i pagamenti in associazione al conto titoli il fittizio “da definire” DCA che è utilizzato (BIC della CB + BIC della assegna Identificativo T2S del Il cliente deve PB) e la PB deve confermare Il cliente deve n.a. fornire obbligatoriam ente l’Identificativo T2S del DCA su due livelli (BIC della CB + BIC della PB) e la PB deve 119 confermare n. a. 11 Identificativo CMB Identificativo T2S del L’informazion Credit Memorandum e Balance all’identificati dal assegnato proprietario del DCA che è utilizzato n. a. relativa fornire vo T2S del CMB non è per i pagamenti in disponibile a associazione al conto MT titoli pertanto assegna che il valore fittizio 120 Il cliente deve obbligatoriam ente l’Identificativo T2S del CMB “da definire” Specificazione della tipologia di operazione. Tipologie di pagamento presenti in Le 12 Tipologia operazione aumento di capitale ed esercizio Warrant di fondi si riferiscono a quelle in essere in Harmonisation Custody. disponibile solo “Pagamento Titoli di Stato” in quanto il pagamento è appunto interessi/rimborso previsto pagamenti su denominati in divisa estera pagamenti su 121 la tipologia pagamento titoli di pagamento progetto dividenti/proventi tipologie MT con l’avvio del pagamento Titoli rende Monte Titoli: Monte obbligatoria mente in T2S “Pagamento su Titoli Stato” di Obbligatorio Titoli di Stato 13 Codice ABI del soggetto pagatore Indicazione del codice del ABI soggetto pagatore. Potrebbe essere assente in caso di soggetto non X n.a. n.a. n. a. 27/04/2015 n.a. pagatore partecipante a MT Indicazione della data di inizio validità dell’associazione 14 Data inizio validità conto titoli/conto cash (DCA) al fine dellagestione dei pagamenti relativi a CA Nessun 15 Data fine validità Indicazione della data di fine validità n. a. valore per significare data aperta 122 n.a. 9.10 Pagamenti relativi alle corporate action in T2 Si ricorda che questi dati sono già presenti in Monte Titoli in quanto già utilizzati per la gestione ordinaria dei pagamenti relativi a Corporate Action. New data in T2S Dati esistenti N. Nome Colonna Formato Descrizione Commenti in Assegnati di default MT MT [AS-IS] da Forniti obbligatoria mente dai clienti BIC della System 1 Parent BIC CHAR (11) Entity responsabile X del Party Indicazione del BIC 2 Party BIC CHAR (11) del Party al quale è X Cfr. 9.7 Tabella: Struttura dei associato il conto conti per il servizio di gestione 3 4 Codice identificativo T2S Account ID Codice ABI depositario X del conto in T2S del Indicazione del codice del ABI X soggetto owner del 123 accentrata Securities account Identificativo 5 del Securities Account Codice del conto X secondo la codifica ABI Indicazione del tipo conto. Può assumere uno 6 dei seguenti valori: Tipo conto X P: proprietà T: terzi L: liquidatore Specificazione dell’ 7 operatività del soggetto. Può ricoprire Ruolo uno dei X seguenti ruoli: 8 Tipologia operazione di emittente intermediario Specificazione della Le tipologia pagamento di 124 tipologie di si operazione. Tipologie riferiscono a quelle di in essere in MT con pagamento presenti l’avvio del progetto in Monte Titoli: Harmonisation Custody aumento di capitale ed esercizio Warrant pagamento dividenti/proven ti fondi pagamento interessi/rimbor so pagamenti su titoli denominati in divisa estera corrispettivi RCC 125 X n.a. Ammesse possibili variazioni ELEMENTI DI CONFIGURAZIONE AGGIUNTIVI NECESSARI NEL CASO IN CUI IL SOGGETTO SI AVVALGA DI UNA BANCA TRAMITE IN T2 9 10 ABI banca d’ appoggio Codice ABI X banca di appoggio ABI banca tramite Codice ABI n.a. possibili variazioni Ammesse della X banca tramite n.a. possibili variazioni Indicazione 11 Ammesse della del Identificativo conto conto RTGS della Target2 della banca banca tramite tramite RTGS Ammesse X n.a. di possibili variazioni riferimento Indicazione 12 Data inizio validità della data di inizio validità X del conto titoli al Ammesse conto contante Indicazione 13 Data fine validità n.a. della variazioni Ove non valorizzata data di fine validità indica del conto titoli al relazione è attiva. 126 che la possibili X conto contante Valorizzare questo dato significa che si vuole chiudere l’associazione conto titoli/conto contante ELEMENTI DI CONFIGURAZIONE AGGIUNTIVI NECESSARI NEL CASO IN CUI IL SOGGETTO NON SI AVVALGA DI UNA BANCA TRAMITE IN T2 Indicazione Identificativo 14 conto RTGS della banca d’ appoggio 15 ABI conto del RTGS Target2 della banca d’appoggio d’ appoggio Codice ABI validità n.a. di possibili variazioni Ammesse della X banca di appoggio Indicazione 16 X riferimento banca Data Ammesse inizio n.a. possibili variazioni della Ammesse data di inizio validità X del conto titoli al n.a. possibili variazioni conto contante 127 Ove non valorizzata indica Indicazione 17 Data fine validità della che la relazione è attiva. data di fine validità Valorizzare questo del conto titoli al dato significa che si conto contante vuole chiudere l’associazione conto titoli/conto contante 128 X 10 Allegato B – Effetti sulle operazioni delle variazione della modalità di adesione alla CCP e/o cambio del soggetto liquidatore Al fine di agevolare la comprensione di quanto descritto al capitolo 6 si invita alle lettura dell’allegato B che propone evidenza empirica degli effetti sui dati delle operazioni conseguenti alle variazioni delle modalità di adesione alla CCP e/o cambio del soggetto liquidatore durante la migrazione a T2S. 11 Allegato C – Access Rights per DCP Si fornisce in allegato un elenco dettagliato dei diritti di accesso che Monte Titoli fornirà ai propri clienti DCP. 129 Disclaimer Heading Questo documento contiene testi, dati, grafici, fotografie, illustrazioni, elaborazioni, nomi, loghi, marchi registrati e marchi di servizio e informazioni (collettivamente le “Informazioni”) che si riferiscono a Monte Titoli S.p.A. (“MT” o “la Società”). MT cerca di assicurare l’accuratezza delle Informazioni, tuttavia le Informazioni sono fornite nello stato in cui si trovano (“AS IS”) e secondo disponibilità (“AS AVAILABLE”) e possono, pertanto, essere non accurate o non aggiornate. A seconda delle circostanze, le Informazioni contenute in questo documento possono o non possono essere state preparate da MT, ma in ogni caso sono fornite senza alcuna assunzione di responsabilità da parte di MT. La Società non garantisce l’accuratezza, la puntualità, completezza, appropriatezza di questo documento o delle Informazioni per il perseguimento di scopi particolari. Nessuna responsabilità è riconosciuta da parte di MT per ogni errore, omissione o inaccuratezza delle Informazioni contenute nel documento. Nessuna azione dovrebbe essere (o non essere) intrapresa facendo affidamento sulle Informazioni contenute nel documento. Resta inteso che non verrà assunta alcuna responsabilità per le conseguenze che possano derivare da qualunque azione intrapresa sulla base delle Informazioni. La Società promuove e offre i servizi Post Negoziazione secondo modalità eque, trasparenti e non discriminatorie e sulla base di criteri e procedure che assicurano l'interoperabilità, la sicurezza e la parità di trattamento tra infrastrutture di mercato, a tutti i soggetti che ne facciano domanda e siano a ciò qualificati in base alle norme nazionali e comunitarie e alle regole vigenti nonché alle determinazioni delle competenti Autorità.
© Copyright 2024 ExpyDoc
