Upload
others
View
64
Download
0
Embed Size (px)
Citation preview
1
MIGRATION PREPARATION
SCHEDULE
T2S PROJECT
Versione 1.0
Sommario
1 GESTIONE DEL DOCUMENTO 5
1.1 Cronologia del documento 5
1.2 Acronimi ed abbreviazioni 5
1.3 Documentazione di riferimento 6
2 OBIETTIVO DEL DOCUMENTO 7
3 PANORAMICA DEL PROCESSO DI MIGRAZIONE A T2S 8
3.1 Pianificazione della migrazione 8
3.2 Attori coinvolti 9
3.3 Composizione della prima finestra 11
3.4 Composizione della seconda finestra 14
3.5 Composizione della terza finestra 15
3.6 Composizione della quarta finestra 16
4 PIANO DELLE ATTIVITA’ DI MIGRAZIONE 18
4.1 Attività e Synchronisation Point 18
5 MIGRAZIONE DEI DATI STATICI 25
5.1 Introduzione alla migrazione dei dati statici 25
5.2 Consegna ai clienti dei dati necessari per la configurazione in T2S 26
5.2.1 Dati dei Servizi di pre-settlement 29
5.2.2 Dati dei Servizi di Liquidazione 30
5.2.3 Dati dei Servizi di regolamento estero (DVP Cross-Border) 31
5.2.4 Dati dei Servizi di gestione accentrata emittenti ed intermediari 31
5.3 Conferma da parte dei clienti dei dati di configurazione forniti da Monte Titoli 33
5.4 Trasferimento dei dati ufficiali di configurazione al sistema di test 35
5.5 Pre-Migration Dress Rehearsal 35
5.6 Frozen Period 36
5.7 Go – live dei dati statici in T2S 37
5.8 Finestra di contingency per il caricamento dei dati statici 37
6 VARIAZIONI ALLE MODALITA’ DI PARTECIPAZIONE AI SERVIZI DI MONTE TITOLI 38
6.1 Modifica del soggetto pagatore 39
6.1.1 Modifica del soggetto pagatore nell’ ambito del servizio di gestione accentrata 39
6.1.2 Modifica del soggetto pagatore nell’ ambito del servizio di liquidazione 39
6.2 Modifica del soggetto liquidatore e della tipologia di adesione alla CCP 40
6.2.1 Modello operativo “A” o Modello di marginazione lordo 42
6.2.2 Modello operativo “B” o Modello di marginazione netto 53
7 T2S USER TESTING & MIGRATION TESTING 74
7.1 Introduzione 74
7.2 User Testing: attori coinvolti 74
7.3 User Testing 75
7.4 Migration Testing 77
8 GESTIONE DEGLI ACCESS RIGHT IN T2S (solo per DCP) 78
8.1 Introduzione alla gestione dei diritti di accesso a T2S 78
8.2 Concetti e definizioni principali 79
8.2.1 User Function 79
8.2.2 Privilegi 80
8.2.3 Secured Object 81
8.2.4 Secured Group 81
8.2.5 Ruolo 81
8.2.6 User 81
8.2.7 Data Scope 81
8.3 Configurazione degli access rights in T2S 84
8.3.1 Configurazione utenti 84
8.3.2 Configurazione privilegi 85
8.3.3 Configurazione ruoli 85
8.4 Processo di assegnazione degli access rights in T2S 86
8.4.1 Access rights a livello di Party 87
8.4.2 Access rights a livello di utenti 89
8.5 Gestione decentralizzata degli access rights in T2S 89
9 ALLEGATO A: DETTAGLIO DATI STATICI PER T2S 91
9.1 Introduzione 91
9.2 Party 93
9.3 Technical address network service link 96
9.4 Associazione di default negoziatore/liquidatore e relativi conti di regolamento: (LIQDEF) 97
9.5 Associazione Negoziatore/GCM/Liquidatore del GCM (CCPNEG) 101
9.6 Eccezione per mercato dell’ associazione negoziatore/liquidatore (LIQNEG) 104
9.7 Struttura dei conti per il servizio di gestione accentrata 107
9.8 Coordinate per il regolamento contante operazioni DVP 111
9.9 Pagamenti relativi alle corporate action in T2S 117
9.10 Pagamenti relativi alle corporate action in T2 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
5
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
6
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-
TRM
http://www.montetitoli.it/area-
download/normativa/expressii/istrxtrm28102013senza.pdf
Istruzioni al Servizio di
Gestione Accentrata
per Intermediari ed
Emittenti
http://www.montetitoli.it/area-
download/normativa/gestioneaccentrata/istruzga08072013clean.pdf
Migration Weekend
Playbook
Documento del gruppo di lavoro “T2S/MT Testing & Migration”
pubblicato nell’ apposita sezione documentale di MT-X
T2S User Detail
Functional
Specifications
http://www.ecb.europa.eu/paym/t2s/pdf/UDFS_v1_2_1.pdf?02dbde
3be45b2d0bf5a5afcf4de34f36
T2S User Hand Book http://www.ecb.europa.eu/paym/t2s/pdf/User_Handbook_v1.0.pdf?
cc76cbb67593fe9e8b489e733a315bea
7
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).
8
3 PANORAMICA DEL PROCESSO DI MIGRAZIONE A T2S
3.1 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 Fase di pre-
migrazione
Weekend di
migrazione
Fase di
stabilizzazione
1 24 marzo 2015 –
19 giugno 2015
19 giugno 2015 –
22 giugno 2015
22 giugno 2015 –
27 luglio 2015
2 04 gennaio 2016 –
25 marzo 2016
25 marzo 2016 –
28 marzo 2016
28 marzo 2016 –
25 aprile 2016
3 14 giugno 2016 –
09 settembre 2016
09 settembre 2016 –
12 settembre 2016
12 settembre 2016 –
17 ottobre 2016
4 03 novembre 2016 –
03 febbraio 2017
03 febbraio 2017 –
06 febbraio 2017
06 febbraio 2017 –
13 marzo 2017
9
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, di cui al link:
http://www.ecb.europa.eu/paym/t2s/about/keydocs/html/index.en.html
10
Si precisa che alcune Banche Centrali, come descritto nelle successive tabelle, supporteranno
solo alcuni dei quattro ruoli precedentemente descritti.
ATTORI DESCRIZIONE
Migrating CSD
Insieme dei CSD che prendono parte a una specifica finestra di
migrazione.
Il processo di migrazione a T2S avviene coinvolgendo
simultaneamente le Banche Centrali Nazionali ed i soggetti clienti
dei CSD (CSD participant)
Migrating CB
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
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
SME CSD
CSD che operano in T2S come SME, ovvero come “Securities
Maintaining Entities” degli strumenti finanziari dei quali sono Issuer
o Techical Issuer
CSD participant
(DCP/ICP)
I CSD participant, ovvero i clienti dei CSD. È possibile distinguere
due differenti tipologie di CSD participant, ovvero:
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
Payment Bank
(DCP/ICP)
Le Payment Bank, ovvero i soggetti clienti delle Banche Centrali. È
possibile distinguere due differenti tipologie di Payment Bank:
DCP: soggetti che interagiscono direttamente con la
piattaforma T2S per la componente cash in modalità A2A
o U2A
ICP: soggetti che interagiscono con la piattaforma T2S
attraverso le Banche Centrali
11
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”
RTGS Operator Operatori del sistema RTGS connessi alla piattaforma T2S, come
ad esempio il “T2S Operator”
T2S Operator Soggetto dell’ Eurosistema che supporta tutte le attività di
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
Clearstream Banking SME CSD
CSD che opera solo come “Securities
Maintaining Entity” dei dati statici
migrati alla piattaforma T2S
Euroclear Belgium SME CSD
CSD che opera solo come “Securities
Maintaining Entity” dei dati statici
migrati alla piattaforma T2S
Euroclear France SME CSD
CSD che opera solo come “Securities
Maintaining Entity” dei dati statici
migrati alla piattaforma T2S
Euroclear Netherlands SME CSD
CSD che opera solo come “Securities
Maintaining Entity” dei dati statici
migrati alla piattaforma T2S
Iberclear SME CSD
CSD che opera solo come “Securities
Maintaining Entity” dei dati statici
migrati alla piattaforma T2S
LuxCSD SME CSD CSD che opera solo come “Securities
12
SOGGETTO TIPOLOGIA COMMENTO
Maintaining Entity” dei dati statici
migrati alla piattaforma T2S
VP Securities SME CSD
CSD che opera solo come “Securities
Maintaining Entity” dei dati statici
migrati alla piattaforma T2S
Bank of Greece CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
Depozitarul Central CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
Malta Stock Exchange CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
Monte Titoli CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
SIX SIS CSD in fase di
migrazione a T2S
Migrazione del sistema di regolamento
e EUR e delle relative attività a T2S
Bank of Greece CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Bank Centrali ta'Malta CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Banca d'Italia CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Banca Nationala a
Romaniei
CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Banco de Portugal CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Deutsche Bundesbank CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
13
SOGGETTO TIPOLOGIA COMMENTO
NBB CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Banque de France CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
De Nederlandsche
Bank
CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Banco de Espana CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Banque centrale du
Luxembourg
CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Oesterreichische
Nationalbank
CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Danmarks
Nationalbank
CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Suomen Pankki CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Banka Slovenije CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Eesti Pank CB in fase di migrazione Copertura parziale dei quattro diversi
14
SOGGETTO TIPOLOGIA COMMENTO
a T2S ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Lietuvos Respublikos
centriniu banku
CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Magyar Nemzeti Bank CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
Narodna banka
Slovenska
CB in fase di migrazione
a T2S
Copertura parziale dei quattro diversi
ruoli delle Banche Centrali in T2S. In
particolare in qualità di: “System Entity”
e “RTGS System Owner”
3.4 Composizione della seconda finestra
SOGGETTO TIPOLOGIA COMMENTO
Euroclear Belgium CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
Euroclear France CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
Euroclear Netherlands CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
Interbolsa CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
NBB - SSS CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
NBB CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
15
SOGGETTO TIPOLOGIA COMMENTO
Banque de France CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
De Nederlandsche
Bank
CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Banco de Portugal CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Wave 1 CSD e CB CSD e CB già migrati nella prima
finestra di migrazione
3.5 Composizione della terza finestra
SOGGETTO TIPOLOGIA COMMENTO
Clearstream Banking CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
Keler Hungary CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
LuxCSD CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
OeKB CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
VP Lux CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
VP Securities CSD in fase di
migrazione a T2S
Migrazione dei sistemi di regolamento
EUR nonchè dei sistemi di regolamento
DKK che si prevede migreranno nel
2018
Deutsche Bundesbank CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Banque centrale du
Luxembourg
CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Magyar Nemzeti Bank CB in fase di migrazione Copertura totale dei quattro diversi ruoli
16
SOGGETTO TIPOLOGIA COMMENTO
a T2S delle Banche Centrali in T2S
Oesterreichische
Nationalbank
CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Wave 1-2 CSD e CB migrati a T2S CSD e CB già migrati nelle prime due
wave di migrazione
3.6 Composizione della quarta finestra
SOGGETTO TIPOLOGIA COMMENTO
CDCP Slovakia CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
Iberclear CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
AS Eesti
Vaartpaberikeskus
CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
CSD of Lithuania CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
Euroclear Finland CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
KDD Slovenia CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
BNY Mellon CSD CSD in fase di
migrazione a T2S
Migrazione completa del sistema di
regolamento e delle relative attività a
T2S
Banco de Espana CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Suomen Pankki CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Banka Slovenije CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
17
Eesti Pank CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Lietuvos Respublikos
centriniu banku
CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Narodna banka
Slovenska
CB in fase di migrazione
a T2S
Copertura totale dei quattro diversi ruoli
delle Banche Centrali in T2S
Wave 1-3 CSD e CB migrati a T2S CSD e CB già migrati nelle prime tre
finestre di migrazione
18
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.
19
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
1
Binding declaration per aderire come
DCP
I clienti devono comunicare a Monte Titoli la
loro volontà (dichiarazione vincolante) di
partecipare come DCP alla piattaforma T2S
X DCP 24/02/2014
2
Distribuzione casi di test per la
certificazione dei DCP
L’ Eurosistema distribuisce ai partecipanti
diretti alla piattaforma T2S la lista dei casi di
test per la certificazione dei DCP
X
ECB
Marzo 2014
3
Distribuzione di contratti e membership
form – draft version
Data prevista per la pubblicazione della
bozza della documentazione contrattuale ai
clienti da parte di Monte Titoli
X
MT
15/05/2014
4
Distribuzione casi di test per
l’autorizzazione
Monte Titoli distribuisce ai partecipanti la
lista dei casi di test per il processo di
autorizzazione
X MT Settembre
2014
5
Registrazione presso i NSP
Ogni partecipante DCP deve completare
l’apposita registrazione presso i NSP
attraverso i rispettivi CSD/CB per l’ambiente
di collaudo
X DCP 31/10/2014
6
Richiesta assegnazione dei
certificati/token Per accedere all’ ambiente
di collaudo in funzione dell’inizio dei test di
connettività
X DCP 14/11/2014
7 Distribuzione di contratti, istruzioni e
membership form
20
N DESCRIZIONE S.P. ATT. SOGGETTO SCADENZA
Data prevista per la pubblicazione finale del
nuovo set contrattuale ai clienti da parte di
Monte Titoli
X MT
15/12/2014
8
Test di connettività
I DCP sono tenuti ad eseguire i suddetti test
per connettersi all’ambiente di collaudo T2S
di Community.
Gli ICP sono coinvolti negli opportuni test di
connettività con MT direttamente in
ambiente di collaudo T1.
X Clienti
(DCP/ICP)
Dal
03/12/2014
al
27/02/2015
9
Configurazione dei DCA e CMB
Le payment bank che offrono ai propri
clienti servizi di regolamento del contante
e/o client collateralisation devono
opportunamente autorizzare i clienti stessi
all’ utilizzo dei propri DCA (creazione CMB)
X X
PB
Entro
20/02/2015
10
Primo Dress Rehearsal di pre migrazione
Esecuzione del primo Dress Rehearsal full
di pre migrazione su dati statici relativi a
titoli e partecipanti in ambiente di collaudo
di Community, che corrisponde all’
ambiente di collaudo T1 di Monte Titoli
X
MT
Dal
23/02/2015
al
27/02/2015
11
Primo Dress rehearsal di pre migrazione:
debriefing
I clienti sono invitati ad inviare a Monte Titoli
i loro feedback relativi al risultato del primo
dress rehearsal nonché a riportare eventuali
problemi o criticità relativi ai dati statici
migrati in T2S e direttamente visibili nella
nuova piattaforma
X X
MT
DCP
Dal
03/03/2015
Al
07/03/2015
12
Processo di registrazione presso i NSP
Ogni partecipante DCP che prende parte ad
una particolare wave di migrazione deve
completare l’ apposita registrazione presso i
NSP attraverso i rispettivi CSD/CB per
l’ambiente di produzione
X DCP 27/02/2015
13 Richiesta dei certificati/token per X DCP 02/03/2015
21
N DESCRIZIONE S.P. ATT. SOGGETTO SCADENZA
accedere all’ ambiente di produzione
14 Test di certificazione per i DCP X DCP Entro marzo
2015
15
Inizio del Community testing
I CSD, le Banche Centrali ed i rispettivi
soggetti partecipanti sono chiamati a
prendere parte al Community Testing
X
CSD
CB
Clienti
(DCP/ICP)
02/03/2015
16
Test di connettività per la prima finestra
di migrazione
I DCP sono tenuti ad eseguire i suddetti test
per connettersi all’ ambiente di produzione
di T2S.
Gli ICP sono coinvolti negli opportuni test di
connettività con MT direttamente in
ambiente di produzione (MT T1)
X
Clienti
(DCP/ICP)
Dal
20/03/2015
al
03/04/2015
17
Termine per la conferma dei dati di
membership per la produzione
Scadenza per la conferma a Monte Titoli dei
dati di membership dei clienti per l’
ambiente di produzione
X
Clienti
(DCP/ICP)
20/03/2015
18
Dress Rehearsal del MWE
I clienti sono chiamati a partecipare per le
attività di loro competenza e ad acquisire i
risultati derivanti dalle prove relative
all’esecuzione del fine settimana di
migrazione e delle relative attività di
regolamento (in ambiente di Community di
T2S e nel corrispondente ambiente di
collaudo T1 di MT)
X
MT
Clienti
(DCP/ICP)
Dal
17/04/2015
al
20/04/2015
19
MWE Dress Rehearsal: debriefing
I clienti sono invitati a riportare a MT l’esito
della simulazione del weekend di
migrazione nonchè particolari criticità e
rischi legati anche alle loro attività “interne”
di migrazione
X X
MT
Clienti
(DCP/ICP)
Dal
23/04/2015
Al
24/04/2015
20 Go-live dei dati statici nell’ ambiente di
produzione di T2S e nei sistemi legacy di X X MT
Dal
27/04/2015
22
N DESCRIZIONE S.P. ATT. SOGGETTO SCADENZA
MT
Caricamento di tutti i dati statici e delle
relative applicazioni nel nuovo ambiente di
produzione T2S e nei nuovi sistemi legacy
di Monte Titoli
al
04/05/15
21
Finestra di contingency per il
caricamento dei dati statici in ambiente
di produzione di T2S
Periodo di buffer nel caso in cui dovessero
emergere criticità legate al processo di
caricamento e migrazione dei dati statici in
T2S
X X MT
Dal
05/05/2015
al
11/05/15
22 Dichiarazione di corretta esecuzione dei
test di certificazione X X
ECB
DCP 15/05/2015
23
Dichiarazione di corretta esecuzione dei
test di autorizzazione
I clienti dichiarano a Monte Titoli la corretta
esecuzione dei test di autorizzazione
X Clienti
(ICP/DCP) 15/05/2015
24
MWE dress rehearsal 1
Prima esecuzione delle prove generali del
fine settimana di migrazione con tutti i dati
di produzione.
Saranno protagonist tutti i soggetti coinvolti
nella prima wave di migrazione a T2S
X
MT
Clienti
(DCP/ICP)
Dal
15/05/2015
al
18/05/2015
25
Business day testing 1
Durante il business day testing si richiedere
ai clienti di immettere transazioni ed
operare esattamente come se fossero in
produzione. Queste prove si realizzano
nell’ambiente di collaudo T1 Monte Titoli
collegato all’ambiente T2S di Community
X Community
Dal
18/05/2015
al
20/05/2015
26
MWE Dress Rehearsal 1: debriefing
I clienti sono invitati ad inviare a MT i loro
feedback relativi al risultato del Dress
Rehearsal ed a riportare eventuali problemi
o criticità emerse durante l’esecuzione del
Dress Rehearsal stesso
X X
MT
Clienti
(ICP/DCP)
Dal
21/05/2015
al
22/05/2015
23
N DESCRIZIONE S.P. ATT. SOGGETTO SCADENZA
27
MWE Dress rehearsal 2
Seconda esecuzione delle prove generali
del fine settimana di migrazione con tutti i
dati di produzione.
Saranno protagonisti tutti i soggetti coinvolti
nella prima wave di migrazione a T2S
MT
Clienti
(DCP/ICP)
Dal
29/05/2015
al
01/06/2015
28
Business day testing 2
Durante il business day testing si richiedere
ai clienti di immettere transazioni ed
operare esattamente come se fossero in
produzione
X Community
Dal
01/06/2015
al
03/06/2015
29
MWE Dress rehearsal 2: debriefing
I clienti sono invitati ad inviare a Monte Titoli
i loro feedback relativi al risultato del
secondo Dress rRehearsal ed al colloquio
con la nuova piattaforma T2S nonché
riportare eventuali problemi o criticità
emerse.
L’esito positivo del suddetto Dress
Rehearsal potrebbe rappresentare un esito
positivo ad uno degli entry criteria a T2S.
X X
MT
Clienti
(ICP/DCP)
Dal
04/06/2015
al
05/06/2015
30
Dichiarazione di corretta esecuzione del
Dress Rehearsal del MWE
I clienti sono chiamati a dichiarare la
corretta esecuzione del Dress Rehearsal
del fine settimana di migrazione
X X
Clienti
(ICP/DCP)
Entro
06/06/2015
31
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 pre-
produzione 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.
X
Clienti
(DCP/ICP)
15/06/2015
24
N DESCRIZIONE S.P. ATT. SOGGETTO SCADENZA
32
T2S GO-LIVE
ESECUZIONE DEL FINE SETTIMANA DI
MIGRAZIONE A T2S
X X TUTTI
Dal
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”.
25
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
26
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
27
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 Bit-
Club 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.
28
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)
Elementi
informativi
Esistenti nei sistemi Monte Titoli
Identificazione regole di mappatura
Nuove informazioni
Richieste per le caratteristiche di T2S
Obbligatoriamente comunicate dai clienti
Assegnate di default da Monte Titoli
29
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 pre-
settlement adotta in assenza di indicazioni in merito al liquidatore e/o al conto titoli da parte del
negoziatore al momento di istruire un’operazione.
30
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 X-
TRM. 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.
31
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.
32
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.
33
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
34
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ù
35
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.
36
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:
37
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.
38
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
39
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
40
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
41
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 X-
TRM 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.
√
42
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.
43
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
Caso 1 Caso 2 Caso 3 Caso 4 Caso 5
Caso 1 n.a. √ √ √Caso 2
Caso 3 √ √ √ √
Caso 4 √ √ √ √
Caso 5 √ √ √ √
44
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
45
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
46
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 diretta e
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
47
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 (il soggetto
liquidatore del negoziatore deve coincidere con il soggetto liquidatore del GCM)
48
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
49
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
50
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:
51
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
negoziatore
il soggetto liquidatore “entrante” ha piena 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 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
52
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
53
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.
54
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
55
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
56
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
57
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
58
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):
59
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
60
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
61
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
62
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
63
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
64
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
65
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
66
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
67
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
68
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
69
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
70
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 (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
71
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
72
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.
73
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
74
7 T2S USER TESTING & MIGRATION TESTING
7.1 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 RESPONSABILITA’
Eurosistema Gestione della preparazione della fase di User Testing
Coordinamento e supporto all’esecuzione dello User Testing
CSD
Banche Centrali
Partecipazione alla preparazione della fase di User Testing
Partecipazione attiva all’esecuzione delle varie fasi di test
Coordinamento delle attività di testing (preparazione ed esecuzione)
con le rispettive Community
CSD Participant
Payment Bank
Partecipazione attiva all’esecuzione delle fasi di test relative al
Community ed al Business Day
75
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.
76
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
legacy MT
Ambiente
T2S Note
Disponibile
da
Disponibile
fino a
T2 Interoperability Utilizzato solo da Monte Titoli. 11/06/2015
T2 Pre-Prod.
Messo a disposizione dei
clienti da Monte Titoli come
nuovo ambiente di pre
produzione in sostituzione di
PI.
12/06/2015 Data aperta
T1 Community
Utilizzato da Monte Titoli e dai
clienti per i collaudi di
connettività e funzionali
durante le fasi di Community e
Business day testing.
05/01/2015 11/06/2015
T1 Produzione
Utilizzato da Monte Titoli e dai
clienti per il passaggio in
produzione a T2S (Migration
Week End) e le successive
attività BAU.
12/06/2015 Data aperta
T3 n.a.
Utilizzato per la sola gestione
dei dati statici di produzione
tramite piattaforma web.
Accessibile solo via internet.
15/12/2014 20/03/2015
T3 Produzione
Connesso all’ambiente di
produzione di T2S per
consentire la migrazione dei
dati statici.
21/03/2015 11/06/2015
77
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 weekends
http://www.ecb.europa.eu/paym/t2s/progplan/html/index.en.html#week
78
8 GESTIONE DEGLI ACCESS RIGHT IN T2S (solo per DCP)
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.
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.
79
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.
80
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:
81
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;
c
82
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.
83
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).
84
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
85
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
RBAC1 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)
86
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).
87
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:
88
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.
89
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.
90
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
91
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.
92
“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.
93
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. Nome colonna Formato Descrizione
Dati esistenti in MT
[AS-IS]
Assegnati di default
da MT
Forniti obbligatoriamente
dai clienti
1 Parent BIC CHAR (11) BIC della System Entity
responsabile del party X MOTI IT MM XXX n. a.
2 Tipologia di
partecipante
Possibili valori:
CSDP
ECSD
Classificazione delle party:
CSDP=CSD Participant
ECSD = External CSD
X Valori assegnati di
default da MT n. a.
3
Data di apertura
DATE
Data di attivazione del Party.
La stessa deve
necessariamente essere
maggiore o uguale al
27/04/2015
X
Data impostata da
Monte Titoli al
27/04/15
Ammesse possibili
variazioni nel caso in cui il
Party assegnato di Default
da MT non coincidesse con
le esigenze del cliente e
dovesse pertanto essere
variato
94
4 Data di chiusura DATE
Momento a decorrere dal
quale il Party non risulta
essere più attivo. La stessa
deve necessariamente essere
superiore alla data di apertura.
X Null
Ammesse possibili
variazioni per le ragioni su
esposte
5 Party BIC CHAR (11) BIC del PARTY X Valore assegnato di
default da MT
Ammesse possibili
variazioni in relazione alle
necessità di setup del CMB
e/o di matching.
In ogni caso almeno un
valore deve essere
presente
6 Long Name VARCHAR (350) Indicazione estesa della
denominazione del Party X
Valore esistente in MT
assegnato sulla base
del nome della Legal
Entity
n.a.
7 Short Name VARCHAR (35) Indicazione abbreviata della
denominazione del Party X
Valore esistente in MT
assegnato sulla base
del nome della Legal
Entity
n.a.
95
8 Indirizzo VARCHAR (70) Indirizzo del Party X
Valore esistente in MT
n.a.
9 Numero civico VARCHAR (16) Indicazione specifica del
numero civico riferito al Party X
10
Codice di
avviamento
postale
VARCHAR (16) Codice di avviamento postale
del Party X
11 Città VARCHAR (35) Indicazione della città del Party X
12 Provincia o
Stato VARCHAR (35)
Indicazione della provincia o
Stato del Party X
13 Codice del
Paese CHAR (2)
Indicazione del codice del
Paese X
14 Technical
Address VARCHAR (256)
Si applica ai soli clienti DCP.
Indicazione del technical
address della party
(distinguished name).
n. a.
Valorizzato
inizialmente da Monte
Titoli con un valore
fittizio tipo “valore da
assegnare”
I clienti ICP non devono
inserire/variare nulla in
questo dato.
Obbligatorio per i soli clienti
DCP. Questo è un nuovo
dato specifico di T2S per
consentire la connessione
diretta alla piattaforma T2S
96
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
N. Assegnati di
default da MT
Assegnati di default
da MT Descrizione
Dati esistenti in
MT
[AS-IS]
Assegnati di default
da MT
Forniti
obbligatoriamente dai
clienti
1 Parent BIC CHAR (11) BIC della System Entity
responsabile del Party X
Cfr. Tabella 9.2Party 2 Party BIC CHAR (11) BIC del party X
3 Technical
Address VARCHAR (256)
Incazione del technical
address della Party
(distinguished name)
n. a
4 Network
Service VARCHAR (35) n. a n. a. Obbligatorio
97
9.4 Associazione di default negoziatore/liquidatore e relativi conti di regolamento: (LIQDEF)
New data in T2S
N. Nome Colonna Formato Descrizione Commenti
Dati
esistenti in
MT
[AS-IS]
Assegnati di
default da MT
Forniti
obbligatoriame
nte dai clienti
1 Sistema di
liquidazione
Sistema di
liquidazione.
Può essere
assegnato uno dei
seguenti valori:
T2S: se
configurazione
lorda e netta di
Express II
coincidono
Netta: per
configurazione
netta
Lorda: per
Dal momento che oggi
in X-TRM sono quasi
sempre presenti per
uno stesso soggetto
due configurazioni,
una relativa alla
liquidazione lorda e
l’altra relativa alla
netta, potrebbero
verificarsi delle
situazioni nelle quali i
due valori differiscono
X n.a.
In caso di valori
“Netta” e “Lorda”
ci si aspetta che
uno dei due sia
chiuso
98
configurazione
lorda
2 Tipo negoziazione
Indicazione del tipo
di negoziazione.
Può assumere uno
dei seguenti valori:
P
T
BLANK=se
valgono P e T
contemporane
amente
X Assegnato di
default da MT
Ammesse
possibili
variazioni
3 Codice BIC del
negoziatore
Indicazione del
codice BIC del
soggetto
negoziatore
Tali informazioni
saranno fornite da MT
qualora esistenti nei
propri archivi
X
Valori
assegnati di
default da MT
n.a.
4 Codice CED del
negoziatore
Indicazione del
codice CED del
soggetto
negoziatore
X
Valori
assegnati di
default da MT
n. a.
5 Codice CED del Indicazione del X Valori Ammesse
99
liquidatore codice CED del
soggetto
liquidatore
assegnati di
default da MT
possibili
variazioni
6
Indicatore
liquidatore di
default
L’indicazione del
Flag (SI/NO)
permette di
identificare se il
liquidatore è quello
di default o meno
X
Valori
assegnati di
default da MT
Ammesse
possibili
variazioni
7 Inizio associazione
liquidatore
Indicazione della
data nella quale
inizia l’
associazione del
negoziatore con il
liquidatore
Si noti che la data è
sempre quella di
regolamento (SD)
X
8 Fine associazione
liquidatore
Indicazione della
data nella quale
termina l’
associazione del
negoziatore con il
liquidatore
Si noti che la data è
sempre quella di
regolamento (SD)
X
9 Codice del conto Indicazione del X Identificativo Ammesse
100
regolamento codice del conto di
regolamento
secondo la codifica
del CSD
conto
assegnato da
MT
possibili
variazioni
10 Indicatore conto di
default
Indica se il conto di
regolamento è
quello di default o
no per quella data
combinazione di
Tipo negoziazione/
liquidatore
X
Valori
assegnati di
default da MT
Ammesse
possibili
variazioni 11 Inizio associazione
conto
Indicazione della
data nella quale
inizia
l’associazione
conto
X
12 Fine associazione
conto
Indicazione della
data nella quale
termina
l’associazione
conto
X
101
9.5 Associazione Negoziatore/GCM/Liquidatore del GCM (CCPNEG)
New data in T2S
N. Nome Colonna Formato Descrizione Commenti
Dati
esistenti in
MT
[AS-IS]
Assegnati di
default da
MT
Forniti
obbligatoriame
nte dai clienti
1 Sistema di
liquidazione
Sistema di
liquidazione.
Può essere
assegnato uno dei
seguenti valori:
T2S: se
configurazione
lorda e netta di
Express II
coincidono
Netta: per
configurazione
netta
Lorda: per
Dal momento che
oggi in X-TRM sono
quasi sempre
presenti per uno
stesso soggetto due
configurazioni, una
relativa alla
liquidazione lorda e
l’altra relativa alla
netta, potrebbero
verificarsi delle
situazioni nelle quali
X n.a.
Cfr9.4:
Associazione di
default
negoziatore/liqu
idatore e relativi
conti di
regolamento:
(LIQDEF)
102
configurazione
lorda
i due valori
differiscono
2 Tipo
negoziazione
Specificazione del
tipo di negoziazione
“proprietà” o “terzi”
X
Valori
assegnati di
default da MT
3 Codice BIC del
negoziatore
Indicazione del
codice BIC del
soggetto
negoziatore
X
Valori
assegnati di
default da MT
4 Codice CED del
negoziatore
Indicazione del
codice CED del
soggetto
negoziatore
X
Valori
assegnati di
default da MT
5 Provenienza
Indica la
provenienza di
mercato
X
Valori
assegnati di
default da MT
Ammesse
possibili
variazioni
6 Mercato di
negoziazione
Indicazione del
mercato di
negoziazione
X
Valori
assegnati di
default da MT
Ammesse
possibili
variazioni
7 Codice CED
della CCP
Indicazione del
codice CED della X
Valori
assegnati di
Ammesse
possibili
103
CCP default da MT variazioni
8
Codice CED dell’
aderente
generale
Indicazione del
codice CED
dell’aderente
generale
X
Valori
assegnati di
default da MT
Ammesse
possibili
variazioni
9
Codice CED del
liquidatore del
GCM
Indicazione del
codice CED del
soggetto liquidatore
del GCM
X
Valori
assegnati di
default da MT
Ammesse
possibili
variazioni
10 Codice del conto
di regolamento
Indicazione del
codice del conto di
regolamento
X
Valori
assegnati di
default da MT
Ammesse
possibili
variazioni
11 Data inizio
validità
Indicazione della
data di inizio
validità
X
Ammesse
possibili
variazioni
12 Data fine validità Indicazione della
data di fine validità X
Ammesse
possibili
variazioni
104
9.6 Eccezione per mercato dell’ associazione negoziatore/liquidatore (LIQNEG)
New data in T2S
N. Nome Colonna Formato Descrizione Commenti
Dati esistenti
in MT
[AS-IS]
Assegnati
di default
da MT
Forniti
obbligatoria
mente dai
clienti
1 Sistema di
liquidazione
Sistema di
liquidazione.
Può essere
assegnato uno dei
seguenti valori:
T2S: se
configurazione
lorda e netta di
Express II
coincidono
Netta: per
configurazione
netta
Lorda: per
configurazione
Dal momento che
oggi in X-TRM sono
quasi sempre
presenti per uno
stesso soggetto due
configurazioni, una
relativa alla
liquidazione lorda e
l’altra relativa alla
netta, potrebbero
verificarsi delle
situazioni nelle quali i
due valori
differiscono
X n.a.
9.4Tabella:
Associazione
di default
negoziatore/liq
uidatore e
105
lorda relativi conti di
regolamento:
(LIQDEF)
2 Tipo negoziazione
Specificazione del
tipo di
negoziazione
X
Valori
assegnati di
default da
MT
3 Codice BIC del
negoziatore
Indicazione del
codice BIC del
soggetto
negoziatore
X
Valori
assegnati di
default da
MT
4 Codice CED del
negoziatore
Indicazione del
codice CED del
soggetto
negoziatore
X
Valori
assegnati di
default da
MT
5 Codice CED del
liquidatore
Indicazione del
codice CED del
soggetto
liquidatore
X
Valori
assegnati di
default da
MT
6 Codice del conto
regolamento
Indicazione del
codice del conto di
regolamento
secondo la codifica
X
Identificativo
conto T2S
assegnato
da MT
106
del CSD
7 Provenienza
Indica la
provenienza di
mercato
X
Valori
assegnati di
default da
MT
Ammesse
possibili
variazioni
8 Mercato di
negoziazione
Indicazione del
mercato di
negoziazione
X
Valori
assegnati di
default da
MT
Ammesse
possibili
variazioni
9 Data inizio validità
Indicazione della
data di inizio
validità
X
Valori
assegnati di
default da
MT
Ammesse
possibili
variazioni
10 Data fine validità Indicazione della
data di fine validità X
Valori
assegnati di
default da
MT
Ammesse
possibili
variazioni
107
9.7 Struttura dei conti per il servizio di gestione accentrata
New data in T2S
N. Nome Colonna Formato Descrizione Commenti
Dati esistenti
in MT
[AS-IS]
Assegnati
di default
da MT
Forniti
obbligatoria
mente dai
clienti
1 Parent BIC CHAR (11)
BIC della System
Entity responsabile
del Party
X MOT IT MM
XXX
Cfr.9.2
TabellaParty
2 Party BIC CHAR (11)
Indicazione del BIC
del Party al quale è
associato il conto
X
Valore
assegnato
di default da
MT
3 Codice ABI del
depositario
Indicazione del
codice ABI del
soggetto owner del
Securities account
X
Valore
assegnato
di default da
MT
n.a.
4 T2S Account ID Codice identificativo
del conto in T2S n.a.
Valore
assegnato
di default da
MT
Non
ammesse
variazioni
108
5 Codice del conto
Identificativo del
Securities Account
secondo la codifica
ABI
X
Valore
assegnato
di default da
MT
n.a.
6 Ruolo
Specificazione dell’
operatività del
soggetto. Può
ricoprire uno dei
seguenti ruoli:
emittente
intermediario
X
Valore
assegnato
di default da
MT
n.a.
7 Tipo conto
Indicazione del tipo
conto.
Può assumere uno
dei seguenti valori:
P: proprietà
T: terzi
L: liquidatore
X
Valore
assegnato
di default da
MT
Ammesse
possibili
variazioni ma
non attese
8 Tipo Conto
Collateral
Indicazione del tipo
conto collateral.
Può assumere uno
X
Valore
assegnato
di default da
n. a.
109
dei seguenti valori:
G: giver
R: receiver
Il tipo conto collateral
deriva dalla
partecipazione ad X-
COM ed è assegnato
a seconda della
configurazione
attualmente
presente.
MT
9 Data di apertura del
securities account
Indicazione della
data di apertura del
conto titoli
Deve essere
maggiore o uguale
al 27/04/2015
X
Valore
assegnato
di default da
MT
Ammesse
possibili
variazioni
10 Data di chiusura del
securities account
Indicazione della
data di chiusura del
conto titoli
Deve
necessariamente
essere successiva
alla data di apertura
del conto titoli
X Null
Non sono
attese
variazioni a
meno che il
securities
account non
venga chiuso
110
dopo la data
di go-live
11 Blocco Operativo
Può assumere uno
dei seguenti valori di
default:
S = si
N = no
I conti con blocco
operativo,
indipendentemente
dal fatto che siano
con o senza saldo,
verranno definiti e
configurati a livello
di T2S
X
Valore
assegnato
di default da
MT
n.a
12 Hold/Release
Indicator
Indicazione dell’
indicatore di Hold
and Release. Può
assumere uno dei
seguenti valori:
H= Hold
R=Released
n.a. RELE
Ammesse
possibili
variazioni
111
9.8 Coordinate per il regolamento contante operazioni DVP
New data in T2S
N. Nome Colonna Formato Descrizione Commenti
Dati esistenti
in MT
[AS-IS]
Assegnati di
default da
MT
Forniti
obbligatoriame
nte dai clienti
1 Parent BIC CHAR (11)
BIC della System
Entity responsabile
del Party
X
Cfr. 9.7 Tabella Struttura dei
2 Party BIC CHAR (11)
Indicazione del BIC
del Party al quale è
associato il conto
X
3 T2S Account ID Codice identificativo
del conto in T2S X
4 Codice ABI del
depositario
Indicazione del
codice ABI del X
112
soggetto owner del
Securities account
conti per il servizio di gestione
accentrata
5 Codice del conto
Identificativo del
Securities Account
secondo la codifica
ABI
X
6 Tipo conto
Indicazione del tipo
conto.
Può assumere uno
dei seguenti valori:
P: proprietà
T: terzi
L: liquidatore
X
7 Ruolo
Specificazione dell’
operatività del
soggetto. Può
ricoprire uno dei
seguenti ruoli:
emittente
intermediario
X
8 Codice ABI del Indicazione del X Valore n.a.
113
soggetto
pagatore
codice ABI del
soggetto pagatore se
anche partecipante
Monte Titoli
assegnato di
default da
MT
9 CB Parent BIC CHAR (11)
Indicazione del BIC
della CB owner del
Party
n.a.
n.a.
L’informazion
e è relativa
all’identificati
vo T2S del
DCA [che si
basa su due
livelli: BIC
della
CB+BIC
della PB] non
è disponibile
a MT
Il cliente deve
fornire
obbligatoriament
e l’Identificativo
T2S del DCA su
due livelli (BIC
della CB + BIC
della PB) e la
PB deve
confermare
10 PB Party BIC CHAR (11)
Indicazione del BIC
della PB owner del
conto DCA
n.a.
114
11 Identificativo
conto DCA
Identificativo T2S del
DCA che è utilizzato
per i pagamenti in
associazione al
conto titoli
n.a.
n. a .
L’informazion
e è relativa
all’identificati
vo T2S del
DCA [che si
basa su due
livelli: BIC
della
CB+BIC
della PB]
non è
disponibile a
MT
Il cliente deve
fornire
obbligatoriament
e l’Identificativo
T2S del DCA su
due livelli (BIC
della CB + BIC
della PB) e la PB
deve confermare
12 Identificativo
CMB
Identificativo T2S del
Credit Memorandum
Balance assegnato
dal proprietario del
DCA che è utilizzato
per i pagamenti in
associazione al
conto titoli
n. a.
n. a.
L’informazion
e relativa
all’identificati
vo T2S del
CMB non è
Il cliente deve
fornire
obbligatoriament
e l’Identificativo
T2S del CMB
115
disponibile a
MT
13 Default Link BOOLEAN
Indicazione del link
di default. Assume
valore pari a “True”
quando il conto DCA
è utilizzato come
conto di default per il
regolamento del
contante in T2S
Si specifica che per
un dato securities
account ci può
essere uno e un
solo link di default
ad un conto DCA,
tutti i link con altri
DCA saranno NON
di default
n. a. n. a. Mandatory
14 Data inizio
validità del link
Indicazione della
data di inizio validità
del link
n. a. 22/06/2015 Mandatory
15 Data fine validità
del link
Indicazione della
data di fine validità
del link
n. a.
Nessun
valore per
significare
n.a.
116
data aperta
16 Collateralisation
Link BOOLEAN
Se assume valore
“true”, T2S può
utilizzare questo
conto titoli per
operazioni di auto-
collateral fatte salve
tutte le altre
condizioni
necessarie
X
Assegnato
da MT sulla
base
dell’attuale
flag di self
collateralizati
on
Ammesse
possibili
variazioni
17 Cash Settlement
Link BOOLEAN
Se assume valore
“true”, T2S può
usare il link tra il
securities account ed
il T2S DCA per il
regolamento della
gamba cash della
settlement
instruction.
X
Valore
assegnato di
default da
MT
Ammesse
possibili
variazioni
117
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
N. Nome Colonna Formato Descrizione Commenti
Dati
esistenti in
MT
[AS-IS]
Assegnati di
default da
MT
Forniti
obbligatoria
mente dai
clienti
1 Parent BIC CHAR (11)
BIC della System
Entity responsabile
del Party
X
Cfr. tabella 9.7Struttura dei
conti per il servizio di gestione
accentrata
2 Party BIC CHAR (11)
Indicazione del BIC
del Party al quale è
associato il conto
X
3 T2S Account ID Codice identificativo
del conto in T2S X
4 Codice ABI del
depositario
Indicazione del
codice ABI del
soggetto owner del
Securities account
X
118
5 Codice del conto
Identificativo del
Securities Account
secondo la codifica
ABI
X
6 Tipo conto
Indicazione del tipo
conto.
Può assumere uno
dei seguenti valori:
P: proprietà
T: terzi
L: liquidatore
X
7 Ruolo
Specificazione dell’
operatività del
soggetto. Può
ricoprire uno dei
seguenti ruoli:
emittente
intermediario
X
8 CB Parent BIC CHAR (11)
Indicazione del BIC
della CB owner del
Party
n.a.
L’informazion
e relativa
all’identificativ
119
9 PB Party BIC CHAR (11)
Indicazione del BIC
della PB owner del
conto DCA
n.a.
o T2S del
DCA [che si
basa su due
livelli: BIC
della CB+BIC
della PB] non
è disponibile
a MT che
pertanto
assegna il
valore fittizio
“da definire”
Il cliente deve
fornire
obbligatoriam
ente
l’Identificativo
T2S del DCA
su due livelli
(BIC della CB
+ BIC della
PB) e la PB
deve
confermare
Il cliente deve
fornire
obbligatoriam
ente
l’Identificativo
T2S del DCA
su due livelli
(BIC della CB
+ BIC della
PB) e la PB
deve
10 Identificativo
conto DCA
Identificativo T2S del
DCA che è utilizzato
per i pagamenti in
associazione al conto
titoli
n.a.
120
confermare
11 Identificativo CMB
Identificativo T2S del
Credit Memorandum
Balance assegnato
dal proprietario del
DCA che è utilizzato
per i pagamenti in
associazione al conto
titoli
n. a.
n. a.
L’informazion
e relativa
all’identificati
vo T2S del
CMB non è
disponibile a
MT che
pertanto
assegna il
valore fittizio
Il cliente deve
fornire
obbligatoriam
ente
l’Identificativo
T2S del CMB
121
“da definire”
12 Tipologia di
operazione
Specificazione della
tipologia di
operazione. Tipologie
di pagamento
presenti in Monte
Titoli:
aumento di
capitale ed
esercizio Warrant
pagamento
dividenti/proventi
fondi
pagamento
interessi/rimborso
pagamenti su
titoli denominati
in divisa estera
pagamenti su
Le tipologie di
pagamento si
riferiscono a
quelle in essere in
MT con l’avvio del
progetto
Harmonisation
Custody.
Monte Titoli
rende
disponibile
solo la
tipologia
“Pagamento
Titoli di
Stato” in
quanto il
pagamento è
appunto
previsto
obbligatoria
mente in T2S
“Pagamento
su Titoli di
Stato”
Obbligatorio
122
Titoli di Stato
13 Codice ABI del
soggetto pagatore
Indicazione del
codice ABI del
soggetto pagatore.
Potrebbe essere
assente in caso di
soggetto pagatore
non partecipante a
MT
X n.a. n.a.
14 Data inizio validità
Indicazione della data
di inizio validità
dell’associazione
conto titoli/conto cash
(DCA) al fine
dellagestione dei
pagamenti relativi a
CA
n. a. 27/04/2015 n.a.
15 Data fine validità Indicazione della data
di fine validità n. a.
Nessun
valore per
significare
data aperta
n.a.
123
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
N. Nome Colonna Formato Descrizione Commenti
Dati
esistenti in
MT
[AS-IS]
Assegnati di
default da
MT
Forniti
obbligatoria
mente dai
clienti
1 Parent BIC CHAR (11)
BIC della System
Entity responsabile
del Party
X
Cfr. 9.7 Tabella: Struttura dei
conti per il servizio di gestione
accentrata
2 Party BIC CHAR (11)
Indicazione del BIC
del Party al quale è
associato il conto
X
3 T2S Account ID Codice identificativo
del conto in T2S X
4 Codice ABI del
depositario
Indicazione del
codice ABI del
soggetto owner del
X
124
Securities account
5 Codice del conto
Identificativo del
Securities Account
secondo la codifica
ABI
X
6 Tipo conto
Indicazione del tipo
conto.
Può assumere uno
dei seguenti valori:
P: proprietà
T: terzi
L: liquidatore
X
7 Ruolo
Specificazione dell’
operatività del
soggetto. Può
ricoprire uno dei
seguenti ruoli:
emittente
intermediario
X
8 Tipologia di
operazione
Specificazione della
tipologia di
Le tipologie di
pagamento si
125
operazione.
Tipologie di
pagamento presenti
in Monte Titoli:
aumento di
capitale ed
esercizio
Warrant
pagamento
dividenti/proven
ti fondi
pagamento
interessi/rimbor
so
pagamenti su
titoli denominati
in divisa estera
corrispettivi
RCC
riferiscono a quelle
in essere in MT con
l’avvio del progetto
Harmonisation
Custody
X
n.a.
Ammesse
possibili
variazioni
126
ELEMENTI DI CONFIGURAZIONE AGGIUNTIVI NECESSARI NEL CASO IN CUI IL SOGGETTO SI AVVALGA DI
UNA BANCA TRAMITE IN T2
9 ABI banca d’
appoggio
Codice ABI della
banca di appoggio X n.a.
Ammesse
possibili
variazioni
10 ABI banca tramite Codice ABI della
banca tramite X n.a.
Ammesse
possibili
variazioni
11
Identificativo
conto RTGS della
banca tramite
Indicazione del
conto RTGS
Target2 della banca
tramite di
riferimento
X n.a.
Ammesse
possibili
variazioni
12 Data inizio
validità
Indicazione della
data di inizio validità
del conto titoli al
conto contante
X
n.a.
Ammesse
possibili
variazioni
13 Data fine validità
Indicazione della
data di fine validità
del conto titoli al
Ove non valorizzata
indica che la
relazione è attiva.
X
127
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
14
Identificativo
conto RTGS della
banca d’
appoggio
Indicazione del
conto RTGS
Target2 della banca
d’appoggio di
riferimento
X n.a.
Ammesse
possibili
variazioni
15 ABI banca d’
appoggio
Codice ABI della
banca di appoggio X n.a.
Ammesse
possibili
variazioni
16 Data inizio
validità
Indicazione della
data di inizio validità
del conto titoli al
conto contante
X n.a.
Ammesse
possibili
variazioni
128
17 Data fine validità
Indicazione della
data di fine validità
del conto titoli al
conto contante
Ove non valorizzata
indica che la
relazione è attiva.
Valorizzare questo
dato significa che si
vuole chiudere
l’associazione conto
titoli/conto contante
X
129
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.
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à.