MIGRATION PREPARATION SCHEDULE · the methods, timing and effort required, within the migration...

1

MIGRATION PREPARATION

SCHEDULE

T2S PROJECT

Version 1.0

Contents

1 DOCUMENT MANAGEMENT 6

1.1 Document History 6

1.2 Acronyms and abbreviations 6

1.3 Reference documentation 7

2 PURPOSE OF THE DOCUMENT 8

3 OVERVIEW OF THE MIGRATION PROCESS TO T2S 9

3.1 Migration planning 9

3.2 Actors involved 10

3.3 Composition of the first wave 12

3.4 Composition of the second wave 15

3.5 Composition of the third wave 16

3.6 Composition of the fourth wave 17

4 MIGRATION ACTIVITY PLAN 19

4.1 Activities and Synchronisation Points 19

5 MIGRATION OF STATIC DATA 26

5.1 Introduction to the migration of static data 26

5.2 Delivery to the clients of the data required for configuration in T2S 27

5.2.1 Pre-settlement service data 29

5.2.2 Settlement service data 31

5.2.3 Cross-border settlement service data (DVP Cross-Border) 32

5.2.4 Centralised administration service data (issuers and intermediaries) 32

5.3 Client confirmation of the configuration of data supplied by Monte Titoli 34

5.4 Transfer of the official configuration data in the test system 36

5.5 Pre-Migration Dress Rehearsal 36

5.6 Frozen Period 36

5.7 Go – live for static data in T2S 37

5.8 Contingency period for loading of static data 38

6 CHANGES IN THE PARTICIPATION METHODS AT MONTE TITOLI SERVICES 39

6.1 Change of payment agent 40

6.1.1 Change of the payment agent within the centralised administration service 40

6.1.2 Change of the payment agent within the settlement service 40

6.2 Change of the settlement agent and the type of registration to CCP 40

6.2.1 Operating model "A" or Gross Margination Model 43

6.2.2 Operating model "B" or Net Margination Model 54

7 T2S USER TESTING & MIGRATION TESTING 75

7.1 Introduction 75

7.2 User Testing: actors involved 75

7.3 User Testing 76

7.4 Migration Testing 78

8 MANAGEMENT OF ACCESS RIGHTS IN T2S (only for DCP) 79

8.1 Introduction to management of access rights to T2S 80

8.2 Main concepts and definitions 80

8.2.1 User Function 81

8.2.2 Privileges 81

8.2.3 Secured Object 82

8.2.4 Secured Group 82

8.2.5 Role 82

8.2.6 User 82

8.2.7 Data Scope 82

8.3 Configuration of the access rights in T2S 85

8.3.1 Users configuration 85

8.3.2 Privileges configuration 86

8.3.3 Roles configuration 86

8.4 Access rights allocation process in T2S 87

8.4.1 Access rights at Party level 88

8.4.2 Access rights at user level 90

8.5 Decentralised management of access rights in T2S 90

9 ATTACHMENT A – DETAILS OF STATIC DATA FOR T2S 92

9.1 Introduction 92

9.2 Party 94

9.3 Technical address network service link 97

9.4 Trader/Settlement agent link and relative settlement accounts: (LIQDEF) 98

9.5 Trader/GCM/GCM Settlement agent link (CCPNEG) 102

9.6 Market exception to the Trader/Settlement agent Association (LIQNEG) 105

9.7 Account structure for the Centralised Administration Service 108

9.8 Account details for the cash settlement of DVP transactions 112

9.9 Account details for payments related to corporate actions in T2S 118

9.10 Payments related to corporate actions in T2 123

10 Attachment B - Effects on the change of participation way to the CCP and/or

change of settlement agent on the transactions 129

11 Attachment C - DCP Access Rights 129

6

1 DOCUMENT MANAGEMENT

1.1 Document History

Date Version Details

09/04/2014 1.0 Italian version

30/05/2014 1.0 English version

1.2 Acronyms and abbreviations

Name Description

ATIE Register of Blocked and Drawn Securities

BAU Business As Usual

BIC Bank Identifier Code

CB Central Bank

CCP Central Counterparty

CMB Credit Memorandum Balance

CMS Collateral Management System

CSD Central Securities Depository

DCA Dedicated Cash Account

DCP Direct Connected Participant

DV Value Date

DVP Delivery Versus Payment

ECB European Central Bank

FIS Standardized Information Flows

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 Weeke nd

MWEDR Migration Weekend Dress Rehearsal

NSP Network Service Provider

OTC Over the Counter

PB Payment Bank

7

PMDR Pre Migration Dress Rehearsal

PMSP Pre - Migration Synchronisation Point

RBAC Role Based Access Controls

RCC Client Fee Settlement

RTGS Real Time Gross Settlement

SAC Securities Account

SME Securities Maintain Entity

SNB Net Bilateral Balance

SP Synchronisation Point

SW Software

T2S Target 2 Securities

UDFS User Detailed Functional Specifications

UHB User Handbook

VAN Value Added Network

1.3 Reference documentation

Reference document Source

Instructions X-TRM

http://montetitoli.it/area-

download/normativa/expressii/instrxtrm28102013no.en.pdf

Instructions of CSD

Service for

intermediaries and

Issuers

http://montetitoli.it/area-

download/normativa/gestioneaccentrata/instr14012014no.en.pdf

Migration Weekend

Playbook Documents of the “T2S/MT Testing & Migration” working group

published in the appropriate documentary section of the MT-X

T2S User Detail

Functional

Specifications

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

3be45b2d0bf5a5afcf4de34f36

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

cc76cbb67593fe9e8b489e733a315bea

http://montetitoli.it/area-download/normativa/expressii/instrxtrm28102013no.en.pdf

http://montetitoli.it/area-download/normativa/expressii/instrxtrm28102013no.en.pdf

http://montetitoli.it/area-download/normativa/gestioneaccentrata/instr14012014no.en.pdf

http://montetitoli.it/area-download/normativa/gestioneaccentrata/instr14012014no.en.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


8

2 PURPOSE OF THE DOCUMENT

The purpose of this document is to provide a detailed description of the set of activities and

processes expected for the direct involvement of the client or their synchronisation, with

reference to the migration of the client's static data.

In particular, details are provided regarding the activities that require client actions, specifying

the methods, timing and effort required, within the migration activity plan established at a

Eurosystem and Monte Titoli level.

The set of preparatory activities required for migration refers primarily to the three months that

precede the T2S go live and applies to the first migration wave only. The subsequent waves will

be discussed in a future document.

Moreover, the purpose of the "Migration Preparation Schedule" document is to provide a

complete overview of:

Identification of the set of preparatory activities to be completed before T2S migration

and requiring the involvement/interaction of/with the client;

Definition of the set of Pre-Migration Synchronisations Points (PMSP) at the

Eurosystem level and those being bilaterally agreed between Monte Titoli and its

clients;

Migration of static data:

o description and management of the migration process to T2S and of the new Monte

Titoli legacy systems;

o description of the informative items required for client configuration in the new

Monte Titoli legacy systems and in T2S; the approach to the recovery of the

required configuration elements for the migration of static data and the

management of the process when the mandatory information required by Monte

Titoli has not been received from the clients yet;

Definition of the "Frozen period" to be defined in order to avoid changes in the

configuration of static data;

Detailed analysis of the possible change scenarios regarding the methods of

participation to Monte Titoli services admitted during migration to T2S;

Introduction to the migration testing phase for the first migration wave to T2S;

Introduction to the management of access rights in T2S and in Monte Titoli (valid

exclusively for DCP clients).

9

3 OVERVIEW OF THE MIGRATION PROCESS TO T2S

3.1 Migration planning

The migration process to the new T2S platform has been divided into four different migration

waves, currently planned according to the diagram shown below.

Each individual migration wave is subdivided into three distinct phases. With particular

reference to the first migration wave, note should be taken of the timetable set by the

Eurosystem and defined as detailed below:

1. Pre-migration phase: period preceding the migration weekend;

2. Migration phase: actual migration to T2S weekend;

3. Stabilisation phase: verification period, subsequent to phase two, of the new T2S

platform.

Wave Pre-migration phase Migration weekend Stabilisation Phase

1 24 March 2015 -

19 June 2015

19 June 2015 -

22 June 2015

22 June 2015 -

27 July 2015

2 04 January 2016 -

25 March 2016

25 March 2016 -

28 March 2016

28 March 2016 -

25 April 2016

3 14 June 2016 -

09 September 2016

09 September 2016 -

12 September 2016

12 September 2016 -

17 October 2016

4 03 November 2016 -

03 February 2017

03 February 2017 -

06 February 2017

06 February 2017 -

13 March 2017

10

3.2 Actors involved

The table below provides a list of the actors involved in the migration process to the new T2S

platform, regardless of the specific migration wave in which they take part.

It is worthwhile to specify that each individual participant takes part in the migration process to

the T2S platform according to the specific role it is supposed to fulfil.

With particular reference to Central Banks, in the new scenario produced by the introduction of

the T2S platform, they may even perform four different roles, as:

1. Owner of the Real Time Gross Settlement system , guaranteeing:

The connection of the current RTGS Target 2 systems to the T2S platform;

The constant monitoring of liquidity in T2S as well as the transfer of the same from/to

Target 2 (liquidity transfer orders);

The management of the Dedicated Cash Accounts (DCA) in T2S.

2. Liquidity manager, guaranteeing:

The connection of the Collateral Management Systems (CMS) to T2S;

The management of the necessary configurations to activate the collateralisation

process in T2S;

The offer of collateral in T2S;

The reconciliation with the CMS of the movements triggered by the collateralisation

transactions in T2S.

3. System Entity, guaranteeing:

The definition and management of its own static data in T2S such as, for instance:

Party, DCA.

4. Settlement Agent, guaranteeing:

The definition of each individual Central Bank as a participant of a CSD;

The management of the link between its own holdings accounts and the DCAs;

The implementation of monetary policy transactions settlements in T2S.

For more information, reference should be made to the section "key documents" on the ECB

site, which contains the main documentation on T2S, through the link provided below:

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

It should be underlined that some Central Banks, as detailed in the tables below, will only

perform some of the four roles previously outlined.

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

11

ACTORS DESCRIPTION

Migrating CSD

Set of CSDs that take part in a specific migration wave.

The migration process to T2S takes place by involving

simultaneously the National Central Banks and CSD clients (CSD

Participant).

Migrating CB

Set of CSDs that take part in a specific migration wave.

The migration process to T2S takes place by involving

simultaneously the national CSDs and the Payment Banks.

As previously mentioned, it should be recalled that the Central

Banks may migrate to the new T2S platform by taking on one or

more of the roles previously described in paragraph 3.2 and listed

below:

Owner of the RTGS system

Liquidity manager

System Entity

Settlement Agent

SME CSD

CSDs that operate in T2S as SMEs, or "Securities Maintaining

Entities" of the financial instruments for which they are the Issuer

or Technical Issuer.

CSD participant

(DCP/ICP)

The CSD participants or CSD clients. It is possible to differentiate

between two different types of CSD participant, that is to say:

DCP: participants that interact directly with the T2S

platform in A2A or U2A mode;

ICP: participants that interact with the T2S platform

through the CSDs.

Payment Bank

(DCP/ICP)

The Payment Banks, meaning the entities that are clients of the

Central Banks. It is possible to differentiate between two different

types of Payment Bank:

DCP: participants that interact directly with the T2S

platform for the cash component in A2A or U2A mode;

ICP: participants that interact with the T2S platform

through the Central Banks.

Network Service

Provider (NSP)

It includes the two VANs (Value Added Networks) of T2S, meaning

"SIA/Colt" and "SWIFT" as well as DL (Dedicated Link) that

supplies the "CoreNet"

RTGS Operator Operators of the RTGS system connected to the T2S platform,

such as for example the "T2S Operator"

12

T2S Operator A entity of the Eurosystem that supports all the production

activities of the new T2S platform.

The subsequent chapters and the corresponding tables provide a list of the different actors

involved in each migration wave, with an indication of the role played by each entity taking part

in it.

However, it should be specified that the content may be subject to changes based on what is

established at the Eurosystem level.

For more detailed information and the latest updates regarding the composition and the roles

played by the various actors, reference should be made to the documentation available in the

specific T2S section on the ECB site (see link below):

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

3.3 Composition of the first wave

SUBJECT TYPE COMMENT

Clearstream Banking SME CSD

CSD that operates exclusively as a

"Securities Maintaining Entity" of the

static data migrated into the T2S

platform

Euroclear Belgium SME CSD




platform

Euroclear France SME CSD




platform

Euroclear Netherlands SME CSD




platform

Iberclear SME CSD




platform


13


LuxCSD SME CSD




platform

VP Securities SME CSD




platform

Bank of Greece Migrating CSD to T2S

Complete migration of the settlement

system and all connected activities to

T2S

Depozitarul Central Migrating CSD to T2S



T2S

Malta Stock Exchange Migrating CSD to T2S



T2S

Monte Titoli Migrating CSD to T2S



T2S

SIX SIS Migrating CSD to T2S Migration of the settlement system in

EUR and all connected activities to T2S

Bank of Greece Migrating CB to T2S Play all the four different roles of

Central Banks in T2S

Bank Centrali ta'Malta Migrating CB to T2S Play all the four different roles of


Banca d'Italia Migrating CB to T2S Play all the four different roles of


Banca Nationala a

Romaniei Migrating CB to T2S

Play some of the four different roles of

Central Banks in T2S. Specifically as:

“System Entity” and “RTGS System

Owner”

Banco de Portugal Migrating CB to T2S




Owner”

14


Deutsche Bundesbank Migrating CB to T2S




Owner”

NBB Migrating CB to T2S




Owner”

Banque de France Migrating CB to T2S




Owner”

De Nederlandsche

Bank Migrating CB to T2S




Owner”

Banco de Espana Migrating CB to T2S




Owner”

Banque centrale du

Luxembourg Migrating CB to T2S




Owner”

Oesterreichische

Nationalbank Migrating CB to T2S




Owner”

Danmarks





Owner”

Suomen Pankki Migrating CB to T2S




Owner”

Banka Slovenije Migrating CB to T2S Play some of the four different roles of

15




Owner”

Eesti Pank Migrating CB to T2S




Owner”

Lietuvos Respublikos

centriniu banku Migrating CB to T2S




Owner”

Magyar Nemzeti Bank Migrating CB to T2S




Owner”

Narodna banka

Slovenska Migrating CB to T2S




Owner”

3.4 Composition of the second wave


Euroclear Belgium Migrating CSD to T2S



T2S

Euroclear France Migrating CSD to T2S



T2S

Euroclear Netherlands Migrating CSD to T2S



T2S

Interbolsa Migrating CSD to T2S



T2S

NBB - SSS Migrating CSD to T2S Complete migration of the settlement


16


T2S

NBB Migrating CB to T2S Play all the four different roles of


Banque de France Migrating CB to T2S Play all the four different roles of


De Nederlandsche

Bank Migrating CB to T2S

Play all the four different roles of


Banco de Portugal Migrating CB to T2S Play all the four different roles of


Wave 1 CSDs and CBs CSDs and CBs already migrated during

the first migration wave

3.5 Composition of the third wave


Clearstream Banking Migrating CSD to T2S



T2S

Keler Hungary Migrating CSD to T2S



T2S

LuxCSD Migrating CSD to T2S



T2S

OeKB Migrating CSD to T2S



T2S

VP Lux Migrating CSD to T2S



T2S

VP Securities Migrating CSD to T2S

Migration of EUR settlement systems

as well as DKK settlement systems that

are expected to migrate in 2018

Deutsche Bundesbank Migrating CB to T2S Performance of all four different roles of


Banque centrale du Migrating CB to T2S Performance of all four different roles of

17


Luxembourg Central Banks in T2S

Magyar Nemzeti Bank Migrating CB to T2S Performance of all four different roles of


Oesterreichische


Performance of all four different roles of


Wave 1-2 Migrated CSDs and CBs

to T2S

CSDs and CBs already migrated during

the first two migration waves

3.6 Composition of the fourth wave


CDCP Slovakia Migrating CSD to T2S



T2S

Iberclear Migrating CSD to T2S



T2S

AS Eesti

Vaartpaberikeskus Migrating CSD to T2S



T2S

CSD of Lithuania Migrating CSD to T2S



T2S

Euroclear Finland Migrating CSD to T2S



T2S

KDD Slovenia Migrating CSD to T2S



T2S

BNY Mellon CSD Migrating CSD to T2S



T2S

Banco de Espana Migrating CB to T2S Play all the four different roles of


Suomen Pankki Migrating CB to T2S Play all the four different roles of


18

Banka Slovenije Migrating CB to T2S Play all the four different roles of


Eesti Pank Migrating CB to T2S Play all the four different roles of


Lietuvos Respublikos

centriniu banku Migrating CB to T2S



Narodna banka

Slovenska Migrating CB to T2S



Wave 1-3 Migrated CSDs and CBs

to T2S

CSDs and CBs already migrated during

the first three migration waves

19

4 MIGRATION ACTIVITY PLAN

The migration to T2S is subdivided into a number of phases:

preparatory activities: these include, for example, the preparation of the HW and SW,

the setup of the communication channels;

pre-migration or migration of static data: the purpose is to upload the static data linked

to financial instruments, participants and securities accounts that are required for the

correct implementation of the T2S settlement system in a production environment. It is

effectively a move to production for the above mentioned static data;

testing of migration activities;

testing of standard custody and settlement activities after the simulation performed

during the migration weekend;

migration weekend or dynamic data migration (transactions): this activity is the moment

when the actual move to T2S is completed and the so called migration weekend takes

place.

In order to verify the correct progress of the activities of all entities involved, as well as to

guarantee the correct alignment, a few Synchronisation Points (SP) have been defined to apply

to the various project phases.

Depending on the nature of these phases the ECB distinguishes between:

bilateral synchronisation points: which only involve a CSD/CB and the Eurosystem;

multilateral synchronisation points: which involve more actors, including the clients of

the respective CSDs/CBs.

In order to guarantee the success of the overall migration process, Monte Titoli, in addit ion to

the synchronisation points defined at the Eurosystem level, has introduced additional

synchronisation points with its clients [4.1].

4.1 Activities and Synchronisation Points

The list below shows the main activities and S.P. that directly or indirectly require the

involvement of clients for the migration to T2S.

The following migration plan could be subject to changes and subsequent redefinition as a

result of the planning put in place by the Eurosystem along with all the other actors taking part in

the first migration wave to T2S.

20

Monte Titoli will take care to provide prompt and well-documented information on any changes

via the usual communication channels in use with its clients.

It should also be noted that some of the activities listed refers exclusively to DCP clients and

may therefore be ignored by ICP clients.

N DESCRIPTION S.P. ACT

OR SUBJECT DEADLINE

1

Binding declaration to become a DCP

The clients must inform Monte Titoli of their

intention (binding declaration) of

participating as DCP to the T2S platform

X DCP 24/02/2014

2

Distribution of test cases for DCP

certification.

The Eurosystem provides the list of test

cases for DCP certification to DCP

participants

X

ECB

March 2014

3

Distribution of contracts and

membership forms - draft version

Deadline for the publication of the draft of

the contractual documents to clients by

Monte Titoli

X

MT

15/05/2014

4

Distribution of test cases for

authorisation

Monte Titoli provides the participants with

the list of test cases for the authorisation

process

X MT September

2014

5

Registration by the NSPs

Each DCP participant must complete the

registration by the NSP for the test

environment through their respective

CSDs/CBs

X DCP 31/10/2014

6

Request for assignment of

certificates/tokens

To access the test environment in order to

begin connectivity testing

X DCP 14/11/2014

7 Distribution of contracts, instructions

and membership forms

21


OR SUBJECT DEADLINE

Deadline for the final publication of the new

set of client contracts by Monte Titoli

X MT

15/12/2014

8

Connectivity testing

The DCPs are required to carry out these

tests in order to connect to the T2S

Community testing environment.

The ICP are involved in the appropriate

connectivity tests with MT directly through

the T1 test environment

X Clients

(DCP/ICP)

From

03/12/2014

to

27/02/2015

9

Configuration of DCA and CMB

The payment banks that offer cash

settlement services and/or client

collateralisation services to their clients

must duly authorise the clients involved to

use their own DCAs (CMB creation)

X X

PB

By

20/02/2015

10

First pre-migration Dress Rehearsal

Implementation of the first full pre-migration

Dress Rehearsal on static data relative to

securities and participants in the

Community test environment,

corresponding to the Monte Titoli T1 test

environment

X

MT

From

23/02/2015

to

27/02/2015

11

First pre-migration Dress rehearsal:

debriefing

The clients are invited to send their

feedback on the result of the first dress

rehearsal to Monte Titoli as well as

reporting any problems or critical elements

relative to the static data migrated to T2S

and directly visible on the new platform

X X

MT

DCP

From

03/03/2015

to

07/03/2015

12

NSP registration process

Each DCP participant must complete the

registration by the NSP for the test

environment through their respective

CSDs/CBs

X DCP 27/02/2015

13 Request for certificates/tokens to access X DCP 02/03/2015

22


OR SUBJECT DEADLINE

the production environment

14 DCP certification tests X DCP By March

2015

15

Start of Community testing

The CSDs, the Central Banks and their

participants are required to take part in

Community Testing

X

CSD

CB

Clients

(DCP/ICP)

02/03/2015

16

Connectivity tests for the first migration

wave

The DCPs are required to perform these

tests to connect to the T2S production

environment

The ICPs are involved in the appropriate

connectivity tests with MT directly in the

production environment (MT T1)

X

Clients

(DCP/ICP)

From

20/03/2015

to

03/04/2015

17

Deadline for confirmation of production

membership data

Deadline for confirmation to Monte Titoli of

the membership data for clients involved in

the production environment

X

Clients

(DCP/ICP)

20/03/2015

18

MWE Dress Rehearsal

The clients are required to take part in the

activities they have been assigned to and to

collect the results from the tests on the

implementation of the migration weekend

and relative to settlement activities (in T2S

Community environment and in the

corresponding Monte Titoli T1 testing

environment)

X

MT

Clients

(DCP/ICP)

From

17/04/2015

to

20/04/2015

19

MWE Dress Rehearsal: debriefing

Clients are invited to report the outcome of

the simulation performed during the

migration weekend to MT as well as any

specific critical elements and risks

connected to their “internal” activities to the

migration

X X

MT

Clients

(DCP/ICP)

From

23/04/2015

to

24/04/2015

23


OR SUBJECT DEADLINE

20

Static data go-live in the T2S production

environment and in the MT legacy

systems

Uploading of all static data and the related

applications in the new T2S production

environment and new Monte Titoli legacy

systems

X X MT

From

27/04/2015

to

04/05/2015

21

Contingency period for upload of static

data into the T2S production

environment

Buffer period provided in case that any

critical elements appear during the

uploading process and migration of static

data into T2S process

X X MT

From

05/05/2015

to

11/05/2015

22 Statement of correct implementation of

the certification tests X X

ECB

DCP 15/05/2015

23

Statement of correct implementation of

the authorisation tests

The Monte Titoli clients report the correct

implementation of the authorisation tests

X Clients

(ICP/DCP) 15/05/2015

24

MWE Dress Rehearsal 1

First implementation of the dress rehearsal

of the migration weekend with all production

data.

All subjects that took part in the first

migration wave to T2S will be involved

X

MT

Clients

(DCP/ICP)

From

15/05/2015

to

18/05/2015

25

Business day testing 1

During business day testing the clients will

be requested to upload transactions and

operate exactly as if they were in

production. These tests are performed in

the Monte Titoli test environment connected

to the T2S Community environment

X Community

From

18/05/2015

to

20/05/2015

26

MWE Dress Rehearsal: debriefing


feedbacks to MT regarding the results of the

X X

MT

From

21/05/2015

to

24


OR SUBJECT DEADLINE

Dress Rehearsal and report any problems

or critical elements that came to light during

the implementation of this Dress Rehearsal

Clients

(ICP/DCP)

22/05/2015

27

MWE Dress Rehearsal 2

Second implementation of the dress

rehearsal of the migration week with all

production data.

All subjects that took part in the first

migration wave to T2S will be involved

MT

Clients

(DCP/ICP)

From

29/05/2015

to

01/06/2015

28

Business day testing 2

During business day testing the clients will

be requested to upload transactions and

operate exactly as if they were in production

X Community

From

01/06/2015

to

03/06/2015

29

MWE Dress Rehearsal 2: debriefing


feedback to MT regarding the results of the

second Dress Rehearsal and the dialogue

with the new T2S platform and report any

problems or critical elements that might

have been appeared.

The positive outcome of the above Dress

Rehearsal could represent a positive

outcome for one of the entry criteria to T2S

X X

MT

Clients

(ICP/DCP)

From

04/06/2015

to

05/06/2015

30

Statement of correct implementation of

the Dress Rehearsal for the MWE

The clients are required to declare the

correct implementation of the Dress

Rehearsal of the migration weekend

X X

Clients

(ICP/DCP)

By

06/06/2015

31

Migration from the PI legacy test

environment to MT's T2 environment

Where applicable, clients are required to

migrate their pre-production test

environments by disconnecting them from

the old Monte Titoli PI test environment and

connecting them to MT's new T2 test

environment (pre-production).

X

Clients

(DCP/ICP)

15/06/2015

25


OR SUBJECT DEADLINE

In addition to this the DCPs must connect

their legacy systems directly to the T2S pre-

production environment

32

T2S GO-LIVE

IMPLEMENTATION OF THE MIGRATION

WEEKEND TO T2S

X X ALL

From

19/06/2015

to

22/06/2015

The move to production in T2S (Migration Weekend - MWE), as referred to the last item of the

previous table, is also known as dynamic data migration process and is described in detail in the

"Migration Weekend Playbook" document.

26

5 MIGRATION OF STATIC DATA

5.1 Introduction to the migration of static data

Migration of static data refers to the migration of the participants ’ configuration data and of the

financial instruments currently found in the Monte Titoli legacy system towards the new legacy

production systems and towards T2S.

Monte Titoli, in line with the strategic migration plan to the T2S platform defined at Eurosystem

level, will upload the static data starting approximately one and half months before (27 April

2015) the go live date for T2S (22 June 2015).

After the upload, this static data will be managed according to BAU criteria until the start of

T2S. More specifically, for what concerns the participant's static data , the criteria described

under chapter 5.6 apply, while regarding the new financial instruments Monte Titoli will upload

them in parallel both in the old environment and in the new system.

The reasons why Monte Titoli will begin uploading static data as of 27 April 2015 are the

following:

To avoid refusals by the T2S platform for Settlement Instructions with an earlier

Settlement Date, during the migration weekend (fail);

To minimize the risk of the migration process even with a separate management of the

activities to be performed during the T2S pre-migration period;

To dedicate an appropriate amount of time to the uploading of the static data that is

fundamental for the correct operation of the new settlement platform and Monte Titoli

services.

During the time preceding the T2S migration weekend, Monte Titoli and its clients are directly

involved in a set of specific preparatory activities in order to define the new set of data required

for client configuration in T2S and for the migration of static data (information on participants,

securities accounts as well as all connected configuration elements) which are on the current

legacy systems.

The static data migration process takes place according to the following steps:

1. Delivery to the clients of the data required for configuration in T2S

2. Client (and/or settlement agent/payment agent) confirmation of the configuration data

supplied by Monte Titoli

3. Transfer of the official configuration data into the test system

4. Pre-Migration Dress Rehearsal

27

5. Start of Frozen Period

6. Go – live for static data in T2S

7. Contingency period for uploading of static data

A graphic representation of the main steps included in the static data migration process to T2S,

which will be subsequently described, is below detailed:

5.2 Delivery to the clients of the data required for configuration in T2S

On 15 December 2014, Monte Titoli will provide its clients with an outline of the configuration

data currently found on the current production systems, adjusted according to the information

required for T2S.

This information, which until now has been collected via Bit -Club and/or the special

Participation forms such as for example the Operational Data Form, will be available and

accessible via a web interface that enables clients to view them and if necessary change them

or add new ones.

This tool will be accessed using the MT-X access credentials the clients already have. Clients

with no credentials are invited to submit a request to Monte Titoli by addressing it to the Monte

Titoli Client Support Office ([email protected]) that will also be able to provide additional

information on how the tool may be used.

mailto:[email protected]

28

Please remind that this tool will also be used once the system is up and running, replacing the

current Bit-Club and Operational Data Form to manage the configuration data for the relevant

services. A user guide will be made available in due course.

If a client requests a change of the data configuration to be included in the current production

system, and therefore using the current procedures, as of 15/12/2014 and until the final

deadline for changes set to 20/03/2015, it will then be up to the client to carry it over into the

new production environment via the web tool, so that it may be taken on board even for

migration to T2S.

In order to guarantee the static data migration process to T2S to take place successfully, thus

allowing the go-live and the uploading of the same in the new Monte Titoli legacy systems and

in T2S, Monte Titoli must register the clients with a clear breakdown of the set of information

required for their configuration in T2S.

The reason is that T2S requires different and in some cases additional information to be added

to what currently found in the Monte Titoli systems.

As detailed in the following diagram, Monte Titoli proceeds with the migration of data basing on

the original information available.

In particular, the set of information currently registered in the Monte Titoli legacy systems will be

migrated basing on specific mapping rules that determine how the information currently held in

the Monte Titoli system is translated in T2S.

Information

Existing in Monte Titoli systems

Identification of the mapping rules

New information

Requests for T2S

Must be communicated by the Clients

Assigned by default by Monte Titoli

29

This approach is designed to guarantee the best efficiency of the migration preparation process

by limiting client intervention to changes of the default values assigned by Monte Titoli and/or

the uploading of the new data required given the characteristics and peculiarities of T2S.

In this second case, if it is not possible to assign pre-determined values, it is essential that the

clients themselves communicate the required information for their configuration.

The information currently not found in Monte Titoli legacy systems, and requested by T2S, is

detailed below:

Account details for the settlement of DVP cash transactions and/or for the set of auto-

collateral transactions to be associated to the securities account

Account details for payments on Government Bonds

Account details for payments on Corporate Actions to be performed in T2S

More in detail, the data introduced via the web interface is related to the configuration of the

following services:

Pre-settlement service

Settlement service

DVP Cross-Border Settlement service

Centralised administration service (issuers and intermediaries)

The configuration for the FIS, RCC services will be provided in the web tool for completeness of

information, although it is not expected that they should face any change as they are not directly

affected by the migration to the new T2S platform.

5.2.1 Pre-settlement service data

For what concerns the configurations of the pre-settlement service (X-TRM), you'll find below all

the details of all information required in relation to:

1. Trader/Settlement agent association, with the indication of the default settlement agent

and its settlement accounts, both by default and not(LIQDEF);

2. Trader/Settlement agent association, relative to both the guaranteed and non-

guaranteed markets as an exception compared to (LIQDEF) based on Provenance and

the Trading Market (LIQNEG);

30

3. Trader/General Clearing Member/Settlement Agent association only for guaranteed

markets (CCPNEG).

In the web tool provided, the data above are presented from the respective point of view of the:

trader

settlement agent

The settlement agent will therefore be able to display all the configurations of the participant

(trader) which appointed it as their settlement agent.

Although they don’t impact on T2S, we also provide the configurations for the settlement of

transactions from the EuroTLX, Hi-MTF and EuroMOT markets, which also include the ExtraMot

segment on the Euroclear and Clearstream (ICSD) cross-border systems.

With particular reference to the Trader/Settlement agent association referred to the previous

list, it is specified that with T2S the association that currently exists between trader and

settlement agent, which now just includes subjects that are indirectly involved in the settlement

transactions, also includes the configuration of the entities that take part in the settlement

transactions (in association with themselves).

"Default settlement agent" refers to the trader/settlement agent association that the pre-

settlement system adopts where no indication regarding the settlement agent and/or the

securities account has been provided by the trader when undertaking a transaction.

Seeing as today in X-TRM there are almost always two different configurations for the same

entity, one concerning gross settlement and one to net, situations may occur, even if rarely, in

which the two may be different.

In this case, Monte Titoli will communicate both configurations through the specific web tool and

the client is invited to specify which of the two should be used in T2S.

More specifically, we require the client to:

1. input the chosen configuration by changing the settlement system setting to "T2S";

2. close the two configurations for the two old systems, setting their shut down data at 19

June 2015.

Finally, among the configuration elements supplied to the clients, Monte Titoli also guarantees

full visibility to the following information:

31

list of functions subscribed and related communication procedures;

list of participants that have been granted operating mandates for X-TRM, with a

detailed indication of the functions assigned as well as the profile associated to them;

the appointing participants may access all the participants that have been appointed for

a specific function and for each of the CED codes they have been assigned to.

Conversely, the assignees may view all the operating mandates received for each

function and for each assigned CED;

list of the participants that have granted contractual PoA (Power of Attorney) for X-TRM.

The granting of a contractual PoA implies a double confirmation of the configuration

data supplied by Monte Titoli even on behalf of the subjects that have been granted

PoA. Indeed, if no contractual PoA has been conferred, the membership data shall be

acquired and considered valid if sent by the client itself;

If a contractual PoA has been granted, the participant to whom the PoA has been

conferred is required to confirm the data membership required for T2S configuration.

5.2.2 Settlement service data

The clients are required to provide the T2S cash account details (DCA) for each securities

account held, in order to enable DVP settlement of the transactions.

The client must indicate whether it intends to avail or not of the auto-collateral function by

setting the appropriate flag.

In the same way, by clicking the appropriate flag, the client indicates whether the transactions to

be charged to the given account, in the absence of a specific indication within the same

instruction, should be considered as "Hold" or "Release" by the system (see paragraphs

“Account structure for the Centralised Administration Service” and “Account details for the cash

settlement of DVP transactions”).

Please note that seeing as authority over definition of DCA is assigned to the Central Banks, the

account details of the DCA are not known by Monte Titoli in advance, and must therefore be

forwarded to Monte Titoli directly by the client.

The above configurations refer to the Settlement system on the T2S platform. The settlement at

the ICSDs of transactions that coming from the market, such as EuroMOT for example and the

corresponding configurations are not subject to changes compared to those currently registered

in Bit-Club.

32

5.2.3 Cross-border settlement service data (DVP Cross-Border)

The cross-border settlement service, as specified in the corresponding "Service Instructions",

handles transfers of financial instruments issued by the cross-border CSD between a Monte

Titoli participant and a participant in a cross-border settlement system in T2S (on this topic

please consult the document in the section:http://montetitoli.it/area-

download/normativa/istrregesteromaggio2012.pdf).

Regarding this service, as of today there has been no indication of the need for changes or

additional information for T2S compared to those currently found in Bit -Club. It is hereby

specified however that the entire set of information relative to the cross-border settlement

service will also be available and accessible through the web tool.

5.2.4 Centralised administration service data (issuers and intermediaries)

The configurations for the centralised administration service concern the structure of the

accounts of the Monte Titoli participants in T2S (see table 4.7).

With reference to the latter, we hereby specify that all the securities accounts valid on the date

of the migration of the static data, regardless of whether they are balanced or not and the

existence of any transaction blocks, shall be established and configured in T2S.

Indications will also be supplied regarding the existing operating mandates and the

communication channels normally used by clients.

For each securities account, intermediary or issuer account, it provides details of the payment

bank and payment accounts for each kind of transaction, as detailed in the table below.

It is here underlined that the diagram provided below also manages the specific kind of issuer

payment bank to be used later during the assignment allocation phase by the issuing

participant:

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

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

33

In T2S, Monte Titoli will offer its clients the opportunity of indicating the payment system that

should be used, that is to say T2S or T2, for each different kind of transaction.

Depending on the different business requirements, the clients will have the option of choosing

whether to configure payments relative to corporate actions in T2 or in T2S, excepting:

Payments involving "Government bonds", implemented solely in the T2S payment

system;

"Payment of RCC fees", where payment is only expected to take place in T2, according

to the standard practices introduced by Custody Harmonization.

In any case Monte Titoli will carry forward the configurations in force in T2 at the time of

migration to T2S for all types of different payments other than those resulting from payments on

Government Bonds.

As a result each client, within a time frame and, for each of its own securities accounts, has to

provide Monte Titoli with the account details of the cash account associated to each account,

and in particular:

The BIC code of the Central Bank on which the cash account is held;

The BIC code (Party BIC) of the Payment Bank in whose name the cash account is

held;

Identification details of the DCA;

Identification of the Credit Memorandum Balance (CMB) assigned to the security

account/s for cash settlements.

34

For more detailed information on the information content of the main configuration data,

reference should be made to the attachment found at point 9.8 (Account details for the cash

settlement of DVP transactions).

5.3 Client confirmation of the configuration of data supplied by Monte Titoli

During the time period that runs from 15 December 2014, date of the delivery to the clients of

the necessary data for client configuration, to 20 March 2015, the clients are required to:

1 examine the configuration elements detailed in chapter 5.2;

2 if necessary, change the configuration elements detailed in point 1;

3 if necessary, close the configuration elements considered not to be necessary in T2S;

4 if necessary, insert the configuration elements to be used at the start of T2S;

5 accept any possible appointment as settlement agent and/or payment agent.

These activities are required in order to prepare and confirm the correctness of the configuration

data that will be subsequently migrated from Monte Titoli to T2S as production data.

In particular, at this stage the client is required to take a very close look at the set of information

provided and assess its correctness/completeness as well as providing prompt confirmation of

all shared configuration elements.

If the client has passed on part of its transactions to third parties, as payment agents or

settlement agents, these entities are also required to become involved and confirm/change the

data according to their specific role.

We hereby specify that, in a situation where the client or the settlement agent/payment agent

does not forward any communication of change or acceptance of the configuration information

they have been supplied with by the foreseen deadline, Monte Titoli will consider valid all the

default values assigned and previously communicated.

For what concerns the "new" configuration elements, seeing as they are specific of T2S and

not currently found on the Monte Titoli legacy systems, the clients themselves are required to

communicate them.

Given the critical nature of these information, if the client doesn't communicate them within a

time appropriate for migration, Monte Titoli will apply the following default configurations:

35

Account details for Corporate Action payments: Monte Titoli will consider valid the

information produced as part of the Custody Harmonization project, that is to say the T2

account details existing at the time of migration;

Account details for Government Bond payments: with reference to the mandatory

nature of this information, for payments in T2S, if the client has supplied information

concerning the account details for cash settlement of DVP transactions and for the set

of auto-collateral transactions related to the securities account but not the account

details for the payment of revenue from Government Bonds, it will be assumed that the

same account will be used as the one communicated for the DVP account details;

Account details for cash settlements of DVP transactions and for the set of auto-

collateral transactions associated with the securities account: with reference to the

mandatory nature of this information, if the client has supplied information concerning

the account details for cash settlement of Government Bonds, but no account details for

the payment of revenue from DVP transactions, it will be assumed that the same

account will be used as the one communicated for the Government Bonds;

Account details for the settlement of DVP transactions and/or for the set of auto-

collateral transactions associated with the securities account and account details for

Government Bond payments:

BEWARE: if these account details are not communicated by the client, they will not be

in a position to settle DVP transactions and/or carry out auto-collateral transactions and

they may not receive the proceeds from payments made on Government Bonds. In this

case the following effects may occur:

o during the migration weekend all the DVP instructions subject to migration that

refer to any of the securities accounts without any association to one or more

DCA cash accounts will be automatically rejected by the new T2S platform and

therefore shall not be migrated. These transactions will have to be freshly

uploaded by the clients as FoP transactions until a valid and correct indication

of the cash account details is communicated to Monte Titoli;

o the sum owed to the client in relation to the payment on Government Bonds will

remain on the Monte Titoli cash account until the client provides Monte Titoli

with the account detail information for Government Bond payments. Any

payment transactions made by Monte Titoli through its administration will be

charged to the client at current rates.

36

5.4 Transfer of the official configuration data in the test system

On 20 February 2015 Monte Titoli will export the official configuration data duly confirmed or

inputted by the clients (and/or settlement agent/payment agent) via the web platform for

membership activities and will transfer them to the test system in order to be able to carry out

the static data migration process dress rehearsals (Pre-Migration Dress Rehearsal).

The clients holding a huge number of accounts may only be required to input their main

management results into the web configuration tool until 19 February 2015; they are not

required to input all production data.

5.5 Pre-Migration Dress Rehearsal

On 23 February 2015, Monte Titoli will attempt a Dress Rehearsal in the Community test

environment on the set of static data duly confirmed/modified by the client and/or settlement

agent/payment agent or taken from the production link. It is here specified that the

implementation of the Pre-Migration Dress Rehearsal will not require any active participation on

behalf of the clients but will be implemented entirely by Monte Titoli.

The correct implementation of the Pre-Migration Dress Rehearsal test represents a pre-

requisite for Monte Titoli for the implementation of the Migration Weekend Dress Rehearsal test.

The web tool that manages the static data configuration process will at this point be available

even in the test environment and will enable clients to upload configurations for any tests that

may be subsequently carried over to the production environment.

Immediately after the conclusion of the pre-migration dress rehearsal, from 3 March 2015 to 7

March 2015, Monte Titoli expects to debrief with its own participants, with the aim of assessing

test output as well as analysing any potential critical areas and problems that may raise.

5.6 Frozen Period

The deadline of 20 March 2015 is the final deadline set for clients for the updating of the

configuration data that will be used for the actual migration to T2S. Consistently with the

descriptions provided above, starting from the following 21 March 2015, Monte Titoli will no

longer accept any changes to the configuration that will be used for the initial upload in the

production environment.

Please note that these limitations apply to all services provided by Monte Titoli with particular

reference to the data that relate directly to the new T2S system. From 21 March 2015 to 27 April

37

2015, Monte Titoli will verify the validity of the data in order to ensure the successful migration of

this data and of the entire subsequent migration weekend.

In the event of company transactions such as mergers, it is worthwhile specifying that , even in

standard conditions, this corporate events require time and appropriate analysis in order to be

successfully processed. Particularly if they are expected to take place very close to a major

change migration such as the one to the T2S platform, they should be assessed and planned

more in advance and with greater care and may not be considered as BAU transactions.

Any new issuer of financial instruments which needs to register with Monte Titoli to issue new

securities during this "frozen period" is invited to complete the membership process in time,

meaning before 21 March, in order to minimize the effort that may lead to problems during the

migration phase, as such situations need to be managed out of the standard procedure and

consequently cannot be tested.

It is here specified that no automatic alignment between environments by Monte Titoli is

foreseen, but these must be carried out directly by the client according to different criteria

depending on whether they refer to the test environment, the production environment, or both.

Given the above, the following scenarios may develop:

Case 1: change carried out by the client, both in the production and test environment;

Case 2: change introduced by the client only for the test environment. In this case the

configuration elements input shall not be present in the production environment,

meaning they will not be migrated to T2S and the new Monte Titoli system.

The client may, therefore, make use of the changes introduced exclusively for test

purposes;

Case 3: change introduced by the client only for the production environment. In this

case the configuration will be input and then migrated to T2S and in the new Monte

Titoli legacy systems.

Any change to the configurations requested by the old Monte Titoli legacy environments, if

considered necessary by T2S as well, must be once again loaded onto the client's production

and/or test environment depending on the requirements detailed above.

5.7 Go – live for static data in T2S

During the pre-migration phase, the ECB requires that all the static data is uploaded in the T2S

production environment and its own legacy systems and subsequently managed/processed

according to BAU criteria.

38

In the light of Monte Titoli's migration plan to the T2S platform, the go-live of the static data will

take place starting on 27 April 2015 for a period of approximately five business days.

As of that date, all Monte Titoli's static data will be reported in the new T2S production

environment and in the new Monte Titoli legacy systems.

5.8 Contingency period for loading of static data

The period between 5 and 11 May 2015 will be used by Monte Titoli to complete the static data

migration activities, should this process be extended due to unforeseen circumstances not

identified in previous test phases.

39

6 CHANGES IN THE PARTICIPATION METHODS AT MONTE TITOLI

SERVICES

To enable the clients to adopt the participation method that best satisfies its specific business

requirements on the new T2S settlement platform and at the same time minimize the

operational risks connected to the migration process itself, we will now proceed to detail the

possible changes in participation methods to the services allowed by Monte Titoli with the

introduction of the new platform (Migration Week End).

If the client is interested in modifying the participation profile in Monte Titoli services in

conjunction with the migration to the T2S platform, it is suggested that it has to consider the

consequences that these changes at a global level.

The next chapters provide a detailed description of the types of change that are admitted as well

as those not admitted and their impact on the dynamic data (X-TRM transactions).

It is worthwhile to underline that, where allowed changes are concerned, these will become

effective as of 22 June 2015, but must have been duly communicated by the clients to Monte

Titoli between 15 December 2014 and 20 March 2015.

Possible changes to service participation methods include the setup and/or withdrawal from one

or more services.

The changes to the X-TRM transactions deriving from a change of company details affect the

content of the G56 information flow for the entities involved in relation to the roles played (for

example settlement agent or General Clearing Member).

Below we provide an analysis of the following change categories:

Change of payment agent for the centralised administration service and/or the

settlement service

Change of settlement agent for OTC transactions and/or those received from non-

guaranteed markets

Change of the settlement agent for guaranteed markets and/or change of their type of

registration to the central counterparty

40

6.1 Change of payment agent

6.1.1 Change of the payment agent within the centralised administration service

The change of the payment agent within the centralised administration during the period of the

migration weekend is admitted and follows the same logic that applies to current changes.

It should be noted that, according with the decisions reached within the Harmonisation Custody

project (Cash Distribution), for payments affecting corporate actions with payment date starting

from Monday and Tuesday following the migration weekend, the new payment agent will receive

provisional/final messages as follows:

6.1.2 Change of the payment agent within the settlement service

The change of the payment agent for the settlement of DVP transactions during the period of

the migration weekend will be admitted, seeing as it is a non-critical transaction.

As on the X-TRM platform the payment agent may be present in the transactions, it is essential

the consistency between the static configurations input; otherwise the system will take on board

the default data setting.

It should be noted that the changes in the payment agent also apply to the failed instructions,

meaning the instructions that are awaiting settlement with an ISD prior to the migration to T2S

weekend.

The change of the payment agent for the settlement influences directly the calculation of the

cash balance and the purchasing power of the payment agent.

6.2 Change of the settlement agent and the type of registration to CCP

Depending on the type of transactions registered in X-TRM at the time of migration, and

therefore on the client configurations that enable their correct processing, the change of the

settlement agent may be applied to:

41

1. only OTC transactions and/or those received from non-guaranteed markets

2. transactions from guaranteed markets and related net bilateral balances

In the former instance, as a result of the change, the previous settlement agent will no longer

find the transactions affected by the change in the report from X-TRM while the same will be

available in the report of the new settlement agent. It will however have no effect on the

information to be forwarded to the trader.

In the latter case, for change of settlement agent in case of transactions from guaranteed

markets, we provide below a summary of the different cases of the participation set-up in X-

TRM and in the Central Counterpart that are divided into:

1. model 'A' or gross margination model, valid for the equity market (see 6.2.1.)

2. model 'B' or net margination model, valid for the bond market (see 6.2.2.)

For further details reference should be made to the "Instructions for the X-TRM Service"

contractual document published on the Monte Titoli website.

The possibility of admitting or excluding configuration changes of static data depending on CCP

membership type and the procedure in use by the CCP participant and/or trader taking part in

settlement depends on the type of amendment required and on the procedure used to calculate

the net bilateral balance.

The analysis provided below details all the possible switches from one scenario to another,

describing each scenario and the possible consequences and impacts on the dynamic data

(indication of the data that is subject to change on the transactions and on the net bilateral

balances) and the participants involved.

For a complete understanding it is also suggested to consult the document referred to in chapter

10. ("Effects on the change of participation way to the CCP and/or change of settlement agent

on the transactions").

It should be noted that the scenarios described in this chapter is highlighted in a colour:

Grey: describe cases that are currently present on the legacy system;

Green: describe instances that are not currently in the Monte Titoli systems, meaning

cases 2, 3B and 5 detailed in the subsequent chapters. It is hereby specified that the

“green” scenarios are reported for completeness of analysis.

42

Furthermore, in the tables that follow, the cases marked with the symbol:

√: refers to changes in the type of CCP membership and/or of the participation

procedure adopted by the CCP participant in the clearing process and/or the trader that

are admitted;

: indicates changes that are admitted and that require an amendment of the

issuer of the transaction (CED code);

X: indicates non admitted changes.

Monte Titoli allows changes in the General Clearing Member (GCM) and/or settlement agent, as

long as this does not entail the creation from scratch or the delete of an X-TRM transaction at

the time of migration.

Furthermore, the changes that require the amendment of the central counterparty involved in

the transaction are not supported (from LCH SA to CC&G and vice versa).

For both operating models (“Gross Margination Model – A” and “Net Margination Model – B”)

each participant can view the transactions depending on its specific role and the type of

accessibility assigned by the trader.

√

43

6.2.1 Operating model "A" or Gross Margination Model

Below we provide a summary of the various cases found in the operating model A:

The following diagram shows an example for each event, indicating the entity to which the

bilateral balance refers to .

The following table summarizes the different scenarios in case of switch between one case to

the another one as described above. The switch from one case to the other is considered as a

change of settlement agent and/or a change in registration to the Central Counterparty.

44

In the Gross Margination Model (Model A) the participant with obligations towards the central

counterparty is the GCM or ICM (besides case 2) therefore the net bilateral balance refers to the

positions of the trader with reference to the central counterparty.

It follows that in all instances involving admitted changes, the entity that performs the role of

trader will have no impact on the X-TRM information.

Move from case 1 to case 3

SCENARIO

The trader moves from direct to indirect in the settlement service

The trader is no longer a direct participant in the CCP but operates through a general

clearing member

CONSEQUENCES

The trader, both in its role as "replaced" settlement agent and individual clearing

member, can no longer view its own transactions

The "incoming" settlement agent/GCM (of the trader) can view the transactions of the

trader that was previously directly appointed as settlement agent

The following data is subject to changes on the transaction:

o settlement agent

o general clearing member

o settlement account

the following data is subject to changes on the bilateral net balance :

45

o settlement agent



SCENARIO

The trader moves from indirect to direct participation in the settlement service

The trader moves from an indirect membership to the CCP to a direct one

CONSEQUENCES

The "replaced" settlement agent, even if acting as GCM, can no longer view the trader’s

transactions

The "incoming" settlement agent that is also the trader and individual clearing member,

by becoming direct, has full access to all the transactions regardless of the role

performed


o settlement agent



o code of the participant that owns the bilateral net balance

The following data is subject to changes on the bilateral net balance :

o settlement agent



SCENARIO

The trader moves from direct in the settlement transaction to indirect (operating through

a settlement agent)

The trader maintains a direct CCP membership mode

CONSEQUENCES

The trader, in its role as "replaced" settlement agent, can no longer view its own

transactions

The "incoming" settlement agent can view the transactions of the trader that was

previously directly involved in settlement


o settlement agent


46

The following data is subject to changes on the bilateral net balance:

o settlement agent



SCENARIO

The trader moves from indirect to direct in the settlement system

The trader maintains a direct CCP membership mode

CONSEQUENCES

The "replaced" settlement agent can no longer view trader transactions


by becoming direct, has full access to all the transactions regardless of the role

performed


o settlement agent



o settlement agent



SCENARIO

The trader moves from direct to indirect in the settlement service

The trader is no longer direct to the CCP but operates through a general clearing

member to the CCP (the trader must use the GCM’s settlement agent)

CONSEQUENCES


transactions

The "incoming" settlement agent can view all the transactions of the trader that was


The general clearing member has a full view of the trader's transactions, thanks to its

indirect membership in the CCP


o settlement agent


47



o settlement agent



SCENARIO

The trader moves from indirect to direct in the settlement service

The trader moves from an indirect membership of the CCP to a direct one

CONSEQUENCES

The "replaced" settlement agent can no longer view the trader’s transactions

The "incoming" settlement agent, which coincides with the trader, has a full view of its

own transactions

The "replaced" general clearing member can no longer view the transactions, due to its

direct membership to the trader's CCP

The individual clearing member (the trader) has a full view of its own transactions

thanks to its direct registration to the CCP


o settlement agent




o settlement agent



COMBINED SCENARIO

SCENARIO 1

The trader moves from an indirect participation to the CCP to a direct one but retains the same

settlement agent

SCENARIO 2

The trader moves from an indirect participation to the CCP to a direct one and changes the

settlement agent

48

CONSEQUENCES

SCENARIO 1

The "replaced" general clearing member can no longer view the trader's balances

The trader acquires the full visibility of its balances even in its role as ICM

The settlement agent continues to have the same visibility over the transactions as the

trader compared to the pre-variation situation seeing as the settlement agent has

remained the same

Only the field relative to the General Clearing Member is subject to changes on the

transaction

SCENARIO 2

The trader acquires the full visibility of its balances even in its role as ICM

The "replaced" general clearing member can no longer view the trader's transactions

even in its role as "replaced" settlement agent

The "incoming" settlement agent has a full view of the trader's transactions even in its

role as settlement agent of the individual clearing member


o settlement agent




o settlement agent



SCENARIO

The trader moves from a direct membership of the CCP to an indirect one

CONSEQUENCES

The "replaced" GCM can no longer view the trader’s balances

The "incoming" GCM can view the trader’s balances



remained the same

Only the field relative to the general clearing member is subject to changes on the

transaction

49


COMBINED SCENARIO

SCENARIO 1

The trader maintains the same settlement agent while changing the GCM (the settlement agent

for the trader must coincide with the GCM settlement agent)

SCENARIO 2

The trader changes the GCM and the settlement agent. It should be noted that the settlement

agent for the trader must coincide with the GCM settlement agent

CONSEQUENCES

SCENARIO 1

The "replaced" GCM can no longer view the trader’s transactions yet retains this

capacity in its role as settlement agent



transaction

SCENARIO 2

The "replaced" settlement agent and GCM can no longer view the trader’s transactions

The "incoming" settlement agent and GCM can view the trader’s transactions. The

following data is subject to changes on the transaction:

o settlement agent




o settlement agent



SCENARIO

The trader changes GCM using its own settlement agent

CONSEQUENCES

The "replaced" GCM can no longer view the trader’s balances of the trader

50

The "incoming" GCM can view the trader’s balances. The settlement agent continues to

have the same visibility over the transactions as the trader compared to the pre-

variation situation seeing as the settlement agent has remained the same


transaction


SCENARIO 1

The trader moves from direct to indirect registration to the CCP

The trader does not change its settlement agent seeing as it already turns out to be the

settlement agent for the new GCM

SCENARIO 2

The trader moves from direct to indirect participation to the CCP

The trader changes its settlement agent that has the same settlement agent as the

GCM

CONSEQUENCES

SCENARIO 1

The "replaced" ICM can no longer view the trader’s balances




remained the same


transaction

SCENARIO 2



previously directly appointed as settlement agent

The "new" general clearing member has a full view of the trader's transactions,

interfacing directly with the CCP

The "replaced" general clearing member can no longer view its own transaction

balances


o settlement agent


51



o settlement agent



SCENARIO

The trader moves from an indirect registration to the CCP to a direct one

The trader changes settlement agent

CONSEQUENCES


The "incoming" settlement agent can view all the trader’s transactions

The "replaced" GCM can no longer view the trader’s balances of the trader

The trader, in its role as "incoming" ICM, can view its own balances


o settlement agent




o settlement agent



SCENARIO

Change of the settlement agent which is also a general clearing member

CONSEQUENCES



role as settlement agent for the general clearing member

Seeing as the settlement agent and the general clearing member are the same entity,

the view of the GCM is the same compared to that of the settlement agent (as reported

above)


o settlement agent


52



o settlement agent



SCENARIO

Change of the settlement agent, but not in the participation set up to the CCP (direct)

CONSEQUENCES


The "incoming" settlement agent can view all trader transactions


o settlement agent



o settlement agent



COMBINED SCENARIO

SCENARIO 1

The general clearing member changes but there is no amendment to the settlement agent

(either for the general clearing member or for the trader), seeing as the settlement agent of the

new GCM is the same as the one of the previous GCM

SCENARIO 2

Change of general clearing member. A change of the trader's settlement agent is also foreseen,

which must then use the settlement agent of the new general clearing member

CONSEQUENCES

SCENARIO 1

The "new" GCM can view the trader's transactions, seeing as the new subject is

required to interface with the CCP

The "old" GCM can no longer view the trader’s transactions

53

The settlement agent of the general clearing member and of the trader continues to

have the same visibility over the existing transactions compared to the pre-variation

situation seeing as the settlement agent has remained the same


transaction

SCENARIO 2

The "old" GCM and trader settlement agent can no longer view the trader’s transactions

The "new" GCM and trader settlement agent can view all the trader’s transactions

The "new" general clearing member can view the trader's transactions, seeing as the

new subject is required to interface with the CCP

The "replaced" clearing member can no longer view the trader’s transactions


o settlement agent




o settlement agent


54

6.2.2 Operating model "B" or Net Margination Model

Below we provide a summary of the various cases found in the operating model B or net

margination model.

The following table shows the different scenarios encountered in moving from one case to the

another one: the move from one case to the other is in each case represented by a change of

settlement agent and/or a change in participation to the Central Counterparty.

55

The following diagram shows an instance for each case indicating the subject to which the

bilateral balance refers to.

Move from case 1 to case 3A

SCENARIO

The trader moves from being direct to indirect in the settlement system

The trader is no longer directly associated with the CCP (individual clearing member)

but operates through a general clearing member (the trader's account will be same as

the GCM account)

CONSEQUENCES

The trader, both in its role as "replaced" settlement agent and individual clearing

member, can no longer view its own transactions, neither as issuer or counterparty

The "incoming" settlement agent/GCM can view the transactions of the trader that was



o settlement agent





o issuer

o negotiation type (in certain instances)

o settlement agent


56

Move from case 3A to case 1

SCENARIO

The trader moves from an indirect participation in the settlement process to a direct one

The trader moves from indirect membership in the CCP to a direct one

CONSEQUENCES

The "replaced" settlement agent, also as GCM, can no longer view the trader’s

transactions

The "incoming" settlement agent, that is also the trader and ICM, has full visibility of all

the transactions regardless of the role performed


o settlement agent





o issuer


o settlement agent



SCENARIO

The trader moves from direct in the clearing operation to indirect (operating through a

settlement agent)

The trader maintains a direct participation to the counterparty

CONSEQUENCES

The "incoming" settlement agent (of the trader and the GCM) can view the transactions

of the trader that was previously directly appointed in clearing


transactions


o settlement agent



o settlement agent

57

o Settlement account


SCENARIO

The trader moves from indirect to direct in clearing

The trader maintains a direct participation to the CCP

CONSEQUENCES


has full visibility of all the transactions regardless of the role performed



o settlement agent



o settlement agent



SCENARIO

The trader is no longer a direct participant in the CCP but operates through a general

clearing member

The trader moves from being directly appointed in the clearing operation to take an

indirect role using the same settlement agent as the GCM. Please note the trader

account is the same as the clearing member's account

CONSEQUENCES


transactions


previously directly involved in the settlement process

The general clearing member has a full view of the bilateral balances set up in its name


o settlement agent





58

o settlement agent


o issuer



SCENARIO

The trader moves from indirect to direct in settlement system

The trader moves from an indirect participation of the CCP to a direct one

CONSEQUENCES


The "incoming" settlement agent, which coincides with the trader, has a full view of its

own transactions

The "replaced" general clearing member can no longer view the transactions, due to its

direct participation to the trader's CCP

The trader, in its role as "incoming" settlement agent, has a full view of its own

transactions thanks to its direct participation to the CCP

The bilateral balances created in the name of the general clearing member are taken on

by the trader


o settlement agent




o settlement agent


o issuer


Move from case 2 to case 3B

COMBINED SCENARIO

SCENARIO 1

The trader moves from direct to indirect in the settlement system using the same GCM. The

settlement agent must use two different accounts for the trader and the GCM

SCENARIO 2

59

The trader moves from direct to indirect in the settlement system and change the general

clearing member. The settlement agent must use two different accounts for the trader and the

GCM

CONSEQUENCES

SCENARIO 1

The trader continues to view its own transactions but no longer as "replaced" settlement

agent

The trader’s "incoming" settlement agent can view all the trader’s transactions, which it

could previously view in its role as GCM

The following fields are subject to change on the transaction:

o settlement agent


The following data is subject to changes on the bilateral net balance (transaction

between trader and its general clearing member):

o settlement agent



between general clearing member and CCP):


SCENARIO 2


agent

The "replaced" GCM can no longer view the trader’s transactions

The "incoming" GCM, even in its role as the trader's settlement agent, has a full view

of the trader's transactions


o settlement agent





o settlement agent


o issuer

o the counterparty



60

o issuer

o settlement agent


o counterparty

Move from case 3B to case 2

COMBINED SCENARIO

SCENARIO 1

The trader moves from indirect to direct in the settlement system and changes General Clearing

Member. The clearing member and the settlement agent coincide

SCENARIO 2

The trader moves from indirect to direct in the settlement system and changes General Clearing

Member. The clearing member and the settlement agent coincide

CONSEQUENCES

SCENARIO 1

The “replaced” trader’s settlement agent, can no longer view the trader’s transactions


transactions

The "new" General Clearing Member, which coincides with the GCM settlement agent,

has a full view of the trader's transactions, thanks to its indirect participation in the CCP.



o settlement agent





o settlement agent


o the counterparty

the following data is subject to changes on the bilateral net balance (transaction

between the general clearing member and the CCP):

o issuer

o settlement agent


61

SCENARIO 2

The trader’s "replaced" settlement agent can no longer view the trader’s transactions


transactions

The general clearing member, which coincides with the GCM settlement agent,

continues to have the same view of the trader's transactions


o settlement agent




o settlement agent


Move from case 2 to case 5B

SCENARIO

The trader moves from direct to indirect in the settlement system and changes the

GCM. The new trader and GCM settlement agent must use different accounts

CONSEQUENCES


agent

The "replaced" GCM, can no longer view the trader’s transactions

The "new" settlement agent of the trader and general clearing member can view all the

trader’s and new GCM’s transactions





o settlement agent





o settlement agent


o counterparty



62

o issuer


Move from case 5B to case 2

SCENARIO

The trader moves from indirect to direct in the settlement system and changes GCM

CONSEQUENCES

The trader, that is the same with the "incoming" settlement agent, has a full view of its

own transactions, but not as GCM settlement agent


The "new" general clearing member, that is the same with its own settlement agent,

has a full view of the trader's transactions, thanks to its indirect membership in the CCP



o settlement agent





o settlement agent


o counterparty



o issuer



COMBINED SCENARIO

SCENARIO 1

The trader moves from an indirect participation to the CCP to a direct one and it maintains the

previous GCM’s settlement agent

SCENARIO 2

The trader moves from an indirect participation to the CCP to a direct one and it resorts a new

settlement agent

63

CONSEQUENCES

SCENARIO 1

The trader acquires the visibility of its balances in its role as ICM

The "replaced" GCM can no longer view the trader's balances, but retains visibility over

them in its role as settlement agent

The settlement agent continues to have the same visibility over the trader’s transactions

compared to the pre-variation situation seeing as the settlement agent has remained

the same






o issuer


SCENARIO 2

The trader acquires the visibility of its balances in its role as ICM

The "replaced" GCM can no longer view the trader's transactions even in its role as

"replaced" settlement agent

The "new" trader’s settlement agent, that is the ICM, can now view all transactions


o settlement agent






o issuer


o settlement agent



SCENARIO

The trader moves from a direct registration to the CCP to an indirect participation in the

CCP

64

CONSEQUENCES




as it had in the pre-variation situation seeing as the settlement agent has remained the

same



o code of the subject that owns the bilateral net balance


transaction



o issuer


Move from case 3A to case 5A

COMBINED SCENARIO

SCENARIO 1

The trader changes GCM while using the same settlement agent

SCENARIO 2

The trader changes GCM and at the same time changes its settlement agent which must

coincide with the one of the GCM

CONSEQUENCES

SCENARIO 1

The trader’s settlement agent continues to view the trader’s transactions, but no longer

as "replaced" GCM

The "incoming" GCM can view the trader’s transactions




SCENARIO 2

The "old" trader settlement agent can no longer view the transactions

The "incoming" settlement agent can now view the trader’s transactions

The "replaced" GCM can no longer view the trader’s transactions

65

The "incoming" GCM acquires the visibility of the trader’s transactions


o settlement agent






o issuer

o settlement agent



SCENARIO

The trader changes GCM using its own settlement agent

CONSEQUENCES




as it had prior to the pre-variation situation seeing as the settlement agent has remained

the same





between general clearing member and CCP);

o issuer

Move from case 3B to case 5B

COMBINED SCENARIO

SCENARIO 1

The trader changes GCM maintaining the same settlement agent that uses two different

accounts for the trader and the GCM

SCENARIO 2

66

The trader changes GCM and changes settlement agent at the same time, which then uses two

different accounts for the trader and the GCM

CONSEQUENCES

SCENARIO 1

The trader’s settlement agent continues to view the trader’s transactions but no longer

as "replaced" GCM

The "incoming" GCM can now view the trader’s transactions




Only the field relative to the issuer is subject to changes on the bilateral net balance

(transaction between general clearing member and CCP)


(transaction between trader and its general clearing member)

SCENARIO 2

The “old” trader settlement agent can no longer view the trader’s transactions, even as

"replaced" GCM

The "incoming" settlement agent acquires the visibility of the trader’s transactions

The "incoming" GCM acquires the visibility of the trader’s transactions


o settlement agent






o settlement agent


o counterparty



o issuer

o settlement agent


67


SCENARIO

The trader changes GCM using its own settlement agent and two different accounts

CONSEQUENCES





the same




Only the data relative to the counterparty is subject to change on the bilateral net

balance (transaction between trader and its general clearing member)

Only the data relative to the counterparty is subject to change on the bilateral net

balance (transaction between general clearing member and CCP)


COMBINED SCENARIO

SCENARIO 1

The trader moves from direct to indirect participation to the CCP

SCENARIO 2

The trader moves from direct to indirect participation to the CCP and changes settlement agent

using the one used by the GCM

CONSEQUENCES

SCENARIO 1





the same




68


o issuer


SCENARIO 2




The "new" general clearing member has a full view of the trader's balances, by

interfacing directly with the CCP

The "replaced" general clearing member can no longer view its own transaction

balances


o settlement agent





o issuer


o settlement agent



COMBINED SCENARIO

SCENARIO 1

The trader changes settlement agent

The trader moves from an indirect participation to the CCP to a direct one

SCENARIO 2

The trader moves from an indirect participation to the CCP to a direct one

CONSEQUENCES

SCENARIO 1





69


o settlement agent





o issuer


o settlement agent


SCENARIO 2



the same

The "replaced" GCM, can no longer view the trader’s balances






o issuer



SCENARIO

The trader continues to participate directly in the settlement system

The trader changes the general clearing member that is also the GCM settlement agent

CONSEQUENCES

The trader's settlement agent, which continues to coincide with the trader itself, can

view all its own transactions






o settlement agent

70


o counterparty



o issuer

o settlement agent



SCENARIO

The trader changes the settlement agent and general clearing member that are the

same entity

CONSEQUENCES



role as general clearing member settlement agent



above)


o settlement agent





o issuer

o settlement agent



SCENARIO

The trader changes the settlement agent that is also a general clearing member. The

settlement agent uses different accounts

CONSEQUENCES


71


role as general clearing member settlement agent



above)


o settlement agent





between trader and its general clearing member);

o settlement agent


o counterparty



o issuer

o settlement agent



SCENARIO

The settlement agent changes but not the participation procedures to the CCPs (direct)

CONSEQUENCES




o settlement agent



o settlement agent


72


COMBINED SCENARIO

SCENARIO 1

The general clearing member changes maintaining the current settlement agent

SCENARIO 2

Both the general clearing member and the settlement agent change

CONSEQUENCES

SCENARIO 1



The "old" general clearing member can no longer view the trader's transactions

The general clearing member and trader settlement agent continues to have the same

visibility over the existing transactions compared to the pre-variation situation seeing as

the settlement agent has remained the same



o code of the subject issuing the transaction


SCENARIO 2

The "old" trader and general clearing member settlement agent can no longer view the

trader’s transactions

The "new" trader and general clearing member settlement agent can view all the


The "new" general clearing member can view the trader's transactions seeing as the




o settlement agent





o issuer

o settlement agent


73


COMBINED SCENARIO

SCENARIO 1

The general clearing member changes maintaining the current settlement agent that uses two

different accounts for the trader and the GCM

SCENARIO 2

Both the general clearing member and the settlement agent change and the settlement agent

uses two different accounts for the trader and the GCM

CONSEQUENCES

SCENARIO 1

The "new" general clearing member can view the trader's transactions seeing as the


The "old" general clearing member can no longer view the trader’s transactions

The general clearing member and trader settlement agent continues to have the same

visibility over the existing transactions compared to the pre-variation situation seeing as

the settlement agent has remained the same


transaction



o counterparty




o issuer

o settlement account (in certain instances)

SCENARIO 2

The "old" trader and general clearing member settlement agent can no longer view the


The "new" trader and general clearing member settlement agent can view all the





74


o settlement agent






o settlement agent


o counterparty



o issuer

o settlement agent


75

7 T2S USER TESTING & MIGRATION TESTING

7.1 Introduction

The purpose of this chapter is to provide a general overview of the different phases of the User

Testing and Migration Testing that require the involvement of the clients (ICP and/or DCP).

7.2 User Testing: actors involved

The following tables propose a list of actors involved in the preparation and performance of the

User Testing phase with specific indications of the commitment made by each of mentioned

actors.

SUBJECT COMMITMENT

Eurosystem Management of the User Testing preparation phase

Coordination and support of User Testing implementation

CSD

Central Banks

Participation in the User Testing preparation phase

Active participation in the implementation of the different test phases

Coordination of the testing activities (preparation and implementation)

with the respective Communities

CSD Participant

Payment Bank

Active participation in the process of the test phases related to the

Community and to the Business Day

76

7.3 User Testing

The T2S User Testing requires the implementation of five different testing phases.

With reference to the testing phases described above, it should be noted that the participation of

the clients is required from the Community phase.

During Community and Business Day testing the clients are required to carry out tests

according to the Test Plan.

77

In particular, during Business Day testing, the clients are required to participate in the Migration

Weekend Dress Rehearsal and, for the following three days, must operate in the testing

environment as if they were operating in production.

The new test environments that Monte Titoli has set up for the performance of the tests and for

the static data migration in the production environment (with their related timing) are briefly

outlined below:

Legacy MT

environment

T2S

environment Notes

Available

from

Available

until

T2 Interoperability Used exclusively by Monte

Titoli 11/06/2015

T2 Pre-Prod.

Available for Monte Titoli’s

clients as a new pro-

production environment

replacing PI.

12/06/2015 Open date

T1 Community

Used by Monte Titoli and by

the clients for connectivity and

functional testing during the

Community and Business Day

testing phases.

05/01/2015 11/06/2015

T1 Production

Used by Monte Titoli and by

the clients to migrate to T2S

production in (Migration Week

End) and the subsequent BAU

activities.

12/06/2015 Open date

T3 n.a.

Used exclusively for the

management of static

production data via the web

platform.

Accessible only via Internet.

15/12/2014 20/03/2015

T3 Production

Connected to the T2S

production environment to

enable the migration of static

data.

21/03/2015 11/06/2015

78

7.4 Migration Testing

Migration Testing is divided into the same phases as the User Testing program. The clients are

not involved in the Bilateral and Multilateral migration testing phase.

The purpose of the Migration Testing phase is to ensure that the CSDs and the CBs involved in

the first migration wave to T2S and the respective financial communities are actually ready to

migrate their legacy systems in the new T2S platform, complying with the deadlines and the

synchronisation points define at community level and bilaterally between Monte Titoli and its

clients.

During the migration testing phase the different entity involved, consistently with their role, are

required to:

verify that the tools, queries and additional reports required for the T2S migration phase

are ready to support migration to T2S;

carry out the uploaded data relative to the pre-migration and migration activities with the

aim of ensuring that the these data is complied with the T2S standards;

check of the data already migrated onto the new platform through the reconciliation

reports;

check that the sequence of activities to be carried out during both the pre-migration and

actual migration phases is appropriate and correctly understood by all actors involved;

check that the planned activities may be carried out in compliance with the final

timetable, particularly during the migration to T2S weekend;

check the appropriateness of the contingency processes and procedures.

For more details reference should be made to the documentation reported below:

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

79

8 MANAGEMENT OF ACCESS RIGHTS IN T2S (only for DCP)

Before getting down to the technical explanation of the procedures and logic behind the access

right to the T2S allocation and management process, it is worthwhile to specify that if the client

decides to opt for a direct connection to the T2S platform, it is required to manage dedicated

preparatory activities related to access right allocation in T2S.

The latter consists of a series of actions summarised below and reported in the table under

heading 4.1: Plan of the activities and Pre-migration Synchronisation Points:

1. The DCP client is required to request Monte Titoli to set up and grant the access for an

administrator user. The administrator user will then be responsible to assign the

privileges internally.

Conversely, the DCP client has to request their Central Bank the grant of an

administrator user for the management of all access rights related to the role assigned

to National Central Banks.

2. The DCPs are required to carry out the registration process with the Network Service

Providers. Indeed, each DCP participant that takes part in a specific migration wave has

to complete the special registration with the NSPs through their respective CSD/CB for

the test environment.

3. The DCP clients must request specific certificates/tokens for access to the T2S system

according to criteria and rules set up by the NSP chosen by the client.

It should be noted that the following paragraph only concerns the DCP clients.

Indeed the clients that opt for an indirect (ICP) connection to the T2S platform via Monte

Titoli are not required to carry out any activity related to the management of access rights to

the T2S platform.

In light of the above, the ICP clients can consider the content of this chapter for purely

descriptive and knowledge improving purposes.

80

8.1 Introduction to management of access rights to T2S

The management of the access rights allocation process in T2S follows the hierarchic structure

of the Party Model established by the new T2S platform.

Indeed, the T2S Party organization is developed according to a hierarchic structure that

envisages three different levels, where it may be distinguished between:

1st level party, meaning the T2S Operator at the head of the hierarchic structure;

2nd level party, meaning the CSDs and the CBs;

3rd level party, meaning the clients of the CSDs (CSD participants) and the clients of the

CBs (Payment Banks).

The process to grant roles and privileges follows the hierarchic structure described in the

diagram above, on the basis of which each entity is responsible for the allocation of roles and

privileges to the users that belong to the categories at a lower level in the structure itself.

In light of the above, the T2S Operator is directly responsible to grant roles and privileges to the

CSDs and CBs, which, in their turn, shall grant the new roles and privileges to the CSD

Participants and the Payment Banks.

8.2 Main concepts and de finitions

In order to facilitate an understanding of the mechanisms behind the allocation of roles and

privileges, we provide a list of the main concepts and definitions on which the management of

access right to T2S is based.

81

8.2.1 User Function

The XML messages and GUI functionalities represent the procedures by which the user may

interact with T2S, either in the A2A or U2A modes.

Based on the set of XML messages and the functions offered by the GUI, a set of «T2S user

functions» may be defined for the users (e.g. sending a settlement instructions, creating a Party,

etc.), both in A2A and U2A mode.

8.2.2 Privileges

A privilege identifies the capability of triggering different «T2S user functions» and represents a

basic element to assign access rights to users. Depending on the application environment,

distinctions may be done between the following privileges:

System Privileges: refer to the «T2S user functions» that do not apply to specific static

or dynamic data (for example: a query on the current phase of the settlement day);

Object Privileges: refer to the «T2S user functions» that apply to a specific static or

dynamic data ( e.g. user function to display the reference data of a securities account).

The system privileges are assigned basing on a top-down approach, as shown in the graphic

representation provided below:

The object privileges, unlike the previous category, are assigned on the basis of a top-down

and/or transverse approach:

82

8.2.3 Secured Object

A "secured object" is a static data object (party, security, securities account and T2S DCA) on

which a specific privilege-object is granted.

8.2.4 Secured Group

A «secured group» is a homogeneous group of «secured objects» (for example: a group of

parties or securities accounts).

8.2.5 Role

A role is a set of privileges.

8.2.6 User

A user is an individual or an application that interact with T2S triggering the «T2S user

functions».

8.2.7 Data Scope

Given the hierarchic structure defined by T2S and described in the introduction, T2S defines the

so called default data scope for each individual privilege, meaning the established set of static

or dynamic data to which the individual user may apply the T2S functions. In particular:

The Users of the T2S Operator have visibility on all static and dynamic data object and

can act on a objects only in exceptional circumstances and on the basis of specific

agreements with the participant in question;

c

83

The Users of the CSDs and the CBs users have visibility on all static and dynamic

data belonging to the same system entity;

The User of the CSD participant and User of the Payment Banks have visibility on

static and dynamic data that is directly or indirectly linked to the same Party.

From the graph provided below it can be seen how users X, Y and Z (placed on a different

hierarchic level of the Party Model in T2S) fall within a different default data scope. In particular:

User X, being a participant of the CSD Part. B acquires by default the data scope of the

CSD Part .B. It should be noted that the data scope also includes the SAC2 as it is the

only securities account of the CSD Part. B. User X does not send settlement

instructions that refer to other securities accounts on T2S;

User Y of the CSD1 acquires by default the data scope marked within the blue area that

includes the SAC1 and SAC2 securities accounts seeing as these securities accounts

belong to the CSD participant (thus CSD Part.A and CSD Part.B) of the CSD1.

User Y may not send settlement instructions that refer to other securities accounts in

T2S that are not included within the above data scope (see the blue area in the graph);

User Z of the T2S Operator, being the first level of the hierarchic structure of the Party

model in T2S, acquires by default the data scope (green area) that includes all

securities accounts loaded on T2S.

84

The default data scope may be extended or reduced depending on the specific business

requirements.

The two next paragraphs provide two examples of both extension and reduction of the default

data scope.

EXTENSION OF THE DEFAULT DATA SCOPE

The following graph shows how user X (the client of CSD Part.B) acquires by default the data

scope of the CSD Part.B, including all the securities accounts that are part of the mentioned

area (in this case the SAC2). Due to the extension of the data scope, the same user X also sees

the predefined range of static or dynamic data extended even to securities account 5 (SAC5).

REDUCTION OF THE DEFAULT DATA SCOPE

The following graphs show how user X, meaning the client of CSD Part. D, acquires by default

the data scope of the CSD Part.D, including all the securities accounts that are part of the

mentioned area (in this case SAC4 and SAC5). Due to the reduction of the data scope, the

same user X also sees the predefined range of static or dynamic data reduced to the sole

securities account 4 (SAC4) and can no longer view the securities account 5 (SAC5)

85

8.3 Configuration of the access rights in T2S

Below we provide a brief description of the principles for the allocation of roles and privileges to

the different T2S Actors.

8.3.1 Users configuration

LINK BETWEEN USER AND PARTY

Each new user is directly linked to its Party. In fact, through the direct link to the interested

Party, each user inherits a default scope data of the Party with which it is associated.

However, there are specific situations that constitute exceptions to the general rule previously

described, such as for example:

The “T2S Administrator” creates a new administrator for a CSD and a CB;

The administrating subject of a CSD creates a new administrator for one of its

participants;

The administrating subject of a CB creates a new administrator for one of its payment

banks.

It is worthwhile to specify that the link between the user and its Party cannot be changed.

86

PARTY ADMINISTRATOR

Each Party must have at least one "Party administrator", meaning a user to which privileges are

granted with the possibility, in its turn, to reassign them to users and subjects that are included

within its default data scope.

8.3.2 Privileges configuration

Each privilege, subsequent to its first creation, is available solely and exclusively for the T2S

Operator administrator. This implies that the administrators of all the other Parties besides the

T2S Operator may not, in their turn, grant mentioned privileges to their users.

A privilege becomes available for other administrating entities besides the T2S Operator

administrator only once the privilege has been granted to the relative reference Party.

Subsequently, each individual Party administrator can, in their turn, grant the relative privileges.

Given the above, the process takes place in two phases:

1. STEP 1: privilege granted to the CSD and CB T2S Operator. Thus the same is available

to the CSD/CB administrator only;

2. STEP 2: privilege granted by a CSD/CB administrator to its own users (CSD/CB vs.

CSD Participant/CB).

8.3.3 Roles configuration

The roles may be assigned to other roles, users and participants.

It should be noted that the role assignment process in T2S (supported by the RBAC1

hierarchical model described in the UDFS document of T2S) is closely linked to the privilege

concept. In fact:

Since a user is granted a role, such entity inherits all the privileges assigned to that

specific role;

Since a Party is granted a role, the same Party inherits all the privileges assigned to

that specific role.

According to the same assignment process for one specific role, the same may be removed

from other roles, users and parties.

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

87

Indeed, conversely compared to what has so far been described, when a role associated to a

user or Party is removed, as a consequence the latter loses all privileges associated with the

role in question.

8.4 Access rights allocation process in T2S

Before the party administrator of a given party can grant a privilege to a user of the same party,

the same privilege has to be granted to the same party, so that it becomes available to the party

administrator (s) of the party.

Given the above, the following diagram shows the steps required to allocate the privilege P to

the users of a CSD or CB (meaning Party A).

In particular, as can be seen from the above graph:

1. The user X, being a T2S Operator Party Administrator, has the right to grant privilege P

to Party A;

2. User Y, being the Party Administrator for Party A, in its turn, has the right to grant

privilege P to all users that belong to the same hierarchic level (meaning User Y1 and

User Y2).

The same process is applied each time a CSD or a CB should proceed with the assignment of

the respective roles and privileges to its participants (the CSD participant and the Payment

Bank).

88

The following graph shows the steps required for the assignment of the privilege P by the CSD

to the CSD participants and by the CB to the Payment Banks:

The graph shows the three different steps which must be followed for the allocation of the

privilege P:

1. The user X, being a T2S Operator Party Administrator, has the right to grant privilege P

to Party A (meaning to CSD or CB);

2. User Y, being the Party Administrator for Party A, in its turn, has the right to grant

privilege P to Party B (meaning CSD participants or Payment Banks);

3. User Z, being the Party Administrator for Party B, has the right to allocate privilege P to

its users (in the example above Z1 and Z2).

It should be noted that User Y1, being party administrator for Party A, can be assigned the

privilege P to users Y1, provided that they belong to the same Party.

Given the above, it should be noted that the access rights configuration process in T2S may be

triggered at the party level or at the single user level.

8.4.1 Access rights at Party level

For all that concerns the configuration of access rights at Party level, it should be noted that the

administrator of the T2S Operator is the person whose duty is to assign the set of predefined

roles and privileges to the CSD and the CB.

The following graph provides an example:

89

Subsequently, the administrator (s) Party for each CSD and CB, as a consequence, has the

possibility of propagating a predefined set of roles and privileges to all its participants, whether

they are CSD participants or Payment Banks.

90

8.4.2 Access rights at user level

Following the configuration of access rights at Party level, each individual party administrator, in

its turn, can grant access rights to individual users, assigning the appropriate roles and

privileges to all users that belong to the same Party.

8.5 Decentralised management of access rights in T2S

As previously described, the management of access rights in T2S totally reflects the model of

the relationship existing between the parties in T2S, developed and distributed over three

different hierarchic levels.

We have come up with a diagram below which sums up the main activities charged to the T2S

Operator, CSD/CB and CSD Participant/PB relative to the management of access rights, in line

with the hierarchic and decentralised Party structure in T2S.

91

For more information reference should be made to the ECB documentation after the workshop

held last July 2012 in Frankfurt regarding the management of access rights:

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

For additional and more detailed information you are invited to consult the technical

documentation made available by the ECB in the ad-hoc section on website. In particular:

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





92

9 ATTACHMENT A – DETAILS OF STATIC DATA FOR T2S

9.1 Introduction

This chapter aims to inform clients (DCP and ICP) on the set of information required by Monte

Titoli for T2S set-up, with the indication of the corresponding migration procedures and rules

adopted by Monte Titoli.

Please note that the configuration details will be discussed in the web tool user guide for static

data configuration.

In order to rationalise the set of data configuration supplied by Monte Titoli to its clients, the set

of data has grouped according to the following logical criteria.

1. Information on Parties in T2S

2. Information on the Technical Address network service link

3. Trader/Settlement agent link and relative settlement accounts (LIQDEF)

4. Trader/General Clearing Member/Settlement agent link for the General Clearing

Member (CCPNEG).

5. Market exception to the Trader/Settlement agent Association (LIQNEG)

6. Account structure for the Centralised Administration Service

7. Account details for the cash settlement of DVP transactions

8. Account details for settlements relating to corporate actions in T2S

9. Account details for payments relating to corporate actions in T2 with the indication of

the configuration elements required if a subject uses or does not use a bank through

T2.

Finally, in order to facilitate the reading of the tables shown, we provide below a short

description of the various columns of the tables in question, which have been ordered as

follows:

“N.” = order number for the data;

"Column name" = name of the data or of the column;

"Format" = format of the data or of the column;

"Description" = description and meaning of the data /column;

"Comments" = any additional or required comments. It does not apply to the first two

tables;

"Existing data in MT [AS-IS]” = refers to any data currently found in the Monte Titoli

systems with the specification of the mapping rules and of the method for their

translation into T2S.

93

In particular:

o The value "X" indicates that the value relative to the data is currently available

in the Monte Titoli legacy systems

o The value "n.a." indicates that the value relative to the data is not present in the

Monte Titoli systems, but it is specific to the new T2S platform.

"New Data in T2S", which may be:

o "assigned by default by MT" = value assigned by default by Monte Titoli during

the migration phase;

o "Mandatorily supplied by the clients" = the value to be provided by the client.

If the data is not provided by the client, Monte Titoli cannot go ahead with the

migration process.

In particular, we provide below the meaning of the three options contained in the

column "New Data in T2S":

o "n.a": when the data is assigned by default by Monte Titoli and there is no

possibility of change by the client;

o "possible amendment admitted": the data is assigned by default by Monte Titoli,

but the client can change the field, modifying the value proposed by Monte

Titoli;

o "mandatory": when the data, that is not part of a set of information known by

Monte Titoli, must necessarily be communicated by the client. This is the "new"

information that is usually requested by the introduction of T2S (for example:

indication of the Network Service, DCA account identification, CMB

identification, etc...).

It should be noted that the rows highlighted in "yellow" indicate that the content is included in the

preceding tables/diagrams and that, as a consequence, the considerations regarding the

values to be assigned or already assigned do not apply seeing as they have already been dealt

with.

All the rows highlighted in yellow in a table constitute the only information that may be replaced

completely if it has already been inserted.

94

9.2 Party

The table below contains the set of information required by Monte Titoli for the client set-up and that refer to the new concept of PARTY

specific of the new T2S platform.

New data in T2S

N. Column Name Format Description Existing data in MT

[AS-IS]

Assigned by default

by MT

Mandatorily provided by

the clients

1 Parent BIC CHAR (11) BIC of the System Entity

responsible for the Party X MOTI IT MM XXX n. a.

2 Participant type

Possible values:

CSDP

ECSD

Party classification:

CSDP = CSD Participant

ECSD = External CSD

X Values assigned by

default by Monte Titoli n. a.

3

Opening date

DATE

Party activation date. The

latter must necessarily be

greater or equal to 27/04/2015

X Date set by Monte

Titoli at 27/04/2015

Possible changes admitted

if the Party assigned by

default by MT does not

coincide with client

requirements and must

therefore be changed

95

4 Closing date DATE

Time from which the Party is

no longer deemed active. The

latter must necessarily be

greater than the opening date.

X Null


for the reasons outlined

above

5 Party BIC CHAR (11) PARTY BIC X Value assigned by

default by MT


based on the requirements

of the CMB setup and/or

matching.

In any case at least a value

of some kind must be

present

6 Long Name VARCHAR (350) Extended indication of the

Party name X

Existing value in MT

assigned on the basis

of the name of the

Legal Entity

n.a.

7 Short Name VARCHAR (35) Short indication of the Party

name X

Existing value in MT

assigned on the basis

of the name of the

Legal Entity

n.a.

8 Address VARCHAR (70) Party address X

96

9 House number VARCHAR (16) Specific indication of the house

number referred to the Party X

Value existing in MT

n.a.

10 Post code VARCHAR (16) Party Post code X

11 City VARCHAR (35) Indication of the Party's City X

12 Province or

State VARCHAR (35)

Indication of the Party's

Province or State X

13 Country Code CHAR (2) Indication of the Country Code X

14 Technical

Address VARCHAR (256)

Applies only to DCP clients.

Indication of the party's

technical address

(distinguished name)

n. a.

Value initially inserted

by Monte Titoli with a

fictitious value such as

"value to be assigned"

The ICP clients are not

required to insert/change

anything in this data item.

Mandatory for DCP clients

only. This is a new data

item specific to T2S to

enable the direct

connection to the T2S

platform

97

9.3 Technical address network service link

The following table is only of interest to DCP clients. The ICP clients may ignore all that is here described for the purpose of their

migration to T2S. It should be noted that the table shown in chapter 9.2, under heading 14, reports the information referred to the

"Technical Address".

The information elements included in fields 3 and 4 of the following table enable the link between a technical address and the

corresponding network service provider of the client uses.

New data in T2S

N. Assigned by

default by MT

Assigned by default

by MT Description

Existing data in

MT

[AS-IS]

Assigned by default

by MT

Mandatorily provided

by the clients


responsible for the Party X

See table 9.2 Party 2 Party BIC CHAR (11) Party BIC X

3 Technical

Address VARCHAR (256)

Indication of the Party's

technical address

(distinguished name)

n. a.

4 Network

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

98

9.4 Trader/Settlement agent link and relative settlement accounts: (LIQDEF)

New data in T2S

N. Column Name Format Description Comments

Existing

data in MT

[AS-IS]

Assigned by

default by MT

Mandatorily

provided by the

clients

1 Settlement system

Settlement system

One of the

following values

may be assigned:

T2S: if the

gross and net

configuration in

Express II

coincide

Net: for net

configuration

Gross: for

gross

configuration

Currently an entity

may hold 2 different

setup in X-TRM, one

for gross and one for

net settlement, but

only one is admitted.

X n.a.

Where "Net" and

"Gross" values

are provided it is

expected that

one of the two

be closed

99

2 Negotiation type

Indication of the

type of negotiation

May take on one of

the following

values:

P

T

BLANK=if P

and T are valid

at the same

time

X Assigned by

default by MT

Possible

changes

admitted

3 Trader’s BIC code Indication of the

trader's BIC code

This information will

be supplied by MT if it

exists in its own

archives

X

Values

assigned by

default by MT

n.a.

4 Trader’s CED code Indication of the

trader's CED code X

Values

assigned by

default by MT

n. a.

5 Settlement agent’s

BIC code

Indication of the

Settlement agent's

CED code

X

Values

assigned by

default by MT

Possible

changes

admitted

100

6 Indicator of default

settlement agent

The indication of

the Flag (YES/NO)

enables to identify

if the settlement

agent is the default

one or not.

X

Values

assigned by

default by MT

Possible

changes

admitted 7

Start of settlement

agent link

Indication of the

date on which the

association of the

trader with the

settlement agent

begins

It should be noted that

the date is always the

settlement date (SD)

X

8 End of settlement

agent link

Indication of the

date on which the

link of the trader

with the settlement

agent ends

It should be noted that

the date is always the

settlement date (SD)

X

9 Settlement account

code

Indication of the

settlement account

code according to

CSD coding

X

Identification

of the account

assigned by

MT

Possible

changes

admitted

10 Indicates whether X

101

Default account

indicator

the settlement

account is the

default one or not

for that particular

combination of

Negotiation

Type/Settlement

agent

Values

assigned by

default by MT

Possible

changes

admitted

11 Start of account

association

Indication of the

date on which the

account link begins

X

12 End of account

link

Indication of the

date on which the

account link ends

X

102

9.5 Trader/GCM/GCM Settlement agent link (CCPNEG)

New data in T2S


Existing

data in MT

[AS-IS]

Assigned by

default by

MT

Mandatorily

provided by

the clients

1 Settlement

system

Settlement system

One of the following

values may be

assigned:

T2S: if the

gross and net

configuration in

Express II

coincide

Net: for net

Currently an entity

may hold two

different setup in X-

TRM, one for gross

and one for net

settlement, but only

one is admitted.

X n.a.

See 9.4: Default

Trader/Settleme

nt agent link

and relative

settlement

103

configuration

Gross: for

gross

configuration

accounts:

(LIQDEF)

2 Negotiation type

Specification of the

"owner" or "third

party" negotiation

type

X

Values

assigned by

default by MT

3 Trader’s BIC

code

Indication of the

trader's BIC code X

Values

assigned by

default by MT

4 Trader’s CED

code

Indication of the

trader's CED code X

Values

assigned by

default by MT

5 Provenance Indication of the

market provenance X

Values

assigned by

default by MT

Possible

changes

admitted

6 Negotiation

market

Indication of the

negotiation market X

Values

assigned by

default by MT

Possible

changes

admitted

7 CCP CED code Indication of the X Values Possible

104

CCP CED code assigned by

default by MT

changes

admitted

8

General clearing

member's CED

code

Indication of the

general clearing

member's CED

code

X

Values

assigned by

default by MT

Possible

changes

admitted

9

GCM settlement

agent’s CED

code

Indication of the

GCM settlement

agent's CED code

X

Values

assigned by

default by MT

Possible

changes

admitted

10 Settlement

account code

Indication of the

settlement account

code

X

Values

assigned by

default by MT

Possible

changes

admitted

11 Validity start

date

Indication of the

start date for

validity

X

Possible

changes

admitted

12 Validity end date Indication of the

end date for validity X

Possible

changes

admitted

105

9.6 Market exception to the Trader/Settlement agent Association (LIQNEG)

New data in T2S


Existing data

in MT

[AS-IS]

Assigned

by default

by MT

Mandatorily

provided by

the clients

1 Settlement system

Settlement system

One of the

following values

may be assigned:

T2S: if the

gross and net

configuration in

Express II

coincide

Net: for net

configuration

Gross: for

gross

configuration

Currently an entity

may hold two

different setup in X-

TRM, one for gross

and one for net

settlement, but only

one is admitted.

X n.a.

9.4 Table:

Default

Trader/Settle

ment agent

link and

relative

settlement

accounts:

(LIQDEF)

2 Negotiation type Specification of the X Values

106

type of negotiation assigned by

default by

MT

3 Trader’s BIC code Indication of the

trader's BIC code X

Values

assigned by

default by

MT

4 Trader’s CED code Indication of the

trader's CED code X

Values

assigned by

default by

MT

5 Settlement agent’s

CED code

Indication of the

Settlement agent's

CED code

X

Values

assigned by

default by

MT

6 Settlement account

code

Indication of the

settlement account

code according to

CSD coding

X

Identification

of the T2S

account

assigned by

MT

7 Provenance Indication of the

market provenance X

Values

assigned by

Possible

changes

107

default by

MT

admitted

8 Negotiation market Indication of the

negotiation market X

Values

assigned by

default by

MT

Possible

changes

admitted

9 Validity start date

Indication of the

start date for

validity

X

Values

assigned by

default by

MT

Possible

changes

admitted

10 Validity end date

Indication of the

end date for

validity

X

Values

assigned by

default by

MT

Possible

changes

admitted

108

9.7 Account structure for the Centralised Administration Service

New data in T2S


Existing data

in MT

[AS-IS]

Assigned

by default

by MT

Mandatorily

provided by

the clients



MOT IT MM

XXX

See 9.2 Table

Party 2 Party BIC CHAR (11)

Indication of the Party

BIC to which the

account is linked

X

Value

assigned by

default by

MT

3 Intermediary’s ABI

code

Indication of the ABI

code for the

intermediary of the

Securities account

X

Value

assigned by

default by

MT

n.a.

4 T2S Account ID Identification code for

the T2S account n.a.

Value

assigned by

default by

MT

No changes

admitted

5 Account code Identification of the X Value n.a.

109

Securities Account

according to ABI coding

assigned by

default by

MT

6 Role


entities operating scope.

May take on one of the

following roles:

issuer

broker

X

Value

assigned by

default by

MT

n.a.

7 Account type

Indication of the type of

account.


following values:

P: owned

T: third party

L: settlement agent

X

Value

assigned by

default by

MT

Changes

possible but

not expected

8 Collateral Account

type


collateral account.


following values:

G: giver

X

Value

assigned by

default by

MT

n. a.

110

R: receiver

The type of collateral

account depends on

participation in X-COM

and is assigned in

accordance with the

current configuration

9 Securities Account

opening date

Indication of the opening

date for the securities

account

It must

necessarily be

greater or equal

to 27/04/2015

X

Value

assigned by

default by

MT

Possible

changes

admitted

10 Securities Account

closing date

Indication of the closing

date for the securities

account

It must

necessarily be

subsequent to

the securities

account opening

date

X Null

No changes

are expected

unless the

securities

account is

closed after

the go-live

date

11 Operating block


following values:

S = yes

The accounts

with an operating

block, regardless

X

Value

assigned by

n.a.

111

N = no of whether they

are balanced or

not, will be

defined and

configured at the

T2S level

default by

MT

12 Hold/Release

Indicator

Indication of the Hold

and Release indicator.


following values:

H = Hold

R = Released

n.a. RELE

Possible

changes

admitted

112

9.8 Account details for the cash settlement of DVP transactions

New data in T2S


Existing data

in MT

[AS-IS]

Assigned by

default by

MT

Mandatorily

provided by the

clients



See 9.7 Table Account structure

for the centralised administration

service

2 Party BIC CHAR (11)


BIC to which with the

account is associated.

X


the T2S account X

4 ABI code of the

intermediary


code of the owner of the

Securities account

X

5 Account code

Identification of the

Securities Account


X

113

6 Account type


account.


following values:

P: owned

T: third party

L: settlement agent

X

7 Role


subjects operating

scope. May take on one

of the following roles:

issuer

broker

X

8 ABI Code of the

cash agent


code of the cash agent if

it is also a Monte Titoli

participant

X

Value

assigned by

default by

MT

n.a.

9 CB Parent BIC CHAR (11) Indication of the BIC of

the Party’s CB owner

n.a.

n.a.

The

information

The client is

compelled to 10 PB Party BIC CHAR (11) Indication of the BIC of n.a.

114

the PB owner of the

DCA account

relates to the

T2S

identification

for the DCA

(which is

based on two

levels: BIC of

the CB+BIC

of the PB] is

not available

on MT

supply the T2S

DCA

identification on

two levels (BIC

of the CB+BIC

of the PB) and

the PB must

confirm

11 DCA account

identification

The T2S identification

element of the DCA that

is used for the payments

in association with the

securities account

n.a.

n.a.

The

information

relates to the

T2S

identification

for the DCA

(which is

based on

two levels:

BIC of the

The client has to

provide the T2S

DCA

identification on

two levels (BIC

of the CB+BIC of

the PB) and the

PB must confirm

115

CB+BIC of

the PB] is

not available

on MT

12 CMB

identification


element of the Credit

Memorandum Balance

assigned by the DCA

owner that is used for

the payments in

association with the

securities account

n. a.

n. a.

The

information

relative to

the T2S

identification

for the CMB

is not

available on

MT

The client have

to provide the

T2S identifying

code for the

CMB

13 Default Link BOOLEAN

Indication of the default

link. Takes on a "true"

value when the DCA

account is used as a

default account for cash

It is underlined

that for a given

securities

account there

may be one and

only one default

n. a. n. a. Mandatory

116

settlements in T2S link to a DCA

account, all links

with other DCAs

will NOT be

default ones

14 Link validity start

date

Indication of the link

validity start date n. a. 22/06/2015 Mandatory

15 Link validity end

date

Indication of the link

validity end date n. a.

No value

means the

date is open

n.a.

16 Collateralisation

Link BOOLEAN

If it takes on a "true"

value, T2S may use this

securities account for

auto-collateral

transactions by

providing all other

required conditions

X

Assigned by

MT on the

basis of the

current self-

collateralizati

on flag

Possible

changes

admitted

17 Cash Settlement

Link BOOLEAN

If it takes on a "true"

value, T2S may use this

link between the

securities account and

the T2S DCA for the

X

Value

assigned by

default by

MT

Possible

changes

admitted

117

settlement of the cash

leg of the settlement

instruction.

118

9.9 Account details for payments related to corporate actions in T2S

In order to facilitate the client’s set-up activities, this table will be populated with non-significant predefined values that the client must

replace with significant values.

New data in T2S


Existing

data in MT

[AS-IS]

Assigned by

default by

MT

Mandatorily

provided by

the clients



See Table 9.7 Account

structure for the centralised

administration service



BIC to which the

account is linked

X


the T2S account X

4 ABI code of the

intermediary


code of the subject that

is the owner of the

Securities account

X

5 Account code Identification of the X

119

Securities Account,


6 Account type


account.


following values:

P: owned

T: third party

L: settlement agent

X

7 Role


subjects operating



issuer

broker

X

8 CB Parent BIC CHAR (11) Indication of the BIC of

the Party’s CB owner

n.a.

The

information

relates to the

T2S

identification

The client has

to provide the

T2S DCA

9 PB Party BIC CHAR (11)

Indication of the BIC of

the PB owner of the

DCA account

n.a.

120

10 DCA account

identification

The T2S identification of

the DCA that is used for

the payments in

association with the

securities account

n.a.

for the DCA

(which is

based on two

levels): BIC of

the CB+BIC

of the PB] not

available on

MT that

therefore

assigns a

fictitious value

"to be

defined"

identification

on two levels

(BIC of the

CB+BIC of

the PB) and

the PB must

confirm.

The client has

to provide the

T2S DCA

identification

on two levels

(BIC of the

CB+BIC of

the PB) and

the PB must

confirm

11 CMB identification


of the Credit

Memorandum Balance

assigned by owner of

the DCA that is used for

payments in association

n. a.

n. a.

The

information

on the T2S

identification

The client has

to provide

the T2S

identifying

121

with the securities

account

element for

the CMB is

not available

on MT that

therefore

assigns a

fictitious

value "to be

defined"

code for the

CMB

12 Transaction type


transaction type. Types

of payment available on

Monte Titoli:

capital increase and

exercising of

Warrant

payment of

dividends/fund

revenue

payment of

interests/reimburse

ment

The types of

payment refer

to those

currently

available with

MT following

the start of the

Custody

Harmonisation

project

Monte Titoli

only provides

the

"Payment of

Government

Bond"

payment

type seeing

as this

payment

must be

made

through T2S.

"Payment on

Government

Bonds"

Mandatory

122

payment on

securities in foreign

currencies

payment on

Government Bonds

13 Payment subject’s

ABI Code

Indication of payment

subject's BIC code.

Could be absent if the

payment subject is not

an MT participant

X n.a. n.a.

14 Start of validity

date

Indication of the start

date for validity of the

securities account/cash

account (DCA)

association to allow

management of

payments relating to CA

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

15 End of validity

date

Indication of the end

date for validity n. a.

No value

means the

date is open

n.a.

123

9.10 Payments related to corporate actions in T2

Remember that this data is already present on Monte Titoli as they have already been used for the standard management of payments

relating to Corporate Actions.

New data in T2S


Existing

data in MT

[AS-IS]

Assigned by

default by

MT

Mandatorily

provided by

the clients



See 9.7 Table: Account

structure for the centralised

administration service



BIC linked with the

account

X


the T2S account X

4 ABI code of the

intermediary


code for the

intermediary of the

securities account

X

5 Account code Identification of the

securities Account X

124


6 Account type


account.


following values:

P: owned

T: third party

L: settlement agent

X

7 Role


subjects operating



issuer

intermediary

X

8 Transaction type


transaction type. Types

of payment available on

Monte Titoli:

capital increase and

exercising of

Warrant

The types of

payment refer

to those

currently

available with

MT following

the start of the

X

n.a.

Possible

changes

admitted

125

payment of

dividends/fund

revenues

payment of

interests/reimburse

ments

payments of

securities in foreign

currencies

RCC fees

Custody

Harmonisation

project

126

ADDITIONAL CONFIGURATION ELEMENTS REQUIRED IF THE SUBJECT USES

AN INTERMEDIARY BANK IN T2

9 ABI of the Agent

Bank

Agent Bank ABI

code X n.a.

Possible

changes

admitted

10

ABI of the

Intermediary

Bank

ABI intermediary

bank code X n.a.

Possible

changes

admitted

11

Details of the

RTGS account of

the intermediary

bank

Details of the RTGS

Target2 accounts of

the intermediary

bank of reference

X n.a.

Possible

changes

admitted


date

Indication of the

start of validity date

of the securities

account to the cash

account

X n.a.

Possible

changes

admitted

127

13 End of validity

end date

Indication of the

validity end date of

the securities

account to the cash

account

Where no value is

shown the position

is to be considered

active. A value in

this field means that

one intends to close

the securities

account/cash

account link

X

ADDITIONAL CONFIGURATION ELEMENTS REQUIRED IF THE SUBJECT DOES NOT USE AN INTERMEDIARY BANK IN T2

14

Details of the

RTGS account of

the agent bank

Details of the RTGS

Target2 accounts of

the agent bank of

reference

X n.a.

Possible

changes

admitted

15 ABI of the Agent

Bank

Agent Bank ABI

code X n.a.

Possible

changes

admitted


date

Indication of the

validity start date of

the securities

account to the cash

X n.a.

Possible

changes

admitted

128

account

17 End of validity

date

Indication of the

validity end date of

the securities

account to the cash

account

Where no value is

shown the position

is to be considered

active. A value in

this field means that

one intends to close

the securities

account/cash

account link

X

129

10 Attachment B - Effects on the change of participation way to the CCP and/or change

of settlement agent on the transactions

In order to facilitate an understanding of the indications provided in chapter 6, please refer to

attachment B which provides the empirical evidence of the effects of the transaction data

resulting from the changes in CCP participation mode and/or a change of settlement agent

during migration to T2S.

11 Attachment C - DCP Access Rights

In the attachment we provide a detailed list of the access rights that Monte Titoli will provide to

its DCP clients.

Disclaimer Heading

This document contains texts, data, graphs, photographs, illustrations, projects, names, logos, registered

trademarks and service and information trademarks (collectively the "information") that refer to Monte Titoli S.p.A.

(“MT” or “the Company”). MT attempts to ensure the accuracy of the information, however the information is

provided as is and as available and may therefore be inaccurate or not updated. Depending on the circumstances,

the information contained in this document may or may not have been prepared by MT, but in any case they are

supplied with no assumption of responsibility by MT: The Company does not guarantee the accuracy, specificity,

completeness or appropriateness of this document or of the information for the achievement of specific goals.

No responsibility is acknowledged by MT for any mistake, omission or inaccuracy of the information contained in

the document. No action should (or should not) be taken by relying on the information contained in this document.

It is understood that there will be no liability for the consequences that may derive from any actions undertaken on

the basis of this information.

The Company promotes and offers Post Negotiation services based on fair, transparent and non-discriminatory

procedures and on the basis of criteria and procedures that ensure the interoperability, safety and equality of

processing between market infrastructures, to all subjects that may request them and are qualified to this end

according to national and community regulations and all current legislation as well as the rulings of all competent

Authorities.

Date post:	14-Aug-2020
Category:	Documents
Upload:	others
View:	7 times
Download:	0 times