general information (origin of request) institute: date ... · audit trail query’ query type in...

General Information (Origin of Request) User Requirements (URD) Other User Functional or Technical Documentation (SYS)

Request raised by: CSD Steering Group (CSG) Institute: CSD Date raised: 21/10/2015

Request title: 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.

Request ref. no: T2S 0560 SYS

Request type: Common Urgency: Normal

1. Legal/business importance parameter: Medium 2. Market implementation efforts parameter: Low

3. Operational/Technical risk parameter: Low 4. Financial impact parameter: Medium

Requestor Category: CSD Status: Authorised at Steering Level

Reason for change and expected benefits/business motivation:

The CSG Task-force (TF) on insolvency proceedings has been focusing on two deliverables:

i. the elaboration of a Collective Agreement that sets out inter alia the legal rights and obligations of the T2S CSDs and T2S NCBs arising in connection with the harmonised definition of the moment of entry and irrevocability of transfer orders which are subject to matching

ii. the definition of high-level procedures and principles to handle the insolvency of a participant in T2S, be it a CSD participant or a central bank’s participant and the subsequent reporting requirements.

During the discussions on the insolvency procedures, it has been identified that, while T2S offers reporting functionalities by means of queries and status advices to comply with reporting requirements, current reporting mechanism is deemed inadequate and operationally cumbersome in the context of insolvency. Indeed, in the current T2S functionality, retrieving the accepted (SF1) and matched (SF2) timestamps for impacted settlement instructions is a 2 step process:

• Impacted settlement instructions need to be retrieved using the semt.026 ‘Settlement Instruction Status Audit Trail Query’ query type in A2A or ‘Settlement Instructions – Search/List Screen’ in U2A (see section 2.2.2.17 of UHB v2.0). Among other parameters, search criterion instruction status type ‘accepted’ or ‘matched’ between specific timestamps or equal to a timestamp can be used. This query retrieves all the instructions filtered according to the specified criteria, e.g. accepted (SF1) and matched (SF2) statuses within the specific time window, but not the actual SF1/SF2 timestamps

• For each settlement instruction impacted, SF1 and SF2 timestamp information is retrievable using the query ‘SecuritiesTransactionStatusQuery’ sese.021 in A2A (audit trail details of a settlement instruction), or either ‘Status History - Details Screen’ or ‘Revisions/audit trail – list screen’ in U2A (settlement instruction details)

In A2A, CSDs have the possibility to save and automate the queries on their legacy platform (i.e. use the output of the first query to feed the second one and prefill most parameters) to reduce the operational effort. In U2A, this is not possible. With message subscription, T2S Actors can also be informed in push mode with the timestamp of the generated status advice ‘sese.024’ produced after SF1 (accepted) and SF2 (matched) has been reached for a settlement instruction. However, as this is not the actual SF1/SF2 timestamps as stored in the database but an approximation corresponding to the timing of the messages generation, it cannot be relied on in the context of insolvency proceedings. The means to report the SF1 and SF2 timestamps of settlement instructions impacted by insolvency was discussed in the CRG meeting of 08/09 February 2016 and further 4CB analysis was focused on following 3 possible options during the CRG teleconference of 24 February 2016: Proposed solution 1: Inform SF1 & SF2 timestamp in sese.024 message including the SF1 and SF2 into the sese.024 in a supplementary data field (A2A) Proposed solution 2: In A2A: Include SF1/SF2 exact timestamps in the response message semt.027 – Securities

T2S Programme Office Request: T2S 0560 SYS

2

Settlement Transaction Query Response Proposed solution 3: In U2A: Include SF1/SF2 exact timestamps in the U2A screen in an easy downloadable File format The 4CB indicated high risk and high impact for proposed solution 1 which has also impact on T2S community and cannot be implemented before release 2.0. This solution 1 was preferred by some CRG members but it was understood that it will not be of use to all T2S community members who do not use sese.024 for all participants. The 4CB highlighted that solution 2 involved regression and integration impacts along with changes on community side as well. It does not suit release 1.3 timeline and may not be best to integrate insolvency situations in general use query. The solution 3 involved a separate query mechanism avoiding regression/integration/adaptation issues and was potentially possible to implement in release 1.3 subject to concurrent CR implementations. Based on the 4CB analysis and urgency considerations, the CRG preferred to go ahead with proposed solution 3 to Include SF1/SF2 exact timestamps in new U2A screen in an easy downloadable File format. The CRG also considered that proposed solution 1 could become relevant in the context of CSDR requirements and therefore it could be tackled via separate change request along with other changes for CSDR.

_______________________________________________________________________________________________

Description of requested change: T2S reporting mechanism must be enhanced to retrieve the necessary information in case of insolvency in a simple and standardised way. The following means have been identified during the TF in order to address this requirement:

• Inclusion of SF1/SF2 exact timestamps in the sese.024 message schema • Simplification of queries in A2A/U2A mode in order to retrieve the necessary SF1/SF2 information • Availability of a standardised report

The above-listed solutions are not mutually exclusive. At this stage, option 1 and 3 have been identified as requiring a change of ISO20022 standards which adds further dependency for the implementation of the CR in T2S. Post CRG discussion, proposed solution 3 covering the requirements for U2A reporting is being considered for this CR. Following requirements must be fulfilled for this option. It must be possible to query via a new U2A screen to retrieve the SF1/SF2 timestamps. The query search parameters should allow to retrieve the SF1 and SF2 timestamps in an efficient and flexible way to cover retrieving the SF1/SF2 timestamps for different insolvency scenarios. The query search parameters should therefore contain following search criteria fields

• Securities account number OR Dedicated cash account number OR Insolvent Party BIC + Parent BIC ( exclusive OR)

• Accepted From Date and Time (e.g. date and time from when the insolvency procedure was declared) • Accepted To Date and Time (Optional) • Status (Optional, multiple selection possible)

The search parameters should retrieve SF1 and SF2 of all settlement instructions within the party BIC’s data scope, which have been accepted by T2S after the "Accepted From Date and Time" and prior to "Accepted To Date and Time" (in case this parameter is used in the query)". Also, if Insolvent party BIC + parent BIC is used in the search parameter then T2S should retrieve all settlement instructions impacting SACs and DCAs within the party BIC’s data scope. Query criteria based on the DCA parameter should also extract the impacted settlement instructions with the DCA as default DCA. Following output fields should be reported in the U2A list screen

• T2S Actor and T2S reference • Instructing party BIC • Instructing party Parent BIC • Securities movement type • Securities account • DCA number1

1 The DCA must be reported also for cases where the DCA is a default DCA in the reported settlement

instructions.


3

• Currency • ISIN • ISIN description • Accepted Timestamp (SF1) • Matched Timestamp (SF2) • Original quantity • Settlement amount • Settled quantity • Settled amount • Debit/Credit indicator • Status (settlement, matching, cancellation)

The query result should be available to download as csv-file (non ISO 20022), which would also be useful for the regulators.

_______________________________________________________________________________________________ Submitted annexes / related documents:

1. See attachment entitled “Insolvency of CSD/CB participants in T2S” from CSG Task Force (version of 29 October 2015)

2. Presentation on different options. option covering the requirements for U2A reporting is provided in slides

13-14 https://www.ecb.europa.eu/paym/t2s/progress/pdf/tg/crg/crg60/02.t2s_0559-0560_requirements_update.pdf 3. 4CB analysis on feasibility of proposed options for CR-560 http://www.ecb.europa.eu/paym/t2s/progress/pdf/tg/crg/crg63/02.cr560-evaluation_of_proposed_solutions.pdf 4. Attachment to the Change Request T2S-0560-SYS including the draft proposal for the UHB chapter 2.2.2.21

(Insolvency procedure Settlement Instructions – Search/List Screen)

_______________________________________________________________________________________________ Proposed wording for the Change request:

UHB

The following UHB v2.1 sections should be modified: Creation of new sections in the UHB v2.1 in order to describe the new available search and list screens and how to use them. (the wording proposal may be subject to changes/updates during the implementation phase of the Change Request) 2.2.2.21 Insolvency procedure Settlement Instructions – Search/List Screen See attached draft document2. 3.15.5 Monitoring of the Lifecycle of a Settlement Instruction

This business package describes the monitoring of the lifecycle of a settlement instruction.

You can check the status updates during the lifecycle of a settlement instruction once it has

been created in T2S.

To monitor the lifecycle of a settlement instruction, carry out the following business scenarios.

❙ View settlement instruction status history

2 Caveat: This draft proposal may be subject to changes/updates during the implementation phase of the Change Request.

Overview

Business

Scenario

https://www.ecb.europa.eu/paym/t2s/progress/pdf/tg/crg/crg60/02.t2s_0559-0560_requirements_update.pdf

http://www.ecb.europa.eu/paym/t2s/progress/pdf/tg/crg/crg63/02.cr560-evaluation_of_proposed_solutions.pdf


4

❙ View SF1/SF2 timestamps of Settlement Instructions in case of Insolvency situation 3.15.5.2 Retrieval of SF1/SF2 timestamps of Settlement Instructions in case of Insolvency situation See attached document 6.3.3.x Insolvency procedure Settlement Instructions – Search/List Screen

Privilege Privilege Code

Privilege Type

Object Types Screen Criteria

Settlement Instruction Matched and Accepted Status Query Privilege

*Detailed drafting to be provided at a later point in time (Privilege details not available yet) 6.4.2 Insolvency procedure Settlement Instructions – Search/List Screen **Drafting to be provided at a later point in time (BRs applicable not available yet) UDFS

1.6.4.4.3 Query management process

QUERY TYPE INITIATION VIA GUI (U2A MODE)

INITIATION VIA XML MESSAGES (A2A MODE)

Settlement Instruction Audit Trail Query

x x

Settlement Instruction Matched and Accepted Status Query

x

Securities Account Position (History) Query

x x

1.6.5.7.6 Billing Data Collection Process The UDFS section has to be updated to include the new query as service item into table 189 “U2A Queries and Business Items” including definition of a new Business Item TABLE 189 - U2A QUERIES AND BUSINESS ITEMS

Query Name Business Item Settlement Instruction Current Status Query Settlement Instruction Settlement Instruction Matched and Accepted Status Query

Settlement Instruction

Settlement Instruction Query Settlement Instruction

3.3.3.31 BillingReportV01 Update of Excel table for External codes included in section 3.3.3.31 BillingReportV01

_______________________________________________________________________________________________


5

High level description of Impact: _______________________________________________________________________________________________ Outcome/Decisions: * CRG meeting of 15 December 2015 and CRG teleconference on 18 December 2015: The CRG decided to put the Change Request on hold. * CRG meeting on 8-9 February 2016: The CRG put the Change Request on hold and the CRG agreed to consider the Change Request for possible inclusion in Release 1.3 in the next CRG teleconference on 24 February 2016 * CRG teleconference of 24 February 2016: The CRG put the Change Request on hold and agreed to go for option 3, U2A query solution, as a candidate for the Release 1.3. * CRG meeting of 10 March 2016: The CRG recommended the Change Request for detailed assessment. * Advisory Group on 24 March 2016: In a written procedure from 18 to 24 March 2016, the Advisory Group was in favour of launching the detailed assessment on the Change Request. * CSD Steering Group on 29 March 2016: In a written procedure from 18 to 29 March 2016, the CSD Steering Group was in favour of launching the detailed assessment on the Change Request. * CRG teleconference on 17 June 2016: The CRG agreed to make some updates on the Change Request. * CRG teleconference on 29 July 2016: The CRG agreed to make some minor changes in the Change Request. The CRG recommended the approval of the updated Change Request and its inclusion in the T2S Release 1.3 in principle subject to the positive outcome of the CRG written procedure on the updated Change Request. * CRG on 19 August 2016: During the written procedure from 16 to 19 August 2016, the CRG agreed with the updates made on the detailed assessment and the revised cost assessment. * OMG on 26 August 2016: During a written procedure from to 19 to 26 August 2016, the Operations Managers Group did not identify any blocking operational impact of the Change Request. The OMG was in favour of adding the Change Request to Release 1.3.

* Advisory Group on 1 September 2016: Following a written procedure from 12 to 18 August 2016, the AG was in favour of approving the Change Request. * CSD Steering Group on 2 September 2016: Following a written procedure from 12 to 19 August 2016, the CSG adopted the resolution to approve the Change Request. * Advisory Group on 20 September 2016: Following a written procedure from 14 to 20 September 2016, the AG was in favour of inclusion of Change Request in T2S Release 1.3. * CSD Steering Group on 21 September 2016: During the CSG meeting on 21 September 2016, the CSG adopted the resolution to include the Change Request in T2S Release 1.3.


6

EUROSYSTEM ANALYSIS – GENERAL INFORMATION

Impact On T2S

Static data management Interface Party data management x Communication Securities data management Outbound processing T2S Dedicated Cash account data

management Inbound processing

Securities account data management x Rules and parameters data

management

Settlement Liquidity management Standardisation and preparation to

settlement Outbound Information Management

Night-time Settlement NCB Business Procedures Daytime Recycling and optimisation Liquidity Operations Daytime Validation, provisioning &

booking LCMM

Auto-collateralisation X Instructions validation Status management Operational services Instruction matching Data Migration Instructions maintenance Scheduling Statistics, queries reports and archive x Billing Report management Operational monitoring x Query management x Statistical information Legal archiving All modules (Infrastructure request) No modules (infrastructure request) Business operational activities Technical operational activities

Impact on major documentation Document Chapter Change Impacted GFS chapter

n/a

Impacted UDFS chapter

1.6.4.4.3 Query management process 1.6.5.7.6 Billing data collection process Table 189 Section 3.3.3.31 BillingReportV01 Annex UDFS chapter 3.3.3.31.2

New query has to be added to the table 180“Availability of Queries in U2A mode”. New query has to be added to the table 189 “U2A Queries and Business Items” including definition of a new Business Item Update of Excel List for External Codes in order to include new Service Items. Available under the following link: http://www.swift.com/mystandards/T2S/camt.077.001.01_T2S

Additional deliveries for Message Specification

Update Excel List for External Codes for camt.077

UHB

2.2.2.21 Insolvency procedure Settlement Instructions – Search/List Screen 3.15.5.2 Retrieval of SF1/SF2timestamps of Settlement Instructions in case of Insolvency situation 6.3.3.x Insolvency procedure Settlement Instructions – Search/List Screen

Creation of the relevant new sections of the UHB to describe the behaviour and specifications of the new screens


7

6.4.2 Insolvency procedure Settlement Instructions – Search/List Screen

External training materials

Other documentations

Overview_basic-complex_queries

Links with other requests Links Reference Title OVERVIEW OF THE IMPACT OF THE REQUEST ON THE T2S SYSTEM AND ON THE PROJECT Summary of functional, development, infrastructure and migration impacts The new query “Settlement Instruction Matched and Accepted Status Query” has to be introduced throughout the different documentation. In case of 4-eyes-principle, please note that the Acceptance Timestamp SF1 will only be set for Settlement Instructions which were approved by the 2nd user. The new screen will only show Settlement Instructions which are approved (I. e. instructions which are awaiting approval, rejected or revoked will not be included in the query result. Otherwise the T2S Actor could not differentiate in the list between accepted and not accepted instruction.) The new query should be used only for insolvency procedures in order to avoid performance issues stemming from excessive use of the query. Therefore, the query should only be available when T2S is “under insolvency status”. Two new screens need to be created in the T2S GUI in line with the CR requirements. Three new Service Items will be created for the query so that it is subject to Billing. LTSI must be amended in order to consider the new service item “Settlement Instruction Matched and Accepted Status Query”, according to http://www.swift.com/mystandards/T2S/camt.077.001.01_T2S. Additionally, LTSI must be amended in order to provide to advanced users the possibility to query SF1 and SF2 timestamps related to their settlement instructions, retrieved through Settlement Status History, and via free queries but not via predefined queries. The new Screen/Query as well as the correct Billing have to be tested. Also LCMM data model should be changed in order to make available to the queries the validation timestamp. Summary of project risk No Security analysis No potentially adverse effect was identified during the security assessment.

http://www.swift.com/mystandards/T2S/camt.077.001.01_T2S


8

DG - MARKET INFRASTRUCTURE & PAYMENTS MARKET INFRASTRUCTURE MANAGEMENT

ECB-PUBLIC

16 August 2016

Cost assessment on Change Requests

T2S-560-SYS – 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.

One-off

Assessment cost* - Preliminary 2,000.00 Euro - Detailed 10,000.00 Euro

One-off Project phase costs 283,445.06 Euro

Annual Operational costs 27,797.54 Euro

*The relevant assessment costs will be charged regardless of whether the CR is implemented (Cf. T2S Framework Agreement, Schedule 7, par. 5.2.3).

Insolvency of CSD/CB participants in T2S

CSG Task Force

Version 29th October 2015

ECB-UNRESTRICTED

Rubric

www.ecb.europa.eu ©


2

ECB-UNRESTRICTED

1

2

3

Scenarios

Toolbox available in T2S

Legal and operational requirements

4

5 Overall steps

Mapping toolbox to Scenarios

Overview

6 Known limitations in the present set-up

7 Possible change request

8 Appendix

Rubric

www.ecb.europa.eu © 3

Requirements

Legal requirements (stemming from SFD):

• Transfer orders instructed by the insolvent party or on its behalf and intended to debit the account of that insolvent party:

• shall be processed in accordance with the system rules if “entered” (i.e. SF1) before the insolvency;

• can be processed according to the system rules even when “entered” after the opening of insolvency proceedings provided that such orders i) were matched on the T2S platform (i.e. SF2) before the operator(*) becomes aware of the insolvency and ii) are settled within the same business day;

• shall not be presented for settlement (i.e. no SF3) if received after the system operator becomes aware of the insolvency;

• (in some jurisdictions) can be processed according to the system rules even when entered after the opening of insolvency proceedings upon instruction of the insolvency liquidator.

• The solvent party retains all its rights in accordance with the system rules. In particular the processing of instructions from the solvent party shall not be affected by the insolvency of the other party.

Operational requirements:

• Ideally simple procedures allowing short reaction time and limiting operational risk.

• The procedure shall not block the reimbursement of auto-collateralisation and automatic cash sweep.

• New instructions received after the moment the operator becomes aware of the insolvency shall be rejected before reaching validation and matching.

• Adequate and standardised reporting mechanism for transactions pertaining to moment of entry (SF1) and moment of irrevocability (SF2) shall be made available to the CSD/NCB system operators and/or to address requests from the insolvency liquidator/regulator.

ECB-UNRESTRICTED Insolvency of CSD/CB participants in T2S

(*) The term “operator” always refers to CSD/CB operator unless stated otherwise

Rubric



4

ECB-UNRESTRICTED

1

2

3

Scenarios



4

5 Overall steps


Overview



8 Appendix

Rubric


SFD requirements: scenarios definition


5

No Description Applicable rule Comment

1 Transfer orders entered before the opening of insolvency proceedings

No action to be taken (i.e. to be processed according to system rules)

The solvent party retains all its rights in accordance with the system rules

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

No action to be taken; cancellation if unsettled at the end of the day of insolvency

If unsettled at the end of the day, shall be put on hold for a later cancellation by the operator(s)

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

To be immediately 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

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

To be immediately cancelled 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.

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)

To be processed according to system rules

Only applicable in some national jurisdictions. Will be using an exception to the rejection rules foreseen under scenario 6

6 Transfer orders entered after the moment the operator becomes aware of insolvency proceedings without involvement of the insolvency liquidator

To be rejected

ECB-UNRESTRICTED

Rubric


SFD requirements: time representation

Time of the opening of the insolvency proceedings

Time the CSD/NCB system operator is made aware

SF1

SF1 SF2

No action to be taken (i.e. to be processed according to the system rules)

SF1 SF2

SF1 SF2 (*)

SF1

SF1(*)

No action to be taken Cancellation if unsettled at the end of the day of insolvency

ICS = current BD

To be immediately put on hold for a later cancellation by the operator(s) ICS > current BD

To be immediately cancelled

To be processed according to the system rules

To be rejected

Requested by the insolvency liquidator

Not requested by the insolvency liquidator

t End of 1st business day of insolvency

Insolvency of CSD/CB participants in T2S Sc

enar

io

1 Sc

enar

io

2 Sc

enar

io

3 Sc

enar

io

4 Sc

enar

io

5 Sc

enar

io

6

(*) This step is not supposed to occur

ECB-UNRESTRICTED

Rubric


Scenario 6 Scenario 5 Scenario 4 Scenario 3 Scenario 2 Scenario 1

7

Entered before

insolvency?

No action to be taken (i.e. to be

processed according to the

system rules)

Entered before made

aware ?

No action to be taken. Cancellation if unsettled at the end of the day of insolvency

To be rejected

To be immediately cancelled

Yes Yes

Yes

No

No

SFD requirements: decision tree

No Requested by the liquidator?

To be processed according to the system rules

Yes

No

Settlement day = day of insolvency?

To be immediately put

on hold for a later cancellation

Matched before made

aware ?

Yes

No

Insolvency of CSD/CB participants in T2S ECB-UNRESTRICTED

Rubric


Application to cross-system transactions

ECB-UNRESTRICTED

What are the relevant reference times? The time when participant A is declared insolvent and the time when CSD A operator is made aware

What are the relevant system rules? The rules of the CSD A system

What are the impacted instructions? The instructions submitted by participant A (or on its behalf) to CSD A for the debit of SAC 1 The counterparty instruction from participant B on SAC 2 is not directly affected by the insolvency


(*)Similarly, if a DCA holder of NCB (e.g. participant D) is insolvent, the time of NCB becoming aware, the system rules of NCB D are relevant and all transfer order debiting the DCA 2 are impacted.

Up to 4 systems (CSD A&B and NCB C&D) may be involved in a cross-border DvP.

Let’s assume for instance(*) the insolvency of participant A in CSD A…

DCA 2 NCB D

Payment Bank D

SAC 2 CSD B

Participant B

DCA 1 NCB C

Payment Bank C

SAC 1 CSD A

Participant A

SAC-DCA link

SAC-DCA link

DvP instruction with ‘insolvent’ Part. A of CSD A

Counterparty RvP instruction with Part. B of CSD B

Rubric



9

ECB-UNRESTRICTED

1

2

3

Scenarios



4

5 Overall steps


Overview



8 Appendix

Rubric



ECB-UNRESTRICTED

T2S provides T2S Actors the tools to revoke access on specific insolvent securities accounts/DCAs (object privileges) or on all accounts (system privileges) from roles, users and parties in U2A mode only


I. Revoke Privileges functionality

o CSDs could block the communication of all the users belonging to the insolvent party by deleting the certificate DN for each user separately

o Alternatively, a CSD could revoke(*) access from the users of the CSD participant, using a CSD participant user linked to a certificate DN belonging to the CSD

o Revoking a system privilege (e.g. ‘Send New Settlement Instruction/Settlement Restriction on Securities either on a Securities Account or on Behalf of an external CSD’) from the user, results in the user no longer being able to use the function linked to that privilege.

o Revoking a system privilege from a role, results in the removal of the privilege from the list of privileges linked to the role. Consequently, all the other roles, users and parties linked to the role will no longer be able to access the function linked to that privilege.

o Revoking a system privilege or an object privilege from a party, T2S applies a cascade(**) effect. This results in the removal of the privilege: o from the list of privileges linked to the party and o from the list of privileges linked to all the roles and users of the party.

o Alternatively, privileges with Deny# option could be granted to the insolvent party/users individually to revoke access to a single securities account/DCA.

(*) Refer to the steps explained in the UHB under section ‘3.2.2 Configuration of a Privilege (Two-Step Approach) to be followed for revoking privileges. (**) The cascade effect is deferred to the EOD. In case it is needed immediately, there will be a possibility defined in the T2S MOP to request the T2S Operator to trigger

this immediately (#) The revoke privilege functionality using ‘DENY’ will be simplified with CR554 (planned for Release 1.2)

Rubric



ECB-UNRESTRICTED

II. Usage of case one and case two restriction types / rules

Case One Restriction

Type

o Apply at business validation level on Settlement Instructions/Restrictions, i.e. as soon as instructions enter T2S for initial processing

o “Reject” or put on “CSD Validation Hold”. The latter is an automatic putting on hold, does not prevent matching)

o Rule-based configuration (obligation) through a set of parameters with the possibility to define exceptions (positive/negative parameter set)

o May use Market Specific Attributes (custom static data field defined on parties, securities accounts, or securities)

o Apply at settlement eligibility level, i.e. on Intended Settlement Date and beyond. Activated on static data objects: “Block” parties, securities, securities accounts, DCAs, RTGS accounts (*)

o Optional to define rules and exceptions through a set of parameters o Cannot use Market Specific Attributes

Case Two Restriction

Type

(*) This results in the restriction of all the T2S dedicated cash accounts linked to the given external RTGS account

Restriction types / rules can be defined in T2S to control settlement flows


Rubric



ECB-UNRESTRICTED

III. Usage of Hold/Release and Cancellation functionality

o CSD needs to put “Yes” in the CSD hold indicator of the maintenance instruction (Hold Instruction) to hold an instruction. Typically used by CSDs for specific actions.

o If the CSD wants to send a Settlement Instruction initially on Hold, the CSD hold indicator must be filled in.

o A Settlement Instruction on Hold can only be released when the relevant CSD sends the corresponding Release Instruction putting “No” in the CSD hold indicator.

CSD Hold

Provides T2S Actors the functionality to hold and release Settlement Instructions, at any time during their lifecycle until they are settled or cancelled

o If the “Hold Release Default” value of the Securities Account is set to “Yes”, the instruction is set automatically On Hold through the Party Hold Status

o In case the Party Hold is activated in the Settlement Instruction, T2S does not check the “Hold Release Default” value in Static Data for the Securities Account(*).

Hold/Release Default

o CSDs can cancel (already matched or matched in T2S) intra-CSD instructions in A2A mode using the message ‘SecuritiesTransactionCancellationRequest’

o In U2A mode the ‘Cancellation Securities Instruction - New Screen’ to be used to input the cancellation instruction

o In case of cross-CSD transaction the instructions will follow bilateral cancellation and require involvement of 2 CSDs.

Cancellation


(*) This behaviour may change in the future with implementation of CR532 ( planned for Release 2)

Rubric



ECB-UNRESTRICTED

T2S query functionality provides T2S Actors means to retrieve Settlement Instructions, pertaining to SF1 and SF2 as required by specific market rules on ad-hoc basis. A2A queries can be tailored and saved for further reuse

o Impacted settlement instructions having reached SF1 and SF2 can be retrieved, using the semt.026 ‘Settlement Instruction Status Audit Trail Query’ query in A2A (see section 3.3.7.12 of UDFS v2.0) or ‘Settlement Instructions – Search/List Screen’ in U2A (see section 2.2.2.17 of UHB v2.0).

o Amongst others parameters(*), search criterion instruction status type ‘accepted’ or ‘matched’ between specific timestamps or equal to a timestamp can be used.

o The query can be automated at the CSD end. The query retrieves all the instructions filtered according to the specified criteria and timestamps.

Settlement Instruction Audit trail

Query

o SF1 and SF2 timestamp information is retrievable using specific queries. o In A2A, using query SecuritiesTransactionStatusQuery sese.021 (see section 3.3.8.2

of UDFS v2.0) retrieve the audit trail details of a settlement instruction. o In U2A, using ‘Status History - Details Screen’ or "Revisions/audit trail – list screen”

(see section 2.2.2.20 and section 2.5.11.1of UHB v2.0) for the settlement instruction details

Status history/ Audit

trail query


IV. Usage of query functionality

(*)Refer to the additional parameters for the A2A query under business rule ‘IIMP124’. Note that for the GUI screen, the field ‘Cancellation status’ with value “Not Cancelled” could be used for SF1 specific instructions.

After acceptance/matching of an SI, T2S provides the timestamp of the sese.024 generation in the real-time status advice. There is a short lapse of time (approx 2-3 sec from EAT data) between the actual acceptance/matching of the SI and the sese.024 generation timestamp. An ISO change would be needed to the sese.024 to include a specific field for reporting the acceptance/matching timestamp

Rubric



14

ECB-UNRESTRICTED

1

2

3

Scenarios



4

5 Overall steps


Overview



8 Appendix

Rubric


Scenario 1

ECB-UNRESTRICTED

Steps:

o No action to be taken (to be processed according to the system rules)


Rubric


Scenarios 2, 3 and 4

ECB-UNRESTRICTED

Steps:

o Retrieve the impacted settlement instructions using the ‘Settlement Instructions – Search/List Screen’ in U2A, OR ‘SecuritiesTransactionStatusQuery’ message in A2A;

o Manual cancellation of SIs (for scenario 4 preferably directly at the time operator is made aware); • In A2A mode, using ‘SecuritiesTransactionCancellationRequest’ message; can be done together by sending a bulk

cancellation request OR; • In U2A mode, using ‘Cancellation Securities Instruction - New Screen’

o By the end of business day all SIs (for scenarios 2 and 3) can be put on hold; • In A2A mode, send settlement modification request to modify the hold indicators to put the relevant instructions on

hold (CSD hold preferably); can be done together by sending a bulk settlement modification request in A2A mode using ‘SecuritiesSettlementConditionModificationRequest’ OR;

• In U2A mode, each instruction must be individually modified, to update the hold indicator using ‘Hold/Release Instruction - New Screen’

o Subsequent or later cancellation of all SIs (for scenarios 2 and 3) that were put on hold

o Retrieve information on the SF1 and SF2 of pending transactions for reporting requirements


Refer to slides 28-29 in the Appendix, for details on tools to retrieve settlement instructions pertaining to SF1 and SF2

Rubric


ECB-UNRESTRICTED

Prerequisites (to be done at time of migration to T2S): The usage of MSA is required so that the rule can be triggered on the day of insolvency. The configuration below can also be performed at party (i.e. CSD participant) level if needed. In normal operating mode, the restriction rules are active and checked but do not apply to any SI.

o Create MSA at securities account level, e.g. “AccountStatus”, with values to be: “Active”, “CSD-Suspended”, “NCB-Suspended”

o Assign a value to each securities account. In normal operating mode, all accounts will have the status “Active”;

o Define following positive restriction rules: • For CSD participant insolvency: If securities movement type = “DELI” and AccountStatus = “CSD-Suspended”, and MSA

configured as “DEBIT”, reject;

• For NCB participant insolvency: if securities movement type = “RECE” and AccountStatus = “NCB-Suspended”, and MSA configured as “CREDIT”, and Credit/Debit indicator = “DBIT”, reject

• For NCB participant insolvency (covers special case of DWP): if securities movement type = “DELI” and AccountStatus = “NCB-Suspended”, and MSA configured as “DEBIT”, and Credit/Debit indicator = “DBIT”, reject

o Define negative restriction rules (exceptions to bypass the rejection) for transactions on behalf of the liquidator, based on e.g. ISO transaction code or the Instructing Party (ideally a standardised exception shall be agreed upon CSDs):

Examples: If AccountStatus = “CSD-Suspended”, and ISO transaction code = TURN, do not reject

If AccountStatus = “NCB-Suspended”, and Instructing Party = BICOFCSDXXX, do not reject

Steps: o When the CSD is made aware of the insolvency, update the impacted account(s) status with the MSA value “Suspended”

All new incoming SIs fulfilling the conditions defined in the positive restriction rules will be rejected at validation in T2S, unless they fulfil the conditions defined in the negative rules


Scenarios 5 and 6

Rubric



18

ECB-UNRESTRICTED

1

2

3

Scenarios



4

5 Overall steps


Overview



8 Appendix

Rubric


Insolvency

Operator made aware

tin taw tcc

SM conference call

• Set auto-collat limit to zero • Delete predefined and standing liquidity transfers orders • Change main PM account

• Retrieve and cancel impacted unmatched settlement instructions (SC4)

All parties confirming readiness

End-of-day

• Query and put on hold unsettled transactions (SC2 and 3)

CS

D s

yste

m

Ope

rato

r C

B s

yste

m

Ope

rato

r

• Apply blocking on insolvent account/party

• Revoke privileges

• Remove blocking on account/party level

• Cancel transactions put on hold

• Update account status to trigger restriction rule (SC 5 and 6)

16:00 DVP cut-off

T2S

Ope

rato

r • Query securities account and DCA links

• Broadcast to all T2S Actors

• Manual cancellation of auto-collat. reimbursement instructions

16:30 Reimbursement auto-collat.

• Manual relocation of collateral


18:00 FOP cut-off

t

• Retrieve info on SF1 and SF2 for pending instructions

ECB-UNRESTRICTED

Rubric



20

ECB-RESTRICTED UPDATABLE

1

2

3

Scenarios



4

5 Overall steps


Overview



8 Appendix

Rubric


Known limitations in the present set-up

ECB-UNRESTRICTED

1. Trigger rejection of SIs based on the insolvency of a DCA holder as required by Scenario 6 is not possible in certain scenarios(*)

a. MSAs cannot be defined for DCAs and used as parameter for the configuration of restriction rules on settlement instructions

Currently, restriction rules with object restriction type SI (Case 1) have to be configured with the securities account (SAC) as parameter. Usage of MSA is also required in order for the restriction rule to be active on the day of insolvency. However, as the relationship between securities accounts and DCAs can be one-to-many, there is a risk to reject more than intended when using MSA on SAC as parameter (see Example 1 of the Appendix). If a securities account is linked to several DCAs, a restriction rule based on “CSD Validation Hold” (see Example 2 of the Appendix) has to be used instead. No existing CR covers this requirement

b. “Default DCA” is only derived at the moment of settlement

Currently, the “default DCA”, i.e. not populated in the SI, is only derived at the time of settlement. Restriction rules that would be based on DCA as parameter (change “a” required) would not be triggered if the DCA is not populated in the settlement instruction. CR 547 foreseen for Release 1.2 covers this requirement

(*) These limitations are relevant in the context of the insolvency of a DCA holder when a securities account is linked to several DCAs belonging to different parties. In other cases, limitations are overcome with the triggering of the rule on SAC level.


Rubric



ECB-UNRESTRICTED

2. Matching (SF2) cannot be prevented in case of insolvency

In the current implementation of the T2S functionality, a SI can be rejected (SF1) or put on hold at the time

of business validation. It is also possible to block settlement (SF3) using specific rules. There is however,

not a possibility to prevent instructions from matching (SF2) in case of need, such as insolvency of a CSD

participant.

This is relevant for scenario 4(*), where the unmatched instructions should be cancelled immediately in

order to avoid further possibility of matching (as once matched, SIs require bilateral cancellation which

may be operationally cumbersome in cross-CSD scenarios). Until then, there could be a risk of matching

and subsequent need for bilateral cancellation even after the status of the SAC has been updated (i.e. to

trigger Case 1 restriction rules on new incoming SIs)

(*) Transfer orders entered after the opening of insolvency proceedings, which were not matched on the T2S platform by the time the operator becomes aware


Rubric



ECB-UNRESTRICTED

3. Tools available for retrieval of SF1/SF2 timestamps of impacted instructions are deemed inadequate in the context of insolvency, i.e. operationally cumbersome

Currently, T2S stores the SF1 (accepted) and SF2 (matched) timestamps for each settlement instruction,

which can be retrieved by means of standard T2S queries. T2S Actors are informed in push mode 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.

Furthermore, the current query functionality available for retrieving the instructions/transactions specific to

each scenario (as described on slide 5), and their related SF1/SF2 timestamps, is perceived to be

inadequate and operationally cumbersome: T2S Actors need to perform several queries to retrieve a

settlement instruction and its specific SF1/SF2 timestamp.


Rubric



24

ECB-UNRESTRICTED

1

2

3

Scenarios



4

5 Overall steps


Overview



8 Appendix

Rubric


Change request(s) to address the identified gaps

ECB-UNRESTRICTED Insolvency of CSD/CB participants in T2S

Requirement 1: It must be possible by one single action per T2S DCA to trigger the rejection of the settlement instructions submitted by the insolvent party or on its behalf and intended to debit the DCA of that insolvent party.

This requirement is seen as a sine qua non condition for the entry into force of the Collective Agreement. It shall therefore have the highest priority.

Requirement 2: In addition to preventing settlement instructions to reach moment of entry (SF1) and

moment of finality (SF3) by means of restriction rules, there must also be a feature in T2S to prevent settlement instructions to from reaching moment of irrevocability (SF2), i.e. matching, in case of insolvency of a CSD participant or DCA holder.

This requirement is not seen as a sine qua non condition for the entry into force of the Collective Agreement. It is seen as an operational risk, which should be covered in the longer run.

Requirement 3: The reporting mechanism must be enhanced to allow the retrieval of the settlement

instructions impacted by insolvency and their related SF1/SF2 timestamps in an efficient and standard way via standardised A2A/U2A query or reports, and/or intimation of the SF1/SF2 timestamps for each settlement instruction by means of the real-time status advice sese.024. This requirement is considered by some members of the Task Force as a pre-requisite for the entry into force of the Collaborative Agreement.

None of these requirements correspond to legal gaps / showstopper. They correspond to functional gaps and aim at simplifying the operational procedures.

Three draft change requests were prepared by the Task Force. If supported by the CSG, they could be worked out by the CRG/OMG.

Rubric



26

ECB-UNRESTRICTED

1

2

3

Scenarios



4

5 Overall steps


Overview



8 Appendix

Rubric


Example 1: Case 1 rejection rule – SAC linked to several DCAs

27

ECB-UNRESTRICTED

DCA1 Payment Bank A

SAC 2 CSD

Participant B

SAC 1 CSD

Participant A

SAC 3 CSD

Participant C

CMB link

DCA2 Payment Bank B

o Payment Bank A is suspended;

o CSD(s) change(s) status of SAC1/2/3 accordingly

from “Active” to “NCB-Suspended”;

o New incoming SIs against payment on SAC 1/2/3

are rejected immediately after the status has been

updated.

All SIs sent on SAC 1/2/3 will be

rejected, even in the case where

the DCA2 belonging to Payment

Bank B is used by CSD participant

C in the transaction.

Rejection rule is not suitable in this

case.


Rubric


Example 2: Case 1 CVAL rule – SAC linked to several DCAs

28

Procedures for insolvency of DCA holders ECB-UNRESTRICTED

DCA1 Payment Bank A

SAC 2 CSD

Participant B

SAC 1 CSD

Participant A

SAC 3 CSD

Participant C

CMB link

DCA2 Payment Bank B

o Payment Bank A is suspended;

o CSD(s) change(s) status of SAC1/2/3 accordingly

from “Active” to “NCB-Suspended”;

o New incoming SIs against payment on SAC 1/2/3

are put on CSD Validation Hold immediately after

the status has been updated.

All SIs on SAC 1/2/3 will

automatically be put on hold, even

in the case where the DCA2

belonging to Payment Bank B is

used by CSD participant C in the

transaction.

All SIs linked to DCA1 must be

manually cancelled; SIs linked to

DCA2 must be manually released

CVAL rule implies additional

operational workload

Rubric


ECB-UNRESTRICTED

o Currently, in the ISO message content of the sese.024 ‘real-time’ status advice message, there is no

specific field* to indicate the accepted (SF1) timestamp of an settlement instruction

o The impacted settlement instructions for SF1 can be retrieved real-time, using the semt.026 ‘Settlement

Instruction Status Audit Trail Query’ query type in A2A (see section 3.3.7.12 of UDFS v2.0) or ‘Settlement

Instructions – Search/List Screen’ in U2A (see section 2.2.2.17 of UHB v2.0) with search criterion

instruction status type as ‘accepted’ between specific timestamps or equal to a timestamp, amongst other

parameters**. The accepted timestamp per SI is not retrieved directly in the query result. For ‘each’ of the

retrieved instruction below queries could be automated to extract the SF1 timestamp.

o The SF1 information for a single instruction is also retrievable using specific queries such as;

In A2A, using query ‘SecuritiesTransactionStatusQuery’ sese.021 (see section 3.3.8.2 of UDFS v2.0)

to retrieve the audit trail details of a settlement instruction

In U2A, using ‘Status History - Details Screen’ or "Revisions/audit trail – list screen” (see section

2.2.2.20 and section 2.5.11.1of UHB v2.0) for the settlement instruction details


Retrieve settlement instructions for SF1

*After acceptance of an SI, T2S provides the timestamp of the sese.024 generation in the real-time status advice. There is a very short lapse of time (approx 2-3 sec from EAT data) between the actual matching of the SI and the sese.024 generation timestamp. An ISO change would be needed to the sese.024 to include a specific field for reporting the acceptance timestamp **Refer to the additional parameters for the A2A query under business rule ‘IIMP124’. Note that for the GUI screen, the field ‘Cancellation status’ with value “Not Cancelled” could be used for SF1 specific instructions.

Rubric


ECB-UNRESTRICTED

o Currently, in the ISO message content of the sese.024 ‘real-time’ status advice message, there is no

specific field* to indicate the matched (SF2) timestamp of an settlement instruction

o The impacted settlement instructions for SF2 can be retrieved real-time, using the semt.026 ‘Settlement

Instruction Status Audit Trail Query’ query type in A2A (see section 3.3.7.12 of UDFS v2.0) or ‘Settlement

Instructions – Search/List Screen’ in U2A (see section 2.2.2.17 of UHB v2.0) with search criterion

instruction status type as ‘matched’ between specific timestamps or equal to a timestamp, amongst other

parameters**. The matched timestamp per SI is not retrieved directly in the query result. For ‘each’ of the

retrieved instruction below queries could be automated to extract the SF2 timestamp.

o The SF2 information for a single instruction is also retrievable using specific queries such as;

In A2A, using query ‘SecuritiesTransactionStatusQuery’ sese.021 (see section 3.3.8.2 of UDFS v2.0)

to retrieve the audit trail details of a settlement instruction

In U2A, using ‘Status History - Details Screen’ or "Revisions/audit trail – list screen” (see section

2.2.2.20 and section 2.5.11.1of UHB v2.0) for the settlement instruction details


Retrieve settlement instructions for SF2

*After matching of an SI, T2S provides the timestamp of the sese.024 generation in the real-time status advice. There is a very short lapse of time (approx 2-3 sec from EAT data) between the actual matching of the SI and the sese.024 generation timestamp. An ISO change would be needed to the sese.024 to include a specific field for reporting the matching timestamp **Refer to the additional parameters for the A2A query under business rule ‘IIMP124’

2.2.2.21 Insolvency procedure Settlement Instructions – Search/List Screen

This screen contains a number of search fields. By inputting the relevant data, you can search for settlement instructions under insolvency situation. The search results will be displayed in a list.

After selecting an entry, you can proceed further by clicking on the buttons below.

This screen will be available for the User in case the Insolvency system parameter is activated.

When exporting the content of this screen, you receive the query result in a csv-file.

This screen is not relevant for CB users.

❙ Securities >> Settlement >> Insolvency procedure Settlement Instructions

To use this screen, you need the following privilege:

❙ Settlement Instruction Matched and Accepted Status Query Privilege

User Instructions Part

This screen is part of the following business scenarios:

❙ Retrieval of SF1/SF2 timestamps of Settlement Instructions in case of Insolvency situation

Business Functionality Document

This screen corresponds to the following business functions:

❙ Query instruction (T2S.GUI.SESE.INX.0010)

❙ Display instruction list (T2S.GUI.SESE.INX.0020)

Note

'Deviations between screenshot and field description might occur due to the screens finalisation process, however the field description is the valid one.'

Context of Usage

Screen Access

Privileges

References

Screenshot

Illustration xx: Insolvency procedure settlement instructions – search/list Screen

Insolvency procedure Settlement Instructions – Search Criteria Insolvent Object Criteria*

Securities Account Number

You can choose to either enter the ‘Securities Account Number’ or to select it from the suggested items in the drop-down menu. Only one of the insolvent object criteria must be filled in: ‘Securities Account Number’, ‘Dedicated Cash Account Number’ or the combination of ‘Insolvent Party BIC’ and ‘Insolvent Parent Party BIC’. In order to query external CSD settlement instructions the search criterion ‘securities account’ must not be filled in. Required format is: max. 35 characters (SWIFT-x) Reference for error message: ❙ QMPC030

Dedicated Cash Account Number

You can choose to either enter the ‘Dedicated Cash Account Number’ or to select it from the suggested items in the drop-down menu. Only one of the insolvent object criteria must be filled in: ‘Securities Account Number’, ‘Dedicated Cash Account Number’ or the combination of ‘Insolvent Party BIC’ and ‘Insolvent Parent Party BIC’. Required format is: max. 34 characters (SWIFT-x) Reference for error message: ❙ QMPC031

Insolvent Party BIC You can choose to either enter the ‘Insolvent Party BIC’ or to select it from the suggested items in the drop-down menu. Only one of the insolvent object criteria must be filled: ‘Securities Account Number’, ‘Dedicated Cash Account Number’ or the combination of ‘Insolvent Party BIC’ and ‘Insolvent Parent Party BIC’.

Field Description

Insolvency procedure Settlement Instructions – Search Criteria If the Insolvent Party BIC is filled in, the Insolvent Parent Party BIC needs to be filled in as well.

Required format is: max. 11 characters (SWIFT-x) Reference for error message:

❙ QMPC032

❙ QMPC084

Insolvent Parent Party BIC

You can choose to either enter the ‘Insolvent Party Parent BIC’ or to select it from the suggested items in the drop-down menu. Only one of the insolvent object criteria must be filled in: ‘Securities Account Number’, ‘Dedicated Cash Account Number’ or the combination of ‘Insolvent Party BIC’ and ‘Insolvent Parent Party BIC’. If the Insolvent Parent Party BIC is filled in, the Insolvent Party BIC needs to be filled in as well.

Required format is: max. 11 characters (SWIFT-x) Reference for error message:

❙ QMPC048

❙ QMPC084

Additional Criteria

Acceptance Date and Time – from

Enter the lower bound of the search range for the acceptance date and time (i.e. SF1: moment of acceptance) or use the calendar icon.

Required format is: YYYY-MM-DD hh:mm:ss

References for error messages:

❙ QMPC015

Only Settlement Instructions successfully created in 4-eyes mode (i.e. approval status = approved) will be considered in the query. Settlement Instructions with other approval status value will not be included in the search results.

Acceptance Date and Time – to

Enter the upper bound of the search range for the acceptance date and time (i.e. SF1: moment of

Insolvency procedure Settlement Instructions – Search Criteria acceptance) or use the calendar icon.



❙ QMPC015

Only Settlement Instructions successfully created in 4-eyes mode (i.e. approval status = approved) will be considered in the query. Settlement Instructions with other approval status value will not be included in the query results.

Matching Status Select the matching status from the possible values:

❙ All (default value)

❙ Unmatched

❙ Matched

Matching Date and Time - from

Enter the lower bound of the search range for the matching date and time (i.e. SF2: moment of irrevocability) or use the calendar icon.



❙ QMPC015

Matching Date and Time - to

Enter the upper bound of the search range for the matching date and time (i.e. SF2: moment of irrevocability) or use the calendar icon.



❙ QMPC015

Settlement Status Select the settlement status from the possible values:


❙ Unsettled

❙ Settled

❙ Partially settled

Cancellation Status Select the cancellation status from the possible values:


❙ Cancelled

❙ Not cancelled

Party Hold status Select the party hold status from the possible values:


❙ On hold

❙ Released

CSD Hold status Select the CSD hold status from the possible values:


❙ On hold

❙ Released

CSD Validation Hold Status

Select the CSD validation hold status from the possible values:


❙ On hold

❙ Released

CoSD Hold Status Select the CoSD hold status from the possible values:


❙ On hold

❙ Released

Insolvency procedure Settlement Instructions - List Actor Reference Shows the reference assigned by the Actor to the

settlement instruction

T2S Reference Shows the reference assigned by T2S to the settlement instruction.

Instructing Party BIC Shows the BIC of the instructing party of the settlement instruction.

Instructing Party Parent BIC

Shows the parent BIC of the instructing party of the settlement instruction.

Accepted Timestamp (SF1)

Shows the accepted timestamp of the settlement instruction.

Matched Timestamp (SF2)

Shows the matched timestamp of the settlement instruction. In case the settlement instruction is unmatched no timestamp will be shown.

Securities Account Number

Shows the securities account number to or from which a securities entry is made.

ISIN Shows the ISIN code of the security.

Securities Description

Shows the description of the security.

Securities Movement Type Code

Shows the securities movement type code from the possible values: ❙DELI ❙RECE

Original Settlement Quantity/Nominal

Shows the quantity of securities to be settled.

Settled Quantity/Nominal

Shows the settled quantity of the settlement instructions.

T2S Dedicated Cash Account Number

Shows the T2S dedicated cash account number stated in the settlement instruction or the default T2S dedicated cash account number in case it was not stated in the settlement instruction.

Debit/Credit Indicator Shows the debit credit indicator related to the cash posting from one of the possible values: ❙DEBIT ❙CREDIT ❙Empty In case the settlement instruction does not contain the debit credit information, no value will be shown.

Currency Shows the currency stated in the settlement instruction.

Settlement Amount Shows the settlement amount as stated in the settlement instruction. In case the Settlement Instruction does not contain the Settlement Amount information, no value will be shown

Settled Amount Shows the total settled amount.

Search This function enables you to start a search according to

the criteria entered. The results are displayed in a list on the next screen.

If the search retrieves a single record, the list screen is also displayed (this differs from the standard U2A behaviour, to access to the details of instruction, the details button must be clicked on).

Next screens:

Buttons

❙ Insolvency procedure Settlement Instructions –

search/list screen


❙ QMPC015

❙ QMPC030

❙ QMPC031

❙ QMPC032

❙ QMPC048

❙ QMPC084

Reset This function enables you to set all fields to default value and blanks out all optional fields

Next screen:

❙ Insolvency procedure Settlement Instructions –

search/list screen

Details This function enables you to display the details of the selected instruction. Next screen: ❙ Settlement Instruction – details screen

3.15.5.2 Retrieval of SF1/SF2 timestamps of Settlement Instructions in case of Insolvency situation

This business scenario describes how to retrieve the SF1/SF2 timestamps of settlement instructions in case of insolvency situation.

Once a settlement instruction is created in T2S it might be necessary for you to retrieve the SF1/SF2 timestamps for insolvency proceedings during the lifecycle of the settlement instruction.

Context of Usage

This business scenario is not relevant for CB users.

To carry out this business scenario, you need the following privileges:

❙ Settlement Instruction Matched and Accepted Status Query Privilege

Further information on screens involved can be found in the screen reference part:

❙ Insolvency procedure Settlement Instructions – Search/List Screen

1. Go to the Insolvency procedure Settlement Instructions – Search/List Screen: Securities >> Settlement >> Insolvency procedure

Settlement Instructions

2. Enter at least one insolvent object criterion known to you to retrieve SF1 and SF2 timestamps of settlement instructions under insolvency procedures.

3. Click on the search button.

A list containing the search results is displayed on the screen.

Alternative

To set all fields to default value and blank out all optional fields, click on the reset button.

Privileges

Reference

Instructions

general information (origin of request) institute: date ... · audit trail query’ query type in...

Documents