DG PAYMENT SYSTEMS AND MARKET INFRASTRUCTURE 19 December 2006 DRAFT WORKING DOCUMENT ON TARGET2-SECURITIES THE FUNCTIONAL ARCHITECTURE This draft working document on TARGET2-Securities (T2S) has been prepared in view of the discussion with market participants during the 18-19 December 2006 meeting. Its aim is to present the functional architecture of the system. The users connectivity options as well as settlement of the cross-csds transactions are also covered. 1. A High Level Overview of T2S This high level description, in combination with the expected Operational Feasibility, presents the functionalities necessary at T2S for the provision of efficient securities settlement services to CSDs. The custody and value added services which are processed and initiated at the CSD level, have an impact on T2S operations in so far as they can result into changes in the securities accounts balances maintained at T2S (see Fig 1 & 2). The CSDs will instruct T2S to perform the related settlement activities. T2S will provide specific instruction types for this purpose which would be restricted to the CSDs only. Within the proposed T2S business model, a high level overview would distinguish between three main building blocks: o o o the T2S settlement engine and transactions database (including the lifecycle management); the dedicated sub-cash accounts and interactions with TARGET2; the securities accounts database(s) and interactions with CSDs. The first refers to the core functionality of the System, the platform responsible for checking availability of cash and securities and eventually executing final settlement in the securities accounts and the cash
accounts database. The second is a database of the cash accounts to be used during the DvP processes and how it interacts with TARGET2. The third is the set of all securities accounts opened with the participating CSDs and operated at the T2S level. Figure 1: An overview of T2S Securities Accounts SETTLEMENT INSTRUCTIONS Cash Accounts CSD CSD A CSD A SECURITIES T2S T2S SETTLEMENT ENGINE NCB A CSD CSD B CSD B SECURITIES NCB B TARGET2 (Cash) (Cash) Participant CSD CSD C CSD C SECURITIES NCB C T2S The dedicated cash sub-accounts are legally part of the RTGS account opened in TARGET2 with the NCBs, but are technically dedicated to T2S. Their functioning is independent; i.e. T2S settlement engine can only debit and credit these dedicated sub-accounts. The CSDs participants can chose to move liquidity in and out of these sub-accounts at any time using the TARGET2 Ancillary System Interface (ASI) settlement procedures 1. At the end of the day all liquidity is pooled back into the main TARGET2 RTGS account to which they belong in order to process end-of-day cash treatments. 2. Functional Description Looking into a more detail level analysis of the T2S, we may distinguish between two main functional blocks: the Lifecycle Management and the core Settlement Engine (see Fig. 2). The T2S Static Data constitutes a third rather static functional block and includes the CSD specific rules for settlement. It is supporting the operations of the other two. Lifecycle Management 1 Settlement procedure1 for real-time transfers and settlement procedure 6 for reservation of liquidity. Page 2 of 8
Lifecycle Management covers 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, matched, unmatched, settled etc). Depending on the current lifecycle status, and on the underlying market rules, an instruction will be moved into the various modules. The following functional modules will be included: Validation to check that incoming messages are well instructed. The rules against which instructions are validated are the ones maintained by the CSDs in the T2S Static Data databases (see Fig. 2) Matching to match instructions (if not already matched at CSD level) Settlement eligibility this module is at the boundary between eligible and non-eligible instructions. It verifies whether an instruction is eligible for settlement (depending on settlement date, deadlines, market closing, etc.) and then hands it over for settlement, or sets back instructions that are no longer eligible (e.g. due to deadlines passing by) to a non-eligible status. Instructions Maintenance updating & changing instructions parameters (e.g. prioritisation etc) Purging - remove instructions out of the system at the end of day Settlement Engine The following modules apply exclusively on instructions that are eligible for settlement and form the core of the settlement engine: Sequencing: Prioritising & Proposing to settlement to define the order in which matched instructions are proposed to the settlement engine Recycling to decide when instructions that failed in their first attempt will be proposed again for settlement. Recycling will propose these instructions to the sequencing module. Optimization to identify linked set of (failed) instructions which could settle according to certain technical netting procedures. Optimization will propose these linked sets to the Sequencing Module. Booking this is the part that breaks down instructions into movements, tries to provision them and finally perform the bookings if possible. This is the only place where account balances can be changed. The T2S Static Data functional block is accessed only by CSDs via the Authorisations Interface. It includes only stocks of data relevant for the processing of settlement in T2S. These data include amongst others updated information on valid participants accounts, active ISINs and access and rights for CSDs participants. Page 3 of 8
Interfaces One can differentiate between three kinds of data groups to be stored and processed in T2S: the settlement instructions, the balances stored on the securities and cash accounts and the authorizations (i.e. the information on which kind of securities are admitted for which kind of settlement, as well as the account setup information, and the connectivity setup of the respective customer). Figure 2 gives an overview on how the relevant data (on instructions, balances/holdings and authorizations) relate to each other. Three different interfaces are required for the interaction between T2S, CSDs and the users 2 : Instructions interface to instruct, to query on the status of and to maintain instructions. Authorization interface, to authorize or maintain accounts, ISINs and customer s access rights. Accounts Balance interface, to query account information, and to monitor accounts. Payment System Interface, to allow CSDs participants to transfer liquidity between the dedicated subcash accounts located in T2S environment and the main RTGS account located in TARGET2 (cash), if and when required. The first three interfaces are primarily for the CSDs to use, but CSDs can give its participants limited access to the Instructions and Accounts Balance Interface. The Payment System Interface is only relevant for users maintaining a TARGET2 RTGS account. Figure 2: A high level functional description of T2S TARGET2-Securities Customers CSD / Participants Exchanges / CCPs CSD B CSD A PARTICIPANTS Customers data SECURITIES CSD A ISINs and ISINS data Instructions Interface Instruct Query Status Maintain Instruction Account Balances Interface Query Monitor CSD AUTHORIZA- TION INTERFACE Set up / change / maintain Participants Securities Rules Lifecycle Management and Matching Instruction ready for settlement SECURITIES CSD A CSD B CSD CSD PARTICIPANTS CSD CSD A CSD CSD B Optimization procedures Settlement Engine SECURITIES CSD CSD A CSD CSD B Information on status RULES CSD CSD A CSD CSD B CASH CASH NCB A NCB B NCB NCB C SETTLEMENT AGENTS CSD A NCB A CSD A NCB B Payment System Interface TARGET2 NCBs T2S Static data 2 Users are defined as CSDs participants Page 4 of 8
A typical settlement transaction referring to a plain vanilla DvP OTC trade could be described as follows: Instructions will enter the T2S system via the Instructions Interface. If not already validated and matched at the CSD level, these functions will be performed at the T2S level. The T2S Static Data will provide the reference information for the instructions validation. The Lifecycle Management and Matching will provide the functionalities required for the Lifecycle of a settlement transaction (validation, matching, settlement prioritisation etc). Ready to settle transactions will be forwarded to the Settlement Engine for checking availability of securities and cash balances. If enough balances are available, final and irrevocable transfers of cash and securities will be executed in an RTGS mode. If there are not enough balances (either for lack of cash or securities), pending transactions will be re-entered for settlement via pre-specified optimization procedures and self-collateralisation. Instructing parties (CSDs and users) will be notified accordingly via the Instructions Interface. The Account Balances Interface will provide reporting on the securities holdings. The Authorizations Interface will provide CSDs with the functionality of updating the static data necessary for the settlement process (e.g. authorised CSD participants, valid ISINs, market specific rules for the Life Cycle Management etc). An interface with TARGET2 will allow users to insert and withdraw central bank liquidity in and out of the T2S cash accounts. The same interface includes NCBs static data on cash accounts (account holders). T2S Functional Blocks The picture below shows how the different Functional Blocks and modules interact with each other. A few explanations need to be added: Real-time interfaces to the Static Data databases are required, to accommodate any change in securities reference data, in customer authorizations, or in schedules and deadlines. Changes in static data have eventually to be applied to all modules, but during settlement processing, they mainly affect the lifecycle management. In the picture, instructions are split between eligible and non-eligible ones, whereas in reality they remain in a common database. Instructions maintenance can be performed as well on eligible instructions, but with a subset of potential activities. Figure 1: An Overview of T2S main Functional Blocks Page 5 of 8
Validation Matching Static Data Manager (1) (2) Matching & Lifecycle Management Engine Lifecycle Management Instructions Instructions not yet/ no longer Settlement Eligibility (4) (8) (3) (5) (11) Instruction Maintenance Purge & Archive Regulatory Reporting Settlement Eligible instructions Engine (10) (6) (9) Recycling Sequencing Optimization Securities accounts Feed back (7) Booking Propose for settlement Cash accounts A typical data flow in a straight plain vanilla OTC trade would be the following: Settlement instructions captured via the Instructions Interface (Section 1.7.2) are processed in the Validation Module (1) according to the rules and restrictions stored in the T2S Static Data Module via the Static Data Manager (3). Once validated, instructions are matched in the Matching Module (2). Whatever the outcome of the matching process (successful or not) instructions may be affected/by the Instructions Maintenance Module (4). Successfully matched transactions are moved to the Settlement Eligibility Module (5) where they are checked for their eligibility to be settled (e.g. check settlement date, blocked instructions etc). Once the status of settlement eligibility has been assigned, instructions are prioritised in the Sequencing Module (6) and processed, in RTGS mode, for the final settlement (cash and securities) in the Booking Module (7). Assuming successful settlement in both securities and cash accounts (DvP Model 1) transactions are reaching their final stage of their lifecycle management and are eventually purged and archive via the relevant module (8). In the case of failed settlement transactions are moved to the Optimisation Module in order to be optimised according to the T2S optimisation rules (9). Following Optimisation instructions are recycled (10) and re-entered in the Sequencing and Booking Modules for the purpose of completing RTGS final bookings. Page 6 of 8
For reasons of simplicity instructions reporting is not covered here. In some of the transaction lifecycle s stages immediate reporting to the instructing entities is required. (More on the reporting interfaces and modes and frequencies are covered in the Feasibility Sudy). This instructions reporting is not to be confused with the regulatory reporting facility for the CSDs (11). Connectivity CSDs will be directly connected to and communicate with T2S. The CSDs participants will connect to the T2S via their CSD, i.e. the CSD with which they legally hold their accounts. This is particularly relevant for smaller local participants and within the first period of T2S production. CSDs participants may see the need to have direct technical connectivity to T2S. In particular some major European custodians have already expressed their willingness to explore from day one of T2S s operation the possibility of direct connectivity to the centralised infrastructure 3. Whatever the strategy chosen by the market participants, the nature of their connectivity should be agreed and established in cooperation with the local CSD, i.e. the system with which the securities accounts are legally held. It is foreseen that all stakeholders of the settlement chain will cooperate on the basis of their mutual interests and will not abuse their controlling positions. Any restricting behaviour in particular will be counter-balanced by the open architecture of the T2S system and the expected improvement of the competition in the depository market (i.e. more opportunities for CSD participants to open securities accounts in any T2S connected CSD). In principle, the T2S architecture would be open enough to accommodate both direct and indirect connectivity options for market participants. As shown in Figure 1, whatever the model of connectivity, settlement instructions will only be managed and processed in the T2S environment by a single entry point: the T2S settlement engine. A Standard Communication Protocol will be used by T2S. This will be based on the ISO 15022/20022 standard for messages. (More on the standards to be adopted in T2S is presented in the Feasibility Study) Cross-CSD transactions It is generally accepted that an issuer CSD cannot unduly deny opening an inter-csd account to an investor CSD (unilateral outbound account). This point is reinforced recently by the EC Code of Conduct. To allow for cross-border settlement in TARGET2-Securities, all investor CSDs should be ready to open inter-csd accounts in all issuer CSDs. It is recognised that an investor CSD may not be ready to provide its participants custody services on all kinds of securities. Therefore, each investor CSD will specify which securities of a remote issuer CSD it 3 Here connectivity is meant only in technical terms. Legally, market participants they will remain direct participants only in their CSDs. Page 7 of 8
is ready to accept in its participants accounts. This implies accepting the handling of these securities and the related corporate actions as proposed in ECSDA s standard agreement. Participants may hold their securities in the CSD where they have been issued ( Issuer CSD ) or with any other CSD ( Investor CSD ) not being the Issuer CSD, provided that the Investor CSD accepts these securities. From a technical point of view, transfer of securities across national borders will take place as a change of holdings in a single database, see Figure 2. The transmission of a security from one participant in an investor CSD to another participant in another investor CSD would necessarily imply a re-alignment at the level of the issuer CSD. In other words, the issuer CSD should always know in which investor CSD the security is held. Re-alignment between securities accounts at the Issuer CSD level will take place in real time. This functionality will exceed the minimum requirements set by the ECSDA standards (at least end of day re-alignment). T2S should also provide the possibility for participants to settle securities issued in CSDs not connected directly to T2S (external CSD). (The issue is currently under analysis in the T2S Feasibility Study). Page 8 of 8