Presentation on Options 3+ and 4 in the context of theT2S functionality for cross-CSD settlement business Teleconference of the Change Review Group 13 December 2013

2  The CSD Steering Group (CSG) on converged towards introducing a new check which would allow settlement only if omnibus and mirror accounts are synchronized (i.e. blocking of all settlement in an ISIN in case of de-synchronisation of omnibus/mirror accounts for both cross-CSD and CSD-internal settlement)  The requirement is summarized as follows: For settlement on ISIN where the Issuer CSD is internal to T2S, T2S is expected to ensure that in case any mirror account of an Investor CSD and the corresponding omnibus account of the issuer CSD or the technical issuer CSD are not synchronized at the level of the securities position:  No cross CSD settlement involving these mirror and omnibus accounts must occur between the Investor CSD and the (technical) issuer CSD  No intra CSD settlement must occur on this ISIN inside the Investor CSD (except for non-realignment settlement instruction or settlement restriction (*) affecting the mirror account) For settlement where the Issuer CSD or the Investor is external to T2S, no check and no restriction will be applicable. The situation and the associated risks remain as they are today without T2S.  This presentation reports on the high level assessment requested to the 4CB regarding two solutions 3+ and 4 identified out of the CSG meeting (*) these instructions of the Investor CSD impacting the deliverable securities position of the mirror account are hereafter called “de(re)synchronizing- Investor SI/SR” Background and content

1a - At the settlement of a CROSS CSD instruction T2S checks if the mirror and omnibus of the realignment chain are synchronized 2a – At the settlement of an INTRA CSD instruction T2S checks if ALL mirror and omnibus accounts are synchronized ISSUER CSD I ISSUANCE S/AC OMNIBUS CSDA PART 1 PART 2 INVESTOR CSD A (TECHNICAL ISSUER CSD A) INVESTOR CSD A (TECHNICAL ISSUER CSD A) MIRROR CSD A/CSD I OMNIBUS CSDB PART 5 PART 6 INVESTOR CSD B MIRROR CSD B / CSD A PART 8 PART 9 This solution extends to the intra-CSD context the existing solution 3 that only prevents currently any cross-CSD settlement when the omnibus and mirror are not synchronized. Solution 3+ : Main features 1b - When mirror and omnibus accounts in the realignment chain are not synchronized the settlement fails 2b- When ANY mirror and omnibus acccounts in the Investor CSD are not synchronized the settlement fails This solution is raising a significant performance issue in the current architecture and requires to review the design of the settlement engine in order to address this performance issue: therefore this solution is not recommended for further assessment 3 X X

4 Solution 4 : Main features This solution relies in case of desynchronisation on a different implementation than solution 3+ to prevent the settlement by setting an intraday restriction on the ISIN involved with such desynchronisation In such a case T2S is expected to ensure that:  Each time a SI/SR of an Issuer CSD or of an Investor CSD is desynchronizing the securities position of any mirror account of an Investor CSD (with its corresponding omnibus at the Issuer CSD)  An intraday restriction is set-up: (i) in the Investor CSD (ii) at the level of the ISIN (iii) but excluding the de(re)synchronizing Investor SI/SR  Therefore preventing any settlement – cross and intra – to take place at this investor CSD  This intraday restriction can be released automatically by T2S (and only by T2S) when the re- synchronization of all the omnibus and mirror accounts are detected again  All settlement instructions that were blocked under the intraday restriction are resubmitted again to settlement at the release of the intraday restriction.

Solution 4 : Main features 1- When an intra CSD SI or SR settles on the omnibus or mirror accounts and generates their desynchronisation 2- T2S triggers an intraday restriction on the ISIN at the Investor CSDA 3a- This intraday restriction blocks any cross CSD settlement between CSDA and CSDI 3b- This intraday restriction blocks any cross CSD settlement between CSDA and CSDB 3c- This intraday restriction blocks any intra CSD settlement in CSD A 3d- This intraday restriction blocks any cross CSD settlement between CSDI and CSD B due to its aplicability on realignment instruction in CSD A involved in the chain 4- The AUTOMATIC RELEASE of the intraday restriction when no desynchronisation exists anymore allows again all settlement ISSUER CSD I ISSUANCE S/AC OMNIBUS CSDA PART 1 PART 2 INVESTOR CSD A (TECHNICAL ISSUER CSD A) INVESTOR CSD A (TECHNICAL ISSUER CSD A) MIRROR SAC OMNIBUS CSDB PART 5 PART 6 INVESTOR CSD B MIRROR SAC PART 8 PART 9 3e- This intraday restriction DOES NOT block the de-(re)synchronizing Investor SI/SR 5 X X v X X

6  Set-up of the intraday restriction –Night-time settlement: T2S put first under intraday restriction (except for de(re)synchronizing Investor SI/SR) all ISIN that are impacted by an intra CSD SI & SR on mirror or omnibus accounts of Issuer CSD and Investor CSD. Then T2S performs the settlement of all instructions, including the ones excluded from the intraday restriction. At the end of the settlement T2S checks and confirms or release the intraday restrictions. –Real-time settlement: T2S checks in VPB at the settlement of any intra CSD SI & SR that impacts directly any mirror account of an Investor CSD (or the omnibus account of an Issuer CSD) if the result of this settlement desynchronizes the mirror account of the Investor CSD. For such Investor CSD T2S triggers an intraday restriction on the given ISIN immediately applicable to all instructions (except on de(re)synchronizing Investor SI/SR).  Release of the intraday restriction –T2S releases the intraday restriction on the basis of similar check that are made on Intra CSD SI & SR on omnibus or mirror accounts but once it is ensured that all mirror accounts of the investor CSD are synchronized Solution 4 : Functional description

7  Recycling –The instructions that fail to settle due to an intraday restriction are all resubmitted to settlement at the release of such intraday restriction as it is already the case with the current feature for intraday restriction.  Auto-collateralisation –The failure to use auto-collateralisation solution under intraday restriction relies on standard functionality that applies currently for collateral instructions under intraday restriction –Concretely no collateral set-up, collateral reimbursement, dynamic substitution can occur when the generated instruction to be used for such collateral operation is subject to an intraday restriction  End of day reimbursement/relocation of collateral –The failure to perform the EOD reimbursement/relocation of collateral relies on standard functionality that applies currently for instructions under intraday restriction  Reporting –At the set-up of an internally generated intraday restriction: Reporting per settlement instruction on a settlement failure due to a blocking based on an ad-hoc functionality allowing to inform the failure with the type (IR due to desynchro) - sese.024 or semt.014 BLOC/SBLO with new additionalreasoninformation e.g “Blocked for desynchronisation of mirror and omnibus” Solution 4 : Functional description

8 Solution 3+Solution 4 Features Check the synchronisation of omnibus and mirror accounts prior the settlement of any CROSS CSD or INTRA CSD instruction T2S automated generation of an Intraday Restriction when the settlement of an Intra CSD instruction desynchronizes any mirror of an Investor CSD with its associated omnibus T2S automated release of the intraday restriction following the settlement of an intra CSD instruction that makes all mirrors of an Investor CSD synchronized with their associated omnibus Risk assessment for complexity & impacts on core functions SHOWSTOPPER Implementing the check for intra CSD instructions would severely endanger the performance of the settlement engine To address this performance issue would need to fully revisit the design of the settlement engine MEDIUM Need to implement new process able to generate/release automatically the intraday restriction But then allowing to benefit from all existing features of the intraday restriction Impact on performance SHOWSTOPPER Implementing the check for intra CSD instructions would severely endanger the performance of the settlement engine LOW - MEDIUM Availability for User Testing Not relevantNot later than end of 2014* Impact on the ongoing testing activities Not relevantHIGH Specifications of the solution to be started in December 2013 Overall comparison of solutions * Earlier delivery subject to detailed assessment