SINGLE SHARED PLATFORM

SINGLE SHARED PLATFORM General Functional Specifications - ANNEX 1 A Document for users Version 1.13

Contents 1 Introduction... 1 2 General features and structure of TARGET2... 4 2.1 Principles of TARGET2...4 2.2 Concept of TARGET2...6 2.3 Features and advantages of TARGET2...7 2.4 Role of CBs in TARGET2...14 2.5 Scope and framework of TARGET2...16 2.6 Time schedule and milestones...22 3 Participation in TARGET2... 23 3.1 Direct participants...25 3.2 Indirect participants...27 3.3 Comparison of direct and indirect participation...28 3.4 Exclusion...29 3.5 Directories of the participants...30 4 Payment processing in the SSP... 32 4.1 Accounting...32 4.2 Payment types...36 Version 1.11 i

Contents 4.3 Payment interface...42 4.4 Payment flow...45 4.5 Payment processing - entry disposition...55 4.6 Liquidity management...62 4.6.1 Reservation facilities...62 4.6.2 Limits...66 4.6.3 Comprehensive queue management...73 4.6.4 Optimisation procedures...77 4.6.5 Pooling of liquidity: grouping of accounts...83 5 Ancillary system settlement... 89 5.1 Ancillary System Interface...89 5.2 Work flow of generic settlement procedures...98 5.2.1 Liquidity transfer...98 5.2.2 Real-time settlement...99 5.2.3 Bilateral settlement...100 5.2.4 Standard multilateral settlement...101 5.2.5 Simultaneous multilateral settlement...102 5.2.6 Dedicated liquidity...104 Version 1.11 ii

Contents 6 Information and Controle Module (ICM)... 109 6.1 Business approach ICM...109 6.2 Information and control measures in the ICM...113 7 Functional assumptions and service level requirements... 115 8 SSP infrastructure and availability measures... 118 8.1 SSP infrastructure...118 8.1.1 General architecture...118 8.1.2 The SWIFT Interface...121 8.2 Business continuity...122 8.3 Contingency measures...127 9 Operational model... 134 9.1 Operating times...134 9.2 Customer contacts...136 10 Migration issues... 138 Glossary and Abbreviations... I Version 1.11 iii

1 Introduction 1 Introduction The next generation of TARGET On 24 October 2002, the Governing Council of the ECB took a strategic decision on the direction of the next generation of TARGET (TARGET2). According to this decision, TARGET2 will be a multiple platform system based on the principles of: Harmonisation A single price structure applicable for the so-called core services Cost effectiveness No competition among its components TARGET2 as a project, which is open to non-euro area CBs of the EU, will consist of national components and of one "shared component". The latter will be an IT platform open to any of those central banks which decide to give up their own RTGS platform. In the first three years of its operation, TARGET2 will only have one possible shared platform. After this initial period, it should be left to the central banks to decide whether there is a need to create additional shared platforms. Single platform concept As from the decision of the Governing Council, the European System of Central Banks (ESCB) has undertaken much effort to elaborate on the future concept of TARGET. During the work, it became clear that only a Single Shared Platform will adequately respond to the needs of the European banking industry. Within this process, a growing number of central banks (CBs) showed their interest to renounce to their own systems and to participate in the SSP. In the light of the aforementioned decision of the Governing Council, Banca d Italia, Banque de France and Deutsche Bundesbank (3G) have declared their intention to co-operate on the development of the new payment system which is intended to be a common offer for the TARGET2-SSP, which should be a fully fledged RTGS system, going live by 2 January 2007. It is assumed at present that all CBs will participate in the SSP. Version 1.13 1

1 Introduction Consequently, the following proposal is based on the idea of having only "one single shared platform, that will be operated by the 3G under the control of all participating central banks including the European Central Bank. Functional specification Content of this document The current document is based on the input received from the TARGET user community during the public consultation and from the European banking community after delivery of its first version. It should be noted that even if some functionality (eg related liquidity pooling and settlement of AS) will need further investigation, this current document has to be considered as the final proposal of the Eurosystem for business and technical aspects of TARGET2. Nevertheless, further legal considerations may require some amendments. This document was drafted by the Eurosystem and will be used, after approval by the respective bodies of the Eurosystem, as a basis for the development of TARGET2. Nevertheless, as requested by the banking industry, the Eurosystem agrees on the necessity for continuous close and interactive involvement of the users in the next phases of the project, more particularly in the Detailed Functional Specifications Phase (DFS). This cooperation should be based on a constructive approach and organised in order to allow to remain in line with the schedule. In addition to the work in the functional and technical areas, it is necessary to stress on the fact that each national banking community will be in close relationship with its NCB to define and monitor the national migration towards TARGET2. This document aims at presenting the general functional specifications for the future TARGET2 system. Chapter 2 General features and structure of TARGET2 presents the general outline of this concept and the framework of TARGET2. In addition it should give a short and comprehensive overview (executive summary), paying also special attention to the user requirements as expressed by the European Payments Council. Chapter 3 Participation in TARGET2 details the conditions of the participation in TARGET2. Version 1.13 2

1 Introduction Chapters 4 to 6 cover the payment processing activity: Chapter 4 Payment processing in the SSP gives a detailed description of the functionality involved in the payment processing including liquidity management issues. As this issue was underlined by the European banking industry and some CBs, chapter 5 Ancillary system settlement presents in detail the main features of the Ancillary System Interface. Chapter 6 Information and Controle Module (ICM) deals with the Information and Controle Module (ICM), the central "switchboard" for participants, with regard to TARGET2 activity. In chapter 7 Functional assumptions and service level requirements, the main functional assumptions for the TARGET2 design are included. Chapter 8 SSP infrastructure and availability measures covers a general overview on the technical concept as well as the important business continuity aspect. In chapter 9 Operational model, some remarks on the operational model can be found. Finally chapter 10 Migration issues gives an initial outlook on the migration process. It details the structure of the migration phase and mentions some activities required at the users side. Version 1.13 3

2 General features and structure of TARGET2 2.1 Principles of TARGET2 2 General features and structure of TARGET2 2.1 Principles of TARGET2 A set of general user requirements The TARGET2 concept was developed in accordance with the following framework: The new system will fulfill the user requirements. It will take into consideration the ongoing developments to set up a Single Euro Payments Area (SEPA) in Europe. The new system should be geared mainly to the needs of the European banking industry and the participating CBs.The European banking sector has made considerable efforts to contribute to the TARGET2 discussion resulting in the response of the European Payments Council (April 2003) and the "TARGET2 user requirements (October 2002)" prepared by the TARGET working group (TWG). The basic assumption regarding the TARGET2 requirements is that national banking communities in Europe see themselves as part of the (entire) European banking sector. The new system will guarantee neutrality. The new TARGET2 system is intended to strengthen Europe as a financial centre. This "neutrality" aspect may be considered in different ways: TARGET2 will respect the principle of "political, geographical and commercial neutrality" vis-à-vis the financial centers. No national banking community will benefit from a "preferential" treatment. The TARGET2 system will be developed and operate on behalf and under the auspices of all Eurosystem participating CBs as "owners". In TARGET2 each bank as well as participating CBs will have the same rights to the service, namely neither bank nor CB will benefit from a preferential treatment. TARGET2 will ensure a level playing field also with regard to the settlement of ancillary systems. Version 1.13 4

2 General features and structure of TARGET2 2.1 Principles of TARGET2 The new system will preserve the decentralised framework of the Eurosystem. In line with the current decision of the Governing Council on TARGET2, the new system must ensure that participating CBs maintain the responsibility for the business relations vis-à-vis their banks. TARGET2 will be highly resilient. Given its systemical importance as one of the biggest payment systems in the world, it must have a state-of-the-art technical infrastructure and organisation in order to ensure business continuity. Version 1.13 5

2 General features and structure of TARGET2 2.2 Concept of TARGET2 2.2 Concept of TARGET2 TARGET2 TARGET2 is the future real-time gross settlement system of the Eurosystem. It will be based on a single platform infrastructure, ie the entire application will be based on an integrated central technical infrastructure (so called "Single Shared Platform" (SSP)). In order to allow for a smooth migration it is foreseen to support the current interlinking logic also at SSP level, for a short period of time, in order to allow a gradual migration of countries in different waves (to be approved). Thus, CBs will not have to migrate to the new environment "in one go". No phased approach From a user's perspective, TARGET2 will offer a broad range of features and services to meet the full requirements of all users (European banking industry, CBs and ECB). In addition to payment processing, the current TARGET2 includes from the outset: most modern liquidity management an advanced standard interface for the settlement of ancillary systems high resilience and state-of-the-art business continuity Limiting the complexity Core and optional services Taking into consideration the dimension of creating a single European TARGET platform, it should, nevertheless, be borne in mind that an "overloading" of the concept should be avoided in order to limit the big complexity of the overall process. In order to accommodate the individual needs of banks and infrastructures, TARGET2 will offer high flexibility, in particular with regard to liquidity management. Many features (eg reservation facilities and the use of limits) are designed in such a way as to allow participating banks to decide whether or not they want to use this specific feature. Version 1.13 6

2 General features and structure of TARGET2 2.3 Features and advantages of TARGET2 2.3 Features and advantages of TARGET2 Assessment against user requirements The following table summarises the main user requirements issued by the EPC in April 2003 and how the concept responds to it. Topic User requirement Related TARGET2 functionality Single system (Item 1) Time schedule and milestones (Item 3) Banks consider TARGET2 as a single system, from both a flow management and an account management point of view, ie a harmonised and integrated system, independent from the number of platforms that will coexist in the end. More visibility is needed on the project timeframe and migration plan in order to enable participants to prepare themselves. Users want the shortest convergence period possible. Banks will need to understand what changes they will need to accommodate in their own internal systems for the migration and be given adequate time to plan and effect any changes. This implies comprehensive and early information on the timing of the introduction of any change. The current concept is based on a "single platform" approach, ie there will only be one technical platform for the provision of payment services for TARGET2. Only in the migration period, an interlinking mechanism might still be necessary regarding those CBs which have not yet been connected to TARGET2. A first general project plan as well as a migration plan are provided. The convergence period will be defined in the coming months according to the possibilities of migration of national banking communities. The general functional specifications provide a general overview of the changes to implement. These changes will be detailed in the user detailed functional specification. A draft version will be available in July 2004 and the final version in December 2004. Version 1.13 7

2 General features and structure of TARGET2 2.3 Features and advantages of TARGET2 Topic User requirement Related TARGET2 functionality Availability of the core services (Item 4) Neutrality (Item 10) Services (Item 13) All core functionality already identified by the TWG in the user requirement document and its appendix, should be in place right from the beginning of TARGET2. The users want the core services available as soon as possible. All choices made with reference to the single shareable platform must be neutral to all users, whatever their location, because each user anywhere in the same playing field should have the same rights to the service. For the choice of the location of the single shareable platform, it is essential to respect the principle of political, geographical and commercial neutrality vis-à-vis the different financial centres. Users wish to participate in the decision making process and welcome the statement that "the service level of TARGET2 will be defined in close co-operation with the TARGET user community". According to the existing schedule, all functionality described in the general functional specifications will be available from the start of TARGET 2 (beginning of 2007). TARGET2 will be a system for the whole European banking industry. There will be no distortion in competition vis-à-vis certain countries, certain market infrastructures or CBs. One of the basic inputs for the concept have been the user requirements of the European banking industry. The present invitation for feedback aims at verifying the TARGET2 concept. Version 1.13 8

2 General features and structure of TARGET2 2.3 Features and advantages of TARGET2 Topic User requirement Related TARGET2 functionality Functional harmonisation and liquidity management (Item 2) Pooling It should be mentioned that the European banking industry focuses much on this issue. Besides chapter 2 in the response of EPC, the topic is covered in the following documents: User requirements (prepared by the TWG, October 2002) Appendix to the user requirements The future service should be fully harmonised also from a business and functional point of view (liquidity management), on top of technical or operational harmonisation. Liquidity management is the individual responsibility of TARGET participants and always remains in their full control. Flexible system options and settings should be in place. Real-time visibility, comprehensive queue management and gridlock resolution TARGET 2 should offer the possibility to reserve liquidity for specific payments at the request of the participant Tools facilitating decreases in the need for intra-day liquidity Prioritisation of payments Use of direct debit facilities for wholesale purposes In the presence of a decentralised business infrastructure where business relationships are the responsibility of individual banks. Cash management facilities will be required. Access to centralised information Pooling facility Netting optimisation facility Other facilities TARGET2 will provide fully harmonised and standardised services from business and technical point of view. TARGET2 will offer state-ofthe-art liquidity management services with a broad range of tools (reservation, prioritisation, active queue management). In order to provide an efficient payment processing, TARGET2 will offer tools to control the liquidity flow and will implement mechanisms which make use of mutual payment flows. TARGET2 will also offer an interbank direct debit facility. TARGET2 will offer liquidity pooling services, relying on the socalled "group of accounts" structure. Version 1.13 9

2 General features and structure of TARGET2 2.3 Features and advantages of TARGET2 Topic User requirement Related TARGET2 functionality Information management Inquiries facilities on the account balances and the status of payments Inquiries on own waiting list of outgoing and incoming payments Push and pull information Information on system breakdowns Provide statistics on payment flows Via the Information and Control Module, a comprehensive set of information can be accessed by the participants. This information comprises liquidity, payment and system status aspects. In addition, TARGET2 will offer statistical services to the participants. Version 1.13 10

2 General features and structure of TARGET2 2.3 Features and advantages of TARGET2 Topic User requirement Related TARGET2 functionality Business continuity, capacity, performance (Item 12) Our requirement is to be able to count on a service with 100% availability and full resilience in case of disaster. Furthermore the overall capacity of the system in terms of volumes and throughput must be sufficient to avoid any deadlocks within the processing of payments - even during peak-hours of the day. The proposed concept to ensure resilience and business continuity is based on a multi-regions/multisites architecture. There would be three "regions". In each region, there would be two distant sites with different risk profiles. The payment and accounting services (which are the most highly time-critical) would rely on a "two regions/four sites" model. This would be combined with the principle of region rotation, in order to ensure the presence of skilled staff in both regions, while the d- related services (eg Data Warehouse) would rely on a "one region/two sites" model. Notwithstanding geographical diversification, TARGET2 would offer a "single face" to the users, who would not have to know on which site or which region the system module is running. Such a technical design is absolutely state-of-the-art, in line with the core principles and, beyond them, with the very best practices for resilience and business continuity resulting from the lessons learned from the events of 11 September 2001. The functional assumptions to size the technical platform are listed in the document. Version 1.13 11

2 General features and structure of TARGET2 2.3 Features and advantages of TARGET2 Topic User requirement Related TARGET2 functionality Technical interface (Item 14) The European banking industry strongly supports the single interface to TARGET for all (domestic and cross-border) payments; it must happen with total certainty and the standards chosen must remain stable in the medium term. The harmonisation of communication standards, message formats (eg SWIFT) and internationally recognised banking technology (eg SWIFTNet) would reduce costs (see User requirements, item 1). TARGET2 offers a set of streamlined and harmonised interfaces with users (credit institutions, market infrastructures and central banks). This will ensure the highest possible level of service, particularly in terms of speed, cost and availability. In terms of communication (tools and standards, both in terms of format of messages and network connections), the major purpose is to allow all market participants to benefit from maximum economies of scale in this framework. Therefore, SWIFT messages and a common communication infrastructure are used. In order to cope with the different needs, all SWIFTNet services (FIN, Interact, Browse, FileAct) will be used. Version 1.13 12

2 General features and structure of TARGET2 2.3 Features and advantages of TARGET2 Topic User requirement Related TARGET2 functionality Ancillary systems (Item 15) Ancillary systems should be able to settle right from the start of TARGET2 on the Single Shared Platform. Please refer to the appendix to the user requirements for more details. From the start TARGET2 will be able to provide full services of settlement for all kind of ancillary systems. These services will be provided through an interface. Its general specifications are described in this document. The number of ancillary systems in operation in Europe is relatively high. TARGET2 will offer one interface for ancillary systems, supporting a number of generic models. The Ancillary System Interface performs a number of functions (some of them are optional) that ancillary systems can choose to combine according to their preferred functioning mode. The Ancillary System Interface provides DVP facilities and is conceived to support various kinds of the existing settlement models. Version 1.13 13

2 General features and structure of TARGET2 2.4 Role of CBs in TARGET2 2.4 Role of CBs in TARGET2 Basics Responsibilities of CBs The new system will preserve the decentralised framework. In particular, the current role of CBs in TARGET remains, in general terms, unchanged. Thus the Single Shared Platform (SSP) in TARGET2 should be seen as a "technical" vehicle for the CBs in order to provide an improved, more harmonised and cost-efficient TARGET service to their users. Each CB will remain fully responsible for the business relations vis-à-vis its participants. Therefore, the new system will be, for example, designed in a "client-based" way in order to meet the administrative and monitoring requirements of the participating CBs. Nevertheless, all the features of the system will be defined with respect to the level playing field commitment of the Eurosystem. Therefore no specific services will be proposed. Tasks of CBs In context of TARGET2, the CBs will have the following responsibilities: in general in migration in operation all contacts and provision of any kind of support to its participants (credit institutions, ancillary systems) responsibility for planning and structuring the domestic migration process inclusion and exclusion of participants monitoring the activity of its participants provision of intra-day liquidity necessary for the smooth running of the system initiating payments on behalf of their own or on behalf of their participants billing to its participants handling of local contingency Version 1.13 14

2 General features and structure of TARGET2 2.4 Role of CBs in TARGET2 CBs as a participant Each CB will also have the status of a direct participant. In practical terms, this means that each CB must be directly addressable in TARGET2 in order to receive payments from other participants able to submit payments on its own behalf or on behalf of its customers to TARGET. Version 1.13 15

2 General features and structure of TARGET2 2.5 Scope and framework of TARGET2 2.5 Scope and framework of TARGET2 Specific role of TARGET The main objectives of the TARGET system might be summarised as follows: to serve the needs of the Eurosystem's monetary policy to provide a reliable and safe mechanism for the settlement of payments on an RTGS basis to increase the efficiency of intra-european payments and to become one of the "core" infrastructures in the envisaged Single Euro Payments Area (SEPA) Scope of TARGET2 TARGET2 concentrates mainly on payment processing. In particular, the following aspects should not be considered as part of TARGET2, irrespective of the fact that these activities belong to the common monetary policy of the Eurosystem and, thus, have a close connection to TARGET2: collateral management execution of monetary policy reserve management and standing facilities Each CB remains fully responsible for the execution of the above mentioned tasks. However, in order to accommodate some needs of those CBs wishing to use commonly shared resources to a larger extent, the SSP will also offer these CBs standardised but optional modules. Version 1.13 16

2 General features and structure of TARGET2 2.5 Scope and framework of TARGET2 The following table gives a comprehensive overview of all services offered by the SSP: Services provided to all users Mandatory Payments processing in the Payments Module (PM) Information and Control Module (ICM) Contingency Module Optional Liquidity pooling Limits Liquidity reservations Services provided to all users subject that the relevant NCB has opted for these services Mandatory Standing Facilities (SF) Reserve Management Module (RM) Optional Home Accounting Module (HAM) Notes: With regards to Reserve Management and Standing Facilities, the choice to adopt standardised SSP modules or to manage them locally is up to the individual CB. For the local management, specific applications have to be in place at CB level. With regard to Home Accounting, the need to maintain in addition or alternatively a home account outside the RTGS system may depend on the strategic decision of the credit institution. Central banks may also opt to provide these services outside the SSP in a proprietary home account environment. Services provided only to the central banks Mandatory Monitoring Data Warehouse (archiving, billing) Optional Data Warehouse (statistics,...) Customer Relationship Module (CRM) Version 1.13 17

2 General features and structure of TARGET2 2.5 Scope and framework of TARGET2 Reserve management and standing facilities CBs who opt for these standardised SSP modules, can offer the following services to their customers: Reserve Management Module Standing Facilities Module Receiving end-of-day balances Monitoring of the running average in the current reserve period Calculation and settlement of interest to be paid (for compulsory reserves) or penalties that banks have to pay (nonfulfilment of reserve requirement) Management of overnight deposit accounts marginal lending accounts Transfer of liquidity to the overnight deposit account Granting of overnight credit either "on request" automatically, if at the end-of-day intra-day credit is turned into overnight credit Calculation and settlement of interest to be paid by the CB (overnight deposit facility) or by the banks (marginal lending facility) Automatic repayment of the deposit or the overnight-credit Need for home accounting Direct TARGET2 participants will have to maintain an RTGS account in the Single Shared Platform. Nevertheless, each CB is free to maintain so-called additional "home accounts". This "home accounting" functionality could be used for the following reasons: Some banks may not be interested to participate directly in the RTGS system, but are nevertheless subject to minimum reserve requirement. In addition, they may wish to directly manage cash withdrawals etc. Therefore they need a CB account outside the RTGS system. In some cases, depending on the specific situation in each country, it may be preferable to have a second set of accounts. This could be used to settle specific operations of direct participants, which already have a TARGET account. Some ancillary systems might, for example, decide not to migrate from the start to the SSP, but maintain - for the time being - a local infrastructure. Version 1.13 18

2 General features and structure of TARGET2 2.5 Scope and framework of TARGET2 Each CB is fully responsible for the execution of its home accounting business. In this context, each CB is also free to choose: if there is a need to offer additional home accounting services (or rely only on TARGET) and for what type of business the home accounting application will be used. Proprietary home accounting application Home Accounting Module (HAM) In this case, the service offered to its banks will contain a limited number of well-defined transactions, but never fully-fledged payment services. The SSP will also offer a standardised Home Accounting Module (HAM). This is to accommodate the needs of those central banks wishing to use commonly shared resources to a larger extent. Those CBs who opt for using this module, can offer the following standardised account services to its customers: Liquidity holding (eg maintaining reserve requirement) on a CB account Interbank transfers between accounts in the HAM held by the same CB Interbank transfers between the HAM accounts and RTGS accounts of direct participants of the same CB Cash withdrawals with the respective CB Use of standing facilities Please note that this module is not intended to offer real payment services. This activity must be performed through another PM participant. The HAM will be technically integrated in the SSP and can be accessed by customers via SWIFTNet. There will also be the possibility, that the HAM account will be managed by a PM participant (the so-called co-manager). The aim of the co-management function is to allow small banks to manage directly their reserve requirement, but to delegate cash flow management to other banks. Version 1.13 19

2 General features and structure of TARGET2 2.5 Scope and framework of TARGET2 Statistical information Monetary policy - general remarks Ways of executing monetary policy operations The Eurosystem will provide statistics on the overall TARGET2 activity. In addition, each CB will decide to what extent and in which way it will offer other statistical information (eg country-related figures, participant related profiles) to its customers. TARGET2 will be the vehicle for the smooth conduct of monetary policy. For the smooth implementation of monetary policy, the Single Shared Platform ensures that: technical failures occur as rarely as possible to minimise the related disturbance to the money market. the system allows an easy, cheap and secure handling of payments by banks to minimise the recourse to standing facilities and the building up of excess reserves in relation to failures to use the system. more generally, the flow of liquidity is frictionless and real-time, to support an efficient interbank market, including cross-border. In the Eurosystem, a broad variety exists in the way in which monetary policy is executed. This is mainly due to the different procedures (eg a prepledged (collateral) pool or repo transactions) and the different ways the collateral management of a CB is technically organised. Version 1.13 20

2 General features and structure of TARGET2 2.5 Scope and framework of TARGET2 The following table shows some examples in the way in which refinancing operations might be executed. No. Activity Mechanism Procedure 1 Liquidity injection via repo via pledge 2 Liquidity withdrawal via repo via pledge The CB collateral application/ Cross-CB payments would initiate a DVP transaction (settlement as ancillary system) The CB could initiate a standard payment in favour of the participant The CB collateral application/ Cross-CB payments would initiate a DVP transaction (settlement as ancillary system) The CB could initiate a direct debit CBs which opt for a proprietary Home Accounting Module may opt to execute monetary policy operations via these accounts. Version 1.13 21

2 General features and structure of TARGET2 2.6 Time schedule and milestones 2.6 Time schedule and milestones A common objective: 2 January 2007 The Eurosystem agreed to consider 2 January 2007 as the common objective for the go-live date of the TARGET2 system. It is of the utmost importance to meet this date in order to: respond to the expectations of market participants ensure the competitiveness and attractiveness of TARGET2 create a reliable framework for strategic planning in the acceding countries In the current stage the following milestones are foreseen: Milestones 2003 2004 2005 2006 2007 Pre-production phase General functional specifications Detailed technical specifications Development Test, going-live preparation Technical implementation General description (30/06/04) Customer Customer Migration Customer Migration Process Migration Process Process User specifications (30/07/04 and 31/12/04) Tests with users CI / MI / CB = country window (wave) Version 1.13 22

3 Participation in TARGET2 3 Participation in TARGET2 General remarks Two types of participation The access to TARGET2 will be fair and open. Nevertheless, this chapter needs to be further elaborated by the Eurosystem to clarify, among others, the issue of access criteria for indirect participants. Two types of participation will be offered: Direct participation Indirect participation The following diagram gives an overview of the two different types of participation from a business point of view. It describes the situation after all CBs of the ESCB have migrated to the SSP. AS = ancillary system CI = credit institutions CB = Central Banks FI = credit institutions and other finance institutions *other security firms direct participant indirect participant CI* (SSP country) Payments Module Remote access CI* (EEA) CBs (SSP country) 1 2 3 4 AS FI FI FI FI FI FI Number Explanation 1 CI is a direct participant in the PM. It is located in a country taking part in the SSP. The direct participant takes part in the SSP from the country where his home CB is located. Via the direct participant indirect participants are connected to the PM. Version 1.13 23

3 Participation in TARGET2 Number Explanation 2 A CI is a direct participant in the PM. It is located in a country of the European Economic Area. The direct participant takes part in the SSP via a country where his home CB is not located. Via the direct participant indirect participants are connected to the PM. 3 CBs are also direct PM participants. Ancillary systems settling in the remaining local home accounting system of a CB for a migration period are no indirect PM participants of the respective CB. 4 Ancillary systems might not be full direct participants because they do not need to run a fully fledged payment system due to the availability of a special interface (Ancillary System Interface) which is also SWIFT-based and integrated into the Payments Module. Mentioning the CBs (Eurosystem) separately should explicitly point out that also CBs can become direct TARGET2 participants. Note: The diagram does not represent the technical connection to the Payments Module. Version 1.13 24

3 Participation in TARGET2 3.1 Direct participants 3.1 Direct participants Characteristics Direct participants have: direct access to the PM an RTGS account within the PM access to real-time information and control measures. They are responsible for their own liquidity management in the PM and for monitoring the settlement process. They can provide an indirect connection to the PM for other institutions as indirect participants and offer them additional services. Access criteria According to the current TARGET1 rules (which will not be changed in TARGET2), the basic access criteria for direct participants are as follows: Supervised credit institutions - as defined in Article I (I) of Directive 2000/ 12/EC of the European Parliament and of the Council of 20 March 2000 relating to the taking up and pursuit of the business of credit institutions - which are established in the European Economic Area (EEA) Treasury departments of member states' central or regional governments active in money markets The public sector - as defined in Article 3 of Council Regulation 3603/93 of 13 December 1993 - of member states authorised to hold accounts for customers Investment firms - as defined in Article 1.2 of Council Directive 93/22/ EEC of 10 May 1993 - established in the EEA and authorised and supervised by a recognised competent authority (with the exclusion of the institutions defined under Article 2.2 of the above-mentioned Directive), provided the investment firm in question is entitled to carry out the activities referred to under items I(b), 2 or 4 of section A of the Annex to the Council Directive 93/22/EEC of 10 May 1993 on investment services in the securities field Version 1.13 25

3 Participation in TARGET2 3.1 Direct participants Organisations providing clearing or settlement services and subject to oversight by a competent authority may be eligible Central banks (CBs) of the Eurosystem and the European Central Bank (ECB) In addition to the legal bases mentioned above, direct participants have to successfully complete a series of tests to prove their technical and operational competence before taking part in the PM. At present stage, there seems to be no need for widening the range of institutions that will have direct access to TARGET2 in comparison to the criteria being valid for TARGET1. Nevertheless, in future it is foreseen that all central banks will apply identical direct access and removal criteria to and from the system (the details need to be further clarified). This harmonisation should not cause the exclusion of current direct participants from the system. But grand-fathering has to be elaborated in more detail. Furthermore, it needs to be further investigated which technical and operational criteria participants' internal systems have to comply with and how to organise the respective compliance checks. Note: It is possible for a participant to technically communicate with the SSP from different locations (but this is more a technical feature, not really a question of indirect participation). Version 1.13 26

3 Participation in TARGET2 3.2 Indirect participants 3.2 Indirect participants Characteristics Indirect participants are registered in the PM are directly linked to one direct participant only can be indirectly addressed in the PM have no own RTGS account within the PM The indirect participant sends payments to/receives payments from the direct participant. The direct participant then sends them to/receives them from the PM. The settlement is done on the RTGS account of the direct participant.the relevant direct participant also manages the liquidity for each of its indirect participants, and has accepted to represent the respective indirect participant. Note: Access criteria for indirect participants are currently being discussed. Version 1.13 27

3 Participation in TARGET2 3.3 Comparison of direct and indirect participation 3.3 Comparison of direct and indirect participation Overview The table below summarises the conditions and features of direct and indirect participants Feature Direct participant Indirect participant Sending and receiving payments directly using an own SWIFT interface directly via a service bureau via direct participant Own RTGS account yes no Liquidity provisioning on its RTGS account by direct participant Liquidity control by itself by direct participant Access to Information and Control Module (ICM) yes no Addressability directly by direct participant Publication in BIC-/ TARGET2 directory as a direct participant (XXX) as (XX+) Note: Service bureaus will be licensed by SWIFT. Therefore they have to fulfil the criteria set up by SWIFT. Anyway it is under the responsibility of the direct participant when he opts to use a service bureau. Version 1.13 28

3 Participation in TARGET2 3.4 Exclusion 3.4 Exclusion Criteria Consequences Identical criteria will apply for the exclusion of direct participants within the Payments Module (PM). An initial indication of the criteria is given below. They have to be revised in detail and will become legal regulations for participating in the PM (terms and conditions). Direct participants in the PM can be excluded by their home CB if: any action to restrain the disposal of their assets has been issued, in particular if insolvency proceedings have been initiated or if a so-called preliminary safeguard has been issued if their licence has expired to conduct banking transactions to render securities services Each CB may exclude a participant for an important reason (eg if there is reasonable doubt that the participant is unable to fulfil the duties arising from the terms of business). Note: The issue of exclusion has to be elaborated in more detail by the ESCB. The exclusion is effective immediately. As from this point no further payments from or for the excluded participant will be accepted by the PM. The participants will be informed via a broadcast in the ICM. Version 1.13 29

3 Participation in TARGET2 3.5 Directories of the participants 3.5 Directories of the participants Directories TARGET2 directory Two directories are available to assist the addressing of payments: TARGET2 directory BIC directory To support the sending of payments in Y-copy mode, the needed routing information will be provided electronically in a structured, automation like so-called TARGET2 directory to the users. This TARGET2 directory is set up in addition to SWIFT's BIC directory to support the specific needs of SSP and its users (provisioning of national sorting code; BIC to be used in SWIFT header for receiver; migration purposes; frequency of update, etc.), and because the BIC directory is currently not able to support these needs. Nevertheless, when the future SWIFT directory service can cater for these requirements, a merger of both directories is possible. It is currently foreseen to offer the TARGET2 directory as download in SWIFTNet FileAct service only. Updates will be based on the content of the up-to-date BIC directory, but take place more often (weekly), because the current three month update period of the BIC directory is not sufficient for SSP purposes. An emergency procedure for immediate updates will be available (eg in case of exclusion of participant). The availability of a new TARGET2 directory version will be announced with a broadcast in the Information and Control Module. During the migration period, the TARGET2 directory will also contain the needed routing information on non-migrated participants. The routing logic between SSP users and a SSP user to a non-migrated participant is exactly the same. In case of a non-migrated participant, the TARGET2 directory will deliver a central SSP BIC, which must be addressed in the SWIFT header instead of the receivers BIC. Sending then happens still in Y-copy mode. Due to this logic, the shift of a non-migrated participant to the SSP is quite simple. Only the central SSP BIC will be replaced by the related receiver BIC. The exchange will take place in a new TARGET2 directory version as mentioned above. Version 1.13 30

3 Participation in TARGET2 3.5 Directories of the participants Note: The information in the TARGET2 directory will not be the basis for the entry-check of incoming messages in SSP. Therefore it will be possible to address payments to another direct PM participant not mentioned in relation to the beneficiary institution in the TARGET2 directory. Further details on the structure and the delivery of the TARGET2 directory will be provided in the User Detailed Functional Specifications. BIC directory The BIC directory shows all global SWIFT participants and the payment system(s) to which they are connected. For indicating direct and indirect SSP participation worldwide the respective TARGET service code (XXX or XX+) is mentioned for each SSP participant. SWIFT maintains the BIC directory and makes it available in various formats. Note: The BIC directory service is currently being discussed at SWIFT (eg frequency of updates). Version 1.13 31

4 Payment processing in the SSP 4.1 Accounting 4 Payment processing in the SSP 4.1 Accounting Accounts in the SSP s Payments Module Each direct TARGET2 participant has to use the Payments Module of the SSP (PM). In order to enable an immediate posting of all payments executed in the Payments Module, each direct participant maintains an account in the Payments Module (so-called RTGS account). The RTGS account of a direct participant is administered under the sole responsibility of the respective CB (CB where the direct participant is located). Each RTGS account is identified by a "BIC 11" code and unequivocally assigned to one direct participant; if a "BIC 8" code is used, it will be filled up with "XXX". Also ancillary systems may hold an account in the Payments Module, if necessary for settlement purposes (eg with regard to the current settlement procedure EBA-EURO1 system). Home accounting All transactions submitted to and executed in the Payments Module will be posted on accounts in the Payments Module. Participating central banks may nevertheless, use the option to settle certain transactions (eg cash operations) outside the Payments Module. In such cases, a "dual accounting" structure will have to be implemented (ie direct TARGET2 participants may have both an account in the Payments Module and in the home accounting environment). This could be either a proprietary home accounting system of the respective CB the standard Home Accounting Module (offered as optional module of the SSP) In order to allow for a free and unlimited access to central bank liquidity independent of the specific accounting structure, a liquidity transfer facility will be offered to direct participants in order to move liquidity from/to RTGS account to/from home accounts (ie by using ICM). Version 1.13 32

4 Payment processing in the SSP 4.1 Accounting Overnight holding of liquidity Depending on the accounting structure used by each CB, the liquidity on the RTGS accounts may be maintained: intra-day and overnight. In this case, the liquidity on the RTGS account at end-of-day will function as "reserve holdings". only intra-day. In this case, the liquidity will be transferred back to the home accounts at end-of-day and vice versa before the start of the next SSP business day. Statement of RTGS accounts In any case, direct participants in the PM are informed on the single items booked on and the final balance on their RTGS accounts by a SWIFT message type MT 940 or MT 950. Statements of RTGS accounts are not available during the day. For intraday liquidity management, the participants are offered a real-time access via the Information and Control Module (ICM). By using an "application-toapplication" mode, participants may also integrate the data stream in their internal application. Sources of liquidity The availability of sufficient liquidity will be of high importance for the participating credit institutions. The following sources of liquidity can be used for the execution of payments: balances on RTGS accounts provision of intra-day liquidity offsetting payment flows (ie using algorithms to settle a number of queued payments) Version 1.13 33

4 Payment processing in the SSP 4.1 Accounting Intra-day liquidity in the SSP Intra-day credit will be granted to the single accounts of credit institutions, against eligible collateral by the respective CB. The following procedures can be used, depending on the decision of the respective CB: implementing credit lines on RTGS accounts (based on a pool of predeposited collateral) implementing credit lines on home accounts (ie an additional liquidity transfer between the home and the RTGS account is necessary) DVP-processing of intra-day repo transactions. In case of repo transactions, the liquidity will be provided as credit item according to the specific procedure set-up by the respective central banks. The credit booking may be initiated by the CB or on behalf of the CB by an Ancillary system (responsible for the securities settlement). If the liquidity pooling functionality is used, the liquidity obtained intra-day will be available among the group of accounts. Credit lines in the PM If credit lines on RTGS accounts are used by CBs, the liquidity available for processing payments is the sum of: the balance on the RTGS account and the credit line. Version 1.13 34

4 Payment processing in the SSP 4.1 Accounting This means that the balance on the RTGS account may enter, up to the respective credit line, into an overdraft position. The following table gives a short example: Action Balance Credit line Available Liquidity (Balance + credit line) Start 1,000 500 1,500 Payment (sent): 200 500 700 800 Payment (sent): -400 500 100 600 Payment (received): 200-200 500 300 Update of credit lines The credit lines in the PM will be updated by the respective CB via a standard interface to its collateral management application. The respective participants will be informed about changes regarding their credit lines via the Information and Control Module. In some cases, payments initiated by CBs in favour of a participant may automatically lead to a change of the credit line (eg main refinancing operations in countries with pre-pledged (collateral) pools). In these cases, the participant will be informed about the payment and the change of credit lines via an MT 900/MT 910. Version 1.13 35

4 Payment processing in the SSP 4.2 Payment types 4.2 Payment types Basics Payments submitted by participants As today, TARGET2 will offer to the participants settlement services in euro. For the following payments and subject to further discussion, the use of TARGET2 will remain mandatory: monetary policy operations (in which the Eurosystem is involved either on the recipient or on the sender side) settlement of the euro leg of foreign exchange operations involving the Eurosystem settlement of cross-border large value netting systems handling euro transfers. In general it seems preferable that in future all systemically important payment systems will have to settle in TARGET2. The Eurosystem will not set de jure or de facto limits for the use of TARGET2. Any payment which users wish to process in real-time and in central bank money can be executed in TARGET2. Participating CBs may use local home accounts of their credit institutions for the above mentioned operations. Credit institutions as PM participants can submit the following payment types: credit transfers direct debits The Payments Module processes payment orders in SWIFT format only: Message type MT 103 (+) MT 202 MT 204 Acceptance mandatory mandatory optional The message structure and field specification will be defined at a later stage. Version 1.13 36