Draft Summary Meeting of the Change Review Group

Transcription

1 T2S PROGRAMME OFFICE 17 July 2015 V0.1 Contact person: Alejandro del Campo Roiz de la Parra Phone: Draft Summary Meeting of the Change Review Group 9 July 2015, from 09:30 to 17:30 held at the European Central Bank 1. Introductory session The Chairperson, Karen Birkel, welcomed the participants. The Chairperson informed about the successful go-live of T2S with SIX SIS, Depozitarul Central (Romania), BOGS and Malta Stock Exchange and that the migration weekend was completed earlier than planned. After the weekend, there was a defect detected which was quickly corrected, following the processes foreseen. The Chairperson also informed that the migration of Monti Titoli was foreseen for the end of August 2015 and a CSG Task Force was constituted to discuss the plan for migrating Monte Titoli and to analyse the impacts on other migration waves in the course of July The Chairperson walked through the agenda which included 10 Change Requests (7 new CRs and 3 CRs from the previous CRG meetings), an update on scope/delivery plan for Release 1.1, clarification on T2S behaviour in case of Change of decimals for SUM of a security, CRG members feedback for Optimisation of T2S GUI use, 4CB presentation on migration of new version ISO messages, CRG feedback on ISO codes across T2S messages, likely obsolete topics from the potential Change Requests for T2S Release 2, way forward for ISIN change functionality, clarification note on availability of generated reports in T2S, Change Request T2S-0447-SYS (Apply Static Data changes immediately in production) and presentation by Euroclear on partial settlement reporting in T2S Statement of Transactions. The Chairperson mentioned that it is important to take decision on the recommendation of CR 494 at the earliest, so that the CR could be accommodated in the Release 1.1.

2 A CRG member mentioned about the difficulties in finding accommodation in Frankfurt due to a fair for the next CRG meeting of September 2015 and the 4CB offered a possibility to hold the CRG meeting outside of Frankfurt. The Chairperson informed that the CRG meeting of September would focus on the Change Requests required for T2S Release 1.2 instead of Release 2 as this is more urgent from the timing point of view. However, a filtering of the CRs which are on hold/potential CRs would be made with the aim of agreeing on a prioritisation for fast-track Release 1.2. Besides the scope of the fast-track Release 1.2, which the Eurosystem suggests to define in the same way as for Release 1.1, the following two elements have to be decided soon: (i) date of deployment to production (2 months ahead migration of Wave 3 tbc); and (ii) expected latest delivery date for user testing. Another reason for postponing the discussion on the scope of Release 2 is because the ESMA requirements for CSDR Level II Standards have been delayed until the end of September Therefore the discussion on the Change Requests for T2S Release 2 before the end of September would be premature. Action point: The CRG will consult the OMG regarding the above element (i) and the PMG/UTSG concerning the above element (ii) in order to the have the replies available for the CRG meeting in September Feedback on action points from previous CRG meetings The participants were informed about the resolution of the action points from previous CRG meetings and it was mentioned that the resolution of the action points could be discussed, if required in the respective agenda item during the meeting. The ECB informed that the action point T2SACTION-1765 on the Change Request T2S-493-SYS is open and the feedback of the OMG (for a need to define the decision process at the OMG level for any change of default Top priority) was awaited. The ECB clarified that the feedback received from the CRG members in the context of the Action point T2SACTION-1789, on the topic UT-PBR-029 (T2S Reports during weekend), had been shared with the OMG and the proposals are under consideration by the OMG. 3. Approval of the summary of previous meetings The ECB informed that the following summaries of the CRG meetings/telcos were updated following the CRG comments. Summary of the CRG meeting of 28 April 2015 Summary of the CRG meeting of 20 May 2015 Summary of the CRG Telco of 26 May

3 Summary of the CRG Telco of 29 May 2015 Summary of the CRG Telco of 9 June 2015 Summary of the CRG written procedure from 11 to 18 June 2015 The ECB agreed to update the summary of the CRG telco of 26 May 2015 to include the reservation of a CRG member in the context of the request from a CSD to set-up Top priority. The ECB also agreed to clarify the statement related to the number of CRs under detailed assessment for Release 1.1 in the summary of the CRG telco of 29 May The participants did not raise any other objections and approved the summaries of the CRG meetings/telcos of 28 April 2015, CRG meeting of 20 May 2015, CRG telco of 26 May 2015, CRG telco of 29 May 2015, CRG telco of 9 June 2015 and CRG written procedure from 11 to 18 June 2015 The ECB will update the summary of the CRG telco of 26 May 2015 to include the reservation of a CRG member in the context of the request from a CSD to set-up Top priority. The ECB will check with the OMG for the current list of requested BICs for the setup of the default top priority. The ECB will clarify the statement related to the number of CRs under detailed assessment for Release 1.1 in the summary of the CRG telco of 29 May Analysis of the change requests The participants went through the different Change Requests (CRs) and made the below recommendations. A) Change Requests from the Market Detailed assessment of Change Request T2S-0494-SYS (Flat file solution for reports at end of day period) The aim of the Change Request T2S-0494-SYS is to create an additional alternative channel for the provision of five reports identified by the CSDs as critical reports for the reconciliation at the end of the business day: Statement of holdings (semt.002) Statement of settled intra-position movements (semt.016) Statement of transactions (semt.017) Statement of pending instructions (semt.018) Statement of pending intra-position movements (semt.034) 3

4 The 4CB provided feedback on the CRG member s comments on the detailed assessment and flat file format specifications. A CRG member mentioned that he still had a few detailed follow-up comments on the 4CB feedback, which he will share with the 4CB. The CRG agreed on following proposals: (i) not skip the delta version of the flat file report when the complete version of the flat file is generated; (ii) generate the weekly/monthly full flat file report on the last business day of the week/month; and (iii) report zeros for positions that have changed during the business day in the complete version of the flat file. The 4CB confirmed that the updated Change Request and the detailed assessment including flat file specifications will be shared with the CRG by 15 July The CRG acknowledged that the Change Request should be recommended for approval by 17 July 2015 at the latest. The CRG decided to recommend the approval of the Change Request in principle, subject to a final validation of the updated Change Request and detailed assessment. CRG decision: The CRG recommended the approval of the Change Request in principle. The 4CB will update the Change Request and its detailed assessment incl. file specifications following the CRG member s comments during the written procedure from 9 to 22 June 2015 and the CRG decisions on 9 July 2015 and send the completed documentation to the CRG by 15 July The CRG will review the final changes to the CR 494 documentation and the recommendation to approve the CR in principle will be confirmed by 17 July Change Request T2S-0525-SYS (Provide Restriction Type name in reason code in due to MSRT) The aim of the Change Request is to include the restriction type name and restriction type description in the reason of the rejection or validation hold status notification. It should apply both to the T2S T2S GUI and the A2A messages. Since the scope of this Change Request also covers the issue described in UT-PBR-040 (Reporting of Rule id for Restriction type Case 1), both topics were discussed together in Input requested by the User Testing Sub-group section. The Change Request initiator explained that only the restriction rule id which is provided in the A2A status notification message is not sufficient as the CSD user has to additionally refer to information on the Restriction types configured by the CSD. The CRG acknowledged that part of the Change Request also addresses the issue raised by the User Testing Sub-group note UT-PBR-040 (Reporting of Rule Id for Restriction type Case one). 4

5 The 4CB indicated that the current U2A behaviour is generic for all rejections (i.e. to display business rule and error text) and does not consider displaying any additional fields for reporting of the fulfilled Rule Id of a case one restriction. The 4CB clarified that they do not anticipate any new assessments for release 1.1 and therefore this Change Request could only be considered for implementation in release 1.2 or later. However in the short term, the 4CB agreed to investigate whether it is possible to implement including as a minimum a Rule Id in the message of GUI, consistently with the level of information for A2A, before wave 2. The CRG decided to put the Change Request on hold for discussion in the September 2015 CRG and agreed that the Change Request T2S-0525-SYS could be a potential candidate for Release 1.2. CRG decision: The CRG decided to put the Change Request on hold. Change Request T2S-0526-URD (Currency, Settlement amount and debit/credit indicator should be additional matching fields for FOP instructions) The aim of the Change Request is to make Currency, Settlement amount and debit/credit indicator as additional matching fields for FOP instructions. The ECB explained that the Change Request is in line with the way forward agreed in the CRG for the User Testing Incident PBI (COSD Currency field in FoP Instructions). The ECB explained that there are two open questions on the requirement for Change requests (i) how the tolerance amounts for the non-t2s currencies shall be defined in T2S? (ii) whether to add the check of the number of decimals of the cash amount for FOPs? The CRG was of the opinion that the tolerance amount for other currencies should be considered when matching FOP instructions. If the tolerance amount for a currency is not available and configures in Static Data, T2S would attempt to match on the exact settlement amount. The CRG also expressed that the check on the number of decimals could be done only if the check is already available for DVP instructions and this does not require an extra development effort for 4CB. The ECB confirmed to check the ECSDA/ESF matching standards for defining tolerance amount for matching currencies other than euro. A CRG member agreed to check and report on which tolerance amounts they use in their systems (e.g. fixed) and how often they update them. The CRG members agreed to provide the non-settlement currencies that they plan to use in a COSD context in T2S, and whether a tolerance amount is applicable for those currencies and if any, which one. The CRG agreed that the Change Request needs to be updated with regards to the currency values which will be included in operations and a procedure for revising their tolerance values on a regular (e.g. yearly) basis. The CRG decided to put the Change Request on hold and agreed that the Change Request T2S URD could be a potential candidate for fast-track Release 1.2. CRG decision: The CRG decided to put the Change Request on hold. 5

6 The ECB will check what the ECSDA/ESF matching standards say state regarding tolerance amount for matching currencies other than euros. Euroclear will check and report on which tolerance amounts they use in their systems (e.g. fixed) and how often they update them. The CSDs will provide the non-settlement currencies that they plan to use in a COSD context in T2S, and whether a tolerance amount is applicable for those currencies and if any, which one. A proposal needs to be elaborated (potentially in conjunction with the OMG) on the currency values which will be included in operations and a procedure for revising their tolerance values on a regular (e.g. yearly) basis and to introduce new currencies in the future. Change Request T2S-0528-SYS (T2S should allow the modification of possible values for an Attribute domain linked to a Market-specific attribute) The aim of the Change Request is to allow modification of possible values for an Attribute domain linked to an MSA. The Change Request initiator explained that the Change Request is required to add new values and update the value description for an attribute domain linked to MSA. The Change Request was raised as agreed in the CRG meeting of 20 May 2015 for the UTSG topic UT-PBR-012 (Attribute domain). The 4CB asked whether the scope of the Change Request also requires the possibility to change or delete the values of an attribute domain. The Change Request initiator agreed to provide feedback on the scope of the Change Request (i.e. need of deletion of MSA values and need of modifying either the MSA value and the MSA description or both) before September CRG meeting. The CRG decided to put the Change Request on hold for the September 2015 CRG meeting and agreed that the Change Request T2S-0528-SYS could be a potential candidate for fast-track Release 1.2. CRG decision: The CRG decided to put the Change Request on hold. The Change Request initiator will provide feedback on the scope of the Change Request T2S SYS (i.e. need of deletion of MSA values and need of modifying either the MSA value and the MSA description or both) before September CRG meeting. 6

7 Change Request T2S-0532-SYS (Hold/release default at account level should not override the Hold/Release indicator defined at instruction level) The aim of the Change Request is to modify the T2S behaviour so that the hold release default parameter should not override any hold/release status informed in the settlement instruction. The Change Request initiator explained that the hold release default should only be applied into instructions without explicit hold/release status being informed. The Change Request initiator confirmed to update the Change Request after reviewing the 4CB comments on the Change Request. The CRG decided to put the Change Request on hold and agreed that the Change Request T2S SYS could be a potential candidate for Release 2. CRG decision: The CRG decided to put the Change Request on hold. The Change Request initiator will update the CR after reviewing the 4CB comments on the Change Request T2S-0532-SYS. Change Request T2S-0533-SYS (Reporting of remaining to be settled quantity/amount in sese.027 and camt.075) The aim of the Change Request is to report in all sese.027 / camt.075 messages the remaining to be settled quantity/amount in the settlement quantity/amount field respectively, whereby the following definitions should be applied: Remaining to be settled quantity = originally instructed quantity settled quantity Remaining to be settled amount = originally instructed amount for unmatched instructions; or Matched amount settled amount for matched instructions. The Change Request initiator explained that the Change Request is required for correctly processing the cancellation status messages sese.027 and camt.075. The CRG agreed to update the Legal/business importance parameter from Critical to High. The CRG decided to put the Change Request on hold the September 2015 CRG meeting and agreed that the Change Request T2S-0533-SYS could be a potential candidate for fast-track Release 1.2. CRG decision: The CRG decided to put the Change Request on hold. The ECB will update the Legal/business importance parameter from Critical to High. Change Request T2S-0534-SYS (CFI code of a security should be modifiable) The aim of the Change Request is to allow changing a classification of financial instrument (CFI) code of an existing security in T2S static data. The Change Request initiator explained that the CFI code may not be available or applicable at the time of assignment. Also, the new standards will lead to changes of the CFI for quite a lot of existing 7

8 ISINs and therefore the possibility to change CFI code in T2S should be available latest at the point of time where the new standard is made mandatory. Another CRG member supported the Change Request as they have already faced an issue due to no possibility of changing the CFI code in T2S. The 4CB suggested that, it would be more efficient if the Change Request could be expanded for including other attributes of security (e.g. country of issuance) which are not possible to modify, if required. The ECB agreed to check whether the feedback on this topic provided by the T2S Advisory Group to ESMA requirements for CSDR Level II Standards needs to be revisited due to the Change Request. Several Change Requests are impacting changes to the security static data and the 4CB has been asked to consider whether these changes should be bundled together, e.g. the change to SUM/decimals, ISIN change. The CRG decided to put the Change Request on hold and agreed that the Change Request T2S SYS could be a potential candidate for Release 2. CRG decision: The CRG decided to put the Change Request on hold. The ECB will check whether the feedback on this topic provided by the Advisory Group to ESMA needs to be revisited due to the Change Request T2S-0534-SYS. In elaborating on other Change Requests which impact the security static data, the 4CB will consider whether the changes should be bundled together, e.g. SUM/decimals, ISIN change. The Change Request initiator (VP Securities) will check whether there is a requirement to change the country of issuance, and if so, include it within this Change Request. B) Editorial Change Requests Change Request T2S-0521-SYS (Editorial change request on UDFS) This Change Request is required to make editorial changes regarding UDFS 2.0, which were previously excluded from Change Request T2S-0485-SYS (Items 5 and 14) due to comments from the OMG. The ECB informed that the OMG did not identify any operational impact of the Change Request during a written procedure from 4 to 18 May A CRG member was not in favour of this change request as they believe that not allowing roles creation by DCPs may have an operational impact on CSDs and DCPs. The CRG member suggested adding a statement in the UDFS that this function is not implemented and based on the post-launch experience; the need for this functionality could be re-confirmed. The 4CB clarified that the functionality to create and maintain roles was never foreseen for the CSD Participants and Payment Banks and the aim of the Change Request was to remove ambiguity from the UDFS. In case the functionality is required for CSD participants and Payment Banks in the future 8

9 then the standard change and release management procedure should be used and a new Change Request could be raised. As the functionality was never foreseen or required by the URD, it could not be included into the implementation as part of the current UDFS scope. The CRG agreed to recommend the approval of the Change Request in principle subject to the final positive feedback from Euroclear. CRG decision: The CRG recommended the approval of the Change Request in principle Change Request T2S-0529-SYS (Editorial Change Request on GFS, UDFS and UHB) This Change Request is required to implement changes in the UDFS, UHB and GFS stemming from user testing defects correction and market comments. The CRG agreed to update the Change Request T2S-0529-SYS to add the billing-related part of the Change Request T2S-0493-SYS. The CRG also agreed have a CRG written procedure on the updated Change Request until 16 July CRG decision: The CRG decided to put the Change Request on hold. The CRG members will provide comments on the Change Request by 16 July Scope proposal for T2S Release 1.1 The 4CB provided the updated planning and way forward for finalising the scope of the Release 1.1, with the aim of final approval of the scope of the Release 1.1 in the CSG meeting on 14&15 September The CRG was informed that there is an on-going CSG written procedure, until 15 July 2015, on the CRG recommendation to add the Change Requests T2S-0445-SYS (User access rights report) and T2S-0471-SYS (Deferred processing of maturity/expiry date update in T2S) to the scope of T2S Release 1.1. The CRG was informed that the 4CB will be able to deliver the detailed assessment on Change Request T2S-0497-SYS (No check on minimum settlement unit when settling Corporate Action instructions) on 7 August 2015, one month ahead of what was initially planned upon CRG request. The CRG agreed that the Change Request T2S-0508-SYS (Cleaning of dynamic data in contingency scenarios) is not required for Release 1.1 anymore following the 4CB confirmation that the proposed operational procedure for wave 1 can also be applied to the other migration waves. The CRG agreed that the Change Request T2S-0493-SYS (Default priority setup) is in principle not required anymore for Release 1.1, subject to confirmation by the OMG. The OMG drafting group at its meeting on July 2015 will discuss on drafting the procedures to manage the default top priority. The CRG also agreed to take out the billing-related part for the Reserved priority from the 9

10 Change Request T2S-0493-SYS and include it in the Change Request T2S-0529-SYS (Editorial Change Request on GFS, UDFS and UHB). The CRG agreed to have a CRG telco on 18 August 2015 (14 to 16 CET) to decide on the recommendation for approval and inclusion of the Change Requests T2S-0497-SYS and T2S SYS in the Release 1.1. Also, the CRG agreed to have another CRG telco just before the CSG meeting of September 2015, to decide on the recommendation for approval and inclusion of the Change Requests T2S-0495-SYS and T2S-0513-SYS in the Release 1.1. The ECB will inform the Migration Sub-group that the CRG sees the Change Request T2S SYS (Cleaning of dynamic data in contingency scenarios) as not required for Release 1.1 anymore so they can consider the withdrawal of the Change Request. The ECB will confirm the timing span of the management of the top priority (T2S SYS) with the OMG. If the OMG is willing to manage the default top priority until the end of the migration waves, CR 493 may be rescheduled for a later Release. T2S Release 1.2 The CRG acknowledged that the 4CB cannot start the detailed assessment of Change Requests for Release 1.2 before September 2015 as they are currently working on the detailed assessment of the Change Requests that are potential candidates for Release 1.1. The CRG was informed that the CRG meeting of September 2015 will focus on the Change Requests for Release 1.2 primarily and that the procedure will be similar as the CRs taken for Release Input requested by the User Testing Sub-group The ECB informed that the UTSG invited the CRG to evaluate and provide guidance on a functional assessment notes given below. User Testing incident INC (Statement of Holdings (semt.002) in complete version zero positions) The note explains that the complete Statement of Holdings report does not include former positions that are zero at the time of report creation. This timeline and consequently the zero positions are only included in the delta report. Additionally the note provides the complementary information that the zero positions could be extracted via queries. As a follow-up to the CRG discussions on this topic in the previous CRG meeting/telco of 20 and 29 May 2015, the 4CB provided the outcome of their analysis on the proposed Option 1b (i.e. reporting zeros for positions that have changed during the business day in the complete (full) version of the Statement of Holdings (semt.002) report ). The 4CB explained that the implementation of the 10

11 proposed Option 1b has negligible performance impact and moderate risk as there is no major update to the software. The CRG was in favour of the proposed Option 1b. It was acknowledged that it is consistent with the CRG requirement for the flat file version of the full Statement of Holdings report. A CRG member from Monte Titoli agreed to raise a Change Request for Option 1b. The 4CB informed that the detailed assessment for this CR could be completed in 4 weeks, as some analysis for this issue has already been done. The detailed assessment on the restriction references may take a little longer. The 4CB also agreed to provide a clarification on the purging of the restriction references in T2S (e.g. until when the restriction references that become zero can be used). Monte Titoli will raise a Change Request for option 1b and the ECB will support the drafting. The 4CB will provide a clarification on the purging of the restriction references in T2S (e.g. until when the restriction references that become zero can be used). User Testing incident INC (semt.002 does not consider unchanged positions in delta) The note clarifies current T2S behaviour for reporting of delta Statement of Holdings report (semt.002) and proposes the options that could be considered by the CRG. As per the current implementation, the Statement of Holdings in delta version provides the current securities positions within a security account, which were either newly created or changed or turned zero. Conversely it will not report the securities position positions of securities that didn t get impacted within the reporting period. The calculation of aggregated positions of a specific security in specific securities accounts only considers the securities positions which were either newly created or changed or turned zero. The note further provided following two proposed options to consider unchanged positions for calculation of aggregated positions in the delta Statement of Holdings (semt.002) report. Option 2a: to consider unchanged positions for calculation of aggregated positions; and Option 2b: to consider unchanged positions for calculation and reporting. The CRG acknowledged that, as per the current implementation, the delta version for the Statement of Holdings (semt.002) considers only the changed positions to calculate and report the aggregate positions. This implementation is the leanest, fastest (i.e. best performance) and also least costly solution for market participants in terms of billing, as only real changes are reported ( pure delta ). Current market practice with regards to the use of delta and full versions of the Statement of Holdings seems to be either varying across markets or the delta version is not used currently in most markets. The SMPG standard does not distinguish between the full and delta versions of the Statement of Holdings. The CRG acknowledged that the feasibility assessment of options 2a or 2b will be available for the September CRG meeting, if requested by the market by 23 July

12 The CRG acknowledged that the implementation of options 2a and 2b would only apply to the delta version for the Statement of Holdings (semt.002) and that a separate Change Request would be needed to update the flat file report accordingly. The 4CB underlies the fact that such a late CR would impact the flat files as, if not decided by 15 July 2015, the flat file would not include the pertinent feature before the migration of wave 2 as the needed new CR could only be delivered thereafter. Both options 2a and 2b are a mixture of changed and unchanged values (mix of delta and full) and will be more costly to market participants in terms of billing. The best possible mitigation of the negative performance impact will be addressed in the feasibility assessment. The CRG agreed to provide their feedback on whether the current implementation (i.e. option 1) is sufficient or if not, which of the proposed options to change the delta semt.002 (i.e. option 2a or option 2b) should be investigated by the 4CB, in a written procedure until 17 July The CRG also agreed that, if required in case of conflicting views in written procedure, the topic will be discussed the CRG Telco on 20 or 21 July The CRG will provide their feedback on whether the current implementation (i.e. option 1) is sufficient or if not, which of the proposed options to change the delta semt.002 (i.e. option 2a or option 2b) should be investigated by the 4CB, in a written procedure until 17 July The ECB/4CB will provide the outcome of the written procedure to the CRG members and if required in case of conflicting views, the topic will be discussed the CRG Telco on 20 or 21 July UT-PBR-034 (semt.027 query response not including expected instructions INC162658) The note explains that, when a T2S Actor queries SIs, using the DCA as a search criteria, only those SIs that have the DCA included explicitly are reported in the query response i.e. those instructions that used the DCA by default, are not reported in the query response even though the DCA by default is the DCA used as search criteria. T2S stores the default DCA in Static Data object CMB Securities Account Link of the Securities Account and is not attached to the SI when a SI is accepted in T2S. Since the default DCA is not attached to the SIs, T2S is not able to retrieve those SIs that do not have explicit DCA mentioned. Some CRG members questioned whether the incident was actually a defect, i.e. in their opinion the T2S design is not working in a consistent way as it offers the functionality of a default DCA but does not report on that DCA when it is used in queries. The 4CB highlighted that the way the interaction between queries and the default DCA functionality is implemented was explained at the beginning of user testing and was not seen as a defect. The CRG agreed to inform the PMG and CSG about the different views about whether the current behaviour of the settlement instruction query response (semt.027) is a defect or not. 12

13 The CRG agreed that a fix/change of the current design (query and message subscription, potentially other impacts) may not be the best solution at this stage. The CRG was in favour of option 2 i.e. enriching the settlement instruction with the default DCA at the acceptance. The 4CB agreed to draft a Change Request for the option 2 for the September CRG meeting. This Change Request could be a candidate for the fast-track Release 1.2 but CRG members expressed no urgency as to the implementation time. This should be further discussed in the September CRG. Also the 4CB agreed to inform the CRG about other cases where the same issue could arise because of default DCA (e.g. message subscription and potentially others). The 4CB will draft a Change Request for the option 2 for the September CRG meeting. This Change Request could be a candidate for the fast-track Release 1.2 but CRG members expressed no urgency as to the implementation time. This should be further discussed in the September CRG. The 4CB will inform the CRG about other cases where the same issue could arise because of default DCA (e.g. message subscription and potentially others). The ECB will inform the PMG/ CSG about the different CRG member s views regarding how to determine if the T2S behaviour is a defect or if it works as required/expected. UT-PBR-035 (Settlement parameters: securities sub-balance type) The clarification note explains that the reporting in the Securities Sub-Balance Type within the sese.025 (settlement confirmation) message provides the information which is included in the inbound sese.023 (settlement instruction) and does not reflect the Securities Sub-Balance Type that was used for the settlement. The note provides the scenarios when the settlement confirmation (sese.025) message provides Securities Sub-Balance Type which is different from the actual Securities subbalance type used during settlement. As a follow-up to CRG telco of 9 June 2015, the 4CB clarified that when selecting securities for collateralisation, T2S only considers restrictions types with a restriction processing type EARM. All positions associated with a CMB eligible for collateralisation for the currency of the cash account (or for all currencies - EXXX), without distinction between them, are potentially utilised by the selection algorithm. Also, in case of pledge-sub where the account used is earmarked at the account level, T2S will always use the eligible position for auto-collateralisation where the securities are held i.e. the "Earmarking for Auto-collateralisation" (EEUR or EXXX) position, i.e. the securities will be taken from the EEUR or EXXX position A CRG member indicated that the current T2S behaviour is expected, as they were aware of this behaviour and adapted their system accordingly. The CRG member considered no urgent need to adjust the T2S behaviour. 13

14 Another CRG member indicated that they are not planning to use the earmarking at account level when they go-live, therefore they are not impacted and do not take an urgent stand on the correction of the issue. The CRG acknowledged that the reporting to CSDs do not indicate the sub-balance which is impacted by settlement and therefore the CSDs may not know about the position type which is impacted for actual settlement in some specific scenarios (e.g. when both EEUR and EXXX contains securities positions eligible for auto-collateralisation). Therefore, the change may still be needed in the long term to align the reporting with the actual settlement behaviour. The CRG was of the view that there is no immediate need to change the current behaviour of reporting the securities sub-balance type in settlement confirmation messages for settlement instructions and settlement restrictions, when they are instructed by T2S actors or generated by T2S. The CRG was of the view that as a long-term solution (i.e. either Release 2 or later), the settlement confirmation messages should always include the actual parameters (e.g. position type), which was used for settlement, instead of the one included in the instruction when different. UT-PBR-038 (Restriction Reference for CoSD in semt.002) The clarification note explains the reporting of restriction references in the Statement of Holdings report (semt.002). The note specifically explains that statement of holdings report does not provide breakdown of restriction references for the CoSD blocked securities position. The 4CB confirmed that a new restriction reference is created each time settlement instructions are subject to conditional settlement. In the context of reporting of restriction references, the 4CB also clarified that T2S purges the restriction references once the detailed restriction type is zero for the configured retention period of 3 months. One CRG member was concerned that the addition of restriction references for CoSD blocking would blow-up the reports as T2S creates new restriction references each time a conditional blocking is done in T2S. The CRG acknowledged that the Restriction References for COSD (Conditional Blocking) is not reported in the Statement of Holdings report (semt.002). The CRG agreed that currently no change is desired to change the T2S behaviour and also indicated that that if a change is required, a new Change Request could be raised for discussion in the September CRG meeting. Action point: VP Securities will raise a Change Request, if the update is required 14

15 UT-PBR-040 (Reporting of Rule id for Restriction type Case 1) The note explains that when a settlement instruction/settlement restriction is entered using via A2A and if the settlement instruction/restriction is subject to a restriction rule, then T2S informs the Rule Id of the restriction rule which was applied to the instruction/restriction in the settlement instruction/restriction status advice message. The reporting of Rule Id for A2A communication was included via item 52 of Change Request T2S-0341-SYS (Correction of typos and minor clarifications on the UDFS v1.2). However, when an instruction entered in the U2A mode via the T2S GUI is rejected/held by a restriction type case one (either CSD validation hold or Rejection, Positive or Negative) the Rule Id is not provided in the screen. The CRG member introducing the issue indicated that this may not be a problem for wave 1 CSDs as there may not be many restriction rules configured by wave 1 CSDs. However, the go-live of wave 2 will add many new restriction rules and therefore the GUI users will be at loss to reconcile the rejection reasons within their system. The CRG member also indicated that the workaround of providing clients with a separate list of rule IDs, restriction type and the rule parameters would also be impossible to be implemented due to unavailability of the Rule Id for the GUI users and therefore requested to consider the change for release 1.1. The 4CB indicated that the current U2A behaviour is general for all rejections (i.e. to display business rule and error text) and does not consider displaying any additional fields for reporting of the fulfilled Rule Id of a case one restriction. The CRG noted that the U2A provided no information about the rule which was applied for rejection/hold and thus the user of the U2A was practically at a loss when trying to reconcile. There was agreement that the U2A was not included in a previous CR where information was foreseen in the A2A. This issue is also covered with the current drafting of the new CR T2S-0525-SYS (Provide Restriction Type name in reason code in due to MSRT). Some CRG members were of the opinion that the Change Request should be foreseen for Release 1.1 already. The 4CB reminded the maximum content of Release 1.1 is already agreed and this Change Request could be a candidate for Release 1.2. A CRG participant proposed having a two-step approach: the first part for Release 1.2 (i.e. include the Rule ID in the GUI) and the fully fledged change for a later stage (i.e. Release.2). The CRG was of the view that without the Rule Id in the GUI in case a settlement instruction is rejected or put on CSD validating hold due to a case one Restriction Type, it is impossible for the user of the GUI to reconcile the underlying reason for the rejection/hold. The 4CB agreed to investigate on whether it is possible to implement something minimum that could be achieved before wave 2 (potentially only having Rule Id in the message of GUI, to have consistency between A2A and U2A), and thereby it would be possible to apply the workaround for the time being. The 4CB will check whether the Rule ID could be added to the GUI in case a Settlement Instruction is rejected due to a Restriction Type, before wave 2. 15

16 UT-PBR-041 (Creation of EoD reports and their interrelation to the SoD - INC164700) The clarification note explains the interrelation between the creation of these EoD reports and the start of day of the next business day. It informs that, as part of the EoD period, the End of Day reporting and statements is the last T2S process of the business day. The provision of the generated reports is not a pre-requisite to close the T2S business day. The CRG acknowledged that the current implementation of SoD processing is dependent on the creation of the EoD reports and not dependent on provisioning of these reports which is carried by the interface and subsequently by the network. The 4CB also informed that the EoD reporting correctly considers the positions and transactions for current business day when the reports are created. A CRG member highlighted that the EoD reports are required by CSD to initiate the corporate actions and send the CA related settlement instructions to T2S for the night-time settlement. It would therefore be unacceptable to start the SoD process in T2S if the reports are not available to the CSDs as the SLA is not met. The ECB informed that this could happen in abnormal situation (e.g. delay at the network service provider side) which might delay delivery of reports to T2S actors. Therefore, this should be a topic for the OMG to consider the situation to be handled by the settlement managers. A CRG member indicated that if the business continuity is at stake, then we may also reconsider the T2S behaviour. However the topic of business continuity is in the remit of the OMG. Another CRG member highlighted that the topic on provisioning of EOD reports was discussed extensively during 2010 meetings when requirements for schedule of settlement day was being finalised. Since T2S has correctly created all the reports and statements for given business day, from the functional point of view, it did not make sense to stop subsequent processing in T2S. The ECB also informed that, after the EoD reports are created in T2S, T2S triggers change of business day as first step of SoD process and highlighted that the Night time settlement processes are executed later in the T2S schedule of settlement day. Another CRG member also indicated a preference to have discussion in the OMG on this topic. The OMG could analyse abnormal scenarios when the reports at the end of day were received later than expected by the end recipients in the context of business continuity. The CRG acknowledged that the creation of end-of-day reports is in line with the Schedule of the Settlement Day defined in the UDFS (i.e. T2S triggers the Start of Day (SOD) process once the EOD reports are created in T2S). The CRG was of the view that the OMG could analyse abnormal scenarios if the reports at the end of day were received later than expected by the end recipients (e.g. due to T2S Network provider issue) in the context of business continuity. The ECB will ask the OMG to analyse abnormal scenarios if the reports at the end of day were received later than expected by the end recipients (e.g. due to T2S Network provider issue) in the context of business continuity. 16

17 UT-PBR-042 (Clarification Note on Pagination in particular for reda.012) The note explains the current T2S implementation for pagination in the context of an incident INC in the pre-migration environment in which a part of query response could not be sent to the T2S as it exceeds the maximum size of 32 MB. In this particular incident, T2S attempted sending a reda.012 message as query response which had exceeded the maximum size of 32 MB. Although the query response was split in several parts, one part exceeded the maximum size of 32 MB and therefore this part could not be sent to the T2S Actor. The 4CB explained that pagination is done for the first repetitive block in a message and therefore pagination is not applied to supplementary block in the message reda.012 which contains MSA values. The note also provides two proposed measures to avoid this situation: (i) use of compression, which is applicable for xml messages which are not subject to pagination (e. g. semt.027, semt.040) as well as for messages which may be subject to pagination (e. g. reda.012); (ii) query securities static data using the selection criterion Issue Date, to ensure that the size of query response remain under the critical volume The 4CB agreed to analyse potential options to include all MSAs in the query/report messages including a CRG member s proposal to do the breakdown by the first element of the Market Specific Attributes Report, which is the Financial Instrument Market Specific Attribute (FinInstrmMktSpcfcAttr). The CRG agreed that, before taking any decision, a further analysis of potential options to include all MSAs in the query/report messages is required. In addition, the SGMS needs to be consulted on the different options before the CRG discussion. The CRG also took note of the two workarounds for use in the meantime (i.e. compression and query by issue date). The 4CB will analyse potential options to include all MSAs in the query/report messages including a CRG member s proposal to do the breakdown by the first element of the Market Specific Attributes Report, which is the Financial Instrument Market Specific Attribute (FinInstrmMktSpcfcAttr). The SGMS will be consulted on potential options to include all MSAs in the query/report messages and revert back to the CRG. 17

18 7. Change of decimals for SUM of a security The 4CB provided a clarification that when a CSD changes the Settlement Unit Multiple (SUM) of a security defined in units, and the new SUM (i.e. SUM2) has a different number of decimals than the old SUM (i.e. SUM1), then T2S will settle instructions but potentially increase or decrease the existing securities positions held in the securities accounts in T2S automatically. In order to avoid this situation, the CSD should remove the positions before this type of change in the SUM and replace them after. It was it is recommended in the CRG meeting in September 2014, that CSDs define the SUM with the relevant number of decimals able to cope with future denominations. The CRG was of the view that an update of a static data object should never trigger the increase or decrease of the securities positions in T2S automatically. Therefore, the CRG expressed that there should be an immediate/ short-term solution to prevent SMEs from changing the decimals in the SUM of security as well as preventing the change of an ISIN (topic under agenda item 11). The solution already proposed at functional level by the 4CB to make mandatory the usage of the maximum number of 9 decimal digits for SUM, is the quickest solution for the time being. A CRG member commented that the mandatory use of 9 decimals digits for defining the SUM will leave less number of digits for integer value for securities positions. The 4CB agreed to clarify what an increase of the number of decimal to 9 digits could mean from a T2S Actor s perspective (e.g. how many integers remain available, how the decimals will be shown in screens and A2A reports/queries, etc.) A CRG member of wave 2 stated that they would not go live with these functionalities, which are a great source of operational risk. The CRG agreed that a fully-fledged solution in the long/medium-term should also be analysed. The 4CB agreed to analyse the way forward of a short-term solution (a change to T2S) to prevent a change to the SUM/decimals. For the long/medium-term solution, the 4CB agreed to draft a Change Request. Considering the criticality of the issue, the CRG was of the opinion that this topic could be discussed in the July Task Force meeting scheduled on 10 July 2015 and that a settlement manager s call is required as soon as possible. The 4CB will analyse the way forward of a short-term solution (a change to T2S) to prevent a change to the SUM/decimals. The 4CB will draft a Change Request for the long/medium-term solution. The 4CB will clarify what an increase of the number of decimal to 9 digits could mean from a T2S Actor s perspective (e.g. how many integers remain available, how the decimals will be shown in screens and A2A reports/queries, etc.) 18

19 8. Optimisation of T2S GUI use The ECB explained that the suggestions/proposal made by CRG members were categorised as usability and functional optimisation of T2S GUI use. As a way forward, the 4CB agreed to do a preliminary analysis on the proposals received for functional optimisation of T2S GUI use with a focus on those that have a greatest benefit to the optimisation of the GUI and the least implementation impacts. The 4CB agreed to provide the outcome of this analysis in the next CRG meeting of September Action point: The 4CB will provide the outcome of their analysis on the CRG member s proposals received for functional optimisation of T2S GUI use in the next CRG meeting of September Feedback received from the Sub-group on Message Standardisation (SGMS) Migration of T2S messages to the latest versions following ISO CRs Differences in the Securities Transaction type codes supported by different settlement related messages These topics could not be discussed due to lack of time and it will be discussed in the next CRG telco/meeting. The CRG feedback will be collected via a written procedure after the meeting. 10. Potential Change Requests T2S Release 2 This topic could not be discussed due to lack of time and it will be discussed in the next CRG telco/meeting. It was highlighted that discussions on the scope of Release 2.0 could start after there is clarity about the impact of the CSDR RTS proposals which will be submitted with delay by ESMA to the European Commission end of September 2015 (originally scheduled for June 2015). 11. Any other business The ECB also informed that the CRG meeting has been rescheduled to 29 October 2015 instead of 8 October 2015 as informed earlier. Presentation on ISIN change functionality the way forward The CRG acknowledged that the use of ISIN change functionality by SME will result into undesirable impact on the securities holdings in T2S. The 4CB agreed to analyse the way forward (a change to T2S) to prevent a change to the ISIN change functionality along with the analysis to prevent the change of number of decimals for SUM. The 4CB will analyse the way forward (a change to T2S) to prevent a change to the ISIN change functionality. 19

20 Clarification note Availability of generated reports in T2S This topic could not be discussed due to lack of time and it will be discussed in the next CRG telco/meeting. The CRG feedback will be collected via a written procedure after the meeting. Change Request T2S-0447-SYS (Apply Static Data changes immediately in production) The aim of the Change Request is to provide tools to the T2S Operator to perform the required actions in order to correct with immediate effect errors in the set-up of Static Data objects by the T2S Actors. The CSDs and Central Banks will be in charge of ensuring the consistency of dynamic data as part of the relevant operational procedure. Some CSDs have raised in various forums their concerns about the implementation of Change Request T2S-0447-SYS with regards the need to stop the settlement when applying this Change Request. More specifically the discussions held in the context of the CSG Task Force for migration of Monte Titoli agreed to discuss these concerns in the CRG forum. The 4CB explained that the need to update some static data intraday by the Change Request T2S SYS is due to the complex design of T2S. The T2S is designed to cater a high complexity of functionalities which uses static data on real-time basis across different T2S modules as well as high performance requirements for settlement. Revisiting the way to meet the user requirements underlying this Change Request would need to reconsider the design of the settlement engine and such a tremendous impact needs to be considered against (i) the actual business needs underlying CR 447 (ii) the actual functioning of CR447 when being exceptionally used. The CRG acknowledged that with CR 447, a tool is available in T2S to handle a crisis situation and that for most static data changes it will be sufficient to wait until the next day for them to become effective. However, the opinion of some CRG members was that there may be more frequent cases where a CSD cannot wait for a next day to trigger an immediate change to static data and it may not be practical to initiate a crisis situation (and thereby stop the settlement engine). The CRG agreed to check with the OMG for which updates of static data objects, the OMG considers that it is not possible to wait for the next day for them to become effective and initiating a crisis situation (stopping the settlement engine) is not a feasible option. The CRG will check with the OMG for which updates of static data objects, the OMG considers that neither initiating a crisis for an immediate update (stopping settlement) nor waiting for the next day for the update are feasible options. 20