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
The next generation of TARGET
Introduction
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
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.
Content of this
document
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
A set of general
user requirements
2
General features and structure of TARGET2
2.1
Principles of TARGET2
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
TARGET2
Concept of 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
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.
Core and optional
services
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
Assessment
against user
requirements
Features and advantages of TARGET2
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)
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.
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.
Time schedule and
milestones
(Item 3)
• More visibility is needed on the
• A first general project plan as
project timeframe and migration plan in order to enable
participants to prepare themselves.
well as a migration plan are
provided.
• Users want the shortest con-
• The convergence period will
vergence 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.
Version 1.13
be defined in the coming
months according to the possibilities of migration of national
banking communities.
• This implies comprehensive
• The general functional specifi-
and early information on the
timing of the introduction of
any change.
cations 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.
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)
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.
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).
Neutrality
(Item 10)
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.
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.
Services
(Item 13)
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".
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
Functional
harmonisation and
liquidity
management
(Item 2)
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
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.
Pooling
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 offer liquidity pooling services, relying on the socalled "group of accounts" structure.
Version 1.13
Related TARGET2 functionality
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
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
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
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 drelated 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
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.
Version 1.13
Related TARGET2 functionality
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 communiThe harmonisation of communica- cation (tools and standards, both
tion standards, message formats
in terms of format of messages
(eg SWIFT) and internationally
and network connections), the
recognised banking technology
major purpose is to allow all mar(eg SWIFTNet) would reduce
ket participants to benefit from
costs (see User requirements,
maximum economies of scale in
item 1).
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.
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
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.
Responsibilities of
CBs
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 provi-
• responsibility for plan-
• inclusion and exclusion
sion of any kind of support to its participants
(credit institutions,
ancillary systems)
ning and structuring the
domestic migration process
of participants
• monitoring the activity of
its participants
• provision of intra-day
•
•
•
Version 1.13
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
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
Specific role of
TARGET
Scope and framework of TARGET2
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)
Version 1.13
Optional
• Data Warehouse (statistics,...)
• Customer Relationship Module (CRM)
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
• Management of
•
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)
•
•
•
•
Need for home
accounting
– 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
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
In this case, the service offered to its banks will contain a limited number of
well-defined transactions, but never fully-fledged payment services.
Home Accounting
Module (HAM)
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
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.
Ways of executing
monetary policy
operations
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.
1
Activity
Liquidity injection
Mechanism
• via repo
• via pledge
Procedure
• The CB collateral application/
•
2
Liquidity withdrawal
• via repo
• via pledge
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
A common
objective:
2 January 2007
Time schedule and milestones
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
ProcessProcess
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
General remarks
Participation in TARGET2
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
Two types of
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
CI
CB
FI
Payments
Module
= ancillary system
= credit institutions
= Central Banks
= credit institutions and
other finance institutions
*other security firms
4
Remote
access
direct
participant
indirect
participant
FI
CI*
(SSP
country)
CI*
(EEA)
CBs
(SSP
country)
1
2
3
FI
FI
FI
FI
AS
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
Characteristics
Direct participants
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
Characteristics
Indirect participants
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
Overview
Comparison of direct and indirect participation
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
via direct participant
•
SWIFT interface
directly via a service
bureau
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
Criteria
Exclusion
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.
Consequences
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
Directories of the participants
Two directories are available to assist the addressing of payments:
• TARGET2 directory
• BIC directory
TARGET2
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
Accounts in the
SSP’s Payments
Module
4
Payment processing in the SSP
4.1
Accounting
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
Update of credit
lines
Balance
Credit line
Available Liquidity
(Balance + credit
line)
Start
1,000
500
1,500
Payment (sent):
800
200
500
700
Payment (sent):
600
-400
500
100
Payment (received): 200
-200
500
300
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
Basics
Payment types
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.
Payments
submitted by
participants
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
Acceptance
MT 103 (+)
mandatory
MT 202
mandatory
MT 204
optional
The message structure and field specification will be defined at a later
stage.
Version 1.13
36
4
Payment processing in the SSP
4.2
Payment types
Domestic specialities regarding field contents to be validated at system
level are not foreseen at the current stage. This does, of course, not
exclude credit institutions agreeing bilaterally or multilaterally on specific
rules regarding the field contents. The SSP will not check whether the
respective PM participants comply with these rules.
Specific
procedures for
ancillary systems
Except from the features offered to all PM participants, ancillary systems
may use specific procedures for the efficient settlement of their business.
By means of the Ancillary System Interface, ancillary systems may initiate:
• credit transfers on their own behalf (debit will take place on its own
account)
• credit transfers on behalf of the participants in the ancillary system (mandated payment: credit transfer)
• direct debits on their own behalf (direct debits are credited on its own
account)
The Ancillary System Interface and the procedures of settlement are described in chapter 5 Ancillary system settlement.
Priority of
payments
Payments will be settled immediately, if sufficient liquidity is available on the
RTGS account of the participant.
To settle payments in the PM in a different way, considering their urgency,
they can be submitted by the sender either using:
• priority class 0 (highly urgent payments)
• priority class 1 (urgent payments)
• priority class 2 (normal payments)
Within a priority class no further priorisation is possible.
Version 1.13
37
4
Payment processing in the SSP
4.2
Payment types
Notes:
• Normally the priority class 0 (top priority) is only available for ancillary
systems settlement transactions and CB transactions except CLS
payments. For these payments also credit institutions should be allowed
to use the priority class 0 (to be confirmed).
• Within a priority class there will be no "sub-priorities“. That means "highly
urgent payments“ will be settled following the optimised FIFO.
• It should be noted that some specific CB transactions, which are not a
payment (eg decrease of credit lines), will be treated preferential to priority class 0.
• If no priority class is selected, payments will be handled as normal
payments.
Classification
Highly urgent
Urgent
Normal
Class of
priority
0
1
2
• Ancillary systems
• AS
• CBs
• Direct PM partici-
• AS
• CBs
• Direct PM partici-
Submission
by...
Characteristic
•
•
• Settlement of
•
Version 1.13
(AS)
CBs
CI (receiver CLS)
(to be confirmed)
transactions/
group of transactions between participants of an AS
Posting central
bank transactions
(eg cash withdrawals)
pants
• Priority payments
• Gross processing
due to extensive
and fast consideration of bilateral
payment flow
pants
• Highly liquidity
•
saving due to
extensive consideration of mutual
payment flow
Claim of real-time
processing takes
second place to
liquidity saving
processing
38
4
Payment processing in the SSP
4.2
Payment types
Payments with a
settlement time
PM participants have also the possibility to determine the settlement time of
their transactions. Two options are available:
• "Transactions with an Earliest Debit Time indicator"
• "Transactions with a Latest Debit Time indicator".
The following table describes payments with a set execution time.
Earliest Debit Time indicator
Latest Debit Time indicator
Features
Transactions to be executed from
a certain time
Transactions to be executed up to
a certain time
Effect
• Transaction is stored until the
• Setting the execution time only
•
Management
indicated time
At the earliest debit time, the
transaction runs through the
entry disposition
If the transaction can not be settled at the earliest debit time, it will
be queued till cut-off time for
payment-type is reached (or revoked).
•
means a special identification
via the Information and Control
Module
The transaction is treated like
any other payment of this type
If the transaction can not be settled
until the indicated debit time, it will
remain in the queue (or be rejected) till cut-off time for paymenttype is reached (or revoked).
In case a payment with a "Latest Debit Time indicator" is not executed 15
minutes prior to the defined time, an automatic notification in the Information and Control Module will be triggered. The broadcast will be directly displayed on top of all screens of the concerned PM participants.
It is possible, to combine the "Earliest Debit Time" indicator with the "Latest
Debit Time" indicator. In this case, the transaction is meant to be executed
during the indicated period.
Warehouse
functionality
It is possible to submit payments with a future date (up to five business days
in advance). In this case, the payment message will be warehoused until
TARGET2 opens for that date. Warehoused payments will benefit from the
same functionality as queued payments, eg transparency in the Information
and Control Module, cancellation, change of priority etc.
Version 1.13
39
4
Payment processing in the SSP
4.2
Payment types
Features of the
direct debit
functionality
Direct debits in TARGET2 are intended for wholesale purposes only and
are restricted to interbank transactions.
The direct debit functionality may be used by:
• credit institutions
• central banks
• ancillary systems
In particular, it might be used to offer an efficient cash management service
within a group of credit institutions or between different branches of a credit
institution.
In any case, the respective participants will have to agree with the parties
allowed to debit their accounts, on the terms and conditions for using this
service. TARGET2 will only offer the general framework.
The participant authorises another participant to issue a direct debit order.
He also has to inform his CB, which will be responsible to record and administrate the pre-agreements in the PM via ICM.
The following parameters are used in connection with the direct debit
scheme:
• Mandatory
– Direct debit issuer
– Account to be debited
– Reference
• Optional
– Maximum amount per day (for all direct debits independent from the
counterparty)
– Maximum amount per counterparty
– Maximum amount of any single payment
The PM will ensure, that the conditions mentioned above are met before
processing a direct debit request.
Version 1.13
40
4
Payment processing in the SSP
4.2
Payment types
Direct debits used
by CBs
The direct debit facility might also be used by central banks. The following
transactions give an example, of when the direct debit functionality could be
used:
• settlement of cash withdrawals
• repayment of monetary policy operations
• fee collections.
Version 1.13
41
4
Payment processing in the SSP
4.3
Payment interface
4.3
Basic principle
Payment interface
The payment interface is SWIFT-based only in order to allow for a "single
window" access at participant's level.
For the payment processing, PM uses the SWIFT FIN Y-copy service.
For that purpose a dedicated Closed User Group (CUG) will be set up.
In order to allow for an efficient and comprehensive provision of information,
the technical platform receives a "full copy" of any payment.
Advantages of
SWIFT
System
broadcasts
The following aspects list the advantages resulting from the SWIFT-usage:
•
•
•
•
•
high availability network with proven track record
high performance network
high level of security (non-repudiation, confidentiality, integrity)
widespread and easy access
store and forward service
One of the main advantages of the SWIFT Y-copy service is the availability
of automatic system broadcasts.
System broadcasts:
Message type
Description
Usage
MT 011
Delivery notification
optional
MT 012
Sender notification
optional
MT 019
Abort notification
mandatory
Note: The usage of optional message types (MT 011 and MT 012) will be
chosen by each participant individually.
In case a participant needs further explanation why a message is negative
acknowledged (MT 019), the local CB help desk can give more details.
Version 1.13
42
4
Payment processing in the SSP
4.3
Payment interface
PKI
The SWIFT FIN Y-copy service would be implemented using the PKI infrastructure (presumably available in the second half of 2005). A bilateral
exchange of security keys between the participants in the cross-CB
payments will therefore not be necessary.
Billing
The cost for message handling will have to be paid by participants themselves. In terms of cost-efficiency, the use of SWIFT Y-copy creates no disadvantage vis-à-vis the customers (compared with the normal FIN service).
Payment flow of Ycopy credit
transfers
The following chart illustrates how the Y-copy service for credit transfers will
work:
Participant Interface
SWIFTNet FIN Y-copy mode
SWIFTNet FIN
Bank A
MT 103(+) / 202 / 204
Bank B
SSP country
MT 097
MT 096
SSP country
MT 011
MT 012
MT 103(+) / 202 / 204
MT 019
PM
Participant interface (Y-copy)
mandatory
either/or
optional
Version 1.13
Booking
instruction
Acknowledgement
Payment processing
43
4
Payment processing in the SSP
4.3
Payment interface
Addresses in
TARGET2
The use of SWIFTNet FIN Y-copy enables the participants to address their
payment messages as in correspondent banking.
Since the FIN Y-copy service is used, payments will be addressed to the
receiving direct PM participant by indicating the BIC in the respective field of
the header. Generally payments for indirect PM participants will have to be
sent to the respective direct PM participant.
The address which has to be used for each (direct or indirect) participant is
listed in the TARGET2 directory.
Please note that the central banks are also direct participants in PM.
The following table summarises the addresses to be used in the SWIFT
application header:
No.
Receiving party
Address
1
direct PM participant
(domestic and cross-border)
<BIC> of direct PM participant
2
indirect PM participant not authorised to send and receive
<BIC> of the respective direct PM participant
3
CB as direct PM participant
<BIC> of the CB
Note: If a direct PM participant technically communicates with the SSP from
a different location using a BIC different from the BIC related to its RTGS
account this different BIC must be used in the header to address the
payment.
Version 1.13
44
4
Payment processing in the SSP
4.4
Payment flow
4.4
Payment flow
Benefit of the SSP
The main benefit of the SSP is that all accounts of direct participants used
for settling euro payments will be held in one technical platform. Debiting
the sending participant's account and crediting the receiving participant's
account are made simultaneously, without an additional interlinking procedure.
Flow of payments
The accounts to be debited and credited are identified by the respective
fields in the basic header (sender) and the application header (receiver) of
the payment message.
After the simultaneous settlement of debit and credit on the RTGS
accounts, a payment is final and irrevocable for the sending participant.
Already when a payment message is included in an algorithm it can not be
revoked during processing. Afterwards it depends, if the payment message
is cleared (final and irrevocable) or still queued (revocable).
Version 1.13
45
4
Payment processing in the SSP
4.4
Payment flow
The following slide describes how the payments are settled:
Participant interface
SWIFTNet FIN Y-copy mode
<BIC A>
7
3
2
MT 097
MT 012
6
MT 103(+) / 202 / 204
MT 103(+) / 202 / 204
MT 096
Bank A
SWIFTNet FIN
1
Bank B
<BIC B>
5
PM
Participant interface (Y-copy)
Payment processing
Bank A Bank B
4
Step
<BIC A>
<BIC B>
Description
1
The sender generates a payment message and addresses it to the receiving
participant.
2
The payment is temporarily stored by SWIFT; a settlement request is sent to
the PM.
3
The payment is validated by the PM for SWIFT syntax. In addition, application
oriented entry checks are also carried out.
4
Depending on sufficient cover, the settlement on the accounts of the respective
participants is executed.
Version 1.13
46
4
Payment processing in the SSP
4.4
Payment flow
Step
Backup payments
in case of the
participant’s
contingency
Description
5
The PM generates a settlement confirmation (MT 097) and sends it to SWIFT
6
SWIFT sends the stored payment to the receiving credit institution, stating the
settlement time in the payment message.
7
The sender can have the execution of the payment confirmed by MT 012. The
confirmation includes also the settlement time.
The payment application of a direct PM participant could break down, due
to a failure and could be unavailable for the rest of the business day.
In such circumstances - if a connection to the SWIFT network is still available-, the participant can generate certain payments via the Information and
Control Module (ICM). In this case, the “four-eyes“ principle will be mandatory. This means backup payments have to be verified and released by the
respective PM participant before they can be settled.
The following table shows the functionality available:
Type of payment
Message Format
Remarks
EURO1-EBA settlement
MT 202 via
SWIFTNet FIN
Special identification in the
account statement
CLS payments
MT 202 via
SWIFTNet FIN
Special identification in the
account statement
Payments to other participants
MT 202 via
SWIFTNet FIN
• Mainly intended for dis-
•
tributing liquidity (which
would be otherwise
locked)
Special identification in
the account statement
For major ancillary systems (eg SSSs) it might also be possible to offer
dedicated backup payments, where specific fields of the message are
already pre-filled with system related information (eg BIC of receiving institution or agreed code words).
The functionality of initiating contingency payments is only possible after
notifying the respective CB.
The usage of SWIFTNet FIN (instead of SWIFT FIN Y-copy) has no influence on the payment processing at the receiving participant's side.
Version 1.13
47
4
Payment processing in the SSP
4.4
Payment flow
Contingency
payments via the
respective CB
In the event of a failure on the side of the respective PM participant, a contingency procedure, related to the national conditions, is used for the above
mentioned payments if the participant has no access to ICM (see chapter
8.3 Contingency measures).
The payment orders will technically be initiated via ICM by the respective
CB on behalf of the failing participant.
Migration phase
The likelihood is that migration to the SSP of all countries will not take place
in form of a "big bang". Therefore, it is necessary to temporarily maintain
the old interlinking structure, for those countries which have not yet migrated.
The service offered for those "cross-platform" payments will remain the
same as in TARGET1. No changes are necessary for those countries still
using a single RTGS platform.
Participants in the PM will have to send payments to receivers in other platforms using the TARGET BIC address of the shared platform. The credit
institutions which are reachable via the TARGET interlinking logic will be listed - like any other participant in the SSP - in the TARGET2 directory.
Version 1.13
48
4
Payment processing in the SSP
4.4
Payment flow
The following slide gives on overview of the topology used for those
payments:
Participant interface
SWIFTNet FIN Y-copy
for interlinking payments during a migration phase
SWIFTNet FIN
MT 012
MT 103(+) / 202
MT 019
Bank A
MT 103(+) /
202
Participant interface (Y-copy)
mandatory
either / or
optional
Booking
instruction
Bank C
MT 097
MT 096
SSP country
Non SSP country
PM
Acknowledgement
Payment processing
Acknowledgement
Interlinking
NRP
Processing
Interlinking
Payment message
internal use only
SSP: single shared platform
NRP: national RTGS platform
Please note, that "new functionality" like direct debits will only be available
between participants in the Single Shared Platform.
Incoming cross-PM payments will be delivered by the PM via
SWIFTNet FIN. The usage of SWIFTNet FIN (instead of SWIFT FIN Ycopy) has no influence on the payment processing at the receiving participant's side.
Version 1.13
49
4
Payment processing in the SSP
4.4
Payment flow
Other SWIFT FIN
messages
Messages received by PM participants will not always be payment messages. Notifications will be received via MT 900/910 as listed below:
Message
type
Name
Examples
Remarks
MT 900
Confirmation of
debit
• Ancillary system settlement (mandated
optional
•
•
•
MT 910
MT 940
MT 950
payments)
Liquidity transfers (to the home
accounts)
Contingency payments
Payments referring to monetary policy
operations (to be discussed)
Confirmation of
credit
• Ancillary system settlement (mandated
(Customer)
Statement message
• End-of-day reporting on all transactions
•
•
optional
payments)
Liquidity transfers (from home accounts)
Payments referring to monetary policy
operations (to be discussed)
optional
settled on the RTGS account
Note: The usage of optional message types will be chosen by each participant individually.
Version 1.13
50
4
Payment processing in the SSP
4.4
Payment flow
The following graph illustrates the payment flow:
Participant Interface
SWIFTNet FIN for other purposes
Bank A
SWIFTNet FIN
MT 900 / 910 / 940 / 950
MT 900 / 910 / 940 / 950
Bank B
SSP country
SSP country
Participant interface
PM
Payment processing
Communication
with the optional
Home Accounting
Module (HAM)
In order to execute intra-day funds transfers between RTGS accounts and
HAM accounts, an internal "bridge" communication will be installed between
the PM and the HAM:
• Payments from RTGS accounts to HAM accounts will have to be initiated
by participants via ICM or by using SWIFTNet FIN Y-copy and addressing the <BIC> of HAM.
• Payments from HAM accounts to RTGS accounts will be reported to the
receiving PM participants via SWIFTNet FIN and message types
MT 202/910.
Version 1.13
51
4
Payment processing in the SSP
4.4
Payment flow
Reasons for
returning
payments
A payment is returned to the sender, in the case:
•
•
•
•
of an error
the sending party revokes the payment
a participant is excluded
a payment could not be successfully executed until the end of the day
Informing the
sender
The sender receives immediately an abort notification (MT 019) including
the reason for return and the reference number of the returned payments.
The transaction is considered as terminated.
Validation
All payments submitted by PM participants will be subjected to the following
high level validations:
• Syntax validation:
SWIFT will be responsible to validate the syntax of messages. Only syntactically correct messages will be delivered to the SSP.
• Security validations:
SWIFT and the PM will ensure that only authorised participants issue
requests.
• Business validation:
The SSP will validate payment messages from a business point of view,
namely value date, participants and duplication of requests, and for
direct debits, the existence of valid pre-agreements between the parties
involved.
If the underlying rules are not followed, the payment will automatically be
rejected.
Revocation
Payment orders submitted by the PM participants and not yet executed may
be revoked at any time. Under no circumstances can any action be taken by
the sending participant to revoke such a payment at the point of debiting.
Version 1.13
52
4
Payment processing in the SSP
4.4
Payment flow
Payments are revoked via the Information and Control Module (ICM). It is
possible to revoke:
• individual payments
• all payments submitted
• all payments to a certain participant
Revoked transactions are marked in the ICM of the sender and receiver.
End-of-day
procedure
The end-of-day procedure includes the following steps:
No.
Step
Description
1
Cut-off for interbank and
customer payments
Payments submitted after the cut-off-time will be
automatically rejected
2
Processing of payments
after the clearing cut-off
Payments submitted before the cut-off time and not
yet settled will be executed between cut-off-time
and return time and immediately delivered to the
receiving PM participant
3
Deleting insuffiently covered payments
The sender receives an abort notification for
payments which have not been settled by the return
time
In principle there should always be one hour between the cut-off time for
customer and the cut-off time for interbank payments. The return time will
be defined some minutes after the cut-off time for customer/interbank
payments.
Access to
standing facilities
The Eurosystem offers two types of standing facilities:
• marginal lending facility
• deposit facility
The participants may access the marginal lending or deposit facility by
request at the latest 30 minutes after the actual cut-off time for interbank
payments. On the last Eurosystem business day of the minimum reserve
maintenance period, the deposit and the marginal lending facility can be
accessed for 60 minutes after the cut-off time for interbank paments.
Version 1.13
53
4
Payment processing in the SSP
4.4
Payment flow
Procedures
Granting access to the standing facility remains under the full control and
responsibility of the respective CB.
Depending on the structure implemented by that CB, requests by participants to access the standing facility will be processed:
• in the own environment of the CB
• via transfers between the Payments Module and the standing facilities
module on the SSP (if used by that CB).
Any negative balances on the RTGS accounts in the PM remaining at the
end of day are automatically considered to be a request for recourse to the
marginal lending facility.
Version 1.13
54
4
Payment processing in the SSP
4.5
Payment processing - entry disposition
4.5
Basics
Payment processing - entry disposition
In recent years, the management of liquidity and the improvement of liquidity efficiency, especially in RTGS systems, have become of utmost importance.
Offering a broad set of liquidity management features helps to fulfill the
objectives of TARGET2. These features may:
• give participants the tools to achieve a flexible and need-based control of
their payment flow, thereby limitating possible liquidity risks
•
•
•
•
result in faster settlement, with a reduced amount of liquidity
help to avoid potential systemic risk owing, eg to gridlock situations
increase transparency to participants
help, all in all, to achieve a higher degree of efficiency
The features are implemented in the Payments Module (PM) on a flexible
and optional basis. This is to allow each credit institution to meet their individual needs, ie the PM participants can simply "switch off" those tools they
do not need.
Objective for
settlement of
transactions
The aim of the processing in the PM is the fast and liquidity-saving gross
settlement of transactions with the following characteristics:
Influencing factors
The payment processing in the PM is influenced by the following factors:
• Cover for single payments or the balance of a group of payments
• Settlement in central bank money
• Immediate, irrevocable booking of settled payments
•
•
•
•
•
Liquidity available on the RTGS account
Setting limits
Used priority
Order of payments submitted
Opposing transactions and synchronisation of payments submitted
Version 1.13
55
4
Payment processing in the SSP
4.5
Payment processing - entry disposition
Basic principles
The following principles apply to the entire payment process in the PM:
• Every payment must be marked as "normal" or "urgent" or "highly
urgent". If no priority class is selected, payments are still handled as normal payments.
• Attempt to settle single or group of transactions immediately after their
delivery, with the exception of payments with an Earliest Debit Time indicator. These payments will be included in the settlement process from
the pre-set time.
• Offsetting payments are used to save liquidity.
• Payments that are finally executed are immediately posted to the RTGS
account of the sender (debit) and the receiver (credit).
• Only payments still not executed may be revoked.
• Queuing of transactions, which cannot be settled immediately, according
to their type in different queues (highly urgent queue, urgent queue, normal queue).
• For highly urgent payments the FIFO-principle applies. Urgent and normal payments will not be settled in the case that highly urgent payments
are queued. The only exception is that payments with lower priority can
be executed before if - and only if - this would allow an offsetting transaction to be settled and the overall effect of this offsetting would be a liquidity increase for that participant.
• For urgent payments the FIFO-principle applies. Normal payments will
not be settled if urgent payments are queued. The only exception is that
payments with a lower priority can be executed before if - and only if this would allow an offsetting transaction to be settled and the overall
effect of this offsetting would be a liquidity increase for that participant.
• Normal payments are executed using the "FIFO by-passing" principle, ie
normal payments submitted may be executed even if other normal
payments are still in the queue (provided that the balance on the RTGS
account is sufficient).
• Continuous attempt to settle transactions in the queues.
• Payment management on entry and the optimisation procedures for
Version 1.13
56
4
Payment processing in the SSP
4.5
Payment processing - entry disposition
queues can be run at the same time.
Principles of entry
disposition
The entry disposition takes offsetting transactions into account. The liquidity
of the PM participant is used to cover balances. In addition, in the case of
normal payments the defined limits are considered.
The following table shows which transactions are taken into account during
the entry disposition by the sender and/or receiver:
Sender
Single submitted payment only
Version 1.13
Receiver
All offsetting highly urgent/urgent and normal transactions in the queues
57
4
Payment processing in the SSP
4.5
Payment processing - entry disposition
Sequence of
settlement checks
The following diagram shows the different settlement checks:
Transaction
1
no
Same and
higher priority
queues empty ?
Offsetting
yes
no
position 1 check
successful ?
6
2
4 no
5
yes
3
Offsetting check
yes
with liq . increase
successful
?
7
8
Settlement criteria
fulfilled
10
?
yes
Queue
Booking on RTGS accounts
yes
no
Extended
offsetting
check
successful
?
no
9
11
Queue
Step
Description
1
The system checks whether there are already operations of an equal or higher
priority level in the queue (exception: if the submitted transaction is a normal
one, it is not checked if the "normal" queue is empty, because the FIFO-principle can be breached for normal payments).
2
If the highly urgent and urgent queue is not empty, a bilateral algorithm named
"offsetting check with liquidity increase" takes place. This algorithm is only successful if offsetting payments from the receiver are available and the sender will
afterwards have an increased liquidity position.
3
If offsetting transactions exist, it is checked if the submitted transaction fulfills
the other settlement criteria (ie bilateral or/and liquidity reservations not breached).
4
If no such offsetting transactions exist, the transaction is put in the queue.
5
If the highly urgent and the urgent queue is empty, a bilateral algorithm, the "offsetting position 1 check" takes place. This algorithm is only successful if offsetting payments on top of the receiver’s queue are available.
Version 1.13
58
4
Payment processing in the SSP
4.5
Payment processing - entry disposition
Step
Description
6
If the offsetting check is successful, it is checked if the submitted transaction fulfils the other settlement criteria (ie bilateral or multilateral limit and liquidity
reservations not breached).
7
If the offsetting check is not successful, a bilateral algorithm named "extended
offsetting check" takes place. This algorithm is only successful if offsetting
payments from the receiver (not only on top of his queue) are available and the
receiver will afterwards have an increased liquidity position.
8
If the extended offsetting check is successful, it is checked if the submitted
transaction fulfills the other settlement criteria (ie bilateral or multilateral limit
and liquidity reservations not breached).
9
If the extended offsetting check is not successful, the transaction is put in the
queue.
10
If the other settlement criteria (ie bilateral or multilateral limit and liquidity reservations not breached) are fulfilled, then the operation(s), is (are) settled on the
RTGS accounts.
11
If the other settlement criteria are not fulfilled, then the operation(s) is (are) put
in the queue until sufficient liquidity is available and the other settlement criteria
are fulfilled (details on the dissolution of the queues are given in chapter 4.6
Liquidity management).
If there is not sufficient liquidity available and/or the other settlement criteria are
not fulfilled till the time of covering is reached (according to the current TARGET
rules 17:07:30 hours for customer payments and 18:07:30 hours for bank-tobank transfers) the payments not settled will be rejected.
Note: If queued payments can not be cleared during the ongoing optimisation procedures and are still queued by the end of the day due to lack of
liquidity (including urgent or highly urgent reservation of liquidity) or insufficient limits, these payments will be rejected during end-of-day processing.
Version 1.13
59
4
Payment processing in the SSP
4.5
Payment processing - entry disposition
Bilateral
optimisation
mechanism
The following diagram shows the different types of optimisation mechanism:
Condition
Step/type
5
Offsetting
position 1
7
Extended
offsetting
2
Offsetting
with liq.
increase
offsetting (highly) urgent
transaction at position 1
in the queue of B
Result
transaction of A
queue of B
(H)Ut, Nt -->B
(H)Ut-->A
(H)Ut--> C
offsetting transaction
in the queue of B
with an amount smaller than the transaction
A => B
offsetting transaction at
position 1 in the queue
B with an amount higher
than the transaction
A => B
transaction of A
queue of B
(H)Ut,
Nt --> B
(H)Ut-->C
(H)Ut,
Nt-->A
transactions
are settled if position
is covered.
transactions
are settled if position
is covered.
liquidity increase
transaction of A
queue of B
(H)Ut-->C
(H)Ut-->B
(H)Ut,
Nt-->A
transactions
are settled if position
is covered.
liquidity increase
(H)Ut = highly urgent or urgent payment
Nt = normal payment
Version 1.13
60
4
Payment processing in the SSP
4.5
Payment processing - entry disposition
Additional
explanations
• Highly urgent and urgent transactions are processed generally, in accordance with the FIFO-principle. The FIFO-principle may however be breached, if it allows the participant to benefit from a liquidity increase.
• Normal transactions are processed according to the "FIFO by-passing"
principle. To save as much liquidity as possible, the FIFO-principle would
not be the optimal one.
• Offsetting position 1: The outcome of this check may be positive even in
the absence of offsetting transactions, provided that A's balance is sufficient to cover the amount of the operation.
• Extended offsetting: Same "breach" of the FIFO/priorities as in the offsetting with liquidity increase, this time from B's perspective.
• Offsetting with liquidity increase: A's queue contains operations which,
due to their priority and/or order in FIFO, should be processed before the
new operation. However, it is attempted to settle the new operation by
seeking an offsetting operation with an higher amount. Indeed, if this offsetting is successful, A will have more liquidity than before, and the
chances to settle the operations with a higher priority and/or order in
FIFO will increase.
"FIFO by-passing"
During entry disposition "FIFO by-passing" for payments with normal priority
means that they may be processed immediately (independent from other
queued normal payments) and can therefore breach FIFO order, under the
condition that the balance on the RTGS account is sufficient for that participant.
Unsuccessful
entry disposition
If the submitted transaction cannot be settled in the entry disposition, it is
placed into the highly urgent, urgent or normal queue, depending on the
payment type.
Version 1.13
61
4
Payment processing in the SSP
4.6
Liquidity management
4.6.1 Reservation facilities
4.6
Liquidity management
Business case
A direct participant in the Payments Module (PM) has the option to control
the use of the supplied liquidity by means of a reservation and limit system
according to individual needs.
Optional usage
The use of the reservation and limits is optional. The single features can be
combined with each other. Each participant also has the option to not define
any limit or reserve and thus use its full liquidity for each payment.
4.6.1
Types of reserves
Reservation facilities
The following table shows the different types of reserves offered in the PM:
Reserve
Reservation
process
Dedicated liquidity
for AS
Explanation
Highly urgent
It reserves liquidity for the execution of highly urgent transactions.
Urgent
It reserves liquidity for the execution of urgent transaction.
The reservation process consists of the following steps:
Step
Explanation
1
The direct PM participant defines the amount being reserved as highly urgent
and/or urgent reserve.
2
The direct PM participant marks those payments which should have access to
the reserved liquidity by determining the appropriate priority.
For the settlement of AS, especially night batches of SSS, the direct PM
participant can "set aside" liquidity ("dedicated liquidity") for this purpose
only (see chapter 5.2.6 Dedicated liquidity). This is effective by maintaining
a specific RTGS sub-account outside the group of RTGS accounts. The
balance of this RTGS sub-account will correspond to funds available to
settle this/these particular operation(s) and will not be consolidated by the
liquidity pooling functionality.
Version 1.13
62
4
Payment processing in the SSP
4.6
Liquidity management
4.6.1 Reservation facilities
Setting and
changing of
reservations
Reservation can be effected by direct PM participants using the ICM. Direct
PM participants have the possibility to
•
•
•
•
"reset" to zero the liquidity reserved
change the amount on demand during the day with immediate effect
establish a specific amount during the current day with immediate effect
input a default amount for the following day(s) (valid until a specific
amount is indicated).
The reservation for the settlement of night batches stemming from AS has
to be made before the closing of the operational day and operates on an
overnight basis.
Initiator of
reservation
To ensure that credit institutions maintain full control of their liquidity
management, only RTGS account holders are generally allowed to reserve
liquidity.
In some cases it is possible that central banks can adjust the amount reserved:
Case
Reason
1
for a special ancillary system (ie for "overnight" processing)
2
in contingency situations (eg technical problem faced by a credit institution)
For this purpose the CB has to receive an instruction or agreement from the
CI in advance as in any other cases the CB acts on behalf of the CI (eg set/
change of limits).
There is also the possibility that ancillary systems may submit a request for
"setting aside" liquidity on behalf of the participant (dedicated reserve, see
chapter 5.2.6 Dedicated liquidity).
Version 1.13
63
4
Payment processing in the SSP
4.6
Liquidity management
4.6.1 Reservation facilities
Effect of
reservation
The following diagram shows the effect of reservations on the use of liquidity for highly urgent, urgent and normal payments:
Liquidity in
the PM = 1,000
Maximum amount
of liquidity for
normal payments
= 700
Maximum amount
of liquidity for
urgent payments
= 900
Maximum amount
of liquidity for
highly urgent
payments
= 1,000
Urgent
reserve
= 200
Highly urgent
reserve = 100
The following table explains the effect of the reservation functionality:
Effect
Highly urgent payment
Urgent payment
Available liquidity
Balance on RTGS account
+ credit line (if available)
Balance on RTGS account
+ credit line (if available)
./. highly urgent reserve
Effect of outgoing
payments
• Reduction of balance
• Reduction of balance on
Effect of incoming
payments
on RTGS account
Reduction of highly
urgent reserve
• Reduction of urgent
Increase of balance on
RTGS account
Increase of balance on
RTGS account
•
RTGS account
reserve
Normal payments have access, at all times, to the balance on the RTGS
account + credit line (if available) ./. highly urgent reserve ./. urgent reserve.
Version 1.13
64
4
Payment processing in the SSP
4.6
Liquidity management
4.6.1 Reservation facilities
The following table gives further explanations on the basis of a numeric
example:
Note: It is assumed that no credit line is available
Activity
Balance on RTGS
account
Start
Settlement of ancillary system = 50
(debit)
ò
Submitting urgent
payment to Bank B
= 200
ò
Submitting normal
payment to Bank C
= 20
ò
Settlement of ancillary system = 100
(credit)
(Un)successful
reservation
ñ
Incoming urgent
payment from Bank
B = 50
ñ
Incoming normal
payment from Bank
C = 30
ñ
Highly urgent
reserve
Urgent reserve
1,000
100
200
950
50
200
750
730
830
880
910
ò
ó
ó
ó
ó
ó
50
50
50
50
50
ó
ò
ó
ó
ó
ó
0
0
0
0
0
After receipt of the reservation request the system checks, whether the
amount of liquidity on the direct PM participant's RTGS account is sufficient
for the reservation.
Enough liquidity available
Requested amount will be
reserved.
Not enough liquidity available
• Liquidity available on the account will be reserved.
• Participant will be notified that the total amount could
not be reserved.
• The rest of the liquidity will not be blocked at a later
point, even if the participant's balance reaches the
level of the initial reservation request.
Version 1.13
65
4
Payment processing in the SSP
4.6
Liquidity management
4.6.2 Limits
4.6.2
Types and
characteristics of
limits
Limits
The following table shows the different types of limits offered in the PM:
Limit
Explanation
Bilateral limits
With the bilateral limit, the direct PM participant restricts the use
of liquidity, when submitting normal payments for another direct
PM participant.
Multilateral limits
With the multilateral limit, the direct PM participant restricts the
use of liquidity, when submitting normal payments for any other
direct PM participant for whom a bilateral limit has not been set.
The limits are sender limits and not credit limits, eg they determine the
payment amount a participant is willing to pay, without having received
payments first.
Note: Limits can not be defined among direct PM participants belonging to
the same group of accounts.
Objectives for the
use of limits
The setting of limits enables the direct PM participant:
• to prevent unbalanced dissipation of liquidity with regard to other direct
PM participants
• to avoid free-riding on the liquidity of a direct PM participant by another
participant
• to synchronise the payment flow with other direct PM participants and to
promote its early submission
Limitation process
The limitation process consists of the following elements:
• Definition of bilateral limits towards selected direct PM participants
• Definition of a multilateral limit towards direct PM participants towards no
bilateral limit is defined
A normal payment can only be settled if it does not cause the bilateral or
multilateral position to go beyond the bilateral or multilateral limit.
Version 1.13
66
4
Payment processing in the SSP
4.6
Liquidity management
4.6.2 Limits
Notes:
• Setting limits is only possible vis-à-vis RTGS account holders in the
SSP.
• A bilateral or multilateral limit with an amount of zero is a limit which is
not defined.
To take a limit (bilateral or multilateral) into account during the settlement
process, it has to be defined the business day before. This means that an
amount above zero has to be defined before the end of the business day
before. But once a limit is defined, it can be changed as described in the
table below.
Setting and
changing of limits
There are appropriate functions available in the ICM for setting and changing limits.
The following table shows the options for setting and changing:
Activity
Initiator of limit
setting and
changing
Explanation
Setting limits
They can be set with effect from the next operating day until further
notice.
Changing limits
They can be increased or decreased and reduced to zero
• for the current business day with immediate effect
• for future business days with effect of the next business day
at any time during the day.
If a limit is once reset to zero, it will not be possible to increase it
again on the same business day. On this day the consequence is,
that during the settlement of normal payments it is not checked any
more whether or not the respective limit will be breached.
Limits are exclusively set by direct PM participants. It is not possible to use
limits vis-à-vis participating CBs.
Only in the case of a technical problem on the direct PM participant's site,
the CB can be authorised by him to adjust the amount of a limit with impact
to the next algorithm.
Version 1.13
67
4
Payment processing in the SSP
4.6
Liquidity management
4.6.2 Limits
General effect of
limitation
The following table explains the effects of the limits:
Normal payment
Available liquidity
Balance on RTGS account
+ credit line (if available)
./. highly urgent reserve
./. urgent reserve
Effect of outgoing
payments
• Reduction of balance on RTGS account
• Reduction of bilateral or multilateral position (Payments will
be queued, if bilateral or multilateral position would exceed
the limits).
Effect of incoming
payments
• Increase of balance on RTGS account
• Increase of bilateral or multilateral position
Bilateral position
Bilateral position towards Bank B is defined as the sum of payments received from Bank B, minus the sum of payments made to Bank B.
Multilateral
position
Multilateral position is defined as the sum of payments received from direct
PM participants towards which no bilateral limit has been defined, minus the
sum of payments made to these direct PM participants.
Version 1.13
68
4
Payment processing in the SSP
4.6
Liquidity management
4.6.2 Limits
Bilateral limit
The following diagram shows the effect of the bilateral limit on the use of
liquidity for normal payments:
Bank A
Normal
payments
to Bank B
Bilateral
limit of Bank A
Bank B
Liquidity for
settling
normal payments
Normal
payments
to Bank A
Usable liquidity
for settlement with Bank B
Not usable liquidity for settlement
with Bank B
Version 1.13
69
4
Payment processing in the SSP
4.6
Liquidity management
4.6.2 Limits
The processing of normal payments in case Bank A has set a bilateral limit
for Bank B is illustrated in the following simplified example:
Bilateral
relation
Bilateral
limit set
Submitted
normal
payments
Explanation
Bank A vis3 million
à-vis Bank B EUR
10 million
EUR
Up to a maximum of 3 million EUR of Bank
A’s liquidity will be used to settle normal
payments between Bank A and Bank B.
Bank B visNot relevant
à-vis Bank A in this
example
6 million
EUR
If Bank A has sufficient liquidity available, a
maximum of 9 million EUR from Bank A
and 6 million EUR from Bank B can be settled.
1 million EUR from Bank A cannot be settled and are queued until
• additional payments from Bank B will be
settled or
• Bank A increases the bilateral limit to an
amount of 4 million EUR.
Otherwise the normal payments will not be
settled and will be rejected by the end of
the day.
Version 1.13
70
4
Payment processing in the SSP
4.6
Liquidity management
4.6.2 Limits
Multilateral limit
The following diagram shows the effect of the multilateral limit on the use of
liquidity for normal payments:
Bank A
Normal
payments
to Banks
C, D, E,...
Multilateral
limit of Bank A
Banks C, D, E,...
Banks C, D, E ...
Liquidity for
settling
normal payments
Normal
payments
to Bank A
Usable liquidity
for settlement with Banks C, D, E, ...
Not usable liquidity for settlement
with Banks C, D, E,...
Version 1.13
71
4
Payment processing in the SSP
4.6
Liquidity management
4.6.2 Limits
The processing of normal payments in the case of Bank A has set a multilateral limit is illustrated in a following simplified example (Bank A has not
defined a bilateral vis-à-vis those banks):
Multilateral
relation
Multilateral
limit set
Bank A visà-vis banks
C, D, E, ...
2 million
EUR
20 million
EUR
Up to a maximum of 2 million EUR of
Bank A’s liquidity will be used to settle
payments between Bank A and Banks C,
D, E, ...
Banks C, D,
E, ... vis-àvis Bank A
Not relevant
in this
example
15 million
EUR
If Bank A has sufficient liquidity available,
a maximum of 17 million EUR from Bank
A and 15 million EUR from Banks C, D,
E, ... can be settled.
3 million EUR from Bank A cannot be
settled and are queued until
• additional payments of Banks C, D,
E,... will be settled or
• Bank A increases the multilateral limit
to an amount of 5 million EUR.
Otherwise the normal payments will not
be settled and rejected by the end of the
day.
Version 1.13
Submitted
normal
payments
Explanation
72
4
Payment processing in the SSP
4.6
Liquidity management
4.6.3 Comprehensive queue management
4.6.3
Interventions on
queued payments
Comprehensive queue management
As long as a payment is not settled, the sending participant has the ability to
change the relevant parameters of this payment. The following options for
intervention at transaction level are offered by the PM:
• Ability to change the payment type of a queued transaction (= change of
priority)
• Re-ordering of queued transactions (exception MT 204: the receiving
participant (debitor) has the ability to re-order)
• Changing the settlement time
• Revocation of a queued transaction
Those features are necessary to enable direct PM participants to react to
changing liquidity conditions during the day.
Note: The Re-ordering of queued transactions is available for all payment
types (also for highly-urgent - to be confirmed).
In case of intervention at transaction level by a direct PM participant, processes are started to resolve the queues.
Changing the
payment type
(priority)
The following table shows the options for changing the payment types and
those participants in the PM allowed to use the different possibilities:
Payment type
Highly urgent
transactions
Urgent
transactions
Normal
transactions
Participants allowed to use
the option
• Credit institutions
• Ancillary systems
• Central banks
Highly urgent payments can only be initiated by ancillary systems (AS) and
CBs except CLS payments. For these payments also credit institutions are
allowed to use the priority class 0 (to be confirmed).
Version 1.13
73
4
Payment processing in the SSP
4.6
Liquidity management
4.6.3 Comprehensive queue management
The payment type can be changed at any time during the operating day.
The sender and the receiver credit institution can see the changed payment
type in the ICM.
The modified payment:
• keeps the original submission time
• is placed in the queue according to the (new) priority and the (old) submission time
• is processed according to the regulations of the (new) priority
The effect of changing the payment type will be:
• Change of the first queued urgent payment into a normal payment:
– If no highly urgent payment is queued immediate attempt to settle the
remaining urgent payments following the FIFO-principle.
– If highly urgent payments are queued no immediate attempt to settle
any urgent payments.
• Change of a normal payment into an urgent payment:
– If the payment changed from normal to urgent moves at the top of the
queued urgent payments and no highly urgent payments are queued,
immediate attempt to settle urgent payments following the FIFO-principle.
– Otherwise no immediate attempt to settle urgent payments.
Re-ordering the
queued
transactions
The sender (except MT 204: receiver/debitor) can change the queue position for an individual or for a sequence of payments. The selected payment
or sequence of payments can be placed:
• to the top of the queued payments with the same payment type
• to the end of the queued payments with the same payment type
The re-ordering can be done at any time during the operating day. The sender and the receiver credit institution can see the changed order in the
queue in the ICM.
Version 1.13
74
4
Payment processing in the SSP
4.6
Liquidity management
4.6.3 Comprehensive queue management
The following table shows the effect of changing the order in the queue:
Action
Effect on payment management
Moving a highly urgent payment to the top
of the queued highly urgent payments
Immediate check whether other payments
can be executed
Moving a highly urgent transaction from
the top to the end of the queued highly
urgent payments
Moving an urgent payment to the top of
the queued urgent payments
Moving an urgent payment from the top to
the end of the queued urgent payments
Moving a highly urgent payment which is
not at the top of the queued highly urgent
payments to the end
It is taken into account during the next
settlement process - no immediate
attempt to settle.
Moving an urgent payment which is not at
the top of the queued urgent payments to
the end
Moving a normal transaction to the top or
the end of the queued normal payments
Changing the
settlement time of
payments till
Payments can include a time that indicates when they should have been
settled (transactions with a "Latest Debit Time indicator").
The settlement time may be changed in the ICM. The change has no impact
on the payment processing, as the time indication only supports the direct
PM participant's queue management. The ICM shows the changed settlement time.
Version 1.13
75
4
Payment processing in the SSP
4.6
Liquidity management
4.6.3 Comprehensive queue management
Changing the
settlement time of
payments from
Payments can include a time that indicates when they should be settled
(transactions with an „Earliest Debit Time indicator").
Changing the settlement time has the following impact on the queue
management:
Action
Revocation of a
queued
transaction
Effect on queue management
Deleting the settlement time of a highly
urgent transaction
Immediate settlement attempt, if the
payment reaches the top of the queued
highly urgent payments.
Deleting the settlement time of an urgent
transaction
Immediate settlement attempt, if the
payment reaches the top of the queued
urgent payments and no highly urgent
payments are queued.
Deleting the settlement time of a normal
transaction
Including the payment in the next settlement process.
Changing the settlement time of a highly
urgent, urgent or normal transaction
Including the payment from the new indicated time.
Highly urgent, urgent and normal payments not yet settled may be revoked
at any time during the operation day.
Transactions are revoked via the ICM. More information is given in chapter
6.2 Information and control measures in the ICM.
Version 1.13
76
4
Payment processing in the SSP
4.6
Liquidity management
4.6.4 Optimisation procedures
4.6.4
Event-oriented
resolving
Optimisation procedures
The (highly) urgent queue is resolved in an event-oriented way starting with
the transaction at the top.
The following table describes the origin of possible events:
Events
Liquidity increase
Intervention on queue level
by...
• Incoming transactions
• Liquidity transfer from home account at CB
• If the transaction on the top of the (highly) urgent
queue is changed (change of order, change of priority, revocation)
Resolving the (highly) urgent queue and entry disposition is handled in the
same way. If a single highly urgent or urgent payment cannot be settled, it
will remain in the queue (at maximum till the end of the business day).
Principles
The normal queue is continuously resolved by including highly urgent and
urgent payments not yet settled. There are four different algorithms available:
•
•
•
•
All-or-nothing optimisation (algorithm 1)
Partial optimisation (algorithm 2)
Multiple optimisation (algorithm 3)
Partial optimisation with ancillary system (algorithm 4).
The single algorithms are used either sequentially or according to the situation. This is to respond in a flexible way to changed liquidity conditions
during the operating day:
The algorithms run sequentially,
• while there is no pending simultaneous multilateral ancillary system:
– algorithm 1 then algorithm 2 then algorithm 3 ...
– if algorithm 2 succeeds then algorithm 1 will run again
• while there is a pending simultaneous multilateral ancillary system:
– algorithm 4
Version 1.13
77
4
Payment processing in the SSP
4.6
Liquidity management
4.6.4 Optimisation procedures
The algorithms run in a flexible way by defining a parametrable time lag between execution of different algorithms.
Algorithm 1: Allor-nothing
optimisation
The following diagram and table explain the functioning of algorithm 1:
Actual
balance
participant A
Incoming
pending
operations
Outgoing
pending
operations
Total position
participant A
Credit limit
participant A
Actual
balance
participant B
Incoming
pending
operations
Outgoing
pending
operations
Total position
participant B
Credit limit
participant B
Step
Description
1
For each direct PM participant, the total position is calculated. It consists of
the
sum of actual balance,
+ incoming payments,
./. outgoing payments.
2
If all total positions are covered, all transactions are settled, provided they
meet the other settlement criteria (ie bilateral or multilateral limits and liquidity reservations are not breached; time indicator is fulfilled).
3
If merely one position is not covered, or if settling the transactions would
cause the bilateral or multilateral limits or liquidity reservations to be breached, no transaction settles and algorithm 2 is triggered.
Version 1.13
78
4
Payment processing in the SSP
4.6
Liquidity management
4.6.4 Optimisation procedures
Algorithm 2:
Partial
optimisation
The following diagram and table explain the functioning of algorithm 2:
Actual balance
part. A
Incoming Outgoing
pending
pending
operations operations
Retaining
single
transactions
Incoming
pending
operations
Outgoing
pending
operations
Credit limit
part. A
participant
A
Total position
participant A
Actual balance
participant B
Incoming Outgoing
pending
pending
operations operations
Incoming
pending
operations
Outgoing
pending
operations
Credit limit
part. B
participant
B
Total position
participant B
Step
Description
1
For each direct PM participant, the total position is calculated according to
algorithm 1. All total positions are checked for cover.
2
If all total positions are covered, all transactions are settled.
3
If merely one total position of a direct PM participant is not covered, single
transactions are retained till the liquidity of the participant is sufficient for
covering its total position. Retained transactions are included in the next
clearing process.
For the retainment of transactions the following rules apply:
• The selection process will only run for a short time.
• Transactions at the end of the queue will be first checked concerning
retainment.
• The selection is started with the direct PM participant with the highest
uncovered total-debit position.
If run of algorithm 2 does not succeed, algorithm 3 is activated.
Version 1.13
79
4
Payment processing in the SSP
4.6
Liquidity management
4.6.4 Optimisation procedures
Algorithm 3:
Multiple
optimisation
Algorithm 3 consists of two steps following one after another.
Step 1
The following diagram and table explain the functioning of step 1 of algorithm 3:
cover check
Determing sequence of processing
Bank A
Bilateral
Bank F Bank M Bank C Bank G Bank D Bank K Bank F
Bank K
Transaction
of Bank A
for Bank X
parameter for
offsetting
little
offsetting
parameter for
liquidity need
relative good
offsetting
10
6
high
liquidity need
relative low
liquidity need
4
2
sequence
relative little
offsetting
good
offsetting
8
relative high
liquidity need
3
4
low
liquidity need
1
Transaction
of Bank X
for Bank A
Bilateral
Transaction
of Bank A
for Bank H
Transaction
of Bank H
for Bank A
Bilateral
Transaction
of Bank A
for Bank K
Transaction
of Bank K
for Bank A
Transactions which should be processed bilaterally (ie between two participants of which at least one has defined a bilateral limit towards the other)
are cleared as follows:
Step
Description
1
Determine the objective sequence of how the bilateral queue should be
worked through: first the pairs of transactions with the best offsetting, then
the other pairs of transactions.
2
Check the bilateral positions regarding coverage. If the settlement of a
transaction is not possible due to a lack of liquidity or breached limits, single transactions are retained in the queue.
Version 1.13
80
4
Payment processing in the SSP
4.6
Liquidity management
4.6.4 Optimisation procedures
Step 2
The following diagram and table explain the functioning of step 2 of algorithm 3:
Checks:
Multilateral
Transactions
Transactions
of Bank A
of Banks
for Banks
B, C, D
B, C, D
for Bank A
Limits breached ?
Liquidity sufficient ?
Transactions which should be processed multilaterally are cleared as follows:
Step
Description
1
Check the multilateral position regarding coverage.
2
If the settlement of a transaction is not possible due to a lack of liquidity or
breached limits, single transactions are retained in the queue.
Version 1.13
81
4
Payment processing in the SSP
4.6
Liquidity management
4.6.4 Optimisation procedures
Algorithm 4:
Partial
optimisation with
ancillary system
The following diagram and table explain the functioning of algorithm 4:
Incoming Outgoing
pending pending
operations operations
Actual balance
part. A
retaining
single
transactions
Incoming
pending
operations
AS debit
(locked)
Credit limit
participant A
AS debit
Outgoing
pending
operations
Total position
participant A
Incoming Outgoing
pending pending
AS debit (locked)
operations operations
Actual balance
participant B
Incoming AS debit
pending
Outgoing
operations pending
operations
Credit limit
participant B
Total position
participant B
Step
Description
1
For each direct participant, the total position is calculated according to
algorithm 1. All total positions are checked for cover.
2
If all total positions are covered, all transactions are settled.
3
If just one total position of a participant is not covered, single transactions
are retained until the liquidity of the participant is sufficient for covering its
total position.
During the selection procedure the AS position remains unchanged (ie AS
debits are never retained).
Retained transactions are included in the next clearing process.
If algorithm 4 succeeds, all payments and AS transactions will be settled.If
algorithm 4 does not succeed, it will be restarted after a short while. It may
also be possible to use algorithm 3 instead.
Version 1.13
82
4
Payment processing in the SSP
4.6
Liquidity management
4.6.5 Pooling of liquidity: grouping of accounts
4.6.5
Pooling of liquidity: grouping of accounts
Objectives
• Avoiding liquidity fragmentation in the TARGET2 system
• Simplifying liquidity disposition and usage
Different
possibilities
In general there are different possibilities and steps imaginable to offer participants in the PM:
• Access to centralised information on their general cash position in the
Eurosystem
• Usage of their global credit position from any entity of the credit institution
Group of accounts
A "group of accounts" would consist of one or several RTGS accounts in
the books of one or several central banks joining the SSP and held by one
or several authorised participant(s) to TARGET2. The intra-day liquidity on
these accounts would be "pooled" at the group of accounts level. Thus, the
"intra-day liquidity available" to settle the payment orders sent by a given
participant would be defined as follows: sum of all balances (and if available, overdraft limits) of the RTGS accounts belonging to the group of
accounts, minus reserved funds (if any) for specific operations.
Note: The facility to reserve funds for specific operations is possible at the
level of the group of accounts. Fund reservation can also be done by "keeping aside" liquidity in a specific account that does not belong to the group
of accounts.
This can be done:
Level
Explanation
On domestic level
A group of accounts is comprised of
accounts belonging to the same CB.
On cross-border-level within the PM
A group of accounts is comprised of
accounts belonging to different CBs; this
may, in particular, be the case for multinational credit institutions.
Version 1.13
83
4
Payment processing in the SSP
4.6
Liquidity management
4.6.5 Pooling of liquidity: grouping of accounts
Two main variants
Two main variants are described in more detail below:
• Consolidated information
• Virtual account
Note: The decision whether SSP will offer "consolidated information“ or "virtual account“ will be taken by the Governing Council.
Consolidated
information
The amount of liquidity is shown and can be controlled by the direct PM participant on a consolidated level. The main features are:
• Possibility to have access to all grouped RTGS accounts
• Offer of information screen with liquidity position of all single RTGS
accounts belonging to the group
• Pooling of liquidity by direct debit functionality done by participant
Virtual account
For all RTGS accounts belonging to one group, a "virtual" account is created. The main features are:
• Aggregation of the relevant data of the single RTGS accounts
• Existence of a "single payment queue" as consequence of having only
one "global liquidity position" for the group
• Possibility to "use" this position by each RTGS account-holder
• Payments are always checked against the "global liquidity“ in the group,
but settled on the single account of the sender
• Offer efficient end-of-day procedures to assure that the funds are allocated in a proper way between the concerned CBs to avoid overnight overdrafts (debit balances in single RTGS accounts which belong to one
group are strictly limited to the intra-day-sphere) and in view of the adequate management of monetary reserves.
Version 1.13
84
4
Payment processing in the SSP
4.6
Liquidity management
4.6.5 Pooling of liquidity: grouping of accounts
Only RTGS accounts can be grouped. The accounts listed below are excluded from grouping:
•
•
•
•
Home accounts, even if technically held in the same platform
accounts with central banks held on SSS platforms (ie integrated model)
accounts of remote access participants
accounts held with non-euro central banks (to be discussed)
One RTGS account can belong to one group of accounts only. Of course
several RTGS accounts of the same PM participant can be within the same
group of accounts.
The principle of intra-day liquidity pooling within a group of accounts allows
the establishment of a "common payment queue" for a group of accounts.
In such a setting, it is no longer necessary to implement intra-day liquidity
management facilities at the RTGS account level. The intra-day liquidity
position of the group of accounts can be managed in a centralised way by
the "group-of-accounts' manager". However, although the group-ofaccounts' manager can manage the common queue for the group of
accounts, the holders of the RTGS accounts keep the possibility to define
the priority of their payments and can revoke their queued payments.
When a payment is posted to the RTGS account of the ordering bank, the
possibility to debit the RTGS account is assessed against the "liquidity available" (as previously defined) in the group of accounts to which that RTGS
account belongs. If the "liquidity available" is bigger or equal to the value of
the payment order and also a defined limit positions is covered (if available),
the RTGS account of the ordering bank is debited, even if this results in a
negative balance. Otherwise, the payment order is queued.
Version 1.13
85
4
Payment processing in the SSP
4.6
Liquidity management
4.6.5 Pooling of liquidity: grouping of accounts
The group-of-accounts' manager should be entrusted with all powers on all
RTGS account within the group of accounts (a legal framework would need
to be defined for this). In particular:
• Each member of the group of accounts shall grant full powers to the
group-of-accounts' manager to carry out any transaction on any RTGS
account in the group of accounts.
• The group-of-accounts' manager is responsible for the intra-day monitoring of the "liquidity available" at the group of accounts level.
• Efficient end-of-the-day procedures will assure that all debit positions are
levelled out against the available cash within the group of accounts. This
process will also ensure that the debit position of each account - if any does not exceed the overdraft limit (where available).
• The group of accounts' manager will be in contact with its home CB as
any other participant in the SSP.
Each holder of (a) RTGS account(s) within the group of accounts is responsible for ensuring the compliance of its institution with the minimum reserve
requirements - if any - and it is the responsibility of the group of accounts'
manager to establish an adequate internal organisation for this.
Illustration of the
settlement
process
Group of accounts A comprises three RTGS accounts belonging to banks
A1, A2, A3:
Account Group A : initial situation (overall net balance: 10+30+20=60)
Bank A1
balance
10
Bank A2
30
Bank A3
20
Suppose that bank A1 initiates a credit transfer of 50 in favour of bank X.
Although the balance on the RTGS accounts of bank A1 is only 10, the
transfer will be executed because the group of account overall balance is
sufficient. The balance of the RTGS accounts within the group of accounts
will evolve as follows:
Version 1.13
86
4
Payment processing in the SSP
4.6
Liquidity management
4.6.5 Pooling of liquidity: grouping of accounts
Situation after execution of the payment
(overall net balance: -40+30+20=10)
Bank A1
balance
50
-40
Bank A2
Bank A3
10
30
20
In general it is under the responsibility of the group-of-accounts' manager to
balance the accounts belonging to the group of account at the end of the
day. Nevertheless the SSP will have an (emergency) procedure in place in
case the group-of-accounts' manager is not able to balance the accounts in
time.
Account Group A : situation after end-of-day levelling (balance: 0+0+10=10)
Bank A1
50
10
30
10
0
Bank A2
30
30
0
Bank A3
10
20
10
Explanation:
(1) The account of Bank A2 is debited and the account of Bank A1 is credited with an amount of 30.
(2) The account of Bank A3 is debited and the account of Bank A1 is credited with an amount of 10.
After executing these transactions the accounts of the three banks belonging to the group-of-accounts are balanced.
Version 1.13
87
4
Payment processing in the SSP
4.6
Liquidity management
4.6.5 Pooling of liquidity: grouping of accounts
Alternatively to the example on balancing the accounts the group-ofaccounts' manager could as well have moved 20 out of the account of Bank
A2 and 20 out of the account of Bank A3 (or any other combination in order
to transfer a total amount of at least 40 into the account of Bank A1). In
practice, the choice may be related to the reserve requirements (if any) of
the respective settlement accounts holders.
Need for sound
legal basis
Intra-day liquidity pooling within a group of accounts relies on the principle
that the debit position of an account within a group is "collateralised" by
cash or credit line held on the other accounts within the group of accounts.
The group-of-accounts' manager will have full access to the intra-day liquidity and overdraft limits held in all accounts within a group. In a context
where the accounts within the group of accounts may be held in different
central banks, legal arrangements need to be worked out in order to ensure
the enforceability of collateralisation in case of default of an account holder
whose account is in debit. In other words, the holders of the accounts within
a group have to be collectively responsible for the debit positions that may
arise on any RTGS account within that group of accounts. For that purpose,
it might be necessary that pooling is only allowed for participants having
between themselves a capital and/or management link (ie belong to the
same "banking group"). Furthermore, the possible consequences of a bank
becoming insolvent during the day need to be explored.
Version 1.13
88
5
Ancillary system settlement
5.1
Ancillary System Interface
Integration into
SSP
5
Ancillary system settlement
5.1
Ancillary System Interface
From market and overseers perspective, there are strong requirements to
settle the cash leg of securities transactions and other comparable transactions (from retail or large value payment systems, fx systems, money market systems,clearing houses, etc.) in central bank money. Today this is
done very often by normal payment procedures (eg EBA, CLS) or with special functionality within the local national home accounting system or the
national RTGS.
In the interest of credit institutions and ancillary systems, the needed functionality is also offered by the SSP.
Advantages
Advantages for ancillary systems (AS) are:
• Broader accessibility of participants (also in a cross-border context)
• Broad range of streamlined functionality
Advantages for credit institutions as participants of ancillary systems using
the Ancillary System Interface (ASI):
• Liquidity pooling (usage of one RTGS account for several ancillary systems)
• Cross border usage (easier remote access to ancillary systems)
• Integration with normal payment business
Users
The Ancillary System Interface can be used by CBs, for their own purposes
(eg cash withdrawals) or on behalf of ancillary systems, and by ancillary
systems themselves.
Version 1.13
89
5
Ancillary system settlement
5.1
Ancillary System Interface
Ancillary systems are:
•
•
•
•
•
•
Retail payment systems
Large value payment systems
FX systems
Money market systems
Clearing houses (CCP)
Securities settlement system (SSS)
When referring to interface with SSSs in the SSP, the SSSs are qualified as
ancillary systems. However SSSs have a peculiar feature in comparison to
other ancillary systems: they are both users of the SSP and service provider for TARGET2 (and the Eurosystem in general). On the one hand the
SSSs need TARGET2 to settle in central bank money the cash leg of securities transactions on a DVP basis. On the other hand, TARGET2 participants, or in general, Eurosystem counterparts will mobilise collateral in view
of getting liquidity from the Eurosystem through SSSs.
In the long run all ASs will settle all their positions in the SSP. Nevertheless,
to allow a smooth transition to SSP, the settlement on local home accounts
will be permitted even after the ending of the migration phase, during a predefined limited period. In any case the CB which provides local home
accounts may decide, after a consultation with the users of AS and the AS
itself, whether to settle in the SSP using the ASI or to settle in the local
home account. Furthermore the AS will decide which services provided by
the ASI to utilise.
Standardisation
The Ancillary System Interface is a standardised interface to the PM. Standardisation will take place for:
• Messages (SWIFT standard messages)
• Network and services (SWIFTNet services)
• Settlement processing (generic settlement procedures - see below)
Version 1.13
90
5
Ancillary system settlement
5.1
Ancillary System Interface
Nevertheless by using optional mechanism (see below), it should be possible to adjust the Ancillary System Interface to existing procedures as
much as possible. This is in accordance with their rules without the obligation to maintain - like "normal" participants - a fully-fledged payment platform. On the other hand, ancillary systems wishing to have an own payment
platform and to perform their operations with the PM as "standard"
payments, will have the freedom to do so.
General features
In order not to impose a change of the settlement model implemented in
existing SSSs, which would not be easy considering the specific domestic
laws and the impact on the systems' users, the PM will allow the settlement
through the two major models:
• Integrated model:
The final settlement of the cash leg takes place (both night and day) in
the SSS itself; cash accounts' management is outsourced by the CB to
the SSS.
• Interfaced model:
The final settlement of the cash leg takes place in the PM.
As these two models have been developed in line with the existing national
laws, for SSSs which operate night cycles, the difference between integrated and interfaced is mainly a matter of legal and contractual relationship
between the SSS and the CB and not a technical matter.
To support both the integrated and interfaced model, the SSP will provide
as follows:
• Payment messages: by means of the Ancillary System Interface, ancillary systems may initiate credit transfers, direct debits and mandated
payments
• Information messages: "dedicated liquidity" (ie blocking of cash, both
acquisition and notification) and auto collateralisation for increasing the
cash balance on RTGS accounts
• Technical cash account in the name of the SSS, ie for net DVP settlement
Version 1.13
91
5
Ancillary system settlement
5.1
Ancillary System Interface
Usage of
“standard“
payment
procedures
As today, standard payment procedures of the SSP can be used for both
models:
• In the integrated model, participants are allowed to transfer liquidity from
their RTGS account to an RTGS account of the ancillary system. This
liquidity must be mirrored to accounts in the name of the participants
held with the ancillary system.
• In the interfaced model participants have to "pay" their balances resulting
from the ancillary system.
The major disadvantage for ancillary systems is that the kick-off for the
payment must come from the participant.
Usage of the
Ancillary System
Interface
By using the Ancillary System Interface, an ancillary system can control the
initiation of liquidity flows. Nevertheless, it is the responsibility of each ancillary system participant to provide the needed liquidity (on the RTGS
account).
Generic settlement
procedures
To support different business cases related to the various types of ASs as
mentioned above (SSSs and ASs other than SSS), six generic settlement
procedures are provided by the PM via the Ancillary System Interface.
All BIS models (1, 2 and 3) are covered by the PM. Nevertheless, the linkage of a generic settlement procedure to a BIS model very often depends
on the national habit.
Version 1.13
92
5
Ancillary system settlement
5.1
Ancillary System Interface
PM generic
settlement
procedure
Integrated
model
Liquidity transfer Real-time link
Transfer between the cash position
of a participant in the ancillary
system and in the PM.
Interfaced
model
Real-time settle- Real-time link
ment
Transfer between the accounts of
two PM participants, aiming at finalising a transaction already able to
settle in the ancillary system.
Bilateral settlement
Batch
Debits and credits are posted
simultaneously in the PM but each
debit/credit is processed independently from the others.
Standard
multilateral settlement
Batch
Debits and credits are posted
simultaneously in the PM but all
debits have to be settled before
credits are made.
Simultaneous
multilateral settlement
Batch
Debits and credits are posted
simultaneously in the PM but all
debits and credits are simultaneously checked for settlement and
can only be settled on an all-ornothing basis.
Dedicated liquidity
Batch
Debits and credits are posted
simultaneously in the PM but all
debits are posted drawing on (and
up to) "dedicated liquidity" previously set aside by PM's participants.
Such a settlement procedure can
be used especially for overnight
business (the dedicated liquidity is set aside with next value
date), but also during the day.
Integrated/
Interfaced
model
Interaction
(batch/realtime)
Description
Settlement
model
Note: Batch means simultaneous sending of all the debit and credit transactions involved in the settlement and not necessarily that the transactions
are settled at the same time.
Version 1.13
93
5
Ancillary system settlement
5.1
Ancillary System Interface
Regarding ASs "other than SSS", many of the above indicated generic settlement procedures could be used. For example: Retail Clearing Payment
Systems might use (at least) the "standard multilateral" or the "simultaneous multilateral" procedures to settle their multilateral balances; Money
Market systems might use either the "real-time payment" or the "bilateral
settlement". Clearing Houses (CCPs) might use (at least) "bilateral settlement" or "standard multilateral settlement" procedure to settle margins of its
participants.
It should be underlined that the "real-time settlement" procedure could also
be utilised to settle multilateral balances of an AS that has an SSP technical
account; in such a case the AS should first send to the SSP individual debit
transactions (to be credited on the AS technical account) and then (after all
debits are settled) individual credit transactions (to be debited on the AS
technical account).
Details of each generic settlement procedure are given in chapter 5.2 Work
flow of generic settlement procedures.
Optional
mechanism
In addition to a mandatory settlement procedure, which must be chosen
from the prominent mentioned generic settlement procedures, the following
pre- and post-connected mechanism can be used to adjust the Ancillary
System Interface to specific needs of each ancillary system:
Mechanism
Related
interaction
Description
Control
period
Batch
Balances in the AS are pre-announced, Settlement Agents may express disagreement (=> possible re-calculation of balances).
Settlement
period
Batch
A limited period of time is allocated to the settlement of the ancillary system, so as to not prevent the settlement of other operations. If the
ancillary system is not settled at the end of
this period, either the respective balances are
rejected or a guarantee mechanism is activated
(see below).
Guarantee
mechanism
Batch
In case an ancillary system cannot be settled
using the sole liquidity of participants, this mechanism provides the complementary liquidity needed.
Version 1.13
94
5
Ancillary system settlement
5.1
Ancillary System Interface
Auto
collateralisation
Mechanism
Related
interaction
Description
Scheduled
time
("from")
Batch and real-time
link
If an ancillary system posts before the scheduled settlement time, it is stored until scheduled
settlement time is reached.
Time limit
("until")
Real-time link
An optional time period is allocated to the DVP or
liquidity transfer to settle (otherwise it is rejected)
As explained earlier, SSSs have a double role in PM (user and liquidity provider), which is in more and more countries combined during the settlement
procedure through so-called auto collateralisation.
According to ECSDA, auto collateralisation can exist in the form of:
• "firm" collateralisation (collateralisation on stock; participants determine
the eligible securities that could be used)
• "self" collateralisation (collateralisation on flows: with securities deriving
from the settlement process itself)
Therefore the PM will also provide such a procedure via:
• management of collateral by each CB within its collateral management
system
• standardised simplified procedure to change credit lines on the SSP via
the collateral management interface
Version 1.13
95
5
Ancillary system settlement
5.1
Ancillary System Interface
Information rules
In addition to settlement facilities, the Ancillary System Interface will provide
ancillary system operators via ICM full visibility on the status of payments/
net balances issued at any time, swiftly, during the entire process.
Furthermore, with reference to the information exchanged with ASI three
kinds of subject are considered:
• AS manager (or CB acting on its behalf)
– transmits a list of participants/Settlement Agents
– transmits end-of-day balances or real-time link instructions (ie indicate that a liquidity transfer has been initiated in its system) or
requests for DVP transfers
– receives settlement notifications, queuing notifications, indication of
the Settlement Agent responsible for queuing in a multilateral AS
– receives notifications of disagreement on balances
• CBs (either acting or not on behalf of AS manager)
– receive settlement notifications, queuing notifications for “their“ AS
and the AS in which their participants are involved
– receive notifications when one of their participants is responsible for
the queuing of a multilateral AS
• Settlement Agents
Since direct participants in ancillary system will not necessarily be, at the
same time, PM participants (and vice versa), some participants in ancillary systems will have to rely on designated PM participants ("Settlement
Agents").
The Settlement Agent settles for these AS's participants any obligations
in the PM arising from their participation in the ancillary system. The
Ancillary System Interface maintains the ancillary system participant/
Settlement Agent table.
Version 1.13
96
5
Ancillary system settlement
5.1
Ancillary System Interface
The Settlement Agent:
– receives settlement and queuing notifications
– responsible for the queuing of a multilateral AS receives a notification
for it
– receives acknowledgements (that the information he transmitted was
received and processed by the RTGS)
– sends disagreements on balances, if any exist
Settlement timing
Currently, the timing of the settlement of ancillary systems varies across
Europe.
As mentioned in the answer to the users consultation, "an attempt should
be made to optimise the settlement mechanisms and timing of ancillary systems within TARGET2 throughout the EU. The extreme varieties of settlement times are an obstacle to efficient liquidity management and create a
potential for operational risk".
Nevertheless, it is unavoidable that ancillary systems make an effort to
agree with central banks on some standard procedures for their efficient
settlement, including a greater harmonisation of settlement times.
The PM will provide all tools and mechanisms to implement and respect the
new schedule for settlement times.
Version 1.13
97
5
Ancillary system settlement
5.2 Work flow of generic settlement procedures
5.2.1 Liquidity transfer
5.2
Work flow of generic settlement procedures
5.2.1
Liquidity transfer
To transfer liquidity between the accounts of a participant held in PM and
AS, also the Ancillary System Interface can be used.
Liquidity transfer
AS -> PM
PM -> AS
SWIFTNet FIN
MT 202
SWIFTNet FIN
MT 202
MT 096
Settlement
Agent
PM
Participant interface
MT 202
MT 097
Settlement
Agent
Payment processing
Payment processing
Ancillary system interface
Ancillary System Interface
Ancillary system
or CB
on its behalf
Step
PM
Participant Interface
Booking
Acknowledgement
instruction
Ancillary system
or CB
notification
on its behalf
Description
AS to PM
The message sent by the AS via the Ancillary System Interface will be
sent out by the PM as an MT 202 to the participant.
PM to AS
• MT 202 sent by the Settlement Agent with the BIC of the PM. It has
•
•
Version 1.13
still to be confirmed whether payments sent by the Settlement
Agent to a special AS (eg CLS) will be treated like highly urgent
payments (priority class 0).
forwarded leg of the Y-copy not used
Notification will be sent out by PM via the Ancillary System Interface to AS
98
5
Ancillary system settlement
5.2 Work flow of generic settlement procedures
5.2.2 Real-time settlement
5.2.2
Real-time settlement
Transfer between the accounts of two PM participants:
Real time settlement
SWIFTNet FIN
Settlement Agent
MT 900
Settlement Agent
MT 910
of buyer
of seller
Participant Interface
Settlement attempt
Ancillary system
or CB
Payment processing
Information and Control Module
information
PM
notification
instruction
Ancillary System Interface
notification
on its behalf
• When a transaction eg securities purchase has been concluded, the AS
or the CB on its behalf issues an instruction to debit the "buyer's" Settlement Agent and to credit the "seller's" Settlement Agent.
• The Payments Module attempts to settle this operation.
• If it can settle then MT 900/910 are sent to the parties, and a positive
acknowledgement to the AS or CB.
• If the operation cannot be settled at the end of the time limit (if such limit
exists), it is cancelled and a negative acknowledgement is sent to the AS
or central bank.
• At each stage, information is available for Settlement Agents through the
Information and Control Module.
Version 1.13
99
5
Ancillary system settlement
5.2 Work flow of generic settlement procedures
5.2.3 Bilateral settlement
5.2.3
Bilateral settlement
Entry disposition of bilateral settlement"
AS transAS transaction
AS transAS transAS action
transaction debit
credit
debit
debit
3
1
no
Liquidity
sufficient ?
queue
yes
2
4
booking on RTGS accounts
Step
Description
1
Each debit transaction of a participant is checked against the liquidity available
in the account/group of accounts.
2
If yes, the transaction is settled.
3
If no, the transaction is posted in the waiting queue. The participant is informed by a broadcast delivered by the Information and Control Module.
4
Credit transactions are settled immediately.
After booking all transactions, the Ancillary System Interface sends a positive
acknowledgement to the AS.
Version 1.13
100
5
Ancillary system settlement
5.2 Work flow of generic settlement procedures
5.2.4 Standard multilateral settlement
5.2.4
Standard multilateral settlement
Entry disposition of
settlement
multilateral
AS transAS transaction
AS transAS transAS action
transdebit
action
credit
debit
debit
3
1
Liquidity
sufficient ?
no
yes
2
5
4
queue
settlement by resolving the queue
booking on RTGS accounts
Debits are posted first (ASs direct debits on the AS participants account in
return of the AS RTGS account). When they are all settled, credits are posted (credit transfers from the AS RTGS account to the AS participants
accounts).
Step
Description
1
Each debit transaction of a participant is checked against the liquidity available
in the account/group of accounts.
2
If yes, the transaction is settled.
3
If no, the transaction is posted in the waiting queue. The participant is informed by a broadcast delivered by the Information and Control Module. Immediately after putting the group of debit transactions in the queue the optimisation
process starts.
4
Pending transactions are settled by resolving the queue.
Version 1.13
101
5
Ancillary system settlement
5.2 Work flow of generic settlement procedures
5.2.5 Simultaneous multilateral settlement
5
5.2.5
After all debit transactions are covered and settled, the credit transactions are
processed and booked.
After booking all transactions, the Ancillary System Interface sends a positive
acknowledgement to the AS.
Simultaneous multilateral settlement
Entry disposition of
settlement
multilateral
group of AS
transactions
debit
credit
debit
debit
3
queue
Version 1.13
credit
1
no
Liquidity
sufficient ?
yes
2
booking on RTGS accounts
102
5
Ancillary system settlement
5.2 Work flow of generic settlement procedures
5.2.5 Simultaneous multilateral settlement
Debits and credits are posted simultaneously but they are settled only if all
participants with a debit position have enough funds available. The difference to the standard multilateral settlement model is that credits from the
ancillary system are considered in the optimisation mechanism. The settlement of debits takes place in the form of ASs direct debits on the AS participants accounts in return of the AS RTGS account; the credits are settled as
credit transfers from the AS RTGS account to the AS participants account.
Step
Description
1
Each debit transaction of a participant is checked against the liquidity available
in the account/group of accounts. Potential liquidity deriving from credit positions are taken into consideration.
2
If yes, all debit and credit transactions are settled and a positive acknowledgement is sent to the Ancillary System Interface.
3
If no, the group of transaction is posted in the waiting queue. The participant(s)
concerned is (are) informed by a broadcast delivered by the Information and
Control Module.
Immediately after putting the group of transactions in the queue algorithm 4
starts.
Version 1.13
103
5
Ancillary system settlement
5.2 Work flow of generic settlement procedures
5.2.6 Dedicated liquidity
5.2.6
General remarks
Dedicated liquidity
• By setting aside dedicated liquidity on a sub-account of an AS participant
within the SSP, which is directly related to one AS, liquidity is exclusively
reserved for this AS.
• Only direct PM participants can have this kind of sub-accounts to be
identified by the BIC of the RTGS main account and the sub-account
number.
• During settlement cycles the dedicated liquidity is blocked and can therefore be used for DVP processing in the SSS.
• Between two settlement cycles, the (remaining) dedicated liquidity is
released and can be adjusted manually or automatically.
• Manual orders for increase/decrease can either be posted by the participant via Information and Control Module (ICM) or by the ancillary system
via the Ancillary System Interface. In the last case, the order is set by the
participant in the infrastructure of the ancillary system.
• Parameters for automatic adjustments of the dedicated liquidity (max or
min amount of dedicated liquidity) are to be defined during the detailed
functional specification phase.
• Increase of dedicated liquidity can also be initiated by transactions to be
credited to the participant by the AS (coupons and redemption of securities) and by auto collateral transactions (see below).
Night batch
A particularity of several ancillary systems is night operations (usually night
batch securities settlement procedures of SSSs). The settlement of night
batches normally requires to perform the transfers for value next business
day without an impact on minimum reserve requirement.
The mechanism implemented is based on 2 steps:
• Reservation of funds in the accounts of the PM the day before the settlement day
• For each single AS, firstly settlement in the RTGS sub-account and then
release of (residual) blocked liquidity should be done
Version 1.13
104
5
Ancillary system settlement
5.2 Work flow of generic settlement procedures
5.2.6 Dedicated liquidity
Note: The modalities of this functionality have to be elaborated in more
detail after the discussion on Eurosystem level will be finished.
Settlement of night batches: reservation of funds
day before settlement day (S - 1)
participant
1
info & control
reservation
AS 2
6
AS 1
3
9
ASs
4
PM
2
Liquidity
sufficient ?
no
partly
sufficient
yes
5
3
AS reserve night
is blocked
AS reserve night
is partly blocked
totally
insufficient
7
request will be
deleted
6
8
Day before settlement day
Step
Description
1
Request of reservation of liquidity for each AS (defining as ancillary system
reserve night) by participant via the Information and Control Module or by
ancillary system via Ancillary System Interface, eg AS reserve night in
total: 9 (3 for AS1 and 6 for AS2).
2
Check if needed liquidity for the total AS reserve night requested is available.
Depending on the collateral management system used by the connected
CB, a re-calculation of the credit line can be necessary before the check.
3
If yes, amount of AS reserve night is blocked and transferred to a subaccount.
4
ASs get positive acknowledgements, information about successful reservation
is given to the participants in the Information and Control Module.
Version 1.13
105
5
Ancillary system settlement
5.2 Work flow of generic settlement procedures
5.2.6 Dedicated liquidity
Day before settlement day
Step
Description
5
If the needed liquidity is only partly available, the whole amount available is
blocked, eg
Available liquidity = 4
AS reserve night = 9 (for AS1 = 3, for AS2 = 6)
=> amount of AS reserve night for AS1 is blocked and for AS2 an amount of 1
is reserved only.
6
ASs get information on the blocked amount, information on only partial successful reservation is given to the participant in the Information and Control
Module.
7
If no liquidity is available, requests are deleted.
8
ASs get negative acknowledgements, information about unsuccessful reservation is given to the participant in the Information and Control Module.
Version 1.13
106
5
Ancillary system settlement
5.2 Work flow of generic settlement procedures
5.2.6 Dedicated liquidity
Settlement of night batches: settlement
settlement day (S)
before 6.00
9
CB
MT 202 / 298
PM
dedicated
liquidity
6.00 - 6.30
10
ASs
PM
12
11
Settlement day (S) before start of payment business
Step
Description
9
If the AS needs more dedicated liquidity during the night processing,
transactions to be credited to the participant by the AS (eg coupons and
redemption of securities) and auto collateralisation transactions can be used.
To increase the dedicated liquidity in the morning the CB concerned has to
submit an MT 202/298 with an appropriate amount.
10
ASs transfer amounts actually used.
11
Settlement positions are posted (debit and credit) and blocked liquidity (on the
sub-account) is released.
12
ASs get positive acknowledgements, that settlement and release of blocked
liquidity have been completed successfully.
Version 1.13
107
5
Ancillary system settlement
5.2 Work flow of generic settlement procedures
5.2.6 Dedicated liquidity
Daylight batch
The processing of a daylight batch is comparable with a night batch. The
main differences between daylight and night batches are:
• Reservation of funds, release, and settlement take place on the same
settlement day (S).
• Daylight batches can run repeatedly without limitation during operating
hours.
Version 1.13
108
6
Information and Control Module (ICM)
6.1
Business approach ICM
Basics
6
Information and Controle Module (ICM)
6.1
Business approach ICM
The Information and Control Module (ICM) will equip SSP participants (credit institutions, market infrastructures, other participants and CBs) with comprehensive online information tools and easy-to-use control measures
appropriate to their different business needs.
Specifically, the ICM will offer the different groups of participants "single window access" to the
• Payments Module (PM)
and depending on whether the CB in question decides to use the optional
services available in the SSP, participants will also have access via ICM to
the
• Home Accounting Module (HAM)
• Reserve Management
• Standing Facilities
In general, each CB/participant has to ask for information to be supplied
(pull technology). This gives each user the flexibility to decide what information should be updated at what time. Information is displayed automatically
in pop-up windows (push technology) only in exceptional circumstances (eg
system broadcasts from an CB, warnings concerning timed payments).
Version 1.13
109
6
Information and Control Module (ICM)
6.1
Business approach ICM
ICM access modes
There are two different technical modes for using ICM.
• Application-to-application mode
Information and messages will be transferred between the SSP and the
individual participant's internal application. Therefore, the participant
must
– develop his own application,
– adapt an existing application or
– purchase an appropriate solution
in order to exchange XML messages (requests and responses) with ICM
via a standardised interface.
• User-to-application mode
The objective is to permit direct communication between a participant's
users and ICM. The information is displayed in a browser running on a
PC system (SWIFT Alliance WebStation). Consequently, participants do
not need to develop a special application.
Version 1.13
110
6
Information and Control Module (ICM)
6.1
Business approach ICM
Home
Accounting
Data
Module Warehouse
participants
SSP
Payments
Module
XML
...
ICM
server
SWIFTNet
InterAct/
FileAct
HTML
(XML)
SWIFTNet
InterAct/
Browse/
(FileAct)
HOST
Adapter
ICM
Client
ICM
Client
back office
Application-to-application
mode
SWIFT Alliance WebStation
User-to-application
mode
Both modes will offer the same range of functionality.
Communication
network and
services
SWIFT's Secure IP Network (SIPN) will be the underlying technical communication network used to exchange information and to run control measures.
The following SWIFTNet services will be used for the different ICM access
modes.
Application-to-application mode
• SWIFTNet InterAct
• SWIFTNet FileAct
Version 1.13
User-to-application mode
• SWIFTNet InterAct
• SWIFTNet Browse
• (SWIFTNet FileAct)
111
6
Information and Control Module (ICM)
6.1
Business approach ICM
Security aspects
ICM can be used to initiate sensitive interventions by the different user
groups. ICM must therefore guarantee an appropriate level of security.
This will be achieved by:
• the use of security features provided by SWIFT as part of the SWIFTNet
services.
• defining different roles for the users in each group of participants (credit
institutions, market infrastructures, other participants and CBs).
• offering the "four eyes" principle as an option. Each participant can
decide to which of the roles available to his users the "four eyes" principle will have to apply. For security reasons, the "four eyes" principle
might be made compulsory for some activities (eg setting up backup
payments).
User
administration
For the user administration the service “Role Based Access Control“
(RBAC) offered by SWIFT will be used.
Each participant is responsible for managing his users, meaning that he will
be responsible for:
• designating the users
• assigning specific roles to each user
Note: The user detailed functional specifications will contain further details
about user administration.
ICM screens
It is foreseen to offer screens only in English.
Since the functionality of the SSP should be geared to participants' needs, it
is envisaged to consult a group of experts on the design of the screens.
Version 1.13
112
6
Information and Control Module (ICM)
6.2
Information and control measures in the ICM
6.2
Information and control measures in the ICM
Basics
Access to the Payments Module via ICM will be mandatory for all direct participants in the Payments Module (PM). This functionality will not be available to indirect PM participants.
Functions
available in ICM
Note: The following non-exhaustive list gives an overview of the different
functions available in ICM:
Business case
Managing the
payment queue
Functions
• View payments delivered for the current business day
•
•
Liquidity
management
• View the current liquidity position
•
•
Version 1.13
– All payments
– Subset of the payments according to criteria defined or loaded by the user
View payments delivered in advance
– All payments
– Subset of the payments according to criteria defined or loaded by the user
Queue management
– Revoking a non-final payment
– Changing the payment type from normal to urgent and vice
versa
– Moving a payment to the top or the end of the queue
– Changing the time of timed payments (Latest Debit Time
indicator, Earliest Debit Time indicator)
– in RTGS account/group of accounts
– in HAM
If the CB opts to continue using its local accounting system,
it is up to the CB to decide whether the ICM interface will be
supported.
Liquidity management
– Transfer liquidity between the RTGS account and the home
account
– Dedicated separation of liquidity for ancillary systems (AS)
– Reservation of liquidity to support the night-time process of
AS
Management of standing orders from the home account to the
RTGS account
113
6
Information and Control Module (ICM)
6.2
Information and control measures in the ICM
Business case
Management of
reservation and
limits
Functions
• Management of the current/default limits for the current busi-
•
Information
management
• View the system broadcasts sent by the CBs during a business
day
• View the system status
•
•
Emergency tool
ness day
– Highly urgent reserves
– Urgent reserves
– Bilateral limits
– Multilateral limits
Management of the current/default limits for the next business
days
– Highly urgent reserves
– Urgent reserves
– Bilateral limits
– Multilateral limits
– Availability of the other RTGS systems linked to TARGET2
(Note: Only during the migration)
– Cut-off times in the PM
– Status of ancillary systems
Access to directory services
– View the TARGET2 directory
– Download the TARGET2 directory
Download of statistical data on the basis of predefined queries
Creating backup payments in favour of
• PM participants
• CLS
• EURO1
Note: Historical data will be provided out of the Data Warehouse.
Version 1.13
114
7
Functional assumptions and service level requirements
7
Project goals
Functional assumptions and service level
requirements
TARGET2 aims to significantly increase performance, resilience and capacity processing, compared to the present situation.
The most important project goals are:
• processing times: 95% of the payments within 5 minutes and the remaining ones within 15 minutes
• availability rate higher than 99.7%
• maximum delay in the case of a major failure is 2 hours
• short interruptions (1 hour): max 6 times a year
In addition to the above mentioned general requirements for the design of
the system architecture and for the budget estimation the definition of
others critical parameters is needed.
Summary of the
functional
assumptions
In the following table a tentative list of these parameters is reported:
Requirements
TARGET1
TARGET2
Remarks
Average number of
payments per day
250,000
380,000
HAM traffic included
Peak number of
payments per day
380,000
500,000
HAM traffic included
Peak number of
payments per hour
n. a.
105,000
-
Estimated yearly
growth
n. a.
5%
-
Number of banks
(direct participant)
1,000
1,000
-
Version 1.13
115
7
Functional assumptions and service level requirements
Requirements
TARGET1
TARGET2
Remarks
Operational hours
7.00 - 18.00 hours
7.00 - 18.00 hours
The platform will
also be open for:
• overnight cycles between
5.00 and 7.00
• end-of-day activities between
18.00 and 22.00
Processing time
max. 30 min
(only cross-border)
max. 5 min - 95 %
Processing time:
max. 15 min - 100 % difference between
receiving time of
MT 096 and sending time of MT
097; Payments
queued for lack of
liquidity are excluded; Organisational measures will
be implemented
(e.g. early opening)
in order to manage
peak workload at
the start of the day
Availability
>99.4 %
> 99.7 %
Allowed unavailability (yearly total):
T1 = 16 h
T2 = 8 h
(daily business operating hours = 11 h)
Maximum number
of short term interruptions per year
12
6
-
Recovery time
(intra-region)
2h
< 1h
-
Recovery time
(inter region)
n. a.
2h
-
Note: Once the methodology of the availability requirements is defined, the
project objectives will be elaborated further.
Version 1.13
116
7
Functional assumptions and service level requirements
TARGET2 SLA
The TARGET2 service level agreement will define the level of performance
and availability provided to the TARGET2 users which the Eurosystem is
aiming at. In order to verify whether this level of service has been reached
in a specific period, the processing time and the technical and business
availability will be used as indicators.
The scope of the failures and interruptions included in the TARGET availability reporting will cover all payments.
In TARGET2, like in the present system, no claims for compensation can be
requested in the event of failure in achieving one or more of the objectives
stated in the SLA. This also allows that these objectives can stick closer to
reality, as they will apply under normal circumstances only and will not have
to cover some exceptional situations.
The recently adopted TARGET non-liability based compensation regime,
establishing rules for the financial compensation of participants in the event
of a malfunctioning of the system should also apply in TARGET2.
Version 1.13
117
8
SSP infrastructure and availability measures
8.1 SSP infrastructure
8.1.1 General architecture
Overview
8
SSP infrastructure and availability measures
8.1
SSP infrastructure
8.1.1
General architecture
The SSP will be based on a centralised architecture, with a high level of
redundancy, with the following main components:
• a central processing system (mainframe), for payment and accounting
services
• Unix servers for SSP Data Warehouse
• a secure wide area network to connect credit institutions, Market Infrastructures and central banks (SWIFTNet)
• a dedicated network to connect the different processing sites
• system and application software
• security systems (firewall,etc.)
Environments
The SSP needs multiple independent processing environments to support
development, test & training and live operations. The number of environments fits the application development life cycle. A customer test environment should always have the same software configuration of the live
environment.
To ensure the maximum availability of these environments, IT resources will
be dedicated to the SSP (ie storage, processing power, etc.) without any
dependencies on other resources or service not belonging to the SSP.
As the SSP will concentrate workload coming from the current distributed
TARGET system, the infrastructure will guarantee high performance and
adequate throughput thanks to a fully scalable architecture. In fact each
component mentioned above can increase its capacity in a modular way.
Version 1.13
118
8
SSP infrastructure and availability measures
8.1 SSP infrastructure
8.1.1 General architecture
Technical
operation
The SSP technical operation will be based on an high degree of automation
to reduce human operator errors and simplify the manageability of the infrastructure. In addition SSP will have a good level of controllability and audibility (confidentiality, integrity, identification/authentication and access rights
permission).
Rotation
The mainframe based operations will be running alternatively in two different regions. In each region two sites will be operative: the primary site and
the secondary or recovery site.
It should be noted that the SSP offers a single interface to its users, ie they
do not recognise in which Region a certain module is running.
Moreover, rotation is fully invisible for CBs, users and market infrastructures, ie no configuration changes in SSP users systems are envisaged.
Workload is distributed between the two regions: while Region 1 will host
the live environment, Region 2 will manage the test & training environments
and the contingency environment. Periodical swaps between the two regions ("rotation") will keep technical and operational staffs always skilled in
each region.
The system and the application software will be kept updated in the two
regions by means of hardware feature (asynchronous remote copy), so that
after the rotation the system will restart with the same customisation (i.e.
naming convention, security policies, management rules, etc.).
Version 1.13
119
8
SSP infrastructure and availability measures
8.1 SSP infrastructure
8.1.1 General architecture
The Data Warehouse as supportive element for the SSP, eg to produce statistical information (see chapter 2.5 Scope and framework of TARGET2),
will run in a third region.
The three regions will be connected by a dedicated network with adequate
bandwidth that will guarantee file transfer services and remote copy of data
from one region to the other.
SSP ARCHITECTURE
Dedicated network
SSP Data Warehouse
Region 3
Remote Access
Remote Access
File transfer
File transfer
Remote Access
Region 1
File transfer
Region 2
SSP payments and accounting services
Security
The SSP will be fully compliant with the TARGET Security Requirements
and Controls (TSRC) established at the Eurosystem level. In particular
security will be managed at the host and network interface level.
Version 1.13
120
8
SSP infrastructure and availability measures
8.1 SSP infrastructure
8.1.2 The SWIFT Interface
The SSP perimeter defence is built by using network firewall systems to filter the communication and log the network access. To protect the SSP
against intrusions and attacks coming from both internal and external people, it is under consideration the implementation of an integrated multi-platform security solution composed of network sensors and system probes
and a centralised system of alarm management (Intrusion Detection System - IDS). The centralised focal point is designated to receive alerts originated by security agents mentioned above.
8.1.2
Overview
The SWIFT Interface
The SWIFT Interface includes the SWIFTNet network and the hardware
and software front-end infrastructures acceding SWIFT services.
SWIFTNet is a TCP/IP network with the following characteristics:
• high performance and availability
• high security (at the transport level (VPN) and session level)
• Public Key Infrastructure and certificates management for user identification and strong authentication
• data confidentiality (by means of cryptography)
• store/forward services required to retrieve eventually lost messages
• scalability
For the payments information exchange, the SSP will use the SWIFTNet
FIN service as the current TARGET system. For the information and control
services, the SSP will use the SWIFTNet services (‘InterAct‘, ‘Browse‘ and
‘FileAct‘), expected to become standard in world-wide financial markets.
Version 1.13
121
8
SSP infrastructure and availability measures
8.2
Business continuity
8.2
Overview
Business continuity
Business continuity paradigm has influenced the SSP infrastructure design
greatly. This is particularly the result of the lessons learned from the tragic
events of 11 September 2001. In particular, the SSP will be able to perform
tasks under abnormal circumstances and manage the failures that require
on-site recovery, alternate site recovery, and alternate region recovery.
Also the TARGET users have strongly requested the enhancement of the
availability measures, proposing three major areas of intervention: - availability, back-up capabilities and contingency processing - in which the performances of TARGET have to be improved compared to the current
situation.
The requirements for service continuity, performance, availability, resilience
and security of the SSP will be higher compared to those of the current distributed systems since a service interruption would affect a large number of
users and Institutions.
TSRC
As stated in the new TARGET Security Requirements and Controls (TSRC),
business continuity measures foreseen in the SSP will ensure that:
• critical payments (as commonly defined by the ad hoc TMWG/TWG subgroup) are processed within 30 minutes and all other payments are processed with 'the same value date
• the operational day ends with a maximum delay of 2 hours
• the sites have different risk profiles
• the secondary region has to re-start within two hours (without considering the decision-making time the duration of which will be defined at a
later stage)
As a result, the infrastructure of the SSP will be based on cutting-edge technology for business continuity measures. In any case, the SSP will be able
to process the abnormal peak workload due to a temporary stop without
delay.
Version 1.13
122
8
SSP infrastructure and availability measures
8.2
Business continuity
As regards to "logical" disaster due to cyber attacks (viruses infection,
denial of services, etc.), the SSP approach is based on incident prevention
and management. This will be addressed by technical (firewall, IDS) and
organizational measures (security policies).
The resumption of critical activities in the aftermath of a disaster may be
hampered by the unavailability of key staff; therefore adequately skilled staff
must be available in all circumstances.
Recovery
classification
In terms of recovery classification, three types of interruption are defined:
Type
Explanation
Short continuity
failure
short service interruption (eg generally the cause may be component failures, a system reboot, or a line failure; these problems may typically be solved at the primary site). According
to the new TSRC, the maximum acceptable occurrence of
short failures is one hour six times a year. In order to bridge
this time, very critical payments have to be processed via contingency measures within 30 minutes upon arrival.
Major failure or
disaster
a serious service interruption (eg disruptions caused by fire,
flood, terrorist attack or major hardware/telecommunication
faults). Those events require the activation of an alternative
site.
Regional disaster a "wide scale regional disruption" that causes severe permanent interruption of transportation, telecommunication, power
or other critical infrastructure components across a metropolitan or a geographical area and its adjacent communities that
are economically integrated with it; or that results in a widescale evacuation or inaccessibility of the population within the
normal commuting range of the disruption's origin.
The business continuity model proposed for the SSP payments and
accounting processing services should be able to face short continuity failure, major failure and regional disaster.
Version 1.13
123
8
SSP infrastructure and availability measures
8.2
Business continuity
Recovery of the
central processing
system
The proposed model for the central processing system is based on two
regions/four sites (two sites for each region):
BUSINESS CONTINUITY
Model for the central processing system
REGION 1
Live Region Rotation Test & Training
(T&T)
Periodic
SITE A
P
Synchronous remote copy
Hot back-up
Intra-region
recovery
SITE B
Asynchronous
P
SITE C
Synchronous remote copy
remote
copy
S
REGION 2
S
SITE D
Hot back-up
In each region the two sites are located at a distance of some kilometres
and connected by means of fibre optical channel. The two sites are fully
equivalent; the same technological resources are installed in each centre:
ie CPU, storage, network interface, software, etc.; differences could be
acceptable in the basic logistic like UPS, air conditioning, plants, etc. The
recovery within a region is assured by synchronous remote copy (SRC)
activated on the whole SSP environment between the two sites of the same
region. The SRC guarantees real-time data updates in both sites; it means
that each write operation is completed only when both sites are updated1.
Intra-regional recovery can last at the most 1 hour (without taking into
account decision-making time) with no loss of data updates.
1. Performances are delayed due to data transmission and remote updates.
Version 1.13
124
8
SSP infrastructure and availability measures
8.2
Business continuity
During normal operation, SSP live environment is running in one site, while
the other site is in hot stand-by mode. To guarantee the hardware functionality, saving cost and speed up the recovery restart phase, the secondary site
could normally be used for other activities of the technical operator. Furthermore at the secondary site backup locations for the staff will be available.
Besides, it will be possible to operate in both SSP sites on a remote basis.
Inter-region
recovery
Recovery of a regional disaster is based on region sites located at long distances from each other (hundreds of kilometres) having a different risk profile. As in the intra-region recovery, the sites of the two regions must be fully
equivalent, but differences in logistics could be acceptable. In particular
recovery of activities and processes during a wide-scale regional disruption
calls for the establishment of out-of-region arrangements for operations and
the related personnel and necessary data to support such an activity. The
objective of establishing out-of-region arrangements is to minimise the risk
that primary and secondary sites and their respective labour pools could be
impaired by an individual wide-scale regional disruption. Out-of-region sites
should not be dependent on the same labour pool or infrastructure components used by the primary region and should not be affected by a wide-scale
evacuation or the inaccessibility of the region's population. As consequence, it could be necessary to operate from the second region for quite a
long time, therefore a high level of system availability should be guaranteed
in the second region too.
Asynchronous
remote copy
Due to the long distance, the recovery from one region to the other is possible only by asynchronous remote copy (ARC), activated on the whole
SSP environment. The ARC cannot guarantee real-time data updates in
both regions, as each write operation can be completed in the active region
while the same update is still in progress within the other region, therefore,
at the same time, data in the two regions may be not identical.
As write operations in the remote region are asynchronous, it is possible
that some data updates are lost in the remote region if a regional disaster
occurs. The amount of lost updating data depends on the network bandwidth, the workload and the disk technology used. In order to restart the
service, with consistent and updated data, adequate procedures to retrieve
and process missing messages from SWIFT are available.
Version 1.13
125
8
SSP infrastructure and availability measures
8.2
Business continuity
Staffing
The availability of skilled personnel with technical and operational background is mandatory. In order to face regional disaster recovery, it is necessary to have adequately trained staff located at both regions to meet
recovery objectives. Periodical live environment exchanges between the
two regions (eg every six months) are necessary to maintain skilled personnel in both regions (region rotation). This is a powerful way to guarantee the
alignment between infrastructures of both regions and to maintain skilled
and prepared staff in each region. Considering the operational risks associated with the region rotation, the organisational and procedural arrangements of the rotation process will be investigated in-depth.
Recovery of Data
Warehouse
The Data Warehouse as supportive element of the SSP is less time-critical
than the other SSP components, business continuity model should be able
to face short continuity failure and major failure; so it will be based only on
intra-region recovery; this procedure will use a daily batch data transfer
from primary to secondary site. In the case of a regional disaster that will
cause an unavailability of the Data Warehouse, the time-critical components of SSP will be able to operate fully without them.
Test
Periodic tests will be planned to verify the accuracy of recovery procedures.
Testing of internal systems alone is no longer sufficient. It is also mandatory
to test back-up facilities with respect to markets, core clearing and settlement organisations and service providers with a view to ensuring connectivity, capacity and integrity of the whole system.
Version 1.13
126
8
SSP infrastructure and availability measures
8.3
Contingency measures
8.3
Overview
Contingency measures
The recovery procedures set up in the SSP are based on the experience of
the Eurosystem’s central banks in managing their own systems.
The SSP is built on the principle of "no single point of failure", ie the multiplication of technological components to guarantee business continuity even
in case of a major disaster like the events of 11 September 2001 (two region
four sites approach).
The general principle is: the priority is "business continuity" rather than
"contingency".
The idea is to keep service interruptions shorter than the time needed to
activate contingency measures, limiting in this way the need to resort to
them. The SSP thus elects to take business continuity functions as its main
solution to system malfunctioning.
Nevertheless, SSP developed contingency procedures since:
• The redundancy of technological components may not always be the
solution, as in the case of software problems, which could also occur in
the alternate site (or the alternate region).
• They are needed to cover the time required for the activation of the alternate site (or the alternate region) in order to process systemically important payments (like CLS payments).
Scenarios
The different scenarios have to cope with the unavailability of:
•
•
•
•
a credit institution system
an ancillary system
one or more CBs
the whole SSP
In each scenario different sub-scenarios can be considered. For each of
them as a first step standard measures can be activated and only as
second step (if standard measures are not available or not sufficient) contingency procedure have to be used.
Version 1.13
127
8
SSP infrastructure and availability measures
8.3
Contingency measures
Unavailability of a
credit institution
The system of a direct PM participant could break down due to a failure and
could be unavailable for the rest of the business day.
As a consequence, the participant could accumulate liquidity on its RTGS
account due to the fact that other SSP participants continue to send him
payments while the participant fails to comply with its payment obligations.
The direct PM participant should be able to settle, at least, systemically
important payments in order to:
• distribute the liquidity accumulated on its account
• minimise interest payments due and claims for damages against the
other participants
In this scenario two different sub-scenarios are possible:
• a breakdown of the PM participant's system
• a failure in the SWIFNet connection
As a first step, the following measures can be activated in the two sub-scenarios:
• a backup system in case of a breakdown (in line with the business
continuity requirements for major players)
• a multiple access to SWIFTNet in case of a failure in the SWIFTNet connection
As regards the contingency measures:
• in case of a breakdown, the possibility for the participant to use the
backup payments function through the Information and Control Module
(SWIFTNet browse) has been envisaged
• in case of a failure in the SWIFTNet connection the participant can ask
the respective CB, according to the national practices, to input systemic
important payments on its behalf using the backup payments functions
on the SSP.
Furthermore, the co-operation among credit institutions (mutual backup
with another participant) is encouraged.
Version 1.13
128
8
SSP infrastructure and availability measures
8.3
Contingency measures
Unavailability of
an ancillary
system
For the ancillary systems the same sub-scenarios foreseen for credit institutions are envisaged (system breakdown, failure in SWIFNet connection).
The measures to be activated are also the same (backup system, multiple
access to SWIFTNet).
As regards the contingency measures, bilateral agreements between the
ancillary system and the involved CBs have to be reached (eg between
ECB and CLS and between ECB and EBA) according to a set of standard
procedures to be defined.
Furthermore, special agreements should be reached for the ancillary system settling in more than one jurisdiction.
Unavailability of
one or more CBs
The unavailability of an CB has to be considered in relation to the different
roles played:
• as a normal participant
• as a liquidity provider
In both cases, manual functions are available in the ICM in order to:
• input the CB critical payments
• provide the liquidity needed for the smooth functioning of the system
Should the access to the ICM be unavailable, all the above mentioned
transactions (payments and liquidity injection) can be input by the SSP operational team on behalf of the affected CBs.
In case of SWIFT unavailability at country level, the first option is to activate
SWIFT alternative links, according to the arrangements established at national level.
If this solution is not possible the contingency solution envisages the
manual input (through the ICM) of systemically important payments by the
SSP operational team on behalf of the affected CBs.
Unavailability of
the whole SSP
Also the unavailability of the whole SSP envisages two different sub-scenarios:
• Unavailability of the central component of the SSP
• General unavailability of SWIFT
Version 1.13
129
8
SSP infrastructure and availability measures
8.3
Contingency measures
In case of unavailability of the central component of the SSP (the SSP is not
running and there is no visibility of the account balances), the business
continuity approach adopted within the SSP envisage the activation of the
alternate site (intra-region recovery) or of the alternate region (inter-region
recovery).
During the time needed for the activation of the alternate site/region the
Contingency Module (CM) can be used in order to settle systemically important payments with "external" impact (eg CLS, EURO1).
It is important to underline that only in this scenario - when the whole European banking community is not able to settle payments in TARGET2 - the
use of the Contingency Module is envisaged.
In case of general unavailability of SWIFT, the potential impact goes beyond the scope of the contingency solution that can be provided by the SSP.
Appropriate communications channels will be established with SWIFT, in
order to follow the resumption activities and to inform the SSP participants
accordingly.
The Contingency
Module (CM):
Overview
The Contingency Module (CM) is a common mandatory tool for all the CBs
joining the SSP and it is operated at CB level.
The basic point is that considering the high level of business continuity the
CM will be kept as simple as possible.
The Contingency Module runs in the region not active when the incident
occurs. The CM is an independent module which includes all the functions
needed to access the SWIFTNet services.
Version 1.13
130
8
SSP infrastructure and availability measures
8.3
Contingency measures
The CM is only activated in case of problems of the PM module.
Normally, only a limited number of systemically important payments are
settled in the CM (eg CLS, EURO1…). In case of prolonged outage, considering the need to process a larger number of critical payments, the
recourse to payment bulking is envisaged.
The Contingency
Module (CM): Main
Features
The main features of the Contingency Module are:
• The presence of separate accounts in the CM (outside the SSP) (static
data are updated every day from repository) in order to avoid time-consuming procedures in the acquisition by the PM of the transactions settled in contingency mode
• No liquidity transfers from the PM to the CM are envisaged as it is difficult to guarantee the validity of balances. Furthermore, the restart of the
PM on the secondary/alternate site would be delayed
• Starting balances are equal to zero; fresh liquidity is injected in the CM
accounts by the CBs using repo operations via a transaction using
SWIFTNet Browse/InterAct
• The CBs are responsible for selecting, receiving and inserting in the CM
the systemically important payments via a transaction using SWIFTNet
Browse/InterAct
• Payment instructions are received by the CBs using local procedures
(fax, national networks, branches,…)
• After the restart of the PM the amount of the balances of the payments
settled in the CM's accounts are automatically sent to the PM
• Information on the current balances and transaction status is available to
the CBs using SWIFTNet Browse/InterAct; it is up to the CBs to inform
CIs after the restart of the PM services, that the balances of the CM's
accounts are booked in the PM
Version 1.13
131
8
SSP infrastructure and availability measures
8.3
Contingency measures
Contingency Module
CI
Instructions
(according to local
rules)
CM
CB
Liquidity injection
Payments
Static data
Automatic settlement of
balances at the end of the
outage
Collateral
PM
CSD
The CM is operated by each CBs for its own credit institutions; under
exceptional circumstances the CM can be operated by the SSP operational
team.
Accounts of CM are normally blocked and it is not possible to settle any
transactions. The CM is activated by the SSP operational team on request
of the TARGET2 co-ordinator.
Version 1.13
132
8
SSP infrastructure and availability measures
8.3
Contingency measures
Contingency
procedures
summary
Unavailability of a credit institution
Event
Standard measures
Contingency measures
System breakdown
Activation of backup systems
Mutual backup
Backup payments function
through ICM (SWIFTNet
Browse)
No access to SWIFTNet
Multiple access
Mutual backup
Backup payments function
through the respective CB
(SWIFTNet Browse)
Unavailability of an ancillary system
Event
Standard measures
Contingency measures
System breakdown
Activation of backup systems
Special agreements have to
be reached
No access to SWIFTNet
Multiple access
Special agreements have to
be reached
Unavailability of SWIFT at country level
Event
Standard measures
Contingency measures
Unavailability of SWIFT at
country level
Redundant network, activation of SWIFT alternative
links
Manual input of systemically important payments by
the SSP operational team
on behalf of the affected
CBs
Unavailability of the whole SSP
Event
Standard measures
Contingency measures
General unavailability of
SWIFT
Redundant network
None
Unavailability of the central component of the SSP
Activation of alternative
sites (intra-region or interregion)
Use of the contingency
module
Version 1.13
133
9
Operational model
9.1
Operating times
Operating times
9
Operational model
9.1
Operating times
The SSP complies with the general rules defined at the Eurosystem level
for the TARGET calendar and operating times.
All the cut-off times are defined in the system as parameters, in order to
cope with abnormal situations and future changes in the business environment.
The exact rules for handling such situations should, however, be defined
when the detailed operational framework for TARGET2 is set up.
The chart below describes the major stages of the business day in the SSP:
A day in the SSP
D+1
18.00
7.00
Submission of
- customer payments (until 17.00)
- bank-to-bank payments (until 18.00)
increase of
reserved
liquidity by
CBs (if
necessary)
Settlement
O/N
processing
SSS
Other ancillary systems
E-o-d
Group of
accounts
E-o-d
processing
intra CB
processing
reservation
O/N
processing
SSS
technical
maintenance
CB operations
Liquidity
withdrawal
(if applicable)
Liquidity
injection (if
applicable)
Update of
credit limits
Version 1.13
Information
on balances
use of
deposit facility
lending facility
134
9
Operational model
9.1
Operating times
A business day
Time
Action
Before the opening
of the business day
• If necessary, increase of dedicated liquidity on sub-accounts
by CBs (using MT 202)
• Settlement of overnight transactions; release of blocked
funds for the overnight process
• Injection of liquidity for those CBs which use their home
accounting system for maintaining liquidity overnight
• Updating of credit lines (in order to have them available at
7.00 hours)
7.00 hours
Opening the business day
17.00 hours
Cut-off for customer payments
It is assumed that most of the ancillary systems have settled
before the cut-off for customer payments.
Specific types of transactions stemming from AS (money market,
DVP, etc.) can be settled via ASI till 18:00 hours.
18.00 hours
Cut-off for interbank payments
After the system
closes for operations
• Automatic end-of-day procedures for the groups of accounts
•
•
•
•
Overnight
Version 1.13
(liquidity transfers between accounts belonging to the same
group)
Automatic settlement of bilateral balances between CBs
(interlinking, intra-PM)
Delivery of relevant data for end-of-day processing at CB
level
Standing facilities window
Reservation for the overnight processing of ancillary systems. This reservation is made parallel to the end-of-day processing at CB level (implies that amounts transferred to the
deposit facility are not available for the overnight processing).
Technical maintenance
135
9
Operational model
9.2
Customer contacts
9.2
Appointment of
duties within the
TARGET2
environment
Customer contacts
Smooth and stable operations require efficient technology as well as swift
and effective communication between the parties involved.
The following diagram shows the communication relationships within the
TARGET2 environment:
TARGET
COORDINATION
OPERATIONAL
TEAMS
SSP
CBs
TECHNICAL
TEAMS
CBs
TARGET2
External
parties
CREDIT
INSTITUTIONS
ANCILLARY
SYSTEMS
CREDIT
INSTITUTIONS
ANCILLARY
SYSTEMS
Term
Explanation
CBs operational team
Entry points for the SSP users
SSP operational and technical teams
CBs second level of support regarding
day-to-day operation
TARGET co-ordination
General co-ordination
Version 1.13
136
9
Operational model
9.2
Customer contacts
Contact through
the TARGET2
participants
The CBs are responsible for the Customer Relationship Management as
well as day-to-day operations.
The most important duties are:
•
•
•
•
•
•
•
•
•
Help desk functions
Management of the emergency procedures
Basic questions
Contacts with users
Follow-up consultation
Test co-ordination
Training co-ordination
Application procedures
National documentation
In the Information and Control Module, a function to view the broadcasts
sent by the CBs during the business day is available.
TARGET status
information
The TARGET status information function provides the users with information on whether TARGET is fully functioning. If this is not the case it is indicated, which component is facing what type of service disruption and the
expected time to resume normal operations.
For availability purposes, TARGET status information is spread to the participants via different channels in a synchronised way:
• ICM
• dedicated information page on the ECB web site
• wire service such as Reuters
Adequate backup and manual contingency procedures ensure that information can be disseminated at all times.
Version 1.13
137
10 Migration issues
10
Migration issues
Content
This section details the various aspects of participants' migration to SSP
(credit institutions and ancillary systems).
Migration scenario
The changeover to SSP can only take place as a country big bang. It
means: a CB, the future direct participants of the country in question and
the ancillary systems that wish to settle in the SSP from the outset must
switch to the SSP at the same time.
Responsabilities
of the central
banks
Each individual CB is responsible for supporting and monitoring the migration of its customers. CBs will be supported by projected related bodies as
far as possible.
Pilot group and
country window
In order to minimise the risk involved in the project, only a limited number of
CBs and their customers may switch to the SSP on 2 January 2007. In such
an approach a pilot group will be set up in collaboration with CBs by the end
of 2004. The "pilots" (CBs, credit institutions, ancillary systems) will be subject to more rigourous requirements (timeframe, initial migration).
Country windows will be defined for the migration of the remaining CBs
(and their customers). Following a three-month stabilisation phase, further
country windows will be planned for 2007. Migration in a later country window gives all involved participants more time to make the necessary adjustments. If further country windows are required in 2008, they will be coordinated and agreed with the Eurosystem’s co-ordination body.
Structure of
migration phase
The migration phase consists of the following stages
•
•
•
•
Information phase (June - December 2004)
Preparation phase (2005)
Test and pre-production phase (2006)
Go live (2 January 2007)
The dates in brackets refer to the schedule for the pilot group.
Version 1.13
138
10 Migration issues
The information phase will serve to convey the necessary detailed information from the various documents. In the subsequent preparation phase,
each participant will have to build up and adjust its infrastructure as appropriate. Upon timely completion of the preparations, the test phase will begin
with various test scenarios in the (SSP) test environment. Once the tests
have been successfully carried out, there will be another test and preparation phase (for the pilots) in the new production environment. When this
phase has also been successfully completed, a date will be set for the
launch, provisionally at the beginning of 2007.
Each individual central bank is responsible for ensuring that the individual
phases are completed on time.
Preparatory work
To ease the time pressure of the tight migration schedule, the future participants should deal with the following issues before the end of 2004:
• Setting up of the necessary project organisation
• Deciding on the type of participation in SSP (direct or indirect)
• Identification of the in-house infrastructures and applications that will
need adjustment
• Carrying out a matching check with other projects that are either planned
or under way.
• Inclusion in the 2005 budget plan
• If not already available, acquisition of a comprehensive SWIFTNet knowledge base in the SWIFTNet Services Browse, InterAct and FileAct as
well as in SWIFTNet FIN in Y-copy mode
Further details will be provided by the relevant central bank during the information phase.
Version 1.13
139
Glossary and Abbreviations
A
Glossary and Abbreviations
3G
Banca d’Italia, Banque de France, Deutsche Bundesbank
AA
ACH
See Automated Clearing House
Ancillary system
Ancillary systems are:
•
•
•
•
•
•
retail payment systems (RS)
large value payment systems (LVPS)
FX systems
money market systems
clearing houses
securities settlement systems (SSS)
Ancillary System
Interface
The Ancillary System Interface (ASI) is a standardised interface to the
Payments Module (PM) which can be used by ancillary systems (AS) to
perform the cash clearing of their business.
ARC
Asynchronous Remote Copy
AS
See ancillary system
ASI
See Ancillary System Interface
Version 1.13
I
Glossary and Abbreviations
B
AS Settlement
Agent
See Settlement Agent
Authentication
The methods used to verify the origin of a message or to verify the identity
of a participant connected to a system and to confirm that a message has
not been modified or replaced in transit.
Automated Clearing House
An electronic clearing system in which payment orders are exchanged
among financial institutions and handled by a data processing centre.
Available liquidity
Credit balance on the account plus credit line for overdraft (if available).
BB
Batch
The transmission or processing of a group of payment orders and/or securities transfer instructions as a set at discrete intervals of time.
BIC
Bank Identifier Code
BIC directory
Directory published by SWIFT. It contains the Bank Identifier Codes (BIC)
of the credit institutions.
BIS
Bank for International Settlements
Version 1.13
II
Glossary and Abbreviations
C
Business
continuity
Payment system's arrangements which aim to ensure that it meets agreed
service levels even if one or more components of the system fail or if it is
affected by an abnormal external event. Include both preventative measures and arrangements to deal with contingencies.
CC
Cash clearing
A method for clearing futures contracts in which positions are periodically
marked to market and resulting obligations are satisfied by cash payments,
known as variation margin.
Cash/liquidity
pooling
functionality
This function will be ensured in the SSP through the group of accounts
structure. A group of accounts consists of one or more account(s) held by a
direct PM participant(s) which has a capital and/or management link. Two
main variants are described in the GFS: consolidated information or virtual
account.
CB
Central bank
CCP
Central Counter Party
Central securities
depository
A facility (or an institution) for holding securities, which enables securities
transactions to be processed by book entry. Physical securities may be
immobilised by the depository or securities may be dematerialised (ie so
that they exist only as electronic records). In addition to safekeeping, a central securities depository may incorporate comparison, clearing and settlement functions.
CI
See credit institution
Version 1.13
III
Glossary and Abbreviations
C
Clearing
The process of transmitting, reconciling and, in some cases, confirming
payment orders or security transfer instructions prior to settlement, possibly
including the netting instructions and the establishment of final positions for
settlement. Sometimes the term is used (imprecisely) to include settlement.
Clearing house
A central location or central processing mechanism through which financial
institutions agree to exchange payment instructions or other financial obligations (eg securities). The institutions settle for items exchanged at a designated time based on the rules and procedures of the clearing house. In
some cases, the clearing house may assume significant counterparty,
financial or risk management responsibilities for the clearing system.
Client
A party that is not a member of the clearing house and must settle through a
clearing member. Also known as customer.
CLS
Continuous Linked Settlement
CM
Contingency module
Common mandatory tool for the CBs for the management of the emergency situations.
Collateral
An asset that is delivered by the collateral provider to secure an obligation
to the collateral taker. Collateral arrangements may take different legal
forms; collateral may be obtained using the method of title transfer (see
repurchase agreement) or pledge.
Version 1.13
IV
Glossary and Abbreviations
C
Collateral pool
Assets owned by members of a payment system that are collectively available to the systems collateral to enable it to obtain funds in circumstances
specified in its rules.
Confidentiality
The quality of being protected against unauthorised disclosure.
Credit institution
The definition given to a "bank" in the European Union. The First EC Banking Directive defines it as an undertaking whose business is to receive
deposits or other repayable funds from the public and to grant credits for its
own account.
Credit transfer
A payment order or possibly a sequence of payment orders made for the
purpose of placing funds at the disposal of the beneficiary. Both the
payment instructions and the funds described therein move from the bank
of the payer / originator to the bank of the beneficiary, possibly via several
others banks as intermediaries and/or more than one credit transfer system.
CRM
See Customer Relationship Management
Cross-CB
payments
Payment between participants of different CB on the SSP.
Cross-PM
payments
Payment between one participant of a CB on the SSP and another participant of an external CB which will migrate later on (use of the interlinking).
Version 1.13
V
Glossary and Abbreviations
D
CRSS
Customer Related Services System
The CRSS is one of the two technical configurations of the SSP (the other
is the PAPSS). On this technical configuration are implemented the Data
Warehouse and the Customer Relationship Management.
Cryptography
The application of mathematical theory to develop techniques and algorithms that can be applied to data to ensure goals such as confidentiality,
data integrity and/or authentication.
CSD
See central securities depository
CUG
Closed User Group
Customer
Entity which is not a participant (direct or indirect) and which uses the service of a participant to exchange transactions in the system. The NCBs as
participants can also have customers.
Customer
Relationship
Management
This optional module aims at managing customer-oriented information related to the participants outside the Information and Control Module. It is implemented on the CRSS.
DD
Dedicated liquidity
Liquidity held on a PM sub-account to allow the settlement of an ancillary
system.
Delivery
Final transfer of a security or financial instrument.
Version 1.13
VI
Glossary and Abbreviations
E
Delivery versus
payment
A link between a securities transfer system and a funds transfer system that
ensures that delivery occurs if, and only if, payment occurs.
Deposit facility
See overnight deposit
Depository
An agent with the primary role of recording securities either physically or
electronically and keeping records of the ownership of these securities.
Direct debit
Pre-authorised debit on the payer's bank account initiated by the payee.
Direct participant
A participant in an interbank funds transfer system (IFTS) who is responsible to the Settlement Agent (or to all other direct participants) for the settlement of its own payments, those of its customers and those of the indirect
participants on whose behalf it is settling.
DVP
See delivery versus payment
EE
EBA
European Banking Association
ECB
European Central Bank
ECSDA
European Central Securities Depository Association
EEA
European Economic Area
Version 1.13
VII
Glossary and Abbreviations
F
Encryption
The use of cryptographic algorithms to encode clear text data (plaintext)
into ciphertext to prevent unauthorised observation.
EPC
European Payments Council
FF
Final settlement
The discharge of an obligation by a transfer of funds and a transfer of securities that have become irrevocable and unconditional.
Firewall
A hardware- and/or software-based system that is used as an interface between the internet and a computer system to monitor and filter incoming and
outgoing communication.
GG
Gridlock
A situation that can arise in a funds or securities transfer system in which
the failure of some transfer instructions to be executed (because the necessary funds or securities balances are unavailable) prevents a substantial
number of other instructions from other participants from being executed.
Gross settlement
system
A transfer system in which the settlement of funds or securities transfer
instructions occurs individually (on an instruction by instruction basis).
Version 1.13
VIII
Glossary and Abbreviations
H
H
HAM
Home Accounting Module
The Home Accounting Module is a common standardised optional module
with basic functions.
Home account
Account hold by NCBs outside of the Payments Module. They can be opened
• for entities that cannot have the status of direct participant in PM
• for entities allowed to open PM accounts that are indirect PM participants
(or do not participate in PM neither as direct nor as indirect)
• for PM account holders for the settlement of operations which are not
processed in the Payments Module
The home accounts are managed by the HAM.
I I
ICM
Information and Control Module
It is the mandatory and unique functional interface between the direct participants and the Payments Module and the other optional modules like
•
•
•
•
Home Accounting
Reserve Management
Standing Facilities
Management of Static Data
Version 1.13
IX
Glossary and Abbreviations
I
Indirect participant
Indirect participants are distinguished from direct participant by their inability
to perform some of the system activities performed by direct participants, in
particular they do not hold RTGS accounts. Indirect participants require the
services of direct participants to perform those activities on their behalf
(settling the payments input to the transfer system).
Integrity
The quality of being protected against accidental or fraudulent alteration or
of indicating whether or not alteration has occurred.
Interlinking
Interlinking provides the common procedures and infrastructure which allow
payment orders between one domestic RTGS system and another domestic RTGS system or between one domestic RTGS system and the SSP
(during the migration period).
Intra-CB payment
Payment between participants of the same CB on the SSP.
Intra-day credit
Credit extended for a period of less than one business day; in a credit transfer system with end-of-day final settlement, intra-day credit is tacitly extended by a receiving institution if it accepts and acts on a payment order even
though it will not receive final funds until the end of the business day. It can
take the form of:
• a collateralised overdraft or
• a lending operation against a pledge or in a repurchase agreement
Intra-day liquidity
Funds which can be accessed during the business day, usually to enable
financial institutions to make payments in real-time.
Version 1.13
X
Glossary and Abbreviations
L
L
Local home
account
Account held by NCBs outside of the Payments Module. They can be opened
• for entities that cannot have the status of direct participants in PM
• for entities allowed to open PM account that are indirect PM participant
(or do not participate in PM neither as direct nor as indirect)
• for PM account holders for the settlement of operations which are not
processed in the Payments Module
The local home accounts are not implemented in the SSP but within every
NCB.
MM
Marginal lending
facility
A standing facility of the Eurosystem which counterparties may use to
receive overnight credit from an NCB at a pre-specified interest rate against
eligible assets.
In general possible options:
• Marginal lending "on request"
Use on request of the participant in general needed for the fulfillment of
reserve requirement.
• Automatic marginal lending
Automatic transformation of intra-day credit in overnight credit at the end
of the day.
MI
Market Infrastructure
Version 1.13
XI
Glossary and Abbreviations
N
N
Netting
An agreed offsetting of positions or obligations by trading partners or participants. The netting reduces large number of individual positions or obligations to a smaller number of obligations or positions. Netting may take
several forms which have varying degrees of legal enforceability in the
event of default of one of the parties.
Netting by novation
Netting by novation agreements provide for individual forward-value contractual commitments (eg foreign exchange contracts) to be discharged at
the time of their confirmation and replaced by new obligations forming part
of a single agreement. Amounts due under a discharged contract will be
added to running balances due between the parties in each currency at
each future value date.
OO
Offsetting
transactions
Specific algorithm activated each time a new payment is received by the
PM to settle a number of queued payments.
Overnight credit
See marginal lending facility
Overnight deposit
A standing facility of the Eurosystem which counterparties may use to make
overnight deposits at a NCB and which are remunerated at a pre-specified
interest rate.
Version 1.13
XII
Glossary and Abbreviations
P
P
Participant
A party who participates in a transfer system. This generic term refers to an
institution which is identified by a transfer system and is allowed to send
orders directly to the system or which is directly bound by the rules governing the transfer system. See also direct participant, indirect participant.
PAPSS
Payment and Accounting Processing Services Systems
One of the two technical configurations of the SSP (the other one is the
CRSS). The following modules of the SSP are implemented on the PAPSS:
•
•
•
•
•
•
•
Contingency Module
Home Accounting Module
Information and Control Module
Payments Module (including the interface for ancillary systems)
Reserve Management Module
Standing Facilities Module
Static data management
Payment message/
instruction
An order or message to transfer funds (in the form of a monetary claim on a
party) to the order of the beneficiary.
Payments Module
Mandatory module which allows the settlement of payments in the RTGS
account.
PHA
See proprietary home account
Version 1.13
XIII
Glossary and Abbreviations
Q
PKI
Public Key Infrastructure
PM
See Payments Module
Pre-pledged
(collateral) pool
Pool of collaterals which are pledged. See collateral.
Proprietary home
account
See local home account
QQ
Queuing
A risk management arrangement whereby transfer orders are held pending
by the originator/deliver or by the system until sufficient cover is available in
the originator's/deliverer's clearing account or under the limits set against
the payee; in some cases, cover may include unused credit lines or available collateral.
RR
RBAC
Role Based Access Control
Real-time gross
settlement
The continuous (real-time) settlement of funds or securities transfers individually on an order by order basis (without netting).
Repo
See repurchase agreement
Version 1.13
XIV
Glossary and Abbreviations
S
Repurchase
agreement
A contract to sell and subsequently repurchase securities at a specified
date and price.
Reserve holdings
Liquidity intra-day and overnight maintained on the RTGS account at the
end-of-day.
Reserve
requirement
The obligation for banks to maintain balances (bank reserves) at the central
bank in respect of certain types of liabilities (in some cases vault cash can
be counted towards this).
RTGS
See real-time gross settlement
RTGS account
Account held in the Payments Module
SS
Securities
settlement system
A system which permits the transfer of securities: either free of payment
(free delivery), for example in the case of pledge; or against payment. Settlement of cash occurs in an interbank funds transfer system through a Settlement Agent.
SEPA
Single Euro Payments Area
Settlement Agent
An institution that manages the settlement process (eg the determination of
settlement positions, monitoring of the exchange of payments, etc) for
transfer systems or other arrangements that require settlement.
Version 1.13
XV
Glossary and Abbreviations
S
Single Shared
Platform
Platform which includes the PAPSS (Payment and Accounting Processing
Services Systems) and the CRSS (Customer Related Services System).
SLA
Service Level Agreement
SRC
Synchronous Remote Copy
SSP
See Single Shared Platform
SSS
See securities settlement system
Standing facility
A central bank facility available to counterparties on their own initiative. The
Eurosystem offers two overnight standing facilities:
• the marginal lending facility and
• the deposit facility.
Standing order
Instruction of a direct participant to transfer regularly a fixed amount from
his home account to an RTGS account (PM).
Sub-account
Specific account holding dedicated liquidity to allow the settlement of an
ancillary system.
SWIFT
Society for Worldwide Interbank Financial Telecommunication
A SWIFT payment message is an instruction to transfer funds; the
exchange of funds (settlement) subsequently takes place over a payment
system or through correspondent banking relationships.
Version 1.13
XVI
Glossary and Abbreviations
T
T
TARGET
Trans-European Automated Real-time Gross settlement Express Transfer
TARGET2
TARGET2 is an Eurosystem project open to non-euro area CBs of the EU.
It is based on national components and one "shared component".
TARGET2
directory
Directory used by participants to find out where a payment has to be
addressed by SWIFTNet Y-Copy mode. On a domestic level, it could be
used to find the relation between the national sorting codes and the related
BICs.
Transfer
Operationally, the sending (or movement) of funds or securities or of a right
relating to funds or securities from one party to another party by
• conveyance of physical instruments/money,
• accounting entries on the books of a financial intermediary or
• accounting entries processed through a funds and/or securities transfer
system.
The act of transfer affects the legal rights of the transferor, transferee and
possibly third parties in relation to the money balance, security or other
financial instrument being transferred.
TSR
TARGET Security Requirements
TSRC
TARGET Security Requirements and Controls
TWG
TARGET Working Group
Version 1.13
XVII
Glossary and Abbreviations
U
U
User
All participants (direct and indirect).
W
W
WGT2
Working Group on TARGET2
Working Group supporting the Payment and Settlement Systems Committee (PSSC) in all TARGET2 related topics.
Version 1.13
XVIII