Migration Preparation Schedule

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