MIGRATION PREPARATION SCHEDULE

Transcription

1 MIGRATION PREPARATION SCHEDULE T2S PROJECT Version 1.0 1

2

3 Contents 1 DOCUMENT MANAGEMENT Document History Acronyms and abbreviations Reference documentation 7 2 PURPOSE OF THE DOCUMENT 8 3 OVERVIEW OF THE MIGRATION PROCESS TO T2S Migration planning Actors involved Composition of the first wave Composition of the second wave Composition of the third wave Composition of the fourth wave 17 4 MIGRATION ACTIVITY PLAN Activities and Synchronisation Points 19 5 MIGRATION OF STATIC DATA Introduction to the migration of static data Delivery to the clients of the data required for configuration in T2S Pre-settlement service data Settlement service data Cross-border settlement service data (DVP Cross-Border) Centralised administration service data (issuers and intermediaries) Client confirmation of the configuration of data supplied by Monte Titoli Transfer of the official configuration data in the test system Pre-Migration Dress Rehearsal 36

4 5.6 Frozen Period Go live for static data in T2S Contingency period for loading of static data 38 6 CHANGES IN THE PARTICIPATION METHODS AT MONTE TITOLI SERVICES Change of payment agent Change of the payment agent within the centralised administration service Change of the payment agent within the settlement service Change of the settlement agent and the type of registration to CCP Operating model "A" or Gross Margination Model Operating model "B" or Net Margination Model 54 7 T2S USER TESTING & MIGRATION TESTING Introduction User Testing: actors involved User Testing Migration Testing 78 8 MANAGEMENT OF ACCESS RIGHTS IN T2S (only for DCP) Introduction to management of access rights to T2S Main concepts and definitions User Function Privileges Secured Object Secured Group Role User Data Scope Configuration of the access rights in T2S Users configuration 85

5 8.3.2 Privileges configuration Roles configuration Access rights allocation process in T2S Access rights at Party level Access rights at user level Decentralised management of access rights in T2S 90 9 ATTACHMENT A DETAILS OF STATIC DATA FOR T2S Introduction Party Technical address network service link Trader/Settlement agent link and relative settlement accounts: (LIQDEF) Trader/GCM/GCM Settlement agent link (CCPNEG) Market exception to the Trader/Settlement agent Association (LIQNEG) Account structure for the Centralised Administration Service Account details for the cash settlement of DVP transactions Account details for payments related to corporate actions in T2S Payments related to corporate actions in T Attachment B - Effects on the change of participation way to the CCP and/or change of settlement agent on the transactions Attachment C - DCP Access Rights 129

6 1 DOCUMENT MANAGEMENT 1.1 Document History Date Version Details 09/04/ Italian version 30/05/ English version 1.2 Acronyms and abbreviations Name ATIE BAU BIC CB CCP CMB CMS CSD DCA DCP DV DVP ECB FIS FOP GCM GUI HW ICM ICP ISD MT MWE MWEDR NSP OTC PB Description Register of Blocked and Drawn Securities Business As Usual Bank Identifier Code Central Bank Central Counterparty Credit Memorandum Balance Collateral Management System Central Securities Depository Dedicated Cash Account Direct Connected Participant Value Date Delivery Versus Payment European Central Bank Standardized Information Flows Free of Payment General Clearing Member Graphical User Interface Hardware Individual Clearing Member Indirect Connected Participant Intended Settlement Date Monte Titoli Migration Weeke nd Migration Weekend Dress Rehearsal Network Service Provider Over the Counter Payment Bank 6

7 PMDR PMSP RBAC RCC RTGS SAC SME SNB SP SW T2S UDFS UHB VAN Pre Migration Dress Rehearsal Pre - Migration Synchronisation Point Role Based Access Controls Client Fee Settlement Real Time Gross Settlement Securities Account Securities Maintain Entity Net Bilateral Balance Synchronisation Point Software Target 2 Securities User Detailed Functional Specifications User Handbook Value Added Network 1.3 Reference documentation Reference document Instructions -TRM Instructions of CSD Service for intermediaries and Issuers Migration Weekend Playbook T2S User Detail Functional Specifications T2S User Handbook Source Documents of the T2S/MT Testing & Migration working group published in the appropriate documentary section of the MT- 3be45b2d0bf5a5afcf4de34f36 cc76cbb67593fe9e8b489e733a315bea 7

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

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 w eekend Stabilisation Phase 1 24 March June June June June July January March March March March April June September September September September October November February February February February March

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: It should be underlined that some Central Banks, as detailed in the tables below, will only perform some of the four roles previously outlined. 10

11 ACTORS Migrating CSD Migrating CB SME CSD CSD participant (DCP/ICP) Payment Bank (DCP/ICP) Network Service Provider (NSP) RTGS Operator DESCRIPTION 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). 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 CSDs that operate in T2S as SMEs, or "Securities Maintaining Entities" of the financial instruments for which they are the Issuer or Technical Issuer. 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. 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. 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" Operators of the RTGS system connected to the T2S platform, such as for example the "T2S Operator" 11

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): 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 CSD that operates exclusively as a "Securities Maintaining Entity" of the static data migrated into the T2S platform Euroclear France SME CSD CSD that operates exclusively as a "Securities Maintaining Entity" of the static data migrated into the T2S platform Euroclear Netherlands SME CSD CSD that operates exclusively as a "Securities Maintaining Entity" of the static data migrated into the T2S platform Iberclear SME CSD CSD that operates exclusively as a "Securities Maintaining Entity" of the static data migrated into the T2S platform 12

13 SUBJECT TYPE COMMENT LuxCSD SME CSD CSD that operates exclusively as a "Securities Maintaining Entity" of the static data migrated into the T2S platform VP Securities SME CSD CSD that operates exclusively as a "Securities Maintaining Entity" of the static data migrated into the T2S 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 Complete migration of the settlement system and all connected activities to T2S Malta Stock Exchange Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S Monte Titoli Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S SI 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 Play some of the four different roles of Banca Nationala a Central Banks in T2S. Specifically as: Migrating CB to T2S Romaniei System Entity and RTGS System Owner Play some of the four different roles of Banco de Portugal Migrating CB to T2S Central Banks in T2S. Specifically as: System Entity and RTGS System Owner 13

14 SUBJECT TYPE COMMENT Deutsche Bundesbank Migrating CB to T2S Play some of the four different roles of Central Banks in T2S. Specifically as: System Entity and RTGS System Owner NBB Migrating CB to T2S Play some of the four different roles of Central Banks in T2S. Specifically as: System Entity and RTGS System Owner Banque de France Migrating CB to T2S Play some of the four different roles of Central Banks in T2S. Specifically as: System Entity and RTGS System Owner Play some of the four different roles of De Nederlandsche Central Banks in T2S. Specifically as: Migrating CB to T2S Bank System Entity and RTGS System Owner Play some of the four different roles of Banco de Espana Migrating CB to T2S Central Banks in T2S. Specifically as: System Entity and RTGS System Owner Play some of the four different roles of Banque centrale du Central Banks in T2S. Specifically as: Migrating CB to T2S Luxembourg System Entity and RTGS System Owner Play some of the four different roles of Oesterreichische Central Banks in T2S. Specifically as: Migrating CB to T2S Nationalbank System Entity and RTGS System Owner Play some of the four different roles of Danmarks Central Banks in T2S. Specifically as: Migrating CB to T2S Nationalbank System Entity and RTGS System Owner Play some of the four different roles of Suomen Pankki Migrating CB to T2S Central Banks in T2S. Specifically as: System Entity and RTGS System Owner Banka Slovenije Migrating CB to T2S Play some of the four different roles of 14

15 SUBJECT TYPE COMMENT Central Banks in T2S. Specifically as: System Entity and RTGS System Owner Eesti Pank Migrating CB to T2S Play some of the four different roles of Central Banks in T2S. Specifically as: System Entity and RTGS System Owner Play some of the four different roles of Lietuvos Respublikos Central Banks in T2S. Specifically as: Migrating CB to T2S centriniu banku System Entity and RTGS System Owner Play some of the four different roles of Magyar Nemzeti Bank Migrating CB to T2S Central Banks in T2S. Specifically as: System Entity and RTGS System Owner Play some of the four different roles of Narodna banka Central Banks in T2S. Specifically as: Migrating CB to T2S Slovenska System Entity and RTGS System Owner 3.4 Composition of the second wave SUBJECT TYPE COMMENT Euroclear Belgium Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S Euroclear France Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S Euroclear Netherlands Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S Interbolsa Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S NBB - SSS Migrating CSD to T2S Complete migration of the settlement system and all connected activities to 15

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 Play all the four different roles of Migrating CB to T2S Bank 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 SUBJECT TYPE COMMENT Clearstream Banking Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S Keler Hungary Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S LuxCSD Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S OeKB Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S VP Lux Migrating CSD to T2S Complete migration of the settlement system and all connected activities 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 Banque centrale du Migrating CB to T2S Performance of all four different roles of 16

17 SUBJECT TYPE COMMENT 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 Migrating CB to T2S Nationalbank Central Banks in T2S Wave 1-2 Migrated CSDs and CBs CSDs and CBs already migrated during to T2S the first two migration waves 3.6 Composition of the fourth wave SUBJECT TYPE COMMENT CDCP Slovakia Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S Iberclear Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S Complete migration of the settlement AS Eesti Migrating CSD to T2S system and all connected activities to Vaartpaberikeskus T2S Complete migration of the settlement CSD of Lithuania Migrating CSD to T2S system and all connected activities to T2S Euroclear Finland Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S KDD Slovenia Migrating CSD to T2S Complete migration of the settlement system and all connected activities to T2S BNY Mellon CSD Migrating CSD to T2S Complete migration of the settlement system and all connected activities 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 17

18 Banka Slovenije Eesti Pank Lietuvos Respublikos centriniu banku Narodna banka Slovenska Wave 1-3 Migrating CB to T2S Migrating CB to T2S Migrating CB to T2S Migrating CB to T2S Migrated CSDs and CBs to T2S Play all the four different roles of Central Banks in T2S Play all the four different roles of Central Banks in T2S Play all the four different roles of Central Banks in T2S Play all the four different roles of Central Banks in T2S CSDs and CBs already migrated during the first three migration waves 18

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

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. Binding declaration to become a DCP 1 The clients must inform Monte Titoli of their intention (binding declaration) of participating as DCP to the T2S platform Distribution of test cases for DCP certification. 2 The Eurosystem provides the list of test cases for DCP certification to DCP participants Distribution of contracts and membership forms - draft version 3 Deadline for the publication of the draft of the contractual documents to clients by Monte Titoli Distribution of test cases for authorisation 4 Monte Titoli provides the participants with the list of test cases for the authorisation process Registration by the NSPs Each DCP participant must complete the 5 registration by the NSP for the test environment through their respective CSDs/CBs Request for assignment of 6 certificates/tokens To access the test environment in order to begin connectivity testing 7 Distribution of contracts, instructions and membership forms ACT OR SUBJECT DEADLINE DCP 24/02/2014 ECB March 2014 MT 15/05/2014 MT September 2014 DCP 31/10/2014 DCP 14/11/

21 N DESCRIPTION S.P. ACT OR SUBJECT DEADLINE Deadline for the final publication of the new MT 15/12/2014 set of client contracts by Monte Titoli Connectivity testing 8 The DCPs are required to carry out these From tests in order to connect to the T2S Clients 03/12/2014 Community testing environment. (DCP/ICP) to The ICP are involved in the appropriate 27/02/2015 connectivity tests with MT directly through the T1 test environment Configuration of DCA and CMB The payment banks that offer cash settlement services and/or client By PB collateralisation services to their clients 20/02/2015 must duly authorise the clients involved to use their own DCAs (CMB creation) First pre-migration Dress Rehearsal Implementation of the first full pre-migration From Dress Rehearsal on static data relative to 23/02/2015 securities and participants in the MT to Community test environment, 27/02/2015 corresponding to the Monte Titoli T1 test environment First pre-migration Dress rehearsal: debriefing The clients are invited to send their From MT feedback on the result of the first dress 03/03/2015 rehearsal to Monte Titoli as well as to DCP reporting any problems or critical elements 07/03/2015 relative to the static data migrated to T2S and directly visible on the new platform NSP registration process Each DCP participant must complete the registration by the NSP for the test DCP 27/02/2015 environment through their respective CSDs/CBs 13 Request for certificates/tokens to access DCP 02/03/

22 N DESCRIPTION S.P. ACT OR SUBJECT the production environment 14 DCP certification tests DCP Start of Community testing The CSDs, the Central Banks and their participants are required to take part in Community Testing 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) Deadline for confirmation of production membership data Deadline for confirmation to Monte Titoli of the membership data for clients involved in the production environment 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) 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 CSD CB Clients (DCP/ICP) Clients (DCP/ICP) Clients (DCP/ICP) MT Clients (DCP/ICP) MT Clients (DCP/ICP) DEADLINE By March /03/2015 From 20/03/2015 to 03/04/ /03/2015 From 17/04/2015 to 20/04/2015 From 23/04/2015 to 24/04/

23 N DESCRIPTION S.P. ACT OR SUBJECT Static data go-live in the T2S production environment and in the MT legacy systems 20 Uploading of all static data and the related MT applications in the new T2S production environment and new Monte Titoli legacy systems Contingency period for upload of static data into the T2S production environment 21 Buffer period provided in case that any MT critical elements appear during the uploading process and migration of static data into T2S process Statement of correct implementation of ECB the certification tests DCP Statement of correct implementation of the authorisation tests Clients The Monte Titoli clients report the correct (ICP/DCP) implementation of the authorisation tests MWE Dress Rehearsal 1 First implementation of the dress rehearsal MT of the migration weekend with all production data. Clients All subjects that took part in the first (DCP/ICP) migration wave to T2S will be involved 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 Community MWE Dress Rehearsal: debriefing The clients are invited to send their MT feedbacks to MT regarding the results of the DEADLINE From 27/04/2015 to 04/05/2015 From 05/05/2015 to 11/05/ /05/ /05/2015 From 15/05/2015 to 18/05/2015 From 18/05/2015 to 20/05/2015 From 21/05/2015 to 23

24 N DESCRIPTION S.P. ACT OR SUBJECT DEADLINE Dress Rehearsal and report any problems Clients 22/05/2015 or critical elements that came to light during (ICP/DCP) the implementation of this Dress Rehearsal MWE Dress Rehearsal 2 27 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 Business day testing 2 From 28 During business day testing the clients will be requested to upload transactions and Community 01/06/2015 to operate exactly as if they were in production 03/06/2015 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 MT From 29 with the new T2S platform and report any problems or critical elements that might have been appeared. Clients (ICP/DCP) 04/06/2015 to 05/06/2015 The positive outcome of the above Dress Rehearsal could represent a positive outcome for one of the entry criteria to T2S Statement of correct implementation of 30 the Dress Rehearsal for the MWE The clients are required to declare the correct implementation of the Dress Clients (ICP/DCP) By 06/06/2015 Rehearsal of the migration weekend Migration from the PI legacy test environment to MT's T2 environment 31 Where applicable, clients are required to migrate their pre-production test environments by disconnecting them from the old Monte Titoli PI test environment and Clients (DCP/ICP) 15/06/2015 connecting them to MT's new T2 test environment (pre-production). 24

25 N DESCRIPTION S.P. ACT OR SUBJECT In addition to this the DCPs must connect their legacy systems directly to the T2S preproduction environment T2S GO-LIVE 32 IMPLEMENTATION OF THE MIGRATION ALL WEEKEND TO T2S DEADLINE 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. 25

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 26

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- 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 (Client@lseg.com) that will also be able to provide additional information on how the tool may be used. 27

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. Existing in Monte Titoli systems Identification of the mapping rules Information Must be communicated by the Clients New information Requests for T2S Assigned by default by Monte Titoli 28

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 autocollateral 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 Pre-settlement service data For what concerns the configurations of the pre-settlement service (-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 nonguaranteed markets as an exception compared to (LIQDEF) based on Provenance and the Trading Market (LIQNEG); 29

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 EuroTL, 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 presettlement 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 -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 Finally, among the configuration elements supplied to the clients, Monte Titoli also guarantees full visibility to the following information: 30

31 list of functions subscribed and related communication procedures; list of participants that have been granted operating mandates for -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 -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 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. 31

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: 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 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: 32

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

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: 34

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 autocollateral 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 autocollateral 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. 35

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 prerequisite 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 36

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

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

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 (-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 Possible changes to service participation methods include the setup and/or withdrawal from one or more services. The changes to the -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 nonguaranteed markets Change of the settlement agent for guaranteed markets and/or change of their type of registration to the central counterparty 39

40 6.1 Change of payment agent 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: 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 -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 -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: 40

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 -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 - TRM and in the Central Counterpart that are divided into: 1. model 'A' or gross margination model, valid for the equity market (see ) 2. model 'B' or net margination model, valid for the bond market (see ) For further details reference should be made to the "Instructions for the -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. 41

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); : 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 -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. 42

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

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 -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 general clearing member the following data is subject to changes on the bilateral net balance : 44

45 o o settlement agent settlement account Move from case 3 to case 1 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 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance : Move from case 1 to case 4 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 The following data is subject to changes on the transaction: 45

46 The following data is subject to changes on the bilateral net balance: Move from case 4 to case 1 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 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 The following data is subject to changes on the transaction: The following data is subject to changes on the bilateral net balance: Move from case 1 to case 5 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 The trader, in its role as "replaced" settlement agent, can no longer view its own transactions The "incoming" settlement agent can view all the transactions of the trader that was previously directly involved in settlement The general clearing member has a full view of the trader's transactions, thanks to its indirect membership in the CCP The following data is subject to changes on the transaction: o general clearing member 46

47 The following data is subject to changes on the bilateral net balance: Move from case 5 to case 1 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 The following data is subject to changes on the transaction: o general clearing member The following data is subject to changes on the bilateral net balance: Move from case 3 to case 4 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 47

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 The following data is subject to changes on the transaction: o general clearing member The following data is subject to changes on the bilateral net balance: Move from case 4 to case 3 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 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 48

49 Move from case 3 to case 5 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 The "incoming" GCM can view the trader s balances Only the field relative to the general clearing member is subject to changes on the 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 general clearing member The following data is subject to changes on the bilateral net balance: Move from case 5 to case 3 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 49

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 prevariation 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 Move from case 4 to case 5 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 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 Only the field relative to the general clearing member is subject to changes on the transaction SCENARIO 2 The "replaced" settlement agent can no longer view the trader s transactions The "incoming" settlement agent can view all the transactions of the trader that was 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 The following data is subject to changes on the transaction: o general clearing member 50

51 The following data is subject to changes on the bilateral net balance: Move from case 5 to case 4 SCENARIO The trader moves from an indirect registration to the CCP to a direct one The trader changes settlement agent CONSEQUENCES The "replaced" settlement agent can no longer view the trader s transactions 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 The following data is subject to changes on the transaction: o general clearing member The following data is subject to changes on the bilateral net balance: Move from case 3 to case 3 SCENARIO Change of the settlement agent which is also a general clearing member CONSEQUENCES The "replaced" settlement agent can no longer view the trader s transactions The "incoming" settlement agent has a full view of the trader's transactions even in its 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) The following data is subject to changes on the transaction: o general clearing member 51

52 The following data is subject to changes on the bilateral net balance: Move from case 4 to case 4 SCENARIO Change of the settlement agent, but not in the participation set up to the CCP (direct) CONSEQUENCES The "replaced" settlement agent can no longer view the trader s transactions The "incoming" settlement agent can view all trader transactions The following data is subject to changes on the transaction: The following data is subject to changes on the bilateral net balance: Move from case 5 to case 5 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 52

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 Only the field relative to the general clearing member is subject to changes on the 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 The following data is subject to changes on the transaction: o general clearing member The following data is subject to changes on the bilateral net balance: 53

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

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 previously directly involved in settlement The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance: o issuer o negotiation type (in certain instances) 55

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 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance: o issuer o negotiation type (in certain instances) Move from case 1 to case 4 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 The trader, in its role as "replaced" settlement agent, can no longer view its own transactions The following data is subject to changes on the transaction: The following data is subject to changes on the bilateral net balance: 56

57 o Settlement account Move from case 4 to case 1 SCENARIO The trader moves from indirect to direct in clearing The trader maintains a direct participation to the CCP CONSEQUENCES The "incoming" settlement agent that is also the trader and individual clearing member, has full visibility of all the transactions regardless of the role performed The "replaced" settlement agent can no longer view the trader s transactions The following data is subject to changes on the transaction: The following data is subject to changes on the bilateral net balance: Move from case 1 to case 5A 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 The trader, in its role as "replaced" settlement agent, can no longer view its own transactions The "incoming" settlement agent can view all the transactions of the trader that was previously directly involved in the settlement process The general clearing member has a full view of the bilateral balances set up in its name The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance: 57

58 o o o o settlement agent settlement account issuer negotiation type (in certain instances) Move from case 5A to case 1 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 "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 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 The following data is subject to changes on the transaction: o general clearing member The following data is subject to changes on the bilateral net balance: o issuer o negotiation type (in certain instances) 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 58

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: The following data is subject to changes on the bilateral net balance (transaction between trader and its general clearing member): The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): SCENARIO 2 The trader continues to view its own transactions but no longer as "replaced" settlement 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 The following data is subject to changes on the transaction: o general clearing member The following data is subject to changes on the bilateral net balance (transaction between trader and its general clearing member): o issuer o the counterparty The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): 59

60 o o o o issuer settlement agent settlement account 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 The trader, in its role as "incoming" settlement agent, has a full view of its own 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. The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance (transaction between trader and its general clearing member): 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 60

61 SCENARIO 2 The trader s "replaced" settlement agent can no longer view the trader s transactions The trader, in its role as "incoming" settlement agent, has a full view of its own transactions The general clearing member, which coincides with the GCM settlement agent, continues to have the same view of the trader's transactions The following data is subject to changes on the transaction: The following data is subject to changes on the bilateral net balance (transaction between trader and its general clearing member): 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 The trader continues to view its own transactions but no longer as "replaced" settlement 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 The "new" general clearing member can view the trader's transactions, seeing as the new subject is required to interface with the CCP The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance (transaction between trader and its general clearing member): o counterparty The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): 61

62 o o issuer settlement account 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 "replaced" settlement agent can no longer view the trader s transactions 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 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance (transaction between trader and its general clearing member): o counterparty The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): o issuer Move from case 3A to case 4 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 62

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 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): o issuer o negotiation type (in certain instances) 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 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): o issuer o negotiation type (in certain instances) Move from case 4 to case 3A SCENARIO The trader moves from a direct registration to the CCP to an indirect participation in the CCP 63

64 CONSEQUENCES The "replaced" ICM can no longer view the trader s balances The "incoming" GCM can view the trader s balances The settlement agent continues to have the same visibility over the trader s transactions as it had in the pre-variation situation seeing as the settlement agent has remained the same The following data is subject to changes on the transaction: o general clearing member o code of the subject that owns the bilateral net balance Only the field relative to the general clearing member is subject to changes on the transaction The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): o issuer o negotiation type (in certain instances) 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 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance 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 64

65 The "incoming" GCM acquires the visibility of the trader s transactions The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): o issuer Move from case 5A to case 3A SCENARIO The trader changes GCM using its own settlement agent CONSEQUENCES The "replaced" GCM can no longer view the trader s balances The "incoming" GCM can view the trader s balances The settlement agent continues to have the same visibility over the trader s transactions as it had prior to the pre-variation situation seeing as the settlement agent has remained the same The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance (transaction 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 65

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 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance Only the field relative to the issuer is subject to changes on the bilateral net balance (transaction between general clearing member and CCP) Only the field relative to the issuer is subject to changes on the bilateral net balance (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 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance (transaction between trader and its general clearing member): o counterparty The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): o issuer 66

67 Move from case 5B to case 3B SCENARIO The trader changes GCM using its own settlement agent and two different accounts CONSEQUENCES The "replaced" GCM can no longer view the trader s balances The "incoming" GCM can view the trader s balances The settlement agent continues to have the same visibility over the trader s transactions as it had prior to the pre-variation situation seeing as the settlement agent has remained the same The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance 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) Move from case 4 to case 5A 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 "replaced" ICM can no longer view the trader s balances The "incoming" GCM can view the trader s balances The settlement agent continues to have the same visibility over the trader s transactions as it had prior to the pre-variation situation seeing as the settlement agent has remained the same The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance 67

68 The following data is subject to changes on the bilateral net balance: o issuer o negotiation type (in certain instances) SCENARIO 2 The "replaced" settlement agent can no longer view the trader s transactions The "incoming" settlement agent can view all the transactions of the trader that was previously directly involved in settlement 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 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance: o issuer o negotiation type (in certain instances) Move from case 5A to case 4 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 The "replaced" settlement agent can no longer view the trader s transactions The "incoming" settlement agent can view all the trader s transactions The "replaced" GCM can no longer view the trader s balances The trader, in its role as "incoming" ICM, can view its own balances 68

69 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance: o issuer o negotiation type (in certain instances) SCENARIO 2 The settlement agent continues to have the same visibility over the trader s transactions as it had prior to the pre-variation situation seeing as the settlement agent has remained the same The "replaced" GCM, can no longer view the trader s balances The trader, in its role as "incoming" ICM, can view its own balances The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance: o issuer o negotiation type (in certain instances) Move from case 2 to case 2 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 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance (transaction between trader and its general clearing member): 69

70 o counterparty The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): o issuer Move from case 3A to case 3A SCENARIO The trader changes the settlement agent and general clearing member that are the same entity CONSEQUENCES The "replaced" settlement agent can no longer view the trader s transactions The "incoming" settlement agent has a full view of the trader's transactions even in its role as general clearing member settlement agent 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) The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance: o issuer Move from case 3B to case 3B SCENARIO The trader changes the settlement agent that is also a general clearing member. The settlement agent uses different accounts CONSEQUENCES The "replaced" settlement agent can no longer view the trader s transactions 70

71 The "incoming" settlement agent has a full view of the trader's transactions even in its role as general clearing member settlement agent 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) The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance (transaction between trader and its general clearing member); o counterparty The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): o issuer Move from case 4 to case 4 SCENARIO The settlement agent changes but not the participation procedures to the CCPs (direct) CONSEQUENCES The "replaced" settlement agent can no longer view the trader s transactions The "incoming" settlement agent can view all the trader s transactions The following data is subject to changes on the transaction: The following data is subject to changes on the bilateral net balance: 71

72 Move from case 5A to case 5A 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 "new" general clearing member can view the trader's transactions, seeing as the new subject is required to interface with the CCP 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 The following data is subject to changes on the transaction: o general clearing member o code of the subject issuing the transaction Only the field relative to the issuer is subject to changes on the bilateral net balance 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 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 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance: o issuer 72

73 Move from case 5B to case 5B 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 new subject is required to interface with the CCP 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 Only the field relative to the general clearing member is subject to changes on the transaction The following data is subject to changes on the bilateral net balance (transaction between trader and its general clearing member): o counterparty The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): o issuer (in certain instances) 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 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 73

74 The following data is subject to changes on the transaction: o general clearing member o code of the participant that owns the bilateral net balance The following data is subject to changes on the bilateral net balance (transaction between trader and its general clearing member): o counterparty The following data is subject to changes on the bilateral net balance (transaction between general clearing member and CCP): o issuer 74

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 Eurosystem CSD Central Banks CSD Participant Payment Bank COMMITMENT Management of the User Testing preparation phase Coordination and support of User Testing implementation 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 Active participation in the process of the test phases related to the Community and to the Business Day 75

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

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 Available for Monte Titoli s T2 Pre-Prod. clients as a new proproduction environment 12/06/2015 Open date replacing PI. Used by Monte Titoli and by the clients for connectivity and T1 Community functional testing during the 05/01/ /06/2015 Community and Business Day testing phases. Used by Monte Titoli and by the clients to migrate to T2S T1 Production production in (Migration Week 12/06/2015 Open date End) and the subsequent BAU activities. Used exclusively for the management of static T3 n.a. production data via the web 15/12/ /03/2015 platform. Accessible only via Internet. Connected to the T2S T3 Production production environment to enable the migration of static 21/03/ /06/2015 data. 77

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 T2S Programme Plan Project Phases User Testing T2S Programme Plan Project Phases Migration weekends 78

79 8 MANAGEMENT OF ACCESS RIGHTS IN T2S (only for DCP) 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. 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. 79

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: 1 st level party, meaning the T2S Operator at the head of the hierarchic structure; 2 nd level party, meaning the CSDs and the CBs; 3 rd 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 definitions 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. 80

81 8.2.1 User Function The ML 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 ML 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 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: 81

82 c 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 Secured Group A «secured group» is a homogeneous group of «secured objects» (for example: a group of parties or securities accounts) Role A role is a set of privileges User A user is an individual or an application that interact with T2S triggering the «T2S user functions» 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; 82

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, 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, 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 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. 83

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. ETENSION OF THE DEFAULT DATA SCOPE The following graph shows how user (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 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, 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 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) 84

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

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 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) 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 RBAC 1 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) 86

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

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, 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 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: 88

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

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

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: 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): 34f36 T2S User Handbook (UHB): 9e733a315bea 91