T2S AG INPUT ON THE ESMA DISCUSSION PAPER. (CSDR, Art. 6 & 7) Contents

Transcription

1 T2S AG INPUT ON THE ESMA DISCUSSION PAPER (CSDR, Art. 6 & 7) 22 May /2014/ Contents 1. General Comments RTS related to Settlement Discipline Measures to prevent settlement fails (Article 6(4)) Incentives for early input of settlement instructions System functionalities Lending facilities Details of the system monitoring settlement fails (Art7/14.a) Details of operation of the appropriate buy-in mechanism: extension period (Article 7(14) (d) Penalties for settlement fails (Article 7(13)) Timing of implementation of the SDR TSs Summary of the feedback on implementation of SDR measures Details of implementation of settlement discipline regime measures Page 1 of 39

2 1. General Comments The T2S Advisory Group (AG), as the main forum for the post-trade harmonisation work undertaken by the T2S Community, welcomes the EU public authorities legislative act on CSDs (the CSDR). The AG would like to express its strong support to the harmonisation agenda embedded in the CSDR provisions and in particular to the creation of a common set of (securities settlement services) rules as is the objective of the level II regulatory and implementing technical standards (RTS and ITS). This is in line with the T2S harmonisation agenda supporting the creation of a single rule book for post trade processes in the T2S markets. It is also in line with the AG chairman s letter to the European Commission (13 July 2011) 1 and the ECB opinion on the CSDR (1 August 2012). 2 In addition, in its annual publication on post trade harmonisation (Fourth T2S harmonisation Progress Report, published on 19/03/2014) the T2S community has expressed its strong interest for the timely adoption and implementation of the CSDR provisions which have a strong impact on a number of prioritised T2S harmonisation activities. 3 The T2S AG takes note of the ESMA s discussion paper reference to the T2S harmonisation agenda (page 8) where it is stated that [. Relevant developments are on-going, notably T2S, that will bring operational harmonisation. Where appropriate, T2S elements have (e.g. record-keeping requirements) or will be considered.] Due to short period lack of time, the AG has only reviewed the first 20 Questions in the Discussion Paper, which are related to settlement discipline regime measures. In particular, it decided to provide its substantive feedback only to questions The AG considers that questions 14-20, which are related to the details of operation of the appropriate buy-in mechanism, are out of the scope of T2S. The AG has also provided some feedback on Penalties for settlement fails (Article 7(13)), for which no specific question was posed by ESMA ag chairman finalletter to dgmarket.pdf??d67ebb2942b9f9c a041 2 See page 2, ECB Opinion on CSDR, 1 August 2012, 3 See Executive Summary, Fourth T2S Harmonisation Progress Report, 19/03/2014, edd9087cdc73d400a Page 2 of 39

3 Given the current status of the CSDR adoption process, it is evident that the RTS will only be adopted after the launch of T2S. The exact timing of the RTS implementation depends on the final and official Commission publication. However, it is up to the discretion of the EU public authorities to possibly reconsider the exact timing of the RTS implementation, provided that enough factual evidence for such a need is presented by the relevant stakeholders. In this spirit, the AG also decided to provide to ESMA its input on some factual evidence with regards to the timing of implementation of the regulatory technical standards (RTS) on the settlement discipline regime based on the practical experience of its users past similar projects. In addition, the AG decided to provide a technical annex that should inform ESMA on some T2S reporting functionalities available to CSDs. These operational processes may be of interest to ESMA in defining the RTS. Finally, the AG would like to clarify that this feedback reflects the views of the T2S community and as a consequence are focusing on the T2S markets and the T2S CSDs. Page 3 of 39

4 2. RTS related to Settlement Discipline The AG input to the ESMA discussion paper is provided after each ESMA question. The text in italic above the question serves to clarify the relevant question of ESMA and is largely taken from ESMA s Discussion paper. 2.1 Measures to prevent settlement fails (Article 6(4)) 9. Under Article 6(4) CSDR, ESMA is expected to develop RTS to specify details of the confirmation and allocation measures and of the procedures between investment firms and their professional clients facilitating settlement and the details of the tools for the management of the timely settlement of transactions. The sections below regard the latter elements. Confirmation and allocation measures were added later in the CSDR negotiations and have not yet been discussed in depth by ESMA; any input is welcome on the possible elements to draft these technical standards. Q1: Which elements would you propose ESMA to take into account / to form the technical standards on confirmation and allocation between investment firms and their professional clients? 10. The main objectives of ESMA when drafting this standard will be that it contributes to (i) the early settlement of transactions on the intended settlement date; and to (ii) the reduction of the number instructions that fail to settle on the intended settlement date. This is aimed to be achieved whilst not inflicting unnecessary costs on the CSDs and their participants. T2S AG feedback on Q1: The AG considers this question out of scope of T2S. Rationale Early confirmation and allocation is a sound and desirable principle contributing to the prevention of settlement fails as well as pre-condition for timely settlement at CSD level. This is due to the fact that the earlier the terms of the trade are agreed between buyer and seller, the sooner the settlement instructions can be sent for matching and settlement to market infrastructures. However, the issue is not directly connected to T2S since this concerns the relationship and interaction between investment firms and their clients. Alternatives Quantitative evidence Page 4 of 39

5 a. Automation i. No manual intervention 11. For the CSD processing of settlement instructions, CSDs should make no use, or very limited use, of manual intervention. Automation may facilitate timely settlement by contributing to an efficient settlement process with lower operational risk. The submission and processing of ordinary settlement instructions, hold and release instructions and other instructions related to the settlement, should therefore be automated. CSDs should not offer services which require manual intervention by default. ESMA is currently of the view that manual intervention should only be allowed in exceptional circumstances that, if any, should be clearly specified in the technical standard. Q2: In your opinion, are there any exceptions that should be allowed to the rule that no manual intervention occurs in the processing of settlement instructions? If so please highlight them together with an indication of the cost involved if these exceptions are not considered. T2S AG feedback on Q2: The receipt and processing of ordinary settlement instructions, 4 hold and release instructions and other settlement related instructions is automated at T2S level. In particular, the T2S Operator does not need to perform any manual tasks to facilitate/trigger the settlement of any instruction on the T2S platform, which are validated, matched and settled automatically according to the general procedures of T2S as well as based on the concrete static data and restrictions provided by CSDs in T2S static data. Furthermore, U2A (user-to-application) mode of communication between CSDs/DCPs 5 and T2S is well described in the T2S User Requirements Document (URD) 6 and the T2S User Detailed Functional Specifications (UDFS) 7 as a legitimate way of communication and should not be considered a type of manual intervention. In particular, certain static data updates can be made only in U2A mode, both at the level of the T2S platform as well as those of the CSDs. These static data updates as infrequent or even one-off events which serve to facilitate settlement. 4 As per the T2S Glossary: Settlement Instruction: An order, originating from both trading and non-trading operations, to deliver or receive securities (or rights in securities) with or without paying an amount of money to an ultimate beneficiary on behalf of an originator. In the event of a sale, the buyer of the securities will need to provide the "receive instruction" while the seller will need to provide the "delivery instruction". Settlement Transaction: A matched pair of settlement instructions. 5 Directly Connected Parties (DCPs): means a T2S User, which has been authorised by its Contracting CSD or Central Bank to access T2S directly to use T2S Services, i.e. without the need for the Contracting CSD to act as a technical interface. (Framework Agreement) 6 Link to T2S URD v.5.03: 7 Link to UDFS v.2.0: Page 5 of 39

6 However, The T2S Community considers that manual intervention should be allowed in the CSD rules of procedures. Rationale and Alternatives In particular cases (such as incident and crisis management) manual intervention by the T2S Operator may be needed. However, such intervention will be done following strict rules and procedures, described explicitly in the Manual of Operation Procedures (MOP), which has been agreed between T2S and participating CSDs, NCBs and DCPs. Another case of manual intervention by the CSDs are also those of a limited amount of activity, involving interaction with other settlement platforms or provision of additional data relevant for settlement in nonstandard format. For example, in the case of settlement between an External CSD (i.e. a CSD not on T2S) and a T2S CSD, it should be allowed for manual intervention by the CSDs in the settlement process. This is because due to the different settlement and/or payment platforms being involved, there may be a need for CSDs in T2S to transfer securities on the T2S platform only after confirmation is received from the External CSD for movement of the securities and/or cash subject to a transaction between participants in both CSDs. (See explanation of CoSD and CSD Validation Hold below). Information on T2S functionalities available to CSDs The U2A mode of communication (via GUI) between T2S and CSDs/DCPs is well described in the UDFS as a possible way of communication. The business cases in which U2A mode is previewed include: - Static data updates. Some static data updates are not possible in A2A mode in T2S. Some examples are the rule set-up of the CoSD 8 functionality, auto-collateralisation set-up, message subscription set-up to receive the relevant messages, etc. - Limited number of settlement instructions being processed in T2S. Some CSDs/DCPs with very limited number of settlement instructions may at least initially join T2S only in U2A mode. Exceptions should be allowed for this based on a decision of the governing bodies of the T2S Project. CoSD and CSD validation hold in T2S and at CSDs 9 CoSD (conditional securities delivery) is by nature a type of functionality which does not allow for straight through processing, because it is specifically used for the case of waiting for an external event to happen, e.g. settlement in a currency that is not in T2S. For risk management purposes, it is deemed necessary that the CSD awaits confirmation from the external event before settlement continues in T2S. 8 Conditional Securities Delivery (CoSD) is a procedure in which the final securities and/or cash booking is dependent on the successful completion of an additional action or event (e.g. registration of shares, cash settlement outside T2S). (T2S URD) 9 Please refer to T2S URD T2S Automatic hold of instruction for additional validation or processing by the CSD and T2S URD chapter Conditional securities delivery parameters Page 6 of 39

7 In addition, it could be possible for the CSD to automate the use of the CoSD (without manual intervention), i.e. if their IT system receives confirmation from the external event, it could trigger the release of the settlement instruction in T2S. But it some cases automation may not be feasible. CSD validation hold is similar to CoSD though it does not automatically block cash and/or securities. It is used by the CSDs in T2S in order to have control on settlement instructions due to regulatory, legal reasons or market practices. These functionalities are not expected to be used heavily by CSDs in T2S. Quantitative evidence Not available Page 7 of 39

8 b. Communication procedures and standards - STP 12. The use of straight through processing ("STP") through the securities chain should be promoted as it might lead to (i) a more efficient settlement procedure; (ii) possibly reduced settlement costs; (iii) lowering operational risk by reducing manual intervention in the settlement process. By STP is meant the automated endto-end processing of trades/settlement instructions including, where relevant, the automated completion of confirmation, matching, routing, clearing and settlement of instructions (in line with the definition of "STP" in the ECB glossary). 13. While a CSD is normally not in a position to ensure automation in the rest of the securities chain, it may choose technical solutions which accommodate the use of STP. Moreover, CSDR Article 35 requires that CSDs use in their communication procedures with participants of the securities settlement systems they operate, and with the market infrastructures they interface with international open communication procedures and standards for messaging and reference data in order to facilitate efficient recording, payment and settlement, as defined in Article 2(1)(31) of CSDR. The use of such procedures and standards may, amongst others, reduce barriers to entry into a market. In this context, is important to note that use of the message format ISO is mandatory for T2S as well as for credit transfers and direct debits in the Single Euro Payments Area (SEPA) (Cf. the Annex to Regulation (EU No 260/2012 of the European Parliament and of the Council of 14 March 2012 establishing technical and business requirements for credit transfers and direct debits in euro and amending Regulation (EC) No 924/2009. ISO is a Universal financial industry message scheme ( These procedures may therefore be considered to facilitate STP and therefore efficiency along the chain. Q3: ESMA welcomes concrete proposals on how the relevant communication procedures and standards could be further defined to ensure STP. T2S AG feedback on Q3: As correctly mentioned above, T2S requires the use of the ISO messaging standard for communication in application-to-application (A2A) mode. Information on T2S functionalities available to CSDs The exact messages and interaction in A2A mode are described in the T2S UDFS. 10 Rationale Alternatives Quantitative evidence 10 Please refer to T2S UDFS Section 2, Dialogue between T2S and T2S Actors and Section 3, Catalogue of messages. For further clarifications on the usage of ISO messages, reference can be made also to the MyStandards Tool, supported by the SWIFT Community. Page 8 of 39

9 c. Matching of settlement instructions 14. Matching in the context of CSDs is the process of comparing the settlement details provided by the buyer and the seller of securities in order to ensure that they agree on the settlement terms of the transaction (T2S URD paragraph 5.5). i. Compulsory matching 15. Matching is a prerequisite for an efficient settlement process as it may reveal inconsistencies between settlement instructions from both counterparties. Matching between CSD participants is a used and generally accepted step in the settlement of a transaction (Cf. ESCB-CESR Recommendation 2 for securities settlement systems (SSS)) and ESMA is of the opinion that matching prior to settlement should be compulsory. An exception to this would be (i) when the settlement instructions received by the CSD are already matched (e.g. trades entered into on a trading venue where the trading venue sends the trade enriched with settlement information to the CSD); or (ii) FoP instructions which consist in transfer of securities between different accounts opened in the name of the same participant. ii. Continuous matching 16. The matching of settlement instructions by CSDs should be fully automated; and occur as early as possible. The CSDs should therefore offer matching real-time; and continuously throughout each business day. iii. Standardised matching fields 17. CSDs currently set their own standards for determining which information should be provided in a settlement instruction. Standardising this by prescribing which matching fields should be used facilitates STP, because it caters for the scenario of CSD participants (including other CSDs) systems which participate in multiple CSDs; and might facilitate cross-border settlement. This easier settlement is achieved via matching fields harmonisation because all the information for the settlement is included in the settlement instructions; and the settlement instructions are exchanged (between the matching parties) in a standardised way. 18. ESMA therefore considers standardising the matching fields used. Harmonisation work in this field has been performed under T2S, where participant CSDs will be required to use the mandatory matching fields (T2S URD paragraph ) reported below: - Instruction type code; - Intended settlement date; - Trade date; - Currency (not for FoP); - Settlement amount (not for FoP), with a certain tolerance level; - Share quantity (for equities) or nominal amount (for fixed income securities); - Buy/sell (Deliver/receive for FoP); - ISIN code; - The counterparty delivering the securities; - The counterparty receiving the securities; and Page 9 of 39

10 - CSD of the counterparty. 19. These fields could be complemented where appropriate. In T2S clients codes are not mandatory matching fields. Client codes are generally voluntary matching fields, which become mandatory on the initiative of either or both counterparties. Nonetheless, client codes may be very important in order to avoid matching the wrong settlement instructions and could therefore be included. 20. It is also ESMA s view that CSDs should set appropriate tolerance levels in the settlement amounts in order to smooth the matching process. Q4: Do you share ESMA s view that matching should be compulsory and fields standardised as proposed? If not, please justify your answer and indicate any envisaged exception to this rule. Are there any additional fields that you would suggest ESMA to consider? How should clients codes be considered? T2S AG feedback on Q4: Compulsory matching The AG agrees with the approach of ESMA with regards to the compulsory nature of matching. Rationale The main reason for the compulsory matching principle is to ensure the safety of the securities transfers, i.e. that they are initiated only once both, the receiving and the delivering counterparty to a transaction, or their authorised parties (custodians, CCPs), have agreed on the terms of the settlement before the settlement instructions will be submitted to the CSDs to effect a certain securities transfer. Standardised Matching Fields The AG also welcomes the ESMA proposal to use the T2S matching fields as a basis for establishing a European standard for matching. A single list of matching fields would ensure harmonisation and avoidance of national specificities in this key area of post trade processing. However, the T2S Community would like to raise its concerns regarding the maintenance procedure of a standardised matching fields list. Rationale One concern is the approval procedure that any update/revision such list would require. For example, should the T2S community identify [and agree on] the need to update the T2S matching fields, would such an update be considered in breach of the CSDR level II RTS? Would ESMA be ready and willing to update such RTS, if and when required by the relevant business needs, and would such an update require an approval (or at least nonobjection ) procedure from all EU public authorities? Alternatives An alternative, which ESMA could consider, is the adoption of a minimum, and non-exhaustive, list of matching fields. Page 10 of 39

11 If this approach was to be followed, the list of matching fields described in standard 1 of the ESF- ECSDA Matching standards 11 could be used. T2S is fully compliant with this list. Information on T2S functionalities available to CSDs The AG confirms that, unless submitted as already matched to the CSDs by trading platforms or CCPs, the settlement instructions of counterparties will be matched on a continuous basis in T2S. Exceptions can be allowed also for FoP and DVP transfers between different securities accounts of one CSD participant, which can be sent by CSD participants as already matched in T2S, provided they have the privilege to instruct on the accounts involved in the transfer. In T2S, CSDs can send instructions as already matched by the CSDs on their platforms. From the business point of view, these are two instructions sent by the CSD that has already matched them (that is why it is not possible to have already matched instructions in the cross-csd case). Technically, they are sent as one instruction and T2S will create the two separate instructions upon successful validation. Settlement instructions always need to have two sides in T2S, also for FOP and for movements between accounts of the same participant. Only the blocking/reservation/earmarking of a position in the same account can be done with one instruction. On par. 16 above: T2S will continuously match settlement instructions. (Please refer to chapter 5.5 Matching of the T2S URD and in particular T2S UR T2S for Continuous real-time matching facility in T2S.) On paragraph 19 above: The field Client of CSD Participant is populated by a BIC (when the client is eligible for a BIC) in T2S. This is an optional matching field in T2S, which means that once filled-in by one counterparty, this field will not prevent matching with an instruction in which this field is not populated (can be matched to blank). However, if both T2S Parties to a transaction have populated this field in their settlement instructions, the values provided have to match. On paragraph 20 above: T2S AG agrees with ESMA s view that appropriate tolerance levels in the settlement amounts serve to smooth the matching process. In T2S these tolerance amounts are 25 when the counter value is above 100,000 or 2 when it is 100,000 or less. (Please refer to T2S URD T2S Tolerance amount for matching ) Quantitative evidence Not available 11 markets/docs/cesame/giovannini/ esf ecsdamatching_en.pdf Page 11 of 39

12 2.2 Incentives for early input of settlement instructions 21. Matching as early as possible in the settlement process gives the possibility to identify and correct inconsistencies in time for the transaction to settle on the ISD. Participants should therefore send settlement instructions to the CSD as early as possible in order to make early matching possible. 22. To accomplish this, disincentives could be applied to (i) the late sending of complete instructions; and/or (ii) the late matching of complete instructions. However, it might be difficult to enforce that specific rule without penalising the participant which sent its instruction timely. 23. It is therefore ESMA s current view that settlement instructions which are not received by the CSD by the end of ISD-2 should be subject to disincentives by the CSD, if the latter is aware that these were not submitted or, after submission, that these could have been submitted before the end of ISD-2 (For some classes the cycle may be different and this would apply with adaptations, notably in the case of shorter than T+2 cycles). Such measures should avoid participants sending instructions to the settlement system only when they are certain the instructions may be settled to avoid penalties for settlement fails. 24. In order to incentivise early matching, CSDs should offer hold/release and bilateral cancellation facilities, without prejudice of the Settlement Finality Directive provisions. 25. CSDs should develop a procedure to inform participants about pending settlement instructions of counterparties. Participants should be able to know that their instruction did not match the reason why. This information could be made available by the CSD within 30 minutes maximum, or similar cap after the first unsuccessful matching attempt; and at the beginning of ISD. Q5: Do you agree with the above proposals? What kind of disincentives (other than monetary incentives such as discounts on matching fees) might be envisaged and under which product scope? T2S AG feedback on Q5: Whilst the AG fully supports the CSDR aim of ensuring early input of settlement instructions, it does not consider it would be practical or necessary to impose a deadline of ISD-2 for input and matching of the settlement instructions at the underlying CSD. Instead the proposal of the T2S Community is that a market practice is proposed by ESMA for transactions with a T+2 or longer settlement cycle to match by T+1 end of business day while for transactions with T+1 or T+0 settlement cycle to match on ISD. This would include the sending of instructions as early in the lifecycle as possible to enable the matching process at the CSD / T2S. Similarly, whilst the AG supports and encourages early matching in order to facilitate efficient and timely settlement of trades on their ISD, its members do not believe that the imposition of financial disincentives in order to meet suggested deadline is necessary and conductive to this aim. The T2S community believes that a settlement discipline regime as outlined by CSDR will provide sufficient incentive for the markets to improve their settlement efficiency. The AG further agrees that in order to support early matching, the CSD should also offer participants the relevant "toolkit" to enable them to match in the CSD early in the settlement cycle with assurance of relevant Page 12 of 39

13 control over the settlement process that they require. This should include, but not necessarily be limited to use of Hold and Release, linking and prioritisation functionality. In addition, the CSD should provide its participants with reports to enable them to identify whether their instructions have been matched as well as reports on whether other CSD participants have submitted settlement instructions, which have not yet been matched against them. (Please refer to the short description on these below or to the attached technical annex for more details regarding the T2S relevant functionalities). Rationale Imposing to send instructions by ISD-2 (or on T) should be avoided due to the following reasons: A) Not practical, due to the fact that instructions resulting out of OTC trades need to pass several participants in the processing chain including potentially travelling through different time-zones including Asia. In such a scenario the underlying investor will not be in a position to instruct its sub custodian until T+1. Equally a number of CCPs either perform their netting function only on the evening of T resulting in instructions being received by the CSD on T+1 or instructions are inserted through continuous net settlement cycle on the evening of T+1. B) Not required, due to fact that trades need to be matched in order for them to settle on ISD. In T2S the most efficient time for transactions to settle is the overnight batch as the overnight batch employs more powerful settlement optimisation procedures that help minimize the necessary resources for settling all matched transactions. These optimisation procedures work the best when more and more transactions are available for settlement at the T2S start of day, i.e. the beginning of overnight settlement on ISD. In order for transactions to settle in the overnight batch of ISD, the instructions should have matched in T2S by end of T+1 Imposing of financial incentives for early matching and disincentives for late matching/ sending of instructions should be avoided due to the following reasons: A) Matching fines may not increase settlement efficiency while at the same time adding to the cost base of the settlement process B) If one was to consider a fine for late matching, should a participant match after ISD (or the relevant cut-off on ISD), this late matching will by definition become one of the reasons for settlement failure (the others being lack of stock, lack of cash or trade at Held status) and as such the last participant to input the trade could be charged the late settlement fine accordingly. C) Applying a fine for late matching before the ISD could actually incentivize behaviour to send instructions without proper checking into the system, in order to be in the system as early as possible. On this basis matching efficiency might actually decline as it may create a flurry of incorrect/incomplete instructions, and thus lead to lots of repairs/reinstructs on T+1 for no good reason, and may even lead to lower settlement rates. D) Different CSD participants operate with different products. Thus, based on the type of their business, some CSD participants may be unduly rewarded (for early matching) while others punished (for late matching). What really matters in the end are settlement rates. This is supported by the quantitative evidence provided below. Page 13 of 39

14 Information on T2S functionalities available to CSDs On par. 24 above: T2S shall provide a hold and release mechanism. CSD participants and CSDs may use this mechanism on a voluntary basis. T2S shall support the hold and release of partially settled instructions (Please refer to T2S UR T2S Hold and release mechanism availability ). T2S shall allow only bilateral cancellations for matched instructions, i.e. both parties must send a Cancellation instruction ( binding matching ) (Please refer to T2S UR T2S Bilateral cancellation ). On paragraph 25 above: T2S provides for allegement messages in case of not matching. The counterparty to a trade, which have not yet sent its settlement instruction, receives an allegement message (sese.028) from T2S according to two different scenarios: Scenario A: A certain time after the first matching attempt (standard delay period, currently configured as 1 hour), to avoid early transmission of the message. Scenario B: Or at the latest a specified time (currently configured as 5 hours ) before the cut-off time of the Intended Settlement Date, i.e. in case the end of the standard delay period would leave less than the standard delay period before the cut-off. Allegement messages are sent only if a CSD participant has subscribed to them. (i.e. they are not mandatory). The allegement message, sent to the counterparty to trade, contains the main details of the settlement instruction which was has not matched. On paragraph 25: the T2S community is, therefore, of the opinion that CSDs should only provide the necessary tools to their participants, via the above-described standard ISO reports, but should not require them to use those, as this may lead to imposing onerous and costly procedures on CSD participants which, depending on their business model, may be actually not required or even counterproductive. Furthermore, mandatory sending of messages by T2S as well as CSDs platforms will lead to a slow- down of processing of settlement. The T2S Community had investigated in the past whether T2S should sent to the T2S instructing party whose instruction is pending a message regarding the reason for not matching. However, the T2S Community has decided against it, because with such a high volume of instructions on the T2S platform, it would technically be very difficult to provide a reason why an instruction has not matched. For example, there could be thousands of instructions with almost identical, but slightly deviating, instruction details and it would be very difficult to identify which exactly are the instructions which are supposed to match but did not. It could be that some CSDs offer such service today where matching (and non-matching) volumes are low. But it was considered that, in view of the arguments provided above, that this service would be technically impractical to be provided on the T2S platform as this could result in a huge flood of information on nonmatched instructions that were never intended to match in any case. Actually, from technical perspective, if both counterparties have sent instructions to T2S, which have not been matched, they will both receive allegement reports from the T2S, provided that the parties have subscribed to receive such allegement messages. Therefore, based on these reports, the CSD participants can find out the reason for non-matching. In addition, the CSD parties can make use of the Securities Settlement Transaction Status Advice (sese.024) message to receive update from T2S when their instructions have been matched. Thus, if they are notified that Page 14 of 39

15 their instructions have not been matched by a certain deadline, they can investigate with their counterparties the reasons for the lack of matching. The receipt of this report is also subject to subscription by the CSD counterparty. This information would be available also via the GUI of T2S, which will be feasible to be used for a small number of instructions. Quantitative evidence A statistical exercise performed by ECSDA in shows that there is no direct correlation between the matching rate on ISD-1 and the settlement efficiency rate on ISD. In other words, a high rate of matching efficiency does not necessarily translate into a proportionally lower rate of settlement fails, although we intuitively think that early matching supports timely settlement. Today, only some CSDs collect matching data (matching data is typically not collected when CSDs primarily settle on-exchange transactions), and only 14 out of 20 SSSs had provided matching data to the 2012 ECSDA study. In most CSDs, the majority of instructions are directly input by the exchange, MTF or CCP, thus resulting in a relatively low proportion of transactions that require counterparties to send a matching instruction. Markets with a small proportion of bilaterally input transactions tend to have a high matching rate, exceeding 89% on ISD-1 (and sometimes equal to 100%). On the opposite, in markets with a more important proportion of bilaterally input instructions, the matching rate is 43% in the ESES markets 13 (on ISD-1), 46% in Portugal, 70% in Spain (CADE Platform), close to 88% in Finland and more than 95% in Norway. For bilaterally input instructions, the matching date is typically agreed by the counterparties and practices differ from one market to another. This explains why it is difficult to define and compare matching efficiency across Europe. Furthermore, the comparison between two market settlement regimes, one with matching fines and one without, UK (EUI) and Italian (Monte Titoli), shows no link between overall settlement rate and inclusion of matching fines with both overall settlement rates being comparable. However, in order to finalise this benchmark, it is suggested that ESMA performs a detailed review of existing CSDs settlement regimes to compare overall settlement rates vs. matching efficiency. 12 The full 2012 ECSDA report is available at: 13 To be noted: currently in ESES matching means commitment to settle. Thus, participants who want to recognise they have to instruct when not having the stock will instruct on a pré-appariement status (tomorrow it will be replaced by the matching hold and release process). So comparing matching rates within CSDs, should be done at least for ESES with some caution. Page 15 of 39

16 2.3 System functionalities 26. There are several reasons why it is advantageous to have more than one batch (In this document the term batch is used as possibility to settle. This is in line with the definition of the term in the PFMI) to settle or to have continuous settlement RTGS (ECB glossary: Real-time gross settlement (RTGS) system: a settlement system in which processing and settlement take place on a transaction-by-transaction basis in real time.) during a business day. One of the advantages is that it enables participants to resolve problems with the settlement instructions which prevented their settlement in the first available settlement batch, while still being able to settle on ISD. This would improve the settlement efficiency and shorten the period in which the parties are exposed to counterparty risk (e.g. credit or liquidity risk). A second reason is that multiple daily settlements may also help ensure efficient use of the cash received by the participants during the settlement cycles, due to different timing of settlement in the payment systems. A third reason is that it may facilitate the establishment of links between CSDs. This because frequent settlement reduces the risk that settlement instructions remain pending in one system as a result of finality not being achieved timely in the linked system. 27. In 2004, ECSDA agreed ten standards for settlement to assist removing the so-called Giovannini (Committee) barriers to settlement (Cfr. the Second Giovannini report from April 2003). ECSDA Standard 9 states that securities settlement systems should support efficient cross-border settlement in Europe. This should be done by including at least one settlement cycle per hour during the opening time of the relevant European currency's banking system and until, at a minimum, two hours before the banking system closes. Not all European CSDs meet this ECSDA standard. Further, it is the understanding of ESMA that in the markets with continuous or multiple daily settlements, not all batches are necessarily widely used. 28. Also according to PFMI8, securities settlement systems should consider adopting real time or multiplebatch processing during the settlement day. There are, however, mixed risk profiles of real time and multiple batches, as further detailed in PFMI8.(In particular Explanatory Note 3.8.7: The use of multiple-batch settlement and RTGS involves different trade-offs. Multiple-batch settlement based on a DNS mechanism, for example, may expose participants to settlement risks for the period during which settlement is deferred. These risks, if not sufficiently controlled, could result in the inability of one or more participants to meet their financial obligations. Conversely, while an RTGS system can mitigate or eliminate these settlement risks, it requires participants to have sufficient liquidity to cover all their outgoing payments and can therefore require relatively large amounts of intraday liquidity. This liquidity can come from various sources, including balances at a central bank or commercial bank, incoming payments, and intraday credit. An RTGS system may be able to reduce its liquidity needs by implementing a queuing facility or other liquidity-saving mechanisms. ) 29. To increase settlement on the ISD, ESMA is of the opinion that the CSDs should be obliged to offer (i) several possibilities to settle; or (ii) on-going DVP settlement throughout each business day. ESMA's view is that it should be left to each CSD to decide whether real time or multiple daily settlement batches will be most appropriate for the markets they serve. However, all CSDs should be obliged to offer at least three daily settlements (batches), unless they operate on an RTGS basis. The latter, being more stringent, would indeed ensure compliance with a multiple batches system. Page 16 of 39

17 Q6: In your opinion, should CSDs be obliged to offer at least 3 daily settlements/batches per day? Of which duration? Please elaborate providing relevant data to estimate the cost and benefit associated with the different options. T2S AG feedback on Q6: CSDs joining T2S will have access to a single settlement model throughout the settlement day: real-time DVP settlement in Central Bank Money. Information on T2S functionalities available to CSDs T2S will use two night-time cycles and within these cycles there are several sequences in which different types of instructions can settle. The maintenance window is currently planned from 03:00 a.m. to 05:00 a.m. If the night-time cycles are completed earlier than 03:00a.m., real-time settlement will commence and continue until 03:00 a.m. Real time settlement will resume after 05:00 a.m. until end-of-day at 18:00. Rationale Alternatives Quantitative evidence Page 17 of 39

18 30. ESMA finds that several other system functionalities may contribute to settlement efficiency: - the use of optimisation algorithms, inter alia applying technical netting (in T2S, transactions are grouped into a set to which technical netting is applied by calculating the net quantities and amounts to be settled on an all-or-none basis. These net quantities and amounts are the basis for the checks against the resources available for the settlement. Such technical netting may solve gridlocks in a "Real Time Gross Settlement" (RTGS) system.) Typically identifying chains of settlement instructions; - partial settlement/splitting a failed settlement instruction in several instructions (e.g. one which will settle and one which will fail); - recycling of settlement instructions by the CSD in order to settle any failed settlement instructions in a later settlement procedure; - shaping a trade by substituting a failed settlement instruction with a number of smaller settlement instructions, which in total are equivalent to the original failed settlement instructions, in accordance with predefined parameters. Q7: In your view, should any of the above measures to facilitate settlement on ISD be mandatory? Please describe any other measure that would be appropriate to be mandated. T2S AG feedback on Q7: Rationale The view of the AG is that the use by the CSDs in T2S of the measures to facilitate settlement described above should be provided for in the legislation, but those should not be made mandatory for all CSDs. The AG would therefore suggest that each CSD should have the option to choose which of the concrete tools listed in paragraph 30 it offers to its participants, based on its business model and taking into account: the services it offers; and the management of the associated risks involved. Information on T2S functionalities available to CSDs The usage of the above features: optimisation algorithms, technical netting, partial settlement and recycling of settlement instructions are available in T2S. In more detail: 1. The technical netting which limits the resources needed for their settlement to the net quantities or amounts of Settlement Instructions, Settlement Restrictions and liquidity transfers submitted together to a settlement on an all-or-none basis. (T2S UR T2S ) 2. The partial settlement which allows T2S, under specific conditions, to settle only a part of Settlement Instructions, Settlement Restrictions or liquidity transfers with the available resources. (T2S UR T2S ) Counterparties can opt-out of partial settlement. 3. The optimisation algorithms which allow the identification and selection of pending Settlement Instructions, Settlement Restrictions able to settle with success when they are submitted together to a settlement attempt. (T2S UR T2S ) Page 18 of 39

19 4. T2S facilitates the resubmission of failed, matched settlement instruction for a new settlement attempt, when still eligible for settlement, or reintroduction of an unmatched settlement instruction into the matching process after the previous matching attempt has failed. (T2S UR T2S ) In addition, to avoid fails and optimise the use of liquidity in T2S, T2S offers auto-collateralisation to central bank and payment/settlement banks (credit providers), i.e. the capacity to provide to credit consumers intraday credit (covering lack of cash) automatically secured in T2S with eligible collateral. This capacity is achieved through the auto-collateralisation which is technically available in all T2S settlement currencies (T2S UR T2S ). Furthermore, these facilities provide for automated substitution of collateral in case already collateralised securities are needed for settlement of settlement instructions. T2S does not offer shaping of transactions. While it facilitates settlement, this is normally a procedure which is used before a transaction is submitted to the settlement engine. Alternatives Quantitative evidence Page 19 of 39

20 2.4 Lending facilities 31. According to CESR-ESCB Recommendation 5 for Securities Settlement Systems ( RSSS 2009, (key issue 3) that A centralised securities lending facility can be an efficient mechanism for reducing settlement failures. However, in markets where the number of settlement failures remains low, centralised securities lending arrangements may not be justified from a cost-benefit perspective. 32. On the basis of CSDR, any provision to be contained in the TS need to refer to securities lending and borrowing mechanisms where the CSD acts as an agent (facilitator). Any mechanism in which the CSD takes on counterparty credit risk requires a special authorisation under the regime envisaged for the services under Section C of the Annex to the CSDR. 33. Centralised securities lending facilitates a speedy matching of potential borrowers and lenders, making the lending process faster and potentially more accurate (automated procedures) and thus overall more efficient. In some markets, they are integrated in the securities settlement system, meaning that loans are automatically generated if this is necessary to avoid settlement fails during each settlement batch. 34. The use of centralised securities lending facilities in connection with settlement might reduce the number of settlement fails. ESMA has considered whether it should be mandatory for the CSDs to make such facilities available to their participants. However: - such facilities are not available in all markets; - they are often restricted to the most liquid shares, in part because other financial instruments may be too scarce to be supplied through a centralised lending facility; - they may entail substantial costs for the CSDs and their participants; - there may be tax disincentives; and - depending on the design of the lending facility, the lender and the borrower may also have to take liquidity and credit risk on each other. Against this background, ESMA believes that CSDs should not be obliged to offer arrangements for the lending and borrowing of securities. Should the service be provided, it should be framed in a harmonised manner. Q8: Do you agree with this view? If not please elaborate on how such arrangements could be designed and include the relevant data to estimate the costs and benefits associated with such arrangements. Comments are also welcome on whether ESMA should provide for a framework on lending facilities where offered by CSDs. Details of the system monitoring settlement fails (Article 7(14)(a) T2S AG feedback on Q8: The T2S AG supports the view of ESMA that although centralised arrangements for lending and borrowing of securities provided by CSDs would serve to increase the settlement efficiency, CSDs should not be obliged to offer this facility on a mandatory basis to their participants. Page 20 of 39

21 In particular, being a lean securities settlement platform itself, T2S does not provide for automatic securities lending and borrowing facilities. However, CSDs in T2S may develop centralised securities lending facilities using the T2S generic functionalities described in the T2S URD and T2S UDFS. The AG is of the opinion that if different CSDs in T2S were to introduce centralised lending facilities, a harmonised approach would be beneficial for the cross-border operations within the T2S markets. However, the AG is not supporting that the details of any such harmonised potential securities lending facility is enshrined in EU regulation (RTS). Rationale Alternatives Quantitative evidence Page 21 of 39

22 2.5 Details of the system monitoring settlement fails (Art7/14.a) 35. Article 7(1) CSDR mandates CSDs to establish a system that monitors settlement fails of transactions in financial instruments and provide regular reports to the authorities as to the number and details of settlement fails and any other relevant information. These reports, including the measures envisaged by CSDs and their participants to improve settlement efficiency, are also to be made public by CSDs in an aggregated and anonymised form on an annual basis. 36.This means that a CSD will need to monitor settlement fails for a number of instruments, which, as outlined in Article 5(1), includes transferable securities, money-market instruments, units in collective investment undertakings and emission allowances, depending on the instruments accepted by the relevant CSD. 37. It is important for competent authorities to have regular and timely information on settlement figures, in order to have an overview of how efficiently securities settlement is occurring, as well as being able to identify where problems are or where they may arise. Likewise, ESMA considers that participants to the settlement system also have access to information on settlement fails so that they may address them in a timely fashion and be able to take necessary action to resolve fails. 38. The content of these reports will need to be accurate and useful for competent authorities and securities system participants to assess and act on. Therefore, the number and details of fails are essential pieces of information that should be included. If participants are not actively sent settlement fails reports by the CSD they should at least have open access to their own status on fails and an aggregate status for the CSD operating the systems to which they are participants. 39. At present, a number of CSDs currently operate a system that does such monitoring, in order to identify transactions that have failed to settle. However, for a number of CSDs this was not a legal obligation before CSDR. As well as the CSD, in a number of jurisdictions the CCP also carries out similar monitoring, also following the Short Selling Regulation. A few jurisdictions also have entities such as authorities or trading venues involved in such monitoring. 40. For the determination of the details of such monitoring, ESMA will rely on the existing mechanisms established voluntarily by ESMA and the competent authorities. 41. The table below presents in more detail the key elements for settlement fails reporting by the supervisors of EU CSDs and ICSDs to ESMA and ensures the consistency of the dataset. Data is sent per settlement day and settlement system. Given the easy availability of the software, Microsoft Excel has been used, although any format may be used provided that enables the processing of the data in an EU harmonised way at ESMA and avoid manual processing. The required data is as follows and further described below. Field Country Code Settlement Date Description Two letter country code The intended settlement date Page 22 of 39