Repo Instructions Introduction Repo is a generic term which covers a diverse range of collateralized lending products and services which, across Europe, are cleared and settled according to different market practices. In an ideal situation there would be harmonization. However, harmonization is unlikely to occur within the current phase of T2S. Therefore, in the absence of harmonization, T2S must develop requirements based on a compromise solution which meets, as nearly as possible, the needs of different stakeholders in both domestic and cross border transactions. The following proposal is a technical way of processing instructions in the event of T2S adopting the compromise solution of allowing the use of both a single message as well as separate DVP/RVP instructions for Repo transactions. It allows T2S to reconcile different operating practices across Europe. The use of the single message could be restricted to "plain vanilla" fixed income financing transactions only but this solution may create some difficulties in those markets where it is in more general use. Therefore, a more generic way of operating is envisaged, which could be extended to non-plain vanilla transactions where the settlement details are known at the outset, based on business rules which will facilitate cross matching of different instruction types. These business rules also provide a basis for administering cancellations where market practice is divided between bi-lateral and unilateral cancellation for repo. Subject to market consultation, this solution could be extended to allow matching of the single message type with another single message type, or DVP/RVP, where not all settlement details are known at the outset for the far leg of a repo transaction. For convenience, this situation is referred to as a Temporary Instruction for the far leg. This proposal addresses only settlement related requirements and is not intended to provide a trade matching service or replace the value added role of CSDs and some trading platforms in arranging and/or administering repo transactions. Summary of Pros and Cons The following is a summary of the Pros and Cons of the compromise solution of allowing a single instruction for plain vanilla repo transactions only. It is included as a point of reference to understand the differences in the two methods of instructing and to highlight some issues using plain vanilla as a point of demarcation. Pros: Allows participants to choose which message type they submit according to current market practice (in domestic markets) and operational convenience. When required (according to market practice, legal jurisdiction) the single message provides a greater degree of certainty and control because it ensures a) matching (i.e. agreement) at outset to both legs of the repo transaction and b) prevents the far side settling before near the side settles. 1
Cons: No clear definition of plain vanilla. Cannot be mandatory as participants in international markets or domestic markets where two messages are currently in use will choose to continue to use separate RVP/RVP messages for plain vanilla. Counterparties in those markets currently using a single message will continue to use this instruction type for non plain vanilla if settlement details are known at the outset. Even where settlement details are not fully known at the outset the counterparties may prefer to match without completing all settlement fields until these are known nearer the settlement date for the far side. CSDs and trading platforms are able to calculate non-plain vanilla. Why restrict them from entering these instructions as a single instruction message? In cross border transactions one or other of the counterparties may need to compromise on which instruction type to use. Probable cause of failing to match and operational errors. The likelihood and cost of operational errors is especially high with repo transactions (short trade cycle, high value, complexity). Proposed solution Technically it is feasible to force participants to use one or the other instruction type and to only match within the same instruction type as per the Euroclear SSE. However, the business model for Euroclear differs from T2S. 1 From, the above summary of Pros and Cons it can be concluded that it is problematic to compartmentalize according to: Transactions: plain vanilla from non-plain vanilla Participants: those who habitually use a single message from those who use separate DVP/RVP. Markets or market practice: due to cross border settlement activity in T2S. Instruments: There are different types of fixed income instruments which could be considered under plain vanilla. Any solution must be generic in order to be able to handle collateralized transactions in any instrument (debt, equity etc.) Therefore, any compromise solution must find a way to effectively reconcile the use of either instruction type, by one or both of the counterparties to a transaction. In concept, it should be possible to accommodate the use of both a single message and two instructions (DVP/RVP) provided T2S has the functionality to recognize and cross-match the different instruction types and control their release for settlement. This functionality could be delivered using the following elements: 1 The situation in T2S differs from that in Euroclear because T2S allows individual CSDs to be Investor CSDs for all T2S eligible instruments and participants can choose which CSD to use irrespective of the domicile of the securities. However, Euroclear Domestic CSDs offering settlement in Central Bank Money can only be investor CSDs for their own domestic securities. Euroclear participants must open accounts at each domestic CSD or concentrate activity in the Full Service of Euroclear Bank. Therefore, in Euroclear, domestic repo business, using the single message, will probably continue as today within each CSD. On the other hand, the use of separate DVP/RVP instructions is likely to remain more prevalent in the ICSD, cross border business, of Euroclear Bank. Because T2S seeks to offer a more open architecture for cross border settlement, in order to open up competition between domestic markets, it is incumbent upon T2S to find a technical means of reconciling these two business models. 2
1. Use of a specific flag on DVP/RVP instructions to indicate that the instruction is a repo (as per current ISO standards). 2. Transaction linking for DVP/RVP. However, this functionality must be able to link both a delivery to a receipt as well as a receipt to a delivery so that it can be used by a counterparty irrespective of which side of the transaction the counterparty is undertaking (repo/reverse repo). 3. New matching business functionality for repo instructions to report specific status on cross matched instructions. Cross matched in this proposal means the matching of a single message type against linked DVP/RVP repo instructions. 4. New binding matching/cancellation business rules for repo instructions to cater for different market needs. In addition, the single message could be extended to non-plain vanilla where settlement details are known at the outset. Where settlement details are not known at the outset then T2S should consider the possible use of a Temporary instruction as a template for the far leg, subject to market consultation. Taking these elements together three scenarios can be identified: 1) Two single messages: Both counterparties submit a single message covering both the near side and far side of the transaction. This may be a plain vanilla repo or a nonplain vanilla repo. Note: In the case of Temporary Instructions, where not all settlement fields are known, T2S would match only the fields which had been input. However the fields input by either counterparty would be mandatory matching fields (i.e. if a settlement date is input on the far side then this must be matched but a countervalue may be left blank by both counterparties and this would be reported as matched). 2) Matched separate DVP/RVPs: Both counterparties can submit two instructions independently (DVP/RVP) with or without the repo flag. TG2 has already specified that the repo flag is a non-matching field. 3) One single message versus separate DVP/RVP: One counterparty enters a single message and the counterparty other enters two instructions (DVP/RVP). The first two scenarios are relatively standard. A compromise solution is required in the case of the third scenario to provide a bridge between participants in, for example, a cross border transaction who use different ways of instructing and managing a repo transaction. In the third scenario, it is proposed that T2S would try and match the DVP/RVP instructions against the single instruction if the following elements were present on both of the DVP/RVP instructions: 1) Both of the instructions had the repo flag. 2) The instructions were linked (i.e. they have a common reference and/or flag which allows them to be identified as linked for settlement purposes but which can also be used to link them for matching purposes). If a single message can be broken down into both a near side and far side DVP/RVP and matched on both sides with separate RVP/DVP instructions bearing the repo flag and which are linked, then T2S can report both the single message and the two separate RVP/DVP instructions as matched. 3
When a single instruction is matched in this way with separate DVP/RVP instructions then the matching should be binding as with matching of two single messages. Cancellation in this case should be only be by bi-lateral agreement because the counterparty entering the single message has done so in order to match for the purpose of agreeing to both legs of the repo contract at the outset in a way that is binding upon the counterparty. Because matching is binding in this case, then T2S will need to report that the DVP/RVP instructions have been matched under those conditions. It can reasonably be assumed that the counterparty entering the separate DVP/RVP instructions by implication agrees to matching being binding by both entering the repo flag and linking the instructions, knowing that his counterparty may/is likely to enter a single message owing to the nature of the transaction, domicile of the counterparty and/or known operational preferences. In the case where T2S tries to match eligible (repo flag + linked) DVP/RVP instructions against a single message and only the near side or far side match then this event could be reported as a distinct matching status (i.e. unmatched on near side only/unmatched on far side only). This will alert the counterparties to the precise nature of the problem and enable them to take action to rectify the problem leg of the transaction. Otherwise, the individual unmatched instructions would be reported as allegements, leaving it to the counterparties to identify the possible pairings on both legs and the leg where there is a matching problem. In order to allow for the business requirement to be able to execute unilateral cancellation of a repo instruction after matching it is proposed to allow unilateral cancellation where the repo flag is entered by both counterparties on separate DVP/RVPs only. The use of the repo flag distinguishes these DVP/RVP transactions from ordinary trade related instructions which would be subject to binding matching. Thus, where neither counterparty has entered the repo flag on a DVP/RVP or only one counterparty has entered the repo flag, then matching should be binding as per a normal DVP/RVP transaction. In this case, a counterparty who may wish to cancel the far leg of a repo transaction (i.e. in case of roll-over) would use the repo flag on a DVP/RVP instruction. However, both counterparties must use the flag for unilateral cancellation to be permitted in T2S. In the case of non-vanilla repo where the settlement details are not known, it should be possible for a counterparty to enter a Temporary instruction as a separate DVP/RVP for the far side and to match this against the far leg of a single instruction provided the repo flag is used together with transaction linking. In this case the Temporary instruction should be able to be amended (with settlement information) and re-matched prior to settlement of the far leg. In the case that the far leg of the transaction fails to be enriched with the required settlement information or fails to match on the enriched settlement information, then the original matching of the Temporary instruction should be deemed sufficient to evidence agreement on the far leg of the transaction as a basis for the counterparties to resolve any settlement differences. It is recognised that in providing the functionality to match Temporary instructions, T2S is not providing a full trade matching service because matching in T2S is restricted to a subset of the input needed for settlement purposes and would not be intended to cover other trade related details (i.e. reference information for rate fixing). Operational implications for participants 4
Any solution requires some changes to current operating practices. The proposal aims to minimise these for participants by T2S undertaking a process which will reconcile divergent market practices. Current users of the single message The proposal enables these participants to be able to continue to use their existing single message. However, further market consultation is required regarding the extent to which this instruction type could be extended to non-vanilla repo including transactions where the settlement details are not fully known at outset. These participants may be obliged to enter separate DVP/RVP when executing repo transactions in the cross border / international market. Today they face the same situation when instructing for settlement a) in a CSD where a single message is not currently used (i.e. CBF in the case of Germany) and b) in an ICSD. Current users of separate DVP/RVP instructions The proposal requires these participants to amend the way that they use separate DVP/RVP instructions as follows: Use of repo flag. This input field would be in accordance with ISO standards. In practice, participants would need to use the flag to ensure matching with counterparties who use the single message and to allow for unilateral cancellation in the case of counterparties who do not use the single message. This functionality may lead to the following situations: o A Participant using the repo flag wants to have the possibility of unilateral cancellation but matches with a counterparty using the single message. Matching therefore becomes binding. o A participant using the repo flag wants to have the possibility of unilateral cancellation but matches with a counterparty that uses separate DVP/RVP but without inputting the repo flag. Matching therefore becomes binding, as per normal trade matching. It is concluded that in both situations only one of the counterparties actually wanted the possibility of unilateral cancellation and that the proposed functionality imposes the standard of binding matching in this case, as with normal trade related instructions. If the counterparties want the possibility of unilateral cancellation then they must both enter separate DVPs/RVPs with the repo flag. A further situation is possible where a) the counterparties require binding matching and b) want to identify the transaction as a repo transaction (i.e. for income compensation purposes) but use separate DVP/RVP instructions. The proposed solution does not allow for both requirements if separate DVP/RVP instructions are used rather than the single message type. However, the use of separate RVP/RVP instruction types is most usual in those markets where matching is not binding. Therefore, it is assumed that participants using DVP/RVP would accept that matching would not be binding in this case, especially as they have a choice which instruction type to use. Use of transaction linking. Generally, this is a new element for repo transactions. Participants will be required to use it if they want to be able to match with participants who use the single message. It is considered that the use of the transaction linking field will, in addition, benefit the market in that it will avoid the possibility that the far side of a repo transaction can settle without the near side having settled. 5
New matching status on repo transactions matched or unmatched against single transaction type. This additional information requires different processing but is intended to assist participants to resolve matching problems. Note on URD updates required Apart from the specific requirements for repo transactions it should be noted that T2S has yet to fully elaborate the rules for: linking of instructions and for matching of Temporary instructions, although these are in scope. Note: Temporary instructions are known currently as Grey Market transactions in the context of the Primary Market but the functionality is generic to any instruction submitted for matching where not all of the settlement details are known at the outset and which can subsequently be converted to a settlement instruction. In the case of repo it is to be determined whether there is a requirement for process indicators (for example, indicators regarding the maturity conditions or conditions regarding interest calculation) to be matched in addition to matching fields used for settlement, without entering into a full trade matching service on T2S. Matching on process indicators may be a market requirement in the case of Temporary instructions where actual settlement data is incomplete but there is a requirement to agree on the basis of the transaction. The proposed solution avoids that T2S is required to calculate any data. T2S will not automatically calculate the return leg of the repo. The proposed solution must allow that a CSD, CCP, Stock Exchange or trading platform can submit already pre-matched instructions using either the single message or separate DVPs/RVPs. 6