Target2 Securities. Monte Titoli User Requirements

Transcription

1 Target2 Securities Monte Titoli User Requirements

2

3 Contents Click here to enter text. 1. Document Management Document History Definitions, Acronyms and Abbreviations References Annex 8 2. Introduction Purpose of the document Scope of the document Out of scope of the document Key guidelines, assumptions and dependencies MT Services overview in T2S Connectivity T2S Connectivity MT Connectivity Routing configuration User and role privileges Static data Management Parties Management Securities Account (SAC), Dedicated Cash Account (DCA) and SAC-DCA link management Securities Management Pre-settlement Transaction Acquisition Validation Enrichment Amendment 32

4 6.5 Hold & Release Cancellation Allegement Matching Bilateral Netting (Net and Gross Margining Model) Forwarding to Settlement System processes Settlement Intra-CSD Settlement Cross Border Settlement Reporting Settlement confirmation Presettlement/Settlement Reporting - G56/G70 File Participant accounting - Daily statement of holding Real time Status advice notification (push information) Custody Services Admission of financial instruments Centralization Reduction of nominal value centralized as a result of repurchase / redemption (Mark-Down) Government Bonds Position change confirmation Corporate Actions Mandate Announcement Distribution Reorganizations Corporate Action reporting and notification Position Management Scope T2S Impact User Requirements and Adaptation Impact 85

5 12. Business day MT services for participants Appendix Pre Settlement Services Overview on partial settlement in T2S Overview on settlement priority in T2S Overview on linkage options in T2S Portfolio Transfer Custody services Corporate action Position Management 137

6 User Requirements 1. Document Management 1.1 Document History Date Version Details Initial version Final version Initial version Final version 1.2 Definitions, Acronyms and Abbreviations Acronyms CAJWG COSD DCA DCP DFP DVP DWP ED ATIE FOP GUI ICP ISD NCB OP PFOD Description Corporate Action Joint Working Group Conditional Settlement Delivery T2S Dedicated Cash Account Directly Connected Party Delivery Free of Payment (only securities) Delivery Versus Payment (cash and securities) Delivery With Payment (cash and securities) Expiry Date Anagrafe titoli impediti ed estratti Free of Payment consists of a DFP and a RFP Graphical User Interface Indirectly Connected Party Intended Settlement Date National Central Bank Open Point Payment Free Of Delivery (only cash) 6

7 PT-TUG RFP RVP RWP SAC SD SI SIA SR T2S TD UR XCOM X-TRM PA Post Trade Technical User Group Receive Free of Payment (only securities) Receive Versus Payment (cash and securities) Receive With Payment (cash and securities) Securities Account Settlement Date Settlement Instruction Società Interbancaria per l Automazione Settlement Restriction Target 2 Securities Trade Date User Requirement MT service for collateral management The pre-settlement service system provided by Monte Titoli Payment Agent Definitions Flow OTC Description Set of information available in an on demand or automatic mode, and not in an continuous update mode. Over the Counter: associated to settlement instructions that are matched within a Settlement platform (T2S) and different from those that are matched in other systems (typically trading platforms) 1.3 References This document relies on the following documents: References I. T2S User Requirements Document version 5.02, 07 September 2012 II. T2S General Functional Specification version 4.0, published on 21st May 2010 III. T2S User Detailed Functional Specifications version 1.2.1, 07 September 2012 IV. Italian NUG Task Force on collateral management operating set-up V. Rules and Instructions of the Services VI. Rules and Instructions of CSD Service VII. Rules and Instructions of Collateral Management Service VIII. Rules and Instructions of Settlement Service (EXPRESS II) 7

8 IX. Technical documentation X. Standard per Utente XI. Armonizzazione corporate actions on stocks Cash Distributions- Modello operativo XII. Custody Harmonization (CUSHAR) adeguamento reorganizations (reorg) 1.4 Annex Annex XIII. T2S - Cross Border Settlement v2.1 8

9

10 2. Introduction 2.1 Purpose of the document The purpose of this document is to give an overview of the services currently offered by Monte Titoli (hereinafter MT) and to agree and formalize with MT s community the User Adaptations Required (hereinafter UAR) to support those services in the new Target-2 Securities context (hereinafter T2S). The proposed analysis is the result of the consultations and discussions taken place during the activities of the Functional User Group, created within the Italian NUG and composed by MT, BI and participant s representatives, during which comments and inputs from the market were collected by MT and decisions on the discussed functional issues were consolidated to be used as the basis of this document. The impact level evaluated in this document is related to the interaction between Monte Titoli s and the Participants systems and not to the Participants internal systems and procedures. All terms used in this document shall be intended as limited to the purpose clarified above i.e. to describe, from a functional and technical perspective, MT s business processes and services and do not have any legal or regulatory binding interpretation. 2.2 Scope of the document The scope of this document is to identify the high level User Adaptation Requirements for the currently offered Monte Titoli services and to implement, when possible, new functionalities offered by T2S. Each User Adaptation requirement belongs to a main topic and each requirement is presented with attributes. The User Adaptation Requirements have the following attributes. LABEL SERVICE ACRONYM NUMERICAL FIELDS (CO) Connectivity (SD) Static data Management (PS) Pre-settlement (ST) Settlement T2S-UAR Pre-settlement/ Settlement (RP) Reporting (CU) Custody Services (CA) Corporate Action (PM) Position Management Table 2-1: Convention for User Adaptation Requirement coding Progressive number within the same service (4 digit) For example: Requirement ID T2S-UAR-CO-0010 Requirement Description Participants will adapt their outbound messages towards X-TRM (RNI and Swift ISO15022) in order to comply with the X-TRM and T2S validation rules on the additional mandatory information. 10

11 The detailed changes to the messages layouts will be made available in the usual documentation SPU ( Standard per Utente ). 2.3 Out of scope of the document At the time of writing the current version of the document (February 2013), the feasibility of a number of Change Requests is under the analysis of the ECB. The adaptation solutions described in this document are based on the documents and versions referenced at par. 0. Amendments to the described adaptations will be analysed once the implementation of the ECB s CRs is definitively approved and the implementation plan formally communicated according to the change management process of the T2S Framework Agreement. 2.4 Key guidelines, assumptions and dependencies MT will coordinate the adaptation and the migration to T2S process of the Italian community according to the following principles: Ensuring efficiency and low operating impact keeping the current operational and reporting processes as unchanged as possible; maintaining the current pre-settlement and settlement information channels and communication infrastructure. Ensuring limited impacts on procedures and communication messages which means: minimum adjustment of the message layouts exchanged with the market platforms (trades capturing in X-TRM); adaptation of User to Application (U2A) Interfaces for the introduction of new T2S functionalities; adaptation of MT systems to maintain the current standard layouts and communication interface with customers (message structures and processes) as unchanged as possible; Full adaptation to standards and harmonization processes T2S integration implies the adaptation to European standards of the Italian specific procedures related to Corporate Actions on Flows and Corporate Action on Stocks. Two working groups (PT-TUG Settlement Optimization and PT-TUG Corporate Action) with representatives of intermediaries, banking associations and a supervisory committee, meets periodically in order to evaluate impacts related to the harmonization. Actions will be taken gradually and the different milestones will be periodically communicated to all clients. CA on flows : implementation of standards o market Claims and Transformation management of CA on pending settlement instructions; 11

12 o buyer protection: possibility for the buyer, when the transaction is not yet been regulated, to communicate his choice regarding a corporate action event. CA on Stocks: implementation of standards o o o o removing the suffix for cash Dividend; managing with two different events, which are currently jointly managed, the coupon payment and the reimbursement payment for a bond; managing the Record Date in Cash Distribution Mandates and CA announcements; managing the CA announcements for interest payments and capital redemptions. The migration to the T2S platform will also imply the introduction of the Trade Date as a mandatory matching field as required by the International Standards. Ensuring, when feasible, equivalent offer of settlement services to both Directly and Indirectly Connected Participants (hereafter DCPs and ICPs respectively) Custody adaptation before T2S replacement of the BI-COMP payment system with Target2. Additionally MT will coordinate the T2S project activities with specific regard to testing and migration and will publish the supporting documentation (planning, guidelines etc.). 12

13

14 3. MT Services overview in T2S The tables below show the list of services and functionalities available in MT for its participants. The table in par.1 summarizes the same services and functionalities with specific regard to their availability depending on the type of interaction with the T2S platform, either through MT infrastructure or direct witht2s. Source Type/ Settlement Type Guaranteed Market Not Guaranteed Market Trades from CCPs and BoI Participants, CCPs and BoI All Source (1) The service w ill not be changed Operational Function Forwarding CCP functionalities Forwarding Cancellation Info Push Settlement Transaction Acquisition CCP functionalities Transaction Acquisition Forwarding Transaction Acquisition Transaction Acquisition Forwarding Amendement Info Pull Operational SubFunction Acquisition (CVT, PCT) Validation Enrichment Splitting (Interposition) Bilateral Netting (Gross A and Net B Model) Forwarding to T2S Acquisition (CVT, PCT) Validation Enrichment Forwarding to T2S Forwarding to non-t2s settlement system (1) Acquisition (CTC) Validation Enrichment Bilateral Netting (Gross A and Net B Model) Forwarding to T2S Acquisition (CVT, PCT, CTC) Acquisition on External-CSD (CTC) Validation Enrichment Forwarding to T2S Forwarding to non-t2s settlement system (1) Priority Linkages Hold/Release Partial Settlement Cancellation Statement of Allegement Statement of pending transaction Statement of transaction Settlement Status Advice Settlement Confermation Allegement Notification Statement of Allegement Statement of pending transaction Statement of transaction Table 3-1: MT Settlement services in T2S 14

15 Source Type/ Settlement Type Participants Issuer All Source Table 3-2: MT Custody services in T2S Custody Operational Function Restrictions Issuance Instructions Coupon Stripping Issuance Instructions Info Pull Info Push Operational SubFunction Earmarking Blocking Reservation Centralization BuyBack Mark UP / Mark DOWN Stripping Unstripping Centralization BuyBack Mark UP / Mark DOWN Statement of Holding Statement of Holding Statement of Holding and Transactions Settlement and Restriction Confermation 15

16 4. Connectivity MT participants will be offered two different operational models of communicating with T2S platform: Directly Connected operational model: it is a technical facility that allows MT clients to access T2S and use the securities settlement services without the need for MT to act as a technical operator; Indirectly Connected operational model: which allows MT s clients to interact with the T2S platform via MT s platform acting as a technical operator. Figure 4-1: Connectivity models The Instructing party is the party instructing T2S to process the business payload of the request. The Business sender is the party which the business sending user belongs to. The Technical sender is the T2S Actor submitting an A2A or an U2A request to T2S. Each technical sender is identified by means of a certificate issued by the connectivity provider. Direct vs. Indirect Connectivity: MT will offer its clients a set of value added services and a number of options that will be available only using MT s platform. The configuration of the different options in terms of offered services and communication channels/standard is described in par.1. 16

17 Figure 4-2: MT connectivity models The term Direct Connected Participant is used in the ECB Framework Agreement in order to identify those participants that will have an own communication infrastructure to interact with T2S and will therefore be submitted, for example, to specific testing activities (Certification) in order to prove their systems would not harm the ECB central system. In the context of this document the pure Direct Operating model would be used by a participant that under no circumstances interacts with T2S through MT technical infrastructure therefore not using any of the services that Monte Titoli will make available to its clients through its own infrastructure. As some specific functionalities/services will actually be available only through MT infrastructure, the mixed model will apply to all those participants that will operate with T2S through both their own infrastructure (as DCPs) and through MT infrastructure. Those participants will: - directly interact and instruct T2S and receive the corresponding subscribed T2S messages, files and reports, - interact and instruct through MT infrastructure receiving the messages, files and reports that MT will make available to all its participants that operate through its infrastructure (no distinction between what in the FA is considered Directly and Indirectly Connected Participant). Those participants will have to communicate which MT services they intend to use and the corresponding information files, reports and messages they intend to receive from MT. 4.1 T2S Connectivity Connectivity to T2S will be available through two different channels: Via Application-to-Application (A2A) using the Swift ISO20022 messaging implemented for T2S; Via User-to-Application (U2A) using the ECB browser based solution GUI (Graphic User Interface). Direct Connectivity has to be considered only as a technical facility to access T2S without the need for MT to act as a technical operator. Direct connectivity affects neither the business nor 17

18 the legal relationship between MT and its clients (T2S party). This implies that both ICPs and DCPs will contract exclusively with Monte Titoli and will be MT participants. 4.2 MT Connectivity Connectivity to Monte Titoli will be available through the currently offered channels. Via Application-to-Application (A2A) using the currently offered communication solutions; Via User-to-Application (U2A) using MT s browser based solutions MT-X. In addition to the current channels MT will also offer a set of ISO20022 standard messages to support the communication between its infrastructure and its clients applications. The complete set of communication channels through MT s infrastructure to T2S will therefore be: RNI (Italian Interbank Network) SWIFT ISO 15022; SWIFT ISO 20022; MT-X Monte Titoli Internet Communication System ; New A2A solution replacing LU6.2. The table below shows a list of the main operational functions available in T2S and the corresponding channel/standard that will be made available for Monte Titoli participants. The functions identified under the A2A and T2S GUI columns will be available only for those that have implemented their own communication infrastructure to interact with T2S in addition to MT functions that they will be allowed to use as all other MT participants. 18

19 Service Settlement Source Type/ Settlement Type Guaranteed Market Not Guaranteed Market Trades from Institutions Operational Function Transaction Acquisition Trades Cancellation from Borsa Italiana Interaction with T2S through MT infrastructure Flow s MS FT Sw ift ISO ISO Fileact (1 ) File containing set of information available in an on demand or automatic mode, and not in an continuous update mode. ( 1 ) RNI MTX Ex- Lu6.2 Direct Interaction with T2S A2A T2S GUI Service Settlement Custody Source Type/ Settlement Type Participants, CCPs and BoI All Source Participants All Sources Operational Function Acquisition (CVT, PCT, CTC) Acquisition on External-CSD (CTC) Amendement Cancellation Info Pull Info Push Restrictions Issuance Instructions Coupon Stripping Info Pull Info Push Table 4-1: Mapping of Operational Functions and communication channels/standards User Requirements and Adaptation Impact Interaction with T2S through MT infrastructure Flow s MS RNI FT Sw ift ISO ISO Fileact MTX Direct Interaction with T2S Ex- T2S Lu6.2 A2A GUI Requirement ID T2S-UAR-CO-0005 Requirement Description Monte Titoli will document the fields and values that will be used in order to guarantee that DCPs will be able to recognise instructions and messages related to MT acting as CSD (for example for Corporate Actions management etc) from instructions and messages in T2S related to DCPs own activity. 19

20 4.3 Routing configuration Scope The scope is the setup and maintenance of the static data which instruct T2S to route messages and files to MT and to Directly Connected Participants T2S Impact As described in UDFS in section Connectivity in table 21, for each T2S Actor who is directly connected to T2S, the information provided are : The Indirectly Connected Participants will be associated to the technical addresses that MT will decide to configure in T2S and no additional information is needed from them. Directly Connected Participants shall communicate to Monte Titoli their technical addresses, network providers and network services. One technical address shall be specified as the default and it is possible to configure additional technical addresses in order to manage different outbound messages (for example files vs single messages) User Requirements and Adaptation Impact Requirement ID T2S-UAR-CO-0010 T2S-UAR-CO-0020 Requirement Description No impact for ICP as they won t use their technical infrastructure to interact with T2S but, instead, will operate through MT technical infrastructure Direct participants will be configured by Monte Titoli as far as the default and the conditional routing static data are concerned. 20

21 4.4 User and role privileges Scope The scope is to assign privileges and Access Rights to Directly Connected Participants users in order to use some ECB s GUI functions and/or XML messages T2S Impact Access Rights will be assigned to users in order for them to be able to use the required ECB s GUI functions and/or XML messages (T2S user functions) User Requirements and Adaptation Impact Requirement ID T2S-UAR-CO-0030 Requirement Description The ECB s GUI will not be available to Indirectly Connected Participants T2S-UAR-CO-0040 MT has to authorize DCPs to use GUI functions and XML messages MT will set up at least one authorized User for each CSD Participant that will directly interact with T2S. The extent of the functions that this authorized User will be allowed to manage will be communicated by Monte Titoli at a later stage of the T2S migration project. This authorized User will then be used by MT s Directly Connected Participants to set up the other users and user profiles to be used within their own organization. Each single User will be assigned its specific roles and each role will be assigned a set of privileges. 21

22 5. Static data Management 5.1 Parties Management Scope The scope is the management of static data regarding MT Clients (Issuers, Intermediaries, Payment Banks) and all the related information needed to provide MT services. Whilst management of static data related to Intermediaries and Issuers is in charge of MT, the management of static data related to Payment Banks is in charge of the National Central Bank (NCB). The coding of MT participants is currently based on ABI codes or other codes assigned by MT for its own purposes. Below the code list provided by MT services: ABI CODE MT CODE CED CODE BIC CODE The code is assigned by Bank of Italy to banks, financial intermediaries, brokers and CCPs. The code has the same standard as the ABI code and in most cases corresponds with it. Sometimes the code is assigned by Monte Titoli to specific accounts that cannot have an ABI Code (e.g., Omnibus Accounts). The code is assigned by SIA. The code is assigned by SWIFT. ABI, CED and BIC codes are currently used to interact with X-TRM services. ABI and MT codes are used also to interact with Custody services T2S Impact T2S supports a hierarchical party model (see diagram below) based on a three level structure with defined relationships between parties and between different levels. Figure 5-1: Parties model Each legal entity may play different roles in T2S. Each legal entity playing multiple business roles results in the definition of several T2S parties, as long as the legal entity established several relationships with different parties in T2S. The structure of Parties in T2S will be based on the defined operating model. 22

23 MT will manage the legal entities in T2S which requires the assignment of 11-character BICs to parties. The BIC code is used in T2S under the constraint that it must be unique within the set of parties having established a business relationship with the same Level 2 party defined in T2S. Level 2 parties can be CSDs or Central Banks. The same BIC can therefore not be used to identify more than one party among the community of parties that have a business relationship with the same CSD or Central Bank. Regarding the management of participants in Monte Titoli the possible roles are : Settlement Agent (SA) Trading Party (TP) Final Beneficiary (FB) Participant to the settlement system (currently ExpressII) and holding an account in MT. Subject that negotiates financial instruments using a securities account of a SA, that does not necessarily have an Exchange membership. It can be either a CSD participant or a client of a CSD participant. Client of the Trading Party or client of the SA User Requirements and Adaptation Impact Requirement ID T2S-UAR-SD-0010 Requirement Description All customers must indicate the BICs which they will use in T2S settlement system; MT is responsible for configuring the BIC in T2S in accordance to the role specified by customers. The Indirectly Connected Participants will be able to operate with the same currently used coding mode. T2S-UAR-SD-0030 The same currently used roles - Intermediary, Issuer, Settlement Agent, Indirect Settlement Member - will be maintained in T2S. Customers shall provide Monte Titoli with specific information related to how the Intermediary has to be configured in T2S. MT systems will manage the relationship between the different coding (current code to BIC code) i.e. participants static data specific for T2S will be managed in the internal processes of MT, without relevant changes for MT s clients that will be able to use the same currently used codes. 5.2 Securities Account (SAC), Dedicated Cash Account (DCA) and SAC-DCA link management Scope The scope is the management of static data regarding clients Securities Accounts, Dedicated Cash Accounts and their relationships. Set up of DCAs will be managed by NCB s, whilst MT will be in charge of creating the links between DCAs and Securities Account. 23

24 5.2.2 T2S Impact As outlined by ECB, based on a Change Request approved by the Advisory Group in November 2012, the CSDs were invited to propose and agree a harmonized number for the security account in T2S in term of length and usage. T2S securities account numbering shall comply with the following T2S rules: The T2S standard, agreed with the other CSDs, requires to use: A. BIC4 of the CSD: to identify the first 4 characters of the BIC code of the CSD (eg MOTI) B. a free text (31 alphanumeric characters) Monte Titoli has defined that the free text will be valued as follows: BIC of the owner of the account (Account Owner); ABI code of the account; MT Account type. Figure 5-2: T2S Securities Account coding CSDs will open and maintain securities accounts, in order to process settlement instructions, in their books on behalf of their participants, regardless of whether they are directly or indirectly connected to T2S. The following types of securities accounts are available in T2S: CSD Participant Account: the ordinary securities account used for settlement of instructions; Issuance Account: the securities account reflecting the holdings of the issuer CSD s participant for a given financial instrument. The Securities Accounts can be linked to the related DCAs for cash settlement and/or autocollateralization purposes. MT will therefore be in charge of creating links between securities accounts and DCAs (created by National Central Banks and provided by customers) in order to set up the settlement configuration. The following types of cash accounts are available in T2S: T2S Dedicated Cash Account (DCA): exclusively used for securities settlement in T2S, linked to an RTGS account in TARGET2 or in another RTGS platform of a T2S eligible non Euro currency. Each DCA can be created to manage only one single currency. T2S 24

25 operates as an ancillary system for the RTGS systems and the position of a DCA shall be equal to zero at the beginning of each settlement day; the end of day balance is swept to the linked RTGS system. NCBs open and maintain T2S Dedicated Cash Accounts in their books for their payment banks. DCA owners have the following requisites: They are settlement payment banks or NCBs; They can have one or more DCA in Euro or non-euro currencies; They have to define which RTGS account the DCA has to be linked to, in order to support the EOD liquidity repatriation; The following types of cash accounts are available in T2: RTGS accounts: RTGS accounts are cash accounts in central bank money opened in one of the RTGS systems connected to T2S. They are a source of liquidity to support the settlement process in T2S; User Requirements and Adaptation Impact MT systems will manage two different codes for Securities Accounts: The MT internal coding that will remain the same as it is today and will be used for all the internal processes (custody and pre-settlement); T2S Securities Account coding, that MT will use to interact with T2S. This implies that MT will provide a classification and mapping between T2S and MT accounts so that clients will be able to work using both coding systems: the current securities accounts (MT code) and the T2S code, maintaining in both cases the same business role as far as MT services are concerned (e.g. intermediaries, issuers, payment banks, paying agents). Requirement ID T2S-UAR-SD-0040 T2S-UAR-SD-0045 T2S-UAR-SD-0050 Requirement Description Indirectly Connected Participants will be able to decide which Securities Account code to use (internal MT code or T2S Securities Account code). The same choice will be available to DCP when interacting with T2S through MT technical infrastructure (using an Indirect Connectivity Operating model). MT will make available to all participants the information (Static Data and related restrictions) stored in T2S which define how MT service will actually operate in T2S. When interacting with T2S platform Directly Connected Participants shall use the T2S Securities Account code. 25

26 The example below shows the mapping of a MT account structure to a T2S account structure: MONTE TITOLI SECURITIES ACCOUNT T2S SECURITIES ACCOUNT OWN BY TYPE OWN BY TYPE Intermediary 00 For each intermediary the following account types shall be defined : «Proprietà» account where intermediary holding securities for itself «Terzi» omnibus account where intermediary holding securities for third parties «Liquidatore» segregated account where intermediary holding securities for their clients «Collateral Giver & Receiver» account used for Tri-Party Collateral Management (XCOM) Party CSD Participant Account Issuer 21 For no fungible securities. n.a. n.a. Issuer 22 Issuance Account Party CSD Participant Account Table 5-1: Mapping of securities accounts for Participants 5.3 Securities Management Scope This section describes the management of static data related to the creation and the management of securities in T2S T2S Impact MT is responsible for the setting up and maintaining the securities in T2S when: it is the issuer CSD of the security; it is the Securities Maintaining Entity (SME), i.e., the single CSD within T2S in charge of creating and maintaining the data for a foreign security issued outside T2S. All Securities currently managed by Monte Titoli, and eligible in T2S, will be migrated in the new settlement system. Additionally MT will have the chance to decide whether to admit and centralize securities that are not eligible in T2S and whether to create accounts in T2S for those securities. The management of T2S securities static data is detailed in par User Requirements and Adaptation Impact Requirement ID T2S-UAR-SD-0060 No Impact for Participants Requirement Description 26

27

28 6. Pre-settlement Monte Titoli s pre-settlement system, X-TRM, currently executes post trade management of transactions coming from both guaranteed and not guaranteed markets as well as OTC trades. The main pre-settlement processes currently managed in X-TRM are: Acquisition Validation Enrichment Matching Forwarding to the settlement systems. X-TRM interacts also with Central Counterparties and provides the participants with the information needed to support their daily operations ( 1 ). Monte Titoli Participants can interact with the pre-settlement system: 1. with their own systems connected to X-TRM in an A2A mode using the currently offered communication solutions; 2. with MT s browser based solutions MT-X (U2A). 6.1 Transaction Acquisition Scope Scope of this section is to describe how transactions will be acquired and updated in X-TRM in the T2S context. X-TRM Platform currently accepts transactions coming from: Guaranteed and not guaranteed markets; Participants; CCPs, Bank of Italy and Monte Titoli itself ; Participants allowed to use X-TRM On line (U2A) can manually manage (insert, modify, cancel) their own transactions. 1 All currently implemented and operated MT services are regulated according to what is formally described in MT official documentation: -Rules and Instructions of the Services ** Rules and Instructions of CSD Service ** Rules and Instructions of Collateral Management Service -** Rules and Instructions of Settelemnt Service (EXPRESS II) - Technical documentation - Standar per Utente (Message layout and specifications) 28

29 6.1.2 T2S Impact The transaction classification used in T2S is different from the one used in X-TRM. The table below shows the different transactions currently processed by X-TRM and the corresponding definitions in T2S: TRANSACTION X-TRM TRANSACTION TYPE SOURCE Market Trades Trades Purchase/sale of securities against a price Repurchase agreements (Repos) Delivery/receipt of securities against cash or free of payment CVT, PCT CVT PCT CTC Payment free of delivery CTC These types of trade are used in order to create and update Bilateral balances as DVP, DWP, RVP,RWP DVP/RVP 2 settlement instruction DVP, RVP FOP,DVP, DWP, RVP, RWP PFOD Guaranteed Markets Not guaranteed Markets X-TRM Participants X-TRM Participants and not Guaranteed Markets National Central Bank, X-TRM Participants, Automatic National Central Bank, X-TRM Participants 2, Automatic Portfolio Transfer CTC FOP X-TRM Participants Table 6-1: Transaction acquisition The above values (DVP, DWP, FOP,ecc.) represent an alias, there is not a correspondent field in S.I. towards T2S. In order to understand the mapping with S.I. please refer to appendix T2S settlement process requires a more complete set of information than the current settlement process. T2S offers also some additional information/options that can be used to manage the settlement instructions. All these information shall be managed in the adapted messages exchanged between MT pre-settlement system and the Participants own systems. The following list provides the most important attributes/options: ISO Transaction code ( 3 ) CUM/EX indicator (for corporate action on flow scope) Opt-out indicator (for corporate action on flow scope) Indicator for partial settlement Indicator for setting settlement priority: Indicator for linking instructions: Pool reference id Reference id for linked Settlement Instruction Reference id for linked Settlement Restriction 2 This type of instruction will be used by Participants only for adjustment of positions related to securities handling 3 The full list of the T2S will allow values and their mapping with the transaction types will be made available in a separate document. 29

30 Reference id for link to previous held/released/amended/cancelled S.I. (related to T2S reference id) When using a reference id the participants shall communicate also which references id type (Participant reference, X-TRM reference, T2S reference) they are using. MT participants interacting with T2S in an indirectly connected mode will have to adapt their applications in order to manage the modified RNI and Swift messages. MT-X will also be adapted in order to allow customers to manually send and manage their trades and transactions User Requirements and Adaptation Impact Requirement ID T2S-UAR-PS-0010 T2S-UAR-PS-0020 T2S-UAR-PS-0030 T2S-UAR-PS-0040 T2S-UAR-PS-0050 Requirement Description MT participants will chose whether to manage their transactions in an indirectly or in a directly connected operating model except from the External-CSD Settlement that will be operated only in indirectly operating mode. Participants that decide to use X-TRM (A2A) will have to add only the mandatory information required by T2S processes except from those that X-TRM will automatically enrich. The currently used messages - RNI (G50 File Transfer - G52 Message Switching); ISO15022 (MT540/1/2/3) will be appropriately adapted in order to manage all the mandatory and additional information and options used in T2S. In addition Participant will be able to use ISO20022 messages (SESE.023) currently non used and new A2A solution replacing LU6.2 Participants will be able to manually send and manage their trades using Monte Titoli s web based solution MT-X (U2A) adequately adapted in order to manage the whole set of additional information and options offered by T2S. Trades originated from automatic matching on the various trading platforms - Market execution (both guaranteed and not guaranteed) - will be automatically acquired in X-TRM and distributed, for all places of settlement, to participants through the existing protocols. MT will continue to calculate net balances and provide relate information to CCP. The additional T2S set of information/option will be managed with appropriate default values directly in X-TRM and/or T2S. No changes are therefore foreseen in the communication protocol between Exchanges and XTRM. For Bank of Italy activities (procedure of placement/repurchase of Government bonds) the current file G60/G61/G62/G63 file transfer will continue to be used. 30

31 6.2 Validation Scope Scope of this section is to describe how the validation process currently managed in MT presettlement system will be adapted and integrated in T2S T2S Impact Validation is an X-TRM process, specific for each type of transaction (CTC, CVT or PCT), that ensures the validity checks of the elementary data in a Settlement instruction sent by Participants, Exchanges, CCPs or BoI. In case the process does not validate the transaction a rejection message will be sent to the instructing party. If the X-TRM validation is passed, the instruction is sent to T2S for a further Business Validation. T2S will apply specific rules to check both the mandatory fields and the additional optional T2S fields eventually used. Only when the complete process (both X-TRM and T2S) have positively been completed a message of acceptance is sent to the instructing party User Requirements and Adaptation Impact To ensure service continuity and minimal impact to its Participants, MT will continue to provide this function using X-TRM validation process consistent with the T2S validation rules. Current X- TRM validation rules will be adapted to all fields (currently used and additional information/options) to both the inbound trade messages (A2A) and MT-X (U2A). Requirement ID T2S-UAR-PS-0060 T2S-UAR-PS-0070 Requirement Description Participants will have to adapt their outbound messages towards X- TRM (RNI, Swift ISO15022, ISO20022 and new A2A solution replacing LU6.2) in order to manage both the mandatory and the optional information required to pass X-TRM and T2S validation rules. X-TRM will send a confirmation/rejection message to its participants when the settlement instruction has successfully passed the X- TRM s acquisition, validation and enrichment phases and it is sent to T2S platform and after T2S acceptance of settlement instruction. 6.3 Enrichment Scope The scope of this section is to describe how the Enrichment process will be managed in the T2S context. Enrichment is an X-TRM process that consists in adding information to the Participants transactions in order to complete the instruction with the information required to be sent to the current Settlement process. The additional information consist both of data managed in X-TRM database (e.g. relation between Parties, Security account involved and other defaults) and of other information calculated according to defined algorithms. 31

32 This function is particularly important in: CVT management because it provides the calculated cash amount, using the details available in the messages and other information stored in the X-TRM database; PCT management because it allows to create the two legs ( spot leg and forward leg ) detailed valorized using the details available in the unique transaction sent by the participant T2S Impact T2S does not implement any enrichment process. This means, for example, that PCTs are managed like any other settlement instruction and Participants would send two separated legs (Repo initiation RVP/DVP and Repo closure DVP/RVP) containing all details. The matching in T2S takes place with the normal rules of the T2S matching applied to the normal Settlement Instructions User Requirements and Adaptation Impact MT will continue to make the Enrichment functionality available to its participants. For this specific service they will therefore need to instruct T2S through MT infrastructure. The Enrichment will be extended in order to complete the set of information, not provided by participants and/or Exchanges, required by to T2S for processing the settlement instructions. Requirement ID T2S-UAR-PS-0080 T2S-UAR-PS-0090 Requirement Description Participants that decide to use X-TRM will be able to benefit from this additional service on all transactions inserted in X-TRM Repos trades will be managed according to the current model only if sent through MT technical infrastructure (X-TRM services) by both involved Parties. 6.4 Amendment Scope This section deals with the Amendment functionality which allows participants to change a Settlement Instruction before the settlement takes place. Settlement Restrictions can also be amended according to the rules explained in par. 11 The Amendment functionality currently available in X-TRM differentiates the amendable fields depending on whether the Settlement Instruction is Matched or still Unmatched T2S Impact Settlement Instructions are amendable in T2S according to the following rules: T2S Actors can only amend the following process indicators: o Partial Settlement Indicator o Priority o Linkages Block 32

33 T2S Actors are only allowed to modify one process indicator per Amendment Instruction at a time. Refer to section 6.5 for the amendment of the Hold/Release process. T2S accepts and processes an Amendment Instruction unless at least one of the following conditions is fulfilled: o The Settlement Status of the Referenced Settlement Instruction is Settled or Cancelled ; o The Referenced Settlement Instruction is identified as CoSD ; o The referenced Settlement Instruction is partially settled and the Amendment Instruction refers to a process indicator other than Priority. In such case the Amendment Instruction is denied. The X-TRM service will be adapted in order to manage the SI amendment according to the rules expressed above. In case of instructions received by Exchanges or CCPs further limitations could be set for amendment. Therefore the amendment of other fields (for S.I. already sent to T2S) can only be done by sending a cancellation of the settlement instruction to be amended and sending a new settlement instruction with the modified fields. On the other hand, for transaction not yet sent to T2S (e.g. Bilateral Balances) the amendment process remain unchanged User Requirements and Adaptation Impact Requirement ID T2S-UAR-PS-0100 T2S-UAR-PS-0110 T2S-UAR-PS-0120 Requirement Description Participants will be able to amend settlement instruction according the T2S rules, therefore only for the: Partial Settlement Indicator, Priority and Linkages Block fields. MT participants will use the currently used RNI (G50 File Transfer - G52 Message Switching), ISO15022 (MT540/1/2/3) and the new ISO (XXXXX) messages adequately adapted. MT-X (U2A) will be adequately adapted in order to allow the manual amendment of SI in T2S. 6.5 Hold & Release Scope This section deals with the Hold/Release functionality which allows participants to hold the sending of the settlement instruction to the settlement engines (net and gross cycles). 33

34 This functionality, currently available in X-TRM, is based on : Two Hold Indicators : Hold Emittente managed by the participant and Hold CSD Emittente managed by the CSD ; Authorization to H&R functions given by Exchanges and CCPs to MT participants and by settlement agents to their trading party ( Negoziatori ) Default values specified for trading party ( Negoziatori ). Automatic mechanism to attribute hold or release status to all settlement instructions that have not been settled (on Net or Gross cycles) and which need to be forwarded to the next cycle of the Gross Settlement System. Specific H&R cut-off MT participant is provided with the information about its own Hold indicators and with the counterparty Hold indicators by X-TRM T2S Impact As described in UDFS in section Hold & Release, this process in T2S is based on : Four Hold indicators: Party Hold managed by the participant, CSD Hold managed by the CSDs, CSD Validation Hold and CoSD Hold both managed by T2S Authorization to H&R functions managed trough privileges which can be set-up at Party or Securities Account level Default values specified at Securities Account level Sending of status advice messages to make available the information related to the Counterparty Hold status only starting from Intended Settlement Date. The messages and the processes of X-TRM will be adapted in order to support the Hold&Release function in T2S, therefore some functionality will no longer be supported: cut-off for the H&R functionality Automatic mechanism In case of instructions received by Exchanges or CCPs further limitations could be set for the management of the Hold/Release indicator. Concerning the information of the Hold indicators of the counterparty, Monte Titoli as CSD, shall make it available even before Intended Settlement Date only to indirect participants. This will be only applied to Intra-CSD scenario User Requirements and Adaptation Impact Requirement ID T2S-UAR-PS-0240 T2S-UAR-PS-0250 Requirement Description Participants will be able to H&R Settlement Instructions according to T2S rules Participants will have to adapt their process in order to support the procedures described above. 34

35 6.6 Cancellation Scope The scope of this section is to describe how the SI cancellation will be implemented in T2S context. A Settlement Instruction can currently be cancelled either by the participant or by other actors as markets, CCPs or BoI. A Settlement Instruction can be cancelled unilaterally only if not yet matched whilst a bilateral cancellation is required when the SI is matched. Cancellation is allowed only for unsettled SI. XTRM system manages also an automatic cancellation of the Settlement Instructions on the Expiry Date ( Data fine validità ) T2S Impact T2S Actors will be able to cancel Settlement Instructions in T2S only after the Instruction s Validation has been confirmed. T2S processes Cancellation Instructions sent : by the Participants; by the Exchanges, CCPs, Bank of Italy Furthermore an Automatic Cancellation can also be sent by the System (Monte Titoli or even T2S itself) for specific instances (i.e. cancellation after a certain recycling period, failed revalidation of a CoSD). As described in UDFS in section Instruction Cancellation a T2S Actor will be able to cancel its Settlement Instructions under the following conditions : When the Settlement Instruction is not yet Settled or Cancelled ; When there are no pending cancellation requests for the same Settlement Instruction; When the Referenced Settlement Instruction is identified as CoSD, and the Instructing Party is the relevant CSD or the relevant Administering Party; When there is a Realignment Instruction related with the Referenced Settlement Instruction that fulfills a CoSD Rule, and the Instructing Party is the relevant CSD. Additionally T2S automatically cancels Unmatched Settlement Instructions after a certain recycling period (currently 20 working days) User Requirements and Adaptation Impact Mt will adapt the cancellation process currently available in X-TRM in order to support the function processing described in the table below: FUNCTION NOTE REFERENCES USED Cancellation of Unmatched S.I. sent by participants X-TRM reference or T2S reference Cancellation Matched S.I. sent by participant X-TRM reference or T2S reference Cancellation of Matched S.I. sent by Participants must be X-TRM reference or T2S 35

36 Exchanges, CCPs, Monte Titoli, Bank of Italy authorized in order to use this function Automatic Cancellation of Unmatched S.I. Automatic Cancellation of Matched S.I. sent by Exchanges, CCPs, Monte Titoli, Bank of Italy Process managed by T2S activated after recycling period Process managed by MT activated at Expiry Date reference (only one leg cancellation allowed) n.a. n.a. Table 6-2: Cancellation Requirement ID T2S-UAR-PS-0130 T2S-UAR-PS-0140 T2S-UAR-PS-0150 T2S-UAR-PS-0160 T2S-UAR-PS-0170 Requirement Description Participants will be able to cancel Settlement Instructions according to T2S rules. Indirectly Connected Participants will be able to cancel Settlement Instructions using either the X-TRM s reference or the T2S reference. The Expiry Date ( Data Fine Validità ) currently managed in X-TRM will no longer be supported for the SI sent by Participants. The Expiry Date ( Data Fine Validità ) currently managed in X-TRM s will be supported for already matched SI sent by Exchanges, CCPs, Monte Titoli, Bank of Italy. MT-X (U2A) will be adequately adapted in order to allow the manual cancelation of SI in T2S. 6.7 Allegement Scope The scope of this section is to describe how the allegement lifecycle is going to be adapted in T2S. Currently the risposta transaction (with a matching indicator = 2 ) in X-TRM represents the Allegement Notification for the counterparty. This information is sent to the participants using G56/G70 flows. Regarding the management of allegement sent by those CSD which do not operate in T2S (External Settlement) please refer to Annex T2S - Cross Border Settlement v T2S Impact Allegement messages in T2S are used to inform the participants that a transaction, e.g. a settlement or a cancellation instruction, on which they are identified as a counterparty and for which their leg is missing has been sent to T2S. The Allegement s lifecycle consists of the following information : Allegement Notification : this information is sent to a counterparty of an Unmatched Settlement Instruction; 36

37 The information below are sent to the counterparty, only after the receipt of an Allegement Notification: - Allegement Remove : when the underlying Settlement Instruction has been matched ; - Allegement Cancellation: when the underlying Settlement Instruction has been cancelled before matching ; Allegement Reporting: this report, also know as Statement of Allegement, provides information about the list of Settlement Instructions that are still to be matched and where the receiving participant is indicated as the counterparty; T2S provides specific messages to support the Allegement s lifecycle described above. Two parameters (available only to the T2S Operator) are used in T2S for the management of the Allegement process workflow: Standard Delay Period: a pre-definite period of time which starts on the first unsuccessful matching attempt. Before cut-off: a pre-definite period of time which will start before Cut-Off and during which the Allegement messages are immediately generated. After the T2S Business validation, the Settlement Instruction undergoes the first matching attempt and, if unsuccessful, it generates, after the standard delay period, an Allegement Notification that will be sent to the Participant identified as the counterparty of the instruction User Requirements and Adaptation Impact MT will adapt the Allegement process in X-TRM in order to be compliant with the same T2S process. This will be achieved by modifying the lifecycle of the risposta transaction (with a matching indicator = 2 ) which in X-TRM represents the Allegement Notification for the counterparty. For this transaction the matching indicator will not turn into a matching status ( 3 ). The diagrams below show the new Allegement lifecycle in T2S context. 37

38 Figure 6-1: X-TRM Allegement Management In a scenario having two ICPs the above diagram will not be impacted with any significant changes. Requirement ID T2S-UAR--PS-0180 Requirement Description Participants will be able to use the current allegement notification (refer to section Reporting). 6.8 Matching Scope The scope of this section is to describe how matching will be adapted in T2S where all the Settlement Instructions will be managed by a single matching engine. The matching engine compares settlement instruction s details provided by the buyer and the seller of securities in order to ensure that both parties agree on the Settlement terms T2S Impact In order to avoid redundancy and to submit the Settlement Instructions, sent either by indirectly connected or by directly connected participants, to a single matching process, the matching service currently implemented in X-TRM will be replaced by the matching service in T2S. Matching is managed in the T2S engine by verifying the values of specific identified fields which are classified in: Mandatory matching fields: these fields have to be valorized in the instruction and the values should be the same in both Settlement Instructions except for Settlement Amount for 38

39 DVP/PFOD for which a certain tolerance is admitted and for Credit/Debit Code (CRDT/DBIT) and Securities Movement Type Deliver/Receiver (DELI/RECE), which values match opposite. Non Mandatory matching fields are further differentiated into : - additional matching fields: this fields are initially not mandatory but when one of the counterparties provides a value for them in its instruction then their values have to match. In other words, once an Additional matching field is filled in by one Counterparty, the other Counterparty shall also fill it in, since a filled-in Additional matching field cannot match with a no value. - optional matching fields: a filled-in field that can match with a no value, but that requires that when both Parties provide a value, the values have to match. The table below reports the complete list of T2S matching fields and the adaptation of the corresponding X-TRM fields. X-TRM FIELDS (ITALIAN NAME) Emittente (2) Controparte (2) Codice di Sistema di Custodia Emittente Codice di Sistema di Custodia Controparte (1) Data di Regolamento Data Eseguito Codice Oggetto Negoziato Quantità Controvalore Valuta di Regolamento Segno Verso Controvalore n.a. Settlement Transaction Condition (1) Trade Transaction Condition (1) T2S FIELDS Delivering / Receiving Party BIC (based on Securities Movement Type) CSD of Delivering / Receiving Party (based on Securities Movement Type) Intended Settlement Date Trade Date ISIN Settlement Quantity Settlement Amount Currency Securities Movement Type Credit / Debit Indicator Payment Type (this fields will be fill automatically by the X-TRM enrichment process) Settlement Transaction Condition (Opt Out) Trade Transaction Condition (CUM / Ex Indicator) TYPE OF MATCHING FIELDS Mandatory Additional (1) (2) Codice BIC Beneficiario Emittente Client (1) (2) Codice BIC Beneficiario Controparte Common Trade Reference (1) of Delivering / Receiving Party (based on Securities Movement Type) Common Trade Reference Conto Regolamento Titoli della Controparte (1) Securities Account of Delivering / Receiving Party Optional 39

40 X-TRM FIELDS (ITALIAN NAME) T2S FIELDS TYPE OF MATCHING FIELDS (based on Securities Movement Type) (1) New information that will be added in X-TRM messages (2) The mapping of these fields in the settlement instruction could change based on the configuration described in section Table 6-3: X-TRM and T2S matching fields With specific regard to the counterparts fields in the settlement instruction, matching in T2S will take place on three levels: Level 1: receiving / delivering CSDs; Level 2: receiving / delivering party; Level 3: securities account of receiving / delivering party and client of receiving / delivering party. Level 1 and Level 2 are mandatory, whilst Level 3 is optional. The remaining fields, currently used for Matching in X-TRM, but not in T2S, will still be managed in XTRM only for enrichment purposes. These fields are: Rateo Unitario, Importo Spese, Provvigione Totale, Prezzo, Cambio, Controparte Centrale, Tipo Operazione. The end-of-validity date field ( Data di Fine Validità ) as per will be supported in transactions but not managed for matching purposes (par. 6.5). The use of the optional matching fields (market practice) is being analyzed within the Harmonization Steering Group (HSG and the Italian NUG Task Force on collateral management, reference section 0) User Requirements and Adaptation Impact Requirement ID T2S-UAR-PS-0190 Requirement Description X-TRM messages will be adapted in order to support all the matching fields required by T2S. 6.9 Bilateral Netting (Net and Gross Margining Model) Scope Scope of this section is to describe how the bilateral netting process will be adapted in the T2S context. The trades coming from guaranteed markets are currently used for the calculation of the bilateral balances. Only the net balances, deriving from the bilateral aggregation of all trades between the CCPs and each of their participants and between the CCPs themselves, are sent to the current Net Settlement System (ExpressII). 40

41 All the other trades, coming from not guaranteed market or sent by participants, are not netted; they are individually sent and settled in the current Net or Gross Settlement Systems depending on the intended settlement date T2S Impact When MT migrates in T2S the currently used net and gross settlement platforms will be completely replaced by the T2S gross settlement platform. However the same algorithm and rules (model A and model B) currently used for the calculation of the net bilateral balances will remain in place in the XTRM system for more details please refer to appendix User Requirements and Adaptation Impact Requirement ID T2S-UAR-PS-0210 Requirement Description All Participants will continue to receive, through MT infrastructure, the pre settlement reporting regarding their activity on guaranteed markets Forwarding to Settlement System processes Scope Scope of this section is to describe how the forwarding to the settlement system will be changed with the introduction of T2S that will replace the current settlement platform T2S Impact Currently MT forwards settlement instructions to: Net (ExpressII) or Gross (Express I) Settlement Systems External CSDs (Settlement Agent services) Other external Settlement System 4 (only routing services). MT s settlement platforms for both net and gross settlement (Express II and Express I) will be completely decommissioned and will be replaced by the T2S platform for: Intra CSD Settlement (both parties have their security account in MT) Cross CSD Settlement (all the CSDs involved are in T2S) 4 As reported in document [VIII] the X-TRM service implements the routing of trades closed on markets (e.g. EuroMOT) and other trading systems (e.g. EuroTLX) as well as transactions entered by the users, to settlement systems other than Express II, currently Euroclear Bank and Clearstream Luxembourg. 41

42 External CSD Settlement (at least one CSD involved is external to T2S). The adaption for cross and external CSD settlement are described in the par. 7.2 of this document. No T2S impact for routing services towards other external Settlement services is envisaged. The table below provides details of the forwarding time for each type of trade. SOURCE SECURITY TYPE GUARANTEED Exchange Exchange Exchange Listed only in Cash Markets Listed only in Repo Markets Listed in both Cash and Repo Markets Yes Yes Yes TRADE TYPE CCP balance CCP balance CCP balance Exchange not relevant No DVP MATCHING STATUS Already matched (FOR INTRA CSD SI) Already matched (FOR INTRA CSD SI) Already matched (FOR INTRA CSD SI) Already matched (FOR INTRA CSD SI) Participants not relevant No ALL 6 (FOR INTRA AND CROSS Matching in T2S CSD SI) Participant (External-CSD settlement) not relevant Table 6-4: Details for type of trade No DVP RVP FOP Already matched FORWARDING TIME After After Hours Market Closing at Trade date 5 After Repo Market Closing at SD-1 After Repo Market Closing at SD-1 Real time Real Time Real time User Requirements and Adaptation Impact Requirement ID T2S-UAR-PS-0220 T2S-UAR-PS-0230 Requirement Description All Participants will be able to continue to send their transactions to X- TRM in RNI, ex LU6.2, SWIFT ISO15022 and ISO Forwarding process towards T2S will be totally in charge of MT. Directly Connected Participants will have to implement their forwarding systems using the ISO20022 implemented in T2S. When the DCP does not use MT platform the forwarding process towards T2S will be totally in charge of DCP. 5 The timing of forwarding will be linked to the X-TRM closing time that will be set after an appropriate interval after the Closing of the After Hours Market. This timing could be modified in the future, in case the markets will allow to modify trades (with impacts on bilateral balances) after the Trade date. 6 DVP, RVP, DWP, RWP, FOP, PFOD 42

43 Requirement ID T2S-UAR-PS-0240 Requirement Description The routing services towards other external Settlement Systems remain unchanged (I.e. EuroMot) 43

44 7. Settlement 7.1 Intra-CSD Settlement Scope Scope of this section is to describe how the settlement between tow CSD s participants will be managed once migrated in T2S. This functionality, which is currently managed by ExpressII (Net and Gross settlement cycles), settles transactions between MT participants which owns a securities account in Monte Titoli. The current settlement cycles uses automatic mechanism of collateralization (self and firm). Regarding the management of partial settlement, ExpressII cancels the original transaction and creates two new transactions, the first one reports the partially Settled quantity and the other the unsettled quantity. In the so called shaping process specific types of transactions could be divided in partial transactions based on quantity thresholds or amount thresholds. Figure 7-1: Flows of the messages in Intra CSD Settlement T2S Impact As described in UDFS in section 1.6. Application Processes Description the settlement will be fully managed by T2S including the mechanism of auto-collateralization. The self and firm collateralization are completely dismantled. The auto-collateralization s mechanism is described in Italian NUG Task Force on collateral management operating set-up (see par.0). 44

45 The settlement of the transactions in T2S is done, always on a gross basis, differently depending on settlement windows (Night-time settlement NTS or Real-time settlement RTS). In the NTS the transactions are settled based on specific sequences. In both cases T2S uses optimising application processes in a way to increase the number and value of transactions settled according to available resources. The Partial Settlement is performed in specific timeframes: during the Last NTS cycle in the sequence X and during the RTS at 2:00 p.m. and 3:45 p.m. X-TRM will be adapted in order to manage all the statuses foreseen by the Settlement Instruction s lifecycles in T2S. Regarding the partial settlement, the transactions will not anymore be cancelled but they will include the related statuses, quantity and amount partially settled. The what so called shaping process will not be dismissed but will be used in order to re-shape the spot leg instruction in Repo OverNight transaction. Further information will be available in Rules and Instructions for Services User Requirements and Adaptation Impact Requirement ID T2S-UAR-ST-0005 Requirement Description The participant will be able to receive all status advice according to their message subscription and their connection operating model 7.2 Cross Border Settlement Service Description MT provides a single gateway to several security markets within and outside the Eurozone including ICSDs. Monte Titoli offers real time gross settlement for off-exchange transactions on a free of payment (FOP) and against payment (DVP) basis on its cross-border markets network. Target2 Securities provides two settlement options, for the cross-border transactions, which difference is determined by the relationship that the CSDs have with T2S : Cross-CSD Settlement: settlement between participants not belonging to the same CSD and being all the CSDs involved in the chain (investor CSDs, technical issuer CSDs and issuer CSD) in T2S. All type of transaction (FOP, DVP, DWP, etc.) are supported. External-CSD Settlement: settlement between participants not belonging to the same CSD and one or several of the CSDs involved in the chain (investor CSDs, technical issuer CSDs and issuer CSD) being external to T2S. Only FOP or DVP/RVP transactions are supported. 45

46 Monte Titoli will continue to provide its participants with the Cross Border services (FOP, DVP. etc.) adapted to T2S processes. The External-CSD Settlement will be made available to MT s participants only in an indirectly connected operating model, i.e. through MT s technical infrastructure. MT will therefore forward to T2S the transactions exclusively to support their Settlement in the Foreign Settlement Platform. These transactions will be sent to T2S as already Matched Settlement Instructions. Participants shall rely only on the statuses provided through MT s technical infrastructure. In the same scenario RVP transactions are sent to T2S as receive free of payment (RFP) instructions. The cash legs will be managed as indicated in the section Pre-funding. Figure 7-2: Flows of the messages in Cross Border Settlement Transaction Acquisition Scope This section integrates and completes the description of the Transaction Acquisition in X-TRM (see par.6.1) with the details specific for the Cross Border scenario T2S Impact Participants can forward the Settlement Instructions both in a directly and in an indirectly connected operating model. For Cross Border Transactions, for which the Settlement occurs outside T2S (external-csd Settlement) participants will be enabled to operate through the MT technical infrastructure, therefore to operate only indirectly connected to T2S. 46

47 Impacts for this functionality in T2S are the same as the ones described for the acquisition in an Intra-CSD Scenario. The messages have to be adapted in order to contain additional information and options offered by T2S. No additional impacts will have to be managed by MT participants User Requirements and Adaptation Impact Requirement ID T2S-UAR-ST-0020 T2S-UAR-ST-0030 Requirement Description Participants will be able to use, based on their connectivity mode, Monte Titoli (both A2A and U2A) or T2S to send Cross Border transactions but will use only the indirect connectivity to send transactions related to External-CSD settlement's scenario. This S.I. will be completed with all information required support Cross Border transactions (counterpart CSD code, counterpart security account etc.) Validation Scope This section integrates and completes the description of the Validation in X-TRM (see par. 6.2) with the details related to the Cross Border scenario T2S Impact The Cross Border Transaction s Validation is composed of : T2S Business Validation: this validation is executed for every Settlement Instruction sent to T2S with specific regard to the static data related to the Cross Border setting. X-TRM Validation: Additional specific validations are managed for External-CSD Settlement. Monte Titoli will configure additional rules (restrictions), in addition to those rules used in T2S Business Validation. Due to the fact that external-csd transactions will be accepted only through X-TRM, no additional rules in T2S are needed for this scenario User Requirements and Adaptation Impact Cross-CSD Settlement Instructions inserted via an indirect mode will only be considered accepted if they ve passed both validation processes (X-TRM and T2S). The Settlement Instructions inserted via a direct mode, after having passed the standard T2S s Business Validation, could be subject to an additional validation process that is managed by using the T2S CSD Validation Hold that allows the impacted CSDs to further validate the instructions according to rules that will be bilaterally agreeed. 47

48 Specific validation rules to support External-CSD Settlement scenarios are created in X-TRM by Monte Titoli and will be documented in the SPU document. The transactions which fail to pass these validation rules will be rejected and not sent to T2S, while those that pass will be forwarded to T2S and submitted to the further T2S Business validation process. Only after successfully passing both MT and T2S validation processes the transactions will be considered as accepted. Requirement ID T2S-UAR-ST-0040 Requirement Description Participants will have to adapt their outbound messages towards X- TRM in order to include all the information necessary for Cross Border Settlement (counterpart CSD, foreign counterpart and its account) Pre-funding Scope The scope of this section is to describe how prefunding for Cross Border transactions will be managed in T2S T2S Impact Cross Border transactions currently require that MT blocks either securities or cash before sending the settlement instructions to the counterpart CSD. Securities or Cash will have to be blocked also in T2S in order to manage Cross Border settlement. On Cross-CSD scenarios, with transactions in currencies eligible in T2S, no pre-funding process is needed. T2S, after having checked (provision check process) that the resources available (i.e. securities account, cash balance and CMB) are sufficient, starts with the booking process. When Cross Border transactions are settled outside T2S (External-CSD scenario 7 ) prefunding is managed by MT: Securities legs: the securities provision for the delivering transactions (FOP or DVP) is made using the T2S s functionality CoSD Securities Blocking; Cash legs: the cash provision for the receiving transactions (RVP) is made using a settlement instruction payment free of delivering (PFOD) that debits the dedicated cash account of the participant and credits the cash account of Monte Titoli. This instruction will be linked in T2S with the RFP 8 instruction (the securities legs of the original RVP transaction). 7 Where only FOP, DVP and RVP transactions are supported. 8 RFP Receive free of payment 48

49 This pre-funding phase takes place during the intended settlement date at 7am User Requirements and Adaptation Impact Requirement ID T2S-UAR-ST-0050 Requirement Description The pre-funding process will be automatically managed by Monte Titoli. Participants will receive a complete set of notification messages (both for cash and for securities) either trough X-TRM or through T2S depending on to the connectivity operating model they have chosen. 9 the specified time can change according to the Service Availability of the CSD. 49

50 8. Reporting MT currently provides a real time notification for the settlement of a settlement transaction and provides a comprehensive reporting for both the Pre-Settlement phase and the various settlement phases. In addition MT provides daily and monthly statements of holdings. There are two types of reporting: 1. Reports pushed by the system received according to a configured subscription (automatic mode); 2. Outcome received according to specific requests sent to the system ( on demand mode). The table below shows the current reporting managed in MT. ID FLOW/MESSAGE 71N G56 ROM G56 ACB G32 G70 MT706/707 DESCRIPTION Settlement Instruction/Restriction confirmation - Real time notification of each single securities account movement Pre-Settlement Report - Details the status of transactions entered in X-TRM but not yet settled (and settled only for gross settlement) Pre-Settlement Report Continuously updated details the status of transactions entered in X-TRM but not yet settled (and settled only for gross settlement) Several layouts for specific Pre-Settlement and Settlement reporting Push information - Status update of all settlement instructions Statement of holding (daily/monthly) MT716/717 Statement of holding on demand on a financial security balance (Request/Outcome) Table 8-1: Current Reporting in flow mode The table below shows the request/notification messages to be used in order to receive the G32 and G56 in an on demand mode. ID FLOW/MESSAGE G30 / G31 G54 / G55 G57 / G58 DESCRIPTION General Information Request Message / Notification (G32 report) Operation Information Request / Notification (G56 report- ROM) Continuous Updating Information Request / Notification (G56 report - ACB) G33 / G34 Specific request flow for collateral limits / Notification (G32 report, layout 10 ) Table 8-2: Current Reporting in on demand mode 50

51 The set of reports that MT will make available after the migration in T2S is shown in following table and has been developed according to the following principles: MT will maintain the G56 ACB, the G70 and the RNI 71N Settlement Notification flows. The same reports will be made available also in ISO15022 and ISO20022 standard. The G56 flows will be enriched with information on settled transaction as well as on pending transactions. The G56 flow will be sent by MT automatically at the end of Night Time Settlement (approximately at a.m.) and at the end of Real Time Settlement (approximately at p.m.). G56 will also be made available in on demand mode. MT will provide the G70 flows with periodic updates (approximately every 5 minutes). The G32, G33 and G34 flows reports will be dismissed. The G54 and G56 ROM on demand will either be dismissed or reviewed in terms level of parametric request (TD; ESD; ISIN; X-TRM code; "Tipo Mercato"..ect). The reports will be made available to all participants that subscribe for the specific reporting service and will include information only for the instructions sent to T2S through MT infrastructure. MESSAGE / REPORT (1) MODE(2) MS RNI FT CONNECTIVITY THROUGH MT INFRASTRUCTURE ISO SWIFT ISO FILEACT EX- LU6.2 DIRECT WITH T2S MT-X A2A U2A Allegement Notification Push No No MT578 Sese.028 No No n.a. Sese.028 n.a. Statement of Push No G70 MT586 Semt.019 G70 Yes Yes Semt.019 Yes allegement Pull No G56 MT586 Semt.019 G56 Yes Yes tbd (3) Yes Settlement Status Advice Push No No MT548 Sese.024 No No n.a. Sese.024 n.a. MT544 Settlement MT545 Push No No Confirmation MT546 MT547 Sese.025 No No n.a. Sese.025 n.a. Statement of G56 Push No G56G70 MT537 Semt.018 pending G70 Yes Yes Semt.018 Yes transactions Pull No G56 MT537 Semt.018 G56 Yes Yes Semt.027 Yes G56 G56 Statement of Push No MT536 Semt.017 Yes Yes Semt.017 Yes G70 G70 transactions Pull No G56 MT536 Semt.017 G56 Yes Yes Semt.027 Yes (1) All this information will be available to the participants according to their message and report subscription. (2) Push : the notification if sent automatically by the system - Pull : the notification is sent by the system after user request (3) Question raised to ECB experts Table 8-3: Pre-Settlement/Settlement reporting in T2S 51

52 8.1 Settlement confirmation Scope As a result of each movement on the participants accounts, MT currently sends its clients a specific message notification (MT544/545/546/547 for those opting for SWIFT messaging), reporting the results of the Settlement Instruction T2S Impact For each Settlement Instruction settled, T2S will send a Transaction Confirmation to the Direct Participant; likewise, for each Settlement Restriction settled, T2S will send an Intra Position Movement confirmation in standard ISO User Requirements and Adaptation Impact Requirement ID T2S-UAR-RP-0010 T2S-UAR-RP-0020 Requirement Description When a settlement instruction is settled indirectly connected participants will receive SWIFT ISO15022 message MT544/545/546/547 or SESE.025 ISO20022 message When a settlement restriction is settled, indirectly connected participants will receive SWIFT ISO15022 message MT508 or SEMT.015 ISO20022 message 8.2 Presettlement/Settlement Reporting - G56/G70 File Scope These files will contain details about the status of transactions entered in X-TRM both those already sent and those not yet sent to the settlement engine in T2S. They allow X-TRM participants to receive a real time status report on all transactions present in the X-TRM system distinguished between: Statement of Allegement Statement of pending transaction Statement of settled transaction As currently, details for the transactions that have not been passed through X-TRM (as Corporate Actions, Issuance Instructions etc.) will not be available in the G56 ACB and G70 reports. X-TRM can provide participants with the G56 ACB report (full mode) also every morning at the end of the overnight processing and at the end of the daily Real Time Settlement cycle. 52

53 Any time during the day, when the X-TRM Service is open, each participant that has subscribed to receive the G56 ACB flows (according to the Counterparties Static Data service, function profile) can send X-TRM a request for information (G57 request message). X-TRM will produce the corresponding acknowledgement (G58 response message) followed by the G56 ACB flow, containing all the transactions updated during the time interval between the previous and the last request (delta mode) according to the parameters inserted in the G54 request. Each participant that has subscribed to receive the G70 flows (according to the Counterparties Static Data service, function profile) will be able to periodically receive the report during the RTS time T2S Impact As the Directly Connected Participants send and manage Settlement Instructions directly in T2S, MT will not provide them with the corresponding information in the G56 and G70 reports. Figure 8-1: Presettlement/Settlement reporting (G56) 53

54 8.2.3 User Requirements and Adaptation Impact Requirement ID T2S-UAR-RP-0030 T2S-UAR-RP-0040 Requirement Description Participants will be able to receive G56/G70 flows but only for the instructions inserted in MT systems. No impacts on how to request and get the file. 8.3 Participant accounting - Daily statement of holding Scope At the end of the business day, MT currently sends its participants the statement of holding with the details of movements, positions and blocks. On a monthly basis, MT sends its participants a Monthly statement showing account movements in financial instruments registered during the preceding month. MT Participants will be able to send position inquiries in order to receive information regarding their own securities positions T2S Impact Monte Titoli will provide its participants, both Directly Connected and Indirectly Connected, the official daily statement of holding. The statement of holding sent by T2S is to be considered provisional until the receipt of 706. Figure 8-2: Daily statement of holding (706) 54

55 8.3.3 User Requirements and Adaptation Impact Requirement ID T2S-UAR-RP-0050 T2S-UAR-RP-0060 T2S-UAR-RP-0070 T2S-UAR-RP-0080: Requirement Description All participants will be able to subscribe and receive MT s daily statement of holding and Statement of transactions (Msg RNI 706, Swift ISO15022 MT535/MT536 or ISO20022 SEMT.002 and SEMT.017).The messages will contain both securities account codes (current internal MT code and T2S Securities Account code) and the new T2S reference identification of the Settlement Instruction. All participants will be able to subscribe and receive MT s monthly statement of holding (Msg RNI 707, Swift ISO15022 MT535 or ISO20022 SEMT.002).The messages will contain both securities account codes (current internal MT code and T2S Securities Account code) and the new T2S reference identification of the Settlement Instruction. All participants will be able to subscribe and receive MT s on demand statement of holding on a financial security balance(msg RNI 717 by sending a RNI 716 request, Swift ISO15022 MT535 by sending a MT549 request).the messages will contain both securities account codes (current internal MT code and T2S Securities Account code) and the new T2S reference identification of the Settlement Instruction. MT's participant will receive in their statement of holding (A2A and U2A) the available, and not available sub-balances with the distinction for Blocked security, Collateralized, CoSD blocking of securities, Earmarked, Reserved (see par.11) 8.4 Real time Status advice notification (push information) Scope In addition to the settlement notification already provided, participants will be able to subscribe to receive from T2S all the possible status changes that a settlement instruction can assume during its life cycle. The scope is the management of the subscription available for the push messaging service. The scope of this section includes also the analysis of the possibility for ICPs to choose to receive only certain messages from MT T2S Impact The T2S subscription service allows a CSD or another duly authorized T2S Actor directly connected to the T2S platform, to subscribe the receipt of messages (e.g. status advice). T2S will provide these messages in ISO Below some possible filters applicable to the message subscription system in T2S: 55

56 FILTER Message Type Instruction Type Party Securities Account ISIN T2S Dedicated Cash Account Instruction Status ISO transaction code Table 8-4: Parameters of subscription DOMAIN Settlement Instruction, Settlement Restriction, ecc. FOP, DVP,DWP,PFOD Bic code Accepted, rejected, matched, cancelled, settled, etc. CORP, CLAI, TRAD etc. In order to provide the Indirectly Connected Participants the messages and reports they choose to receive MT will implement in T2S the appropriate message subscription. Moreover, upon request, MT will subscribe messages in T2S that allow a participant to receive also specific push information (e.g. status advices of a particular type of Settlement Instruction) User Requirements and Adaptation Impact Requirement ID T2S-UAR-RP-0080 T2S-UAR-RP-0090 Requirement Description Indirectly Connected Participants will subscribe in MT the set of messages they choose to receive in RNI, IS and ISO20022 standard. Directly Connected Participants will be enabled to subscribe in T2S the set of messages they request to receive. 56

57

58 INDIRECT PARTICIPANT MT USER INTERFACE Monte Titoli T2S User Requirements 9. Custody Services T2S as settlement platform aims to substitute the settlement processes of the participating CSDs without impacting their interaction models with the Issuer and the Intermediaries. The following diagram shows the High Level Schema of MT Custody services in T2S context and the different interactions of directly / indirectly connected participants in T2S. DIRECT PARTICIPANT MT Custody Services Admission of Financial Instruments Centralization Government Bond Coupon Stripping Participant Accounting Safekeeping of physical certificates Corporate Action Mandate Announcement Distribution Reorganization Reporting INTERFACE T2S MT STATIC DATA Figure 9-1: Custody - Schema 9.1 Admission of financial instruments Scope This section covers the management of the admission of financial instruments to settlement, custody and other additional services. The management of non-fungibles securities is not covered. 58

59 Although a residual number of un-fungible financial instruments is still centralized in MT, there are currently no new issues forecasted and those that are still managed will expire before the go live planned date of the 1 st wave of T2S T2S Impact MT securities static data contain all the information needed by each service to perform the settlement, the Corporate Actions and other additional services. T2S requires only a limited set of information for settlement processing purposes. The securities eligible in T2S must comply with the following criteria: have an ISIN code, as securities instrument identifier are held with CSD in T2S settled in book-entry form are fungible (from a settlement processes perspective). Additionally MT will have the chance to decide whether to admit and centralize securities that are not eligible in T2S and whether to create accounts in T2S for those securities. For this reason a MT dedicated procedure, shared with participants, shall be prepared, defining the securities eligibility/not eligibility criteria and how they will be managed in terms of rules and requirements. MT will be responsible for the setting up and the maintenance of securities in T2S in the following cases: when it is the Issuer CSD of the security; when it is the Securities Maintaining Entity (SME), i.e., the CSD within T2S in charge of creating and maintaining the data for a foreign security issued outside T2S. T2S requires CFI code ( 10 ) as a mandatory field. This attribute already exists in the MT265 bis (the module used by Issuer for requesting of admission of securities), but it is not available for the users. The CFI code will be mandatory and stored in the static data of MT but it will be not used in the communication flows between MT and customers, ensuring an automatic alignment with T2S static data User Requirements and Adaptation Impact Requirement ID T2S-UAR-CU-0010 T2S-UAR-CU-0020 Requirement Description CFI code will be a mandatory field in MT265 bis form. The download and the consultation of the adapted securities list (MT23 form) with CFI code, will be available on daily basis in the MT-X platform. 10 The CFI code (Classification of Financial Instruments) is an international standard classification (ISO 10962) of financial instruments. The Italian National Agency responsible for assigning the CFI code is Bank of Italy. 59

60 9.2 Centralization The centralisation operation can be performed either on sight or with a deferred date. Financial instruments credited to the securities account of the beneficiary Intermediary are immediately available for settlement. Below some typical operations of the issuer: 1. Centralization of new issuances of financial instruments (First Issuance) 2. Issuance of new tranches of financial instruments already issued (Mark-Up) 3. Reduction of nominal value as a result of repurchase / redemption (mark-down). These transactions will be available in T2S only through MT s technical infrastructure (Indirectly connected operating model) both A2A and U2A solutions. Issuance, mark-up and mark-down transactions are available to both intermediaries which have their securities account opened in MT and to intermediaries that have their securities account in another CSD inside T2S and that has a link with Mt. The operating model for the latters is different in the following aspects: MT must be authorized (POA) to instruct on their T2S securities account opened in the other CSD The issuer has to communicate MT, the party BIC code and its T2S securities account code The transaction is managed as a cross-csd settlement and MT sends FOP instructions to be matched in T2S The following table summarize for each MT message type, the corresponding ISO transaction code in T2S: MT message MT Type Description ISO Transaction Code First Issuance of Financial 5/0 Issuance (ISSU) Instrument Msg 710 New issuance of financial MT542 5/2 Mark-up (MKUP) instruments 6/2 Reduction of nominal value Mark-Down (MKDW) Centralization of new issuances of financial instruments (First Issuance ) The Issuer currently sends MT the elements required to perform the instructions: The ISIN code of the financial instrument to be centralized The value date (on sight or deferred date) for the instruction to be settled The amount (quantity/nominal value) of the financial instrument to be credited The beneficiary/ies security/ies account The above elements can be sent also through MT s browser based solutions MT-X or using the RNI 710 message 60

61 Financial instruments credited to the securities account of the beneficiary Intermediary are immediately available at the intended settlement date T2S impact The Centralization management and monitoring processes will remain in charge of MT.The transaction will be performed as it currently is, either on sight or at a deferred date. The process of managing and monitoring the operation of centralization (i.e. verifying between the deliberated amount and the issued amount) remains in charge of MT which will update those information in its systems. The diagram below describes the Centralization process and the corresponding information flow in T2S. Figure 9-2: Centralization process for MT participants An issuer instructs directly MT using a specific communication channel and will receive notification by MT in the same way. Depending on the choice selected, Issuer receives the corresponding notification (i.e. RNI N, MT542-MT546, sese.023-sese.025). MT prepares and sends to T2S already matched FOP instructions linked together for a settlement on all-or none bases ( 11 ). As in the current process, the instruction is delivered 11 The model describes the process in place when both parties are configured as MT participants. Please refer to par.9.2 for details on the process that involved a participant to another CSD. 61

62 immediately for "on sight instructions or only at the intended settlement date for deferred date instructions. Issuers and ICPs, for all transactions settled, will receive a notification by MT; the table below summarizes inbound/outbound messages of Centralization workflow. Message Description connectivity Rni/MT-X Iso15022 Iso20022 from / to Centralization order Msg 710 MT 542 Sese.023 Issuer/MT Acknowledgement Msg 71N MT 548 Sese.024 MT/Issuer - - Sese.025 T2S/DCP MT/ICP Msg 71N MT 546 Sese.025 Settlement confirmation MT/Issuer Msg 71N MT MT/DCP On request only User Requirements and Adaptation Impact Requirement ID T2S-UAR-CU-0030 Requirement Description The 710 message and the corresponding ISO and messages (MT542, sese.023) will be adapted in order to accept the new T2S Securities account code, the CSD/parties code and the new message type for the management of the centralization of new issuances Issuance of new tranches of already issued and centralized financial instruments (Mark UP) New tranches of financial instruments are currently issued by sending MT the corresponding instruction either through MT s browser based solutions MT-X or using the RNI 710 message. The issuer should send MT the new total issued value (previous value plus value of the new tranche) and the value of the tranche to be issued T2S impact The Centralization management and monitoring processes will remain in charge of MT. The transaction will be managed as it currently is: to be performed "on sight" or at deferred date. MT will monitor on the centralization operation (i.e. verifying between the deliberate amount and the issued amount) and will update those information. The overall operational model will be the same as the one described for the first issuance User Requirements and Adaptation Impact Requirement ID T2S-UAR-CU-0040 Requirement Description The 710 message and the corresponding ISO and messages (MT542, sese.023) will be adapted in order to accept the new T2S Securities account code, the CSD/parties code and the new message type for the management of the mark up / mark down. 62

63 9.3 Reduction of nominal value centralized as a result of repurchase / redemption (Mark-Down) Scope Monte Titoli enables Issuers to reduce the nominal value or quantity of centralized financial instruments that they have issued. The operation may be performed by the Issuer: in the Issuer's own securities account; in the securities account of any beneficiaries. The Mark Down Transactions on the Issuer s Securities account will be forwarded to T2S as already matched. The Mark down transactions on the second point, will be forwarded to T2S as settlement instructions to be matched. In this case the transaction will be moved to X-TRM platform in order to align to the procedure envisaged for the FOP to be matched T2S impact The diagram below describes the Mark-Down process and the interaction with T2S. Figure 9-3: Mark-Down process 63

64 The incoming message sent by Issuer, will be forwarded to T2S through X-TRM. Within T2S the S.I. will be processed in the life cycle of settlement instructions and managed by T2S actors. Validation, Instructing maintenance, Matching and Settlement are the components of settlement instruction life cycle. The intermediary counterpart receives the allegement notification (sese.028) from T2S and sends its leg of the transaction. The table below summarizes inbound/outbound messages of Mark-Down process: Message Description connectivity Rni/MT-X Iso15022 Iso20022 from / to Mark-Down order Msg 710 MT 540 Sese.023 Issuer/MT Mark-Down order - MT 542 Sese.023 ICP/MT Acknowledgment Msg 71N MT 548 Sese.024 MT/Issuer Mark-Down order - - Sese.023 DCP/T2S Allegement notification Msg G56 MT 578 Sese.028 MT/ICP Allegement notification - - Sese.028 T2S/DCP Settlement confirmation Msg 71N MT 544 Sese.025 MT/Issuer Settlement confirmation - - Sese.025 T2S/MT T2S/DCP Settlement confirmation Msg 71N MT 546 Sese.025 MT/ICP User Requirements and Adaptation Impact Requirement ID T2S-UAR-CU-0050 Requirement Description New allegement message for ICP/DCP (sese.028, G56). T2S-UAR-CU-0060 This transaction will require to be matched in T2S. 9.4 Government Bonds Placement operation Scope This section describes the placement of Government Bond int2s. Background information: As decided by Bank of Italy the operating models of Placement, Auction and Buyback concerning Government Bond, here proposed for T2S, reflect the current scenario, so it assumes that the parties who participate have a securities account in Monte Titoli T2S impact Government bonds are admitted after placement managed by Bank of Italy using the Placement of securities (NEWCOL) and settlement procedure managed by Monte Titoli 64

65 On the day of auction Bank of Italy informs MT using the 710 message the nominal value of each financial instrument placed and using G60 messages, the contracts concluded in relation to the auction. At the end of day of the auction, after the reconciliation of flows between Bank of Italy and Monte Titoli, the transactions will be sent in T2S using DVP and FOP settlement instruction linked. FOP instruction is used for placement received by Bank of Italy through 710 message. It contains the total nominal value of each financial instrument involved to the placement. For each instruction related to Auction (G60 flow containing the detailes of Auction), MT prepares a DVP Settlement instruction linked to the previous FOP instruction for Placement, using a link type "After" (for further details ref. Appendix ) When transaction is settled, Monte Titoli informs Bank of Italy and the Intermediaries of the outcome of settlement by notification messages (71N, sese.025, G56). All the settlement instructions not yet settled about 5 days after the intended settlement date will be cancelled by Monte Titoli User Requirements and Adaptation Impact Requirement ID T2S-UAR-CU-0070 Requirement Description MT will send the DVP and FOP settlement instructions to T2S the day of the auction after the reconciliation of flows between Bank of Italy and Monte Titoli. They will be settled at the intended settlement date Buy-back operation Scope This section describes the buy-back of Government Bond int2s T2S impact Buy-back auctions are managed by the Bank of Italy through the NEW-COL procedure, while their settlement is managed by Monte Titoli On the day of auction Bank of Italy informs MT using the 710 message the nominal value of each financial instrument repurchased and using G60 messages, the contracts of repurchasing in relation to the auction. The day of the auction, after the reconciliation of flows between Bank of Italy and Monte Titoli, the transactions will be sent in T2S using DVP and FOP settlement instruction linked together. When transaction is settled, Monte Titoli informs Bank of Italy and the Intermediaries of the outcome of settlement by notification messages (71N, sese.025, G56). All the settlement instructions not yet settled about 5 days after the intended settlement date will be cancelled by Monte Titoli. 65

66 User Requirements and Adaptation Impact Requirement ID T2S-UAR-CU-0080 Requirement Description MT will send the DVP and FOP settlement instructions to T2S the day of Buyback, after the reconciliation of flows between Bank of Italy and Monte Titoli. They will be settled at the intended settlement date Cash distribution of Government Bonds Scope This section describes the cash distribution of Government Bond int2s. Current the cash distribution of Government bonds takes place during the night cycle of ExpressII, in T2 platform with procedure 6 dedicated liquidity where the crediting is done on a RTGS or sub-account of beneficiaries T2S impact The cash distribution of Government Bonds will be settled in T2S. Payments on Government Bonds provide liquidity on DCA of beneficiaries during the first sequence dedicated to a Corporate action in the first night-time settlement cycle. Cash reporting is provide by MT by means of 7B2/566 custody messages. Unlike Cash distribution of Corporate Bond, for the Italian Government bonds the participants cannot choose to receive the payment in T2 directly from Monte Titoli; they will receive the payments in T2S only and, if needed, they can set the option for the automatic transfer of "CORP" funds from T2S to T2. At the Record Date, during T2S Start of Day phase, Monte Titoli sends Bank of Italy the amount of government bond to be paid, and after confirmation of amount, proceeds for crediting the cash to the DCA of Monte Titoli. Afterwards, Monte Titoli sends T2S already matched a payment free of delivery settlement instruction, for crediting the cash to the DCA of beneficiaries, ensuring the liquidity in night time settlement for funding. All Settlement instructions are linked together and settled on «all-or none» bases User Requirements and Adaptation Impact Requirement ID T2S-UAR-CU-0090 T2S-UAR-CU-0100 Requirement Description The already matched payment free of delivery settlement instructions (PFOD), will be identified with ISO transaction code set to CORP The cash distribution of Government Bond will be settled in the Night Time Settlement, in the sequence dedicated to a CA 66

67 9.4.4 Coupon Stripping/Unstripping Scope The term coupon stripping describes the process of splitting the coupons from a bond, creating the so-called strips and the hybrid strip that includes, for not indexed BTP, the last coupon amount and the principal bond repayments. In case the bond is inflation-linked, the component that varies according to the index is also separated (uplift principal)., Strips split from different securities, but with the same maturity, are mutually fungible included the hybrid coupon (for non indexed BTP). The term unstripping describes the opposite process. Stripping/Unstripping operations may be carried out on fixed-rate or index-linked government bonds which are not prematurely redeemable (nominal BTPs and inflation-linked BTPs) T2S impact A Stripping/Unstripping procedure does not exist in T2S with the same characteristics of Italian practice, therefore this functionality will be made available to Monte Titoli participants only through its technical infrastructure, therefore it will be managed only in an indirectly connected operating model. The participants will continue to use RNI 7A7-7A8 or MT565 messages to request stripping and unstripping. All these transactions should be instructed and processed as linked transactions to be settled on an all-or-none basis with ISO transaction code CORP. The chart below describes the coupon stripping/unstripping process and the corresponding information flow in T2S: Figure 9-4: Stripping 67

68 User Requirements and Adaptation Impact Requirement ID T2S-UAR-CU-0120 Requirement Description Coupon stripping will available for participants trough Indirect mode only 9.5 Position change confirmation Scope MT, after each securities account movement, sends a specific message confirmation (msg 71N) to participants informing them of the operation result or indicating their updated account balance T2S Impact In T2S it is not possible to receive systematically the updating of the financial instruments position after each settled instruction, therefore the message 71N, and the corresponding ISO and messages, of real time confirmation will be regularly sent to participants, but it will not show the new balance resulting from the Settlement Instruction User Requirements and Adaptation Impact Requirement ID T2S-UAR-CU-0110 T2S-UAR-CU-0120 Requirement Description The RNI 71N message will be changed because it will contain both coding systems (current MT Securities Account code and T2S Securities Account code) and will not contain the new position information. All participants will be able to subscribe 71N message. DCPs will be able to subscribe sese.025 message from T2S 68

69

70 10. Corporate Actions The settlement service for Corporate Actions in Monte Titoli is currently integrated and managed within the Custody Service. The introduction of T2S will not impact MT processes with its Issuers or Intermediaries in terms of management of the following processes: Mandate Announcements Processing Election In other words Custody services will be provided by Monte Titoli to its participants (both ICP/DCP) according to the current service model i.e. through Monte Titoli technical infrastructure. In addition the DCPs will receive securities and cash reporting/settlement notification directly to T2S also. The corporate actions will be managed in T2S by managing the securities accounts (SAC) and, if cash transactions are requested, by managing the corresponding linked DCAs or RTGS account in T2. T2S will manage settlement of securities in euro and other eligible currencies. For payments in euro, MT participants will be able to choose whether they are credited or debited in their DCA in T2S or their RTGS account in T2. There will not be differences for participants who choose to pay in T2 or T2S in terms of cut-off time and settlement windows. MT ensures that cash distribution will be made at the same time in T2 or T2S, as explained in parr , With regard to payments in non-euro currencies, not eligible in T2S, MT will continue to use its current systems for: National Securities issued in non-euro currencies: through payment banks appointed by the issuer to perform currency payments in foreign markets; Foreign Securities paid in non-euro currencies: through SWIFT messages (MT202), when MT s currency account is credited by the foreign payer in charge. The analysis of the implementation of Corporate Actions management in T2S, proposed in this section, is based on the assumption that the harmonization process to the International Standards has been completed. Both categories of Corporate Actions - Distributions (cash, securities, with options and Reorganizations (mandatory, mandatory with option, voluntary) - are analyzed. The following table shows a non exhaustive mapping of the Italian main categories of Corporate Actions and the corresponding international standards: CORPORATE ACTION Stock dividends, Bonus issues Right issue) Cash Dividends/ Interest Payment CORPORATE ACTION STANDARD Securities Distribution Cash Distribution 70

71 CORPORATE ACTION Capital increase (option rights exercise) or Optional dividend (cash or/and securities) Redemption Mandatory Conversion, merger, splitting and reverse split up, Redemption Warrant Exercise, Voluntary Conversion, OPA, OPS, Conversion of share from registered to bearer shares and vice-versa (called Tramutamenti) CORPORATE ACTION STANDARD Securities distributions + Mandatory Reorganization with option Mandatory Reorganization without option Mandatory Reorganization without option Voluntary Reorganization Table 10-1: Corporate Actions 10.1 Mandate Scope Scope of this section is to describe how the process available to the Issuers to send Monte Titoli all information required to manage the Corporate Events will be managed in T2S T2S Impact The corporate event handling in general, remains unchanged for the Issuers as they will continue to communicate MT the information needed to correctly manage all corporate action events (cash distribution, security distribution etc.) User Requirements and Adaptation Impact Mandate and the notification of variable data will be communicated using the MT-X platform with minimal changes to eventually include the indication of T2S as the selected payment platform and the DCA of the paying agent. Requirement ID T2S-UAR-CA-0010 Requirement Description The mandates messages will be amended to include T2S as a cash settlement platform and the Dedicated Cash Account of the paying agent Announcement Scope The scope of this section is to describe how the Announcements management will be processed in T2S T2S Impact MT will provide all participants with the Announcements that contains the operating details related to events for both those that have been confirmed by the issuer (or its agent) ad those that have not yet been confirmed ( unconfirmed ). The Announcement details can be distributed with the following messages: 71

72 RNI/MT-X message Swift MT User Requirements and Adaptation Impact As described in the cash distribution operating model,. new Announcements for Cash Distribution (SWIFT MT564) will be completed with additional information: Key Dates (Record Date, Ex Date, Payment date). MT receives the MT564 message from the CSD or the issuer. The information shall be made available no later than the day after the message is accepted by MT. The current processing remains unchanged in terms of timing and forwarding of messages to all participants who, at the time of the announcement, have a significant position (positive balance) on the financial instrument affected by the CA.. As currently it will be possible to receive MT564, upon request. The layout of the announcements will be amended in order to accommodate the choice of T2S cash payment mode, the T2S securities account and the payment bank. Requirement ID T2S-UAR-CA-0020 Requirement Description Depending on the type of CA, the announcements (MT564, RNI721/722, etc.) will be amended to include T2S security account, T2S as cash payment mode, the Payment Bank Distribution Cash Distributions Scope Scope of this section is to describe how the proceeds of the CA in cash distribution, which consist only of cash, will be managed in T2S. The main types of such events are: Cash dividends Interest payments T2S Impact MT provides Cash Distribution to credit beneficiaries who have, at the record date, security positions in financial instruments affected by CA. MT will allow payment Banks and beneficiaries to choose whether to be debited/credited liquidity stemming from CA in T2 or in T2S. In details this means that: each paying agent may choose to be debited: o either on their RTGS account in T2 72

73 o or on their DCA account on T2S - each participant may choose to be credited: o either on their RTGS account in T2, o or on their account in T2S DCA, As provided in the operating model of the cash distribution (see par.0), the intermediary can choose to pay in T2S or in T2 for event type (i.e. coupons / dividends / RCC) according to the default option, that can be modified by participants. Payments to participants will be managed by MT by sending T2S specific instructions (already matched "payment free of delivery - PFOD), indicating that it is a corporate actions (CORP). All instructions are linked and will be settled in an all or none mode. MT will assign them a reserved priority level to ensure their settlement occurs before other SIs not related to CA. In case no funds have been made available by the payment agent, within the established deadline, the corresponding payments are postponed to the next day, providing the participants with 7B2 messages. The diagram below describes the scenario of a paying agent that decides to pay CA on its RTGS account in T2. The beneficiary can decide whether to receive the cash proceeds in T2 (RTGS account) or in T2S (Dedicated Cash Account). RTGS Issuer/Paying Agent RTGS MT T2 DCA MT T2S RTGS MT RTGS Beneficiary RTGS MT DCA Beneficiary Figure 10-1: Cash settlement scenario in T2 During the Real Time Settlement, according to the timing and the rules of the new cash distribution model, MT debits the paying agent s RTGS account and credits the RTGS or the DCA accounts of Final Beneficiaries through its own RTGS or DCA accounts. The payment is managed by using the simultaneous multilateral settlement (procedure 5) that allows to settle in All or None mode. The procedure 5 with information period" option, allows the paying agent to revoke debit instructions prepared in T2 by MT. At the end of the Information period, MT proceeds with the payment by debiting the account of the paying agent and crediting the accounts of the beneficiaries for all the not revoked instructions. The diagram below describes the scenario of a paying agent that decides to pay CA on its DCA in T2S. The beneficiary can decide whether to receive the cash proceeds in T2 (RTGS account) or in T2S (Dedicated Cash Account). 73

74 DCA Issuer/Paying Agent MT DCA T2S RTGS MT T2 RTGS MT DCA Beneficiary RTGS MT RTGS Beneficiary Figure 10-2: Cash settlement scenario in T2S During the Real Time Settlement, according the timing and the rules of the new cash distribution model, MT debits the paying agent s DCA and credits the DCA or the RTGS accounts of Final Beneficiaries through its own DCA or RTGS accounts. MT will send T2S the settlement instructions (PFOD) in status Hold and MT receives status advices and settlement confirmations from T2S. At the deadline defined according to the international standards (11:45) MT releases all instructions that have not been revoked by the paying agent. The instructions (PFOD) should contain the information reported in the following tables. PFOD for debiting the DCA of the paying agent Message fields ISO Transaction CODE Payment Type Code Movement Type ISIN Cash Amount Quantity Security Account of Delivering party Security Account of Receiving party DCA of Delivering party DCA of Receiving party Matched Priority indicator Status Partial settlement indicator Corporate Action Event Identification Description CORP APMT DELI Underlying security Cash proceeds ZERO the Securities account of PA which deliver the cash to MT the Securities account of MT which receives the cash from PA the DCA of PA which deliver the cash to MT the DCA of MT which receives the cash from PA YES RESERVED priority HOLD NO CA unique reference number Table 10-2: PFOD for debiting the DCA of the paying agent 74

75 PFOD for crediting the DCA of the beneficiaries Message fields ISO Transaction code Payment type code Movement type ISIN Cash amount Quantity Security Account of Delivering party Security Account of Receiving party DCA of Delivering party DCA of Receiving party Matched Priority indicator Corporate Action Event Identification Description CORP APMT DELI Underlying security Cash proceeds ZERO the Securities account of MT distributing the cash proceeds the Securities account of Beneficiaries receiving the cash proceeds the DCA of MT distributing the cash proceeds the DCA of beneficiary s paying agent which receives the cash from MT Yes No CA unique reference number Table 10-3: PFOD for crediting the DCA of the beneficiaries User Requirements and Adaptation Impact Requirement ID T2S-UAR-CA-0030 T2S-UAR-CA-0040 T2S-UAR-CA-0050 T2S-UAR-CA-0060 Requirement Description Paying agents will be able to choose whether they pay the CA: using their RTGS account (T2) using their T2S DCA The already matched payment free of delivery settlement instructions (PFOD), will be identified with ISO transaction code set to CORP Participants will be able to choose whether to be credited liquidity stemming from CA: to their T2 RTGS account to their T2S DCA The timing of notification messages will remain unchanged and in line with the timing for cash distribution in T2. 75

76 Securities distribution Scope Scope of this section is to describe how the proceeds of the CA in securities settlement, which consist only of securities, will be managed in T2S. The main types of such events are: Stock dividends Bonus issues Rights distribution T2S Impact The Corporate Actions with securities distribution will be settled in T2S. MT will send T2S a FOP (DFP delivery free of payment) already matched settlement instruction for each participant who have, at the record date, security positions in financial instruments affected by CA. The settlement instructions will be created for the Outturn ISIN security and with ISO transaction code set to CORP. The indicative instruction type, from MT s perspective, is the following: Message fields ISO Transaction code Payment type code ISIN Cash amount Quantity Security account of Delivering party Security account of Receiving party Table 10-4: Securities distribution Description CORP FREE Outturn ISIN ZERO Securities proceeds of the participant It represents the security account of Issuer agent the Securities account of Beneficiaries receiving the securities proceeds User Requirements and Adaptation Impact Requirement ID T2S-UAR-CA-0070 Requirement Description In T2S the settlement instructions of securities distribution will be settled in the Night Time Settlement period, in the first sequence dedicated to a CA Distribution with options Scope Scope of this section is to describe how distributions with options will be implemented in T2S. 76

77 Distributions with options are distribution events which provide the investor with a choice of how to receive the corresponding proceeds (for example the optional dividend that gives the possibility to choose between receiving cash and/or securities) T2S Impact Settlement Instructions for this type of Corporate Actions will be settled in T2S, as described above for CA settlement at par and The choices are communicated by MT Participants trough the current messages RNI 715 and Swift 565 which will be amended in order to manage both securities account (ABI code and T2S code). In case the option chosen is cash, intermediaries should have the possibility to select T2 or T2S in order to receive the proceeds User Requirements and Adaptation Impact Requirement ID T2S-UAR-CA-0080 Requirement Description The RNI 715 and Swift 565 messages contain both security account codes (internal MT and T2S security account) 10.4 Reorganizations Mandatory Reorganizations without options Scope This section describes how reorganizations without options will be managed in T2S. A mandatory Reorganization, is, for example, the one that affects always the underlying security. This event fully or partly replaces the underlying securities with one or more other resources (cash only, securities only, both cash and securities). Typical examples of such events are: Redemption Stock split Merge Mandatory Conversion This process to manage reorganization is a variation of the process Securities Distribution described above in par T2S Impact The settlement Instructions for this type of Corporate Actions will be settled in T2S. If the resulting proceed is cash, intermediaries will have the possibility of choosing between T2 and T2S.. Depending upon the CA reorganization event (security and/or cash): Redemption (securities and cash): MT will handle the settlement instructions for debiting the securities account of beneficiaries and crediting the securities account of Issuers, as FOP already matched with ISO transaction code set to CORP using the link in all-or-none 77

78 mode. It will be settled in the Night Time Settlement period, in the first sequence dedicated to CA. Cash credits will be handled as a Cash Distribution. Mandatory Conversion, Merge (securities only): MT will handle the settlement instructions for debiting the underlying securities account of beneficiaries and crediting the outturn securities account of Issuers, as FOP already matched with ISO transaction code set to CORP using the link in all-or-none mode. It will be settled in the Night Time Settlement period, in the first sequence dedicated to CA User Requirements and Adaptation Impact Requirement ID T2S-UAR-CA-0090 Requirement Description In T2S the CA regarding security only will be settled in the Night Time Settlement period, in the first sequence dedicated to CA Mandatory Reorganizations with options Scope This section describes how reorganizations with options will be managed in T2S. A mandatory Reorganization with option event is a reorganization, where the investor has the faculty to choose the type of proceeds. A conversion is an example of a mandatory reorganization with option event (e.g. where the investor has a choice of receiving cash and/or securities as proceeds). Examples of such events are: Capital Increase Warrant exercise (for the last election period) T2S Impact Elections will be sent by MT s Participants through the current 715 RNI message or MT565 Swift message which will be amended in order to manage both securities account (ABI code and T2S code). The last date by when the subscription message can be sent to Monte Titoli is the last election date (T). This deadline will be parametric and it will be fixed depending on coexistence of two alternative Settlement Systems ( T2/T2S) that can be used for cash settlement. As the cut-off of Payment Free of Delivery is set at 16:00 pm in T2S, the current deadlines and timing for Capital Increase and Warrant Exercise should be anticipated. MT will communicate all involved parties (Payment Agents, Beneficiary, Issuer) the amount to be settled for the complete execution of the corporate action. 78

79 As MT allows the subscribers for Capital Increase and Warrant Exercise, to choose whether they want to pay the CA: either on its RTGS account in T2 or on its DCA account on T2S. Also the bank of the Issuer will be given the possibility to choose the payment system where to receive the cash resulting from the elections process. Cash settlement scenario in T2S Both the Securities account and Cash account (DCA), respectively with FOP (Free of Payment) and PFOD ( Payment Free of Delivery) Instructions already matched will be managed exclusively through settlement instructions. MT will send T2S the PFOD Instructions for debiting the subscribers when the Real Time Settlement cycle starts: MT assigns a reserved priority level to the PFOD instructions sent to T2S ensuring their settlement prior to other transactions not related to CA. The PFOD instructions should be valued with MT Internal number of CA that ensure the Payment Agent to univocally identify the event to settle. In case of a full cash availability, the transaction is immediately executed debiting the DCAs of the subscribers and crediting MT s DCA. In case of lack of cash, the instructions remain pending in T2S until the end of the Settlement window. At the end of the Settlement Window, if the funds are not yet available, a notification message is sent by MT to the Paying Agents and the Contingency phase is activated. In case the bank appointed by the Issuer acts also as a subscriber, the payment is performed by Monte Titoli by creating appropriate links between the debit and the credit instructions using the Link ALL-OR-NONE mode. Contingency processing: The contingency phase is used in order to settle instructions that have not yet been settled because of lack of funds during the ordinary Settlement Phase. In case of lack of cash the transaction remains pending in T2S and MT will request the subscriber to make the missing amount available on its account in order to continue with the transaction s execution. After the intermediary confirmation to reduce the amount to be subscribed, MT adjusts the amount that is still unsettled by sending a new settlement instruction with the new (reduced) amount. If contingency fails, MT cancels the new settlement instruction. No other settlement attempts are done 79

80 User Requirements and Adaptation Impact This process is a variation of the process Voluntary Reorganizations. Requirement ID T2S-UAR-CA-0100 T2S-UAR-CA-0110 T2S-UAR-CA-0120 T2S-UAR-CA-0130 Requirement Description Participants should send elections through message 715 (RNI) or MT565 (swift ISO15022) which will be amended in order to accommodate the new field T2S securities account. Participants will continue to receive a RNI message 71N or the corresponding Swift messages. Subscribers will be able to choose whether to pay the CA: to their RTGS account (T2) to their T2S DCA (T2S) MT will send T2S already matched payment free of delivery settlement instructions (PFOD), with ISO transaction code set to CORP The bank of the Issuer will be able to choose whether to be credited liquidity stemming from CA in T2 or T2S system Voluntary Reorganizations Scope Scope of this section is to is to describe how voluntary reorganizations will be managed in T2S. A reorganization is classified as voluntary when the holder of the underlying security has the choice to opt for participating or not. A tender offer (Offerta Pubblica di Acquisto), for example, allows the shareholders to sell (tender) or exchange their securities. This section covers the standard steps for a CSD to settle the outcome of a voluntary reorganization in T2S. The only currently used case is the Warrant exercise bond and shares conversions (all election periods, except the last one) T2S Impact All settlement Instructions to be used in order to manage this type of Corporate Actions will be settled in T2S and the process can be referred to the Mandatory Reorganisations with options process already described in par User Requirements and Adaptation Impact See par

81 10.5 Corporate Action reporting and notification Scope Corporate Actions reporting towards issuers and intermediaries will continue to be an internal MT process. All participants having a securities account with a significant position impacted by corporate actions, will receive the corresponding reporting either through MT infrastructure or directly trought2s platform. The main types of CA settlement reporting sent by MT to its parties, Issuers, Paying Agents are listed below: Provisional notification message Constitution of Fund notification message Final notification message Delay notification message Cancellation notification message Corporate Action Cash Distribution Message Description Rni Swift Mt-X T2s 7B1 Provisional/Final Msg 7B1 MT564/56 Msg 7B1 P/D 6 P/D - 7B2 Provisional/Final Msg 7B2 MT564/56 Msg 7B2 P/D 6 P/D - 7B3 Provisional/Final Msg 7B2 MT564/56 Msg 7B3 P/D 6 P/D - 7B1-Constitution of Msg 7B1 Msg 7B2 F MT566 Funds P/D - 7B4 Revoke/cancel /suspend Msg 7B4-7B5 Msg 7B5 - Security Distribution Settlement confirmation Msg 71N MT566 Msg 71N Election Msg 704 MT565 Settlement notification Msg 71N MT566 Msg 71N Sese.025 7B2 - Final Msg 7B2 MT566 Table 10-5: Corporate Action securities and cash reporting T2S impact No major impacts on CA reporting are foreseen int2s. The message layout of payments notification (provisional and final) will be amended to include the new T2S fields (securities account, dedicated cash account, etc.) User Requirements and Adaptation Impact Requirement ID T2S-UAR-CA-0140 Requirement Description Participants will have to adapt their systems in order to manage the amended messages 81

82 11. Position Management 11.1 Scope T2S provides several ways to allow T2S Actors to manage their securities position: the Blocking, the Reservation and the Earmarking functionalities (also called as restriction processing ) T2S Impact In order to set-up any blocking, reservation or earmarking on a securities position a restriction type has to be configured within the static data in T2S. The restriction processing is managed in T2S by using Settlement Restrictions and Settlement Instructions. Blocking It is a process that allows to transfer and to block a specified amount of securities from a delivery sub balance securities account to a blocked one and viceversa. Securities blocking does not allow to block more securities than the ones available in the identified securities account. In case the quantity is higher than the available quantity then the Settlement Restriction is not partially settled and recycled waiting incoming securities (ref. UDFS at page ). Reservation It is a process that allows to transfer and to reserve a specified quantity of securities from a delivery sub balance securities account to a reserved one and viceversa. It is possible to reserve a position greater than the securities position available on the securities account by automatically reserving all incoming securities until the quantity of the reservation is completely filled (ref. UDFS at page ). Earmarking It is a process that allows to identify a defined quantity of a security in one securities account as eligible only for a specific type of transactions or processes (e.g. for auto-collateralisation or other specific purposes). For example, a payment bank can earmark a securities position in a securities account as eligible collateral. Earmarking in T2S shall never result in a negative securities position, i.e. it is not possible to earmark a securities position on a securities account for an amount that is greater than the available position. In case this happens the Settlement Instruction or Restriction is partially settled without additional settlement attempts (ref. UDFS at page ). Restriction Type The restriction type on security position is configured by: The T2S Operator, when the purpose applies to all T2S Parties irrespective of their CSD; A CSD when the purpose applies only to the T2S Parties of this CSD and their securities positions. 82

83 The management of the restrictions in T2S is executed by identifying the securities positions that need to be updated. T2S requires the combination of the following identifiers to be used: the Securities Account ID; the ISIN Code; the restriction type ID. A T2S Actor will then instruct T2S: with a Settlement Restriction (SR) to set-up, increase, and decrease a blocking, a reservation, an earmarking; with a Settlement Instruction (SI) to set-up and increase an earmarking; with a Settlement Instruction to use a blocking, a reservation, an earmarking. The Restriction Reference is the unique identifier assigned by T2S when a Blocking or Reservation detailed cash/securities restriction is set up in a securities account. No Restriction Reference is used for Earmarking. Figure 11-1: Blocking and Reservation model 83

84 Figure 11-2: Earmarking & Earmarking for Auto Collateralisation model The scheme below summarizes appendix and the actions described. For more details please refer to SR/SI ACTION PROCESS NOTE Blocking The quantity to be blocked cannot be greater than the one available on the securities account. Settlement Restriction is not partially settled and recycled waiting incoming securities. SR Set-up Reservation The quantity to be reserved can be greater than the one available. All incoming securities are automatically reserved until the quantity of the reservation is filled. Settlement Restriction is partially settled and recycled waiting incoming securities. Earmarking If the quantity to be blocked is greater than the available one, the Settlement Restriction is partially settled and not recycled. Increase Decrease Blocking Reservation Earmarking The restriction reference is to be specified in the SR (except for earmarking). There are the same validation rules on the quantity as the Set-up. SI Set-up Increase Use Use Earmarking Blocking Reservation Earmarking Table 11-1: Instructions for restriction processing No restriction reference must to be indicated but only the specific restriction type. The increase is possible when the instructing Party is receiving Securities The restriction reference is to be specified in the SI. It is possible indicate more than a reference. No restriction reference must to be indicated but only the specific restriction type 84

85 11.3 User Requirements and Adaptation Impact Requirement ID T2S-UAR-PM-0010 T2S-UAR-PM-0020 T2S-UAR-PM-0030 T2S-UAR-PM-0040 T2S-UAR-PM-0050 T2S-UAR-PM-0060 T2S-UAR-PM-0070 T2S-UAR-PM-0080 T2S-UAR-PM-0090 T2S-UAR-PM-0100 Requirement Description MT will properly configure privileges and access rights in order to permit its DCPs to use Blocking, Reservation, Earmarking and Earmarking for Auto-collateralization purposes, either via A2A or ECB s browser based U2A solution (GUI). ICP will be able to use blocking functionalities through MT infrastructure in an A2A mode by using RNI, ISO15022, ISO20022 messages and new A2A solution replacing LU6.2. See picture Blocking & Reservation in the following pages. ICP will be able to use blocking functionalities through MT infrastructure by using MT U2A solutions (MT-X and X-TRM on line). See picture Blocking & Reservation in the following pages. ICP will be able to use reservation functionalities through MT infrastructure in an A2A mode by using RNI, ISO15022, ISO20022 messages and new A2A solution replacing LU6.2. See picture Blocking & Reservation in the following pages. ICP will be able to use reservation functionalities through MT infrastructure by using MT U2A solutions (MT-X and X-TRM on line). See picture Blocking & Reservation in the following pages. ICP will be able to use earmarking functionalities via MT in an A2A way by using RNI, ISO15022, ISO20022 messages and new A2A solution replacing LU6.2. See picture Earmarking & Earmarking for Auto-Collateralization on the next pages. ICP will be able to use earmarking functionalities through MT infrastructure by using MT U2A solutions (MT-X and X-TRM on line). See picture Earmarking & Earmarking for Auto-Collateralization in the following pages. ICP will be able to use earmarking for autocollateralization functionalities via MT in an A2A way by using RNI, ISO15022, ISO20022 messages and new A2A solution replacing LU6.2. See picture Earmarking & Earmarking for Auto-Collateralization on the next pages. ICP will be able to use earmarking for autocollateralization functionalities through MT infrastructure by using MT U2A solutions (MT-X and X-TRM on line). See picture Earmarking & Earmarking for Auto-Collateralisation in the following pages. ICPs will receive in their statement of transactions (A2A and U2A) all the transaction related information available in T2S response messages. 85

86 12. Business day T2S provides a harmonized settlement day for all settlement procedures. The T2S Settlement Day includes 5 periods and each period includes different processes as following listed: T2S Periods T2S timeline description Start of Day (SOD) 6:45pm - 7:30pm The start of day period including: Change of business date in T2S; Preparation for night-time settlement: Revalidation of Settlement Instructions/ Settlement /Restrictions/amendments/hold and release instructions Night-Time Settlement (NTS) Maintenance Window Real-Time Settlement (RTS) 7:30pm - 3:00 am 3:00am - 5:00 am 5:00am - 6:00 pm The NTS consists in two settlement cycles for processing cycles for each of them is defined a specific sequence of execution of operations The first night-time settlement with reporting and processing of static data maintenance instructions/ maintenance instructions The last night-time cycle, including partial settlement, with reporting and processing of static data maintenance instructions/maintenance instructions at the end of each settlement sequences including 4 sequences. At the end of each night-time sequence, T2S generates full or delta reports and sends also to the T2S Actors messages such as settlement status advices, settlement confirmation, posting notification, etc. T2S validates and accepts the static data maintenance instructions and maintenance instructions, then it also performs a revalidation of all Settlement Instructions and Settlement Restrictions to ensure that they are valid for the considered static data update. During the execution of a night-time settlement sequence, T2S does not respond to queries related to securities positions or cash balances. All services are unavailable except for Interface application processes which are restricted to the messages received in A2A mode (queued for processing until the maintenance window is completed). The real-time settlement period including: The real-time settlement preparation; The real-time settlement with 2 partial settlement windows; the DVP and PFOD cut off time (4:00 pm) The real-time settlement closure 86

87 T2S Periods T2S timeline description End of Day (EOD) Table 12-1: T2S Settlement day 6:00pm - 6:45 pm The end of day period including The stop of settlement engine; The internal T2S securities accounts consistency check; The recycling and purging; Identification and cancellation of all the pending settlement instructions/restrictions which have passed the last recycling day The end of day reporting and statements During the execution of night-time settlement sequences, T2S will not respond to queries related to securities positions/ holdings or cash balances. If these queries are received via U2A, they will be rejected. If T2S receives the queries via A2A, they will be queued and processed during the next reporting phase. It is important to note that for all static data updates, T2S performs a revalidation for all settlement instructions and settlement restrictions that failed to settle or not yet submitted to a settlement attempt. The current MT settlement schedule will be adapted to be compliant with the new timing and deadlines in T2S. This means that MT s daily CUT OFFs and EOD (End Of Day) processes will also need to be scheduled according to T2S scheduling. MT will need to adjust, postpone or parallelize its processes to increase their efficiency in order to adhere to the new schedule. After the reception of the EOD Statement of Holdings from T2S at 6.45 pm and after MT balances alignment, the Corporate Action (CA) processing will start in order to prepare Settlement instructions to be sent to T2S within the first settlement cycle which is scheduled at 7.15 pm in T2S. The following table shows the current X-TRM cut-off and the future scheduling in T2S. All identified cut off are submitted to the review and the approval of the Italian community and might eventually even be removed. Deadlines/Events X-TRM/EXPII X-TRM/T2S Start of Day N/A 18:45 19:30 Night-Time settlement Net: 19:45 07:00 Net: N/A Gross: N/A Gross: 19:30 03:00 Maintenance window 22:30 07:00 XTRM: 22:30 05:00 T2S: 03:00 05:00 Day-Time Settlement Net: 09:30 13:00 Net: N/A Gross: 08:00 18:00 Gross: 05:00 18:00 Pre Settlement (X-TRM service availability) 07:00 22:30 05:00 22:30 End of Day N/A 18:00 18:45 87

88 X-TRM cut-off X-TRM/EXPII X-TRM/T2S DVP T same day 16:00 Tbd DVP T+1 17:30 Tbd DVP T+2 22:00 Tbd FOP T same day 18:30 Tbd Table 12-2: X-TRM cut-off in T2S The following table shows pull/push report timing : Reports Time Mode At the end of Night-time settlement ROM (G56) (NTS)(1) Push At the end of Real-time settlement (RTS) Statement of transaction Continuously during X-TRM service Statement of allegment ACB (G56) Pull availability G70 Continuously during X-TRM service availability Push Statement of Holding(2) At the end of End-of-Day T2S period Push (1) during NTS, before close of X-TRM, ICPs will receive either pull (via G56) or push (via G70) reporting aligned to T2S reports sent to X-TRM at the end of sequences; at open of X-TRM ICPs will receive push reporting (via G56), even if RTS starts before maintenance window; (2) with the details of movements, positions and sub-balance restrictions. Table 12-3: Report Timing The following table shows the Corporate Actions scheduling: 88

89 Figure 12-1: CA scheduling 89

90 13. MT services for participants The tables below show the list of services and functionalities provided by MT in T2S: - the first two ones report the options available through MT infrastructure, - the following two ones give evidence of both the options available and those that will not be available when interacting directly with the T2S platform. Settlement Source Type/ Settlement Type Operational Function Operational SubFunction Interaction with T2S through MT infrastructure Guaranteed Market Not Guaranteed Market Trades from CCPs and BoI Forwarding CCP functionalities Acquisition (CVT, PCT) Validation Enrichment Splitting (Interposition) Bilateral Netting (Gross A and Net B Model) Forwarding to T2S Acquisition (CVT, PCT) Validation Enrichment Forwarding to T2S Forwarding to non-t2s settlement system (1) Acquisition (CTC) Validation Enrichment Bilateral Netting (Net & Gross) Forwarding Forwarding to T2S Acquisition (CVT, PCT, CTC) Acquisition on External-CSD (CTC) Participants, CCPs and BoI Transaction Acquisition Validation on External-CSD (CTC) Enrichment on External-CSD (CTC) All Source (1) The service w ill not be changed Transaction Acquisition CCP functionalities Transaction Acquisition Forwarding Transaction Acquisition Forwarding Amendment (2) Cancellation (2) Info Pull Info Push (2) The functions w ill available according to Market Rules Forwarding to T2S Forwarding to non-t2s settlement system (1) Priority Linkages Hold/Release Partial Settlement Cancellation Statement of Allegement Statement of pending transaction Statement of transaction Settlement Status Advice Settlement Confirmation Allegement Notification Statement of Allegement Statement of pending transaction Statement of transaction Table 13-1: MT services in T2S: Settlement - Interaction with T2S through MT infrastructure 90

91 Custody Party Type Operational Function Operational SubFunction Interaction with T2S through MT infrastructure Participants Issuer All Source Restrictions Issuance Instructions Coupon Stripping Issuance Instructions Info Pull Info Push Earmarking Blocking Reservation Mark UP / Mark DOWN Stripping Unstripping Centralization BuyBack Mark UP / Mark DOWN Statement of Holding Statement of Holding Statement of Holding and Transactions Settlement and Restriction Confermation Table 13-2: MT services in T2S: Custody - Interaction with T2S through MT infrastructure 91

92 Source Type/ Settlement Type Guaranteed Market Not Guaranteed Market Trades from CCPs and BoI Participants, CCPs and BoI All Source (1) The service w ill not be changed Operational Function Transaction Acquisition CCP functionalities Forwarding Transaction Acquisition Forwarding Transaction Acquisition CCP functionalities Forwarding Transaction Acquisition Forwarding Amendment (2) Cancellation (2) Info Pull Info Push Settlement Operational SubFunction Acquisition (CVT, PCT) Validation Enrichment Splitting (Interposition) Bilateral Netting (Gross A and Net B Model) Forwarding to T2S Acquisition (CVT, PCT) Validation Enrichment Forwarding to T2S Forwarding to non-t2s settlement system (1) Acquisition (CTC) Validation Enrichment Bilateral Netting (Net & Gross) Forwarding to T2S Sending Settlement Instruction Acquisition on External-CSD (CTC) Validation on External-CSD (CTC) Enrichment on External-CSD (CTC) Forwarding to T2S Forwarding to non-t2s settlement system (1) Priority Linkages Hold/Release Partial Settlement Cancellation Statement of Allegement Statement of pending transaction Statement of transaction Settlement Status Advice Settlement Confirmation Allegement Notification Statement of Allegement Statement of pending transaction Statement of transaction Direct Interaction with T2S (2) The functions w ill available according to Market Rules Table 13-3: MT services in T2S: Settlement - Direct Interaction with T2S 92

93 Party Type Participants Issuer All Source Operational Function Restrictions Issuance Instructions Coupon Stripping Issuance Instructions Info Pull Info Push Custody Table 13-4: MT services in T2S: Custody - Direct Interaction with T2S Operational SubFunction Earmarking Blocking Reservation Mark UP / Mark DOWN Stripping Unstripping Centralization BuyBack Mark UP / Mark DOWN Statement of Holding Statement of Holding Statement of Holding and Transactions Settlement and Restriction Confermation Direct Interaction with T2S 93

94 14. Appendix 14.1 Pre Settlement Services Trades from Guaranteed and not Guaranteed Markets All trades related to guaranteed markets linked to X-TRM will continue to go through X-TRM, then MT will continue to calculate the bilateral balances and it will provide to send them to T2S. All trades related to not guaranteed markets currently linked to X-TRM, will continue to go through X-TRM, then MT will send to T2S trades in real time. On exchange trades will be forwarded to T2S already matched if both Settlement Agents have an account in MT; in case one of them has an account in another CSD participating in T2S, trades have to be matched in T2S. On exchange trades contributing to bilateral net balances are available only in X-TRM MT will be authorized to send Settlement Instructions (as bilateral balances) in T2S on behalf of all actors involved. MT must obtain the updated data base related to the relationship between traders, general clearing members and settlement agents/settlement accounts for all market participants. Netting criteria will not take into consideration the end of validity date. This information will be considered by MT to manage the buy in procedure (cancellation of a settlement instruction at the date of the end of validity). Regarding guaranteed trades MT will continue to calculate bilateral balances and to send them to T2S as settlement instructions; for not guaranteed market each trade will be sent as single settlement instruction. Criteria to define balances (except for the use of end of validity date ) will not change operative rules, linked to the validation of the market/ccp/settlement participation; It will be performed the enrichment activity for not guaranteed trades as well (assignment of Settlement Agent/Settlement Account) based on information included into the data base. In case of Repo Overnight (same day repo), both guaranteed and not guaranteed trades, spot leg will be sent to T2S in real time as single settlement instruction. Before sending to T2S, the spot leg can be submitted to the shaping process, in accordance with markets/ccps agreement. Corporate Actions on fails transactions will follow the approach and the operative model set up from Corporate Actions on Flow management (out of scope in present document). 94

95 Regarding the additional fields expected into Settlement Instructions (Partial settlement, Priority, Linkage option) proper tables can be used including default rules for each specific market. For this purpose following defaults have been assumed: Partial settlement filled to PART Priority filled to 2 (Top priority) Linkage option filled to No Cum/Ex and Opt-out options default to be defined The following figures show the operative models in case of guaranteed and not guaranteed Markets. Figure 14-1: Guaranteed Markets Operative model 95

96 Figure 14-2: Not Guaranteed Markets Operative model Transaction from Participants MT will continue in T2S to provide Acquisition, validation and enrichment services for all kind of trades (CVT, PCT and CTC) in order to fill correctly the settlement istruction towards T2S. All trades inserted by Participant that decide to use MT as interface towards T2S, will continue to go through X-TRM, then MT will send to T2S trades in real time. MT will be authorized to send Settlement Instructions in T2S on behalf of all actors involved. In relation to the additional fields offered by T2S in Settlement Instruction MT will allow its Participants to set up them in messages between Participant and X-TRM. PCT Management This trade is composed by an instruction spot leg and a forward leg, with the same trade date, same counterparty and the same security and nominal value as well. The amount, both in spot and forward leg, will be calculated by X-TRM as per pre-defined algorithms. T2S does not allow Participants to send REPO trades, for this purpose two separate instructions must be sent. The result will be a combination of a DVP instruction (spot leg), and a RVP instruction (forward leg). MT will continue to provide its participant Repo full enrichment and duplications services only when both the participant use X-TRM infrastructure. For REPO coming from guaranteed market, process will follow the same rules, except for the instructions that will be sent to T2S already matched The following schemes describe the scenarios depending on the connectivity of the participants involved for all the Repo trades not deriving from Markets. 96

97 Figure 14-3: PCT, both Participans use X-TRM Figure 14-4: PCT, both Participans do not use X-TRM 97

98 Matching and Allegement The following table lists the matching fields in T2S. Matching Fields Payment Type Securities Movement Type ISIN Code Trade Date Intended Settlement Date Settlement Quantity Delivering Party BIC Receiving Party BIC CSD of the Delivering Party CSD of the Receiving Party Currency Settlement Amount Credit/Debit Additional Settlement Transaction Condition Opt-out Trade Transaction Condition CUM/EX Indicator Settlement Instruction 1 Mandatory Settlement Instruction 2 The value of these fields must be the same in both the settlement instructions The value of these fields must be the same in both the settlement instructions (only for S.I. against payment) Non Mandatory The value of these fields must be the same if is present at least in one settlement instructions Opt out MATCH Opt out ExCoupon CumCoupon NO MATCH NO MATCH CumCoupon (blank) Optional The value of these fields must be the same if is present n both the settlement instructions Common Trade Reference MATCH Client of delivering CSD NO BANKCCLLMAR participant MATCH BARCGB210ZS Client of receiving CSD participant BSCHESMMXXX MATCH (blank) Securities account of the MATCH delivering Securities account of the receiving Table 14-1: Matching fields in T2S NO MATCH

99 In the following table T2S matching fields are compared with X-TRM matching fields. Table 14-2: Matching fields in T2S compared with X-TRM matching fields 99

100 The followings figures show the Allegement Management activity diagrams. The first is a general schema, the second and third are different scenarios depending on the connectivity type of Participants. Figure 14-5: Allegement Management Standard Delay Period & Before Cut-Off time Figure 14-6: Allegement Management - ICP vs ICP 100

101 Figure 14-7: Allegement Management DCP vs ICP Bilateral Netting (Net and Gross Margining Model) Regarding the margining models, in both cases of guaranteed (as net balances) and not guaranteed trades (as single transactions), in the following pages some examples of valorization of Parties and Securities Accounts in settlement instruction towards T2S will be shown. Please note that cases 1 and 4 are the same in both gross and net operative model. The model 2 is not currently used by any Participant. The following Party/Security representation is valid for guaranteed trades and for not guaranteed trades as well as when the trader is a direct clearing member. In this case the BIC of Receiving Party will be the one of the counterparty Settlement Agent and the client of Receiving Party will be represented by Counterparty Trader code. 101

102 Figure 14-8: Operative Model A (gross) and B (net) Case 1 - Example: BANKABC roles: trader, Individual Clearing Member and Settlement Agent The following Party/Security representation is valid for guaranteed trades and for not guaranteed trades as well as in the case of the trader is a indirect clearing member. In this case the BIC of Receiving Party will be the one of the counterparty Settlement Agent and the client of Receiving Party will be represented by Counterparty Trader code. Figure 14-9: Operative Model A (gross) Case 3 - Example: BANKDEF as Trader, BANKGHI as General Clearing Member and Settlement Agent 102

103 Figure 14-10: Operative Model B (net) Case 3 - Example: BANKJKL as Trader, BANKGHI as General Clearing Member and Settlement Agent 103

104 Figure 14-11: Operative model A (Gross) and B (Net) Case 4 - Example: BANKMNO as Trader and Individual Clearing Member, with BANKPQR as Settlement Agent Figure 14-12: : Operative model A (gross) Case 5 - Example: BANKSTU as Trader, BANKVWX as General Clearing Member and BANKYZ1 as Settlement Agent for both entities 104

105 Figure 14-13: Operative Model B (Net) Case 5 - BANK234 as Trader, BANKVWX as General Clearing Member, BANKYZ1 as Settlement Agent for both entities Forwarding to Settlement System processes In T2S does not exist a field containing the transaction type (DVP, RVP, RWP, DWP, FOP or PFOD), this is an alias value resulting from the combination of the field Payment Type code and the sign of the settlement instruction in its securities and cash leg. In fact all instructions SESE.023 versus T2S should be sent with a valid Payment Type Code: APMT if the settlement instruction is against payment 105

106 FREE if the settlement instruction is free of payment All the Settlement Instructions SESE.023 sent to T2S and related to market execution net balances will be sent with Payment Type Code APMT even when countervalue of bilateral balance is equal to zero. AS stated in T2S validation rule MVCV286 (Either the Settlement Amount or Settlement Quantity of a settlement instruction must be greater than zero) T2S does not allow to send settlement instructions where both the quantity and countervalue of bilateral balance are equal to zero. In this case two instructions will be sent: the first containing the sum of quantity and amount of delivering trades the second containing the sum of quantity and amount of receiving trades The same procedure will be applied when the quantity of net balance is less then minimum settlement quantity. In fact in T2S Securities static data there are two attribute: Minimum Settlement Unit and Settlement Unit multiple (also used by T2S in partial settlement management). When the quantity of a settlement instruction is less than Minimum Settlement Unit, because of the netting process, it will be necessary to proceed with two instructions as when the balance is 0. Here below the list of value, that will be used in market execution, related to payment type code depending on type of trade (deliver or receive) and depending on the valid countervalue for all settlement instructions. Table 14-3: Valorization of payment type code 106

107 14.2 Overview on partial settlement in T2S After the full settlement attempt, T2S will activate Partial settlement function into three specific windows: During the day time cycle: one window between 2.00pm and 2.15pm one window between 3.35pm and 4.00pm During the last night time cycle Partial settlement will be applied if the following conditions have been satisfied: Settlement Instruction (SI) has been set up as instruction available for Partial Settlement by counterparties and it is not linked to other instructions (functions: with afte befo ) Thresholds criteria have been satisfied The relevant variables for Partial Settlement are the following: Type of instruction (FOP, DVP, DWP) The Partial Settlement indicator filled into the instruction by the Instructing party Thresholds set-up Isin Security Settlement CCY (Currency) Instructing party can fill the partial settlement indicator as follow: NPAR PartialNotAllowed: Partial settlement is not allowed PARC PartialSettlementCashThresholdAllowed: Partial settlement is allowed but must satisfy a cash value minimum (value defined in static data). PARQ PartialSettlementQuantityThresholdAllowed: Partial settlement is allowed but must satisfy a minimum quantity of securities (quantity defined in static data). PART PartialAllowed: Partial settlement is allowed There are two types of thresholds: Thresholds set on security data base (Units Minimum Settlement and Settlement Unit Multiple) by the Issuer CSD or by Security Maintaining Entity if the Issuer CSD is external to T2S Thresholds set on static data base for cash by T2S Operator In the static data the thresholds function for Partial Settlement allows T2S operator to apply the parameter only on two variables: Instrument Type Currency The variable Instrument Type can assume the following values: All (default value) Unit-quoted securities Nominal-quoted securities 107

108 The variable Currency can assume any CCY values or value = ALL The following figure shows an example of partial settlement cash threshold configuration made by T2S Operator.. Figure 14-14: Partial Settlement thresholds on cash in T2S - Example Rif. User Handbook v1.0 pag

109 Table 14-4: Partial Settlement T2S Examples Rif. USFS (page 340) 14.3 Overview on settlement priority in T2S T2S uses priority levels in such a way that if several instructions compete with respect to using the same securities and/or cash resources, in the night-time or real-time optimisation process, preference for settlement is given to the instruction with the highest level of priority. Table 14-5: Priority Management in T2S overview --Rif. UDFS_v1.2.1 da pag.333 This level of priority can be set by the T2S Actor or automatically assigned by T2S based on parameters previously set by the T2S Operator in the static data. 109

110 Default priority level for Settlement Instruction In case no level of priority is indicated in the Settlement Instruction or Settlement Restriction by the T2S Actor, T2S allows setting in the static data, a default value automatically taken into account according to the following data contained in the incoming Settlement Instruction or Settlement Restriction Table 14-6: Priority Management in T2S overview -Rif. UDFS_v1.2.1 da pag.333 Modification of the level of priority set on a Settlement Instruction T2S Actors can modify the level of priority of a Settlement Instruction or a Settlement Restriction, until its full settlement, through an Instruction Maintenance (for partially settled Settlement Instruction, the new level of priority applies to the pending part of the Settlement Instruction ) Applicable level of priority to matched Settlement Instructions For matched Settlement Instructions, T2S defines a single level of priority applicable to both Settlement Instructions based on the value of each one indicated by the T2S Actor or automatically assigned by T2S: If both matched Settlement Instructions indicate the same level of priority, T2S uses this level of priority for both matched Settlement Instructions; If both matched Settlement Instructions indicate a different level of priority, T2S uses the highest level of priority for both matched Settlement Instructions; If both matched Settlement Instructions do not indicate a level of priority, T2S uses the lowest level of priority (i.e. "Normal"). Use of the prioritisation in the settlement process in T2S During the night-time settlement period, T2S takes into the account the applicable level of priority for all Settlement Instructions and Settlement Restrictions before any settlement attempt. During the real-time settlement period, T2S takes into account the applicable level of priority only for pending Settlement Instructions during the recycling and optimisation process. T2S does not take into account the level of priority at the first settlement attempt of Settlement Instructions and Settlement Restrictions. 110

111 If an additional choice has to be made between Settlement Instructions or Settlement Restrictions with the same level of priority, T2S gives the preference to the oldest ones based on their Intended Settlement Date 14.4 Overview on linkage options in T2S T2S allows to link settlement instructions and settlement restrictions. This feature allows to apply to the linked instructions some specific rules in the following phases: - Business validation - Eligibility - Settlement. The link is admitted among two or more settlement instructions, among two or more settlement restrictions or between a settlement instruction and a settlement restriction. Validation There must be congruence between the Intended Settlement Date and the type of link (e.g. an AFTER instruction can not have a lower Intended Settlement Date than the ISD of the linked instruction) The Party owner indicated for T2S actor reference has to exist The System User of the instruction has to be enabled to link the instruction of another party (with specific access rights) There must be congruence between the link type and the instruction status (e.g.link BEFORE with an already settled instruction) There must be congruence between the Pool Counter and the total number of instructions having the same Pool Reference Eligibility An instruction with link AFTER remains unsettled until the referenced instruction is settled During the night cycle an instruction with link AFTER skips the sequence if the referenced instruction can not be processed The instructions with link BEFORE are processed even if the referenced instruction is missing Settlement It is not allowed to create a link to an instruction partially settled In order to connect the instructions each other, there are two alternatives: Using a Processing Position Code: - INFO for information purposes, without any processing in T2S - BEFO the instruction shall be settled before the referenced instruction - AFTE the instruction shall be settled after the referenced instruction - WITH the instruction shall be settled at the same time of the referenced instruction ( all or none ). Using a Pool Reference, a common code linking a pool of instructions. The following instructions cannot be linked: 111

112 - A Liquidity Transfer instruction with a settlement instruction or a settlement restriction - A settlement instruction or a settlement restriction with an instruction automatically generated by T2S - A settlement instruction or a settlement restriction with an instruction type CLAI or TRAN. To link an instruction the following references may be used: T2S actor references - Account owner reference - Intra position movement reference - Intra balance movement reference - Account servicer reference - T2S reference - Market infrastructure Pool reference To modify a Link: A T2S actor is allowed to create, update, cancel a link. To update a link a Participant first needs to UNLINK through an AMENDMENT instruction and then LINK with the same message to input the modification Alternatively, Participant can delete and input again the instruction Portfolio Transfer Introduction Portfolio transfers occur when a client changes bank. Depending on the market and on the client profile (i.e. retail vs. institutional) requesting the transfer the procedure can be significantly different. This document does not consider the cross-border settlement of Portfolio Transfer, but Intra- Csd settlement only. The aim of this document is to: describe the current process flows identified as Portfolio Transfers Including all details required (due to rules, regulations and taxes); provide a new process and message format based on T2S Italian Portfolio Transfer current process Nowadays Monte Titoli's participants instruct Portfolio Transfers through a unilateral FOP instruction (no matching is required) using proprietary RNI 710 message. When the instruction 112

113 has been settled, MT transmits the settlement confirmation to both participants. All additional details provided by the delivering participant are confirmed through proprietary RNI 71N message (including beneficiary data and fiscal details). Portfolio transfers type are indentified as follow: (see also Table 1): 1. Institutional Client (Cliente istituzionale) = N 2. Delivery to a different holder (Trasferimento diverso intestatario) = N The following information are provided by the delivering party into the settlement instruction when transmitting to MT. The table below shows only an extract of the Portfolio's Transfer specific attributes, so that the basic settlement details such as delivering/receiving securities account, ISIN, quantity, etc, are not included. 113

114 Field id Italian field name Field name Description (RNI convention IDC 717 Riferimenti References It s the internal reference of the operation assigned by the delivering party. IDC 77A Dati fiscali Fiscal data of This field contains the following subfields Beneficiario Beneficiary (77A/1 77A/5) IDC 77A/1 IDC 77A/2 IDC 77A/3 IDC 77A/4 IDC 77A/5 Prezzo Buying clear secchissimo d acquisto price Cambio Clear price prezzo exchange rate secchissimo NAV Net Asset Value Cambio NAV Net Asset Value exchange rate Indicatore tipo Regime type regime indicator It represents the average price used for tax calculations It contains the exchange rate in case the clear price is in a currency different from EUR Same meaning as clear price Same meaning as per clear price exchange rate List of possible values: G = Gestito A = Amministrato D = Dichiarativo The tax regime indicated in the message is equal to that existing at the time of the contract with the ordering bank List of possible values: S/N (i.e. YES/NO) IDC 778 Cliente istituzionale Institutional Client IDC 177 Codice divisa Currency of It represents the currency of buying clear operazione buying clear price/ NAV price IDC 032 Data valuta Value Date It represents the date of portfolio transfer as the date positioned between the closing of client position and the fiscal data carried over by the counterparty. Not to be confused with the settlement date IDC 77B IDC 779 Trasferimento diverso intestatario Descrizione beneficiario Delivery to a different holder Beneficiary Data Table 14-7: Italian portfolio transfer information requirements It means whether there is a change in beneficial owner or not. Portfolio transfers are identified only by value N (i.e. NO). If value is Y (i.e. YES) then this instruction is not a portfolio transfer It is a free text (2x50 long) and contains details of final beneficiary/ies such as Name, Surname, Address and/or Tax identifier /s 114

115 Portfolio Transfer in T2S Introduction to T2S rules Instructions in T2S, Including portfolio transfer, has follow the T2S matching rules.this implies that both the delivering and the receiving party should instruct their own side of the transaction and in order for this to be Identified as a Portfolio Transfer, "PORT" will be used as the Securities Transaction Type identifier. After the T2S launch the MT 710 will not be supported and therefore Portfolio Transfer in T2S will be instructed: For Monte Titoli participant acting as DCP in T2S sese.023 message or T2S GUI sent directly to the platform For Monte Titoli participants acting as ICP in T2S through G52 X-TRM settlement instruction or X-TRM online. The G52 messages are still being analysed a separate Users Standard will be provided concerning the specifics of the above mentioned messages. Trough sese.023 message sent to Monte Titoli All the data needed for the composition of the Portfolio Transfer, will be available in X-TRM and the relative message will be integrated including these data so as to be aligned with T2S. Those adaptations will be available in the "User standard messages". The Information below has to be used in the settlement instruction (sese.023) in order for this to be identified as a Portfolio Transfer: Transaction Type : PORT ; Change of Beneficial Ownership (alternative option below): - NCBO ( NO Change of Beneficial Owner) - YCBO ( Change of Beneficial Ownership) ; Beneficiary information: filled in the Delivering/Receiving parties (Party block 2 to 5) Fiscal Information: filled in Delivering/Receiving parties (Additional Information tag of each Party n item starting block Party 2) Introduction to T2S rules The T2S's proprietary format limitation, forces the Italian market to use "non formatted fields". This is due to the fact that the transposition from the Settlement Instruction (sese. 023) to the Allegement Message (sese.028), the Status Advise (sese.024) and Confirmation Message (sese.025) does not include the full set of information provided in the original instruction. For ICPs all information will be transposed in G56 Allegement, Confirmation and Status Advice Messages. a) Change of Beneficial Ownership The specific field for this information is <BnfclOwnrsh>, which is not transposed in sese.028, sese.024 and sese.025, therefore this specific field is used: <TradDtls> <TradId> 115

116 b) Common ID It is an optional field. In order to ensure the proper matching of the two transactions in T2S the field <CmonId> should be populated, the reason why this field is adopted is because the Final Beneficiaries ( valued in Party2 ) are not identified using BIC codes and therefore this can't be considered as field for matching. c) Deal Price Clear Purchase Price (only one of them is used in a transaction) it is envisioned to value them on the main field <DealPric> which has two different subfields <Val><Rate> and <Val><Amt><Ccy>, ( the Currency is envisioned to be always EUR). Moreover the NAV indicator is present on the narrative fied <NmAndAdr>. d) Final Beneficiaries The field Party2 in Receiving Settlement Parties is used in order to Identify the Final Beneficiaries, the specific field <NmAndAdr> is used because these are not identified with a BIC code: CSD's BIC valued in (MOTI): <RcvgSttlmPties> <Dpstry> <AnyBIC> BIC of the Monte titoli Participant: <RcvgSttlmPties> <Pty1> <AnyBIC> Bank, at which the final beneficiaries have an account (ABI CODE) and Information concerning the Final Beneficiaries including account number. < RcvgSttlmPties> <Pty2> <id><nmandadr> <Nm> e) Delivering account owner In order to Identify the original account owners, the Bank's BIC and the relative account information (FROM which the positions are transferred) the analogue field in the <DlvrgSttlmPties> is used: CSD's BIC is valued in (MOTI): <DlvrgSttlmPties> <Dpstry> <AnyBIC> 116

117 BIC of Monte Titoli participant (PARTY 1): <DlvrgSttlmPties> <Pty1> <AnyBIC> Bank, at which the order's party have an account (ABI CODE) and Information concerning the Instructing Beneficiaries including account number < DlvrgSttlmPties> <Pty2> <id><nmandadr> <Nm> These information are transferred on the messages chain generated such as sese.028, sese025 and sese Portfolio transfer message specification The tables below show Portfolio Transfer's specific information, the selected sese.023's fields and related sese.028 (Allegement), sese.025 (Confirmation) and sese.024 (Status Advice). For ICPs all information will be transposed in G56 Allegement, Confirmation and Status Advice Messages. ID(* ) G52 Sese.023 Transposed to: Field description Main Field Name Field name Sese. 028 G56 Iso Transaction code Sese. 025 Sese. 024 X X X TB D Change of beneficial owner indicator <TradDtls> <TradDtls> <TradId> X X X TB D Average value date <TradDtls> <TradDtls> <TradId> X X X TB D Regime type indicator <TradDtls> <TradDtls> <TradId> X X X TB D TB D Beneficiary Data (Fiscal Code name and address ) Beneficiary Data (Fiscal Code name and address) <DlvrgSttlmPties> <RcvgSttlmPties> <DlvrgSttlmPties> <Pty2> <id><nmandadr> <Nm> <RcvgSttlmPties> <Pty2> <id><nmandadr> X X X X X X 117

118 <Nm> TB D Clear purchase price (bonds) <TradDtls> <TradDtls> <DealPric> <Val><Rate> X X Clear purchase price (shares) <TradDtls> <TradDtls> <DealPric> <Val><Amt><Ccy> X X Table 14-8: Beneficiary Data and Purchase Fiscal Information of the Beneficiary (*) The Identification fields name of G52 message are in progress and will be specified in Standard for User Trade identification format specification The field <TradId> of the block <TradDtls> is a field which can contain a maximum of 16 characters, the below shows how the information should be structured: a) Trade Details: The field <TradId>, is a mandatory field and formatted as: <TradDtls> <TradId> Format Specification: Regime Type Indicator/Change of Beneficial Ownership/Average Value date a) Regime Type Indicator: b) Change of Beneficial Ownership: Four Characters c) Average Value Date: six characters d) Information separator (/): two characters 118

119 Name Example notes A Regime Type Indicator Change of Beneficial owner NCBO one letter choice from: G = Gestito A = Amministrativo D = Dichiarativo NCBO = No change of Beneficial Owner YCBO = Change of Beneficial owner Average Value Date DDMMYY Table 14-9: < TradId> Field Example Name and address format specification The field <NmAndAdr><Nm> is a narrative field which can contain a maximum of 140 characters, the below shows how these information should be detailed: a) Receiving Settlement Party: The field < NmAndAdr><Nm> is formatted as: <RcvgSttlmPties> <Pty2> <id><nmandadr> <Nm> Price NAV Indicator / Account information of the Final Beneficiaries / Fiscal Code, name and address If there is more than one beneficiary data, the second one is valued on the : <RcvgSttlmPties> <Pty3> <id><nmandadr> <Nm> Fiscal Code, name and address the third one: <RcvgSttlmPties> <Pty4> <id><nmandadr> <Nm> Fiscal Code, name and address There is a limit of a maximum of four data beneficiaries per sese.023 since Party 5 <pty5> is the last one wherein this can be contained. Format Specification: 119

120 a) Price NAV indicator b) Account of Final Beneficiaries: Max 35 Characters c) Information separator ( / ): two characters. d) Fiscal Code (optional field) and Name and Address: Summing up the characters of a),and b)which are of 36 characters the remaining characters for this field are

121 Name Example notes Price NAV Indicator YNAV To be valued with: YNAV: if price is expressed as a Net Asset Value NNAV: if price is not expressed as a Net Asset Value Account of the Final Beneficiaries ( ABI CAB ( Max 35 Characters) + Account Destination account) Fiscal Code, name and address RSSMRC83F19F205I Marco Rossi Via Italia 1 Milano Table 14-10: < NmAndAdr><Nm> Field Example This field contains the Fiscal code information. Name and address b) Delivering Settlement Party: The field < NmAndAdr> <Nm> is formatted as: <DlvgSttlmPties> <Pty2> <id><nmandadr> <Nm> Fiscal Code, name and address of the Original Beneficieries If there is more than one beneficiary data, the second one is valued on the : the third one: <DlvgSttlmPties> <Pty3> <id><nmandadr> <Nm> Fiscal Code, name and address <DlvgSttlmPties> <Pty4> <id><nmandadr> <Nm> Fiscal Code, name and address There is a limit of a maximum of four data original beneficiaries per sese.023 since Party 5 <pty5> is the last one wherein this can be contained. Format Specification: 121

122 a) Account of original Beneficiaries (ABI CAB): Max 35 Characters b) Information separator ( / ): one character Custody services Placements, Buybacks and Exchange offer of Government Securities NEWCOL procedure (AS IS) The centralization of government bonds are made as a result of the placement instructions managed by the Bank of Italy through the procedure Placement of Government Bonds (NEWCOL) and the related settlement instructions managed by Monte Titoli through the settlement system Express II. Through the NEWCOL procedure, the Bank of Italy on behalf of the Ministry of Economy and Finance (MEF) manages: Placement of government bonds through ordinary and supplementary auction with direct placement; Buy-back of government securities; Exchange transactions (similarly, from the functional point of view, to a placement instruction settled through securities) Placement in T2S Bank of Italy the day of Auction: Transmits to MT the RNI710 message (type 5/0 op 27) deferred to the settlement date, containing the total nominal value of each financial instrument subjected to placement; in this message the counterparty is the MEF account (12510) Transmits to X-TRM (flow G60) the Settlement Instructions of the Auction At the end of day, the Bank of Italy sends to X-TRM the G62 flow of night reconciliation. At the end of day of the Auction after the reconciliation of flows between Bank of Italy and Monte Titoli, the transactions will be sent in T2S.organized as follows: For placement on the securities account of MEF (12510) a FOP settlement instruction is sent; For each trade concluded, a DVP settlement instruction is sent, linked to the FOP instruction using a link type AFTER All the settlement instructions will be sent as already matched ; The Intended Settlement day: The success of the instructions described will be notified to the Bank of Italy and to the participants subscribers through the message 71N and/or the flow G56/G70 At the end validity date: approximately 5 days after the intended settlement date, settlement instructions not yet settled are cancelled by Monte Titoli N.B.: for supplementay auctions, the day after the auction and the intended settlement day may coincide. 122

123 The diagram below describes the Placement workflow and the interaction with T2S. Figure 14-15: Workflow of placement in T2S (1/2) Figure 14-16: Workflow of placement in T2S (2/2) 123

124 Buy-back in T2S The day of auction (Buy-back) : The Bank of Italy transmits the message 710 (type 6/2 op 28) deferred to the settlement date containing the total nominal value of each financial instrument subjected to buy-back; in this message the counterparty is the MEF account (12510) The Bank of Italy transmits to X-TRM (flow G60) the buy-back trades concluded through the auction At the end of day, the Bank of Italy sends to X-TRM the flow G62 of night reconciliation. The day of the auction, after the reconciliation of flows between Bank of Italy and Monte Titoli, the transactions will be sent in T2S organized as follows: For buy-back on the securities account of MEF (12510) a FOP settlement instruction is sent For each trade processed, a DVP settlement instruction is sent, linked to the FOP instruction using a link type BEFORE ; All the settlement instructions will be sent as already matched ; The Intended Settlement day: The success of the instructions described will be notified to the Bank of Italy and to the participants subscribers through the message 71N and/or the flow G56/G70 At the end validity date: approximately 5 days after the intended settlement date, settlement instructions not yet settled are cancelled on Monte Titoli initiative Exchange offer of Government Securities The exchange of securities, from the functional point of view, is a similar to a placement instruction settled through securities The details referring to placement and exchange are described in the previous paragraphs. It should be noted that for one bond in placement, there may be a buy-back up to ten. At the end of an auction of exchange, the following information will be provided: a message 710 for the placed bond plus one for a buy-back bond A flow G60 for the placed bond plus one for each buy-back bond Government Bond: Interest Payment and Redemption in T2S AS IS Now the Government Bonds Interest payment and Redemption take place in Target2. 124

125 Currently Interest Payment and Redemption of Government bonds takes place during the night cycle of Express II, in T2 platform with procedure 6 dedicated liquidity where the crediting is done on a RTGS or sub-account of beneficiaries. The process is structured as follows: MT sends to Bank of Italy the data regarding the payment amounts The Bank of Italy performs the reconciliation procedures and confirms the result to Monte Titoli After the start of Target 2 night-time procedure, Bank of Italy sends a current order of debit of its own RTGS account and credit of its own sub-account After the start cycle, Monte Titoli sends to ASI the messages (ASTI) debiting the Bank of Italy sub-account in return of its own technical account and, after receiving notification of the credit (ASIS), debiting its own technical account and crediting the subaccounts of the beneficiaries. TO BE in T2S The interest payment and redemption of Government Bonds will take place in T2S during the night-time settlement cycle in the first sequence dedicated to a Corporate Action. The process is structured as follows: At the latest of the Start of Day (6:45pm 7:30 pm), MT sends to Bank of Italy the amount to be paid and after confirmation of amount proceeds for crediting the cash to the DCA of Monte Titoli. Afterwards, Monte Titoli will distribute these amounts to the intermediaries, ensuring the banks to use this liquidity, already in the first T2S night-time cycle. The instructions payment free of delivery (PFOD), generated by Monte Titoli, are linked together and settled on all-or none bases Issuer Instructions (Issuance, Mark-Up, Mark-Down) Below some typical operations of the Issuer: 1. Centralization of new issuances of financial instruments (First Issuance) 2. Issuance of new tranches of financial instruments already issued (Mark-Up) 3. Reduction of nominal value as a result of repurchase / redemption (Mark-Down). These transactions will be available in T2S only through MT s technical infrastructure (Indirectly connected operative model) using the communication channel: RNI, SWIFT (ISO15022/ISO20022), MT-X First Issuance and Mark-up (AS IS) General features of these transactions: The Issuer currently sends MT the elements required to perform the instructions: - The ISIN code of the financial instrument to be centralized - The value date (on sight or deferred date) for the instruction to be settled - The amount (quantity/nominal value) of the financial instrument to be credited - The own security account of financial instrument to be debited the global amount (quantity/nominal value) 125

126 - The beneficiary/ies security/ies account For further issuances, the issuer has to communicate the new global amount of the issue and the increased amount to be issued, using the standard MT communication channels. MT provides to register the issue in book entries by debiting the issuer account and crediting the intermediaries accounts First issuance and Mark-up in T2S MT maintains the responsibility for the management and checks on the centralisation ( deliberato amount vs issued amount), and updates such details only upon formal notification by the issuer. In correspondence with the instruction sent by the issuer, already matched (FOP) settlement instructions will be sent to T2S, one by each beneficiary intermediary, under the condition of simultaneous settlement. Similarly to what happens today, the instruction can be processed on sight or at a deferred date Reduction of nominal value (Mark-Down) AS IS General characteristics of the transaction: The issuer can request the reduction of the quantity or nominal value of financial instruments centralized, communicating the following information: The ISIN code of the financial instrument to be reduced in quantity/ nominal value The value date (on sight or deferred date) of the instruction to be settled The accounts affected by the transaction (issuer account and security account of the issuer in their role as intermediary) The amount (quantity/nominal value) of the financial instrument to be reduced The transaction can be executed by the Issuer, affecting the holdings on: 1. Their own securities account, in their role as Intermediary; 2. The securities account of any MT intermediary. In the first case, mark-down is executed by the issuer themselves via 710 message (so called op 28). In the second case, the issuer sends MT a notification quoting the amount to be reduced and the securities account affected. MT executes the transaction only upon receipt of the authorization of the intermediary involved Reduction of Nominal Value (Mark-Down) in T2S In T2S the Mark-Down executed by Issuer on its own security account (in its role of intermediary), will be sent to T2S as already matched instruction. The Mark-Down executed by Issuer on intermediary s accounts will be sent to T2S as an instruction to be matched. Such matching request, replaces the administrative authorization request by the intermediary. In this case, the RNI710/MT542 messages will be sent to T2S thought X-TRM platform. Please refer to the taxonomy hereafter: 126

127 Table 14-11: Taxonomy for mark-down 14.7 Corporate action Introduction Securities bookings resulting from Corporate Actions processing, will be outsourced to T2S. MT will maintain value added functions, as well as the commercial relationship with Clients, by maintaining, at the same time, full legal responsibility towards the latter. Within this ambit, while it is recognized that Corporate Action Processing is out of T2S scope, the organization, operational and IT impacts on Clients infrastructure are to be taken into account, and analyized. Endorsement of Corporate Actions Processing International Standards (Cash Distributions and Reorganizations Harmonization) represents a key factor for migration to T2S. Adaptation Guidelines Particular attention has been given by Monte Titoli to following items: Maintain as much as possible communication protocols unchanged in the relationship with Clients Make securities arising from Corporate Actions available at the start of the first night settlement cycle on the day following the settlement date (SD) Let the gross settlement of cash related to Corporate Actions within midday on settlement date. Guarantee full choice cash settlement system to Clients, on the basis of Corporate Event Decisions taken Following are the decisions agreed during T2S Corporate Actions meetings held last year: Monte Titoli grants flexibility to clients, including intermediaries and issuers, on their preferred cash settlement system: T2 vs T2S As it happens nowadays, issuers will notify their preferred cash settlement system (that will be used as the default system) to Monte Titoli via MT-X. Issuers will have, however, the possibility to opt for the other system at any time Cash settlement agents acting on behalf of intermediaries, if any, will also instruct Monte Titoli on their preferred cash settlement system (that will be used as the default system) with the methods already in use. Agents will have, however, the possibility to opt for the other system at any time Payment pre-advice and advice messages will continue to be provided by Monte Titoli through the electronic communication channels in use (RNI /SWIFT/MT-X) 127

128 Both T2S directly and indirectly connected participants will continue receiving Corporate Action information messages from Monte Titoli, as well as payment messages and statements of accounts. The same participants will continue relying on Monte Titoli for the processing of their Corporate Action Instructions All instructions (FOP/PFOD) will have the CA unique reference in order to enable the paying agent/beneficiary to identify the CA that is being processing. Monte Titoli will use NOS (numero operazione speciale) for domestic securities and COAF for foreign financtial instruments, both of them are reported in all provided information. In addition, T2S directly connected participants will receive information flows from T2S As a confirmation of positive Corporate Event processing, all involved parties will receive RNI 7B2 messages (or the equivalent SWIFT message) For securities movements 71N (or the equivalent SWIFT message) will be still available. Corporate Actions Processing According to the guidelines drawn up by International Standards, Corporate Events have been dividend into two main categories: DISTRIBUTION without options (cash distribution, securities distribution) with options (cash or securities distribution) REORGANIZATIONS Mandatory with options (option right exercise) Mandatory without options (mandatory conversion) Voluntary (tender offer) T2S Corporate Action settlement instructions Independently on the Event type, Corporate Action processing consists in instructions sent to T2S for cash and/or securities settlement settlement 128

129 Table 14-12: T2S Corporate Action settlement instructions Securities distributions Monte Titoli processes Securities Distributions by crediting, on settlement date, disbursed securities in the intermediaries accounts, on positions as of Record Date No impacts on intermediaries are envisaged, but it is important to note that: Record Date positions are the ones certified by T2S Disbursed securities are credited on intermediaries accounts and they will be available on SD, before the start of the first overnight settlement batch cycle Settlement of already matched DFP instructions for the booking of securities is confirmed via RNI71N or MT566 or sese.025 messages Cash distributions Upon appointment from Issuers, Monte Titoli processes Cash Distributions by crediting cash on intermediaries accounts, on Settlement Date, on the basis of balances as of the Record Date. Cash Distributions include: A. Interest payments on corporate bonds B. Cash dividends Settlement occurs according to the timing established by T2S (as per International Standards): Cash will be settled within 12:00 on SD Paying agents will make the cash available for distribution on SD, within the deadline that is still to be established Within the agreed payment model, each issuer/paying agent will have the chance to choose its preferred settlement system: its own RTGS account in T2 its own DCA in T2S Each intermediary, also, may opt to receive funds on one of the two: 129

130 its own RTGS account in T2 Its own DCA in T2S Cash settlement scenario in T2 The diagram below shows the workflow for paying agent that decide to pay through its own T2 account. The beneficiaries may decide to receive cash on either their T2 or T2S accounts: Figure 14-17: Cash settlement scenario in T2S T2 account Figure 14-18: Payment instructions rejection/cancellation T2 Account The payment in T2 is made through Procedure n. 5 with information period option for debiting the RTGS account of the paying agent. The information period option is available to let paying agent rejecting cash transfer orders within 12:00 on SD (see reference XI ) 130

131 The paying agent may revoke the transfer order within 11:45 on SD. Monte Titoli cancels the transfer order accordingly. If no rejection/revoke is instructed, beneficiaries accounts are credited as follows: MT debits its own RTGS account and credits intermediaries RTGS accounts, for the ones who opted to receive cash in T2 MT debits its own RTGS account to the benefit of its DCA account for subsequent delivery of cash to intermediaries DCAs, for the ones who opted to receive cash in T2S This will allow MT to avoid to collect power of attorneys from intermediaries, as otherwise T2S requires when CSDs instruct cash transfer to participants DCAs Payments that are unsettled within the established deadline due to a lack of cash, are postponed to the following business day. Intermediaries are advised of the delay with 7B2 messages N.B.: for further information of cash distribution in T2 see reference XI Cash settlement in T2S scenario The diagram below shows the workflow for paying agent that decide to pay through its own T2S DCA. account. The beneficiaries may decide to receive cash on either their T2 or T2S accounts: Figure 14-19: Cash settlement scenario in T2S T2S DCA 131

132 Figure 14-20: Payment instructions rejection/cancellation T2S DCA The paying agent DCA is debited real time by MT, via already matched PFOD instructions in on-hold status. Such instructions have the CORP identifier. Within 11:45 on SD, the paying agent may need to reject the transfer order. MT then cancels the PFOD instructions and releases all other PFOD instructions for which cash cover is available If no rejection/refusal is instructed, beneficiaries accounts are credited as follows: MT transfers funds to its own T2 RTGS account for subsequent transfer to the benefit of intermediaries RTGS accounts, for the ones willing to receive cash in T2 MT debits its own DCA in T2S for subsequent transfer to the intermediaries DCAs, for the ones willing to receive cash in T2S This solution allows MT to avoid to collect power of attorneys from intermediaries, as otherwise T2S requires when CSDs instruct cash transfer to participants DCAs Unsettled payments due to a lack of cash within the established deadline are postponed to be following business day. Intermediaries are advised of the delay with 7B2 messages Mandatory Reorganisations with options Monte Titoli processes the Corporate Action in T2S according to instructions from intermediaries, on the basis of balances as of Record Date. Settlement occurs within 16:00 according to the timeline established by T2S Within the agreed model, each issuer/paying agent has the chance to choose its preferred settlement system: its own RTGS account in T2 its own DCA in T2S Each intermediary, also, will opt to receive fund debits on one of the two: its own RTGS account in T2 Its own DCA in T2S 132

133 For the sake of simplicity, the following sections detail the cash flow only. Distinction is made between payments settled in T2 or in T2S Rights subscription Rights subscription instructions are sent via RNI 715 messages (or equivalent SWIFT messages). This message remains unaltered. The latest deadline for receiving instructions is the Corporate Action end date (T). Such deadline will be better defined soon after the daily schedule is finalized On (T), on the basis of intermediaries instructions, MT calculates entitlements, forwards payment advice messages and makes the balances of rights that have been the object of instructions unavailable in the intermediaries accounts MT sends payment instruction messages (RNI 7B1/7B2/ 7B3) Settlement of cash in T2S MT forwards PFOD instructions to T2S: PFOD instructions have the priority reserved PFOD instructions have the CA unique reference to which they refer to, in order to enable the paying agent to identify the CA that is being processing. In case of funds availability, cash is settled through the debit of the DCA s paying agent and the credit of MT s DCA The paying agent receives a confirmation of the debit entry, via either sese.025 or 71N RNI messages, which also have the CA unique reference In case funds are not available within the closure of the settlement phase, MT cancels the payment order by its own initiative, sends advice to the paying agent and starts contingency Netting in T2S when the paying agent and the intermediary instructing subscription are the same entity As in T2, the netting of payment obligations between the paying agent and the intermediary, when they are the same entity, is possible in T2S (procedure n. 5) Netting is calculated by Monte Titoli. The intermediary s debit instruction is linked to the paying agent s credit instruction for settlement on a all or none basis 133

134 Figure 14-21: Cash settlement in T2S (ordinary process) Contingency: settlement of failed instructions Contingency refers to instructions which failed settlement due to a lack of cash during CA processing. In case of lack of cash: The PFOD instruction remains pending in T2S until cancellation by MT MT solicits the intermediary to make funds available. After the intermediary confirmation to reduce the amount to be subscribed, MT adjusts the amount that is still unsettled by sending a new settlement instruction with the new (reduced) amount If contingency fails, MT cancels the new settlement instruction. No other settlement attempts are done 134

135 The diagram below shows the workflow of contingency process. Figure 14-22: Cash settlement in T2S (contingency process) Securities settlement in T2S Upon receipt of Cash settlement confirmation, the system checks payments settled in T2 and/or in T2S equal the aggregate amount. After realignment: Underlying securities are debited from intermediaries accounts New securities should be available BEFORE the overnight cycle of settlement date +1. The securities bookings mentioned above are the result of FOP instructions, having the CORP identifier and a Reference Pool number which are linked between each other for settlement on a all or none basis The Reference Pool bears the CA unique reference number + 1 progressive number The credit of funds raised to the DCA or RTGS account of the paying agent acting on the issuer s behalf Securities and cash Realignment and accounting messages in T2S All messages to issuing companies/intermediaries/paying agents acting on behalf of issuers/ sellement agents appointed by intermediaries are provided by MT through the communication channels in use (RNI /SWIFT/MT-X) DCPs will also receive messages from T2S. Messages are: a) Cash 135

136 Payment pre-advice Confirmation of funds availability Payment advice Payment delay advice Payment cancellation advice b) Securities Summary of instructions received and processed Bookings in the securities accounts Daily statement of accounts Figure 14-23: Corporate Actions - Daily schedule in T2S (1/2) 136

137 Figure 14-24: Corporate Actions - Daily schedule in T2S (2/2) 14.8 Position Management Blocking and Reservation in T2S Blocking and Reservation functionalities are included into restriction processing module. These functionalities allow the operator to block a specific position quantity (partial or total) in a specific securities account. The following elements are needed to create and use Blocking and Reservation functionalities: The securities account The restriction type (to set up) that identify a specific sub-balance of the securities account The restriction reference assigned by T2S when block has been created. It will be adopted to use/increase/decrease the quantity blocked/reserved. Configuration of the Restriction Type: Only CSD and T2S Operator can set up the Restriction type at static data level (cfr UDFS v ). This configuration allows CSD to define an identification (4 byte es. BLK1), that can be used by CSD Community to identify a specific securities account sub-balance. The configuration related to a restriction type (Blocking or Reservation) on a securities position includes only the definition of validity period and not other types of rules unlike other restriction types (Page 47 UDFS Restriction types). 137

138 For blocking functionality can be used Settlement Restriction (SR) or Settlement instruction (SI) according the following rules: Table 14-13: Blocking How to use If the quantity specified into settlement restriction is more than the quantity available on subbalance delivering, the Settlement Restriction is not partially settled and is recycled waiting incoming securities (ref. pag 449 T2S-UDFS 1.2.1). If the quantity specified into settlement instruction is more than the quantity available on subbalance delivering, the instruction will be executed partially only if set up of partial settlement indicator allows it (ref. pag 463 T2S-UDFS 1.2.1). For reservation functionality can be used Settlement Restriction (SR) or Settlement instruction (SI) according the following rules: Table 14-14: Reservation How to use If the quantity indicated in the settlement restriction is more than the one available on the subbalance delivering, the instruction will be executed partially and sent to settlement until it will reach the quantity reserved (ref. pag 449 T2S-UDFS 1.2.1). If the quantity indicated in the settlement instruction is more than the one available on subbalance delivering, it will be executed partially only if the related partial settlement indicator allow it (ref. pag 474 T2S-UDFS 1.2.1). 138

139 Blocking and Reservation functionalities will be offered by Monte Titoli starting from wave 1: For indirect participant, Monte Titoli will offer specific functions in MT-X specific messages: for SR: - RNI N (properly modified) - ISO15022 MT524 - MT508 - ISO20022 semt semt semt for Settlement Instruction: - G50/52 (properly modified) - ISO20022 sese sese sese Direct participants can use the same instructions (in ISO format) sent directly to T2S. The following schema describes the interaction between participant and MT and/or T2S for blocking and reservation management. Figure 14-25: Blocking and Reservation management process 139

140 The following 3 tables list and describe the functional impacts foreseen for blocking and reservation management. Table 14-15: Functional changes for Blocking and Reservations (1/3) Table 14-16: Functional changes for Blocking and Reservations (2/3) 140

141 Table 14-17: Functional changes for Blocking and Reservations (3/3) Earmarking and Earmarking for autocollateralization Earmarking is included into restriction processing module, as well as Blocking and Reservation functionalities. This process allow to fix a specific quantity in a specific security account only for a specific trade or process (i.e. for auto-collateralisation) There are two types of earmarking: Earmarking for auto-collateralisation defined through T2S GUI by T2S Operator Earmarking defined through T2S GUI by CSD Both restriction process earmarking and earmarking for auto-collateralisation functions work in the same way except for positions identified for auto-collateralisation, that can be included in the automatic process provided by T2S for auto-collateralisation; the others can be used for specific business purposes, decided by T2S Actors. Earmarking for auto-collateralisation at securities account level (ref. Pag 452 and 831 T2S-UDFS 1.2.1) Earmarking for auto-collateralisation can be adopted: At position level (restriction type + security account + ISIN) At securities account level In the second case the restriction type prevals on a restriction type set up as sub-balance in the same account in a settlement instruction or settlement restriction, except for the ones related to Blocking or Reservation (ref. T2S UR-T2S and UDFS Pag 452 T2S-UDFS ). If a security account must be earmarked at account level it is necessary to post all positions available on the other sub-balances (delivery, earmarked different from the one used to flag the account) on earmarked position for auto-collateralisation in advance, except for positions blocked or reserved (ref. Pag 453 T2S-UDFS ). The restriction type (earmarking) combined with securities account and ISIN, identifies a specific security position into a: Settlement Restriction: as balance from or balance to 141

142 Settlement Instruction: as balance impacted by delivering or receiving Validity Check of the sub-balances involved in a SR/SI in T2S In T2S there is no need to create a security position defined into SI or in a SR in advance, to settle the trade. Position will be created during the settlement phase. This is valid for any type of sub-balance (delivery, earmarking, etc ) On the opposit, every positions in debit must be already present during the settlement phase (ref. pag 452 T2S-UDFS 1.2.1). For each restriction earmarking that will be defined, it can be possible to create any sub-balance of the principal security account and reserve specific security quantities through the following actions: Set up Increase Decrease Use For earmarking no restriction reference (as blocking and reservation) must be indicated but only the specific restriction type. If the quantity present in the settlement restriction is more than the one available on subbalance delivering, instruction will be executed partially but it will not be recycled to settlement phase for the residual quantity (ref. pag 482 and 486 T2S-UDFS 1.2.1). If the quantity included in the settlement instruction is more than the one available on subbalance delivering, it will be executed partially only if the related partial settlement indicator allows it (ref. pag 484 and 488 T2S-UDFS 1.2.1). Table 14-18: Earmarking How to use Auto-collateralisation concepts (ref. from pag 344 to 361 T2S-UDFS v ) There are two types of auto-collateralisation in T2S: on flow on stock 142

143 Auto-collateralisation on flow prevals on auto-collateralisation on stock. Auto-collateralisation on flow on SI of receipt of securities, participant can specify the subbalance of the own security account (Earmarking for auto-collateralisation). In this way, in case of cash position not covered, security received from settlement can be subject to collateral by T2S process. Auto-collateralisation on stock in case of cash position not covered and after checking that there is not the possibility to apply the collateralisation on flow (or it is not sufficient), it will be activated the collateralisation on stock. Monte titoli will offer earmarking functionality starting from wave 1. The choice of all participants to set up the earmarking for auto-collateralisation at security account level, will be managed directly by Monte Titoli in T2S, same as today for the self collateralization through the Membership forms ( scheda dati operativi ). At migration stage it will be sent into the sub-balance earmarked, the proper collateral profiles powered, at present, from the flows G33-G34. At the beginning of the new process, these flows will be abandoned. For indirect participant, Monte Titoli will offer specific functions in MT-X and/or specific messages for Settelement Restrictions, in alternative to the flows G33-G34: RNI N (properly modified) ISO15022 MT524 - MT508 ISO20022 semt semt semt and for the Settlement Instructions: G50/52 (properly modified) ISO20022 sese sese sese Direct participants can use the same instructions (in ISO format), sent directly to T2S The following schema describes the interaction between participant and MT and/or T2S for earmarking management. 143

144 Figure 14-26: Earmarking management process The following 3 tables list and describe the functional impacts foreseen for earmarking management. 144

145 Table 14-19: Functional changes for earmarking (1/3) Table 14-20: Functional changes for earmarking (2/3) 145