USER REQUIREMENTS CHAPTER 5 LIFECYCLE MANAGEMENT AND MATCHING REQUIREMENTS

Transcription

1 USER REQUIREMENTS CHAPTER 5 LIFECYCLE MANAGEMENT AND MATCHING REQUIREMENTS T2S project Team Reference: T2S Date: 15 November 2007 Version: 1 Status: Final

2 TABLE OF CONTENT 5 Lifecycle Management and Matching Requirements High-level description of Lifecycle Management and Matching Lifecycle Types...9 Table: Lifecycle Types Validation Validation of incoming settlement instructions Re-validation of instructions due to update of static data Instruction maintenance Hold and release mechanisms Amendment of instructions Cancellation of instructions Matching Requirements related to Matching Mandatory matching fields Additional matching fields Settlement eligibility Requirements related to settlement eligibility Transaction Types...34 Table: Plain Vanilla...35 Table: Special...37 Table: Collateral Related...39 Table: Conditional...41 Table: Corporate Events Related...43 Version: 1 Page 2 of 44 Status: Final

3 5 Lifecycle Management and Matching Requirements After the interactions between the T2S actors and the T2S system in a single timeframe as well as the business roles of the T2S actors, assets, currencies and transaction types involved in this centralised settlement procedure in Euro central bank money have been presented, it is time to focus on the instructions, which T2S actors will send to the T2S system to settle their market operations, and on how these instructions are handled within T2S. Therefore, the objective of this Chapter is to analyse the lifecycle of an instruction, the different paths through the system that it can take, and the related lifecycle status attached to these paths (validated, rejected, matched, unmatched, etc.). The Chapter consists of 7 Sections with the following contents. Firstly, Section 5.1 gives a high level overview of the different implicated processes along the Lifecycle. Sections 5.2 and 5.7 present the different Lifecycle types and transaction types that define the way followed by the instructions according to different attributes. Section Validation - describes the checks that the incoming instructions have to pass to be valid for T2S mainly consistency and authorisations checks. Section Instruction maintenance - covers the different cases and ways of affecting a previously sent instruction. Section Matching - analyses in depth the procedure to ensure that the counterparties agree on the terms of the transaction. Finally, Section Settlement eligibility - identifies the conditions that the instructions have to fulfil to become eligible for settlement. Version: 1 Page 3 of 44 Status: Final

4 5.1 High-level description of Lifecycle Management and Matching The Lifecycle management and matching function consists of the four main processes Validation, Instruction Maintenance, Matching and Settlement Eligibility and the Communication function, which are illustrated in the following context diagram and described below (see Overall Context Diagram in chapter 2): T2S Settlement Instruction Lifecycle Management and Matching CSD Maintenance Instruction Status Messages Query/ Response Settlement Instruction Maintenance Instruction Validation Status Message 1.1 Validation Information Static Data Ready to be matched Maintenance Instruction Already matched Settlement Instruction Status messgaes Maintenance Instruction Query/ Response T2S Interface Matching Status Message Allegments 1.3 Matching Matched instruction 1.4 Settlement Eligibility Maintenance Instruction 1.2 Instruction Maintenance Status update Instruction maintenance status message T2S Party Query Response Settlement Status Message D.1 Instruction 1.5 Communication Settlement Transaction Settlement Instruction Maintenance Instruction Status messages Settlement Status Messages Status update New Settlement Instruction Unsettled Transactions Query/Response Settlement Version: 1 Page 4 of 44 Status: Final

5 1.1 Validation Validation is the process of checking the consistency of instructions sent to T2S. These consistency checks 1 ensure that the incoming instruction is in line with T2S static data. Incoming instructions may be ready to be matched, already matched or with matching not required. Validated instructions are then forwarded either for matching or for settlement eligibility. All incoming instructions received during the opening day shall be immediately validated in T2S following a harmonised set of validation rules. After validation, the status of the instruction becomes either "accepted" or "rejected". Input Settlement instruction Maintenance instruction Information From CSD or directly connected T2S Party From CSD or directly connected T2S Party Information from Static Data Output Information Validation status message Settlement instruction Maintenance instruction Already matched/matching not required instruction Status update Asking Static Data for information needed to validate Responses to CSD/directly connected T2S Party regarding instruction status ( Accepted or Rejected ) Accepted settlement instruction forwarded to Matching function. Forwarding to Instruction Maintenance Forwarding to Settlement Eligibility function. Status update in the instruction database. 1 Validation must be distinguished from the format and syntax checks which are performed by the interface module before instructions entering the Lifecycle Management. Version: 1 Page 5 of 44 Status: Final

6 1.2 Instruction maintenance Instruction maintenance shall consist of amendments, cancellations, hold and release of a settlement instruction. Amendment of matching fields will be made possible before matching and amendment of non-matching fields and process indicators will be possible until actual settlement occurs. CSD participants shall be able to cancel instructions unilaterally prior to matching. Once matched, instructions can only be cancelled bilaterally, i.e. both parties have to send a cancellation instruction (binding matching). On the receipt of the one counterpart s cancellation instruction, allegement messages will be sent to the other counterpart. CSDs, CCPs Stock Exchanges and trading platforms shall be able to unilaterally cancel instructions generated by them, under their Power of Attorney at any time unless they have been settled. T2S shall provide hold and release mechanisms. T2S parties and CSDs may use these mechanisms on a voluntary basis. These mechanisms allow T2S parties and CSDs to hold or release instructions prior to settlement. Input Maintenance instruction Maintenance of instruction from Validation function Output Instruction maintenance Maintenance Instruction status message Status update Amending, cancelling or holding/releasing instructions Status message to CSD/directly connected T2S Party after the attempt of doing maintenance to the instruction. Status update of the Instruction database. 1.3 Matching Matching is normally defined as the process used for comparing the settlement details provided by the buyer and the seller of securities in order to ensure that they agree on the terms of the transaction. T2S shall provide real-time matching facilities throughout the whole operating day. Following matching, the status of the instruction shall become "matched" or "unmatched T2S shall provide information to the instructing parties on the result of the matching process. Matched instructions shall remain matched until actual settlement occurs. If unmatched, T2S shall provide information on the reasons to the counterparties together with allegement facilities. Input Accepted settlement instruction From Validation function Version: 1 Page 6 of 44 Status: Final

7 Output Matching status message Matched instruction Status update Allegements Matching status message to CSD/directly connected T2S Party. Forwarding matched instruction to the Settlement Eligibility function. Status update in the instruction database. If the counterparty s instruction has not arrived. Data Store D.5 Instruction Data store 1) This data store keeps the latest status of an instruction, throughout the lifecycle of an instruction. 2) This status is updated after validation, matching, instruction maintenance and settlement. 3) The status of an instruction can be queried by the instructing party, be it the CSD or the directly connected T2S Party throughout the lifecycle of the trade. 4) In case an auto-collateralisation is triggered for settlement, a new instruction is created. 5) Unsettled settlement instructions which are still eligible for settlement are sent to settlement function for future settlement. 1.4 Settlement Eligibility It is the process of performing the final checks related to settlement date, status of the instruction (on hold or other), etc. before sending an instruction to the settlement process. T2S shall provide a harmonised set of settlement eligibility criteria. Input Matched instruction Already matched instruction/matching not required From matching function From validation function. Output To be settled Forwarding to the settlement function. Version: 1 Page 7 of 44 Status: Final

8 1.5 Communication The communication function would receive the settlement status message from LCMM and would forward it to the T2S interface to be sent to the directly connected T2S parties and CSDs as per the subscription service. (Please see chapter 13) Input Settlement Status Message Received after each settlement attempt. Output Settlement Status Message Forwarding to the Interface function. In addition and independently of what this communication function deals with, T2S shall inform the directly connected T2S parties and CSDs about the result of the Lifecycle processes and the consequent status of the instructions. T2S is able to immediately notify any status change of the instructions to the T2S parties and CSDs (e.g. Accepted, matched, unmatched, pending, failed, rejected). T2S shall communicate the refusal, fail or expiration (Unmatched instructions after 20 days and failed instruction at the end of the recycling period) of the instructions together with the reason. T2S shall report to the directly connected T2S parties and CSDs if the maintenance instruction is no longer possible together with the reason. Moreover, T2S shall provide allegement facilities. The information to be provided shall be subject to the common communication framework as well as the available message subscription (Please see Chapter 13). The T2S message subscription shall let directly connected T2S parties and CSDs customize their information needs: content, frequency, automation, etc. Version: 1 Page 8 of 44 Status: Final

9 5.2 Lifecycle Types This section includes a description of different lifecycle types that an instruction may follow from its entrance in T2S system until its settlement. The lifecycle types which comprise the different transaction types listed in section 5.7. The following list of different processes defines the different Lifecycle Types: Instruction type: the first distinction is made on the type of instruction which is received by T2S, e.g. delivery vs. payment or free of payment. Validation rules: validation rules depend on the instruction type and on the type of instructing party (CSD participant, CSD, etc.) and on other circumstances (e.g. matching required or not). Matching rules and matching fields: matching field depend on the different instruction types. Matching may be required or not depending on the instructing party and depending on the business case (e.g. corporate events have a particular treatment in lifecycle as well as in settlement). Eligibility rules: eligibility rules may vary in some special cases (e.g. Repos) Cancellation and Hold & Release rules: although cancellation of matched instructions is bilateral, nonetheless, instructions which do not require matching as well as others in special cases may have different rules. Use of conditionality: cases in which conditionality is required change significantly the lifecycle. To determine the lifecycle type, T2S will make use of a decision table selecting the lifecycle type based on the selection of the following attributes: Instruction type (DvD, FoP, ) Instructing party (CCP, CSD participant, ) Conditionality Rules as Defined by the CSDs (e.g. from static data, is a ISIN require registration) Information from static data related to the ISIN (e.g. for the need of registration) Version: 1 Page 9 of 44 Status: Final

10 Table: Lifecycle Types Lifecycle Type Instruction type Validation rules Matching rules Eligibility rules Cancellation Hold and release CoSD Block Position Block securities or Standard + validations for No match Standard Unilateral by Instructing Party Unilateral by Instructing Party No cash position instructions which do not require required matching DvD DvD Standard Standard Standard Standard Standard No DvD Conditional DvD Standard Standard DvD Standard Standard until the moment in Standard until the moment in Yes DvD which it is reserved which it is reserved DVD for collateral substitution DvD Standard Standard Standard Unilateral by Instructing Party Unilateral by Instructing Party No DvD DvD already matched DvD Standard + validations for No match Standard Standard, with the limitation Standard, with the limitation No instructions which do not require required required by the specific instructing required by the specific matching party. instructing party. DVD for securities conversion DvD Standard + validations for No match Standard Unilateral by Instructing Party Unilateral by Instructing Party No instructions which do not require required matching DvD Conditional for CA DvD Standard + validations for No match Standard Unilateral by Instructing Party Unilateral by Instructing Party Yes instructions which do not require required matching DvP DvP Standard Standard Standard Standard Standard No Version: 1 Page 10 of 44 Status: Final

11 Lifecycle Type Instruction type Validation rules Matching DvP rules Eligibility rules Cancellation Hold and release CoSD DvP Conditional DvP Standard Standard Standard Standard until the moment in Standard until the moment in Yes DvP which it is reserved which it is reserved DvP for Repos already matched DvP Standard + validations for No match Standard + check that the Standard, with the limitation Standard, with the limitation No instructions which do not require required first leg is settled before required by the specific instructing required by the specific matching settling the second. party. instructing party. DvP for Repos DvP Standard Standard DvP Standard + check that the Standard Standard No first leg is settled before settling the second. DvP already matched DvP Standard + validations for No match Standard Standard, with the limitation Standard, with the limitation No instructions which do not require required required by the specific instructing required by the specific matching party. instructing party. DwP instructed by CCP DwP Standard + validations for No match Standard Standard, with the limitation Standard, with the limitation No instructions which do not require required required by the specific instructing required by the specific matching party. instructing party. FoP FoP Standard Standard FoP Standard Standard Standard No FoP Conditional FoP Standard Standard FoP Standard Standard until the moment in Standard until the moment in Yes which it is reserved which it is reserved FoP already matched FoP Standard + validations for Matched instructions which do not require the CSD by Standard Standard, with the limitation Standard, with the limitation No required by the specific instructing required by the specific Version: 1 Page 11 of 44 Status: Final

12 Lifecycle Type Instruction type Validation rules Matching rules Eligibility rules Cancellation Hold and release CoSD matching party. instructing party. FoP for special purpose (same FoP Standard + validations for No match Standard Unilateral by Instructing Party Unilateral by Instructing Party No owner or C.A.) instructions which do not require required matching Payment PFoD Standard + validations for No match Standard Unilateral by Instructing Party Unilateral by Instructing Party No instructions which do not require required matching Version: 1 Page 12 of 44 Status: Final

13 5.3 Validation Validation is the process of checking the instruction to ensure that it is valid to be forwarded to the matching or to the settlement process, once the system has previously checked that the format and the syntax are correct Validation of incoming settlement instructions Decisional table TG To determine the lifecycle type, T2S will make use of a decision table based on the selection of the following attributes: Instruction type Instructing party Conditionality Rules as Defined by the CSDs Other information from the static data (e.g. ownership of the accounts) A set of information which will result into incoherent lifecycle type will cause the rejection of the instruction. Harmonised set of validation rules TG All incoming instructions shall be validated in T2S. T2S shall establish a harmonised set of validation rules. A non-exhaustive list of detailed validation requirements is included in this chapter. When a validation rule is not fulfilled, T2S shall reject the instruction without checking the remaining validation requirements. Information provided after validation TG T2S shall provide information to the T2S actors on the result of the validation, including information on the reason if the instruction is rejected. Version: 1 Page 13 of 44 Status: Final

14 Matching reference check for already matched instructions TG If two instructions enter T2S already matched, they must have a matching reference indicator to couple them. Additional validation of already matched instructions TG If two instructions enter T2S already matched, T2S shall check that the matching fields are identical. The matching fields to be validated depend on the instruction type in accordance with the matching rules. Multiple entry check TG T2S shall check that there is no duplicate/multiple submission of incoming new instructions based on the instruction reference. It is assumed that each instruction should bear a unique reference. This reference, in combination with the code of the T2S actor, shall be the basis for a multiple entry check. ISIN check TG T2S shall check that the ISIN(s) exists and that it is eligible for settlement in the corresponding CSD on the intended settlement date. After the issuing date, T2S shall reject any instruction with a provisional ISIN. Version: 1 Page 14 of 44 Status: Final

15 Securities account check TG T2S shall check that the CSD participants involved have the securities account in the corresponding CSD in T2S on the instructing day and are authorised to use it according to the CSD s terms and conditions. Currency check TG T2S shall check that the currency of the cash leg of a transaction is eligible for settlement in T2S. This check shall not be carried out for FoP instructions if the field for the cash amount is filled. Reference check for settlement instructions TG T2S shall check the existence of a previous instruction if the settlement instruction is linked to another one. The settlement instruction shall include the reference to the linked instruction. Validation of maintenance instructions TG In case of instructions for holding/releasing, cancelling or amending instructions, T2S shall check whether an instruction with the same related reference exists. T2S shall check that the maintenance instruction is valid. Minimum settlement unit check TG T2S shall check against the minimum settlement unit or nominal. Version: 1 Page 15 of 44 Status: Final

16 This check will not be performed in case of instructions related to corporate events. When more than one ISIN are involved (i.e. DvD instructions) the validation shall be performed on all of them. Multiple settlement unit check TG T2S shall check against the multiple settlement unit or nominal. This check will not be carried out in case of instructions related to corporate events. When more than one ISIN are involved (i.e. DVD instructions) the validation shall be performed on all of them. Trade date check TG T2S shall check that trade date is equal to or earlier than the intended settlement day. Intended settlement date check TG T2S shall check that the intended settlement date is a T2S settlement day. Unique instruction TG If a unique instruction containing all the details of the two parts enters T2S, T2S shall create two separate instructions with the same Unique Reference Number. These instructions will be considered as entering T2S already matched. Repos sent with a unique instruction Version: 1 Page 16 of 44 Status: Final

17 TG If a Repo is received by T2S as a unique instruction containing all the details of the two movement (inception and redemption), T2S shall create two separate instructions with the same Unique Reference Number. These instructions will be flagged and linked as Repos. Lifecycle of Repos sent with a unique instruction TG Lifecycle of single instructions Repo will be handled as any other DvP instruction. Any maintenance instruction, such as hold, cancel, etc., will be applied on both the movement if applicable. In the case in which the inception is already settled, the maintenance instruction is applied on the redemption. Repurchase settlement date check TG In case of "plain vanilla fixed income financing instructions" (e.g. Repo instructions), T2S shall check that the repurchase settlement date is equal or later than the purchase date. Background: With "plain vanilla fixed income financing instructions" T2S means a specific type of fixed income financing instruction for which all the information regarding both the first and the second leg of the transaction are predetermined when they are introduced in T2S. They will be introduced in T2S with a single message and T2S will generate both legs with the information received. T2S will not calculate any data.i This does not mean that only this type of fixed income financing transactions will be supported by T2S. It is up to the participants to send one single message or two if they wish. Participants may also send two separate instructions as for example in the case of open-ended repos. Issuing date check TG In case of securities traded on grey markets, T2S shall check that the intended settlement date is equal or later than the issuing date. For technical house-keeping instructions this check shall not apply. Version: 1 Page 17 of 44 Status: Final

18 Cash account check TG T2S shall check the authorisations related to the cash accounts when a payment in T2S is involved. T2S shall check that the cash account to be credited or debited is linked to the securities account or T2S party in static data. Proxy check TG If the instructing party is not the owner of the account, T2S shall check that it is authorised to send such instruction on behalf of the account owner. Securities amount check of matched instructions TG For instructions matched externally, T2S shall check that the debits of securities are equal to the credits (for the pairs of instructions or for the total of instructions if they are going to be processed as AoN). Additional validation check when an external CSD is present TG T2S shall perform the specific validation checks needed for transactions involving at least one external CSD. T2S shall not validate information regarding CSD participants of the CSD outside T2S, although instructions will contain such information. T2S shall identify the chain of the CSDs involved in the transactions, according to the information maintained in the Static Databases. Check for regulatory/supervisory requirements Version: 1 Page 18 of 44 Status: Final

19 TG T2S shall perform validation checks required by legal authorities (i.e. for anti-money laundering, anti terrorist financing, etc.) for settlement. Instruction type/instructing party check when process indicator is present TG T2S shall check that settlement process indicators are valid considering the type of instruction and the instructing party. In case of maintenance instruction coming from CSD participants to deactivate the partial settlement indicator (activated at the level of the instruction), T2S shall check that the indicator has not been activated by instructions generated by CSDs, CCPs, Stock Exchanges and trading platforms under their power of attorney. If so, the maintenance instruction shall be rejected. Instructing party check for instruction maintenance purposes TG For instruction maintenance purposes (see 5.4 below), information about the instructing party needs to be available to the Lifecycle Management. Non-settlement related information TG Non-settlement related information shall be allowed in instructions to cover CSD participants needs, but it will neither be validated nor matched by T2S. Status after validation Version: 1 Page 19 of 44 Status: Final

20 TG After the validation process the status of the instruction becomes "accepted" or "rejected" if instructions enter T2S to be matched; if instructions enter T2S already matched, then the status becomes rejected or matched. Information provided after validation TG T2S shall provide information to the T2S actors on the result of the validation process, including information on the reason if an instruction is rejected. Full audit trail TG T2S shall log the whole lifecycle of an instruction (moments, events, status) to ensure a fully date and time stamped and fully referenced lifecycle (i.e., T2S will provide a full audit trail ). (See Chapter 16 for further information) Re-validation of instructions due to update of static data Re-validation after database change TG When some relevant information in the databases changes, T2S shall check all pending instructions which are affected by these changes and verify validity (and eligibility) pursuant to the change. CSDs will be informed of the result and instructing parties will be informed on the impacted instructions. For those instructions which will require amendments to become valid again, it is up to the CSD to cancel and reinstruct or to modify them according to the conditions agreed with the CSD participants. Version: 1 Page 20 of 44 Status: Final

21 5.4 Instruction maintenance The instruction maintenance is the process of amending, cancelling, holding and releasing settlement instructions. Availability of instruction maintenance TG CSD participants may use the instruction maintenance regardless of whether their instructions are matched in the CSD or in T2S. Information provided after instruction maintenance TG T2S shall provide information to the T2S actors on the result of the instruction maintenance, including information on the reason if a maintenance instruction is rejected. Allegement functionality for instruction maintenance TG Allegements will be sent to the T2S actor when the counterpart sends any of the following maintenance instruction: Cancellation Partial settlement allowed (amendment) Hold Release Hold and release mechanisms Hold and release mechanisms allow CSD participants and CSDs to hold back or release instructions for settlement. They allow CSD participants to match and confirm the term of the settlement of any transaction Version: 1 Page 21 of 44 Status: Final

22 without initiating actual settlement. Maintenance instructions to hold and to release may be sent by T2S actors as many times as needed without limitation by T2S. H&R mechanism availability TG T2S shall provide a hold and release mechanism. CSD participants and CSDs may use this mechanism on a voluntary basis. H&R mechanism check TG T2S shall only allow the T2S actor which has put an instruction on hold, to release it. If there are two hold instructions for the same instruction (one by the CSD participant and one by the CSD), also the release instructions must come from both. H&R mechanism under a power of attorney TG Instructions generated by CSDs, CCPs, Stock Exchanges and trading platforms under their power of attorney, can only be put on hold by them. H&R mechanism until settlement occurs TG Instructions can be put on hold until actual settlement occurs, even beyond the intended settlement date. Instructions on hold will be considered as failed at the end of the "intended settlement" date. T2S shall recycle held instructions with the status on hold. Version: 1 Page 22 of 44 Status: Final

23 Rejection of a Hold instruction TG If a hold instruction is received at a moment in which it is no longer possible to put the related instruction on hold because it has been settled, T2S shall reject it and inform the sender accordingly Amendment of instructions No foreseen calculations TG T2S shall not carry out any kind of calculations. It is up to the CSD participants, CSDs, CCPs or Stock Exchanges or trading platforms to amend instructions that require updating before settlement. T2S may amend instructions only by filling in default values (e.g. default accounts) preset in the Static Data. Amendment options TG T2S shall allow CSD participants to amend matching fields before matching. Amendments of process indicators and non matching fields shall be possible until settlement occurs. Authorisation check for amendment TG T2S shall not allow CSD participants to amend instructions (including process indicators) generated by CSDs, CCPs, Stock Exchanges and trading platforms under their power of attorney. Amendment by CSDs TG Version: 1 Page 23 of 44 Status: Final

24 T2S shall allow CSDs to amend participants instructions according with their rules, even after matching in case of corporate events Cancellation of instructions Possible cancellation of instructions matched in CSD/T2S TG T2S shall allow T2S actors to request a cancellation of an instruction within T2S. Cancellation check TG T2S shall check that the related instruction which is requested to be cancelled exists within T2S and that it can be cancelled. The ability for T2S actors to cancel their instructions depends on the status of the instruction within T2S and on the type of transaction. Authorisation check for cancellation TG CSD participants shall not be able to cancel instructions generated by CSDs, CCPs, Stock Exchanges or trading platforms under their Power of Attorney. Cancellation of unmatched instructions TG T2S shall cancel unmatched instructions after a period of 20 working days from the latter of the intended settlement date or the last status change. In case that T2S cancels unmatched instructions, the instructing party shall be informed. Version: 1 Page 24 of 44 Status: Final

25 Unilateral versus bilateral cancellation TG CSD participants shall be able to cancel settlement instructions unilaterally until the moment in which they are matched. Once matched, settlement instructions can only be cancelled bilaterally, i.e. both parties have to send a cancellation instruction (binding matching). On the receipt of the first cancellation instruction, allegements will be sent to the T2S actors. Only on the receipt of a valid cancellation instruction from the other party to the transaction, both settlement instructions will be cancelled, provided they have not settled in the interval. In case of cancellation instructions, if bilateral cancellation is needed, T2S will check that the cancellation instruction from the counterpart is already in the system. If not, the cancellation instruction will be kept until the second one is introduced. Deadline for cancellation TG Instructions can be cancelled until actual settlement occurs. In case that the settlement fails, instructions may be cancelled if there is a pending (bilateral) cancellation instruction before forwarding it to the settlement process again. Cancellation instructions will be kept in the system waiting for the cancellation instruction from the counterpart, if bilateral cancellation is required. Once both cancellation instructions are in the system, if instructions are in the settlement engine, they will also be kept and re-processed should settlement fail. Cancellation triggered when the length of recycling is reached TG T2S shall cancel the instructions which remain failed after the number of days defined in the length of recycling by the CSDs, CCPs, Stock Exchanges and Trading Platforms under their terms and conditions. The length of recycling for cross-csd instructions shall be harmonised. When a cross-csd instruction involves a CCP, the most restricting length of recycling determined by either the CSD or Version: 1 Page 25 of 44 Status: Final

26 the CCP shall apply. The length of recycling shall be set in T2S static data. When necessary, the length of recycling shall be able to be set a zero-day. The Recycling procedures are described in chapter 8. Authorisation check for cancellation TG T2S shall allow CSDs, CCPs Stock Exchanges and trading platforms to cancel unilaterally instructions generated by them under their Power of Attorney until actual settlement occurs. For CoSD, T2S shall allow the administering party to cancel unilaterally the instruction (under its responsibility) if the external condition could not be fulfilled under its Power of Attorney, even once the securities reservation has taken place. Automatic cancellation functionality to CCPs TG T2S shall provide an optional automatic cancellation functionality to CCPs, which would on behalf of the CCP cancel all failed instructions at the end of the settlement day. Cancellation by CSD TG A CSD should be able to cancel an instruction in T2S at its own discretion and in line with its terms and conditions/operating procedures, even in the case is which the instruction has been introduced directly by a CSD participant. Status after cancellation TG Version: 1 Page 26 of 44 Status: Final

27 In response to the cancellation process, the status of the instruction becomes cancelled or remains as it was. T2S shall inform impacted parties about the reason of the cancellation. Version: 1 Page 27 of 44 Status: Final

28 5.5 Matching Matching is normally defined as the process used for comparing the settlement details provided by the buyer and the seller of securities in order to ensure that they agree on the settlement terms of the transaction. T2S shall offer a matching functionality. Instructions may either be matched in T2S or they may enter T2S already matched. Instructions which enter T2S already matched must comply with the T2S matching rules. For instructions generated by stock exchanges, other trading platforms and CCPs, they may enter the settlement process in T2S either directly or through their local CSD. When instructions enter T2S already matched, there should be no disruption to the settlement process as a result of the matching location. In this context: The user will have the choice of matching in T2S or in a CSD. Cross-CSD instructions and instructions from directly connected users will be matched in T2S. Matching services offered by CSDs will not disrupt provisions for direct connectivity. As consequence, all CSDs participating in T2S need to ensure that all instructions involving a T2S actor, which is directly connected to T2S or has chosen on a permanent basis to match in T2S as well as instructions involving a CSD participant of another CSD (cross-csd transactions), are forwarded to T2S for matching. Although this is not a T2S user requirement, its implementation in the systems of the participating CSDs is a pre-condition for the below user requirements to function properly. There would have to be exceptions to matching in T2S for certain types of transactions: External settlement Value-added services like securities lending Potentially non-fungible securities/registered shares Requirements related to Matching Continuous real-time matching facilities TG Version: 1 Page 28 of 44 Status: Final

29 T2S shall provide real-time matching facilities throughout the whole settlement day (as defined by the chapter 3). T2S matching exceptions TG Instructions shall be matched by T2S, with the exception of (i) instructions of two indirectly connected CSD participants of the same CSD, which have both decided to match at that CSD or (ii) instructions generated by stock exchanges, trading platforms, CCPs or CSDs (for some specific instructions as for example those related to corporate events), which may enter T2S already matched or with matching not required. FoP instructions with matching not required TG Free of payment instructions between securities accounts belonging to the same T2S party within the same CSD specified via the Static Data do not need to be matched. Status after matching TG After the matching process, the status of the instruction shall become matched or unmatched. Information provided after matching TG T2S shall provide information to the T2S actors on the result of the matching process. Allegement facilities for matching Version: 1 Page 29 of 44 Status: Final

30 TG T2S shall send an allegement message per unmatched instruction, after the first unsuccessful matching attempt, if the attempt failed because of a missing counterpart instruction. The allegement shall be sent after a delay period to allow the receipt of instructions by T2S. The unmatched instruction can be a settlement instruction or a maintenance instruction that needs to be matched, like for instance a cancellation instruction. Removal of allegement message TG T2S shall send a removal of allegement message when the previously sent allegement message is no longer valid (i.e. the settlement instruction has been matched with the counterpart). Matching of Repos TG Matching of single instruction Repos will be performed on separate instructions (inception or redemption) independently. Matching fields will be as defined for DvP instructions. Cancellation of matched instructions TG Matched instructions shall remain matched until actual settlement occurs except for the cases described in the User requirements related to cancellation rules (Chapter 5.4.3). Tolerance amount for matching TG Version: 1 Page 30 of 44 Status: Final

31 When required, the cash amount will be matched even with a tolerance (no perfect match). The tolerance amount will be in two different bands depending on the countervalue (e.g., the general tolerance amount for matching the cash amount field might be 25 when the countervalue is above or 2 when it is less or equal to ). Once two instructions are matched with a discrepancy in the cash amount, within the limit of the tolerance amount, the instruction will be settled with the seller s cash amount. Allowed process indicators TG T2S shall accept process indicators. They will be used to perform certain actions in the settlement of the instructions. Process indicators list TG Non-exhaustive list of process indicators: Partial settlement allowed; Link indicator (e.g. All or None (AoN)); Setting settlement priority; Self-collateralisation allowed Mandatory matching fields Mandatory matching fields TG Mandatory matching fields are those instruction fields which need to be matched between instructions. The mandatory matching fields will depend on the instruction type (DvP, DwP, FoP or DvD). The current list of mandatory matching fields is included in the below table. The securities accounts are mandatory fields in the instruction (the one who delivers shall include the deliverer account and the one who receives shall include the receiver account), but they are not matching fields. Version: 1 Page 31 of 44 Status: Final

32 DvP / DwP FoP DvD instruction type code instruction type code instruction type code intended settlement date intended settlement date intended settlement date Trade date trade date trade date currency cash amount share quantity (for equities) or share quantity (for equities) To deliver: share quantity nominal amount (for fixed or nominal amount (for (for equities) or nominal income securities) fixed income securities) amount (for fixed income securities) To Receive: share quantity (for equities) or nominal amount (for fixed income securities) buy/sell Deliver/Receive Deliver/Receive ISIN code ISIN code ISIN code to deliver ISIN code to Receive code of the counterpart who delivers the securities Code of the counterpart who receives the securities. code of the counterpart who delivers the securities Code of the counterpart who receives the securities. code of the counterpart who delivers the securities Code of the counterpart who receives the securities Additional matching fields Additional matching fields TG Additional matching fields are those fields that are not mandatory but become mandatory if at least one of the two settlement counterparts instructs them. A non-exhaustive list of these additional matching fields is included in the below table. Version: 1 Page 32 of 44 Status: Final

33 DvP FoP DvD Common reference 2 Common reference Common reference Cash amount if it is not a blank field 3 Trade price 4 Client of delivering CSD Client of delivering CSD Client of delivering CSD participant 5 (if a defined participant (if a defined participant (if a defined standard code, e.g. BIC, exists, it should be used) standard code, e.g. BIC, exists, it should be used) standard code, e.g. BIC, exists, it should be used) Client of receiving CSD Client of receiving CSD Client of receiving CSD participant 6 (if a defined participant (if a defined participant (if a defined standard code, e.g. BIC, exists, standard code, e.g. BIC, exists, standard code, e.g. BIC, exists, it should be used) it should be used) it should be used) 5.6 Settlement eligibility Settlement eligibility is necessary before forwarding an instruction to the settlement process. Checks related to blocking of securities or accounts will be done within the settlement process. For a general description of the eligibility process, please refer to Chapter Requirements related to settlement eligibility Harmonised set of settlement eligibility criteria TG T2S shall provide a harmonised set of settlement eligibility criteria. T2S shall forward for settlement only those instructions which meet the eligibility criteria. Settlement eligibility check 2 It will be voluntarily introduced by both counterparties in order to facilitate the matching. 3 It is for FoP instructions. Therefore, the cash will not be settled in T2S. 4 To ensure that matching identifies a correct pair of instructions among a group of similar instructions with the same trade date and cash amounts within the tolerance limit 5 The ESF/ECSDA standards refer to second layer market participant (sub-account/customer of counterparty). 6 The ESF/ECSDA standards refer to second layer market participant (sub-account/customer of counterparty). Version: 1 Page 33 of 44 Status: Final

34 TG T2S shall check that the intended settlement date is the current date or earlier for the instruction to be considered as eligible for settlement. Instructions eligible for settlement TG T2S shall consider eligible for settlement only those instructions which satisfy either the criterion "the status is matched/already matched" or "the status is accepted and matching not required for this type of instructions". Instructions "on hold" shall not be considered eligible. 5.7 Transaction Types Transaction types are described in generic terms (e.g. Securities Lending, Transfer of Securities) and for each a lifecycle type is associated. In the transaction types are also described those process indicators which do not impact lifecycles and are used mainly for settlement specificities (e.g. All-or-None indicators). The following list of attributes determines a non-exhaustive list of different Transaction Types: Originator: whether the instructing party is a CSD participant, a CCP, etc. Lifecycle Type: see section 5.2 Priority: whether there is a special priority as in the case of monetary policy transactions Link Indicator: indicators of some settlement constraints such as All-or-None link Specificity: special condition under which the instructions may be executed; as an example, the administering party must be determined in the case of a conditional instruction. Version: 1 Page 34 of 44 Status: Final

35 T2S User Requirements Chapter 5 - Lifecycle management and matching requirements Table: Plain Vanilla Transaction Type Originator Lifecycle Type Link Indicator Note Back to Back CSD participant DvP already Matched Delivery - Facilities to ensure the Back to Back execution of buy and sell instructions. It Redelivery refers to a unique ISIN where, as an example, one or more buy "block" orders are delivered by several "allocated" sell orders Back to Back CSD participant DvP Delivery - Facilities to ensure the Back to Back execution of buy and sell instructions. It Redelivery refers to a unique ISIN where, as an example, one or more buy "block" orders are delivered by several "allocated" sell orders Basket CSD participant DvP already Matched AoN Instructions to Buy/Sell may be sent linked together for an All or None execution. They may contain different ISIN Basket CSD participant DvP AoN Instructions to Buy/Sell may be sent linked together for an All or None execution. They may contain different ISIN Cash Transfer CSD participant Payment None Mark up / Mark down CSD participant FoP for special None purpose (same owner or C.A.) UCITS increase/decrease CSD participant FoP for special None purpose (same owner or C.A.) Securities will be settled as mark up and mark down of the quantity of issued securities. It will be as the process of issuance or redemption of securities. Special type of mark up/down related to the fund Industry. Plain Vanilla (buy, sell) Stock Exchange, DvP already Matched None Plain vanilla instructions received by Stock Exchange/CCP which enter T2S Version: 1 Page 35 of 44 Status: Final

36 T2S User Requirements Chapter 5 - Lifecycle management and matching requirements Transaction Type Originator Lifecycle Type Trading Platforms or CCPs Link Indicator Note already matched. Zero quantity DvP are accepted as they might be the result of netting by the CCP. Plain Vanilla (buy, sell) CSD participant DvP already Matched None Instructions received by CSD participants to settle plain vanilla (buy/sell) instructions Plain Vanilla (buy, sell) CSD participant DvP None Instructions received by CSD participants to settle plain vanilla (buy/sell) instructions securities conversion CSD participant DVD for securities None conversion Transfer of securities CSD participant FoP already Matched None Instruction to transfer securities between accounts of different CSD participants Transfer of securities CSD participant FoP None Instruction to transfer securities between accounts of different CSD participants Transfer of securities between CSD participant FoP for special None accounts of the same owner purpose (same owner or C.A.) Instruction to transfer securities between accounts of the same CSD participant Version: 1 Page 36 of 44 Status: Final

37 T2S User Requirements Chapter 5 - Lifecycle management and matching requirements Table: Special Transaction Type Originator Trx Lifecycle Description Link Indicator Note Auto collateralization T2S DvP already matched None Auto collateralization T2S DVD for securities None substitution conversion Buy in / Sell out CSD TRAD DvP None Buy in / Sell out Buy in / Sell out CSD participant CSD participant TRAD DvP already Matched None TRAD DvP None Coupon reattachment CSD participant FoP for special purpose None (same owner or C.A.) The coupon re-attachment transforms the individual zero coupon originated by a coupon stripping, in the original security. The un-stripping is possible recollecting the whole series of principal and related coupons. Coupon Stripping CSD FoP for special purpose None The coupon detach (stripping) transforms the bond into a zero coupon plus a number participant (same owner or C.A.) of separate zero coupons with different maturity representing the coupon payments. Delivery Payment Market Transactions Market Transactions with CSD or CCP TRAD DwP already Matched None Instruction that deliver cash and securities. It may be the netting resulting from PAIR different instructions. Claim CSD DvP already Matched None Instruction generated from the CSD to compensate a Market Claim Claim CSD Payment None Instruction generated from the CSD to compensate a Market Claim Version: 1 Page 37 of 44 Status: Final

38 T2S User Requirements Chapter 5 - Lifecycle management and matching requirements Transaction Type Originator Trx Lifecycle Description Link Indicator Note Market Transactions Claim CSD FoP for special purpose None (same owner or C.A.) Instruction generated from the CSD to compensate a Market Claim Version: 1 Page 38 of 44 Status: Final

39 T2S User Requirements Chapter 5 - Lifecycle management and matching requirements Table: Collateral Related Transaction Type Originator Trx Lifecycle Description Link Indicator Note DbV CSD DvP already AoN matched Instructions to lend against set of securities (collateral). Instructed via the CSD systems are linked together for an All or None execution. They may contain different ISIN. Special case of basket Monetary Policy CSD participant REPU DvP for Repos None Repo for monetary policy purpose Operations RVPO already matched Monetary Policy CCBM2 CNCB FoP already None Operations Pledge / matched collateral management Movement of pledging is processed as a FoP or DvD instruction Monetary Policy CCBM2 Operations Pledge / collateral management CNCB DVD for collateral None substitution Movement of pledging is processed as a FoP or DvD instruction. Repos without link will be processed as normal Buy/Sell instructions Pledge management) Pledge management) (collateral Stock Exchange, COLL FoP for special None Trading Platforms purpose (same or CCPs owner or C.A.) (collateral CSD participant COLL FoP already None Matched Movement of pledging is processed as a FoP instruction Movement of pledging is processed as a FoP instruction Pledge management) (collateral CSD participant COLL FoP None Movement of pledging is processed as a FoP instruction Repo CSD participant REPU DvP for Repos None Repurchase Agreements with maturity dates up to 12 months, forward and open Version: 1 Page 39 of 44 Status: Final