Need this Stats assignment to be done in next 4 hours.

8 March 2007

TARGET2-SECURITIES

THE BLUEPRINT

Table of contents

Introduction 2 1. Project Objectives 2 2. Perimeter of TARGET2-Securities 8 3. Functional Architecture 12 4. TARGET2-Securities Project Time frame 19

Address: Kaiserstrasse 29, 60311 Frankfurt am Main, Germany Postal address: Postfach 16 03 19, 60066 Frankfurt am Main, Germany Telephone: +49 69 1344 0 Fax: +49 69 1344 6000 Website: http://www.ecb.int All rights reserved. Reproduction for educational and non-commercial purpose is permitted provided that the source is acknowledged.

© European Central Bank, 2007

Page 2 of 20

Introduction

At its meeting on 6 July 2006 the Governing Council of the European Central Bank (ECB) decided to explore, in cooperation with central securities depositories (CSDs) and other market participants, the possibility of setting up a new service for securities settlement in the euro area, called TARGET2- Securities (T2S). Since then, the Eurosystem has been actively soliciting the views of CSDs and market participants. It is also carrying out an internal Operational Feasibility Study on the project. A high-level presentation on the methodology, the principles and the preliminary findings of this study has already been shared with the market via industry-wide meetings held in the ECB, including representatives from the European public authorities.

This paper presents a first blueprint of the T2S design that can be used for the formal market consultation, following the Governing Council’s decision in March 2007 to initiate the project.

It should be clarified at the outset that only the high-level principles of the project are presented here. For a thorough understanding of the legal, operational, technical and economic aspects of the project, reference should be made to the T2S Feasibility Study document(s) which will be published in parallel.

Section 1 describes the background to the proposal and the benefits that T2S would bring. Section 2 describes the perimeter of T2S and the scope of services it would provide. Section 3 presents how T2S would work. Finally, Section 4 presents the project’s time frame.

1. Project Objectives

Contributing to integration in EU securities settlement

Over the past decade, two trends have been apparent in the development of the European securities settlement infrastructure:

• There has been considerable progress in integrating settlement systems at the national level, with the result that in most EU countries, there is now just one settlement platform for all types of securities.

• At the EU level, some cross-border company mergers have resulted in bringing CSDs in different countries under common ownership (e.g. Clearstream and Euroclear Group). Although these mergers have the objective of integrating settlement platforms progress has to date been slow.

Consequently, while efficiency at the national level has improved, there is widespread consensus that more needs to be done at a cross-border level. It is particularly striking that, almost eight years after the introduction of the euro, the euro area still lacks an efficient, integrated securities infrastructure that would support the operation of a single financial market. This illustrates the difficulty faced by

Page 3 of 20

independent and competing organisations in coordinating solutions across multiple countries and involving many different participants.

The result of this fragmented infrastructure is that the cost of clearing and settlement is considerably higher in the EU compared to the US. Various studies (by CEPS, Giovannini, LSE/OXERA) have concluded that the price per cross-border transaction in Europe is between 2.5 and 5 times higher than in the US, with the cost per cross-border transaction between 1.5 and 4 times higher.

Increasing efficiency of settlement of securities transactions in euro

The implementation of TARGET2 presents an opportunity for the European securities industry to take a major step forward. TARGET2 will, for the first time, provide a single technical infrastructure that enables market participants to pool their euro liquidity across different countries. This will make it possible to bring together the payments associated with securities settlement across multiple CSDs. However, the benefits to banks of pooling liquidity are limited if TARGET2 has to maintain separate interfaces to multiple securities settlement engines in the various CSDs.

To maximise the settlement efficiency of securities transactions, two conditions need to be satisfied:

• a single cash account (that will allow for liquidity pooling) must be operated; and

• it should be possible to deliver in real time, simultaneously settling cash and securities on a single platform via common procedures.

The concept of T2S has emerged out of these requirements.

The most innovative element in this concept is that the securities accounts of multiple CSDs will be maintained on a single technical platform together with central bank cash accounts, while all other functions – notably, the relationship with intermediaries, investors and issuers and the management of corporate actions – remain with the CSDs, as is the case today. However, while this split is a radical one, it is also logical. Settlement is the most standardised process among CSDs activities. The relationships with intermediaries, investors and issuers, on the other hand, are much more heterogeneous, with numerous local variations. It is therefore possible to integrate the settlement process relatively rapidly, while allowing the eventual harmonisation of local market practices to take place at a later stage.

The Eurosystem is in a unique position in Europe, given that the euro area level is a truly operative decision-making framework that is just as efficient as any national level scheme. In addition, in seeking to overcome sectoral or national barriers that stand in the way of a more efficient market structure, is reassuming a traditional role for central banks in many countries*. This is entirely consistent with the mandates of the ECB and the national central banks (NCBs) of the Eurosystem. The provision of T2S is possibly the only solution that will allow existing national CSDs to continue to operate in a decentralised framework. In doing so, it provides the same service and functionality to all financial market users as a minimum in the euro area (and potentially in the whole EU/European Economic Area as well).

By maintaining CSDs’ current role in relation to intermediaries, investors and issuers, the project ensures that there will continue to be choice and competition in the provision of services; if anything, T2S will

Page 4 of 20

provide greater possibilities for choice and competition. Participants may choose among multiple CSDs to access securities through a single entry point based on a common Settlement Engine. This would be also true for other infrastructures (e.g. central counterparties (CCPs) and trading platforms) in respect of the Code of Conduct recently signed under the auspices of the European Commission. Issuers can also improve the liquidity and issuance cost of their securities by making them directly available to a wider range of participants via a single, potentially local CSD.

The ability of any bank (including international CSDs (ICSDs)) to offer securities settlement in commercial bank money will not be affected. The parallel provision of securities settlement services in central bank money and commercial bank money represents a stimulus for central banks to provide efficient services. This is as true for T2S as it is for TARGET2.

T2S shares the same objectives as other public initiatives in this field, most notably the European Commission’s Code of Conduct. The common objective is to improve efficiency and reduce costs through ensuring greater competition. The Code of Conduct pursues this objective through CSDs’ self- commitment to provide price transparency, to facilitate access and interoperability, to unbundle services and to separate accounts. T2S, on the other hand, approaches this issue from an operational angle. The two initiatives naturally reinforce one another, and for this reason the European Commission has stated its support for T2S right from the start. The European Parliament has also concluded that “until such time as an [integrated settlement] infrastructure may have been introduced, an ECB governance must be put in place”.1

The potential benefits for TARGET2-Securities users

Although the initial impulse for the T2S concept was the opportunity created by the TARGET2 payment system, the potential benefits go much further and affect a wide range of users.

• The settlement of cross-border securities transactions can be as efficient as domestic settlement, eliminating the cost disadvantages that have hitherto impeded the development of a single financial market especially when compared with the US one (see Chart 1). This will be achieved by bringing together the securities accounts of multiple CSDs (as well as dedicated sub-cash accounts of NCBs) on a single platform. The bookings for the transfer of securities between participants of different CSDs can all be made simultaneously, together with the cash movements. This eliminates the current highly complex and costly processes of interactions between various platforms, which are costly often not synchronised, entailing delays and could pose a risk in terms of failing to achieve

1 European Parliament Resolution on the ECB’s Annual Report 2005: “15. Welcomes the publication of the ECB's first report on financial integration in the euro zone, since this is vital both for putting across information concerning monetary policy and for financial stability; notes that, according to the ECB, financial integration calls for the integration of market infrastructures, in particular settlement-delivery systems; notes the intention of the ECB to create a settlement infrastructure; notes that, until such time as an infrastructure may have been introduced, an ECB governance must be put in place”.

Page 5 of 20

settlement finality. These shortcomings are responsible for the current unattractiveness of CSD links. T2S will also automate the realignment process between CSDs on a real-time basis without needing to use additional, often costly, procedures.

• T2S will propose the same pricing for domestic and cross-border settlements. All markets may operate in real time under the same settlement engine, thus allowing a faster reuse of securities and central bank money

• Competition would be fostered by pooling all securities that settle in central bank money in a single settlement engine accessible via multiple CSDs. At the same time, a decentralised structure is maintained whereby each CSD is responsible for maintaining its relationships with intermediaries, investors and issuers, as well as asset-servicing.

• As the European securities settlement industry could still achieve significant economies of scale, a single settlement engine with the volume scale of T2S could potentially lead to a substantial decrease in settlement costs on average. This is particularly the case for cross-CSD settlement. The economic feasibility of the project shows that this is possible despite the conservative working assumptions currently used in the calculations.

• A reduction in the number of settlement engines will decrease the CSDs’ infrastructure costs on the one hand, and the number of interfaces needed by market participants on the other. This is an additional factor which is reasonably expected to benefit infrastructures and users’ back office development and running costs.

• T2S will encourage CSDs to offer their participants the opportunity, if they choose, to centralise their securities holdings in one place. This will depend on the readiness of CSDs to hold securities issued in other CSDs, although it should be noted that CSDs will have an incentive to do so in order to improve their competitive position vis-à-vis their participants.

• Issuers may potentially reach a much wider set of participants while continuing to use the same CSD they are using today (and with the same procedures as today under their local legal and tax regimes). This effectively makes the euro financial market a domestic market that does not entail any additional costs. In addition, this will increase the attractiveness of securities, which are currently marginalised because of their national nature, by making them available throughout the euro market.

• Investors will obtain cheaper access to non-local securities, which today requires prohibitive cross- border settlement procedures, and will therefore benefit from greater opportunities to diversify their portfolio. In addition, institutional investors will probably also benefit from lower fees to access the domestic market, while the share of infrastructure costs represents a significant part of the fees they pay to their custodians.

• The Eurosystem and its counterparties will also benefit from this efficiency in terms of using collateral in its credit operations. With cross-border deliveries becoming as efficient as domestic ones, a new generation of Eurosystem collateral handling procedures could be implemented.

Page 6 of 20

Improved Eurosystem collateral management could rationalise and harmonise Eurosystem practices in this field, in particular replacing the current correspondent central banking model (CCBM) procedures and multiple domestic procedures when securities are used for collateral purposes.

• Finally, by de facto introducing standardised euro area-wide settlement, T2S will significantly contribute to the momentum for further harmonisation in the financial markets. The successful introduction of T2S will further facilitate, even during its development phase, the current industry cooperation towards elimination of the remaining barriers identified by the Giovannini Report.

Although TARGET2 is a euro payment system, the problems of fragmentation and inefficiency are wider than in the euro area. T2S will therefore be designed in such a way (an open architecture) that it could later on provide settlement against other EU currencies, where there is market demand, and provided that the relevant NCB is prepared to enable settlement in its currency.

As far as the Eurosystem is concerned, this is a project unlike any undertaken before, as it reaches out beyond banks and payments systems into securities markets. The Governing Council has indicated that the Eurosystem is willing to finance and operate T2S, but it also recognises that it will need the cooperation and commitment of CSDs and securities market participants in order to deliver the service successfully. It is therefore looking at mechanisms to enable its project partners to participate fully in its design and development, in a way that appropriately links the degree of commitment with the level of involvement in decision-making.

Chart 1: Domestic and Cross border settlement costs in EU

0

5

10

15

20

25

30

35

United States

EU domestic

EU cross- border

Min Max Avg.

- EU dom estic costs range from 0.35 to 3.43 �€ ;

- �… and are higher than US

(+ 0.10 to 2.90 �€);

- Cross-border costs higher than dom estic ones (19.5 to 35.0 �€).

Source: O xera, LSE, CEPS

Conclusion

By providing a single platform for the settlement of the cash and securities legs of all the transactions today effected in the various CSDs, T2S will significantly contribute to increasing the efficiency of

Page 7 of 20

settlement and the integration of the EU capital markets infrastructure. A single platform will enable the settlement of all domestic and cross-border securities transactions.

It will also allow the potential benefits stemming from TARGET2 (cash) to be fully exploited, since this will complement the possibility of having a single pool of liquidity with that of a having a single entry point for the settlement of securities, providing cash and securities settlement in the same platform.

Page 8 of 20

2. Perimeter of TARGET2-Securities

Functional specialisation: custody and settlement

Two dimensions can be distinguished with regard to the functional organisation of the securities market infrastructure:

• the management of flows, including the trading, clearing and settlement functions as a result of the movement of securities (against or not cash);

• the management of stocks, involving the custody or asset-servicing function as a result of the relationship between issuers and investors (see Chart 1).

Chart 2: Two dimensions of CSD services today

INVESTOR CSD

INVESTOR CSD

SECURITIES SETTLEMENT SECURITIES

SETTLEMENT

TRADINGTRADING

ISSUER CSD

ISSUER CSDISSUERISSUER INVESTORINVESTOR

CCP CLEARING

CCP CLEARING

CeBM SETTLEMENT

CeBM SETTLEMENT

BANK & BROKER BANK &

BROKER

LISTINGLISTING

Management of Flows

Management of Stocks

Asset Services Corporate actions Investor information

A CSD today typically undertakes tasks related to both the settlement and custody functions. The proposed model represents an opportunity for CSDs to perform their securities settlement function in central bank money via T2S. The custody function (investor and issuer CSDs) will continue to be performed by the CSDs as is currently the case, including the responsibility for the notary function of issuance (see Chart 2). Other services such as settlement against commercial bank money and value- added business are not part of the scope of T2S.

Chart 3: Perimeter of T2S

Page 9 of 20

INVESTOR CSD

INVESTOR CSD

SECURITIES SETTLEMENT SECURITIES

SETTLEMENT

TRADINGTRADING

ISSUER CSD

ISSUER CSDISSUERISSUER INVESTORINVESTOR

CCP CLEARING

CCP CLEARING

CeBM SETTLEMENT

CeBM SETTLEMENT

BANK & BROKER BANK &

BROKER

LISTINGLISTING

EXCHANGE

CSD

TARGET2-SECURITIES

CLEARING HOUSE

A CSD has extensive relations to its home market stakeholders: the issuers, the investors directly or via the brokers and the custodian banks, the CCPs, the tax authorities, the supervisory authorities and the legislators. These relations require a range of asset-servicing activities that are typically adapted to local market conditions, for which the local CSD has long-standing expertise. The settlement function, on the other hand, only relates to the participants in the settlement process and to the cash clearing entity, the central bank and its participating banks.

Participants in the settlement process are often active in several markets. As a consequence, they have to build and maintain multiple connections to several systems, or have to route their transactions through more expensive custodian networks. The introduction of TARGET2 for cash settlement within the euro area has facilitated these connections for the cash side of settlement transactions. For the securities leg, however, these complex and costly connections remain.

The proposed management of the settlement and custody functions in separate platforms (T2S and asset- servicing platforms of CSDs) is motivated by the fact that settlement services are already highly standardised and easier to harmonise than the custody business. The latter is typically more complex and may take more time to harmonise owing to the national differences that exist with regard to custody, corporate actions and beneficial ownership (e.g. owing to different legal and tax regimes). The feasibility of this separation will be presented in detail in the operational and business analysis chapter of the T2S Feasibility Study.

To avoid parallel settlement and to allow CSDs to decommission their settlement platforms and systems, T2S needs to offer the same level of settlement services for the assets that CSDs settle in euro today.

Page 10 of 20

T2S scope of services

Within the context of the functionality described above, T2S will cover the following aspects in the services provided:

Scope of assets

T2S will provide settlement services for all securities (with International Security Identification Number (ISIN) codes) held through the participating CSDs’ accounts. These include debt instruments, equities, investment funds and warrants.2 Securities that are denominated in foreign currency but settled in euro will also be covered by T2S, provided they are held through a T2S-connected CSD. This implies that securities issued outside T2S could be settled through T2S, provided that a T2S-connected CSD has a link with the external issuer CSD.

Settlement type

T2S will offer an “optimised delivery versus payment (DvP)” settlement model. It will be based on real- time gross settlement (RTGS) procedures combined with self-collateralisation and continuous optimisation (including technical netting and other algorithms), as well as recycling mechanisms.3 Such mechanisms will compensate for situations where participants lack liquidity (e.g. self-collateralisation) or for complex transactions (specific algorithms for back-to-back transactions or chains of trades, for example). This innovative optimised DvP settlement model will maximise settlement efficiency in terms of liquidity, speed and safety.

In addition, free of payment (FOP) settlement and other types of securities settlement needed for CSDs to function effectively will be offered as well.

Scope of services

T2S will manage the entire settlement process by offering the following services:

• receiving settlement instructions4 and checking their technical validity against a static reference database (updated and controlled by the CSDs – the information checked will be defined with the CSDs);

• providing matching services, mainly for transactions conducted between participants of different markets;

• verifying the availability of and reserving securities and central bank money;

• managing queues;

2 This list of assets may not be exhaustive. 3 The details of the self-collateralisation procedure, e.g. the application of haircuts, assets and counterparties, are to be performed

in accordance with the rules defined by the Eurosystem and the relevant NCB providing the credit. Further analysis on the exact rules and procedures will be described in the next phase of the project.

4 T2S will accept unmatched or matched settlement instructions from CSDs, CCPs, stock exchanges or other organised markets, and possibly also market participants (users).

Page 11 of 20

• providing settlement optimisation mechanisms;

• offering self-collateralisation;

• executing debits and credits on securities accounts;

• performing automated real-time realignment of inter-CSD accounts where applicable; and

• reporting to CSDs and other participants on the status of each settlement instruction5 and the account balance.

Operating hours

T2S will offer daylight and night-time settlement in order to cover the range of services already provided by some CSDs. The daylight operating hours of T2S will be in line with the timetable of TARGET2. Similarly, T2S will perform night-time settlement during the same night-time period when TARGET2 supports the settlement of ancillary systems.

Currency

In principle, T2S will cover securities transactions settling in euro central bank money. This service will also be available to CSDs outside the euro area settling in euro central bank money. The design of T2S will also allow for the provision of securities settlement in other EU currencies, provided that there is market demand, and assuming that the relevant NCB is prepared to enable settlement in its currency.

Non-compulsory participation

T2S is a project that seeks to offer safe, efficient and competitive settlement services across all connected markets. Market participants largely support the project. However, the benefits for the market will only materialise if all CSDs, or at least a critical mass of them, join the project because of the greater competition it will introduce, even if this may run counter to their corporate interests in the short term.

At this stage, the Eurosystem believes that the pressure of the market and the quality of the solution proposed are sufficiently strong to convince all CSDs to follow the European integration approach. In this context, participation in T2S should not be made mandatory.

5 In case of direct user access (see footnote 1), T2S would also provide settlement-related information directly to the user as well

as to the CSD.

Page 12 of 20

3. Functional Architecture

A high-level overview of T2S

This high-level description, in combination with the more detailed Operational Feasibility Study, presents the T2S functionalities necessary to provide CSDs with efficient securities settlement services. The custody and value-added services which are processed and initiated at the CSD level have an impact on T2S operations insofar as they can result in changes in the securities accounts balances maintained via T2S (see Boxes 1 and 2).

As a consequence, the CSDs will instruct T2S to perform related settlement activities. T2S will provide via its interfaces specific instruction types for this purpose which would be restricted to the CSDs.

Within the proposed T2S business model, three main building blocks can be distinguished under the high- level overview:

o the T2S Settlement Engine and Transactions Database (including the Lifecycle Management);

o the dedicated sub-cash accounts in TARGET2;

o the Securities Accounts Database(s) and interactions with CSDs.

The first refers to the core functionality of the system, the platform responsible for checking the 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 dedicated cash sub cash accounts to be used during the DvP processes and how this database interacts with the RTGS accounts. The third is the set of all securities accounts opened with the participating CSDs.

Chart 4: An overview of T2S

CSD ACSD A

CSD BCSD B

CSD CCSD C

T2S SETTLEMENT

ENGINE

T2S SETTLEMENT

ENGINE

SECURITIES ACCOUNTS

TARGET2 CASH ACCOUNTS

CSD A SECURITIES ACCOUNTS

NCB C ACCOUNTS

T2S

SETTLEMENT INSTRUCTIONS

ParticipantParticipant

NCB B ACCOUNTS

NCB A ACCOUNTS

CSD B SECURITIES ACCOUNTS

CSD C SECURITIES ACCOUNTS

Page 13 of 20

The dedicated cash sub-accounts (Chart 4) are part of the RTGS accounts opened in TARGET2 with the NCBs, technically dedicated to T2S. They function independently; i.e. the T2S Settlement Engine can only debit and credit these dedicated sub-accounts. The CSDs’ participants can choose to move liquidity in and out of these sub-accounts at any time using the TARGET2 functionality (ICM and payment functionality) At the end of the day, all liquidity is pooled back into the main TARGET2 RTGS account in order to process end-of-day cash balances.

Chart 5: TARGET2 Dedicated Sub-account

Functional description

If we analyse T2S in more detail, two main functional blocks can be distinguished: Lifecycle Management and the core Settlement Engine (see Box 1). The T2S Static Data constitutes a third rather static functional block that supports the operations of the other two, and includes the CSD-specific rules for settlement. The current version of the Operational Feasibility Study also covers in some detail the level of functionality described below.

Lifecycle Management

The Lifecycle Management covers the lifecycle of an instruction, the different processes it can take within the system, and the related lifecycle status attached to these processes (e.g. validated, matched, unmatched, settled, etc.). Depending on the current lifecycle status and on the underlying market rules, an instruction will be processed within the following functional modules:

• Validation – This checks that the instructions of incoming messages are correct. The rules against which instructions are validated are the ones maintained by the CSDs in the T2S Static Data databases.

• Matching – This matches instructions (if not already matched at CSD level).

• Settlement eligibility – This module distinguishes 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 either hands it over for settlement, or returns instructions that are no longer eligible (e.g. due to expired deadlines) by assigning them a non-eligible status.

Dedicated cash

Sub-accounts

RTGS account

Managed via T2S functionality

Page 14 of 20

• Instructions maintenance – This updates the parameters of instructions (e.g. prioritisation, enrichment, etc.).

• Purging – This removes settled instructions from the system at the end of the day.

Settlement Engine

The following modules apply exclusively to instructions that are eligible for settlement and form the core of the Settlement Engine:

• Sequencing – This creates queues of instructions that are eligible for settlement in a way that optimises settlement results while also taking into account different levels of priority.

• Booking – This is the heart of the Settlement Engine, where the final bookings of the movements related to the instructions regarding the securities and cash accounts are performed. This is the only place where account balances can be changed.

• Optimisation – This identifies linked sets of (failed) instructions which could be settled if certain technical netting procedures are performed. Optimisation will propose these instructions as linked sets for processing in the Sequencing Module.

• Recycling – This determines when instructions that failed in their first attempt will be put forward again for settlement. Recycling will propose these instructions for processing in the Sequencing Module.

The T2S Static Data functional block can only be accessed by CSDs via the authorisations interface (see next section). The block purely includes stocks of data relevant for the processing of settlement in T2S. These data include updated information on valid participants’ accounts, active ISINs, and access and rights for CSDs’ participants.

Interfaces

Three kinds of data groups to be stored and processed in T2S can be differentiated: settlement instructions, balances stored on the securities and cash accounts, and authorisations (i.e. the information on which kind of securities are admitted for which kind of settlement, as well as the account set-up information plus the connectivity set-up of each customer).

Box 1 provides an overview of how the relevant data (on instructions, balances/holdings and authorisations) relate to each other. Four different interfaces are required for the interaction between T2S, CSDs and the users6:

6 Users are defined as CSDs’ participants.

Page 15 of 20

An instructions interface, which can be accessed by CSDs as well as some users. This will provide a bi- directional functionality in order to instruct settlement, to receive settlement status and feedback, to query the status of instructions, and to maintain and manage instructions.

An authorisation interface, which can only be accessed by CSDs. This provides the latter with the functionality to authorise securities and participants relevant for settlement.

An accounts balance interface, which can be uni-directionally accessed by CSDs as well as some users to query balance information and to monitor accounts.

A payment system Interface, which allows CSDs’ participants to transfer liquidity between dedicated sub- cash accounts located in T2S and the main RTGS account located in TARGET2 (cash), if and when required.

These interfaces are primarily for the use of the CSDs, although CSDs can give their participants limited access to the instructions and accounts balance interfaces.

Box 1: A High-level Functional Description of T2S

TARGET2-Securities

Lifecycle Management and Matching

T2S Static data

C us

to m

er s

/ E xc

ha ng

es /

CC Ps

C SD

P ar

tic ip

an ts

Account Balances Interface

• Query• Monitor

Instructions Interface • Instruct • Query Status • Maintain

Instruction CSD A

CSD A ISINS

SECURITIES ISINs and data

PARTICIPANTS Customers data

CSD B

CSD A CSD B

CSD A CSD A

RULES

CSD A CSD B CSD A CSD B

CSD A CSD A CSD A CSD A

RULES

CSD A CSD B

CSD A CSD A

SECURITIES

CSD A CSD B CSD A CSD B

CSD A CSD A CSD A CSD A

SECURITIES

Information on status

Instruction ready for settlement

CSD A ACCOUNTS

SECURITIES ACCOUNTS

CSD B ACCOUNTS

CSD…

CSD A ACCOUNTS

SECURITIES ACCOUNTS

CSD B ACCOUNTS

CSD…

CASH ACCOUNTS

NCB C ACCOUNTS

NCB…

TARGET2 CASH

ACCOUNTS

NCB…

NCB A ACCOUNTS

NCB B

ACCOUNTS

TARGET2 CASH

ACCOUNTS

NCB…

NCB A ACCOUNTS

NCB B

ACCOUNTS

Optimization procedures

Se ttl

em en

t En

gi ne

Optimization procedures

Se ttl

em en

t En

gi ne

N C

Bs

CSD AUTHORIZA- TION INTERFACE

CSD A NCB B CSD A NCB B

CSD A NCB A

SETTLEMENT AGENTS

•Set up / change / maintain

• Participants • Securities • Rules CSD A

CSD B

CSD A CSD A CSD A CSD B CSD A CSD B

CSD A CSD A CSD A CSD A

CSD PARTICIPANTS

A typical settlement transaction (e.g. a “plain vanilla” DvP over-the-counter trade) could follow this lifecycle:

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 reference information for

the validation of instructions. 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 where the availability of securities and cash balances will

be checked. 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 owing to a lack of cash or securities), pending

Page 16 of 20

transactions will be re-entered for settlement via pre-specified optimisation and self-collateralisation procedures.

Instructing parties (CSDs and users) will be notified accordingly via the instructions interface.

The account balances interface will report on the securities holdings. The authorisations 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 Lifecycle Management, etc.).

TARGET2 will allow users to add central bank liquidity to and withdraw it from the dedicated cash sub accounts.

The interaction of functional modules in T2S

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 authorisations, or in schedules and deadlines. Changes in static data eventually have to be applied to all modules, but during settlement processing, they mainly affect the Lifecycle Management.

• In the flow process example described below, instructions are split between eligible and non-eligible ones.

• Instructions maintenance can also be performed for eligible instructions*, but with a subset of potential activities.

Box 2: An Overview of the Interaction of the Main Functional Blocks in T2S

Page 17 of 20

Settlement Engine

Matching & Lifecycle Management Engine

Lifecycle Management

Instructions

Validation

Matching

Instruction Maintenance

Purge & Archive

Regulatory Reporting

Static Data Manager

Optimization Sequencing Recycling

Settlement Eligibility

Instructions not yet/ no

longer eligible

Eligible instructions

Booking

Feed back

Propose for settlement

Securities accounts

Cash accounts

1

2

3

4

5

6

7

8

9 10

11

A typical data flow in a straight “plain vanilla” over-the-counter trade would be as follows: settlement instructions “captured” via the instructions interface 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, 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 settlement eligibility (e.g. checking the settlement date, blocked instructions, etc.). Once they have been assessed as eligible for settlement, 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 (optimised DvP model), transactions reach the final stage of their lifecycle management and are eventually purged and archived 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). In case of successful optimisation, the instructions are then immediately put into the settlement queue via the Sequencing Modules. In case optimisation was not successful, instructions are stored and eventually recycled (10) and re-entered in the Sequencing and Booking Modules, according to the T2S recycling rules.

Page 18 of 20

For reasons of simplicity, instruction reporting is not covered here. In some transaction lifecycle stages, immediate reporting to the instructing entities is required. This is not to be confused with the regulatory reporting facility for the CSDs (11).

Annex 1 of the Operational Feasibility Study provides more detail on the functionalities and interactions of the T2S functional blocks and modules.

Connectivity

CSDs will be directly connected to and will communicate with T2S. Users (CSDs’ participants)7 will normally connect to T2S via their own CSD, i.e. the CSD with which they legally hold their accounts. This is particularly relevant for smaller local participants, especially within the first period of live operation of T2S. Users can also continue to send instructions in their proprietary formats. Their CSDs will be responsible for converting these instructions into the T2S harmonised standards (message formats, codification of securities accounts, etc.).

However, some users may see the need to have direct technical connectivity to T2S. In particular, some major European custodians have already expressed their willingness to explore right from the start of T2S the possibility of ensuring direct connectivity to the centralised infrastructure.8 Whatever the strategy chosen by the market participants, the nature of their connectivity should be agreed and established in cooperation with their local CSD, i.e. the system with which they legally hold their securities accounts. Within this scenario, directly connected entities must be able to instruct T2S according to the harmonised messages and standards, since T2S will not offer converting and mapping services.

All stakeholders along the settlement chain are expected to cooperate on the basis of their mutual interest and should not abuse their controlling positions. Any “restrictive” policies that are against the interests of the local settlement community will be counterbalanced by the open architecture of the T2S system and the expected improved competition in the depository market (i.e. there will be more opportunities for CSD participants to open securities accounts in any CSD connected to T2S). The Code of Conduct has a similar incentivation effect.

In principle, the T2S architecture should be sufficiently open to accommodate both direct and indirect connectivity options for market participants. As Box 1 shows, whatever the connectivity model, settlement instructions will only be managed and processed in the T2S environment by a single entry point: the T2S Settlement Engine.

7 CCPs, despite being part of the post-trading infrastructure, are also considered CSD participants for the purpose of securities

settlement. However, the functionality available in the T2S Settlement Engine will take into account the specific settlement requirements stemming from central counterparty netting.

8 Here connectivity is meant only in technical terms. Legally, market participants will only remain direct participants in their CSDs.

Page 19 of 20

T2S will use a standard communication protocol based on the ISO 15022/20022 standard for messages. (For more information on the standards to be adopted in T2S, see the Operational Feasibility Study.)

Cross-CSD transactions

It is generally accepted that an issuer CSD cannot refuse to open an inter-CSD account for an investor CSD (unilateral outbound account). This point has recently been reinforced by the Code of Conduct.

In order to achieve full coverage for all actors within T2S, all investor CSDs should be ready to open inter-CSD accounts in all issuer CSDs.

However, it is also recognised that some links may lack an underlying business case, or that an investor CSD may not be adequately prepared to provide its participants with custody services for all kinds of securities, at least not right from the start of T2S production. Therefore, each investor CSD will have to specify which securities of a remote issuer CSD it is ready to accept in its participants’ accounts. This implies accepting handling these securities and the related corporate actions as proposed in the standard agreement of the European Central Securities Depositories Association (ECSDA).

Participants may hold their securities in the CSD in which they have been issued (“issuer CSD”) or with any other CSD (“investor CSD”) that is not 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 (Annex 2 of the Operational Feasibility Study provides concrete examples of how these transactions will be handled in T2S).

The transmission of a security from one participant in an investor CSD to another participant in another investor CSD would necessarily imply a realignment at the level of the issuer CSD. In other words, the issuer CSD should always know in which investor CSD the security is held. Realignment 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 regarding end-of-day realignment).

T2S should also enable participants to settle securities issued in CSDs not directly connected to T2S

(external CSDs). (This issue is also covered in some detail in the Operational Feasibility Study.)

4. TARGET2-Securities Project Timeframe

Due to its complexity and wide range of specifications, it is foreseen that the T2S project will take between four to six years to materialise.

A tentative project timetable is presented, based on a six-year project.. A detailed and thoroughly documented time frame will be developed following the initiation decision alongside the preparation of the User Requirements.

Page 20 of 20

- Phase 1: User Requirements and Design (approximately 40% of the project workload; estimated to take place between Q2 2007 – Q3 2009). This phase will start with the Governing Council’s final decision to initiate the project. It includes the definition of the User Requirements and, as a next step, the first draft of the Detailed Functional Specifications (DFS) of the T2S functionalities. An extended engagement with CSDs and market participants is foreseen for this phase in order to ensure that services offered by T2S will enable, on the one hand, the design of an efficient pan-European infrastructure, and on the other the smooth functioning of the CSDs’ operations. Synergies with TARGET2 could help reduce the time needed for this phase. The definition of the non-functional requirements is also to be developed here.

- Phase 2: Development and Implementation (approximately 30% of the project workload; estimated to take place between Q4 2009 – Q3 2011). In this phase, the development and finalisation of the DFS would occur. This phase includes the application development of T2S and implementation steps, and the various units and modules testing at the project team level. Fine-tuning to the DFS could also take place at this stage.

- Phase 3: Testing and Deployment (approximately 30% of project workload; estimated to take place between Q4 2010 – Q1 2013). This final phase includes testing on module integration, interfaces, performance and back-up facilities. The supporting documentation (manuals, procedures, etc.) will be finalised during this phase, and user training will be conducted. The final user acceptance tests should be performed at the start of this phase.

Migration options

The various options and details relating to the gradual migration to the T2S environment, namely the move of the CSDs’ settlement function to the central system, should be discussed with the market. This migration could be based on the different jurisdictions (as in TARGET2) or on different assets (debt instrument vs. equities markets). This may be particularly relevant for new Eurosystem members that join the Eurosystem by the time that T2S goes into production.

Chart 6: Provisional T2S Project Phases and Timeframe

Phase 1 Phase 2 Phase 3

• Public Consultation • User Requirements • Detailed Functional Specifications

(DFS) • Architectural Specifications • Decision on Migration Policy

March 2007

• T2S Development & Implementation

• Units and Modules Testing

• Fine Tuning (DFS)

• UAT Testing • Integration,

performance, interface & back up testing

• Migration Options • Final Deployment

T2S

March 2013

Governing Council

Question/Question.doc

Maximum 5 pages (1.5 spaced); figures and/or tables are allowed on additional pages.

1. (60 points – maximum 3 pages)

Do the problem that is described in the attached Excel spreadsheet. When you do this problem, you are allowed to ask for help within your organization of a person, who is very well versed in Excel (or any other appropriate data analysis software). However, the person who would help you with the use of Excel should not assist you with regard to the design of your expressions or formulas or with the interpretation of the results.

When you experiment with your regression analysis, you have to decide on a trade-off between a relatively simple expression and an acceptable R-Squared. (Any one of the five KRIs may appear only in at most two of the (composite) factors in your expression.)

2. (40 Points - maximum 2 pages)

See the attached document that describes a trade settlement system and answer following questions:

a) Identify the potential points of failure in the trade settlement system described in the document.

b) Describe the types of events that can result in Operational Risk losses. Can you say anything about the frequencies and severities of losses? You may want to provide a qualitative discussion about the frequencies and severities, possibly as a function of total number of trades, the types of trades, or other system or environment characteristics.