migration preparation schedule€¦ · 1. owner del sistema real time gross settlement, garantendo:...

1

MIGRATION PREPARATION

SCHEDULE

T2S PROJECT

Versione 1.0

Sommario

1 GESTIONE DEL DOCUMENTO 5

1.1 Cronologia del documento 5

1.2 Acronimi ed abbreviazioni 5

1.3 Documentazione di riferimento 6

2 OBIETTIVO DEL DOCUMENTO 7

3 PANORAMICA DEL PROCESSO DI MIGRAZIONE A T2S 8

3.1 Pianificazione della migrazione 8

3.2 Attori coinvolti 9

3.3 Composizione della prima finestra 11

3.4 Composizione della seconda finestra 14

3.5 Composizione della terza finestra 15

3.6 Composizione della quarta finestra 16

4 PIANO DELLE ATTIVITA’ DI MIGRAZIONE 18

4.1 Attività e Synchronisation Point 18

5 MIGRAZIONE DEI DATI STATICI 25

5.1 Introduzione alla migrazione dei dati statici 25

5.2 Consegna ai clienti dei dati necessari per la configurazione in T2S 26

5.2.1 Dati dei Servizi di pre-settlement 29

5.2.2 Dati dei Servizi di Liquidazione 30

5.2.3 Dati dei Servizi di regolamento estero (DVP Cross-Border) 31

5.2.4 Dati dei Servizi di gestione accentrata emittenti ed intermediari 31

5.3 Conferma da parte dei clienti dei dati di configurazione forniti da Monte Titoli 33

5.4 Trasferimento dei dati ufficiali di configurazione al sistema di test 35

5.5 Pre-Migration Dress Rehearsal 35

5.6 Frozen Period 36

5.7 Go – live dei dati statici in T2S 37

5.8 Finestra di contingency per il caricamento dei dati statici 37

6 VARIAZIONI ALLE MODALITA’ DI PARTECIPAZIONE AI SERVIZI DI MONTE TITOLI 38

6.1 Modifica del soggetto pagatore 39

6.1.1 Modifica del soggetto pagatore nell’ ambito del servizio di gestione accentrata 39

6.1.2 Modifica del soggetto pagatore nell’ ambito del servizio di liquidazione 39

6.2 Modifica del soggetto liquidatore e della tipologia di adesione alla CCP 40

6.2.1 Modello operativo “A” o Modello di marginazione lordo 42

6.2.2 Modello operativo “B” o Modello di marginazione netto 53

7 T2S USER TESTING & MIGRATION TESTING 74

7.1 Introduzione 74

7.2 User Testing: attori coinvolti 74

7.3 User Testing 75

7.4 Migration Testing 77

8 GESTIONE DEGLI ACCESS RIGHT IN T2S (solo per DCP) 78

8.1 Introduzione alla gestione dei diritti di accesso a T2S 78

8.2 Concetti e definizioni principali 79

8.2.1 User Function 79

8.2.2 Privilegi 80

8.2.3 Secured Object 81

8.2.4 Secured Group 81

8.2.5 Ruolo 81

8.2.6 User 81

8.2.7 Data Scope 81

8.3 Configurazione degli access rights in T2S 84

8.3.1 Configurazione utenti 84

8.3.2 Configurazione privilegi 85

8.3.3 Configurazione ruoli 85

8.4 Processo di assegnazione degli access rights in T2S 86

8.4.1 Access rights a livello di Party 87

8.4.2 Access rights a livello di utenti 89

8.5 Gestione decentralizzata degli access rights in T2S 89

9 ALLEGATO A: DETTAGLIO DATI STATICI PER T2S 91

9.1 Introduzione 91

9.2 Party 93

9.3 Technical address network service link 96

9.4 Associazione di default negoziatore/liquidatore e relativi conti di regolamento: (LIQDEF) 97

9.5 Associazione Negoziatore/GCM/Liquidatore del GCM (CCPNEG) 101

9.6 Eccezione per mercato dell’ associazione negoziatore/liquidatore (LIQNEG) 104

9.7 Struttura dei conti per il servizio di gestione accentrata 107

9.8 Coordinate per il regolamento contante operazioni DVP 111

9.9 Pagamenti relativi alle corporate action in T2S 117

9.10 Pagamenti relativi alle corporate action in T2 123

10 Allegato B – Effetti sulle operazioni delle variazione della modalità di adesione alla CCP e/o cambio del

soggetto liquidatore 129

11 Allegato C – Access Rights per DCP 129

5

1 GESTIONE DEL DOCUMENTO

1.1 Cronologia del documento

Data Versione Dettagli

09/04/2014 1.0 -

1.2 Acronimi ed abbreviazioni

Nome Descrizione

ATIE Anagrafe Titoli Impediti ed Estratti

BAU Business As Usual

BIC Bank Identifier Code

CB Central Bank

CCP Central Counter Party

CMB Credit Memorandum Balance

CMS Collateral Management System

CSD Central Securities Depository

DCA Dedicated Cash Account

DCP Direct Connected Participant

DV Data Valuta

DVP Delivery Versus Payment

ECB European Central Bank

FIS Flussi Informativi Standardizzati

FOP Free Of Payment

GCM General Clearing Member

GUI Graphical User Interface

HW Hardware

ICM Individual Clearing Member

ICP Indirect Connected Participant

ISD Intended Settlement Date

MT Monte Titoli

MWE Migration Week End

MWEDR Migration Week End Dress Rehearsal

NSP Network Service Provider

OTC Over the Counter

PB Payment Bank

6

PMDR Pre Migration Dress Rehearsal

PMSP Pre - Migration Synchronisation Point

RBAC Role Based Access Controls

RCC Regolamento Corrispettivi Clienti

RTGS Real Time Gross Settlement

SAC Securities Account

SME System Maintain Entity

SNB Saldo Netto Bilaterale

SP Synchronisation Point

SW Software

T2S Target 2 Securities

UDFS User Detailed Functional Specifications

UHB User Handbook

VAN Value Added Network

1.3 Documentazione di riferimento

Documento di

riferimento Fonte

Istruzioni Servizio X-

TRM

http://www.montetitoli.it/area-

download/normativa/expressii/istrxtrm28102013senza.pdf

Istruzioni al Servizio di

Gestione Accentrata

per Intermediari ed

Emittenti

http://www.montetitoli.it/area-

download/normativa/gestioneaccentrata/istruzga08072013clean.pdf

Migration Weekend

Playbook

Documento del gruppo di lavoro “T2S/MT Testing & Migration”

pubblicato nell’ apposita sezione documentale di MT-X

T2S User Detail

Functional

Specifications

http://www.ecb.europa.eu/paym/t2s/pdf/UDFS_v1_2_1.pdf?02dbde

3be45b2d0bf5a5afcf4de34f36

T2S User Hand Book http://www.ecb.europa.eu/paym/t2s/pdf/User_Handbook_v1.0.pdf?

cc76cbb67593fe9e8b489e733a315bea

http://www.montetitoli.it/area-download/normativa/gestioneaccentrata/istruzga08072013clean.pdf

http://www.montetitoli.it/area-download/normativa/gestioneaccentrata/istruzga08072013clean.pdf

http://www.ecb.europa.eu/paym/t2s/pdf/UDFS_v1_2_1.pdf?02dbde3be45b2d0bf5a5afcf4de34f36


http://www.ecb.europa.eu/paym/t2s/pdf/User_Handbook_v1.0.pdf?cc76cbb67593fe9e8b489e733a315bea


7

2 OBIETTIVO DEL DOCUMENTO

L’obiettivo di questo documento è descrivere nel dettaglio l’insieme di attività e processi che

prevedono un coinvolgimento diretto del cliente o la sincronizzazione con lo stesso nel percorso

di migrazione a T2S, con riferimento alla migrazione dei dati statici del cliente.

In particolare, si dettagliano le attività che prevedono l’intervento del cliente, specificandone

modalità, tempistiche e contributo previsto, nell’ambito nel piano delle attività di migrazione

definito a livello di Eurosistema e di Monte Titoli.

L’insieme delle attività preparatorie della migrazione si riferisce principalmente ai tre mesi che

precedono l’avvio di T2S ed è applicabile solo alla prima finestra di migrazione. Le finestre

successive saranno trattate in un documento successivo.

In particolare, l’obiettivo del documento “Migration Preparation Schedule” è quello di fornire una

panoramica completa relativamente a:

Identificazione dell’insieme di attività preparatorie da finalizzarsi in vista della

migrazione a T2S e che prevedono un attivo coinvolgimento/interazione del/col cliente;

Definizione dell’insieme di Pre-Migration Synchronisation Point (PMSP) definiti a livello

di Eurosistema e di quelli aventi natura prettamente bilaterale, delineati tra Monte Titoli

ed i propri clienti;

Migrazione dei dati statici:

o descrizione e gestione del processo di migrazione a T2S e nei nuovi sistemi legacy

di Monte Titoli;

o descrizione degli elementi informativi necessari per la configurazione dei clienti nei

nuovi ambienti legacy di Monte Titoli ed in T2S; approccio al reperimento degli

elementi di configurazione necessari per la migrazione dei dati statici e gestione del

processo in caso di informazioni indispensabili a Monte Titoli ma non pervenute dai

clienti;

Definizione del “Frozen period” volto ad evitare eventuali variazioni ai dati statici di

configurazione;

Analisi di dettaglio dei possibili scenari di variazione alle modalità di partecipazione ai

servizi di Monte Titoli ammesse durante la migrazione a T2S;

Introduzione alla fase di testing della migrazione per la prima wave di migrazione a

T2S;

Introduzione alla gestione degli access rights in T2S ed in Monte Titoli (valido solo per

clienti DCP).

8

3 PANORAMICA DEL PROCESSO DI MIGRAZIONE A T2S

3.1 Pianificazione della migrazione

Il processo di migrazione verso la nuova piattaforma T2S è organizzato in quattro diverse

finestre di migrazione (c.d. migration waves), attualmente pianificate secondo lo schema sotto

riportato.

Ogni singola finestra di migrazione è suddivisa in tre fasi distinte. Con particolare riferimento

alla prima finestra di migrazione, si noti la schedulazione dettata dall’Eurosistema e definita

secondo quanto segue:

1. Fase di pre-migrazione: periodo antecedente il weekend di migrazione;

2. Fase di migrazione: weekend di migrazione a T2S vero e proprio;

3. Fase di stabilizzazione: periodo, conclusa la fase due, di verifica della nuova

piattaforma T2S.

Wave Fase di pre-

migrazione

Weekend di

migrazione

Fase di

stabilizzazione

1 24 marzo 2015 –

19 giugno 2015

19 giugno 2015 –

22 giugno 2015

22 giugno 2015 –

27 luglio 2015

2 04 gennaio 2016 –

25 marzo 2016

25 marzo 2016 –

28 marzo 2016

28 marzo 2016 –

25 aprile 2016

3 14 giugno 2016 –

09 settembre 2016

09 settembre 2016 –

12 settembre 2016

12 settembre 2016 –

17 ottobre 2016

4 03 novembre 2016 –

03 febbraio 2017

03 febbraio 2017 –

06 febbraio 2017

06 febbraio 2017 –

13 marzo 2017

9

3.2 Attori coinvolti

La tabella proposta di seguito fornisce un elenco dei diversi attori coinvolti nel processo di

migrazione verso la nuova piattaforma T2S, a prescindere dalla specifica finestra di migrazione

alla quale gli stessi prendono parte.

È bene specificare che ogni singolo soggetto partecipa al processo di migrazione alla

piattaforma T2S a seconda dello specifico ruolo che ricopre.

Con particolare riferimento alle Banche Centrali, nel nuovo panorama designato

dall’introduzione della piattaforma T2S, le stesse possono ricoprire quattro differenti ruoli,

ovvero:

1. Owner del sistema Real Time Gross Settlement, garantendo:

La connessione degli attuali sistemi RTGS Target 2 alla piattaforma T2S;

Il costante monitoraggio della liquidità in T2S nonchè il trasferimento della stessa

da/verso Target 2 (liquidity transfer orders);

La gestione dei Dedicated Cash Accounts (DCA) in T2S.

2. Gestore della liquidità, garantendo:

La connessione dei sistemi di Collateral Managament System (CMS) a T2S;

La gestione delle configurazioni necessarie per attivare i processi di collateralizzazione

in T2S;

L’ offerta di collaterale in T2S;

La riconciliazione dei movimenti derivanti dalle operazioni di collateralizzazione in T2S

con il CMS.

3. System Entity, garantendo:

La definizione e la gestione dei propri dati statici in T2S quali, ad esempio: Party, DCA.

4. Settlement Agent, garantendo:

La definizione di ogni singola Banca Centrale come soggetto partecipante di un CSD;

La gestione del link tra i propri conti titoli ed i DCA;

L’esecuzione del regolamento di operazioni di politica monetaria in T2S.

Per maggiori dettagli informativi si rimanda alla sezione “key documents” sul sito di ECB,

contenente la principale documentazione relativa a T2S, di cui al link:

http://www.ecb.europa.eu/paym/t2s/about/keydocs/html/index.en.html

http://www.ecb.europa.eu/paym/t2s/about/keydocs/html/index.en.html

10

Si precisa che alcune Banche Centrali, come descritto nelle successive tabelle, supporteranno

solo alcuni dei quattro ruoli precedentemente descritti.

ATTORI DESCRIZIONE

Migrating CSD

Insieme dei CSD che prendono parte a una specifica finestra di

migrazione.

Il processo di migrazione a T2S avviene coinvolgendo

simultaneamente le Banche Centrali Nazionali ed i soggetti clienti

dei CSD (CSD participant)

Migrating CB

Insieme delle Banche Centrali che prendono parte a una specifica

finestra di migrazione.

Il processo di migrazione a T2S avviene coinvolgendo

simultaneamente i CSD nazionali e le payment bank.

Come precedentemente descritto, si ricorda che le Banche

Centrali possono migrare alla nuova piattaforma T2S assumendo

uno o più ruoli, descritti in apertura al paragrafo 3.2 e di seguito

elencati:

Owner del sistema RTGS

Gestore della liquidità

System Entity

Settlement Agent

SME CSD

CSD che operano in T2S come SME, ovvero come “Securities

Maintaining Entities” degli strumenti finanziari dei quali sono Issuer

o Techical Issuer

CSD participant

(DCP/ICP)

I CSD participant, ovvero i clienti dei CSD. È possibile distinguere

due differenti tipologie di CSD participant, ovvero:

DCP: soggetti che interagiscono direttamente con la

piattaforma T2S in modalità A2A o U2A

ICP: soggetti che integagiscono con la piattaforma T2S

attraverso i CSD

Payment Bank

(DCP/ICP)

Le Payment Bank, ovvero i soggetti clienti delle Banche Centrali. È

possibile distinguere due differenti tipologie di Payment Bank:

DCP: soggetti che interagiscono direttamente con la

piattaforma T2S per la componente cash in modalità A2A

o U2A

ICP: soggetti che interagiscono con la piattaforma T2S

attraverso le Banche Centrali

11

Network Service

Provider (NSP)

Comprendono i due VAN (Value Added Network) di T2S, ovvero

“SIA/Colt” e “SWIFT” così come DL (Dedicated Link) che fornisce

“CoreNet”

RTGS Operator Operatori del sistema RTGS connessi alla piattaforma T2S, come

ad esempio il “T2S Operator”

T2S Operator Soggetto dell’ Eurosistema che supporta tutte le attività di

produzione della nuova piattaforma T2S

I successivi paragrafi e le corrispondenti tabelle riportano un elenco dei diversi attori coinvolti in

ogni finestra di migrazione, con indicazione del ruolo con il quale ogni soggetto vi prende parte.

Si specifica tuttavia che il contenuto potrebbe subire variazioni a seconda di quanto definito a

livello di Eurosistema.

Per informazioni di maggior dettaglio e per gli ultimi aggiornamenti circa la composizione ed i

ruoli assunti dai diversi attori, si invita a fare riferimento alla documentazione disponibile nell’

apposita sezione di T2S sul sito della ECB (cfr. link di seguito):

http://www.ecb.europa.eu/paym/t2s/progplan/html/index.en.html

3.3 Composizione della prima finestra

SOGGETTO TIPOLOGIA COMMENTO

Clearstream Banking SME CSD

CSD che opera solo come “Securities

Maintaining Entity” dei dati statici

migrati alla piattaforma T2S

Euroclear Belgium SME CSD




Euroclear France SME CSD




Euroclear Netherlands SME CSD




Iberclear SME CSD




LuxCSD SME CSD CSD che opera solo come “Securities


12




VP Securities SME CSD




Bank of Greece CSD in fase di

migrazione a T2S

Migrazione completa del sistema di

regolamento e delle relative attività a

T2S

Depozitarul Central CSD in fase di

migrazione a T2S



T2S

Malta Stock Exchange CSD in fase di

migrazione a T2S



T2S

Monte Titoli CSD in fase di

migrazione a T2S



T2S

SIX SIS CSD in fase di

migrazione a T2S

Migrazione del sistema di regolamento

e EUR e delle relative attività a T2S

Bank of Greece CB in fase di migrazione

a T2S

Copertura totale dei quattro diversi ruoli

delle Banche Centrali in T2S

Bank Centrali ta'Malta CB in fase di migrazione

a T2S



Banca d'Italia CB in fase di migrazione

a T2S



Banca Nationala a

Romaniei

CB in fase di migrazione

a T2S

Copertura parziale dei quattro diversi

ruoli delle Banche Centrali in T2S. In

particolare in qualità di: “System Entity”

e “RTGS System Owner”

Banco de Portugal CB in fase di migrazione

a T2S





Deutsche Bundesbank CB in fase di migrazione

a T2S





13


NBB CB in fase di migrazione

a T2S





Banque de France CB in fase di migrazione

a T2S





De Nederlandsche

Bank


a T2S





Banco de Espana CB in fase di migrazione

a T2S





Banque centrale du

Luxembourg


a T2S





Oesterreichische

Nationalbank


a T2S





Danmarks

Nationalbank


a T2S





Suomen Pankki CB in fase di migrazione

a T2S





Banka Slovenije CB in fase di migrazione

a T2S





Eesti Pank CB in fase di migrazione Copertura parziale dei quattro diversi

14


a T2S ruoli delle Banche Centrali in T2S. In



Lietuvos Respublikos

centriniu banku


a T2S





Magyar Nemzeti Bank CB in fase di migrazione

a T2S





Narodna banka

Slovenska


a T2S





3.4 Composizione della seconda finestra


Euroclear Belgium CSD in fase di

migrazione a T2S



T2S

Euroclear France CSD in fase di

migrazione a T2S



T2S

Euroclear Netherlands CSD in fase di

migrazione a T2S



T2S

Interbolsa CSD in fase di

migrazione a T2S



T2S

NBB - SSS CSD in fase di

migrazione a T2S



T2S

NBB CB in fase di migrazione

a T2S



15


Banque de France CB in fase di migrazione

a T2S



De Nederlandsche

Bank


a T2S



Banco de Portugal CB in fase di migrazione

a T2S



Wave 1 CSD e CB CSD e CB già migrati nella prima

finestra di migrazione

3.5 Composizione della terza finestra


Clearstream Banking CSD in fase di

migrazione a T2S



T2S

Keler Hungary CSD in fase di

migrazione a T2S



T2S

LuxCSD CSD in fase di

migrazione a T2S



T2S

OeKB CSD in fase di

migrazione a T2S



T2S

VP Lux CSD in fase di

migrazione a T2S



T2S

VP Securities CSD in fase di

migrazione a T2S

Migrazione dei sistemi di regolamento

EUR nonchè dei sistemi di regolamento

DKK che si prevede migreranno nel

2018

Deutsche Bundesbank CB in fase di migrazione

a T2S



Banque centrale du

Luxembourg


a T2S



Magyar Nemzeti Bank CB in fase di migrazione Copertura totale dei quattro diversi ruoli

16


a T2S delle Banche Centrali in T2S

Oesterreichische

Nationalbank


a T2S



Wave 1-2 CSD e CB migrati a T2S CSD e CB già migrati nelle prime due

wave di migrazione

3.6 Composizione della quarta finestra


CDCP Slovakia CSD in fase di

migrazione a T2S



T2S

Iberclear CSD in fase di

migrazione a T2S



T2S

AS Eesti

Vaartpaberikeskus

CSD in fase di

migrazione a T2S



T2S

CSD of Lithuania CSD in fase di

migrazione a T2S



T2S

Euroclear Finland CSD in fase di

migrazione a T2S



T2S

KDD Slovenia CSD in fase di

migrazione a T2S



T2S

BNY Mellon CSD CSD in fase di

migrazione a T2S



T2S

Banco de Espana CB in fase di migrazione

a T2S



Suomen Pankki CB in fase di migrazione

a T2S



Banka Slovenije CB in fase di migrazione

a T2S



17

Eesti Pank CB in fase di migrazione

a T2S



Lietuvos Respublikos

centriniu banku


a T2S



Narodna banka

Slovenska


a T2S



Wave 1-3 CSD e CB migrati a T2S CSD e CB già migrati nelle prime tre

finestre di migrazione

18

4 PIANO DELLE ATTIVITA’ DI MIGRAZIONE

La migrazione a T2S è suddivisa in più fasi:

attività preparatorie: fra queste sono incluse, a puro titolo di esempio, la preparazione

degli ambienti HW e SW, l’attivazione dei canali di comunicazione;

premigrazione o migrazione dei dati statici: è finalizzata al caricamento, in ambiente di

produzione, dei dati statici relativi a strumenti finanziari, partecipanti e conti titoli

necessari al buon funzionamento del nuovo sistema di regolamento T2S. Si tratta di un

vero e proprio passaggio in produzione dei suddetti dati statici;

collaudo delle attività di migrazione;

collaudo delle attività ordinarie di custody e di regolamento a seguito della simulazione

del weekend di migrazione;

fine settimana di migrazione o migrazione dei dati dinamici (operazioni): questa attività

rappresenta il momento ove si completa il il vero e proprio passaggio a T2S ed avviene

durante il cosiddetto week end di migrazione.

Al fine di controllare il corretto avanzamento delle attività di tutte le parti coinvolte, nonché

garantirne il giusto allineamento, sono stati definiti alcuni Synchronisation Points (SP) che si

applicano alle varie fasi del progetto.

A seconda della natura degli stessi, l’ ECB distingue:

synchronisation points bilaterali: coinvolgono solo un CSD/CB e l’ Eurosistema;

synchronisation points multilaterali: coinvolgono più attori, inclusi i clienti dei rispettivi

CSD/CB.

Al fine di garantire il successo del processo di migrazione nel suo complesso, Monte Titoli

definisce, oltre ai punti di sincronizzazione stabiliti a livello di Eurosistema, momenti addizionali

di allineamento con i propri clienti [4.1].

4.1 Attività e Synchronisation Point

Sono qui elencate le principali attività e S.P. che prevedono, direttamente o indirettamente, il

coinvolgimento dei clienti in funzione della migrazione a T2S.

Il seguente piano di migrazione potrebbe subire variazioni ed essere sottoposto a successive

ridefinizioni sulla base della pianificazione stabilita dall’Eurosistema unitamente a tutti gli altri

attori partecipanti alla prima finestra di migrazione a T2S.

19

Monte Titoli provvederà a dare tempestiva e circostanziata informativa di queste eventuali

variazioni tramite gli usuali canali di comunicazione con i clienti.

Si noti altresì che alcune delle attività elencate sono di pertinenza dei soli clienti DCP e pertanto

possono essere ignorate dai clienti ICP.

N DESCRIZIONE S.P. ATT. SOGGETTO SCADENZA

1

Binding declaration per aderire come

DCP

I clienti devono comunicare a Monte Titoli la

loro volontà (dichiarazione vincolante) di

partecipare come DCP alla piattaforma T2S

X DCP 24/02/2014

2

Distribuzione casi di test per la

certificazione dei DCP

L’ Eurosistema distribuisce ai partecipanti

diretti alla piattaforma T2S la lista dei casi di

test per la certificazione dei DCP

X

ECB

Marzo 2014

3

Distribuzione di contratti e membership

form – draft version

Data prevista per la pubblicazione della

bozza della documentazione contrattuale ai

clienti da parte di Monte Titoli

X

MT

15/05/2014

4

Distribuzione casi di test per

l’autorizzazione

Monte Titoli distribuisce ai partecipanti la

lista dei casi di test per il processo di

autorizzazione

X MT Settembre

2014

5

Registrazione presso i NSP

Ogni partecipante DCP deve completare

l’apposita registrazione presso i NSP

attraverso i rispettivi CSD/CB per l’ambiente

di collaudo

X DCP 31/10/2014

6

Richiesta assegnazione dei

certificati/token Per accedere all’ ambiente

di collaudo in funzione dell’inizio dei test di

connettività

X DCP 14/11/2014

7 Distribuzione di contratti, istruzioni e

membership form

20


Data prevista per la pubblicazione finale del

nuovo set contrattuale ai clienti da parte di

Monte Titoli

X MT

15/12/2014

8

Test di connettività

I DCP sono tenuti ad eseguire i suddetti test

per connettersi all’ambiente di collaudo T2S

di Community.

Gli ICP sono coinvolti negli opportuni test di

connettività con MT direttamente in

ambiente di collaudo T1.

X Clienti

(DCP/ICP)

Dal

03/12/2014

al

27/02/2015

9

Configurazione dei DCA e CMB

Le payment bank che offrono ai propri

clienti servizi di regolamento del contante

e/o client collateralisation devono

opportunamente autorizzare i clienti stessi

all’ utilizzo dei propri DCA (creazione CMB)

X X

PB

Entro

20/02/2015

10

Primo Dress Rehearsal di pre migrazione

Esecuzione del primo Dress Rehearsal full

di pre migrazione su dati statici relativi a

titoli e partecipanti in ambiente di collaudo

di Community, che corrisponde all’

ambiente di collaudo T1 di Monte Titoli

X

MT

Dal

23/02/2015

al

27/02/2015

11

Primo Dress rehearsal di pre migrazione:

debriefing

I clienti sono invitati ad inviare a Monte Titoli

i loro feedback relativi al risultato del primo

dress rehearsal nonché a riportare eventuali

problemi o criticità relativi ai dati statici

migrati in T2S e direttamente visibili nella

nuova piattaforma

X X

MT

DCP

Dal

03/03/2015

Al

07/03/2015

12

Processo di registrazione presso i NSP

Ogni partecipante DCP che prende parte ad

una particolare wave di migrazione deve

completare l’ apposita registrazione presso i

NSP attraverso i rispettivi CSD/CB per

l’ambiente di produzione

X DCP 27/02/2015

13 Richiesta dei certificati/token per X DCP 02/03/2015

21


accedere all’ ambiente di produzione

14 Test di certificazione per i DCP X DCP Entro marzo

2015

15

Inizio del Community testing

I CSD, le Banche Centrali ed i rispettivi

soggetti partecipanti sono chiamati a

prendere parte al Community Testing

X

CSD

CB

Clienti

(DCP/ICP)

02/03/2015

16

Test di connettività per la prima finestra

di migrazione

I DCP sono tenuti ad eseguire i suddetti test

per connettersi all’ ambiente di produzione

di T2S.

Gli ICP sono coinvolti negli opportuni test di

connettività con MT direttamente in

ambiente di produzione (MT T1)

X

Clienti

(DCP/ICP)

Dal

20/03/2015

al

03/04/2015

17

Termine per la conferma dei dati di

membership per la produzione

Scadenza per la conferma a Monte Titoli dei

dati di membership dei clienti per l’

ambiente di produzione

X

Clienti

(DCP/ICP)

20/03/2015

18

Dress Rehearsal del MWE

I clienti sono chiamati a partecipare per le

attività di loro competenza e ad acquisire i

risultati derivanti dalle prove relative

all’esecuzione del fine settimana di

migrazione e delle relative attività di

regolamento (in ambiente di Community di

T2S e nel corrispondente ambiente di

collaudo T1 di MT)

X

MT

Clienti

(DCP/ICP)

Dal

17/04/2015

al

20/04/2015

19

MWE Dress Rehearsal: debriefing

I clienti sono invitati a riportare a MT l’esito

della simulazione del weekend di

migrazione nonchè particolari criticità e

rischi legati anche alle loro attività “interne”

di migrazione

X X

MT

Clienti

(DCP/ICP)

Dal

23/04/2015

Al

24/04/2015

20 Go-live dei dati statici nell’ ambiente di

produzione di T2S e nei sistemi legacy di X X MT

Dal

27/04/2015

22


MT

Caricamento di tutti i dati statici e delle

relative applicazioni nel nuovo ambiente di

produzione T2S e nei nuovi sistemi legacy

di Monte Titoli

al

04/05/15

21

Finestra di contingency per il

caricamento dei dati statici in ambiente

di produzione di T2S

Periodo di buffer nel caso in cui dovessero

emergere criticità legate al processo di

caricamento e migrazione dei dati statici in

T2S

X X MT

Dal

05/05/2015

al

11/05/15

22 Dichiarazione di corretta esecuzione dei

test di certificazione X X

ECB

DCP 15/05/2015

23

Dichiarazione di corretta esecuzione dei

test di autorizzazione

I clienti dichiarano a Monte Titoli la corretta

esecuzione dei test di autorizzazione

X Clienti

(ICP/DCP) 15/05/2015

24

MWE dress rehearsal 1

Prima esecuzione delle prove generali del

fine settimana di migrazione con tutti i dati

di produzione.

Saranno protagonist tutti i soggetti coinvolti

nella prima wave di migrazione a T2S

X

MT

Clienti

(DCP/ICP)

Dal

15/05/2015

al

18/05/2015

25

Business day testing 1

Durante il business day testing si richiedere

ai clienti di immettere transazioni ed

operare esattamente come se fossero in

produzione. Queste prove si realizzano

nell’ambiente di collaudo T1 Monte Titoli

collegato all’ambiente T2S di Community

X Community

Dal

18/05/2015

al

20/05/2015

26

MWE Dress Rehearsal 1: debriefing

I clienti sono invitati ad inviare a MT i loro

feedback relativi al risultato del Dress

Rehearsal ed a riportare eventuali problemi

o criticità emerse durante l’esecuzione del

Dress Rehearsal stesso

X X

MT

Clienti

(ICP/DCP)

Dal

21/05/2015

al

22/05/2015

23


27

MWE Dress rehearsal 2

Seconda esecuzione delle prove generali

del fine settimana di migrazione con tutti i

dati di produzione.

Saranno protagonisti tutti i soggetti coinvolti

nella prima wave di migrazione a T2S

MT

Clienti

(DCP/ICP)

Dal

29/05/2015

al

01/06/2015

28

Business day testing 2

Durante il business day testing si richiedere

ai clienti di immettere transazioni ed

operare esattamente come se fossero in

produzione

X Community

Dal

01/06/2015

al

03/06/2015

29

MWE Dress rehearsal 2: debriefing

I clienti sono invitati ad inviare a Monte Titoli

i loro feedback relativi al risultato del

secondo Dress rRehearsal ed al colloquio

con la nuova piattaforma T2S nonché

riportare eventuali problemi o criticità

emerse.

L’esito positivo del suddetto Dress

Rehearsal potrebbe rappresentare un esito

positivo ad uno degli entry criteria a T2S.

X X

MT

Clienti

(ICP/DCP)

Dal

04/06/2015

al

05/06/2015

30

Dichiarazione di corretta esecuzione del

Dress Rehearsal del MWE

I clienti sono chiamati a dichiarare la

corretta esecuzione del Dress Rehearsal

del fine settimana di migrazione

X X

Clienti

(ICP/DCP)

Entro

06/06/2015

31

Migrazione dall’ ambiente di collaudo

legacy PI all’ambiente T2 di MT

I clienti, ove applicabile, sono chiamati a

migrare i loro ambienti di collaudo di pre-

produzione disconnettendoli dal vecchi

ambiente di collauto PI di Monte Titoli ed a

connettere gli stessi al nuovo ambiente di

collaudo T2 di MT (pre produzione).

In aggiunta i DCP devono connettere i loro

sistemi legacy direttamente all’ ambiente di

pre-produzione di T2S.

X

Clienti

(DCP/ICP)

15/06/2015

24


32

T2S GO-LIVE

ESECUZIONE DEL FINE SETTIMANA DI

MIGRAZIONE A T2S

X X TUTTI

Dal

19/06/2015

al

22/06/2015

Il passaggio in produzione a T2S (Migration Week End - MWE), di cui all’ultimo elemento della

tabella precedente e noto anche come processo di migrazione dei dati dinamici, è descritto in

dettaglio nel documento “Migration Weekend Playbook”.

25

5 MIGRAZIONE DEI DATI STATICI

5.1 Introduzione alla migrazione dei dati statici

Con migrazione dei dati statici si intende la migrazione dei dati di configurazione dei partecipanti

e degli strumenti finanziari presenti negli attuali sistemi legacy di Monte Titoli verso i nuovi

sistemi legacy di produzione e versoT2S.

Monte Titoli, in linea col piano strategico di migrazione alla piattaforma T2S definito a livello di

Eurosistema, caricherà i dati statici a partire da circa un mese e mezzo prima (27 aprile 2015)

rispetto alla data di avvio di T2S (22 giugno 2015).

Successivamente al caricamento tali dati statici saranno gestiti secondo criteri BAU fino all’avvio

di T2S. Nello specifico, per ciò che concerne i dati statici dei partecipanti si applicano i criteri

descritti al paragrafo 5.6, mente per i nuovi strumenti finanziari sarà Monte Titoli ad inserirli

parallelamente sia nel vecchio ambiente che nel nuovo sistema.

Le ragioni per le quali Monte Titoli procederà al caricamento dei dati statici a partire dal 27

aprile 2015 risultano essere le seguenti:

Evitare rifiuti da parte della piattaforma T2S relativamente a Settlement Instruction con

data regolamento antecedente, durante il weekend di migrazione (fail);

Minimizzare il rischio intrinseco al processo di migrazione anche attraverso una

gestione separata delle attività da svolgersi nel periodo di premigrazione a T2S;

Dedicare un tempo adeguato all’attività di caricamento dei dati statici fondamentali per il

corretto funzionamento della nuova piattaforma di regolamento e dei servizi di Monte

Titoli.

Nel lasso temporale che precede il weekend di migrazione a T2S, Monte Titoli ed i suoi clienti

sono direttamente coinvolti in una serie di specifiche attività preparatorie per la definizione del

nuovo insieme di dati necessari per la configurazione dei clienti in T2S e per la migrazione dei

dati statici (informazioni riguardanti i partecipanti, i conti titoli nonché gli elementi di

configurazione ad essi correlati) che popolano gli attuali sistemi legacy.

In sintesi, il processo relativo alla migrazione dei dati statici si svolge secondo i seguenti passi:

1. Consegna ai clienti dei dati necessari per la configurazione in T2S

2. Conferma da parte dei clienti (e/o settlement agent/agenti pagatori) dei dati di

configurazione forniti da Monte Titoli

3. Trasferimento dei dati ufficiali di configurazione al sistema di test

4. Pre-Migration Dress Rehearsal

26

5. Inizio Frozen Period

6. Go – live dei dati statici in T2S

7. Finestra di contingency per il caricamento dei dati statici

Si fornisce di seguito una rappresentazione grafica dei principali step caratterizzanti il processo

di migrazione dei dati statici in T2S, che saranno oggetto di approfondimento nei successivi

paragrafi.

5.2 Consegna ai clienti dei dati necessari per la configurazione in T2S

In data 15 dicembre 2014, Monte Titoli fornirà ai propri clienti una fotografia dei dati di

configurazione presenti negli attuali sistemi di produzione, adattati alla luce delle informazioni

necessarie per T2S.

Questi dati, fino ad oggi raccolti mediante Bit-Club e/o gli appositi moduli di Partecipazione quali

ad esempio la Scheda Dati Operativi, saranno disponibili e accessibili mediante un’interfaccia

web che consente ai clienti di prenderne visione ed eventualmente modificarli oppure inserirne

di nuovi.

L’accesso a questo strumento avverrà tramite le credenziali di accesso a MT-X già in possesso

dei clienti. I clienti che ne fossero sprovvisti, sono invitati a farne richiesta direttamente a Monte

27

Titoli indirizzando la richiesta all’ufficio Client Support ([email protected]) che sarà in grado di

fornire anche ulteriori informazioni in merito all’utilizzo dello strumento.

Si ricorda che tale strumento sarà poi utilizzato anche a regime, in sostituzione dell’attuale Bit-

Club e della Scheda Dati Operativi, per la gestione dei dati di configurazione dei vari servizi. A

tempo debito ne sarà, altresì, reso disponibile un manuale d’uso.

Qualora il cliente dovesse richiedere una variazione dei dati di configurazione a valere

sull’attuale sistema di produzione, e dunque con le attuali modalità, a partire dal 15/12/2014 e

fino al termine ultimo a disposizione per le modifiche del 20/03/2015, sarà sua cura riportarla

anche nel nuovo ambiente di produzione mediante lo strumento web, affinchè venga presa in

carico anche al fine della migrazione a T2S.

Affinché il processo di migrazione dei dati statici in T2S possa avvenire con successo,

permettendone dunque il go-live ed il caricamento nei nuovi sistemi legacy di Monte Titoli ed in

T2S, Monte Titoli dovrà presentare in maniera analitica ai clienti l’insieme di informazioni

necessarie per la configurazione degli stessi in T2S.

Infatti, l’introduzione di T2S richiede elementi informativi differenti e talvolta aggiuntivi rispetto a

quelli attualmente in essere nei sistemi di Monte Titoli.

Come illustrato nel seguente schema, Monte Titoli procede alla migrazione dei dati in base

all’origine dell’elemento informativo.

In particolare, l’insieme di informazioni attualmente esistenti nei sistemi legacy di Monte Titoli

verrà migrato sulla base di specifiche regole di mappatura che definiscono le modalità di

traduzione delle informazioni dall’attuale sistema Monte Titoli a T2S.

mailto:[email protected]

28

Tale approccio è volto a garantire maggiore efficienza al processo di preparazione alla

migrazione in quanto limita l’intervento dei clienti alle eventuali modifiche dei soli valori di default

assegnati da Monte Titoli e/o all’inserimento dei soli dati nuovi richiesti alla luce delle

caratteristiche e peculiarità di T2S.

In questo secondo caso, qualora non sia possibile l’assegnazione di valori predeterminati, è

indispensabile che siano i clienti stessi a provvedere ad una puntuale comunicazione degli

elementi informativi necessari per la loro configurazione.

Le informazioni attualmente non presenti nei sistemi legacy di Monte Titoli, e richieste da T2S,

risultano essere le seguenti:

Coordinate per il regolamento del contante di operazioni DVP e/o per l’insieme di

operazioni di autocollateral da associare al conto titoli

Coordinate per i pagamenti relativi ai Titoli di Stato

Coordinate per pagamenti relativi alle Corporate Action da effettuarsi in T2S

Più in dettaglio, i dati presentati tramite l’interfaccia web sono relativi alla configurazione dei

seguenti servizi:

Servizi di pre-settlement

Servizio di regolamento

Servizio di regolamento estero (DVP Cross Border)

Servizio di gestione accentrata (emittenti ed intermediari)

Elementi

informativi

Esistenti nei sistemi Monte Titoli

Identificazione regole di mappatura

Nuove informazioni

Richieste per le caratteristiche di T2S

Obbligatoriamente comunicate dai clienti

Assegnate di default da Monte Titoli

29

Le configurazioni relative ai servizi FIS, RCC saranno proposte nello strumento web per

completezza di informazione, nonostante non si preveda subiscano alcuna variazione in quanto

non direttamente impattate dalla migrazione alla nuova piattaforma T2S.

5.2.1 Dati dei Servizi di pre-settlement

Per ciò che concerne le configurazioni relative al servizio di pre-settlement (X-TRM), troverete a

seguire tutti gli elementi informativi di dettaglio inerenti a:

1. Associazione Negoziatore/Liquidatore, con l’indicazione del liquidatore di default e

relativi conti di regolamento, di default e non (LIQDEF);

2. Associazione Negoziatore/Liquidatore relativamente sia ai mercati garantiti sia non

garantiti come eccezione rispetto alla (LIQDEF) in base a Provenienza e Mercato di

Negoziazione (LIQNEG);

3. Associazione Negoziatore/General Clearing Member/Liquidatore per i soli mercati

garantiti (CCPNEG).

Nello strumento web messo a disposizione, i dati di cui sopra sono presentati dal punto di vista

rispettivamente del:

soggetto negoziatore

soggetto liquidatore

Il soggetto liquidatore avrà quindi la visibilità di tutte le configurazioni dei partecipanti

(negoziatori) dai quali è stato designato come liquidatore.

Sono inoltre fornite, pur non essendo impattate da T2S, anche le configurazioni per il

regolamento delle operazioni provenienti dal mercato EuroTLX, Hi-MTF e EuroMOT che include

anche il segmento ExtraMot sui sistemi esteri Euroclear e Clearstream (ICSD).

Con particolare riferimento all’Associazione Negoziatore/Liquidatore di cui al precedente elenco,

si specifica che con T2S l’associazione attualmente esistente tra soggetto negoziatore e

soggetto liquidatore, oggi comprensiva dei soli soggetti che sono indiretti alla liquidazione,

comprende anche la configurazione dei soggetti che partecipano alla liquidazione (associazione

con se stessi).

Per “liquidatore di default” si intende l’associazione negoziatore/liquidatore che il sistema di pre-

settlement adotta in assenza di indicazioni in merito al liquidatore e/o al conto titoli da parte del

negoziatore al momento di istruire un’operazione.

30

Poichè oggi in X-TRM sono quasi sempre presenti per uno stesso soggetto due differenti

configurazioni, una relativa alla liquidazione lorda e un’altra relativa alla netta, potrebbero

verificarsi situazioni, anche se rare, nelle quali le due differiscono.

In presenza di tale scenario, Monte Titoli le comunica entrambe attraverso lo strumento web

dedicato ed il cliente è invitato ad indicare quale delle due configurazioni deve essere utilizzata

in T2S.

In particolare, si chiede che il cliente:

1. inserisca la configurazione prescelta impostando come sistema di regolamento il valore

“T2S”;

2. chiuda le due configurazioni per i due sistemi obsoleti, impostandone la data di chiusura

al 19 giugno 2015.

Infine, tra gli elementi di configurazione forniti ai clienti, Monte Titoli garantisce piena visibilità

anche delle seguenti informazioni:

elenco delle funzioni sottoscritte e relative modalità di comunicazione;

elenco dei soggetti ai quali è stato conferito mandato operativo per X-TRM, con

indicazione di dettaglio delle funzioni delegate nonché del relativo profilo abilitato; i

soggetti deleganti hanno visibilità di tutti i soggetti ai quali hanno conferito mandato per

una data funzione e per ciascuno dei codici CED a loro assegnati. Viceversa i soggetti

assegnatari potranno vedere tutti i mandati ricevuti per ciascuna funzione e per ciascun

CED assegnatario;

elenco dei soggetti che hanno conferito PoA (Power of Attorney) contrattuale per X-

TRM. Il conferimento del PoA contrattuale impone, direttamente o indirettamente, una

doppia conferma anche da parte dei soggetti ai quali è stata conferito il PoA in relazione

ai dati di configurazione forniti da Monte Titoli. Infatti, qualora non sia stata conferito

PoA contrattuale, i dati di membership saranno acquisiti e considerati validi se inviati

dal cliente stesso.

Nel caso in cui sia stata conferito PoA contrattuale, i soggetti ai quali è stato conferito

PoA sono tenuti a confermare i dati di membership necessari per le relative

configurazioni in T2S.

5.2.2 Dati dei Servizi di Liquidazione

I clienti sono tenuti a fornire per ciascun conto titoli detenuto le coordinate del conto contante

T2S (DCA) associato, al fine di consentire il regolamento DVP delle operazioni.

31

Il cliente deve indicare se intende utilizzare o meno la funzionalità di auto-collateralizzazione

valorizzando l’apposito indicatore.

Analogamente il cliente indica, valorizzando apposito indicatore, se le operazioni istruite a

valere sul dato conto, in assenza di specifica indicazione all’interno della stessa istruzione,

debbano essere considerate come “Hold” o “Released” dal sistema (cfr. paragrafi “Struttura dei

conti per il Servizio di gestione accentrata” e “Coordinate per il regolamento contante di

operazioni DVP”).

Si noti che, dal momento che la definizione dei conti DCA è di competenza delle Banche

Centrali, le coordinate del conto DCA non sono note a priori a Monte Titoli e pertanto devono

essere fornite a Monte Titoli direttamente dal cliente.

Le suddette configurazioni si riferiscono al servizio di Liquidazione presso la piattaforma T2S. Il

regolamento presso gli ICSD delle operazioni provenienti da mercato, quali ad esempio

EuroMOT e le corrispondenti configurazioni non subiscono variazioni rispetto a quelle

attualmente registrate in Bit-Club.

5.2.3 Dati dei Servizi di regolamento estero (DVP Cross-Border)

Il servizio di regolamento estero, come specificato nelle corrispondenti “Istruzioni del Servizio”,

copre i trasferimenti di strumenti finanziari emessi dal CSD estero fra un partecipante Monte

Titoli ed un partecipante ad un sistema di regolamento esterno a T2S (a riguardo si invita a

consultare il documento nell’ apposita sezione documentale: http://montetitoli.it/area-

download/normativa/istrregesteromaggio2012.pdf).

Per ciò che concerne tale servizio non si evidenziano, al momento, variazioni e necessità di

informazioni aggiuntive e specifiche per T2S rispetto a quelle attualmente in essere in Bit-Club.

Si specifica che, tuttavia, l’intero set di informazioni relative al servizio di regolamento estero

saranno anch’esse disponibili e visualizzabili attraverso il web tool.

5.2.4 Dati dei Servizi di gestione accentrata emittenti ed intermediari

Le configurazioni relative al servizio di gestione accentrata riguardano la struttura dei conti dei

partecipanti Monte Titoli in T2S (cfr. tabella 4.7).

Con riferimento a quest’ultima, si specifica che tutti i conti titoli validi alla data di migrazione dei

dati statici, indipendentemente dal fatto che abbiano saldo o meno e dall’eventuale esistenza di

blocchi operativi, saranno definiti e configurati in T2S.

http://montetitoli.it/area-download/normativa/istrregesteromaggio2012.pdf

http://montetitoli.it/area-download/normativa/istrregesteromaggio2012.pdf

32

Saranno inoltre fornite indicazioni in merito ai mandati operativi in essere ed ai canali di

comunicazione utilizzati dai clienti.

In corrispondenza di ciascun conto titoli, sia esso intermediario od emittente, sarà indicata la

banca pagatrice e le relative coordinate di pagamento per ciascuna tipologia di operazione, di

cui alla tabella sottostante.

Si specifica che lo schema proposto di seguito gestisce anche la specifica fattispecie di banca

pagatrice per emittente utilizzata successivamente in fase di assegnazione dell’incarico da parte

del soggetto emittente:

In T2S, Monte Titoli offrirà ai propri clienti la possibilità di indicare il sistema di pagamento sul

quale operare, T2S ovvero T2, per ciascuna tipologia di operazione.

A seconda delle diverse esigenze di business, i clienti avranno infatti la facoltà di scegliere se

configurare i pagamenti relativi alle corporate action in T2 o T2S, fatta eccezione per:

pagamenti relativi ai “Titoli di Stato”, effettuati unicamente nel sistema di pagamento

T2S;

“Pagamento Corrispettivi RCC”, ove è previsto il pagamento solo in T2, in linea con

quanto previsto dalle prassi di Harmonization Custody.

In ogni caso Monte Titoli riporterà le configurazioni in vigore in T2 al momento della migrazione

a T2S per tutte le tipologie di pagamento diverse dalle operazioni scaturite dal pagamento su

Titoli di Stato.

33

Ne consegue che il cliente dovrà fornire per tempo a Monte Titoli, in corrispondenza di ciascuno

dei propri conti titoli, le coordinate relative al conto cash ad esso associato, in particolare:

Codice BIC della Banca Centrale in cui è detenuto il conto cash;

Codice BIC (Party BIC) della Payment Bank a cui è intestato il conto cash;

Identificativo del DCA;

Identificativo del Credit Memorandum Balance (CMB) assegnato al/i conto/i titoli per il

regolamento del contante.

Per informazioni di maggior dettaglio circa il contenuto informativo dei principali dati di

configurazione, si faccia riferimento all’allegato presente al punto 9.8 (Coordinate per

pagamento contante operazioni DVP).

5.3 Conferma da parte dei clienti dei dati di configurazione forniti da Monte Titoli

Nel lasso temporale che va dal 15 dicembre 2014, data di consegna ai clienti dei dati necessari

per la configurazione dei clienti, al 20 marzo 2015, i clienti sono tenuti a:

1 prendere visione degli elementi di configurazione di cui al capitolo 5.2;

2 variare, se del caso, gli elementi di configurazione di cui al punto 1;

3 chiudere, se del caso, gli elementi di configurazione ritenuti non più necessari in T2S;

4 inserire, se del caso, gli elementi di configurazione da utilizzare dal momento della

partenza di T2S;

5 accettare eventuali incarichi di liquidatore e/o agente pagatore.

Tali attività sono necessarie al fine di predisporre e confermare la correttezza dei dati di

configurazione che saranno successivamente migrati da Monte Titoli a T2S come dati di

produzione.

In particolare, in tale fase il cliente è tenuto a prendere attenta visione del set di informazioni

fornitegli e valutarne la correttezza/esaustività nonché fornire puntuale conferma degli elementi

di configurazione condivisi.

Qualora il cliente abbia demandato parte della sua operatività a soggetti terzi, quali soggetti

pagatori piuttosto che settlement agent, anche questi ultimi sono chiamati ad intervenire e

confermare/modificare i dati in relazione ai rispettivi ruoli assunti.

Si specifica che, nella situazione in cui il cliente o settlement agent/soggetto pagatore non

facciano pervenire, entro le scadenze previste, alcuna comunicazione di variazione o

34

accettazione rispetto alle informazioni di configurazione a loro fornite, Monte Titoli assumerà

come validi, qualora esistenti, i valori di default assegnati e precedentemente comunicati.

Per ciò che concerne tutti gli elementi di configurazione “nuovi” poiché caratteristici di T2S e

non attualmente presenti nei sistemi legacy di Monte Titoli, i clienti sono obbligatoriamente

tenuti a darne comunicazione.

Data la criticità di questi elementi informativi, qualora il cliente non dovesse comunicarli in

tempo utile per la migrazione, Monte Titoli applicherà le seguenti configurazioni di default:

Coordinate per pagamenti di Corporate Action: Monte Titoli assume valido il set di

informazioni definito nell’ ambito del progetto Harmonisation Custody, ovvero le

coordinate T2 in essere nel momento della migrazione;

Coordinate per pagamento su Titoli di Stato: con riferimento all’obbligatorietà di questo

dato, per il pagamento in T2S, qualora i clienti abbiano fornito le informazioni riguardo

le coordinate per il regolamento contante per operazioni DVP e per l’insieme di

operazioni di autocollateral in associazione al conto titoli ma non le coordinate per il

pagamento di proventi relativi ai Titoli di Stato, si assume per queste ultime il medesimo

valore comunicato per le coordinate DVP;

Coordinate per il regolamento contante per operazioni DVP e per l’insieme di operazioni

di autocollateral in associazione al conto titoli: con riferimento all’obbligatorietà di

questo dato, qualora i clienti abbiano fornito informazioni relativamente alle coordinate

per il pagamento su Titoli di Stato, ma non le coordinate per il pagamento di operazioni

DVP, si assume per queste ultime il valore comunicato per le coordinate relative ai

pagamenti sui Titoli di Stato;

Coordinate per il regolamento contante per operazioni DVP e per l’insieme di operazioni

di autocollateral in associazione al conto titoli e coordinate per pagamenti relativi ai

Titoli di Stato.

ATTENZIONE: nel caso in cui dette coordinate non dovessero essere comunicate dal

cliente, lo stesso si troverà nell' impossibilità di regolare operazioni DVP e/o di

effettuare operazioni di autocollateral e non potrà ricevere i proventi derivanti da

pagamenti effettuati su Titoli di Stato. In questo caso si avranno inoltre i seguenti effetti:

o durante il weekend di migrazione tutte le istruzioni DVP oggetto di migrazione

che fanno riferimento ad un conto titoli senza alcuna associazione ad uno o più

35

conti contante DCA saranno automaticamente respinte dalla nuova piattaforma

T2S e pertanto risulteranno non migrate. Queste operazioni dovranno essere

nuovamente istruite dai clienti stessi come operazioni FoP fino alla

comunicazione a Monte Titoli di una valida e corretta coordinata contante.

o l'ammontare dovuto al cliente relativamente al pagamento su Titoli di Stato

rimarrà sul conto contante di Monte Titoli fino a quando il cliente stesso non

provvederà a comunicare a Monte Titoli le informazioni relative alle coordinate

per i pagamenti su Titoli di Stato. Eventuali operazioni di pagamento effettuate

da Monte Titoli in via amministrativa saranno addebitate al cliente secondo le

tariffe vigenti al momento.

5.4 Trasferimento dei dati ufficiali di configurazione al sistema di test

In data 20 febbraio 2015 Monte Titoli esporterà i dati ufficiali di configurazione opportunamente

confermati o impostati dai clienti (e/o settlement agent/soggetto pagatore) mediante la

piattaforma web per le attività di membership e li traferirà nel sistema di collaudo per poter

effettuare le prove generali del processo di migrazione dei dati statici (Pre-Migration Dress

Rehersal).

I clienti che hanno una cardinalità di conti elevata potranno limitarsi ad inserire nello strumento

web di configurazione fino alla data del 19 febbraio 2015 le principali casistiche di gestione; non

è necessario quindi inserire tutti i dati di produzione.

5.5 Pre-Migration Dress Rehearsal

In data 23 febbraio 2015, Monte Titoli eseguirà una prova di Dress Rehearsal nell’ambiente di

collaudo di Community sull’insieme di dati statici opportunamente confermati/modificati dal

cliente e/o settlement agent/soggetto pagatore e prelevati dall’ambiente di produzione. Si

specifica che l’esecuzione del Pre-Migration Dress Rehearsal non richiede alcuna

partecipazione attiva dei clienti ma sarà eseguito unicamente da Monte Titoli.

La corretta esecuzione del test di Pre-Migration Dress Rehearsal rappresenta un pre requisito

per Monte Titoli per l’esecuzione del test di Migration Weekend Dress Rehearsal.

Lo strumento di configurazione dei dati statici via web sarà a questo punto disponibile anche in

ambiente di collaudo e consentirà ai clienti di impostare configurazioni per eventuali test che

potranno poi essere riportate nell’ambiente di produzione.

36

Immediatamente dopo la conclusione del dress rehearsal di pre-migrazione, dal 3 marzo 2015

al 7 marzo 2015, Monte Titoli prevede un momento di debriefing con i propri partecipanti, con

l’obiettivo di valutare l’ output del test nonché analizzare potenziali criticità e problematiche

emerse.

5.6 Frozen Period

La scadenza del 20 marzo 2015 costituisce per i clienti il termine ultimo per l’aggiornamento dei

dati di configurazione che saranno utilizzati per l’effettiva migrazione a T2S. Coerentemente con

quanto descritto in precedenza, a partire dal successivo 21 marzo 2015, Monte Titoli non

accetterà più alcuna modifica alle configurazioni che saranno utilizzate per il caricamento

iniziale nell’ambiente di produzione.

Si noti che tali limitazioni si applicano a tutti i servizi erogati da Monte Titoli con particolare

riferimento ai dati che afferiscono direttamente al nuovo sistema T2S. Dal 21 marzo 2015 al 27

aprile 2015 Monte Titoli verificherà la consistenza dei dati al fine di garantire il successo della

migrazione degli stessi e del successivo weekend di migrazione.

Nell’evenienza di operazioni societarie quali ad esempio le fusioni, è bene precisare che queste

costituiscono anche in condizioni ordinarie operazioni che richiedono un certo tempo e

un’adeguata analisi per poter essere completate con successo. A maggior ragione se previste

in prossimità di una migrazione epocale come quella qui descritta alla piattaforma T2S debbono

essere considerate e pianificate con maggior anticipo e maggior cura e non possono essere

considerate come operazioni BAU.

Eventuali nuovi emittenti di strumenti finanziari che avessero esigenza di registrarsi presso

Monte Titoli perché intenzionati ad emettere nuovi strumenti in questo “frozen period” sono

invitati a completeare le pratiche di registrazione in tempo utile ovvero prima del 21 marzo al

fine di ridurre al minimo gestioni eccezionali che potrebbero introdurre problemi durante la fase

di migrazione in quanto appunto situazioni gestite in modo non ordinario e quindi non

collaudabili.

Si specifica che non è previsto alcun allineamento automatico fra gli ambienti da parte di Monte

Titoli, ma gli stessi devono essere apportati direttamente dal cliente secondo criteri differenti in

relazione all’esigenza di voler alimentare l’ambiente di test piuttosto che di produzione, o

entrambi.

Alla luce di quanto detto, si possono verificare i seguenti scenari:

37

Caso 1: variazione apportata a cura del cliente in doppio, sia in ambiente di produzione

che di test;

Caso 2: variazione apportata dal cliente solo in ambiente di test. In tal caso gli elementi

di configurazione inseriti non saranno presenti in ambiente di produzione, ovvero non

saranno migrati a T2S e nei nuovi sistemi anagrafici di Monte Titoli.

Il cliente potrà, quindi, fruire della variaizone apportata esclusivamente per finalità di

collaudo;

Caso 3: variazione apportata solo in ambiente di produzione. In tal caso la

configurazione inserita sarà quindi migrata a T2S e nei nuovi sistemi legacy di Monte

Titoli.

Eventuali variazioni alle configurazioni richieste nei vecchi ambienti legacy di Monte Titoli, se

ritenute necessarie anche per T2S, dovranno essere riportate a carico del cliente in ambiente di

produzione e/o di collaudo a seconda delle esigenze sopra illustrate.

5.7 Go – live dei dati statici in T2S

Durante la fase di pre-migrazione, l’ECB richiede che tutti i dati statici siano caricati

nell’ambiente di produzione T2S e nei propri sistemi legacy e successivamente gestiti/alimentati

secondo criteri BAU.

Alla luce del piano di migrazione di Monte Titoli alla piattaforma T2S, il go-live dei dati statici

avrà luogo a partire dal 27 aprile 2015 per un periodo di circa cinque giorni lavorativi.

A partire da tale data, tutti i dati statici di Monte Titoli saranno presenti nel nuovo ambiente di

produzione di T2S così come nei nuovi sistemi legacy di Monte Titoli.

5.8 Finestra di contingency per il caricamento dei dati statici

Il periodo che va dal 5 all’ 11 maggio 2015 sarà utilizzato da Monte Titoli per completare le

attività di migrazione dei dati statici, nel caso in cui le stesse dovessero prolungarsi a causa di

situazioni impreviste non individuate nelle precedenti fasi di collaudo.

38

6 VARIAZIONI ALLE MODALITA’ DI PARTECIPAZIONE AI SERVIZI DI

MONTE TITOLI

Per consentire ai clienti di adottare le modalità di partecipazione che meglio si confanno alle

specifiche esigenze di business della nuova piattaforma di regolamento T2S ed al contempo

contenere i rischi operativi legati al processo di migrazione stesso, andiamo ora ad illustrare le

variazione delle modalità di partecipazione ai servizi consentite da Monte Titoli all’atto della

partenza della nuova piattaforma (Migration Week End).

Qualora il cliente sia interessato a modificare le proprie modalità di partecipazione ai servizi di

Monte Titoli in concomitanza con la migrazione alla piattaforma T2S, si suggerisce di prendere

accuratamente nota delle conseguenze che queste modifiche comportano.

Nei successivi paragrafi sono descritte in dettaglio le casistiche di variazione ammesse e non

ed i relativi impatti sui dati dinamici (operazioni X-TRM).

È bene sottolineare che, in caso di cambiamenti ammessi, questi saranno effettivi dal lunedì 22

giugno 2015, ma dovranno essere opportunamente comunicati dai clienti a Monte Titoli dal 15

dicembre 2014 al 20 marzo 2015.

Fra le variazione alle modalità di partecipazione ai servizi sono incluse l’ attivazione e/o il

recesso da uno o più servizi.

Le variazioni alle operazioni X-TRM conseguenti ad una variazione anagrafica determinano il

contenuto del flusso informativo G56 dei soggetti coinvolti rispetto ai diversi ruoli (ad esempio

liquidatore o General Clearing Member).

Di seguito si analizzeranno le seguenti categorie di variazione:

Cambio del soggetto pagatore per il servizio di gestione accentrata e/o per il servizio di

liquidazione

Cambio del soggetto liquidatore per le operazioni OTC e/o provenienti da mercati non

garantiti

Cambio del soggetto liquidatore per i mercati garantiti e/o cambio della tipologia di

adesione alla controparte centrale

39

6.1 Modifica del soggetto pagatore

6.1.1 Modifica del soggetto pagatore nell’ ambito del servizio di gestione accentrata

E’ consentita la modifica del soggetto pagatore per la gestione accentrata nel periodo a cavallo

del weekend di migrazione e segue le medesime logiche di variazione attuali.

Si noti che, coerentemente con quanto definito nell’ambito del progetto Harmonisation Custody

(cash distribution), per i pagamenti relativi alle corporate action con data valuta a partire dal

lunedì ed il martedì successivi al weekend di migrazione, il nuovo soggetto pagatore riceverà i

messaggi previsionali/definitivi come segue:

6.1.2 Modifica del soggetto pagatore nell’ ambito del servizio di liquidazione

E’ consentita la modifica del soggetto pagatore per il regolamento delle operazioni contro

pagamento nel corso del weekend di migrazione, in quanto operazione non critica.

Poiché da un punto di vista della piattaforma X-TRM, il soggetto pagatore potrebbe risultare

presente nelle operazioni, è necessario che vi sia coerenza con le configurazioni statiche

impostate; alternativamente il sistema assume il dato impostato per default.

Si precisa che la variazione del soggetto pagatore si applica anche alle istruzioni fail, cioè alle

istruzioni in attesa di regolamento con ISD antecedente al weekend di migrazione a T2S.

La variazione del soggetto pagatore per il regolamento ha un’influenza diretta sul calcolo del

saldo contante e del purchasing power del soggetto pagatore.

6.2 Modifica del soggetto liquidatore e della tipologia di adesione alla CCP

A seconda del tipo di operazioni presenti in X-TRM al momento della migrazione, e quindi delle

configurazioni cliente che ne consentono il corretto trattamento, la variazione del soggetto

liquidatore si può applicare:

1. alle sole operazioni OTC e/o provenienti da mercati non garantiti

2. alle operazioni provenienti da mercati garantiti ed ai conseguenti saldi netti bilaterali

40

Nel primo caso, per effetto della variazione, il liquidatore precedente non troverà più

nell’informativa X-TRM le operazioni soggette a variazione mentre le medesime saranno

disponibili nell’informativa del nuovo liquidatore. Nessun impatto invece sull’informativa

destinata al negoziatore.

Nel secondo caso, per la variazione del soggetto liquidatore in presenza di operazioni

provenienti dai mercati garantiti, si premettono di seguito alcuni schemi riassuntivi delle

casistiche che si verificano in X-TRM a seconda delle modalità di partecipazione dei vari attori

alla liquidazione e alla controparte centrale e che si possono distinguere in:

1. modello ‘A’ o modello di marginazione lordo, valido per il mercato equity (cfr. 6.2.1)

2. modello ‘B’ o modello di marginazione netto, valido per il mercato bonds (cfr. 6.2.2)

Per elementi di maggior dettaglio si prega di fare riferimento al documento contrattuale

“Istruzioni del Servizio X-TRM” pubblicato sul sito web Monte Titoli.

La possibilità di ammettere od escludere variazioni di configurazione ai dati statici relativamente

alla tipologia di adesione alla CCP e alle modalità di partecipazione alla liquidazione del

partecipante alla CCP e/o del negoziatore è strettamente legata non solo alla variazione di

configurazione in senso stretto ma anche alle modalità di calcolo del saldo netto bilaterale.

L’analisi proposta di seguito dettaglia tutti i possibili passaggi da una casistica ad un’altra,

descrivendone lo scenario e le possibili conseguenze ed impatti sui dati dinamici (indicazione

dei dati oggetto di modifica sulle operazioni e sui saldi netti bilaterali) e sui soggetti coinvolti.

Per una più efficace comprensione si consiglia di consultare parallelamente anche il documento

di cui al capitolo 10. (“Variazioni tipologia di adesione alla CCP e cambio liquidatore”).

Si noti che gli scenari descritti ai paragrafi il cui titolo è evidenziato con il colore:

Grigio: descrivono casistiche attualmente presenti nel sistema

Verde: descrivono fattispecie attualmente non presenti nei sistemi Monte Titoli, ovvero

le casistiche 2, 3B e 5B dettagliate nei successivi paragrafi. Si specifica che i suddetti

scenari di variazione vengono riportati per completezza di analisi.

Inoltre, nelle tabelle che seguono, le casistiche contrassegnate con il simbolo:

√: indicano variazioni alla tipologia di adesione alla CCP e/o delle modalità di

partecipazione alla liquidazione del partecipante alla CCP e/o del negoziatore

considerate ammissibili

41

indicano variazioni ammissibili con variazione del soggetto emittente (codice

CED) dell’ operazione

X : indicano variazioni non ammissibili.

Monte Titoli ammette la variazione del Partecipante Generale (GCM) e/o del soggetto

liquidatore, purché ciò non comporti la creazione ex-novo o l’eliminazione di un’operazione X-

TRM al momento della migrazione.

Inoltre, non sono ammesse variazioni che, direttamente o indirettamente, prevedono il

cambiamento della controparte centrale coinvolta nella transazione (da LCH SA a CC&G e

viceversa).

Per entrambi i modelli operativi («Modello di marginazione lordo - A» e «Modello di

marginazione netto - B») ogni singolo soggetto ha la visibilità delle operazioni a seconda dello

specifico ruolo che ricopre e del tipo di abilitazione assegnata dal soggetto negoziatore.

√

42

6.2.1 Modello operativo “A” o Modello di marginazione lordo

Di seguito viene fornito uno scherma riassuntivo dei vari casi presenti nel modello operativo A:

Il seguente schema riporta, a titolo di esempio, un’istanza per ciascun caso indicando il

soggetto in capo al quale si costruisce il saldo bilaterale.

La seguente tabella riassume i differenti scenari di passaggio da un caso all’altro fra quelli sopra

descritti. Il passaggio da un caso all’altro è rappresentato di volta in volta da un cambio di

liquidatore e/o un cambio di partecipazione alla Controparte Centrale.

43

Nel modello di marginazione lorda (Modello A) il soggetto obbligato nei confronti della

controparte centrale è il GCM o ICM (a parte il caso 2) quindi il saldo netto bilaterale creato è

relativo alle posizioni del soggetto negoziatore nei confronti della controparte centrale.

Ne consegue che in tutti i casi di variazione ammessa il soggetto che ricopre il ruolo di

negoziatore non avrà alcun impatto sull’informativa X-TRM.

Passaggio dalla casistica 1 alla casistica 3

SCENARIO

Il negoziatore passa da diretto ad indiretto alla liquidazione

Il negoziatore non è più partecipante diretto alla CCP ma si avvale di un aderente

generale

CONSEGUENZE

Il soggetto negoziatore, sia in qualità di liquidatore “uscente” e di aderente individuale,

non ha più visibilità delle proprie operazioni

Il soggetto liquidatore/GCM “entrante” (del negoziatore) ha visibilità delle operazioni del

soggetto negoziatore che prima aderiva direttamente alla liquidazione

I seguenti dati sono oggetto di modifica sull’ operazione:

o soggetto liquidatore

o aderente generale

o conto di regolamento

I seguenti dati sono oggetto di modifica sul SNB:

o liquidatore



SCENARIO

Caso 1 Caso 2 Caso 3 Caso 4 Caso 5

Caso 1 n.a. √ √ √Caso 2

Caso 3 √ √ √ √

Caso 4 √ √ √ √

Caso 5 √ √ √ √

44

Il negoziatore passa da indiretto a diretto alla liquidazione

Il negoziatore passa da una modalità di adesione indiretta alla CCP a diretta

CONSEGUENZE

Il soggetto liquidatore “uscente”, in qualità anche di GCM, non ha più la visibilità delle

operazioni del soggetto negoziatore

il soggetto liquidatore “entrante”, che è anche negoziatore ed aderente individuale,

divenendo diretto ha piena visibilità di tutte le proprie operazioni a prescindere dal

ruolo



o aderente generale


o codice del soggetto intestatario del SNB


o liquidatore



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





o liquidatore



45

SCENARIO

Il negoziatore passa da indiretto alla liquidazione a diretto


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





o Liquidatore



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


proprie operazioni

Il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto


L’aderente generale ha piena visibilità delle operazioni del negoziatore, a causa dell’

adesione indiretta alla CCP



o aderente generale



o liquidatore


46


SCENARIO

Il negoziatore passa da indiretto a diretto alla liquidazione

Il negoziatore passa da un’adesione indiretta alla CCP ad un’adesione diretta

CONSEGUENZE


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.



o aderente generale



o liquidatore



SCENARIO COMBINATO

SCENARIO 1

Il soggetto negoziatore passa da un’adesione indiretta alla CCP ad un’adesione diretta ma

mantiene il medesimo soggetto liquidatore.

SCENARIO 2

Il soggetto negoziatore passa da un’adesione indiretta alla CCP ad un’adesione diretta e

cambia il soggetto liquidatore.

CONSEGUENZE

SCENARIO 1

L’ aderente generale “uscente” perde la visibilità dei saldi del negoziatore

Il negoziatore acquisisce la visibilità dei proprio saldi anche in qualità di ICM

47

Il soggetto liquidatore continua ad avere la stessa visibilità sulle operazioni del

negoziatore rispetto alla situazione pre-variazione poiché il soggetto liquidatore rimane

il medesimo.

Solo il campo relativo all’aderente generale è oggetto di modifica sull’ operazione

SCENARIO 2

Il negoziatore acquisisce visibilità dei proprio saldi anche in qualità di ICM

L’ aderente generale “uscente” perde la visibilità delle operazioni del negoziatore anche

nel suo ruolo di liquidatore “uscente”


negoziatore anche nel ruolo di soggetto liquidatore dell’ aderente individuale.



o aderente generale


I seguenti dati sono oggetto di modifica sul SNB




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 medesimo.

Solo il dato relativo all’aderente generale è oggetto di modifica sull’ operazione


SCENARIO COMBINATO

SCENARIO 1

Il negoziatore mantiene il medesimo soggetto liquidatore cambiando il GCM (il soggetto

liquidatore del negoziatore deve coincidere con il soggetto liquidatore del GCM)

48

SCENARIO 2

Il negoziatore cambia GCM e contestualmente cambia anche il soggetto liquidatore. Si noti che

il soggetto liquidatore del negoziatore deve coincidere con il soggetto liquidatore del GCM.

CONSEGUENZE

SCENARIO 1

Il soggetto GCM “uscente” perde la visibilità delle operazioni del soggetto negoziatore

ma la mantiene in qualità di liquidatore

Il GCM “entrante” acquisisce la visibilità dei saldi del soggetto negoziatore

Solo il campo relativo all’aderente generale è oggetto di modifica sull’ operazione

SCENARIO 2

Il soggetto liquidatore e GCM “uscente” perde la visibilità delle operazioni del soggetto

negoziatore

Il liquidatore e GCM “entrante” acquisisce la visibilità delle operazioni del soggetto

negoziatore



o aderente generale






SCENARIO

Il negoziatore cambia il GCM utilizzando il proprio soggetto liquidatore

CONSEGUENZE





il medesimo.


49

Passaggio dalla casistica 4 alla casistica 5 SCENARIO COMBINATO

SCENARIO 1

Il soggetto negoziatore passa da diretto ad indiretto alla CCP

Il soggetto negoziatore non cambia il suo soggetto liquidatore in quanto già risulta

essere il liquidatore del nuovo GCM

SCENARIO 2


Il soggetto negoziatore 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 medesimo.


SCENARIO 2


negoziatore


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.



o aderente generale



o liquidatore


50


SCENARIO

Il negoziatore passa da un’adesione indiretta alla CCP ad una partecipazione diretta

Il negoziatore cambia il soggetto liquidatore

CONSEGUENZE


negoziatore


negoziatore


il negoziatore, nel ruolo di ICM “entrante” ha la visibilità dei proprio saldi



o aderente generale



o liquidatore



SCENARIO

Cambia il soggetto liquidatore che è anche aderente generale

CONSEGUENZE


negoziatore


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).



o aderente generale



51




SCENARIO

Cambia il soggetto liquidatore ma non le modalità di partecipazione alla CCP (diretta)

CONSEGUENZE

Il soggetto liquidatore “uscente” perde la visibilità delle operazioni del soggetto

negoziatore

il soggetto liquidatore “entrante” ha piena visibilità delle operazioni del soggetto

negoziatore








SCENARIO COMBINATO

SCENARIO 1

Cambia l’aderente generale ma non è prevista alcuna variazione del soggetto liquidatore

(dell’aderente generale e del liquidatore del soggetto negoziatore), in quanto il liquidatore del

nuovo GCM è lo stesso del precedente GCM.

SCENARIO 2

Cambia l’ aderente generale. Inoltre è prevista una variazione del soggetto liquidatore del

negoziatore che deve utilizzare il liquidatore del nuovo aderente generale.

CONSEGUENZE

SCENARIO 1

Il “nuovo” GCM ha visibilità delle operazioni del negoziatore, essendo il nuovo soggetto

chiamato ad interporsi con la CCP

Il “vecchio” GCM non ha più la visibilità delle operazioni del negoziatore

52

Il soggetto liquidatore dell’ aderente generale e del negoziatore continua a mantenere la

visibilità delle operazioni in essere rispetto alla situazione pre-variazione poiché il

soggetto liquidatore rimane il medesimo


SCENARIO 2

Il “vecchio” soggetto liquidatore del GCM e del negoziatore non ha più la visibilità delle


Il “nuovo” soggetto liquidatore del GCM e del negoziatore ha più piena visibilità delle


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.



o aderente generale





53

6.2.2 Modello operativo “B” o Modello di marginazione netto

Di seguito viene fornito uno scherma riassuntivo dei vari casi presenti nel modello operativo B o

modello di marginazione netto:

La seguente tabella riassume i differenti scenari di passaggio da un caso all’altro fra quelli sopra

descritti. Il passaggio da un caso all’altro è rappresentato di volta in volta da un cambio di

liquidatore e/o un cambio di partecipazione alla Controparte Centrale.

Il seguente schema riporta, a titolo di esempio, un’istanza per ciascun caso indicando il

soggetto in capo al quale si costruisce il saldo bilaterale.

54

Passaggio dalla casistica 1 alla casistica 3A

SCENARIO

il negoziatore passa da diretto ad indiretto alla liquidazione

Il negoziatore non è più diretto alla CCP (aderente individuale) ma si avvale di un

aderente generale (conto del negoziatore uguale al conto del GCM)

CONSEGUENZE

Il soggetto negoziatore, sia in qualità di liquidatore “uscente” che di aderente

individuale, non ha più visibilità delle proprie operazioni, che non vede più né come

emittente né come controparte

Il soggetto liquidatore/GCM “entrante” ha visibilità delle operazioni del soggetto


I seguenti campi sono oggetto di modifica sull’ operazione:


o aderente generale



I seguenti campi sono oggetto di modifica sul SNB:

o emittente

o tipo negoziazione (in alcuni casi)

o liquidatore


Passaggio dalla casistica 3A alla casistica 1

SCENARIO

55

Il negoziatore passa da una partecipazione indiretta alla liquidazione a diretta

Il negoziatore passa da un’ adesione indiretta alla CCP a diretta

CONSEGUENZE

Il soggetto liquidatore “uscente”, anche in qualità di GCM, non ha più la visibilità delle


Il soggetto liquidatore “entrante” , che è anche negoziatore e ICM , ha piena visibilità di

tutte le proprie operazioni a prescindere dal ruolo



o aderente generale




o emittente


o liquidatore



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





o liquidatore


56


SCENARIO



CONSEGUENZE

Il soggetto liquidatore “entrante” , che è anche negoziatore ed aderente individuale, ha

piena visibilità di tutte le operazioni a prescindere dal ruolo


negoziatore





o liquidatore



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


proprie operazioni



L’aderente generale ha piena visibilità dei saldi bilaterali creati a suo nome



o aderente generale




o liquidatore

57


o emittente



SCENARIO


Il negoziatore passa da un’adesione indiretta alla CCP ad un’adesione diretta

CONSEGUENZE


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



o aderente generale



o liquidatore


o emittente


Passaggio dalla casistica 2 alla casistica 3B

SCENARIO COMBINATO

SCENARIO 1

Il negoziatore passa da diretto alla liquidazione ad indiretto mantenendo lo stesso GCM. Il

liquidatore deve utilizzare due conti diversi per il soggetto negoziatore e per il GCM.

SCENARIO 2

58

Il negoziatore passa da diretto ad indiretto alla liquidazione e contestualmente cambia

l'aderente generale. Il liquidatore deve utilizzare due conti diversi per il soggetto negoziatore e

per il GCM.

CONSEGUENZE

SCENARIO 1

Il soggetto negoziatore continua a vedere le proprie operazioni ma non più nel ruolo di

liquidatore “uscente”

Il soggetto liquidatore “entrante” del negoziatore ha piena visibilità delle operazioni del

soggetto negoziatore che peraltro già vedeva in qualità di GCM

I seguenti campi sono oggetto di modifica sull’ operazione:



I seguenti dati sono oggetto di modifica sul SNB (operazione tra negoziatore e suo

aderente generale):

o liquidatore


I seguenti dati sono oggetto di modifica sul SNB (operazione tra aderente generale e

CCP):


SCENARIO 2

Il soggetto negoziatore continua a vedere le proprie operazioni ma non più nel ruolo di


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




o aderente generale


aderente generale):

o liquidatore


o emittente

o la controparte


CCP):

59

o emittente

o liquidatore


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


o aderente generale



o codice soggetto intestatario del SNB


aderente generale):

o liquidatore


o la controparte


CCP):

o emittente

o liquidatore


60

SCENARIO 2

Il soggetto liquidatore “uscente” del negoziatore non ha più la visibilità delle operazioni

del soggetto negoziatore

Il negoziatore, nel ruolo di soggetto liquidatore “entrante” ha piena visibilità delle

proprie operazioni

I' aderente generale, che coincide con il soggetto liquidatore del GCM, continua ad

avere la medesima visibilità delle operazioni del negoziatore





aderente generale):

o liquidatore


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


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


nuovo soggetto chiamato ad interporsi con la CCP


o aderente generale





aderente generale):

o liquidatore


o controparte

61


CCP):

o emittente


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.


o aderente generale





aderente generale):

o liquidatore


o controparte


CCP):

o emittente



SCENARIO COMBINATO

SCENARIO 1


mantenendo come liquidatore quello del precedente GCM

SCENARIO 2

62

Il negoziatore passa da un’adesione indiretta alla CCP ad una partecipazione diretta e

contestualmente si avvale di un nuovo liquidatore

CONSEGUENZE

SCENARIO 1

Il negoziatore acquisisce visibilità dei propri saldi in qualità di ICM

Il GCM “uscente” perde visibilità dei saldi del negoziatore ma ne mantiene la visibilità in

qualità di liquidatore



il medesimo.

I seguenti dati sono oggetto di modifica sull' operazione

o aderente generale



CCP):

o emittente


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


Il “nuovo” soggetto liquidatore del negoziatore, che è ICM, ha piena visibilità delle

operazioni



o aderente generale




CCP):

o emittente


o liquidatore


63


SCENARIO

Il negoziatore passa da un’adesione diretta alla CCP ad una partecipazione indiretta

alla CCP.

CONSEGUENZE





il medesimo.


o aderente generale




CCP):

o emittente


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


o aderente generale

64


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



o aderente generale




CCP):

o emittente

o liquidatore



SCENARIO

Il negoziatore cambia il GCM utilizzando il proprio soggetto liquidatore

CONSEGUENZE





il medesimo.

I seguenti dati sono oggetto di modifica sull’ operazione

o aderente generale



CCP):

o Emittente

Passaggio dalla casistica 3B alla casistica 5B

SCENARIO COMBINATO

SCENARIO 1

65

Il negoziatore cambia GCM mantenendo lo stesso liquidatore che utilizza due conti distinti per il

negoziatore ed il GCM

SCENARIO 2

Il negoziatore cambia GCM e contestualmente cambia anche il soggetto liquidatore che utilizza

due conti distinti per il negoziatore ed il GCM

CONSEGUENZE

SCENARIO 1

Il soggetto liquidatore del negoziatore mantiene la visibilità delle operazioni del soggetto

negoziatore ma la perde in qualità di GCM “uscente”



o aderente generale


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




o aderente generale




aderente generale):

o liquidatore


o controparte


CCP):

o emittente

o liquidatore

66



SCENARIO

Il negoziatore cambia il GCM utilizzando il proprio soggetto liquidatore utilizzando due

conti distinti

CONSEGUENZE





il medesimo.


o aderente generale


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)


SCENARIO COMBINATO

SCENARIO 1


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 medesimo.


67

o aderente generale



o emittente


SCENARIO 2


negoziatore


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.



o aderente generale


o codice del soggetto emittente del SNB


o emittente


o liquidatore



SCENARIO COMBINATO

SCENARIO 1

Il negoziatore cambia il soggetto liquidatore


SCENARIO 2


CONSEGUENZE

SCENARIO 1


negoziatore

68


negoziatore


Il negoziatore, nel ruolo di ICM “entrante” ha la visibilità dei proprio saldi



o aderente generale




o emittente


o liquidatore


SCENARIO 2



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


o aderente generale



o emittente



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


o aderente generale

69



aderente generale):

o liquidatore


o controparte


CCP):

o emittente

o liquidatore



SCENARIO

Il negoziatore cambia il soggetto liquidatore e aderente generale tra loro coincidenti

CONSEGUENZE


negoziatore



essendovi coincidenza tra il soggetto liquidatore e l’aderente generale, la view del GCM




o aderente generale




o emittente

o liquidatore



SCENARIO

Il negoziatore cambia il soggetto liquidatore che è anche aderente generale. Il

liquidatore utilizza conti diversi

70

CONSEGUENZE


negoziatore



Essendovi coincidenza tra il soggetto liquidatore e l’aderente generale, la view del GCM




o aderente generale




aderente generale):

o liquidatore


o controparte


CCP):

o emittente

o liquidatore



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


negoziatore

Seguenti dati sono oggetto di modifica sull’ operazione:




o liquidatore

71



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


Il “vecchio” aderente generale non ha più la visibilità delle operazioni del negoziatore





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


Il “nuovo” soggetto liquidatore del negoziatore e dell’aderente generale ha piena



nuovo soggetto chiamato ad interporsi con la CCP.




o aderente generale




o emittente

72

o liquidatore



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 “vecchio” aderente generale non ha più la visibilità delle operazioni del negoziatore






aderente generale):

o controparte



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


Il “nuovo” soggetto liquidatore del negoziatore e dell’aderente generale ha piena





73



o aderente generale




aderente generale):

o liquidatore


o controparte


CCP):

o emittente

o liquidatore


74

7 T2S USER TESTING & MIGRATION TESTING

7.1 Introduzione

L’obiettivo del presente capitolo è fornire una panoramica generale delle differenti fasi dello

User Testing e Migration Testing che implicano, direttamente od indirettamente, il

coinvolgimento dei clienti, siano essi partecipanti Directly Connected Participant (DCP) o

Indirectly Connected Participant (ICP).

7.2 User Testing: attori coinvolti

Le seguenti tabelle propongono un elenco degli attori coinvolti nella preparazione ed

esecuzione della fase di User Testing con specifica indicazione delle responsabilità in capo ad

ognuno.

SOGGETTO RESPONSABILITA’

Eurosistema Gestione della preparazione della fase di User Testing

Coordinamento e supporto all’esecuzione dello User Testing

CSD

Banche Centrali

Partecipazione alla preparazione della fase di User Testing

Partecipazione attiva all’esecuzione delle varie fasi di test

Coordinamento delle attività di testing (preparazione ed esecuzione)

con le rispettive Community

CSD Participant

Payment Bank

Partecipazione attiva all’esecuzione delle fasi di test relative al

Community ed al Business Day

75

7.3 User Testing

Lo User Testing di T2S prevede l’ esecuzione di cinque differenti fasi di collaudo.

Con riferimento alle fasi di testing sintetizzate sopra, si noti che la partecipazione diretta dei

clienti è prevista a partire dalla fase di Community.

Durante il Community ed il Business Day testing i clienti sono chiamati ad eseguire i collaudi

secondo quanto indicato nel Piano delle Prove.

76

In particolare, durante la fase di Business Day testing, i clienti sono tenuti a partecipare alle

prove generali di Migration Weekend e, per i tre giorni successivi, ad operare in ambiente di

collaudo come se stessero operando direttamente in produzione.

I nuovi ambienti di collaudo che Monte Titoli mette a disposizione per l’esecuzione dei test e per

le fasi di passaggio in produzione dei dati statici con il relativo timing sono sinteticamente

illustrati di seguito:

Ambiente

legacy MT

Ambiente

T2S Note

Disponibile

da

Disponibile

fino a

T2 Interoperability Utilizzato solo da Monte Titoli. 11/06/2015

T2 Pre-Prod.

Messo a disposizione dei

clienti da Monte Titoli come

nuovo ambiente di pre

produzione in sostituzione di

PI.

12/06/2015 Data aperta

T1 Community

Utilizzato da Monte Titoli e dai

clienti per i collaudi di

connettività e funzionali

durante le fasi di Community e

Business day testing.

05/01/2015 11/06/2015

T1 Produzione

Utilizzato da Monte Titoli e dai

clienti per il passaggio in

produzione a T2S (Migration

Week End) e le successive

attività BAU.

12/06/2015 Data aperta

T3 n.a.

Utilizzato per la sola gestione

dei dati statici di produzione

tramite piattaforma web.

Accessibile solo via internet.

15/12/2014 20/03/2015

T3 Produzione

Connesso all’ambiente di

produzione di T2S per

consentire la migrazione dei

dati statici.

21/03/2015 11/06/2015

77

7.4 Migration Testing

Il Migration Testing si suddivide nelle medesime fasi in cui è suddiviso lo User Testing. I clienti

non sono direttamente coinvolti nella fase di Bilateral e Multilateral migration testing.

L’ obiettivo della fase di Migration Testing è quello di assicurare che i CSD e le CB coinvolte

nella prima finestra di migrazione a T2S e le rispettive comunità finanziarie siano effettivamente

pronti a migrare i propri sistemi legacy alla nuova piattaforma T2S, rispettando le deadline e i

synchonisation point definiti a livello comunitario ed in maniera bilaterale tra Monte Titoli ed i

propri clienti.

Durante la fase di migration testing i differenti soggetti coinvolti, coerentemente col proprio ruolo

ricoperto, sono chiamati a:

Verificare che gli strumenti, query e report aggiuntivi richiesti per la fase di migrazione a

T2S siano adeguati a supportare la migrazione a T2S;

Eseguire il caricamento dell’intero set di dati relativi alle attività di pre migrazione e di

migrazione con l’obiettivo di assicurarsi che i dati stessi siano conformi agli standard di

T2S;

Verificare i dati già migrati alla nuova piattaforma attraverso reports di riconciliazione;

Verificare che la sequenza di attività da eseguire sia durante la fase di pre migrazione

che di migrazione in senso stretto sia adeguata e correttamente compresa da tutti gli

attori coinvolti;

Verificare che le attività programmate possano essere eseguite nel rispetto della

schedulazione definita, soprattutto durante il weekend di migrazione a T2S;

Verificare l’adeguatezza dei processi e delle procedure di contingency.

Per maggiori dettagli si invita a far riferimento alla documentazione di seguito riportata:

Dedicated Info Session "T2S User Testing and Migration: an urgent matter“

http://www.ecb.europa.eu/paym/t2s/governance/sessions/html/mtg21.en.html

T2S Programme Plan – Project Phases – User Testing


T2S Programme Plan – Project Phases – Migration weekends

http://www.ecb.europa.eu/paym/t2s/progplan/html/index.en.html#week

http://www.ecb.europa.eu/paym/t2s/governance/sessions/html/mtg21.en.html


http://www.ecb.europa.eu/paym/t2s/progplan/html/index.en.html#week

78

8 GESTIONE DEGLI ACCESS RIGHT IN T2S (solo per DCP)

Prima di addentrarci nella spiegazione tecnica delle modalità e delle logiche alla base del

processo di assegnazione e gestione dei diritti di accesso a T2S è bene specificare che,

qualora il cliente decida di adottare una connessione diretta alla piattaforma T2S, è chiamato a

gestire un processo preparatorio ad hoc relativo all’assegnazione degli access right in T2S.

Quest’ultimo consta in una serie di azioni di seguito sintetizzate e riportate nella tabella di cui al

4.1: Piano delle attività e Synchronisation Point di premigrazione:

1. Il cliente DCP è tenuto a richiedere a Monte Titoli la configurazione e predisposizione di

un utente amministratore. Sarà quest’ultimo, in quanto utente al quale i privilegi sono

concessi in prima istanza, a riassegnarli internamente ad altri soggetti.

In maniera speculare, il cliente DCP dovrà chiedere anche alla Banca Centrale di

riferimento l’assegnazione di un utente amministratore per la gestione di tutti i diritti di

accesso relativi a quanto di competenza della Banche Centrali Nazionali;

2. I DCP sono chiamati ad eseguire il processo di registrazione presso i Network Service

Provider. Infatti, ogni partecipante DCP che partecipa ad una particolare finestra di

migrazione deve completare l’apposita registrazione presso i NSP attraverso i rispettivi

CSD/CB per l’ambiente di produzione;

3. I clienti DCP dovranno provvedere a richiedere specifici certificati/token per l’accesso al

sistema T2S secondo criteri e regole dettate dal NSP scelto dal cliente.

8.1 Introduzione alla gestione dei diritti di accesso a T2S

La gestione del processo di assegnazione degli access rights in T2S segue la struttura

gerarchica del modello delle Party dettato dalla nuova piattaforma T2S.

Si prega di notare che il seguente paragrafo è di interesse esclusivo dei clienti DCP.

Infatti i clienti che optano per una connessione indiretta (ICP) alla piattaforma T2S

attraverso Monte Titoli non sono tenuti ad effettuare alcuna attività relativa alla gestione dei

diritti di accesso alla piattaforma T2S.

Alla luce di quanto detto, i clienti ICP possono considerare il contenuto del presente

paragrafo a scopo meramente illustrativo e conoscitivo.

79

Infatti, la struttura delle Party in T2S si sviluppa secondo una struttura gerarchica articolata su

tre diversi livelli, ove è possibile distinguere:

Party di I livello, ovvero il T2S Operator posto al vertice della struttura gerarchica;

Party di II livello, ovvero il CSD e la CB;

Party di III livello, ovvero i clienti del CSD (CSD participant) ed i clienti delle CB

(Payment Bank).

Il processo di assegnazione di ruoli e privilegi segue la struttura gerarchica descritta nello

schema di cui sopra, in base al quale ogni soggetto è responsabile dell’ assegnazione di ruoli e

privilegi agli utenti facenti parte delle categorie poste ad un livello sottostante della struttura

gerarchica.

Alla luce di quando detto, il T2S Operator è direttamente responsabile dell’ assegnazione di

ruoli e privilegi ai CSD e CB che, conseguentemente, provvederanno ad assegnare i relativi

ruoli e privilegi ai CSD Participant e Payment Bank.

8.2 Concetti e definizioni principali

Al fine di agevolare la comprensione dei meccanismi alla base dell’ assegnazione di ruoli e

privilegi, si fornisce di seguito una lista dei principali concetti e definizioni alla base della

gestione degli access rights in T2S.

8.2.1 User Function

I messaggi XML e le funzionalità della GUI rappresentano le modalità attraverso le quali un

utente può interagire con T2S, rispettivamente in modalità A2A e U2A.

80

Sulla base del set di messaggi XML e delle funzionalità offerte dalla GUI, è possibile definire il

set di «T2S user function» per gli utenti (ad esempio l’ invio di una istruzione di regolamento,

creazione di una Party, etc), sia in modalità A2A che U2A.

8.2.2 Privilegi

Un privilegio identifica la capacità di innescare le differenti «T2S user functions» e rappresenta

l’elemento basilare per l’assegnazione dei diritti di accesso agli utenti. A seconda del loro

ambito di applicazione, i privilegi possono essere distinti in:

Privilegi di sistema: si riferiscono a «T2S user function» non applicabili a specifici dati

statici o dinamici (esempio: una query per la valutazione dello status attuale della fase

del settlement day);

Privilegi oggetto: si riferiscono a «T2S user function» applicabili a specifici dati statici o

dinamici (esempio: una funzionalità che mostra specifiche informazioni di un securities

account).

I privilegi di sistema vengono assegnati secondo un approccio top-down, come si evince dalla

rappresentazione grafica di cui di seguito:

I privilegi oggetto, a differenza della precedente categoria, vengono assegnati secondo un

approccio top down e/o trasversale:

81

8.2.3 Secured Object

Un “secured object” è un dato statico (party, titoli, securities account e T2S DCA) sul quale

viene concesso un specifico privilegio-oggetto.

8.2.4 Secured Group

Un «secured group» è un insieme omogeneo di «secured objects» (ad esempio, un gruppo di

party o di securities account).

8.2.5 Ruolo

Un ruolo può essere definito come un insieme di privilegi.

8.2.6 User

Un utente è un soggetto o un’applicazione che interagisce con T2S attraverso le «T2S user

function» disponibili.

8.2.7 Data Scope

Alla luce della struttura gerarchica definita da T2S e descritta nella sezione introduttiva del

seguente documento T2S definisce, per ogni singolo privilegio, il cosiddetto default data scope,

ovvero l’ ambito predefinito di dati statici o dinamici ove il singolo utente può abilitare le funzioni

di T2S. In particolare:

Gli utenti del T2S Operator hanno visibilità sulla totalità di dati statici e dinamici e

possono agire sui diversi oggetti statici e dinamici dei loro partecipanti solo in

circostanze eccezionali e sulla base di specifici accordi con gli stessi;

c

82

Gli utenti del CSD e delle CB hanno visibilità sulla totalità di dati statici e dinamici

appartenenti alla medesima entità legale;

Gli utenti del CSD participant e le Payment Bank hanno visibilità sull’ insieme di dati

statici e dinamici che risultano essere, direttamente ed indirettamente, legate alla

medesima Party.

Dal grafico proposto di seguito si evince come gli utenti X, Y e Z (posti ad un differente livello

gerarchico del modello di Party in T2S) rientrino in un diverso default data scope. In particolare:

L’ utente X, essendo un soggetto partecipante del CSD Part.B, acquisisce di default il

data scope del CSD Part.B. Si noti che il data scope include anche il SAC2 in quanto

unico conto titoli del CSD Part.B. Utente X non può inviare istruzioni di regolamento

riferite ad altri conti titoli in T2S;

L’utente Y del CSD1 acquisisce di default il data scope circostanziato nell’ area blu che

include anche i conti titoli SAC1 e SAC2 poiché i suddetti conti titoli appartengono al

CSD participant (quindi CSD Part.A e CSD Part.B) del CSD1.

L’utente Y non può inviare istruzioni di regolamento riferite ad altri conti titoli in T2S che

non facciano parte del suddetto data scope (cfr. area blu del grafico);

L’utente Z del T2S Operator, essendo al primo livello della struttura gerarchica del

modello delle Party in T2S, acquisisce di default un data scope (area verde) che include

tutti i conti titoli in essere in T2S.

Il default data scope può essere esteso o ridotto a seconda delle specifiche esigenze di

business.

83

I due successivi paragrafi propongono due esempi rispettivamente di estensione e riduzione del

default data scope.

ESTENSIONE DEL DEFAULT DATA SCOPE

Il seguente grafico mostra come l’ utente X, ovvero il soggetto cliente del CSD Part.B,

acquisisce il data scope di default del CSD Part.B, inclusi tutti i conti titoli facenti parte della

suddetta area (in questo caso il SAC2). A causa dell’ estensione del data scope, lo stesso

utente X vede estendere l’ambito predefinito di dati statici o dinamici anche al conto titoli 5

(SAC5).

RIDUZIONE DEL DEFAULT DATA SCOPE

Il seguente grafico mostra come l’ utente X, ovvero il soggetto cliente del CSD Part.D,

acquisisce il data scope di default del CSD Part.D, inclusi tutti i conti titoli facenti parte della

suddetta area (in questo caso il SAC4 e SAC5). A causa della riduzione del data scope, lo

stesso utente X vede ridurre l’ambito predefinito di dati statici o dinamici al solo conto titoli 4

(SAC5) e perde la visibilità sul conto titoli 5 (SAC5).

84

8.3 Configurazione degli access rights in T2S

Si propone di seguito una breve descrizione dei principi alla base dell’ assegnazione di ruoli e

privilegi ai diversi T2S Actors.

8.3.1 Configurazione utenti

LINK TRA UTENTI E PARTY

Ogni nuovo utente è direttamente collegato alla relativa Party. Infatti, attraverso il collegamento

diretto con la Party interessata, ciascun utente eredita il default data scope della Party a cui è

associato.

Tuttavia, vi sono delle specifiche situazioni che costituiscono eccezione alla regola generale

precedentemente descritta, ad esempio:

Il “T2S Administrator” crea un nuovo soggetto amministratore di un CSD e di una CB;

Il soggetto amministratore di un CSD crea un nuovo soggetto amministratore per uno

dei suoi partecipanti;

Il soggetto amministratore di una CB crea un nuovo soggetto amministratore per una

sua payment bank.

Si specifica che il legame tra un utente e la propria Party non può essere oggetto di modifica.

PARTY ADMINISTRATOR

85

Ogni Party deve avere almeno un “Party administrator”, ovvero un utente al quale i privilegi

sono concessi con la possibilità, a sua volta, di riassegnarli ad utenti e soggetti nell’ ambito del

proprio default data scope.

8.3.2 Configurazione privilegi

Ogni privilegio, successivamente alla sua prima creazione, è disponibile solo ed esclusivamente

al soggetto amministratore del T2S Operator. Ciò implica che i soggetti amministratori di tutte le

altre Party diversi dal T2S Operator non possono, a loro volta, concedere tali privilegi ai propri

utenti.

Un privilegio diventa disponibile a soggetti amministratori diversi dall’ amministratore del T2S

Operator solo dopo che lo stesso privilegio è stato concesso alla relativa Party di riferimento.

Da questo momento in poi, ogni singolo amministratore di una Party può concedere, a sua

volta, i relativi privilegi.

Alla luce di ciò, il processo di articola in due fasi:

1. STEP 1: privilegio concesso dal T2S Operator al CSD e CB. Dunque lo stesso risulta

essere disponibile solo al soggetto amministratore del CSD/CB

2. STEP 2: privilegio concesso dal soggetto amministratore di un CSD/CB ai propri utenti

(CSD/CB vs CSD participant/CB)

8.3.3 Configurazione ruoli

I ruoli possono essere assegnati ad altri ruoli, utenti e partecipanti.

Si noti che il processo di assegnazione dei ruoli in T2S (supportato dal modello gerarchico

RBAC1 descritto nel documento degli UDFS di T2S) è strettamente legato al concetto stesso di

privilegio. Infatti:

Nel momento in cui si concede un ruolo ad un utente, il soggetto in questione eredita

tutti i privilegi assegnati a quello specifico ruolo;

Nel momento in cui si concede un ruolo ad una Party , la stessa eredita tutti i privilegi

assegnati a quello specifico ruolo.

1 RBAC: Role Based Access Controls (Ferraiolo, D.F., and Kuhn, D.R.1992)

86

Seguendo il medesimo processo logico di assegnazione di uno specifico ruolo, lo stesso può

essere rimosso da altri ruoli, utenti e party.

Infatti, specularmente rispetto a quanto descritto in precedenza, nel momento in cui un ruolo

associato ad un utente o Party viene rimosso, lo stesso perde, conseguentemente, tutti i

privilegi ad esso associati.

8.4 Processo di assegnazione degli access rights in T2S

Affinché un party administrator possa assegnare privilegi agli utenti facenti parte della

medesima party, gli stessi devono essere stati preventivamente assegnati alla party stessa.

Alla luce di quanto detto, il seguente schema illustra gli step necessari per l’assegnazione del

privilegio P agli utenti del CSD o della CB (ovvero Party A).

In particolare, come si evince dal grafico di cui sopra:

1. L’utente X, essendo un Party administrator del T2S Operator, ha la facoltà di concedere

il privilegio P alla Party A;

2. L ‘utente Y, essendo Party administrator del Party A ha, a sua volta, la facoltà di

concedere il privilegio P a tutti gli user facenti parte del medesimo livello gerarchico

(ovvero User Y1 ed User Y2).

87

Il medesimo processo logico si applica ogni qual volta un CSD o una CB proceda con

l’assegnazione dei rispettivi ruoli e privilegi ai propri partecipanti, ovvero ai CSD participant e

Payment Bank.

Il seguente grafico illustra gli step per l’assegnazione del privilegio P dal CSD ai CSD participant

e dalla CB alle Payment Bank:

Il grafico evidenzia i tre differenti step da seguire per l’assegnazione del privilegio P:

1. L’utente X, essendo un Party administrator del T2S Operator, ha la facoltà di concedere

il privilegio P alla Party A (ovvero al CSD o CB);

2. L ‘utente Y, essendo Party administrator del Party A ha, a sua volta, la facoltà di

concedere il privilegio P alla Party B (ovvero CSD participant o Payment Bank)

3. L’utente Z, essendo Party administrator del Party B, ha la facoltà di assegnare il

privilegio P ai suoi utenti (nell’ esempio di cui sopra Z1 e Z2).

Inoltre si noti che l’utente Y1, in quanto party administrator della Party A, può a sua volta

assegnare il privilegio P agli utenti Y1, purchè siano soggetti facenti parte capo al medesimo

Party.

Alla luce di quanto detto, si noti che il processo di configurazione degli access rights in T2S può

innescarsi a livello di Party o a livello di singolo utente.

8.4.1 Access rights a livello di Party

Per ciò che concerne la configurazione degli access rights a livello di Party, si noti che il

soggetto amministratore del T2S Operator è colui in capo al quale spetta l’ onere di assegnare il

set predefinito di ruoli e privilegi al CSD e della CB.

Il seguente grafico ne propone un esempio:

88

Successivamente, i soggetti Party administrator di ogni CSD e CB hanno, conseguentemente,

la possibilità di assegnare un set predefinito di ruoli e privilegi a tutti i propri partecipanti, siano

essi CSD Participant o Payment Bank.

89

8.4.2 Access rights a livello di utenti

Successivamente la configurazione degli access rights a livello di Party, ogni singolo party

administrator può, a sua volta, concedere access rights ai singoli user, assegnando gli

appropriati ruoli e privilegi a tutti gli utenti che fanno capo al medesimo Party.

8.5 Gestione decentralizzata degli access rights in T2S

Come precedentemente descritto, la gestione degli access rights in T2S riflette in toto il modello

della relazione esistente tra le party in T2S, sviluppato ed articolato su tre differenti livelli

gerarchici.

Si propone di seguito uno schema che sintetizza le principali attività in capo al T2S Operator,

CSD/CB e CSD Participant/PB relativamente alla gestione degli access rights, in linea con la

struttura gerarchica e decentralizzata delle Party in T2S.

90

Per maggiori dettagli informativi si faccia riferimento alla documentazione resa pubblica dalla

ECB a seguito di un workshop tenutosi lo scorso luglio 2012 a Francoforte sul tema degli

access rights:http://www.ecb.europa.eu/paym/t2s/governance/extmtg/html/mtg43.en.html

Per informazioni di ulteriore dettaglio vi invito a consultare la documentazione tecnica resa

disponibile dalla ECB nell’ apposita sezione documentale. In particolare:

T2S User Detailed Functional Specifications (UDFS):

http://www.ecb.europa.eu/paym/t2s/pdf/UDFS_v1_2_1.pdf?02dbde3be45b2d0bf5a5afcf4de

34f36

T2S User Handbook (UHB):

http://www.ecb.europa.eu/paym/t2s/pdf/User_Handbook_v1.0.pdf?cc76cbb67593fe9e8b48

9e733a315bea

http://www.ecb.europa.eu/paym/t2s/governance/extmtg/html/mtg43.en.html





91

9 ALLEGATO A: DETTAGLIO DATI STATICI PER T2S

9.1 Introduzione

Questo capitoli si prefigge l’obiettivo di rendere noto ai clienti, siano essi partecipanti diretti

(DCP) o indiretti (ICP) alla piattaforma T2S, l’insieme di informazioni necessarie a Monte Titoli

per la configurazione in T2S, con indicazione delle corrispondenti modalità e regole di

migrazione adottate da Monte Titoli. Tale visione è puramente logica e tutti i dettagli pratici per

la configurazione saranno illustrati nel manuale d’uso del web tool per la configurazione dei dati

statici.

Al fine di razionalizzare l’intero insieme degli elementi di configurazione forniti da Monte Titoli ai

propri clienti, si è scelto di raggrupparle nei seguenti schemi logici:

1. Informazioni relative al Party in T2S

2. Informazioni relative al Technical Address network service link

3. Associazione Negoziatore/Liquidatore e relativi conti di regolamento (LIQDEF)

4. Associazione Negoziatore/General Clearing Member/Liquidatore del General Clearing

Member (CCPNEG)

5. Eccezione per mercato dell’ associazione Negoziatore/Liquidatore (LIQNEG)

6. Struttura dei conti per il Servizio di gestione accentrata

7. Coordinate per il regolamento contante di operazioni DVP

8. Coordinate per i regolamenti relativi alle corporate action in T2S

9. Coordinate per i pagamenti relativi alle corporate action in T2, con indicazione degli

elementi di configurazione necessari nel caso in cui il soggetto si avvalga o meno di

una banca tramite in T2.

Inoltre, al fine di agevolare la lettura delle tabelle proposte, si fornisce di seguito una breve

descrizione delle diverse colonne che compongono le tabelle stesse, le quali risultano così

articolate:

“N.” = numero d’ordine del dato

“Nome colonna” = nome del dato o della colonna

“Formato” = formato del dato o della colonna

“Descrizione “ = descrizione e significato del dato/colonna

“Commenti” = eventuali commenti aggiuntivi e necessari. Non si applica alle prime due

tabelle.

92

“Dati esistenti in MT [AS-IS]” = indica eventuali dati attualmente in essere nei sistemi

Monte Titoli con identificazione delle regole di mappatura delle dette informazioni e

modalità di traduzione delle stesse in T2S.

In particolare:

o Il valore “X” indica che il valore relativo al dato in questione è attualmente

presente nei sistemi legacy di Monte Titoli

o Il valore “n.a.” indica che il valore relativo a quel dato non è presente nei sistemi

di Monte Titoli ma è specifico della nuova piattaforma T2S

“Nuovi Dati in T2S”, i quali possono essere:

o “assegnati di default da MT” = valore assegnato di default da Monte Titoli in

fase di migrazione al dato di interesse;

o “Forniti obbligatoriamente dal Cliente” = il valore da assegnare al dato deve

obbligatoriamente essere fornito dal cliente.

In assenza di comunicazione del dato in questione da parte del cliente, Monte

Titoli non può procederne alla migrazione.

In particolare, si riporta di seguito il significato logico delle tre opzioni contenute nella

colonna “New Data in T2S”:

o “n.a”: quando il dato è assegnato di default da Monte Titoli e non è prevista

alcuna possibilità di modifica da parte del cliente;

o “ammesse possibili variazioni”: quando il dato è assegnato di default da Monte

Titoli ma è prevista la possibilità per il cliente di apportare modifiche al campo

stesso rispetto a quanto valorizzato da Monte Titoli;

o “obbligatorio”: quando il dato, non facendo parte del set informativo conosciuto

da Monte Titoli, deve essere obbligatoriamente comunicato dal cliente. Queste

sono le infomazioni "nuove", tipicamente richieste dall'avvento di T2S (esempio:

indicazione del Network Service, identificativo conto DCA, identificativo CMB,

etc...).

Si noti che le righe evidenziate in “giallo” indicano che il contenuto è ripreso da tabelle/schemi

precedenti e pertanto non si applicano le considerazioni riguardo ai valori da assegnare o

assegnati in quanto già trattati.

Tutte le righe evidenziate in giallo in una data tabella costituiscono un unico elemento

informativo che può essere sostituito in toto ove appunto già inserito in precedenza.

93

9.2 Party

La tabella proposta di seguito riporta l’insieme di informazioni necessarie a Monte Titoli per la configurazione dei clienti e riferibili al

nuovo concetto di PARTY introdotto con l’ avvento della nuova piattaforma T2S.

Nuovi dati in T2S

N. Nome colonna Formato Descrizione

Dati esistenti in MT

[AS-IS]

Assegnati di default

da MT

Forniti obbligatoriamente

dai clienti

1 Parent BIC CHAR (11) BIC della System Entity

responsabile del party X MOTI IT MM XXX n. a.

2 Tipologia di

partecipante

Possibili valori:

CSDP

ECSD

Classificazione delle party:

CSDP=CSD Participant

ECSD = External CSD

X Valori assegnati di

default da MT n. a.

3

Data di apertura

DATE

Data di attivazione del Party.

La stessa deve

necessariamente essere

maggiore o uguale al

27/04/2015

X

Data impostata da

Monte Titoli al

27/04/15

Ammesse possibili

variazioni nel caso in cui il

Party assegnato di Default

da MT non coincidesse con

le esigenze del cliente e

dovesse pertanto essere

variato

94

4 Data di chiusura DATE

Momento a decorrere dal

quale il Party non risulta

essere più attivo. La stessa

deve necessariamente essere

superiore alla data di apertura.

X Null

Ammesse possibili

variazioni per le ragioni su

esposte

5 Party BIC CHAR (11) BIC del PARTY X Valore assegnato di

default da MT

Ammesse possibili

variazioni in relazione alle

necessità di setup del CMB

e/o di matching.

In ogni caso almeno un

valore deve essere

presente

6 Long Name VARCHAR (350) Indicazione estesa della

denominazione del Party X

Valore esistente in MT

assegnato sulla base

del nome della Legal

Entity

n.a.

7 Short Name VARCHAR (35) Indicazione abbreviata della

denominazione del Party X


assegnato sulla base

del nome della Legal

Entity

n.a.

95

8 Indirizzo VARCHAR (70) Indirizzo del Party X


n.a.

9 Numero civico VARCHAR (16) Indicazione specifica del

numero civico riferito al Party X

10

Codice di

avviamento

postale

VARCHAR (16) Codice di avviamento postale

del Party X

11 Città VARCHAR (35) Indicazione della città del Party X

12 Provincia o

Stato VARCHAR (35)

Indicazione della provincia o

Stato del Party X

13 Codice del

Paese CHAR (2)

Indicazione del codice del

Paese X

14 Technical

Address VARCHAR (256)

Si applica ai soli clienti DCP.

Indicazione del technical

address della party

(distinguished name).

n. a.

Valorizzato

inizialmente da Monte

Titoli con un valore

fittizio tipo “valore da

assegnare”

I clienti ICP non devono

inserire/variare nulla in

questo dato.

Obbligatorio per i soli clienti

DCP. Questo è un nuovo

dato specifico di T2S per

consentire la connessione

diretta alla piattaforma T2S

96

9.3 Technical address network service link

La seguente tabella è di interesse per i soli clienti DCP. I clienti ICP possono ignorare quanto qui descritto ai fini della loro migrazione a

T2S. Si noti che la tabella di cui al capitolo 9.2. riporta al capo numero 14 l’ informazione riferita al “Technical Address”.

Gli elementi informativi di cui ai campi 3 e 4 della seguente tabella consentono, invece, di designare un’associazione tra i technical

address ed il corrispondente network service provider del quale il cliente si avvale.

Nuovi dati in T2S

N. Assegnati di

default da MT


da MT Descrizione

Dati esistenti in

MT

[AS-IS]


da MT

Forniti

obbligatoriamente dai

clienti

1 Parent BIC CHAR (11) BIC della System Entity

responsabile del Party X

Cfr. Tabella 9.2Party 2 Party BIC CHAR (11) BIC del party X

3 Technical

Address VARCHAR (256)

Incazione del technical

address della Party

(distinguished name)

n. a

4 Network

Service VARCHAR (35) n. a n. a. Obbligatorio

97

9.4 Associazione di default negoziatore/liquidatore e relativi conti di regolamento: (LIQDEF)

New data in T2S

N. Nome Colonna Formato Descrizione Commenti

Dati

esistenti in

MT

[AS-IS]

Assegnati di

default da MT

Forniti

obbligatoriame

nte dai clienti

1 Sistema di

liquidazione

Sistema di

liquidazione.

Può essere

assegnato uno dei

seguenti valori:

T2S: se

configurazione

lorda e netta di

Express II

coincidono

Netta: per

configurazione

netta

Lorda: per

Dal momento che oggi

in X-TRM sono quasi

sempre presenti per

uno stesso soggetto

due configurazioni,

una relativa alla

liquidazione lorda e

l’altra relativa alla

netta, potrebbero

verificarsi delle

situazioni nelle quali i

due valori differiscono

X n.a.

In caso di valori

“Netta” e “Lorda”

ci si aspetta che

uno dei due sia

chiuso

98

configurazione

lorda

2 Tipo negoziazione

Indicazione del tipo

di negoziazione.

Può assumere uno

dei seguenti valori:

P

T

BLANK=se

valgono P e T

contemporane

amente

X Assegnato di

default da MT

Ammesse

possibili

variazioni

3 Codice BIC del

negoziatore

Indicazione del

codice BIC del

soggetto

negoziatore

Tali informazioni

saranno fornite da MT

qualora esistenti nei

propri archivi

X

Valori

assegnati di

default da MT

n.a.

4 Codice CED del

negoziatore

Indicazione del

codice CED del

soggetto

negoziatore

X

Valori

assegnati di

default da MT

n. a.

5 Codice CED del Indicazione del X Valori Ammesse

99

liquidatore codice CED del

soggetto

liquidatore

assegnati di

default da MT

possibili

variazioni

6

Indicatore

liquidatore di

default

L’indicazione del

Flag (SI/NO)

permette di

identificare se il

liquidatore è quello

di default o meno

X

Valori

assegnati di

default da MT

Ammesse

possibili

variazioni

7 Inizio associazione

liquidatore

Indicazione della

data nella quale

inizia l’

associazione del

negoziatore con il

liquidatore

Si noti che la data è

sempre quella di

regolamento (SD)

X

8 Fine associazione

liquidatore

Indicazione della

data nella quale

termina l’

associazione del

negoziatore con il

liquidatore

Si noti che la data è

sempre quella di

regolamento (SD)

X

9 Codice del conto Indicazione del X Identificativo Ammesse

100

regolamento codice del conto di

regolamento

secondo la codifica

del CSD

conto

assegnato da

MT

possibili

variazioni

10 Indicatore conto di

default

Indica se il conto di

regolamento è

quello di default o

no per quella data

combinazione di

Tipo negoziazione/

liquidatore

X

Valori

assegnati di

default da MT

Ammesse

possibili

variazioni 11 Inizio associazione

conto

Indicazione della

data nella quale

inizia

l’associazione

conto

X

12 Fine associazione

conto

Indicazione della

data nella quale

termina

l’associazione

conto

X

101

9.5 Associazione Negoziatore/GCM/Liquidatore del GCM (CCPNEG)

New data in T2S


Dati

esistenti in

MT

[AS-IS]

Assegnati di

default da

MT

Forniti

obbligatoriame

nte dai clienti

1 Sistema di

liquidazione

Sistema di

liquidazione.

Può essere

assegnato uno dei

seguenti valori:

T2S: se

configurazione

lorda e netta di

Express II

coincidono

Netta: per

configurazione

netta

Lorda: per

Dal momento che

oggi in X-TRM sono

quasi sempre

presenti per uno

stesso soggetto due

configurazioni, una

relativa alla



netta, potrebbero

verificarsi delle

situazioni nelle quali

X n.a.

Cfr9.4:

Associazione di

default

negoziatore/liqu

idatore e relativi

conti di

regolamento:

(LIQDEF)

102

configurazione

lorda

i due valori

differiscono

2 Tipo

negoziazione

Specificazione del

tipo di negoziazione

“proprietà” o “terzi”

X

Valori

assegnati di

default da MT

3 Codice BIC del

negoziatore

Indicazione del

codice BIC del

soggetto

negoziatore

X

Valori

assegnati di

default da MT

4 Codice CED del

negoziatore

Indicazione del

codice CED del

soggetto

negoziatore

X

Valori

assegnati di

default da MT

5 Provenienza

Indica la

provenienza di

mercato

X

Valori

assegnati di

default da MT

Ammesse

possibili

variazioni

6 Mercato di

negoziazione

Indicazione del

mercato di

negoziazione

X

Valori

assegnati di

default da MT

Ammesse

possibili

variazioni

7 Codice CED

della CCP

Indicazione del

codice CED della X

Valori

assegnati di

Ammesse

possibili

103

CCP default da MT variazioni

8

Codice CED dell’

aderente

generale

Indicazione del

codice CED

dell’aderente

generale

X

Valori

assegnati di

default da MT

Ammesse

possibili

variazioni

9

Codice CED del

liquidatore del

GCM

Indicazione del

codice CED del

soggetto liquidatore

del GCM

X

Valori

assegnati di

default da MT

Ammesse

possibili

variazioni

10 Codice del conto

di regolamento

Indicazione del

codice del conto di

regolamento

X

Valori

assegnati di

default da MT

Ammesse

possibili

variazioni

11 Data inizio

validità

Indicazione della

data di inizio

validità

X

Ammesse

possibili

variazioni

12 Data fine validità Indicazione della

data di fine validità X

Ammesse

possibili

variazioni

104

9.6 Eccezione per mercato dell’ associazione negoziatore/liquidatore (LIQNEG)

New data in T2S


Dati esistenti

in MT

[AS-IS]

Assegnati

di default

da MT

Forniti

obbligatoria

mente dai

clienti

1 Sistema di

liquidazione

Sistema di

liquidazione.

Può essere

assegnato uno dei

seguenti valori:

T2S: se

configurazione

lorda e netta di

Express II

coincidono

Netta: per

configurazione

netta

Lorda: per

configurazione

Dal momento che

oggi in X-TRM sono

quasi sempre

presenti per uno

stesso soggetto due

configurazioni, una

relativa alla



netta, potrebbero

verificarsi delle

situazioni nelle quali i

due valori

differiscono

X n.a.

9.4Tabella:

Associazione

di default

negoziatore/liq

uidatore e

105

lorda relativi conti di

regolamento:

(LIQDEF)

2 Tipo negoziazione

Specificazione del

tipo di

negoziazione

X

Valori

assegnati di

default da

MT

3 Codice BIC del

negoziatore

Indicazione del

codice BIC del

soggetto

negoziatore

X

Valori

assegnati di

default da

MT

4 Codice CED del

negoziatore

Indicazione del

codice CED del

soggetto

negoziatore

X

Valori

assegnati di

default da

MT

5 Codice CED del

liquidatore

Indicazione del

codice CED del

soggetto

liquidatore

X

Valori

assegnati di

default da

MT

6 Codice del conto

regolamento

Indicazione del

codice del conto di

regolamento

secondo la codifica

X

Identificativo

conto T2S

assegnato

da MT

106

del CSD

7 Provenienza

Indica la

provenienza di

mercato

X

Valori

assegnati di

default da

MT

Ammesse

possibili

variazioni

8 Mercato di

negoziazione

Indicazione del

mercato di

negoziazione

X

Valori

assegnati di

default da

MT

Ammesse

possibili

variazioni

9 Data inizio validità

Indicazione della

data di inizio

validità

X

Valori

assegnati di

default da

MT

Ammesse

possibili

variazioni

10 Data fine validità Indicazione della

data di fine validità X

Valori

assegnati di

default da

MT

Ammesse

possibili

variazioni

107

9.7 Struttura dei conti per il servizio di gestione accentrata

New data in T2S


Dati esistenti

in MT

[AS-IS]

Assegnati

di default

da MT

Forniti

obbligatoria

mente dai

clienti

1 Parent BIC CHAR (11)

BIC della System

Entity responsabile

del Party

X MOT IT MM

XXX

Cfr.9.2

TabellaParty

2 Party BIC CHAR (11)

Indicazione del BIC

del Party al quale è

associato il conto

X

Valore

assegnato

di default da

MT

3 Codice ABI del

depositario

Indicazione del

codice ABI del

soggetto owner del

Securities account

X

Valore

assegnato

di default da

MT

n.a.

4 T2S Account ID Codice identificativo

del conto in T2S n.a.

Valore

assegnato

di default da

MT

Non

ammesse

variazioni

108

5 Codice del conto

Identificativo del

Securities Account

secondo la codifica

ABI

X

Valore

assegnato

di default da

MT

n.a.

6 Ruolo

Specificazione dell’

operatività del

soggetto. Può

ricoprire uno dei

seguenti ruoli:

emittente

intermediario

X

Valore

assegnato

di default da

MT

n.a.

7 Tipo conto


conto.

Può assumere uno


P: proprietà

T: terzi

L: liquidatore

X

Valore

assegnato

di default da

MT

Ammesse

possibili

variazioni ma

non attese

8 Tipo Conto

Collateral


conto collateral.

Può assumere uno

X

Valore

assegnato

di default da

n. a.

109


G: giver

R: receiver

Il tipo conto collateral

deriva dalla

partecipazione ad X-

COM ed è assegnato

a seconda della

configurazione

attualmente

presente.

MT

9 Data di apertura del

securities account

Indicazione della

data di apertura del

conto titoli

Deve essere

maggiore o uguale

al 27/04/2015

X

Valore

assegnato

di default da

MT

Ammesse

possibili

variazioni

10 Data di chiusura del

securities account

Indicazione della

data di chiusura del

conto titoli

Deve

necessariamente

essere successiva

alla data di apertura

del conto titoli

X Null

Non sono

attese

variazioni a

meno che il

securities

account non

venga chiuso

110

dopo la data

di go-live

11 Blocco Operativo

Può assumere uno

dei seguenti valori di

default:

S = si

N = no

I conti con blocco

operativo,

indipendentemente

dal fatto che siano

con o senza saldo,

verranno definiti e

configurati a livello

di T2S

X

Valore

assegnato

di default da

MT

n.a

12 Hold/Release

Indicator

Indicazione dell’

indicatore di Hold

and Release. Può

assumere uno dei

seguenti valori:

H= Hold

R=Released

n.a. RELE

Ammesse

possibili

variazioni

111

9.8 Coordinate per il regolamento contante operazioni DVP

New data in T2S


Dati esistenti

in MT

[AS-IS]

Assegnati di

default da

MT

Forniti

obbligatoriame

nte dai clienti


BIC della System

Entity responsabile

del Party

X

Cfr. 9.7 Tabella Struttura dei


Indicazione del BIC


associato il conto

X


del conto in T2S X

4 Codice ABI del

depositario

Indicazione del

codice ABI del X

112

soggetto owner del

Securities account

conti per il servizio di gestione

accentrata

5 Codice del conto

Identificativo del

Securities Account

secondo la codifica

ABI

X

6 Tipo conto


conto.

Può assumere uno


P: proprietà

T: terzi

L: liquidatore

X

7 Ruolo


operatività del

soggetto. Può

ricoprire uno dei

seguenti ruoli:

emittente

intermediario

X

8 Codice ABI del Indicazione del X Valore n.a.

113

soggetto

pagatore

codice ABI del

soggetto pagatore se

anche partecipante

Monte Titoli

assegnato di

default da

MT

9 CB Parent BIC CHAR (11)

Indicazione del BIC

della CB owner del

Party

n.a.

n.a.

L’informazion

e è relativa

all’identificati

vo T2S del

DCA [che si

basa su due

livelli: BIC

della

CB+BIC

della PB] non

è disponibile

a MT

Il cliente deve

fornire

obbligatoriament

e l’Identificativo

T2S del DCA su

due livelli (BIC

della CB + BIC

della PB) e la

PB deve

confermare

10 PB Party BIC CHAR (11)

Indicazione del BIC

della PB owner del

conto DCA

n.a.

114

11 Identificativo

conto DCA

Identificativo T2S del

DCA che è utilizzato

per i pagamenti in

associazione al

conto titoli

n.a.

n. a .

L’informazion

e è relativa

all’identificati

vo T2S del

DCA [che si

basa su due

livelli: BIC

della

CB+BIC

della PB]

non è

disponibile a

MT

Il cliente deve

fornire

obbligatoriament


T2S del DCA su

due livelli (BIC

della CB + BIC

della PB) e la PB

deve confermare

12 Identificativo

CMB


Credit Memorandum

Balance assegnato

dal proprietario del


per i pagamenti in

associazione al

conto titoli

n. a.

n. a.

L’informazion

e relativa

all’identificati

vo T2S del

CMB non è

Il cliente deve

fornire

obbligatoriament


T2S del CMB

115

disponibile a

MT

13 Default Link BOOLEAN

Indicazione del link

di default. Assume

valore pari a “True”

quando il conto DCA

è utilizzato come

conto di default per il

regolamento del

contante in T2S

Si specifica che per

un dato securities

account ci può

essere uno e un

solo link di default

ad un conto DCA,

tutti i link con altri

DCA saranno NON

di default

n. a. n. a. Mandatory

14 Data inizio

validità del link

Indicazione della

data di inizio validità

del link

n. a. 22/06/2015 Mandatory

15 Data fine validità

del link

Indicazione della

data di fine validità

del link

n. a.

Nessun

valore per

significare

n.a.

116

data aperta

16 Collateralisation

Link BOOLEAN

Se assume valore

“true”, T2S può

utilizzare questo

conto titoli per

operazioni di auto-

collateral fatte salve

tutte le altre

condizioni

necessarie

X

Assegnato

da MT sulla

base

dell’attuale

flag di self

collateralizati

on

Ammesse

possibili

variazioni

17 Cash Settlement

Link BOOLEAN

Se assume valore

“true”, T2S può

usare il link tra il

securities account ed

il T2S DCA per il

regolamento della

gamba cash della

settlement

instruction.

X

Valore

assegnato di

default da

MT

Ammesse

possibili

variazioni

117

9.9 Pagamenti relativi alle corporate action in T2S

Al fine di facilitare le attività di configurazione del cliente questo schema sarà popolato con valori predefiniti non significativi che il cliente

deve provvedere a sostituire con valori significativi.

New data in T2S


Dati

esistenti in

MT

[AS-IS]

Assegnati di

default da

MT

Forniti

obbligatoria

mente dai

clienti


BIC della System

Entity responsabile

del Party

X

Cfr. tabella 9.7Struttura dei


accentrata


Indicazione del BIC


associato il conto

X


del conto in T2S X

4 Codice ABI del

depositario

Indicazione del

codice ABI del

soggetto owner del

Securities account

X

118

5 Codice del conto

Identificativo del

Securities Account

secondo la codifica

ABI

X

6 Tipo conto


conto.

Può assumere uno


P: proprietà

T: terzi

L: liquidatore

X

7 Ruolo


operatività del

soggetto. Può

ricoprire uno dei

seguenti ruoli:

emittente

intermediario

X

8 CB Parent BIC CHAR (11)

Indicazione del BIC

della CB owner del

Party

n.a.

L’informazion

e relativa

all’identificativ

119

9 PB Party BIC CHAR (11)

Indicazione del BIC

della PB owner del

conto DCA

n.a.

o T2S del

DCA [che si

basa su due

livelli: BIC

della CB+BIC

della PB] non

è disponibile

a MT che

pertanto

assegna il

valore fittizio

“da definire”

Il cliente deve

fornire

obbligatoriam

ente

l’Identificativo

T2S del DCA

su due livelli

(BIC della CB

+ BIC della

PB) e la PB

deve

confermare

Il cliente deve

fornire

obbligatoriam

ente

l’Identificativo

T2S del DCA

su due livelli

(BIC della CB

+ BIC della

PB) e la PB

deve

10 Identificativo

conto DCA



per i pagamenti in

associazione al conto

titoli

n.a.

120

confermare

11 Identificativo CMB


Credit Memorandum

Balance assegnato

dal proprietario del


per i pagamenti in

associazione al conto

titoli

n. a.

n. a.

L’informazion

e relativa

all’identificati

vo T2S del

CMB non è

disponibile a

MT che

pertanto

assegna il

valore fittizio

Il cliente deve

fornire

obbligatoriam

ente

l’Identificativo

T2S del CMB

121

“da definire”

12 Tipologia di

operazione

Specificazione della

tipologia di

operazione. Tipologie

di pagamento

presenti in Monte

Titoli:

aumento di

capitale ed

esercizio Warrant

pagamento

dividenti/proventi

fondi

pagamento

interessi/rimborso

pagamenti su

titoli denominati

in divisa estera

pagamenti su

Le tipologie di

pagamento si

riferiscono a

quelle in essere in

MT con l’avvio del

progetto

Harmonisation

Custody.

Monte Titoli

rende

disponibile

solo la

tipologia

“Pagamento

Titoli di

Stato” in

quanto il

pagamento è

appunto

previsto

obbligatoria

mente in T2S

“Pagamento

su Titoli di

Stato”

Obbligatorio

122

Titoli di Stato

13 Codice ABI del

soggetto pagatore

Indicazione del

codice ABI del

soggetto pagatore.

Potrebbe essere

assente in caso di

soggetto pagatore

non partecipante a

MT

X n.a. n.a.

14 Data inizio validità

Indicazione della data

di inizio validità

dell’associazione

conto titoli/conto cash

(DCA) al fine

dellagestione dei

pagamenti relativi a

CA

n. a. 27/04/2015 n.a.

15 Data fine validità Indicazione della data

di fine validità n. a.

Nessun

valore per

significare

data aperta

n.a.

123

9.10 Pagamenti relativi alle corporate action in T2

Si ricorda che questi dati sono già presenti in Monte Titoli in quanto già utilizzati per la gestione ordinaria dei pagamenti relativi a

Corporate Action.

New data in T2S


Dati

esistenti in

MT

[AS-IS]

Assegnati di

default da

MT

Forniti

obbligatoria

mente dai

clienti


BIC della System

Entity responsabile

del Party

X

Cfr. 9.7 Tabella: Struttura dei


accentrata


Indicazione del BIC


associato il conto

X


del conto in T2S X

4 Codice ABI del

depositario

Indicazione del

codice ABI del

soggetto owner del

X

124

Securities account

5 Codice del conto

Identificativo del

Securities Account

secondo la codifica

ABI

X

6 Tipo conto


conto.

Può assumere uno


P: proprietà

T: terzi

L: liquidatore

X

7 Ruolo


operatività del

soggetto. Può

ricoprire uno dei

seguenti ruoli:

emittente

intermediario

X

8 Tipologia di

operazione

Specificazione della

tipologia di

Le tipologie di

pagamento si

125

operazione.

Tipologie di

pagamento presenti

in Monte Titoli:

aumento di

capitale ed

esercizio

Warrant

pagamento

dividenti/proven

ti fondi

pagamento

interessi/rimbor

so

pagamenti su

titoli denominati

in divisa estera

corrispettivi

RCC

riferiscono a quelle

in essere in MT con

l’avvio del progetto

Harmonisation

Custody

X

n.a.

Ammesse

possibili

variazioni

126

ELEMENTI DI CONFIGURAZIONE AGGIUNTIVI NECESSARI NEL CASO IN CUI IL SOGGETTO SI AVVALGA DI

UNA BANCA TRAMITE IN T2

9 ABI banca d’

appoggio

Codice ABI della

banca di appoggio X n.a.

Ammesse

possibili

variazioni

10 ABI banca tramite Codice ABI della

banca tramite X n.a.

Ammesse

possibili

variazioni

11

Identificativo

conto RTGS della

banca tramite

Indicazione del

conto RTGS

Target2 della banca

tramite di

riferimento

X n.a.

Ammesse

possibili

variazioni

12 Data inizio

validità

Indicazione della


del conto titoli al

conto contante

X

n.a.

Ammesse

possibili

variazioni


Indicazione della


del conto titoli al

Ove non valorizzata

indica che la

relazione è attiva.

X

127

conto contante Valorizzare questo

dato significa che si

vuole chiudere

l’associazione conto

titoli/conto contante

ELEMENTI DI CONFIGURAZIONE AGGIUNTIVI NECESSARI NEL CASO IN CUI IL SOGGETTO NON SI AVVALGA DI UNA BANCA

TRAMITE IN T2

14

Identificativo

conto RTGS della

banca d’

appoggio

Indicazione del

conto RTGS

Target2 della banca

d’appoggio di

riferimento

X n.a.

Ammesse

possibili

variazioni

15 ABI banca d’

appoggio

Codice ABI della

banca di appoggio X n.a.

Ammesse

possibili

variazioni

16 Data inizio

validità

Indicazione della


del conto titoli al

conto contante

X n.a.

Ammesse

possibili

variazioni

128


Indicazione della


del conto titoli al

conto contante

Ove non valorizzata

indica che la

relazione è attiva.

Valorizzare questo

dato significa che si

vuole chiudere

l’associazione conto

titoli/conto contante

X

129

10 Allegato B – Effetti sulle operazioni delle variazione della modalità di adesione alla

CCP e/o cambio del soggetto liquidatore

Al fine di agevolare la comprensione di quanto descritto al capitolo 6 si invita alle lettura

dell’allegato B che propone evidenza empirica degli effetti sui dati delle operazioni conseguenti

alle variazioni delle modalità di adesione alla CCP e/o cambio del soggetto liquidatore durante

la migrazione a T2S.

11 Allegato C – Access Rights per DCP

Si fornisce in allegato un elenco dettagliato dei diritti di accesso che Monte Titoli fornirà ai propri

clienti DCP.

Disclaimer Heading

Questo documento contiene testi, dati, grafici, fotografie, illustrazioni, elaborazioni, nomi, loghi, marchi registrati e

marchi di servizio e informazioni (collettivamente le “Informazioni”) che si riferiscono a Monte Titoli S.p.A. (“MT” o

“la Società”). MT cerca di assicurare l’accuratezza delle Informazioni, tuttavia le Informazioni sono fornite nello

stato in cui si trovano (“AS IS”) e secondo disponibilità (“AS AVAILABLE”) e possono, pertanto, essere non

accurate o non aggiornate. A seconda delle circostanze, le Informazioni contenute in questo documento possono o

non possono essere state preparate da MT, ma in ogni caso sono fornite senza alcuna assunzione di

responsabilità da parte di MT. La Società non garantisce l’accuratezza, la puntualità, completezza, appropriatezza

di questo documento o delle Informazioni per il perseguimento di scopi particolari.

Nessuna responsabilità è riconosciuta da parte di MT per ogni errore, omissione o inaccuratezza delle Informazioni

contenute nel documento. Nessuna azione dovrebbe essere (o non essere) intrapresa facendo affidamento sulle

Informazioni contenute nel documento. Resta inteso che non verrà assunta alcuna responsabilità per le

conseguenze che possano derivare da qualunque azione intrapresa sulla base delle Informazioni.

La Società promuove e offre i servizi Post Negoziazione secondo modalità eque, trasparenti e non discriminatorie

e sulla base di criteri e procedure che assicurano l'interoperabilità, la sicurezza e la parità di trattamento tra

infrastrutture di mercato, a tutti i soggetti che ne facciano domanda e siano a ciò qualificati in base alle norme

nazionali e comunitarie e alle regole vigenti nonché alle determinazioni delle competenti Autorità.

migration preparation schedule€¦ · 1. owner del sistema real time gross settlement, garantendo:...

Documents