Change Requests 559 and 560 resulting from the CSG s Task Force (TF) on Insolvency Proceedings

Transcription

1 Change Requests 559 and 560 resulting from the CSG s Task Force (TF) on Insolvency Proceedings CRG teleconference on 22 January 2016 T2S Programme Office European Central Bank 1

2 Change Requests resulting from Insolvency TF Background The Insolvency TF has been focusing on 2 deliverables: Collective Agreement Sets out the legal rights and obligations of the T2S CSDs and NCBs in connection with the harmonised definition of the moment of entry (SF1) and irrevocability of transfer orders (SF2) High-level Procedures Principles for handling the insolvency of a participant in T2S (DCA or SAC holder) and subsequent reporting requirements, to be further elaborated in the MOP Outcome: T2S provides tools to ensure compliance with the legal requirements of the SFD BUT an insolvency situation cannot be managed adequately from an operational standpoint with the current T2S functionalities. The CRs aim at improving operational efficiency for managing insolvency of a T2S participant 2

3 Change Requests resulting from Insolvency TF Scope 3 CRs were raised by the TF: CR558 (*) It is already possible to trigger rejection based on the SAC with current functionality Trigger rejection of new incoming settlement instructions based on the DCA (*) : Covered by 4CB in a separate presentation Focus of this presentation CR559 CR560 Prevent matching new/existing settlement instructions in case of insolvency of CSD participant / DCA holder: Description / Current functionality / Rationale Implementation options T2S reporting must be enhanced to allow retrieval of SF1/SF2 timestamps in a simple and standard way: Description / Current functionality / Rationale Implementation options Objective of the presentation is to better understand the requirements, rationale, implementation options, and define priority for the CRs 559&560 3

4 Change Requests resulting from Insolvency TF CSG TF s views on the CRs and their urgency The Change Request T2S-0558-URD aims at implementing a tool, which can be quickly activated in the event of the insolvency of a DCA holder and which would result in the rejection of any new instructions (i.e. prevent them entering the system). The majority of the Task Force members consider that, without its implementation, they would not be in a position to confirm their satisfaction with the tools and procedures related to insolvency of participants, which would prevent the Collaborative Agreement from entering into force. The Change Request T2S-0559-URD aims at preventing the successful matching of instructions when they have entered the system before the operator becomes aware of the insolvency but are not yet matched by then. The members of the Task Force do not view the implementation of this change as an absolute necessity before the entry into force of the Collective Agreement. However they consider that it is an operational risk, which should be covered in the longer run. The Change Request T2S-0560-SYS aims at making the SF1 and SF2 time stamps (i.e. time of validation and time of matching) easily and automatically retrievable for the system operators. Different means are proposed for fulfilling this requirement and are reflected in the draft change request. The implementation of this change request may require a prior change to the ISO20022 standards. Some members of the Task Force consider this change request as a pre-requisite for the entry into force of the Collaborative Agreement. 4

5 Change Request T2S-0559-SYS Description of requirement and current functionality Requirement: Unmatched instructions submitted by an insolvent party (or on its behalf) and aiming at debiting one of its accounts(securities account or DCA) should not be eligible for matching, unless the instruction is submitted on behalf of the insolvency liquidator(*) Current T2S functionality allows to prevent settlement instructions from reaching: SF1 With the configuration of Case 1 restriction rejection rules, settlement instructions are rejected at validation stage SF3 - By setting a instruction on hold as configuration of Case 1 (CVAL) - Case 2 restriction types (intraday blocking on ISINs, accounts, parties), settlement instructions are not eligible for settlement There is no possibility in T2S to prevent (a subset of) settlement instructions (see further details on next slide) from reaching SF2 (matching). 5

6 Change Request T2S-0559-SYS Rationale for this requirement Scenario 4: Transfer orders entered after the opening of insolvency proceedings, which were not matched on the T2S platform by the time the operator becomes aware SI 1 from insolvent party SI 2 from solvent party t0 t1 t2 t3 SF1 Risk of matching with insolvent party instruction Time of the opening of the insolvency proceedings Time the CSD/NCB is made aware and: 1. Activates (case 2 restriction) blocking on SAC/DCA (SF3) 2. Activates (case 1 restriction) rejection on SAC/DCA (SF1) CSD queries unmatched instructions at t1 and cancels them End of 1 st business day of insolvency The CR addresses the risk of an insolvent party s SI entered between t0 and t1 matching with a counterparty SI entered between t1 and t2, when the CSD cancels unmatched instructions. Matched instructions require bilateral cancellation t 6

7 Change Request T2S-0560-SYS Description of requirement and current T2S functionality Requirement: T2S query/reporting functionality must be enhanced to allow the retrieval of the settlement instructions impacted by insolvency and their related SF1 (accepted) /SF2 (matched) timestamps in an efficient and standard way. Current T2S reporting functionality is deemed operationally cumbersome in the context of insolvency. When the CSD/NCB Operator has been made aware of the insolvency Flags relevant SAC(s) or DCA(s) as under insolvency CR560: retrieve the settlement instructions impacted by insolvency Further Actions By CSD (Hold or Cancel) 7

8 Change Request T2S-0560-SYS Current T2S Functionality Extraction of settlement instructions impacted by insolvency via A2A involves two step process 1. CSD sends semt Settlement Instruction Status Audit Trail Query Impacted settlement instructions having reached SF1 and SF2 can be retrieved. Amongst others parameters, search criterion instruction status type accepted or matched between specific timestamps or equal to a timestamp can be used. The query can be automated at the CSD end. The query retrieves all the instructions filtered according to the specified criteria and timestamps. The SecuritiesSettlementTransactionQueryResponse (semt.027) does not contain together both the SF1 (Accepted) timestamp and SF2 (Matched) timestamp of the reported settlement instructions 2. CSD sends sese Settlement Instruction Audit Trail Query SF1 and SF2 timestamp information is retrievable for each instruction Cumbersome process to query each instruction retrieved from step 1 but could be automated at the CSD end for A2A. 8

9 Change Request T2S-0560-SYS Explanation of requirement and rationale Current T2S Functionality Extraction of settlement instructions impacted by insolvency via U2A No direct way to query SF1 via U2A In the settlement instruction search screen, user could use status not cancelled with the time period. This way the audit trail should behave same as it would have been the status accepted and retrieve all the instructions which were given the status not cancelled in that specific timeframe (a SI can only be given the status not cancelled upon its acceptance in T2S). For each instruction listed, retrieve the SF1 timestamp in the status history details Other search criteria may be part of the query. Please note that query using DCA may not yield instructions using the default DCA until CR547 is implemented 9

10 Change Request T2S-0560-SYS Potential non-mutually exclusive Implementation options Current reporting mechanism is deemed operationally cumbersome in the context of insolvency. The insolvency TF deemed that T2S reporting mechanism must be enhanced to retrieve the necessary information in case of insolvency in a simple and standardised way. Potential non-mutually exclusive options 1. Inclusion of SF1/SF2 exact timestamps in the sese.024 message schema 2. Simplification of queries in A2A/U2A mode in order to retrieve the necessary SF1/SF2 information 3. Availability of a standardised report via U2A/A2A 10

11 Change Request T2S-0560-SYS Possibilities discussed in previous CRG meetings Inform SF1 & SF2 timestamp in sese.024 message Currently, T2S Actors are informed with the timestamp of the generated status advice sese.024 produced after SF1 (accepted) and SF2 (matched), but are not informed with the actual SF1/SF2 timestamps as stored in the database, due to the lack of ISO fields in the status advice sese.024 message schema. Considerations: ISO change requires longer implementation (earliest 2017) Not guaranteed (or even unlikely) to be accepted by ISO on international basis Adaptation to new message structure would mean higher adaptation costs for the T2S community CRG already had a consensus that changing the sese.024 message for insolvency situation is not the right solution. CRGs preference was mainly for reporting and U2A related change. 11

12 Change Request T2S-0560-SYS Simplification of queries in A2A/U2A mode In A2A: Include SF1/SF2 exact timestamps in the response message semt Securities Settlement Transaction Query Response In U2A: Include SF1/SF2 exact timestamps in the U2A screen in an easy downloadable File format Considerations semt.027 is T2S message (Pillar 3) and would be easier to change in T2S context, i.e. ISO CR not necessarily needed. However SGMS expert advice and further ISO approval would be needed Adaptation to new message structure semt.027 would mean adaptation costs for the T2S community using this message (mainly CSDs who will adapt for insolvency scenarios and CSDPs who will have to align to new message structure) Considerations No change to U2A screen layout. The download of the csv file from U2A to retrieve the SF1 and SF2 timestamp in addition to current content (for all users who wish to download the U2S result) Non intuitive as the SF1 and SF2 timestamp is not visible, apart from in the exported.csv file Creation of CSV file would take longer due to new complicated data access impacting the performance Semi-automatic process as CSDs may need to feed the csv file in their internal systems for further processing Alternative would be to add SF1 and SF2 timestamp in the SI list screen layout, though used only for specific scenarios and would impact U2A performance 12

13 Change Request T2S-0560-SYS Availability of a new standardised query Availability of a new standardised query to report SF1/SF2 exact timestamps via U2A Input query criteria Securities account number (Optional; or;) 1 Dedicated cash account number (Optional or;) 1 Insolvent Party BIC + Parent BIC (Optional or;) 1 Insolvent Party type (CSDP or payment bank or both, enabled only when Insolvent party BIC is entered) Accepted From Date (.e.g. date from when the insolvency procedure was declared) Accepted From time (e.g. Time the insolvency procedure was declared Accepted To Date (Optional) Accepted To time (Optional) Status (multiple selection possible) 1 : At least one of these search criteria has to be present Extraction criteria Standard business rules to ensure consistency of input search criteria to be applied Query should extract only those settlement instructions which have reached SF2 (matched) and or SF1 (accepted) after the timestamp entered in the search criteria Insolvent party BIC + parent BIC in the search parameter retrieves all settlement instructions impacting SACs or DCAs within the party BIC s data scope. Instructions impacting debit or credit transactions are reported. Based on query output (debit/credit indicator), CSDs to evaluate which instructions are needed to be acted upon. Please note that query using DCA search criteria considers positive implementation of CR547 -Enrich a settlement instruction with the default DCA at the acceptance 13

14 Option 2A - Change Request T2S-0560-SYS Availability of a new standardised query Output fields T2S Actor and T2S reference Instructing party BIC Instructing party Parent BIC Securities movement type Securities account / DCA number Currency ISIN ISIN description Accepted Timestamp (SF1) Matched Timestamp (SF2) Order quantity Settlement amount Settled quantity Settled amount Debit/Credit indicator Status (settlement, matching, cancellation) Output order Details shown segregated under settlement instruction status including SF1 and SF2 timestamps CRG could decide any other sorting requirement Additional features The query should be available to download as csv-file (non ISO 20022), which would also be useful for the regulators. CRG could decide on provision of additional features Allow user to navigate to settlement instruction detail screen by selecting the instruction Buttons for further actions by liquidator in the new U2A screen (e.g. button to cancel or hold the settlement instructions in bulk/multiple selection) Considerations No change to current T2S related messages. Better option if redesigning the GUI for handling insolvency has severe performance considerations Semi-automatic process as CSDs may need to feed the csv file in their internal systems for further processing 14

15 Change Request T2S-0560-SYS Availability of a new standardised query via A2A Availability of a standardised query to report SF1/SF2 exact timestamps via A2A New T2S specific messages (request and response) to cater to insolvency related reporting. The reporting conditions same as for the U2A requirement Considerations: New T2S messages. Only CSDs will have to adapt to requesting the insolvency related reporting The business use would be remote and limited only to CSDs in T2S. SGMS expert advice and ISO approval would still be needed? 15

16 Thank you for your attention 16

17 Annex A:Insolvency of CSD/CB participants in T2S SFD requirements: scenarios definition N o Description Applicable rule Comment 1 Transfer orders entered before the opening of insolvency proceedings 2 Transfer orders entered after the opening of insolvency proceedings, which were matched on the T2S platform before the operator becomes aware and for settlement on the same business day 3 Transfer orders entered after the opening of insolvency proceedings, which were matched on the T2S platform before the operator becomes aware but for settlement later than on the day of insolvency 4 Transfer orders entered after the opening of insolvency proceedings, which were not matched on the T2S platform by the time the operator becomes aware 5 Transfer orders entered after the moment the operator becomes aware of insolvency proceedings upon request of the insolvency liquidator (Art. 2 (8) of the Collective Agreement) 6 Transfer orders entered after the moment the operator becomes aware of insolvency proceedings without involvement of the insolvency liquidator No action to be taken (i.e. to be processed according to system rules) No action to be taken; cancellation if unsettled at the end of the day of insolvency To be immediately put on hold for a later cancellation by the operator(s) To be immediately cancelled To be processed according to system rules To be rejected The solvent party retains all its rights in accordance with the system rules If unsettled at the end of the day, shall be put on hold for a later cancellation by the operator(s) In case of cross-csd transaction, requires bilateral cancellation by the two CSDs; putting on hold ensures that settlement is prevented if bilateral cancellation is not effected once ISD is reached Immediate cancellation preferable as putting on hold may not prevent matching. Even when matched, such transfer orders would not settle as long as intraday blocking is active on the party or account. Only applicable in some national jurisdictions. Will be using an exception to the rejection rules foreseen under scenario 6 17

18 Annex A:Insolvency of CSD/CB participants in T2S SFD requirements: time representation of scenarios Scenario 1 SF1 No action to be taken (i.e. to be processed according to the system rules) Scenario 2 SF1 SF2 ICS = current BD No action to be taken Cancellation if unsettled at the end of the day of insolvency Scenario 3 SF1 SF2 ICS > current BD To be immediately put on hold for a later cancellation by the operator(s) Scenario 4 SF1 SF2 (*) To be immediately cancelled Scenario 5 SF1 Requested by the insolvency liquidator To be processed according to the system rules Scenario 6 SF1 (*) Not requested by the insolvency liquidator To be rejected Time of the opening of the insolvency proceedings (*) This step is not supposed to occur Time the CSD/NCB system operator is made aware End of 1 st business day of insolvency t 18

19 Annex B Input received on CR560 reporting requirement Input from SIX SIS The requirement is for a Query and not a report. The query should work as follows. Input to the Query by CSD: - CSD Participant BIC (who is in default) - Time of the opening of the insolvency proceedings (Timestamp) - Time the CSD/NCB system operator is made aware (Timestamp) The orders (In-CSD as well as Cross-CSD) of the CSD participant which meets following criteria should be displayed - Orders which are pending (Not settled and not cancelled) - Orders which are settled or cancelled between the Insolvency opened date and CSD aware date including both dates Output of the Query: The details of the orders required in output are Status, SF1 timestamp, SF2 timestamp, Order quantity, Settlement amount, all References, Suggested action (according to scenarios described in the Insolvency of CSD/CB participants in T2S Slide no.6 ). 19

20 Annex B Input received on CR560 reporting requirement Input from Iberclear Input to the Query by CSD: - Insolvent participant BIC - Date the insolvency procedure was declared - Time the insolvency procedure was declared Our proposal for the query reply: - Instructions affected by the insolvent procedure Output of the Query: All details shown segregated under SF1 and under SF2. 20