CR raised by: T2S Project Team Institute: ECB Date raised: 15/09/08

Transcription

1 /2009/ CR raised by: T2S Project Team Institute: ECB Date raised: 15/09/08 Change Request title: Unmatched messages No further information CR ref. no: T2S URD 0007 (T2S-URD V4-CLA-07) Change Request Classification: Clarification Chapter 13 Priority (S,H,M,L): L Requestor Category: T2S project team T2S Remove reference to matching from UR , table 13-3 and the related flow diagrams. In line with the change request T2S URD 0018, T2S should inform the instructing party why matching was not successful by providing them with potential matching candidates that differ in a matching field only. The requirement T2S (Confirmation of validation and matching through status messages) should be modified as follows: "In addition to sending a negative validation status message when an instruction fails validation, T2S shall send a positive validation status message for those that pass validation. When negative, validation status messages shall report on more than one error, in the limit of validations performed by T2S for a single instruction. The same rules shall apply to matching status messages. Each negative message, whether positive or negative, returns the status and the reason code as assigned by life cycle management (chapter 5) to inform the instructing party why validation or matching failed. Both types of message This will be included in the subscription service; thus, CSDs and directly connected T2S parties can elect not to receive them." * SG Meeting on 03 Nov 2008 Outcome: Agreed Recommendation to the AG: Approval * AG Meeting on 25 Nov 2008 Approval of SG recommendation. However, this CR has to be further analysed because it is linked to the CR T2S URD 0018 that the AG sent back to the SG * SG meeting on 12 Jan 2009 Outcome: Rejected Recommendation to the AG: Rejection * AG Meeting on 20 Jan 2009 AG sent the CR back to the SG for further analysis because it is linked to the CR T2S URD 0018

2 CR raised by: T2S Project Team Institute: ECB Date raised: 24/09/08 Change Request title: Potential matching candidates CR ref. no: T2S URD 0018 (T2S-URD V4-CON-09) Change Request Classification: Substance Chapter 5 Priority (S,H,M,L): M Requestor Category: T2S project team T2S In line with market needs and current practice in some CSDs, T2S should inform the instructing party why matching was not successful by providing him with potential matching candidates that differ in one field only. The provision of a matching candidate would help the identification of possible matching candidates for unmatched settlement instructions. The requirement T2S (Status after matching) should be modified as follows: T2S Match Status after matching "After a succesful validation of a settlement instruction, T2S shall set the status of assign the instruction to the match status matched when it enters already matched and the match status or unmatched for all other received instructions. T2S shall assign an instruction the match status matched after a successful matching '' A new requirement should be added to chapter 5: T2S Provision of potential matching candidate(s) "T2S shall allow a T2S Actor to subscribe to a service that identifies possible matching candidates for unmatched settlement instructions. In case of a settlement instruction remains unmatched on or one business day before the intended settlement date, T2S shall provide a process to identify one or possibly more potential matching candidate(s) from the set of unmatched instructions. The algorithm to identify potential matching candidates will compare mandatory matching fields, but will suppress one mandatory matching field in the comparison according to the following order until a candidate is found. - Nominal or quantity - Cash amount - Currency - Intended settlement date - Trade date - ISIN - BIC of the counterpart delivering or receiving the securities - CSD of the counterpart - Buy/Sell For example, the algorithm will compare all mandatory matching fields for an unmatched settlement instruction with the exception of the nominal or quantity on its first attempt. Should the algorithm identify one or more possible matches, then the process stops for this settlement instruction and outputs the identified possible matches based on Page 2 of 45

3 mismatched quantity. Is the algorithm unable to identify possible matching candidates, then the algorithm will attempt to identify candidates by comparing all matching fields for the unmatched instruction with the exception of the cash settlement amount. Should the algorithm identify one or more possible matches, then the process stops for this settlement instruction and outputs the identified possible matches based on mismatched cash settlement amount. Is the algorithm unable to identify possible matching candidates, then the process continues with the currency and so forth." A new requirement should be added to chapter 13: T2S Report with potential matching candidate(s) T2S shall send T2S Actors that have subscribed to the potential matching candidate service a report with the potential matching candidate(s) that T2S has identified. * SG Meeting on 03 Nov 2008 Outcome: Rejected (complex tool with low additional benefits) Recommendation to the AG: Rejection * AG Meeting on 25 Nov 2008 AG sent the CR back to the SG for further analysis * SG meeting on 12 Jan 2009 Outcome: Change of priority: Low to Medium. Change of Classification: Consistency to Substance. New wording to be prepared for the next SG meeting by the Project Team. Agreed that proposed scope in T2S should cover: Procedure should run only for instructions remaining unmatched on the intended settlement date or one day before (in real time only if the instruction is received on the intended settlement date) The best fit algorithm should be limited to 1 mismatched field only. Matching fields should be prioritised; all possible mandatory matching fields should potentially be taken into account Best fit algorithm should return the best fit instruction to the T2S party of the unmatched instruction for information purposes only This procedure must not be seen as guarantee that the correct match has been found for an instruction, but rather that T2S provides functionality to support T2S parties with fails management. Recommendation to the AG: Approval (subject to wording agreement in Sub-Group meeting in March) * AG Meeting on 20 Jan 2009 AG required SG further evaluation Page 3 of 45

4 CR raised by: T2S Project Team Institute: ECB Date raised: 22/09/08 Change Request title: Consistency amendments in Annex 14 graphs CR ref. no: T2S URD 0027 (T2S-URD V4-CON-19) Change Request Classification: Consistency Annex 14 Priority (S,H,M,L): L Requestor Category: T2S project team To specify the terms in order to make the Annex consistent. To consistently use the terms in Annex 14 In Annex 14, Section 2, page 5, lines Modification of the second paragraph as follows: "Direct holding systems may maintain two types of securities accounts in a CSD. We call them generically: * Safekeeping accounts/end-investor accounts that are opened in the name of end-investors and to which the proprietary rights with legal effects are Under assessment, and * Clearing/commission accounts/ participants accounts that refer to securities accounts opened in the name of brokers/custodians for the purposes of settlement of trades in securities and in which securities belonging to one or several end-investors can be held" * SG Meeting on 03 Nov 2008 Outcome: Further clarification from the T2S PT is required. Modification of the description of the CR: - Addition of further information in the description of the request in order to make it clearer: "The terms used in the diagrams are not updated in the version 4 of the URD, and therefore they are not in line with the introduced terms in the text (generic and neutral terms)." Recommendation to the AG: Request further evaluation * AG Meeting on 25 Nov 2008 AG asked the SG for further analysis * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 4 of 45

5 CR raised by: T2S Project Team Institute: ECB Date raised: 24/10/08 Change Request title: Authorisation to initiate liquidity transfers on behalf of a T2S party CR ref. no: T2S URD 0043 Change Request Classification: Consistency Change Type: New Requirement Chapter 16 Priority (S,H,M,L): M Requestor Category: T2S project team T2S The requirement T2S (CSD or another party acting on behalf of a payment bank) describes that the CSDs may initiate liquidity adjustments on behalf of payment banks provided an authorisation by the payment bank. Therefore, there should be an entity to support this requirement. The chapter 16 on static data requirements does not define any entity to store information about a delegation given to a T2S actor (party) to act on behalf of another T2S actor (party) for the purpose of liquidity transfers. A new requirement should be added as a section (T2S Dedicated Cash Account Instructing Party) in order to create a new entity by the name of "On behalf of interested Party" T2S On behalf of interested party The On behalf of interested party entity shall store information about T2S actors allowed to initiate liquidity transfer from a T2S dedicated cash account belonging to another T2S Actor on its behalf under a power of attorney. Attributes and description: On Behalf of Interested Party Identifier: This attribute shall specify the unique party identifier of the T2S Party for which the power of attorney is valid. Instructing Party Identifier: This attribute shall be the unique party identifier of the T2S actor allowed to act on behalf of the T2S dedicated cash account owner. T2S Dedicated Cash Account Identifier: This attribute shall define the unique identifier of the T2S dedicated cash account. Valid From: This attribute shall specify the date from which the authorisation is valid. Valid To: This attribute shall specify the date to which the authorisation is valid. * SG Meeting on 03 Nov 2008 Outcome: Further clarification from the T2S PT is required Recommendation to the AG: No action * AG Meeting on 25 Nov 2008 AG sent the requirement back to the SG for further analysis * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 5 of 45

6 CR raised by: NBB Institute: NBB Date raised: 28/10/08 Change Request title: Securities Forecast CR ref. no: T2S URD 0114 Change Request Classification: Substance Change Type: New Requirement Chapter 14 Priority (S,H,M,L): H Requestor Category: CSD T2S The monitoring facility should also allow the banks and CSDs to view not only the cash forecast but also the "securites forecast" (i.e. a simulated securities position in which all short positions with matched and unmached instructions are considered settled). T2S should offer this functionality not only to the direct participants but also to the indirect particpants (through their CSD), which implies that instructions coming from other CSD's have to be taken into account. A possibility could be to run this programme after each optimisation cycle, or otherwise on demand by the T2S-participant (if not too expensive to run - ev. billable?) This functionality actually offered by NBB CSD (and we suppose by many others). It constitutes a big advantage for the banks. If T2S would not offer this functionality, this would imply that all direct participants and all CSDs would have to develop it themselves. An additional advantage is that this functionality reduces the number of fails. A new requirement should be added to chapter 14: T2S Securities Forecast Query "The securities forecast query shall allow a CSD or T2S Party to query for a combination of securities account and intended settlement date or for a combination of T2S Party and intended settlement date the expected securities position(s) for the end of a settlement day. The settlement date of the query must always be the current settlement date or current settlement date plus 1 business day. An additional query criterion will allow the CSD or T2S Party to output calculated short positions on T2S Party or securities account (Mandatory) only, depending on whether the query pertains to a T2S Party or securities account. The query calculation algorithm for the securities forecast shall assume that all unsettled instructions, both matched and unmatched, will settle on the intended settlement date. When a T2S Actor queries a securities forecast on party level, then the query provides all securities accounts that are linked with that party. In a securities forecast query on T2S Party level, T2S will group by ISIN and within ISIN by securities account so that the query provides totals on ISIN level. The query parameters that can be used are the following: Attribute whether the query pertains to a T2S Party or securities account T2S Party or securities account (Mandatory) depending on whether the query pertains to a T2S Party or securities account ISIN (Must be valid ISIN if entered) Intended settlement date (must be current settlement date or current settlement date plus 1 business day) Short positions only (Boolean value - Yes/No) on T2S Party or securities account (Mandatory) depending on whether the query pertains to a T2S Party or securities account The query will return the following information for the combination of securities account, ISIN and intended settlement date: CSD party identifier and mnemonic T2S party identifier and mnemonic Page 6 of 45

7 Securities account identifier Intended settlement date One or multiple ISINs with the following information I. Current securities position - [A] II. Total unsettled instructions (either matched or unmatched) [B] III. Calculated securities positions expected at end of intended settlement date [A] + [B]" * SG Meeting on 12 Jan 2009 Outcome: Agreed that proposed scope in T2S should cover: The security forecast should be only request driven (query) Securities forecast should be per ISIN or range of ISIN, possible for a specific T2S party account of a CSD The possibility to make the Securities forecast available for a specific category of assets (e.g. fixed income) should be investigated The scope of the securities forecast is valuable, but limited from the original proposed scope because of potential performance impact. It must be noted that securities movements from corporate actions cannot be included in the T2S query. Recommendation to the AG: Approval (subject to wording agreement in Sub-Group meeting in March) * SG Meeting on 12 Jan 2009 Outcome: New wording to be prepared for the next SG meeting by the Project Team. Agreed that proposed scope in T2S should cover: The security forecast should be only request driven (query) Securities forecast should be per ISIN or range of ISIN, possible for a specific T2S party account of a CSD The possibility to make the Securities forecast available for a specific category of assets (e.g. fixed income) should be investigated The scope of the securities forecast is valuable, but limited from the original proposed scope because of potential performance impact. It must be noted that securities movements from corporate actions cannot be included in the T2S query. Recommendation to the AG: Approval (subject to wording agreement in Sub-Group meeting in March) * AG Meeting on 20 Jan 2009 AG required SG further evaluation Page 7 of 45

8 CR raised by: Clearstream Institute: Clearstream Date raised: 18/11/08 Change Request title: Guaranteed recycling of the CoSD blocking of cash after end of day CR ref. no: T2S URD 0117 Change Request Classification: Substance Change Type: New Requirement Annex 8 Chapter 8 Priority (S,H,M,L): H Requestor Category: CSD There is a need for the sweep of blocked cash (after the end of day) for CoSD receipts to maintain this cash separate from the underlying customer's cash position. The recycling of CoSD blocking of cash must always succeed. The reason why the cash blocking must be maintained after an end of day cash sweep is: -it cannot be poached for any other purpose, -the recycling of the CoSD blocking of cash will always succeed: this cash is effectively swept back in. -we effectively resume the lifecycle of the affected CoSD receipts where this was left off: pending confirmation from the external settlement location -we prevent there ever being an external settlement of a receipt, where the instructing customer no longer has the cash required for their receipt. Unless this is done, there is a possibility CSD will be of short cash because of CoSD receipts. This is unworkable, it implies that the CSD takes a credit risk on their customer. It is not necessary to design this process with this risk built in. A new requirement should be added to chapter 9: T2S CoSD Cash Blocking: "T2S shall maintain a CoSD cash blocking during the end of day cash sweep. -T2S shall sweep cash blocked for CoSD, with the information that this cash is to be blocked in T2, to the T2 account linked to the T2S dedicated cash account. -T2 shall maintain the CoSD cash blocking and sweep the cash back to the T2S dedicated cash account it originated from at the start of day where the CoSD cash blocking will be regenerated on the T2S dedicated cash acount of the T2S party. Change requests will have to be issued for T2." * SG Meeting on 12 Jan 2009 Outcome: ECB Project Team to provide concrete example and alternatives with advantages and disadvantages of each alternative Recommendation to the AG: Request further evaluation * AG Meeting on 20 Jan 2009 AG required SG further evaluation Page 8 of 45

9 CR raised by: T2S Project Team Institute: ECB Date raised: 18/11/08 Change Request title: Delivery-versus-Delivery is not an instruction type but two linked FOP instructions CR ref. no: T2S URD 0118 Change Request Classification: Clarification Chapter 5, Chapter 7, Chapter 9, Chapter 13, Annex 2 Priority (S,H,M,L): M Chapter 5 on LCMM should be changed to make it clear that a delivery versus delivery (DVD) is not an instruction type but a delivery free of payment (DFOP) instruction linked to a receive free of payment (RFOP) instruction In the absence of a strong business case, the ISO2022 does not foresee the creation of a new instruction type for a delivery versus delivery (DVD) instruction. From a legal point of view, it is not relevant whether a given transaction type (FOP, DVP or DVD) is exercised via a specific instruction type or via the linking of other instruction types, as long as the desired effect (and its operational certainty/safety) is assured. In essence, a DVD (delivery versus delivery) transaction is the exchange of two securities positions (for whatever purpose, e.g. exchange offers, corporate actions, substitutions of collateral hence not necessarily a transfer of ownership), whereby the execution of either delivery has to be dependent on the other (corresponding) delivery. Hence, the understanding of a DVD as two linked FOP transactions, being dependent (contingent) on each other, is absolutely correct. The binding effect on the two mutual instructions is created when the instructions are entered into the respective system(s) (in accordance with the (future) harmonised rules of participating CSDs). The instruction type used within the system(s) (DVD or 2 linked FOPs) is irrelevant in this regard. Removal of the following bullet point in section Instruction types (page 9, lines 5 and 6) because DVD is not an instruction type: " DVD (delivery versus delivery) defines an exchange of securities between the parties concerned. For example, collateral substitution uses a DVD instruction." - Modification of the requirement T2S (Minimum settlement unit check) because DVD is not an instruction type: "T2S shall check the settlement unit against the minimum settlement unit or nominal. T2S shall validate all ISINs where an instruction contains more than one ISIN (e.g. in the case of DVD instructions)." - Modification of the requirement T2S (Multiple or deviating settlement unit check) because DVD is not an instruction type: "T2S shall check against the multiple or deviating settlement unit or nominal. T2S shall not perform this check on some instructions related to corporate events. T2S shall validate all ISINs where an instruction contains more than one ISIN (e.g. in the case of DVD instructions)." - Modification of the requirement T2S (Mandatory matching fields) and T2S (Additional matching fields) because DVD is not an instruction type: T2S : "Mandatory matching fields are those instruction fields that T2S matches in instructions. The instruction type (DVP, DWP, or FOP or DVD) shall determine the mandatory matching fields. The current list of mandatory matching fields is documented in the table below." T2S and T2S : Removal of the column DVD that includes matching fields Addition of a footnote in FOP column: "In line with current market practices, in T2S DVD instructions will consist of Page 9 of 45

10 two linked FOP instructions (link between a RFOP and a DFOP)". - Modification of the tables (Examples of life cycle types) and (Examples of transaction types) of chapter 5 in order to remove any mention to DVD instructions - Modification of the table Message glossary (Chapter 13, page 35, 6 bullet point) "Should cover all type of instructions being part of T2S scope, including DVD, Delivery with Payment, single instruction with both buying and selling legs, bulk orders/block-trade instructions, DVP and RVP with securities quantity equal to zero, and others as defined in chapter 5." - Modification of the sentence in line 18, page 14 of section Corporate events settlements (non-trading related settlements) as follows: "This is covered by the delivery versus delivery transaction (DVD) consisting of two FOP instructions (DVD), already a generic T2S requirement." - Modification of the sentence in line 3, page 17 of chapter 7 (requirement T2S ) as follows: "The provision-checking shall cover all the settlement legs of the relevant transaction (i.e. e.g. the cash and securities legs for a DVP transaction, both securities legs for a DVD transaction, etc )." - Removal of the rows of DVD and RVD and Table of chapter 11 - Attribute Domain of Settlement Instruction types (page 16) - Modification of the definition Delivery-versus-Delivery (DVD) in the glossary (annex 2. Page 6) as follows: "a type of instruction and settlement mechanism, specifying a link between two securities transfers, to ensure that a delivery occurs if, and only if, another delivery occurs and vice versa." * SG meeting on 12 Jan 2009 Outcome: (1) Check with the ISO registration body through the Messages standardisation Sub-Group what the impact would be if DVD would be included as instruction type, i.e. if more than 1 ISIN would be foreseen in an instruction. (2) Check if there is a legal difference between 1 DVD instruction and 2 linked FOP instructions (one more secure than the other) Recommendation to the AG: Request further evaluation * AG Meeting on 20 Jan 2009 AG required SG further evaluation * Message Standardisation SG meeting on 12 February The SG confirmed that there is no need for a DVD as an instruction type. With reference to the reporting of DVDs, it was concluded that since DVDs may not be separately identified from other instructions, they may not be the subject of a specific reporting either. Moreover, the need for such a reporting is not established Page 10 of 45

11 CR raised by: T2S Project Team Institute: ECB Date raised: 20/11/08 Change Request title: The dual user approval should be available for static and dynamic data management. CR ref. no: T2S URD 124 Change Request Classification: Consistency Chapter 16 Priority (S,H,M,L): M The dual user approval requirement defined in chapter for static data change management should also include dynamic data management. T2S must apply the principle of dual authorisation to T2S static and dynamic data objects, maintainable by a T2S system user directly through the GUI. Requirement to change the text "static data" for "Static and dynamic data". In the following pages and lines in section Static Data Change Management: Page 14; line 21 Page 15; line 1, line 18, line 26 (twice) and line 27 Page 16; line 3 (twice), line 4, line 5, line 7, line 9 (twice), line 13, line 14, line 17, line 18, line 20, line 25, line 26 and line 28 Page 17; line 2, line 3, line 12 and line 14 - And also, a requirement to add new text on UR T2S , as follows: "Static and dynamic data change management specifies the business requirements for processing and approving updates to static and dynamic data made by one T2S system user by another T2S system user within the same organisation, i.e. T2S party, often referred to as dual authorisation. T2S shall provide a flexible configurable change management component for static data so that T2S actors can parameterise their change approval processes (dual authorisation) for the various static and dynamic data entities according to their legal, regulatory, audit and operational requirements. Dual authorisation on dynamic data will apply to those business objects that an authorised T2S System User can change manually such as: - Input settlement instruction - Input maintenance instructions of a settlement instruction - Input a liquidity transfer order" * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 11 of 45

12 CR raised by: T2S Project Team Institute: ECB Date raised: 25/11/08 Change Request title: Validation of the Market-specific restriction types CR ref. no: T2S URD 131 Change Request Classification: Consistency Change Type: New Requirement Chapter 5 Priority (S,H,M,L): M T2S Requirement T2S includes the market-specific restriction types that may be applicable to securities account, security, T2S dedicated cash account, securities position, cash amount and T2S party. Chapter 5 on LCMM should include a validation in order to check if there is any restriction that may be applicable to a settlement instruction Chapter 5 on LCMM should include a validation in order to check if there is any restriction that may be applicable to a settlement instruction New requirement T2S Market-specific restriction check T2S shall check the market-specific restriction that may be applicable to the securities account, security, T2S dedicated cash account, securities position, cash amount and T2S party of the instruction. T2S shall validate the applicable restrictions are in line with the information contained in the instruction The market-specific restrictions are described in the requirement T2S and T2S * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 12 of 45

13 CR raised by: T2S Project Team Institute: ECB Date raised: 25/11/08 Change Request title: Allegement Cancellation and Allegment removal CR ref. no: T2S URD 132 Change Request Classification: Consistency Change Type: Clarification Chapter 5 Priority (S,H,M,L): M T2S Chapter 5 on LCMM must clarify that the "removal of allegement" refers to both allegement removal and allegement cancellation. The removal of allegement is sent when the previous allegement is no longer valid and can take one of the following two forms: - Allegement Cancellation that requests the cancellation of a previously sent allegement message, because of a mistake by the sender or because the alleging party cancelled its instruction. - Allegement Removal that acknowledges that a previously sent allegement message is no longer valid, because the alleged party has e sent its instruction in the meantim. Inconsistency between Chapter 5 and Chapter 13 (Table 13-3 Message Glossary), which distinguishes Allegement Removal and Allegement Cancellation in line with ISO standards; bringing Chapter 5 in line with Chapter 13 increases the clarity and consistency of the URD The requirment T2S (Allegement facilities for matching ) should be changed as follows: "T2S shall send an allegement message for any unmatched instruction after the first unsuccessful matching attempt where this was because of a missing counterpart instruction. However, T2S shall send the allegement only after having waited for the missing counterpart instruction for a predetermined period of time in accordance with the subscription service defined in Section T2S shall also send an allegement cancellation and a new allegement message where a matching field of an unmatched instruction is amended and an allegement has already been sent. T2S shall send an allegement removal or allegement cancellation removal of allegement message when the previous allegement message is no longer valid (e.g. the settlement instruction has been matched with the counterpart): An allegement cancellation requests the cancellation of a previously sent allegement message, either due to a mistake or a cancellation of the settlement instruction by the sender. An allegement removal acknowledges that a previously sent allegement message is no longer valid, because the alleged party has in the meantime sent its instruction." * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 13 of 45

14 CR raised by: T2S Project Team Institute: ECB Date raised: 27/11/08 Change Request title: Consistency change to include non-euro NCBs cash monitoring procedure CR ref. no: T2S URD 134 Change Request Classification: Consistency Change Type: Clarification Chapter 6.3 Priority (S,H,M,L): M The UR indicates that the monitoring need for non-euro NCBs will be investigated, this comment should be deleted and explicitly stated that the monitoring tools will be the same in T2S for all NCBs irrelevant of the currency. The chpater 6 has to clarify that the monitoring tools needed for NCBs are the same in T2S for all NCBs irrelespective of the currency. The section NCBs' global cash monitoring must be modified as follows: - The introductory paragraph of section NCBs' global cash monitoring should be modified as follows (page 24): "This chapter contains user requirements to especially support the needs with respect to the monitoring euro of liquidity for NCBs (Euro and non-euro currency. How the monitoring needs of non-euro NCBs for non-euro currencies can be supported will have to be investigated further in the next phase of the T2S project." * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 14 of 45

15 CR raised by: T2S Project Team Institute: ECB Date raised: 27/11/08 Change Request title: NCB cash monitoring procedure CR ref. no: T2S URD 135 Change Request Classification: Consistency Change Type: Clarification Chapter 6 Priority (S,H,M,L): M Chapter 6 should have to be consistent with the T2S capability of settling currencies other than the euro. Modification should be made to allow non-euro NCBs to have the necessary tools to monitor the cash accounts of their participants in the RTGS system. Chapter 6 should have to be consistent with the T2S capability of settling currencies other than the euro. Replacement of TARGET2 with RTGS systems in section Framework for the user requirements related to liquidity monitoring: "The specific needs of NCBs with regard to monitoring have to be in line with the framework in the list below: An NCB will have access to information about on the liquidity available on the cash accounts held by direct TARGET2 RTGS system's participants if the participants have opened the accounts with the relevant NCB. The access has to be possible for all cash accounts related to TARGET2 the RTGS system business as well as for dedicated T2S cash accounts. To meet the need for liquidity monitoring an overall view is needed. This means that information provided on liquidity must be based on information stemming from both T2S and TARGET2 RTGS systems. Features available for liquidity monitoring purposes in TARGET2 and other RTGS systems should be enlarged and reused according to the additional needs stemming from T2S. Where necessary, additional monitoring features should be developed." * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 15 of 45

16 CR raised by: T2S Project Team Institute: ECB Date raised: 27/11/08 Change Request title: Consistency change to include non-euro NCBs in the context of global cash monitoring CR ref. no: T2S URD 136 Change Request Classification: Consistency Change Type: Clarification Chapter 6 Priority (S,H,M,L): M Section 6.3 on the NCBs global cash monitoring should not contain references to any specific RTGS systems and the requirements should formulate exclusively what functionality T2S will provide to NCBs so that NCBs have the necessary information to perform global cash monitoring. Section 6.3 must reflect that T2S will provide standardised functionality for global cash monitoring. The Section NCBs' global cash monitoring should be modified as follows: This chapter contains user requirements to especially support needs with respect to monitoring euro liquidity. How the monitoring needs of non-euro NCBs for non-euro currencies can be supported will have to be investigated further in the next phase of the T2S project Role of NCBs with respect to liquidity monitoring 1 The specific role of NCBs in T2S is their function as provider of liquidity for securities settlement to be used for settling securities transaction (provision of central bank money). This section defines the specific functions that T2S shall provide to support global liquidity monitoring by NCBs. in order to make information available to monitoring and control tools used by NCBs for liquidity monitoring purposes Framework for the user requirements related to liquidity monitoring The specific needs of NCBs with regard to monitoring have to be in line with the framework in the list below: º An NCB will have access to information about the liquidity available on the cash accounts held by direct TARGET2 participants if the participants have opened the accounts with the relevant NCB. The access has to be possible for all cash accounts related to TARGET2 business as well as for dedicated T2S cash accounts. º To meet the need for liquidity monitoring an overall view is needed. This means that information provided on liquidity must be based on information stemming from both T2S and TARGET2. º Features available for liquidity monitoring purposes in TARGET2 should be enlarged and reused according to the additional needs stemming from T2S. Where necessary, additional monitoring features should be developed Features for liquidity monitoring With a view to the need of NCBs to perform liquidity monitoring at an overall level (see section 6.3.2), two monitoring screens in the ICM of TARGET2 were identified that need to be enlarged: º Liquidity on CB Level; º Reservations and Dedicated Liquidity. In addition, there is a need to have an overview of the limits defined by an NCB with regards to the use of autocollateralisation in T2S, and their utilisation. Footnote 6 As well as information related to monitoring and individual information about the cash side of the credit institutions, the NCBs will have full access to information on instructions they sent to T2S as T2S participants. For Page 16 of 45

17 example, they will have knowledge of instructions sent by them to T2S in order to sellback (return or unwind) repo transactions performed for intraday credit and monetary policy operations. The requirement T2S (Total amount of liquidity available in T2S) should be modified as follows: In response to a query, T2S shall provide make available to the monitoring and control tool of the an NCBs the total amount of liquidity available on the T2S dedicated cash accounts owned by payment banks and T2S parties within the in its sphere of responsibility. of the respective NCB. The requirement T2S (Total amount of predefined and standing liquidity transfer orders) should be modified as follows: In response to a query, T2S shall provide make available to the monitoring and control tool of the an NCBs the overall amount of predefined liquidity transfer orders, and the overall amount of standing liquidity transfer orders defined by payment banks within the in its sphere of responsibility. of the respective NCB. The requirement T2S (Monitoring of limits to restrict the use of auto-collateralisation) should be modified as follows: In response to a query T2S shall provide make available to the monitoring and control tools of the NCBs information about the limits they have defined for payment banks in order to restrict them in making use of autocollateralisation in T2S. T2S shall offer auto-collateralisation to facilitate settlement. In T2S, auto-collateralisation will be offered in order to facilitate the settlement process. In order to limit the amount of liquidity that some specific participants in T2S can create through the use of auto-collateralisation, NCBs will have the possibility to define a limit per participant. This limit will be the maximum amount of liquidity that can be created in T2S through the use of auto-collateralisation for the respective participant. * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 17 of 45

18 CR raised by: T2S Project Team Institute: ECB Date raised: 27/11/08 Change Request title: NCBs and settlement banks should also be able to query the limits that they have established to their participants CR ref. no: T2S URD 139 Change Request Classification: Substance Change Type: Clarification Chapter 14 Priority (S,H,M,L): M T2S NCBs and settlement banks should also be able to query the limits that they have established to their participants. Add NCBs as a T2S party that shall be able to query limits. NCBs and settlement banks should be able to query the limits that they have established to their participants Requirement T2S should be changed as follows: "NCBs and payment banks shall be able to query limits that they have defined in T2S for parties to which they provide credit in central bank money. The query shall support the following selection parameters: Limit type (net buying limit, auto-collateralisation limit), Credit consumer (party identifier), Limit currency, Limit amount with comparison operator (e.g. greater than 10,000,000), Validity date, Technical status (active, deleted), Limit identifier. The query shall return the following information: NCB Credit provider (party name and party identifier) Credit consumer (party name and party identifier) T2S dedicated cash account Limit type (net buying limit, auto-collateralisation limit), Limit currency, Limit amount, Valid from date, Technical status (active, deleted), Limit identifier. Securities accounts linked to limit." * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 18 of 45

19 CR raised by: T2S Project Team Institute: ECB Date raised: 27/11/08 Change Request title: NCBs should also be able to query limit utilisation CR ref. no: T2S URD 140 Change Request Classification: Substance Change Type: Clarification Chapter 14 Priority (S,H,M,L): M T2S NCBs should also be able to query limit utilisation on the limits that they have established to their participants. Add NCBs as a T2S party that shall be able to query limits utilisation. NCBs should be able to query limit utilisation on the limits that they have established to their participants Requirement T2S should be changed as follows: "NCBs and payment banks shall be able to query the current utilisation of limits they have defined in T2S for parties to which they provide credit in central bank money. The query shall support the following selection parameters: Limit type (net buying limit, auto-collateralisation limit), Credit consumer (party identifier), Limit currency, Percentage utilisation with comparison operator (e.g. utilisation greater 90%), Limit identifier. The query shall return the following information: NCB Credit provider (party name and party identifier) Credit consumer (party name and party identifier) T2S dedicated cash account Limit type (net buying limit, auto-collateralisation limit), Limit currency Limit utilisation Remaining limit." * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 19 of 45

20 CR raised by: T2S Project Team Institute: ECB Date raised: 27/11/08 Change Request title: NCBs should also be able to query the limit utilisation journal CR ref. no: T2S URD 141 Change Request Classification: Substance Change Type: New Requirement Chapter 14 Priority (S,H,M,L): M T2S NCBs should also be able to query the limit utilisation journal on the limits that they have established to their participants.. T2S party shall be able to query limits utilisation journal. NCBs should also be able to query the limit utilisation journal on the limits that they have established to their participants. New requirement T2S Limit utilisation journal query: NCBs and settlement/payment banks shall be able to query the T2S limit utilisation journal. An NCB shall be able to query the limit utilisation journal for settlement/payment banks for which the NCB has defined limits in T2S. Settlement/payment banks shall be able to query the limit utilisation journal for T2S parties for which the settlement/payment bank has defined limits in T2S. The query shall support the following mandatory parameters: * Credit consumer (party identifier) * Date The query shall support the following optional parameters: * T2S dedicated cash account * Limit type (net buying limit, auto-collateralisation limit) The query shall output the following data: * Credit consumer (party identifier) * Date * T2S dedicated cash account * Limit type (net buying limit, auto-collateralisation limit) * Debit/Credit * Limit currency * Limit Amount * Limit utilisation after * Remaining limit after * Transaction reference and type of transaction (there may be more than one transactions for one limit change) * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 20 of 45

21 CR raised by: T2S Project Team Institute: ECB Date raised: 28/11/08 Change Request title: Cancellation of instructions affected by a static data update CR ref. no: T2S URD 143 Change Request Classification: Consistency Chapter 13 Priority (S,H,M,L): L T2S T2S will cancel the instructions that do not pass the revalidation after a static data change. In this respect, the requirement T2S (Checking pending instructions because of static data maintenance) must be amended to make it consistent with the requirement T2S (Revalidation after changes in data). The requirement T2S was modified by the CR T2S URD There is a inconsistency between requirements T2S and T2S Modification of the requirement T2S Checking pending instructions because of static data maintenance: "When static data maintenance occurs while there are still pending instructions, T2S shall check which settlement instruction T2S must revalidate as a result of the static data chenge whether the maintenance has an impact on the pending instructions. If the result of the validation is negative yes, T2S will not automatically update the pending instructions, but shall send a negative status message to the CSD or the directly connected T2S party to inform about the cancelation of need to cancel and replace the pending instructions or to amend them to be consistent with the updated static data. The timing is defined in chapter 5, life cycle management. The only case where T2S will automatically reflect (at the level the interface and the messages/reports/queries) the Static Data change on the pending instructions is in the event of an ISIN change for one same security." * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 21 of 45

22 CR raised by: T2S Project Team Institute: ECB Date raised: 03/12/08 Change Request title: Population of static data relating to close links CR ref. no: T2S URD 144 Change Request Classification: Consistency Chapter 8 Priority (S,H,M,L): M T2S Inconsistency for the treatment of static data for close links in Chapters 6, 16 and 8 (T2S , T2S , chapter ) There is a inconsistency for the treatment of static data for close links. Modification of the requirement T2S (Restrictions related to the existence of close links) as follows: "Each settlement bank that has access to credit operations with its central bank shall identify the database used by T2S for collateral management purposes relating to auto-collateralisation, any securities (ISINs) for which the relevant settlement bank has identified a close link. with their national central bank any securities (ISINs) for which the relevant settlement bank has identified a close link. This information is transmitted by the national central bank to the database used by T2S for collateral management purposes relating to auto-collateralisation. When a settlement bank has opted for the aforementioned options (i) or (ii), T2S shall not use the securities for which a close link has been identified for auto collateralisation.(...)" * SG meeting on 12 Jan 2009 Postponed to the next URM sub-group meeting due to the lack of time. Page 22 of 45

23 CR raised by: T2S Project Team Institute: ECB Date raised: 16/12/08 Change Request title: Bulk messages for block-trades CR ref. no: T2S URD 146 Change Request Classification: Substance Chapter 5, Chapter 12, Annex 12, Annex 14 Priority (S,H,M,L): M Remove reference to bulk messages from the URD, namely chapters 5 and 12, as well as annexes 12 and 14. (as well as from the management summary) Bulk messages will not be supported, they are simply not needed neither for functional nor for technical reason. Removal of requirement T2S (Block-trade instruction) in chapter 5: - The requirement T2S (File processing rule) of chapter 12 (Interfaces) should be modified as follows: "If there are file transfer or structure problems, T2S shall ensure that files are rejected entirely. This does not apply if there are validation problems at the level of individual instructions in the file. In this case, the file is completely processed and rejection messages are sent for the individual invalid instructions. Bulk message requirements for block-trades A bulk message is a message containing a set of instructions (usually called block-trade instructions); it might be that instructions should settle independently or that all instructions are interlinked. In the context of T2S, bulk messages can be used to send several instructions to T2S in one shot, without making use of file transfer. Bulk messages as described above are within the ISO standard. Regarding the processing of bulk messages, the following should be highlighted:" - Removal of requirement T2S (Bulk message processing) rule in chapter 12 "If there are transfer or structure technical problems, or validation problems at the level of individual instructions in the bulk message, T2S shall ensure that the bulk message is rejected entirely." - Deletion of the following paragraph of annex 12 (Corporate events) in page 22: "To better support direct holding systems that will face higher volumes than nominee systems, there should be the possibility to use a bulk message (also called block instruction) to instruct settlement of CE impacting a large number of accounts. The concept of bulk message/ block instruction in ISO will consists in several transactions (all debit or all credit intended movements) in the same message for different securities accounts and different quantities. For more details, reader is invited to refer to Annex 14, Settlement of Direct Holdings in T2S." - Deletion of the footnote 2 of annex 12 (Corporate events) in page Deletion of the following paragraph in page 20 of annex 14 (Settlement of direct holdings in T2S): "To better support direct holding systems that will face high volumes due to above requirement related to allocations, there should be the possibility to use a bulk message. The concept of bulk message is already in place in ISO 20022, for other business areas, and consists in several transactions (all debit or all credit intended movements) in the same message for different securities accounts and different quantities. Once trade and allocation transactions are settled, T2S will inform the instructing party (each broker if directly connected or their CSD) as described by the Interfaces URD (same messages, statements and reports as available for indirect holding countries)." - Deletion of the footnote 2 of annex 14 (Settlement of direct holdings in T2S) in page 20 Page 23 of 45

24 * SG meeting on 12 Jan 2009 Outcome: Approved in principle, subject to a viable solution found for the Finnish market Recommendation to the AG: Request further evaluation * AG Meeting on 20 Jan 2009 AG required SG further evaluation Page 24 of 45

25 CR raised by: T2S Project Team Institute: ECB Date raised: 08/01/09 Change Request title: Settlement instruction query CR ref. no: T2S URD 150 Change Request Classification: Substance Chapter 14 Priority (S,H,M,L): L Requestor Category: T2S Project team Paragraph , UR T2S and T2S Cancel section 14.3 Instruction Queries and replace with the change request. The redundancies and inconsistencies throughout the section 14.3 should be eliminated. Attachment to change request T2S URD 150.doc See the proposed wording in the document entitled 'Attachment to change request T2S URD 150.doc' Page 25 of 45