CLASSIFICATION DIRECTLY CONNECTED PARTIES IN T2S

Transcription

1 T2S PROGRAMME OFFICE ECB-UNRESTRICTED 11 June 2013 Item /2013/ CLASSIFICATION DIRECTLY CONNECTED PARTIES IN T2S Background The T2S Advisory Group (AG) in February 2013 invited the T2S Programme Office (PO) to provide a background note on the classification of DCPs (Directly Connected Parties) in T2S. In this note, the PO briefly analyses the different categories, as suggested by the AG members in their February meeting, in which a T2S Actor is deemed as a DCP. The aim of this document is to trigger a discussion in the T2S Advisory Group on the business roles a DCP may undertake in T2S without jeopardising the technical DCP concept as described in the following chapters 1 and 2. The legal point of view is not mentioned in this note specifically, but can be found in the November AG note Conditions for DCPs : As basis to this note the AG in February 2013, discussed the conditions for directly connected parties in the following note: 1 What is a DCP? The Framework Agreement establishes that Directly Connected Party (DCP) means a T2S User 1, which has been authorised by its Contracting CSD or Central Bank to access T2S directly to use T2S Services, i.e. without the need for the Contracting CSD or Central Bank to act as a technical interface (which would in this case be termed an indirectly connected party ). 1 T2S User: T2S User defines a legal entity that has a contractual/legal relationship with a CSD, which has entered into a contractual relationship for the use of T2S. It also defines a payment bank (DCA Holder), providing liquidity through an RTGS account in RTGS system to a financial institution, settling in T2S.

2 The term directly connected party refers to the technical connection to the T2S platform: Direct Connectivity refers to the existence of a (direct) network connection between a T2S Actor and the T2S platform using a VAN Provider, Dedicated Link or Internet 2. Any participant of the CSD or Central Bank has the possibility to connect to T2S via direct connectivity. E.g. Banks, custodians, CCPs, stock exchanges, trading platforms, as well as CSDs as participant of another CSD in T2S. To become a DCP is subject to authorisation of the each CSD and/or NCB whose services the T2S Actor is wishing to use as a DCP. A DCP can communicate technically with T2S without using the relevant CSD or Central Bank as a relay or proxy (e.g. sending settlement instructions, receiving status advices, querying data etc.). A CSD and/or Central Bank participant could be a DCP for all or only for certain T2S services, subject to the authorisation of the CSD and/or NCB whose services the T2S Actor is wishing to use as a DCP. For example, a participant could be a DCP for queries, reporting, sending of settlement instructions or cash instructions separately or for all these T2S services at the same time. Furthermore, being a DCP in one CSD does not automatically imply becoming a DCP on the cash side (i.e. in one or several NCBs) or in other CSDs while at the same time being a DCP in one NCB does not automatically imply becoming a DCP on the securities side (i.e. in one or several CSDs) or in other NCBs as well. From a T2S perspective, in order to become a DCP, a participant of a CSD or Central Bank needs to meet the following conditions: The DCP will have to adapt its technical communication interface to the T2S platform. For A2A access, it will have to comply with the T2S message format and use one of the T2S authorised communication channels (VAN-NSP providers SWIFT or SIA/Colt or via the T2S Dedicated Link). For U2A access, the DCP has to use one of the T2S authorised communication channels (VAN-NSP providers SWIFT or SIA/Colt or via the T2S Dedicated Link) or internet 2. 2 There are limitations for the usage of the T2S Internet connectivity and cannot replace the official connectivity options (VAN/DL) as specified in the T2S URD and the Framework Agreement. Page 2 of 8

3 Any participant that wants to become a DCP in T2S has to be certified by the Eurosystem. For that purpose, the participant shall complete the Eurosystem certification test scenarios that are identical for all markets and will be defined by the Eurosystem. These tests that need to be performed are a limited number of extended connectivity tests and will thus depend on the connectivity channel to be used by the DCP. DCPs that plan to use the A2A interface will likely have more extensive tests than DCPs that would want to use T2S only via GUI (U2A). The DCPs are bound through the contracts they have with their CSDs and/or Central Banks. Therefore each CSD and Central Bank may define additional conditions under which they will accept their participant to become a DCP for each part of the service they offer. For that purpose, the CSDs and Central Banks may define authorisation tests that their participants must complete. Being technically connected to the T2S platform is not enough for a CSD / Central Bank participant to take any action on the platform or use any service or function. Thus the functions a DCP can perform in T2S depend on the access that the CSDs and/or Central Banks will grant to the DCP. CSDs and/or Central Banks must grant access rights to their participant specifying exactly what the participant is allowed to do on T2S and what it is not, resulting in different DCP profiles in different markets. The more T2S functionality a DCP wants to access, the more privileges it will require from its CSD or Central Bank. 2 How a DCP communicates with T2S T2S Parties have the possibility to directly communicate with T2S in two ways: Application-to-Application (A2A) interaction i.e. using ISO20022 messaging via DL-/VA-NSPconnections only (with SLAs) and/or User-to-Application (U2A) interaction using the T2S GUI via DL-/VA-NSP-connections (with SLAs) or secured (SSL+PKI) Internet 3 -based Access (only possible without SLA) The A2A access mode offers the majority of the T2S functionality, for example - Sending settlement instructions to T2S - Creation of static data in T2S, like Party, Securities Accounts, DCAs - Querying T2S for settlement instructions, account postings, account balances etc. - Receiving reports from T2S - Managing liquidity etc. The U2A mode offers access to the complete T2S functionality (including what is offered in A2A mode). However, certain functionality of T2S is offered only in U2A mode, for example - Maintaining relationship between CSD Participant and a Securities Account 3 There are limitations for the usage of the T2S Internet connectivity and cannot replace the official connectivity options (VAN/DL). Page 3 of 8

4 - Creating links between a Securities Account and a DCA - Maintaining static data in T2S - Set-up and Maintenance of Privileges and Restriction rules in T2S The functions which are only available in the U2A mode are mainly related to set-up activities which are performed by CSDs and Central Banks and therefore generally not applicable to DCPs. 3 Categories of DCPs from a technical point of view Based on the technical concept of a DCP and how a DCP can communicate with T2S from a technical perspective, a DCP can be classified into two technical categories: DCP using A2A (and potentially U2A) DCP using U2A only This categorisation is especially relevant for the Eurosystem certification. The Eurosystem certification test scenarios will be defined by the Eurosystem and will depend on the connectivity channel to be used by the DCP (limited extended connectivity tests). DCPs that plan to use the A2A interface will likely have more extensive tests than DCPs that would want to use T2S only via GUI (U2A). For the work to be conducted in the User Testing Sub-Group (Sub-Group of the PMG) with regards to the specification of the Eurosystem certification and their planning of the workload during the User Testing phase, an additional deadline (the DCP Communication mode indication " deadline) will be defined by the Eurosystem, by which all DCPs are expected to notify their intention to use the communication channel (A2A or U2A). In the technical context, it may also be relevant to categorise DCPs according to the access rights/privileges to T2S, which will be set-up by their CSDs/Central Banks. This categorisation could be relevant for the specification of the authorisation tests which will be defined by the CSDs and Central Banks. However, there is currently not enough information on this topic to conduct this categorisation. 4 Categories of DCPs from a business point of view The aim of the following chapter is to propose different categories of DCPs that might be relevant in practice from a business concept point of view to support potential DCPs in their preparation for T2S. 4.1 DCPs on the securities side ( Securities DCPs ) Securities DCPs with business relations to multiple CSDs ( Full DCP ) A Securities DCP with business relations to multiple CSDs is connected to T2S via one of the three network providers and will probably interface directly with T2S in the Application to Application (A2A) mode. Examples of this A2A / messaging communication with T2S are: - Send Settlement Instructions Page 4 of 8

5 - Receive status advices/confirmations - Query Information from T2S - Receive Reports In addition, the institutions will also be able to access T2S via the T2S GUI (User to Application mode), for example, to support an internal operation or for functions that are not offered by A2A. This type of DCP would typically be large institutions or banks with high volumes of securities settlement instructions such as CCPs, custodians, potentially trading platforms and other banks. The DCPs falling under this category will have to pass the Eurosystem Certification tests for A2A and U2A in the early stage of the Community testing of the migration wave in which they migrate to T2S for the first time. Completing of these tests in the first weeks of the Community testing stage is expected due to the nature of the required tests (extended connectivity tests) as this provides the basis for all later interaction with the T2S platform. In addition, they shall pass the authorisation tests defined by each CSD through which the institution wants to become a DCP during the Community testing stage of that CSD. These institutions would also be customers of more than one CSD. Due to this dimension, a representative of this category of DCPs needs to find answers to questions which are of multilateral nature (from multiple CSDs in potentially multiple migration waves) such as: How shall my institution ensure a consistent test plan across multiple CSDs belonging to the same or different migration waves? Will my institution be subject to CSD authorisation tests that may diverge from one CSD to another? Does my institution need to support parallel testing on different T2S test environments? Does my institution have to contribute to the migration of the CSD to T2S? Which procedure is my institution expected to follow in case of a crises situation? Which preparations have to be done on my institution s side? Securities DCPs with business relations to a single CSD For a Securities DCP with business relations to a single CSD, the same considerations as in the previous chapter would apply with regards to the Eurosystem certification and authorisation tests of the single CSD, if an interaction via A2A and U2A is envisaged. However, Securities DCPs with lower volume or Securities DCPs which primarily connect through their single CSD for their regular business could use only the T2S User to Application (U2A/Graphical User Interface) communication mode to connect to T2S (i.e. such Securities DCP would technically be considered an indirectly connected party for the A2A communication mode to T2S). Depending on the access rights granted by the CSD, this DCP can still be connected to T2S for full access rights or limited access rights (e.g. read-only access only for queries). Securities DCPs using U2A only will have to obtain the Eurosystem Certification only for the U2A communication mode. Also the CSD s Page 5 of 8

6 authorisation tests for U2A, if any, would depend on the operations the DCP will be allowed to do in T2S via U2A. Such institutions are typically customers of a single CSD. Due to this dimension, a representative of this category of DCPs needs to find answers to questions which are of bilateral nature such as: How will my CSD adapt to T2S and how that impacts my institution? What is my CSD s test plan for T2S and how that impacts my institution? When will my CSD migrate to T2S and whether my institution has to contribute to the migration? Will my institution need to adapt the existing A2A interface with my CSD? Which preparations have to be done on my institution s side? 4.2 Investor CSDs in T2S The Investor CSD (as a participant of another CSD in T2S) may be viewed as a DCP from the point of view of an Issuer CSD in T2S. Regarding the Eurosystem certification, the Investor CSD will have to pass the Eurosystem certification test scenarios applicable to all T2S Actors using the same connectivity mode. The Eurosystem certification testing only needs to be passed once, i.e. at the point of time that CSD connects to the T2S Platform for the first time (e.g. as an Issuer CSD or in the role of a Securities Maintaining Entity for its Issuer CSD business). With regards to the CSDs authorisation tests, the typical question is whether the (Technical) Issuer CSD may treat the Investor CSDs similarly to other participants and thus ask them to pass the applicable authorisation tests (or different tests applicable to the particular Issuer CSD-Investor CSD business relationship). Examples of the questions that a representative of this category of DCP might have are: As a participant of an Issuer CSD, what are the authorisation tests, if any, that my institution has to perform with the issuer CSD before the Issuer CSD migration? Will my authorisation tests with the issuer CSD be the same as for other participants of this Issuer CSD? Will my authorisation tests be the same across all CSDs that provide my institution access to a market? 4.3 DCPs on the cash side ( Cash DCPs ) A Payment Bank that is currently active as a TARGET2 participant (or participant of another RTGS system) may be a DCA holder in T2S as per the rules and conditions defined by the individual Central Bank as user of the T2S services. Page 6 of 8

7 The Central Banks as user of the T2S service intend to set up the access rights to DCAs for DCA Holders in a harmonised way. Thus in this case, from the T2S perspective, if DCA Holders have a direct network connection to T2S, they are considered as DCPs by T2S and are labelled as Cash DCPs. Similarly to the securities side, the Cash DCPs can communicate with the T2S platform via A2A and/or U2A. Cash DCPs will have to pass the Eurosystem Certification tests for A2A and/or U2A in the early stage of the Community testing of the migration wave in which they migrate to T2S. In addition, they shall pass the authorisation tests defined by the Central Bank using T2S in which books the DCA will be opened during the Community testing stage of that Central Bank. A representative of this category of DCPs needs to find answers to e.g.: What rights and obligations does my institution have in case I am a directly connected to T2S? How is liquidity management performed in the RTGS and in T2S using two separate access channels? How can the used technical infrastructure be adapted? Is my institution able to cope with the used standards and formats in T2S? What is my Central Bank s test plan for T2S and how does this impacts my institution? What preparations have to be done on my institution s side? How is my institution involved in operational procedures in normal and abnormal situations? Note: A DCA Holder only using the T2-T2S Interface (T2SI) (via A2A or U2A) for its T2S services via an already established connection is from T2S perspective an indirectly connected party, since the DCA Holder uses a Eurosystem Central Bank system (i.e. T2) to connect to T2S. 5 Conclusion The categorisation of DCPs is primarily driven by the business concept of a potential DCP. However this categorisation from a business point of view (chapter 4) does not jeopardise the technical DCP concept as described in the chapters 1 to 3 of this note. Depending on the DCP categories, different types of needs and questions might emerge. E.g. when the connection is used for a single activity, the needs of the DCP are of bilateral nature and should be manageable through the interaction with the respective CSD. However, when the connection is used for multiple CSDs, the needs of the DCPs are of multilateral nature. According to the T2S Programme Plan, it is expected that the DCPs on the securities side, especially those participants of CSDs who will connect via multiple CSDs, would declare their interest to the T2S Programme Office by 31 October 2013 ( DCP interest ). The Cash DCPs should declare their interest to the Eurosystem Central Bank in which books the DCA will be opened in time before their migration to T2S. This deadline is not applicable to CSDs who have signed the Framework Agreement, Central Banks who have signed the Currency Participation Agreement and (Eurosystem) and Central Banks that will sign the Page 7 of 8

8 Agreement for the use of T2S services in TARGET2, as they are de facto assumed to be DCPs. The deadline is also not applicable to Securities DCPs with business relations to a single CSD. In addition to the DCP interest deadline of 31 October 2013 specified above, as a next step, an additional deadline ( DCP communication mode indication") will be defined by the Eurosystem after consultation within the User Testing Sub Group. The purpose of this second deadline is to clarify the planning of the Eurosystem certification and usage of the communication channels (A2A/U2A) in T2S during the User Testing phase. Page 8 of 8