USER REQUIREMENTS: T2S TECHNICAL GROUP ON SCOPE & SCHEDULE

TARGET2-SECURITIES PROJECT TEAM WORKING DOCUMENT 17 September 2007 T2S/07/0218 DRAFT V4.0 AG USER REQUIREMENTS: T2S TECHNICAL GROUP ON SCOPE & SCHEDULE Table of Contents 1. EXECUTIVE SUMMARY... 3 2. INTRODUCTION... 4 3. SCOPE... 5 3.1 SECURITIES CATEGORIES... 6 3.1.1 Categorisation of Securities... 6 3.1.2 Issues raised... 10 3.1.3 Links to other TGs... 11 3.2 TYPES OF TRANSACTIONS... 12 3.2.1 Transactions... 12 3.2.2 Logic of the Transaction Types... 12 3.2.3 Logic of grouping Transaction Types... 12 3.2.4 Issues raised... 12 3.2.5 Links to other TGs... 12 3.3 SETTLEMENT CURRENCIES... 13 3.3.1 Cash settlement in T2S... 13 3.3.2 Cash settlement outside T2S... 14 3.3.3 Issues raised... 14

3.3.4 Links to other TGs... 15 3.4 INTERACTION WITH EXTERNAL S... 16 3.4.1 Role and relationships between s in T2S... 16 3.4.2 Cross-s Settlement Procedure... 16 3.4.3 Scenarios of External s Interaction... 16 3.4.4 Maintenance of Static Data... 17 3.4.5 Issues raised... 17 3.4.6 Links to other TGs... 17 3.5 OVERALL PROCESS FLOW... 18 3.5.1 Open Issues... 18 3.5.2 Links to other TGs... 18 4. SCHEDULE... 19 4.1 GENERAL STRUCTURE OF THE SETTLEMENT DAY... 19 4.1.1 High-level T2S timetable... 19 4.1.2 Start of Day Procedures... 19 4.1.3 Main periods of the Settlement Day... 19 4.1.4 End of Day procedures... 19 4.1.5 Availability of Interfaces... 19 4.1.6 Specific Deadlines... 19 4.1.7 Calendar... 19 4.1.8 Issues raised... 20 4.1.9 Links to other TGs... 20 5. ANNEXES... 21 5.1 T2S GLOSSARY... 21 5.2 ISSUES ANALYSED BY OTHER TGS... 21 5.2.1 Archiving... 21 5.2.2 Use Cases... 21 Format Disclaimer: The current format of the URTG1 serves only as an outline of the analysis and the clarification required on the T2S Scope and Schedule. A uniform format of stating user requirements is to be used by all TGs at a later stage Page 2 of 22

1. Executive Summary [one two pages summary of the URTG1 for the benefit of the Eurosystem decision making bodies. To be drafted at the final stages of the document, perhaps as a consolidating Summary of overall T2S Users Requirements Document] Page 3 of 22

2. Introduction [TO BE DRAFTED] Introductory Text on the purpose of the UR TG1 as part of the Final T2S User Requirements Document The following topics are proposed to be covered by the TG s mandate: Table 1: Topics covered by TG1: T2S Scope & Schedule Proposed Topics Scope 1. Securities categories 2. Settlement currencies 3. Types of transactions 4. Overall Process Flow 5. Interaction with External s Schedule 6. General structure of the operational day Page 4 of 22

3. Scope General Introductory Text on the Scope of Businesses of T2S Following the Mandate.. List of Topics for the Scope Page 5 of 22

3.1 Securities Categories The aim of the current section is to identify the securities, the settlement of which will form part of the T2S Scope. In order to achieve this there is a need to use some eligibility criteria which reflect the standard T2S settlement procedures In principle, T2S shall cover all securities assigned an official International Securities Identifying Number (ISIN), held in book entry form in a T2S connected and be fungible from a settlement procedure perspective. An exhaustive list of all securities currently settled in the EU s is not the purpose of the current user requirements. However, a high level list of securities types and sub-types are included for presentational purposes. The list is equally not excluding the settlement of new securities that may be developed by the market as the outcome of financial innovation. An additional list of non-standardised securities (from the settlement perspective) have been identified with the help of the s expertise on the securities settled in their books. They refer to national specificities and local practices which may require special settlement procedures. The aim is not to exclude in principle any assets which are currently settled in s but to strike a balance between an all inclusive policy and a manageable and cost effective centralized platform. Following the presentation of the T2S settlement procedures in TG3, it remains to be evaluated whether the T2S settlement functionality can cover the specific settlement procedures of these assets. These procedures can either be accommodated within T2S with the introduction of a specific functionality module or remain within s as done currently. 3.1.1 Categorisation of Securities In principle all securities assigned an ISIN issued by a National Numbering Agent (NNA) under ISO 6166, which are further deposited and settled in book entry form in a T2S connected are part of the scope. Any derivative actions connected to such electronic settlement (physical delivery, registration etc) should remain with the s. Local securities that are currently not part of a connected s scope of businesses are not be part of T2S either. The underlying principle being that T2S should provide the functionality for covering the s current service level and types of assets. Eligibility Criteria Securities eligibility for inclusion in the T2S settlement services, should be assessed against the following criteria: The securities should 1. have an ISIN Code, as instrument identifier; 2. be held in a T2S connected ; Page 6 of 22

3. settle in book entry form and 4. be fungible (from settlement processes perspective). In this case fungibility is understood in a way that amounts of a certain security (designated by a specific ISIN) are interchangeable during the settlement process. This means, that no additional security identifier is required in addition to the ISIN for completing the settlement procedure (transfers in securities accounts). This does not exclude that some securities may require prior or subsequent steps to the settlement procedure in order to register, identify or update additional codes (registration codes, reference numbers etc). These procedures would be executed by the s as done currently. T2S should only perform the settlement processing layer associated with the ISIN. Non-standardised securities Some s have already identified securities which, despite having a single ISIN at issuance, they do not fall into the fungibility category as described above. Typical examples could be a specific corporate bond in Italy and the so called premium lottery bonds in Sweden. The description of their settlement procedures so far indicated that additional identifiers (certificate codes in Italy and trade sequence identifiers plus number specifications in the case of Sweden) may be required to be checked during the settlement procedure. Such functionality is in principle not part of the lean harmonised settlement procedure foreseen in T2S. However if such securities are expected to be still active by the time T2S is launched (start 2013) a procedure should be available for their settlement. This could either take place in s, providing the appropriate interaction between s and T2S is established. The current frequency of the settlement activity of such instruments is very low (on average, one settlement transaction per day is reported for the Italian corporate bond and 100 in the case of Sweden). The primary market activity of such instruments require higher volumes, especially in the case of the lottery bonds. However, this is a one-off event. The technical details of information exchange between s and T2S should be further analysed. In case the current assessment of the low settlement frequency is reconfirmed, this should not pose any considerable technical problems. The functionality could be similar to the Conditional Securities Delivery, where final settlement in T2S is conditional to additional release information to be provided by the s. An alternative solution would be the development of an additional functional module within T2S. This would provide the management and checking of additional codes during the settlement procedure. It could be a module specific to one, a few or ideally to all markets where non-fungible settlement procedures are required. Such solution would be in line with the AG discussion on the need to develop a lean T2S system without excluding the developments of additional services and modules clearly focused and billed on market specificities. The need for checking the Register Reference (RR) codes of transactions on Spanish equities could also be considered within this framework. The checking is performed by the local in order to update the Central Registry managed by it. Again, depending on the interaction services established between s Page 7 of 22

and T2S, the validation/checking of the RR could be managed by the prior to the final securities settlement in T2S. List of standardised securities Based on the analysis done by T2S project team on the list of securities provided by five of the s participating in TG1, four broad standardised settlement securities categories have been identified. Although the table does not aim at providing a detail instrument classification list of the EU securities market, the categories and their groups are in line the CFI classification: Table 3.1 Standardised securities Securities Categories Equities Debt Instruments Securities Sub-categories (groups) Shares (common/ordinary) Preference shares Preferred shares Convertible shares Preferred convertible shares Preference convertible shares Units (i.e. unit trusts/mutual funds) Equities (others) Bonds Convertible bonds Bonds with warrants attached Mapping to existing securities provided by s participating in TG1. Equity Shares, Preference shares Undertakings for Collective Investment in Transferable Securities (UCITS), Venture capital funds, KUXE, TPS (Trust preferred Securities), Mutual Fund, Equity funds, real property funds, index funds, forward market funds, other funds, mixed security and real property funds, Hedge funds, Pension funds, Exchange Traded Fund (ETF) Global bearer certificates/depository receipts, Savings share Bonds, debentures, public notes, Type A federal bond, Type B federal bond, TPS bond, funding debentures, participating debentures, inflation linked bonds, other linked bonds, Bonds cum warrants, bonds ex warrant, Exchangeable bonds, savings bank bonds. Corporate bond Convertible bond, convertible bond cum warrant, convertible bond ex warrant Page 8 of 22

Entitlements (Rights) Others/Miscellaneous Medium terms bonds Money market instruments Asset Backed Securities (ABS) Mortgage Backed Securities (MBS) Debt instruments (others) Allotment rights Subscription rights Purchase rights Warrants Entitlements (others) Certificates Treasury Note/Bill, Asset Backed Securities (ABS), Asset backed commercial papers, collateral debt obligations, Mortgage bonds, Mortgage Backed Securities (MBS), Bonds with put option, Callable bond/puttable bond, Covered Bonds, European covered bonds, Commercial Paper, Municipality paper Treasury financial papers, Credit linked notes. Certificate of deposit, Stripped Bonds, Stripped Coupons, fractional interests, residuals Subscription rights Warrants, Covered Warrants Security certificates, Index certificates, interest rate certificates, currency certificates, other certificates. Subscription certificates, liquidation share certificates, profit sharing certificates, registered profit sharing certificates, profit sharing certificates cum warrants, profit sharing certificates ex warrant, participating certificates, savings bank certificates, land charge deeds and charge certificates. Product certificates, Commodity certificates, Metal certificates Derivatives contracts (options, futures) have not been considered as they are not settled per se in a. Only their underlying assets may be settled in a. This list provided below, indicates the securities that do not fall in the category of standardised settlement procedures ( non-standardised securities ). Additional steps may be required either at the or at T2S level during the settlement procedure in order to execute transfers in the securities accounts. Table 3.2 Non standardised securities Page 9 of 22

Security type Specific national examples Specific settlement procedure Non-Fungible securities Italian corporate bond Need to check the availability of certificate codes in the participants accounts. Swedish Premium lottery bonds Trade sequence identifiers and serial numbers (or number specifications ) to be recorded. In all cases, further analysis is required in order to assess whether or not s could perform the additional checks required at their local databases and instruct T2S for the final settlement procedure. In line with this, a preliminary investigation into the SE lottery bonds showed that the additional procedures described above are treated separately from the settlement processes. 3.1.2 Issues raised TG members are welcome to provide feedback on any other specific securities that may raise specific consideration in their markets. In doing so, respondents should first question how s are currently managing such securities. T2S is only offering to centralise in a common platform the electronic settlement of securities holdings in securities accounts. Table 3.1.3: Issues raised Issue Issue description Mitigation Related Outcome Status Reference approach agreed work in Code other Groups URTG1.3.1.1 From the standardised securities list provided, can it be List of exceptions/nonstandardised securities to be AG Open assumed that all checked with securities sub- EA and categories settled presented to the AG today in the fits into the list provided? URTG1.3.1.2 It would be also s still to provide na One average: one Open helpful if the % input on business secondary market Page 10 of 22

settlement volumes of the security subtypes could be provided by the? case/relevance of any exception list securities settlement transaction for the IT corporate bond, 100 secondary market settlement transactions for the SE lottery bond, 400,000 primary market settlement transactions URTG1.3.1.3 There is a need to If the market sees the TG3 Open further define the need for developing additional module such a module in for settling non- T2S, TG3 should standardised include it as an securities (non- additional functional fungible). module in the description of the T2S settlement services 3.1.3 Links to other TGs The categorisation of securities may assist requirement definitions in other workstreams as listed in the table below Table 3.1.4: Links to other TGs TG2 Lifecycle management and matching TG3 Settlement functionality TG4 Static data: definition of the necessary securities static data Requirements defined by another work stream Requirements stemming from S&S impacting on other work streams Page 11 of 22

3.2 Types of transactions 3.2.1 Transactions 3.2.2 Logic of the Transaction Types 3.2.3 Logic of grouping Transaction Types In Figure XXX, a first draft of the types of transactions is listed. Figure 3.3.x: Types of Transactions the settlement of which is to be covered by T2S [DRAFT] 3.2.4 Issues raised Table 3.2.3: Open Issues Open Issue Issue description Mitigation Related Outcome Status Reference approach agreed work in Code other Groups URTG1.3.2.1 3.2.5 Links to other TGs Table 3.3.2 Links to other TGs TG2 Lifecycle management: full list of instructions types TG3 Settlement functionality: specific settlement processes, settlement mechanisms for specific categories of securities, settlement process of non-settlement related transactions TG4 Static data: description of specific data needs Requirements defined by another work stream Requirements stemming from S&S impacting on other work streams Page 12 of 22

3.3 Settlement Currencies 3.3.1 Cash settlement in T2S Euro CeBM In planning T2S, the Eurosystem s prime focus is efficiency and security in the euro area securities settlement environment. As a result, and in accordance with principles 8, 9 and 10, the focus of T2S at least during its first production phase, is to provide settlement services in euro central bank money (CeBM). The cash settlement will take place in T2S cash sub-accounts. The exact location and interaction of these accounts with the TARGET2 RTGS accounts is currently analysed by TG3 (mini-consultation) and will be presented to the AG for validation. The service could also be available to those s outside the euro area which chose to settle in euro CeBM. Securities that are denominated in foreign currency but settled in euro CeBM will also be covered by T2S, provided they are held through a T2S-connected. Non-euro CeBM According to principle 10, the system will be technically capable of providing settlement also in non-euro CeBM. This technical capability does not necessitate availability of the service from day one of T2S production, unless explicitly requested so by the relevant non-eurosystem NCB(s). In any case, the provision for settlement in non-euro CeBM requires the willingness of those NCBs to authorise the technical operation of a part of their cash accounts (or dedicated sub-accounts) by the Eurosystem. The initiative should come from the relevant NCB in coordination with its local market community. The connection of non-euro CeBM may require specific user requirements such as: The settlement instructions need to include currency codes as a parameter (not as a fixed settlement currency on the security as it will be possible to have the same ISIN that settles in different currencies). ISO instruction messages currently provide the possibility to include settlement currency information; The T2S cash account structure should also allow that some s participants may have more than one currency cash account; System interaction requirements between T2S and the payment system of central bank of the respective non-euro currencies; Definition of the Calendar of settlement (or opening) days for non-euro CeBM settlement in T2S. In addition to TARGET2 calendar, there is a need to maintain opening and closing days for additional CeBM currencies that will potentially connect to T2S; It should be clarified here that the possibility to connect non-euro CeBM to T2S (in addition to standard euro CeBM service) does not create a multi-currency, FX platform. Each single settlement transaction Page 13 of 22

continues to have only a single cash leg in a single currency. In its turn, this is not to be confused with the possibility to settle the same ISIN in more that one currencies (one currency per transaction). 3.3.2 Cash settlement outside T2S It should be noted that securities settlement the cash-leg of which takes place outside of T2S, in other currencies or CoBM is possible, while using a reservation mechanism until the external cash settlement has been finally processed. This service could be covered under the Conditional Securities Delivery (CoSD) functionality. The aim is to allow instructing parties, via their s, to complete specific securities settlement transactions in T2S using a securities blocking functionality in the T2S securities accounts. The blocking status is released by the instructing party(ies) via their which manages this service in T2S. The release instruction is sent to T2S when cash settlement outside T2S is complete. The next steps is final settlement in the T2S securities accounts. The exact service offered by this functionality is currently under a mini-consultation procedure primarily in TG3 but also partially in TG2 and TG5. In particular questions regarding which entity should manage or administer CoSD (instructing parties, s) and the unilateral/bilateral release and cancellation instructing are currently under investigation with the market and within the T2S Team. The service should not be used exclusively for conditional DvP settlement. It should be a tool for all kinds of conditional securities settlement (i.e. in the case where need for s to check specific securities or transactions reference codes prior to final settlement). 3.3.3 Issues raised TG1 members are welcome to provide input on what would be required from T2S in order to support securities settlement the cash leg of which is outside T2S. When it comes to non euro CeBM it seems rather difficult to define at this stage which these currencies will be. The aim would be to define in general terms what considerations need to be made to allow for their future inclusion (e.g. what kind of cash account handling capabilities, calendars etc). In this case a migration plan should be carefully planned and introduced (or at least anticipated at this stage). Table 3.3.1: Issues raised Open Issue Issue description Mitigation approach Related Outcome Status Reference agreed work Code in other Groups URTG1.3.3.1 Cash settlement To be tackled in the TG3 Open outside T2S (via context of defining the CoSD) may require T2S timetable. To support for deadlines analyse the implications Page 14 of 22

different to those applicable in the cash management of TARGET2. URTG1.3.3.2 In the case of CoSD, are there any technical restrictions for directly instructing users? URTG1.3.3.3 How would the T2S calendar of opening days be affected by the connection of non-euro CeBM currency(ies)? for eligibility and cut-off times. Issue is part of miniconsultation of TG2, TG3 and TG5 The inclusion of noneuro currencies in T2S (CeBM) might imply that the working days applicable for such non-euro currencies might be different from the TARGET 2 calendar. Open Open 3.3.4 Links to other TGs In such scenario the impact on other areas of the UR could be found in the following topics: Table 3.3.2 Links to other TGs TG2 Lifecycle Management: for the reservation mechanism and links with the cash settlement outside T2S TG3 Settlement functionality: cross-border settlement between s TG4 Static data TG5 Interfaces & Telecommunication TG6 Non-functional requirements: description of migration requirements and methodology Requirements defined by another work stream Requirements stemming from S&S impacting on other work streams Page 15 of 22

3.4 Interaction with external s 3.4.1 Role and relationships between s in T2S Definition of the Role and Relationships between s Implementation in the Static Data 3.4.2 Cross-s Settlement Procedure 3.4.3 Scenarios of External s Interaction When External s are involved, different scenarios need to be distinguished to explain the settlement procedure. These scenarios are detailed in the following section. Scenario 1: The Investor s are External and the Issuer is in T2S T2S Issuer Investor Investor Scenario 2: One Investor is External, one Investor and the Issuer are in T2S T2S Issuer Issuer Investor Investor Scenario 3: One Investor and the Issuer are External, one Investor is in T2S T2S Issuer Issuer Investor Investor Scenario 4: The Issuer is External, the Investor s are in T2S T2S Issuer Investor Investor Page 16 of 22

3.4.4 Maintenance of Static Data 3.4.5 Issues raised Table 3.4.1: Issues Open Issue Issue description Mitigation Related work Outcome Status Reference approach agreed in other TGs Code URTG1.3.4.1 3.4.6 Links to other TGs Table 3.4.2 Links to other TGs TG2 Lifecycle Management TG3 Settlement Functionality TG5 Interfaces and Telecommunications Requirements defined by another work stream Requirements stemming from S&S impacting on other work streams Page 17 of 22

3.5 Overall Process Flow Overview of T2S Functional Blocks and Interfaces 3.5.1 Open Issues Table 3.5.1: Open Issues Open Issue Issue description Mitigation Related Reference approach work Code agreed in other TGs URTG1.3.5.1 3.5.2 Links to other TGs This overall functional description is important as guidance tool for the processes described in other TGs. Table 3.4.2 Links to other TGs TG2 Lifecycle management TG3 Settlement functionality TG4 Static Data TG5 Interfaces and Telecommunications TG6 Non functional Requirements Requirements defined by another work stream Requirements stemming from S&S impacting on other work streams Page 18 of 22

4. Schedule Introductory Text on the Schedule of the operational day of T2S: Following the Mandate.. List of Topics for the Schedule 4.1 General Structure of the Settlement Day 4.1.1 High-level T2S timetable Box 4.x: A high level settlement timetable Chart Explanations: 4.1.2 Start of Day Procedures 4.1.3 Main periods of the Settlement Day T2S Night-time settlement processing: Maintenance window: Daytime processing: 4.1.4 End of Day procedures 4.1.5 Availability of Interfaces 4.1.6 Specific Deadlines 4.1.7 Calendar Page 19 of 22

4.1.8 Issues raised Table 4.1.1: Issues raised Open Issue Issue description Mitigation approach Related Outcome Status Reference agreed work in Code other TGs 4.1.9 Links to other TGs Table 4.1.2 Links to other TGs TG2 Lifecycle management TG3 Settlement functionality Requirements defined by another work stream Requirements stemming from S&S impacting on other work streams Page 20 of 22

5. Annexes [Any Technical Annexes, like detailed flow charts, Timetables and material from other TGs could be inserted here] 5.1 T2S Glossary Draft version: 0.2 T2S-07-0072_07073 0_glossary_v.0.2.xls 5.2 Issues analysed by other TGs 5.2.1 Archiving The Archiving topic and its corollary On-line storage is under consideration within TG6 TG6 members are asked to clarify their requirements on the following points: What Measurement on-line response time queries on-line response time reports on-line data storage period Archive retrieval time Archive period in seconds in seconds in months in hours in years Archive period duration being under national regulation, so far, the NUGs will be consulted on this topic during the "mini consultation" 5.2.2 Use Cases In this section the logic for devising the use case of T2S is presented together with the first draft list of the use cases as prepared by TG5. Page 21 of 22

Logic for devising the list of use cases CA Transfer Reorganization of Securities/ transaction Cash Blocking/Unblocking of CA FOP Transaction positions Types Mark CA up/mark payment down of Transaction securities Settlement Type Transaction Non-Settlement type transaction Lending/Borrowing transaction transaction Collateral transaction Payment Money only DVD Settlement DVP Settlement FOP Settlement Instruction Query query from from Settlement currency is non but it is a T2S Currency Settlement Currency is Non-T2S currency Instruction query from from participant Instruction Instruction maintenance maintenance participants participant Intra Transaction Cross transaction (Where Both investor are in T2S) Cross Border Transaction (Where one Investor is outside T2S) Instruction maintenance maintenance Balance query Query Both Participants have indirect access One Participant has direct access and the other has indirect access Both participants have direct access. Balance Balance query Query participant participant Participant Participant data data update update Issuer is within T2S Issuer is outside T2S Security data update Rule Rule update data update Regular reporting Draft list of the use cases. TG5 is working on the topic: \\Gimecb01\ homedir-ad$\dattade Page 22 of 22