MIGRATION PREPARATION SCHEDULE

(1)

MIGRATION PREPARATION

SCHEDULE

T2S PROJECT

(2)

(3)

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

(5)

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

(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 Weekend

MWEDR Migration Weekend Dress Rehearsal

NSP Network Service Provider

OTC Over the Counter

(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

(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-m igration phase Migration w eekend 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.

(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

Euroclear France SME CSD

Euroclear Netherlands SME CSD

Iberclear SME CSD

(13)

LuxCSD SME CSD

VP Securities SME CSD

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

Malta Stock Exchange Migrating CSD to T2S

Monte Titoli Migrating CSD to 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 Central Banks in T2S

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

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

(14)

Deutsche Bundesbank Migrating CB to T2S

NBB Migrating CB to T2S

Banque de France Migrating CB to T2S

De Nederlandsche

Bank Migrating CB to T2S

Banco de Espana Migrating CB to T2S

Banque centrale du

Luxembourg Migrating CB to T2S

Oesterreichische

Nationalbank Migrating CB to T2S

Danmarks

Suomen Pankki Migrating CB to T2S

(15)

Central Banks in T2S. Specifically as: “System Entity” and “RTGS System Owner”

Eesti Pank Migrating CB to T2S

Lietuvos Respublikos

centriniu banku Migrating CB to T2S

Magyar Nemzeti Bank Migrating CB to T2S

Narodna banka

Slovenska Migrating CB to T2S

3.4 Composition of the second wave

Euroclear Belgium Migrating CSD to T2S

Euroclear France Migrating CSD to T2S

Euroclear Netherlands Migrating CSD to T2S

Interbolsa Migrating CSD to T2S

NBB - SSS Migrating CSD to T2S Complete migration of the settlement system and all connected activities to

(16)

SUBJECT TYPE COMMENT T2S

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

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

De Nederlandsche

Bank Migrating CB to T2S

Play all the four different roles of Central Banks in T2S

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

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

Keler Hungary Migrating CSD to T2S

LuxCSD Migrating CSD to T2S

OeKB Migrating CSD to T2S

VP Lux Migrating CSD to 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 Central Banks in T2S

(17)

Luxembourg Central Banks in T2S

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

Oesterreichische

Performance of all four different roles of Central Banks in T2S

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

Iberclear Migrating CSD to T2S

AS Eesti

Vaartpaberikeskus Migrating CSD to T2S

CSD of Lithuania Migrating CSD to T2S

Euroclear Finland Migrating CSD to T2S

KDD Slovenia Migrating CSD to T2S

BNY Mellon CSD Migrating CSD to T2S

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

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

(18)

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

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

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 week end 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)

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

(22)

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)

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 The clients are invited to send their feedbacks to MT regarding the results of the

X X MT

From 21/05/2015

(24)

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 The clients are invited to send their 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)

(25)

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

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

(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 pre-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:

(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 t he 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 sy stem 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.

MIGRATION PREPARATION SCHEDULE