Repo processing in T2S

Transcription

1 Repo processing in T2S Background A number of CSDs currently support specific processing for Repo transactions. This allows participants to instruct both legs of a Repo transaction through one instruction. Details relating to the start and end legs of the Repo need to match before the start leg is sent for settlement. The CSD will also only send the end leg for settlement once the start leg has already settled. A number of CSDs allow the interest rate on the Repo transactions to be linked to an index rate (i.e. Libor or Eonia) and calculate the interest to be paid on the end leg. Other CSDs and the ICSDs do not all provide this functionality. Where this functionality does not exist Repo transactions are instructed as two separate and distinct instructions for matching and settlement. Current Themes in the Repo Market Firstly a large number of Repo transactions across Europe are still traded OTC (as opposed to on an Automated Trading System such as MTS or B TEC). This can lead to a degree of market risk as there is no widespread use of transaction matching services. Therefore often the final terms of the transaction are only positively confirmed when settlement is attempted on the end leg. Hence there is a recognised need to provide a mechanism for timely transaction matching to minimise this risk. Due to the flexible nature of Repo transactions this matching service would have to be able to support a wide range of post trade adjustments to the transaction, e.g. Partial return/top up of collateral, repricing of trade, rate changes, Index linked interest rates, substitution of collateral, change of end date etc. Secondly when a coupon is paid the participant holding the securities will receive the funds. If this participant had received the securities on the back of a Reverse Repo transaction they pass the coupon back to the original holder - the Repo counterpart. In an ideal world (I)CSDs should be able to recognise repo transactions and automatically compensate the coupon to the original bond holder. This would greatly reduce the manual workload involved in passing these coupons between market participants. This functionality is only available in a number of CSDs where a single Repo instruction is used. T2S & Repo Transactions T2S should be transformational in opening up cross border settlement, therefore while currently it is possible for Repo functionality to happily exist in isolation within a

2 number of the CSDs, ideally a harmonised approach should be taken to ensure consistent treatment of Repo transactions across all markets. This is essential if matching and settlement efficiency is to be maintained. Potential Solutions in T2S Single Message with full matching of Post Trade Actions T2S would build a Repo service that would allow all types of Repo to be matched Harmonises market around one single approach for all repos STP approach for All Repos Ensures no confusion in market over what type of messaging to use and therefore reduces possibility for matching and settlement inefficiency Potentially lower participant variable costs (e.g. communication SWIFT assumes cost of matching Repo transaction same as for normal instruction) Reduced market risk as both legs of transactions are matched from the outset and are continuously matched throughout lifecycle of the Repo Ensures end leg of the Repo doesn t settle before the start leg. Low implementation costs for market practitioners currently using CSD Repo offerings (assumes only trade vanilla repo) Allows for automatic coupon compensation by (I)CSDs as all Repo transactions could be tracked High Implementation costs for T2S - flexible nature of Repos requires the matching tool to include full functionality around the on-going matching of post trade actions. This would require a complicated and expensive build. High implementation costs for market practitioners requires majority of Users to build new messaging infrastructure for Repo trades especially Users trading full spectrum of Repos (i.e. simple and flexible) This form of transaction matching is not considered to be a settlement function, therefore should T2S build this? Separate Messages for Start and End leg no specific Repo functionality included in T2S Repo transactions instructed as two distinct messages Harmonises market around one single approach for all repos Ensures no confusion in market over what type of messaging to use and therefore reduces possibility for matching and settlement inefficiency Low implementation costs for both T2S and Market Practitioners Allows T2S to concentrate on providing settlement services and not Transaction Matching services

3 Allows (I)CSDs or other Market Service providers to offer the value added services of Repo transaction matching if market demand is sufficient Increased participant variable costs (e.g. need to send separate SWIFT instructions) Participants using current CSD Repo services would need to make changes unless CSDs choose to continue to offer the service as Value Added No reduction in market risk as end leg of transactions are not matched from the outset Doesn t allows for automatic coupon compensation by (I)CSDs Possible for the end leg of the Repo to settle before the start leg although the use of linking functionality could mitigate this Not as STP as single message approach need to match both legs independently Single Instruction covering just Plain Vanilla Repo transactions Transactions which have a defined end leg could still be instructed as a single message all flexible Repo Transactions to be instructed as two separate messages Potentially lower participant variable costs (e.g. communication SWIFT assumes cost of matching Repo transaction same as for normal instruction) STP approach for vanilla Repos Reduced market risk on plain vanilla transactions as both legs are matched from the outset Ensures end leg of vanilla Repo trades doesn t settle before the start leg. No implementation costs for participants currently using CSD Repo service who only trade vanilla repos Allows for automatic coupon compensation by (I)CSDs on vanilla transactions No harmonisation around one single approach for all repos No clear definition of plain vanilla may lead to market confusion and reduction in matching and settlement efficiency as some participants send one message and others two Implementation costs for T2S especially if transactions whose interest rate is set relative to an Index are included High Implementation and variable costs for Participants trading both vanilla and flexible Repos. Fragmented approach does not enable STP and would require complicated logic to be built in participant s systems to handle the two separate flows for the same product. Fragmented approach particularly difficult to implement where several steps involved in getting instructions to the settlement location (e.g. via Global Custodians)

4 This form of transaction matching is not necessarily considered to be a settlement function, therefore should T2S build this? No reduction in market risk on flexible Repos as end leg of transactions are not matched from the outset Doesn t allows for automatic coupon compensation by (I)CSDs on flexible Repos Possible for the end leg of the flexible Repo to settle before the start leg although the use of linking functionality could mitigate this Single Message incorporating matching of Vanilla instructions but not full matching of Flexible Repos All Transactions instructed as one message and matched based of terms of trade known at the time. End leg created in settlement system but Post trade actions not matched and end leg of transaction to be updated independently by participant when/if changes made Harmonises market around one single initial approach for the instruction of all repos Ensures end leg of vanilla Repo trades doesn t settle before the start leg. No implementation costs for participants currently using CSD Repo service who only trade vanilla repos Allows for automatic coupon compensation by (I)CSDs on transactions not updated No reduction in market risk as no certainty of matching on end leg due to possibility that it could be updated Implementation costs for T2S especially if transactions whose interest rate is set relative to an Index are included High Implementation and variable costs for Participants trading both vanilla and flexible Repos. Fragmented approach does not enable STP and would require complicated logic to be built in participant s systems to handle the hybrid approach. Fragmented approach particularly difficult to implement where several steps involved in getting instructions to the settlement location (e.g. via Global Custodians) This form of transaction matching is not necessarily considered to be a settlement function, therefore should T2S build this? Doesn t allows for automatic coupon compensation by (I)CSDs on flexible Repos Recommendations In order to avoid confusion in the market place and additional costs for participants and T2S then Repo transactions should be sent as two separate transactions.

5 While a Repo Transaction matching tool is the preferred market solution it is probably not appropriate for T2S in its current settlement remit to build this. Either CSDs could expand to offer this solution as a value added service or other market service providers could be encouraged to develop this. Additionally any compromise around offering a Repo service covering just vanilla repos, or variants of, has the potential to introduce significant costs for Users and little benefit in terms of reducing market risk, and may actually introduce significant matching and settlement inefficiency in the cross border market.