T2 UDFS Book 2 v11.01 20171030 PDF

Single Shared Platform
User Detailed Functional Specifications

- Optional Services -
2nd book
Version 11.01
30 October 2017
Table of Contents
Table of Contents
11 Introduction ............................................................... 1
12 User Guide for optional modules ............................ 5

12.1 User Guide for Home Accounting Module (HAM) ................. 5
12.1.1 Overview and functional architecture.......................................................... 5
12.1.2 Participation in HAM................................................................................... 9
12.1.3 Account management .............................................................................. 10
12.1.4 Transactions processing .......................................................................... 12
12.1.5 Cash reservation function......................................................................... 36
12.1.6 Queue management ................................................................................ 37
12.1.7 Operational day management .................................................................. 38
12.1.8 Interaction and reporting .......................................................................... 38
12.1.9 Administration .......................................................................................... 41
12.1.10 Exclusion of an HAM participant............................................................... 42
12.2 User Guide for Reserve Management (Module) (RM) .........43

12.2.1 General features ...................................................................................... 43
12.2.2 Interaction and reporting for credit institutions .......................................... 46
12.2.3 Administration tool for CBs ....................................................................... 47
12.3 User Guide for Standing Facilities (Module) (SF) ...............48

12.3.1 General features ...................................................................................... 48
12.3.2 Interaction ................................................................................................ 58
13 ICM User Handbook ................................................ 59
Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 ii

Table of Contents
13.1 Overview on ICM ................................................................... 59
14 Technical Specifications ........................................ 60

14.1 SWIFTNet FIN related issues ............................................... 60
14.1.1 SWIFTNet FIN - General aspects ............................................................ 60
14.1.1.1 Business Identifier Codes (BICs) for SSP ................................................ 60
14.1.1.2 Public Key Infrastructure (PKI) ................................................................. 64
14.1.1.3 SWIFTNet FIN messages ........................................................................ 66
14.1.1.3.1 Structure .................................................................................................. 66
14.1.1.3.2 Formatting rules for fields ......................................................................... 67
14.1.2 SWIFTNet FIN Messages - Details .......................................................... 69
14.1.2.1 Header and Trailer ................................................................................... 69
14.1.2.1.1 Header ..................................................................................................... 69
14.1.2.1.1.1 Basic Header ........................................................................................... 69
14.1.2.1.1.2 Application Header................................................................................... 70
14.1.2.1.1.3 User Header ............................................................................................ 72
14.1.2.1.2 Trailer ...................................................................................................... 80
14.1.2.1.2.1 General description .................................................................................. 80
14.1.2.1.2.2 Handling of PDM/PDE Trailer................................................................... 83
14.1.2.2 Textblock of the different message types ................................................. 91
14.1.2.2.1 Payment messages ................................................................................. 91
14.1.2.2.1.1 MT 103 .................................................................................................... 91
14.1.2.2.1.2 MT 103+ .................................................................................................. 98
14.1.2.2.1.3 MT 202 .................................................................................................. 103
14.1.2.2.1.4 MT 202 COV .......................................................................................... 115
14.1.2.2.1.5 MT 202 simplified (HAM only) ................................................................ 122
14.1.2.2.1.6 MT 204 .................................................................................................. 126
14.1.2.2.2 Cash flow management messages ........................................................ 129
14.1.2.2.2.1 MT 900 .................................................................................................. 129
14.1.2.2.2.2 MT 910 .................................................................................................. 138
14.1.2.2.2.3 MT 940 .................................................................................................. 150
Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 iii

Table of Contents
14.1.2.2.2.4 MT 950................................................................................................... 157

14.1.2.3 SWIFT system messages ...................................................................... 164
14.1.2.3.1 MT 012................................................................................................... 164
14.1.2.3.2 MT 019................................................................................................... 166
14.1.2.4 Examples for addressing payments ....................................................... 168
14.1.2.4.1 Payments between HAM and PM........................................................... 171
14.1.2.4.2 Payments between account holders in HAM .......................................... 177
14.1.2.4.3 Payments with proprietary home accounts ............................................. 178
14.2 SWIFTNet InterAct and FileAct related issues ..................182

14.2.1 Overview ................................................................................................ 182
14.2.2 How to use the application-to-application approach ............................... 183
14.2.3 Use cases .............................................................................................. 184
14.2.3.1 Home Accounting Module ...................................................................... 184
14.2.3.1.1 Modify reservation .................................................................................. 184
14.2.3.1.2 Modify standing order ............................................................................. 185
14.2.3.1.3 Liquidity transfer (between accounts belonging to the same participant in
HAM and PM) ........................................................................................ 186
14.2.3.1.4 Regular transactions (interbank transfer between accounts ................... 186
14.2.3.1.5 Get account............................................................................................ 187
14.2.3.1.6 Get reservation ...................................................................................... 188
14.2.3.1.7 Get transaction ....................................................................................... 189
14.2.3.1.8 Get business day information ................................................................. 190
14.2.3.2 Reserve Management ............................................................................ 191
14.2.3.2.1 Get account RM ..................................................................................... 191
14.2.3.3 Standing Facilities .................................................................................. 192
14.2.3.3.1 Liquidity transfer between SF and PM/HAM account .............................. 192
14.2.3.3.2 Get account SF ...................................................................................... 193
14.2.3.3.3 Get transaction SF ................................................................................. 193
14.2.3.4 Static Data ............................................................................................. 194
14.2.3.4.1 Get HAM account ................................................................................... 194
14.2.3.4.2 Get SF account ...................................................................................... 195
14.2.3.4.3 Get participant........................................................................................ 195
Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 iv

Table of Contents
14.3 Internet access related issues ........................................... 196

14.3.1 Overview ................................................................................................ 196
14.3.2 Account statement ................................................................................. 196
14.4 Entry check .......................................................................... 204

14.4.1 Double entry check for HAM .................................................................. 204
14.4.2 Error codes ............................................................................................ 204
15 Test procedure ...................................................... 205
Glossary and Abbreviations ................................. 206
Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 v

11 Introduction
11 Introduction
Aims This document aims at presenting the User Detailed Functional Specifica-
tions (UDFS) of the optional modules of the TARGET2 system. It comes in
addition to a first book dealing with the core services of TARGET2, to a third
book providing additional information for central banks and to a fourth book,
which describes the formats of XML messages. The fourth book is com-
pleted by the schema files provided in an electronic form. Furthermore, de-
tailed information on ICM screens is provided in the ICM User Handbooks.
These books constitute the whole set of UDFS for TARGET2.
The optional modules described hereafter are offered to the users of a
banking community through SSP modules if their central bank (CB) decided
to opt for such modules. Each CB can decide either to adopt such modules
or to offer the corresponding services through a proprietary application.
When a CB has opted for an optional module of the SSP, its use by the
banking community of the country considered is either mandatory (eg:
Standing Facilities (Module), Reserve Management (Module)) or optional
(Home Accounting Module).
Services provided to all users
Mandatory Optional
• Payments processing in the Pay- • Liquidity pooling Scope of

ments Module (PM)
• Limits Book 1
• Information and Control Module
• Liquidity reservations
(ICM)
• Contingency Module (CM)
• Value added services related to the
TARGET2 interconnection with
• Static Data (Management) Module T2S
(SD)
Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 1

11 Introduction
Services provided to all users subject that the relevant CB has opted for these
services
Mandatory Optional
• Standing Facilities (Module) (SF) • Home Accounting Module (HAM) Scope of

• Reserve Management (Module) this book
(RM)
Services provided only to central banks
Mandatory Optional
• Monitoring • Billing optional services (CRISP) Scope of

• Mandatory CRSS services • Query and report optional services Book 3
(CROSS: storage, archiving, files (CRAKS1)
for billing calculation)
• Customer relationship optional
• Static Data (specific consultation/ services (CRAKS3)
updates by the CBs)

11 Introduction
12.1 User Guide for Home Accounting Module (HAM)
12.1.1 Overview and functional architecture
mandatory services for CBs

CRSS optional services for CBs
(CROSS, storage, archiving, files for
(CRAKS1, CRISP, CRAKS3)
billing calculation)
Payments Module (PM) Standing Static Data (SD)

Facilities (SF) Module
payments processing
Home
Ancillary Accounting Monitoring
participant T2S Module (HAM)
Systems
interface Interface
Interface Rerserve
(Y-copy) (T2SI) Contingency
(ASI) Management
Module (CM)
(RM)
Information and Control Module
(ICM)
Central Credit Ancillary T2S actors in

Banks Institutions Systems T2S TARGET2
(CBs) (CI) (AS) (eg CSDs)
Scope of this book
Structure The present document is structured as follows:

• Chapter 12 User Guide for optional modules, page 5
User guide for optional modules presents the user functionality of the dif-
ferent optional modules proposed by the SSP.
• Chapter 13 ICM User Handbook, page 59
ICM user handbook (optional modules) presents a general overview of
the Information and Control Module for each optional module. Detailed
information on the ICM, the related screens and the user roles in provid-
ed in a separate document “ICM User Handbook I“.
• Chapter 14 Technical Specifications, page 60
Technical specifications present the use of the SWIFT reference to PM
and HAM, the description of the messages used within the SSP and oth-

11 Introduction
er technical aspects for the optional modules (including their interaction

with core modules). The use of Internet access is also present.
• Chapter 15 Test procedure, page 205
Tests procedures present the rules management of the tests regarding
the development of the optional modules of the SSP.
References to time should be read as references to CET/CEST (even if it is
not mentioned separately). CEST (Central European Summer Time) is a
daylight saving time/summer time zone. It is generally only used during the
summer and during the winter CET is used instead.

12 User Guide for optional modules

12.1 User Guide for Home Accounting Module
(HAM)
Overview Home Accounting Module (HAM) manages accounts that can be held by
two different kinds of users:
• Banks and other entities, according to the rules defined by the respective
CB (in the following “HAM account holders“)
• CB customers (correspondents and others) not allowed, according to the
TARGET Guideline, to open accounts in the PM (in the following “CB
customer’s account holders“).
HAM accounts, according to the specific situation of each individual country,
can be held by:
• banks not direct PM participant, but subject to minimum reserve require-
ments and wishing to manage cash withdrawals, deposits, etc. directly;
• banks which are direct PM participant, but need to have a second set of
accounts in order to settle specific operations;
• banks entering the system using Internet access having either HAM or
CB customer account.
HAM accounts do not have payment system purposes. Only a limited num-
ber of operations can be settled on them: transactions with CBs and basic
interbank transfers for the management of minimum reserves. Customer
payments, cross-border payments and balances stemming from ancillary
systems have to be settled in the RTGS account.
Transfers between HAM accounts and “CB customer’s accounts“, even if
held at the same CB, are not allowed.

HAM accounts: The following diagram shows the transactions allowed from/to HAM ac-
Transactions counts:
allowed
CB 1 Other CBs
RTGS accounts
HAM accounts
CB customer’s “CB customer’s accounts“ can be used to settle domestic and cross-border
accounts payments (both customer and interbank) within “CB customer’s accounts“
and towards PM (transfers between CB customer’s accounts held at differ-
ent CBs and between CB customer’s accounts and RTGS accounts held at
different CBs are allowed).

CB customer’s The following diagram shows the transactions allowed from/to “CB custom-
accounts: Trans- er’s accounts“:
actions allowed
CB 1 Other CBs
RTGS accounts
CB’s customer
accounts
Functional HAM is accessible through a SWIFTNet interface based on a V-shape mod-

architecture el.
All operations settled in HAM accounts can be initiated via:
• “Simplified“ MT 202 with a limitation in the format (only fields needed for
the execution of transfers of liquidity are allowed; it is not possible to
specify a final beneficiary different from the account to be credited). In-
ternet-based participant are not allowed to perform MT 202 but only li-
quidity transfer via ICM.
• Information and Control Module (ICM) at the initiative of the account
holder or, in contingency situations, at the initiative of the CB on behalf of
the account holder (backup transactions)
Operations settled through “CB customer’s accounts“ can be triggered via:
• MT 202, MT 202 COV (Bank to Bank payment with customer credit trans-
fer details)

• MT 103/103+
• Information and Control Module (ICM) at the initiative of the CB on behalf
of the account holder (backup transactions)
The functional architecture of HAM is illustrated in the following slide:
CB
"HAM accounts "CB customer’s
holders" accounts holders"
FIN msgg
FIN msgg FIN msgg MT 202/202 COV/
MT 202/900/910/940/950 MT 202/900/910/940/950 103/103+/900/910/940/950
€ €
(Browse/InterAct/FileAct, € € €
Reporting, Browse/InterAct € (Browse/InterAct €
Administration, Cash reporting) Cash reporting)
Monitoring, data for
general ledger, central
bank operations)
SWIFTNet
SWIFT Interface
RM HAM
Liquidity bridge
SF PM
INTERNET
"HAM accounts "CB customer’s

holders" accounts holders"
Low volume participant Low volume participant
FIN msgg
Liquidity transfer MT 202/2502 COV/103/103+
€ €
€ €
€ €

12.1.2 Participation in HAM
12.1.2 Participation in HAM

Participants HAM accounts can be opened by:
• Direct PM participants (with an RTGS account)
• Indirect PM participants (also SWIFT limited member with a SWIFT-BIC)
• Credit institutions and other entities not participating in PM (neither di-
rectly nor indirectly)
“CB customer’s accounts“ can be opened by institutions (not allowed to
open accounts in the PM according to TARGET Guideline) which are cus-
tomers of a CB participating to TARGET2.
CUG A Closed User Group (CUG) is set up in order to:

• Verify that only authorised participants can exchange messages with the
HAM (as holder either of HAM accounts or of “CB customer’s accounts“).
• Allow those participants that are not full member of SWIFT to open ac-
counts in the HAM. Some entities have a SWIFT-BIC, but do not meet
the requirements to be full SWIFT members (SWIFT shareholders able to
exchange SWIFT message worldwide), for these entities SWIFT has
provided alternative modalities, among which the Payment System Par-
ticipant (PSPA) is used within HAM. These entities need to have a
SWIFT-BIC and are able to exchange SWIFT messages within the CUG
of HAM.
• Use the reverse billing service offered by SWIFT for the notifications sent
by the HAM to HAM account holders.
Two different CUGs need to be set up for “HAM account holders“ and for
“CB customer’s account holders“ taking into account that different address-
es are used for sending the transactions and that the reverse billing function
is used only for “HAM account holders“.
“HAM account holder“ and “CB customer's account holders“ can have a
SWIFT-BIC or a non-SWIFT-BIC. In the latter case the input of the transac-
tions can be done directly only by participants using Internet access, for the

12.1.3 Account management
others input is done by the central bank or by the co-manager (Internet-

based participants cannot act as co-manager even though they can be co-
managed).
Participants only using Internet access do not need to be members of a
CUG.

Account As regards the account management:
management
• One institution is allowed to open several accounts in the HAM. However,
each account is identified by a different BIC-11. As an exception, for CB
customers it will be possible to identify with the same BIC-11 accounts
opened at different CBs. In this case payments will be addressed using
an internal SSP identifier linked in a unique way to the CB customer BIC
and to the CB BIC, see example No. 7 in chapter 14.1.2.4.1 Payments
between HAM and PM, page 171.
• The “group of accounts“ function is dedicated to RTGS accounts in PM
and hence not available on the HAM.
For “CB customer’s accounts“, a specific function is provided to CBs in or-
der to manage a liquidity threshold and to enable them to invest possible
excess funds on behalf of their customers.
Co-management For HAM accounts, a co-management function between the RTGS account
in PM held by the direct participant (the co-manager) and the HAM account
of another credit institution (co-managed account) is possible. In this case,
the co-manager is able to manage the account of the co-managed, having
both the possibilities of:
• debiting the HAM account and crediting its own RTGS account (direct
debit between participants) or the RTGS account of another participant
• debiting the HAM account and crediting another HAM account (same CB)
The co-management function will be available also on a cross-border basis.

On an optional basis the co-manager will be able to receive the settlement

notification (MT 900/910) for all the transactions settled in each co-managed
account.
Furthermore, on an optional basis the co-manager will be able to receive the
balance report (MT 940/950) for all the co-managed accounts.
Internet-based participants cannot act as co-manager even though they can
be co-managed.
Other features For both HAM accounts and “CB customer’s accounts“ a storing function for
future value date payments is provided (up to five TARGET working days in
advance). The storing function is not available in case of HAM Internet-
based participant which can only use the ICM liquidity transfer (other ac-
count) functionality.
CBs are able to debit and credit all the accounts held by their “CB custom-
er’s/HAM account holders“ both via SWIFTNet FIN (using the MT 202 “Sim-
plified“ for HAM accounts and the MT 202 “Standard“, MT 202 COV and MT
103/103+ for CB customer’s accounts) and via ICM (HAM Internet-based
participant can only use the ICM liquidity transfer (other account) functionali-
ty).
Banks holding both a HAM account and an account in the PM have access
to an automatic transfer function for start-of-day (either for the whole bal-
ance or for a specific amount) from HAM account to RTGS account, as well
as end-of-day transfers from RTGS account to HAM account. In this case it
is needed to have the same BIC-11 for the accounts held in PM and HAM.

12.1.4 Transactions processing

Transactions All the transactions settled through the HAM are immediately final.
related to HAM
accounts The following operations can be settled on the HAM accounts:
No. Operation
1 Interbank transfer between HAM accounts (held at the same central bank) includ-
ing operations with the own central bank (eg cash withdrawals and deposits, etc.)
2 Interbank transfer between HAM accounts (held at the same central bank) initiated
by a PM co-manager
3 Liquidity transfer from HAM accounts to RTGS accounts (accounts held by the
same participant)
4 Interbank transfers from HAM accounts to the RTGS account (accounts of differ-
ent participants also in case the accounts are held by different CBs)
5 Interbank transfers from HAM accounts to the RTGS account (accounts of differ-
ent participants) initiated by a co-manager
6 Interbank transfers from HAM accounts to the RTGS account of the co-manager
7 Liquidity transfers from RTGS accounts to HAM accounts (both accounts held by
the same participant)
8 Interbank transfers from RTGS accounts to HAM accounts (accounts of different

participants)
9 Transfers with the SF in order to have access to the standing facilities (only via
ICM)
10 Automatic transactions stemming from the RM (remuneration and penalties)
11 Automatic transactions related to billing (stemming from CRISP) (not available

from the start of TARGET2)
Note: In the operations No. 3 and 7 same participant means a participant

holding a PM and a HAM account identified by the same BIC-11.

The processing of transactions No. 1 to No. 8 is described in the following

diagrams and tables.
Interbank Interbank transfer between HAM accounts (held at the same central bank)
transfers between (No. 1):
HAM accounts
Bank A Bank B
SWIFTNet FIN
MT 202 MT 202
MT 900 MT 910
"Simplified" "Simplified"
4 4
1 3
Participant Interface
2 Booking
optional Payment processing

message
HAM

Step Description
1 Sender (Bank A) generates a payment message (MT 202 simplified) and address-
es it to HAM, with beneficiary Bank B.
2 HAM debits Bank A’s account and credits Bank B’s account.
3 HAM sends the payment message (MT 202 simplified) to Bank B.
4 On an optional basis the debit notification (MT 900) is sent to Bank A and the
credit notification (MT 910) is sent to Bank B.
Note: CIs have the possibility to choose separately whether to receive the
debit (MT 900) and/or credit notification (M T910) (Internet-based partici-
pants will get no confirmation via MT 900/910).
The Internet-based participants can use the existing functionality “Liquidity
Transfer other Accounts“ to transfer liquidity from the HAM account to other
HAM accounts (both SWIFT-based and Internet-based participants).

Interbank Interbank transfer between HAM accounts (held at the same central bank)
transfers between initiated by a co-manager (No. 2):
HAM accounts
initiated by a co-
manager Co-manager Co-managed Bank B
(PM participant) (HAM participant) (HAM participant)
SWIFTNet FIN
MT 900
4
MT 202 MT 202 MT 910
"Simplified" MT 900 "Simplified"
4 4
1 3
2 Booking
optional Payment processing

message
HAM

Step Description
1 Co-manager generates a payment message (MT 202 simplified) and addresses it

to HAM, with beneficiary Bank B, setting as debtor the co-managed.
2 HAM debits co-managed account and credits Bank B’s account.
3 HAM sends the payment message (MT 202 simplified) to Bank B.
4 On an optional basis the debit notification (MT 900) is sent to the co-manager and
to the co-managed, and the credit notification (MT 910) is sent to Bank B.
Liquidity Liquidity transfer from HAM accounts to RTGS accounts (same participant)
transfers from (No. 3):
HAM accounts to
RTGS accounts in
PM (same partici- SWIFTNet FIN
pant) (SWIFT- 3
based) Bank A Bank A
MT 900
MT 202 7
"Simplified"
MT 910
1
Participant Interface Internal Participant Interface

message
2 Booking 5 Booking
Payment processing Notification Payment processing

6
HAM PM
optional
message

Step Description
1 Sender (Bank A) generates a liquidity transfer message (MT 202 simplified) and
addresses it to HAM, with beneficiary its own account in PM (the same BIC needs
to be used in PM and HAM).
2 HAM debits the HAM account of Bank A and credits the account of the CB.
credit notification (MT 910) is sent to the CB.
4 HAM sends an internal message (MT 202 simplified) to PM.
5 PM debits the account of the CB and credits the RTGS account of Bank A.
6 PM sends a notification to HAM.
7 On an optional basis, PM sends the credit notification (MT 910) to Bank A and the
debit notification (MT 900) to the CB.

Interbank From HAM accounts to RTGS accounts in PM (different participants also in

transfers from case of accounts held at different central banks) Interbank transfers from
HAM accounts to HAM accounts to the RTGS account of another participant (No. 4):
RTGS accounts in
PM (different par-
ticipants also in SWIFTNet FIN
case of accounts Bank A 3

Bank B
held at different MT 900
MT 202
MT 202
central banks) “Simplified“
1 7

message
2 Booking 5 Booking

6
HAM PM
optional
message
Step Description
1 Sender (Bank A) generates a transfer message (MT 202 simplified) and address-
es it to HAM, with beneficiary PM participant (Bank B).
2 HAM debits the account of Bank A and credits the account of the CB of Bank A.
credit notification (MT 910) is sent to the CB.
5 PM debits the account of the CB of Bank A and credits the account of Bank B.

Step Description
7 PM sends an MT 202 (based on data of M T202 simplified) to Bank B.
8 On an optional basis PM sends the debit notification (MT 900) to the CB.
Note: Internet-based participants can use the existing functionality “Liquidity

Transfer other Accounts“ to transfer liquidity from the HAM account to the
PM account (both SWIFT-based and Internet-based participants). (Internet-
based participants will get no confirmation via MT 900/910).
Interbank Interbank transfers from HAM accounts to the RTGS account of another
transfers from participant initiated by a co-manager (No.5):
HAM accounts to
RTGS accounts
Co-managed
initiated by a co- (HAM participant)
manager
SWIFTNet FIN
Co-manager 3 3 Bank B
(PM participant) (PM participant)
MT 900 MT 900
MT 202 MT 202
“Simplified
“
1 7

message
22 Booking 5 Booking

6
HAM PM
optional message

Step Description
1 Co-manager generates a transfer message (MT 202 simplified) and addresses it

to HAM, with beneficiary PM participant (Bank B), setting as debtor the co-
managed.
2 HAM debits the co-managed account and credits the account of the CB of the co-
managed.
to the co-managed and the credit notification (MT 910) is sent to the CB.
5 PM debits the account of the CB of the co-managed and credits the account of
Bank B.
7 PM sends an MT 202 (based on data of MT 202 simplified) to Bank B.

Interbank Interbank transfers from HAM accounts to the RTGS account of the co-
transfers from manager (No. 6):
HAM accounts to
the RTGS
Co-managed
account of the co- (HAM participant)
manager SWIFTNet FIN

Co-manager 3 Co-manager
3
(PM participant) 7 (PM participant)
MT 900 MT 900
MT 202 MT 202
“Simplified“
1

message
2 Booking 5 Booking

6
HAM PM
optional message
Step Description
1 Co-manager generates a transfer message (MT 202 simplified) and addresses it

to HAM, with beneficiary itself in PM, setting as debtor the co-managed.
2 HAM debits the co-managed account and credits the account of the CB of the co-
managed.
to the co-managed and the credit notification (MT 910) is sent to the CB.
5 PM debits the account of the CB of the co-managed and credits the account of the

Step Description
co-manager.
7 PM sends to the co-manager the MT 202 (based on data of MT 202 simplified).
Liquidity Liquidity transfers from RTGS accounts to HAM accounts (same participant)
transfers from (No. 7):
RTGS accounts in
PM to HAM
accounts (same SWIFTNet FIN 2 1
participant) 10 MT 202
Bank A Bank A
MT 202 9
simplified
MT 202 2
MT 910
10
MT 096
MT 097
3 8
Participant Interface 5 Participant Interface (Y-copy)
Internal
6 Booking message 4 Booking Acknowledgement
7
Payment processing Payment processing
Notification
HAM PM
optional message

Step Description
1 Sender (Bank A) generates a payment message (MT 202 with limitation in the
format according MT 202 simplified) and addresses it to PM, with beneficiary its
own HAM account.
2 The payment is temporarily stored by SWIFT.
3 A settlement request (MT 096) is sent to PM.
4 PM debits the Bank A’s RTGS account and credits the account of the CB. On an
optional basis, PM sends the credit notification (MT 910) to the CB.
5 PM sends to HAM an internal message (MT 202 simplified).
6 HAM debits the account of the CB and credits the HAM account of Bank A.
7 HAM sends a notification to PM.
8 PM generates a settlement confirmation (MT 097) and sends it to SWIFT.
9 SWIFT sends the stored payment (MT 202) to PM (useless leg of Y-copy).
10 On an optional basis, HAM sends to Bank A the confirmation of the execution of

the transfer (MT 202 simplified) and/or the credit notification (MT 910) and sends
the debit notification (MT 900) to the CB.

Interbank Transfers (interbank) from RTGS accounts to HAM accounts (different par-
transfers from ticipants) (No. 8):
RTGS accounts in
PM to HAM
accounts (differ- SWIFTNet FIN 2 1
ent participants) 10 MT 202
Bank A Bank B
MT 202 9
simplified
MT 910 MT 202
11
MT 096
MT 097
3 8
Participant Interface 5 Participant Interface (Y-copy)
Internal
message Acknowledgeme
6 Booking 4 Booking
nt
Payment processing 7 Payment processing

Notification
HAM PM
optional message
Step Description
1 Sender (Bank B) generates a payment message (MT 202 with limitation in the
format according MT 202 simplified) and addresses it to PM, with beneficiary Bank
A in HAM.
4 PM debits the Bank B’s account and credits the account of the CB of Bank A.
5 PM sends to HAM an internal message (MT 202 simplified); on an optional basis

Step Description
the credit notification (MT 910) is sent to the CB.
6 HAM debits the account of the CB of Bank A and credits the HAM account of Bank
A.
7 HAM sends a notification to PM.
9 SWIFT sends the stored payment (MT 202) to PM (useless leg of Y-copy).
10 HAM sends the notification (MT 202 simplified) to Bank A.
11 On an optional basis, HAM sends the credit notification (MT 910) to Bank A and
the debit notification (MT 900) to the CB.
Note:
• Sender SWIFT-based PM - Receiver HAM Internet-based participant:
Sender must send the payment in SWIFT Y-copy mode to the receiver
“TRGTXEPMHAM“ in the header. The HAM account holder, whose CB
has to be credited will be specified in field 58 of the Y-copy payment by
filling in the BIC of the Internet-based participant. The CB will be credited
in PM and the payment will be forwarded to HAM, where the HAM ac-
count of the Internet-based participant will be credited in HAM (Internet-
based participants will get no confirmation via MT 900/910).
• Sender PM Internet-based participant - Receiver HAM account holder ei-
ther SWIFT-based or Internet-based participant:
Internet-based participants enter their payment instructions via the new
dedicated screen for MT 202 in their ICM Internet interface. In this case
the receiver (which is not transmitted to HAM) must be filled with the
PMHAM BIC TRGTXEPMHAM. Field 58 has to be filled with the BIC of
the HAM account holder. The ICM forwards the entered payment infor-
mation (fields will be similar to MT 202 message structure) to PM, where
the necessary booking information is extracted.
The payment will be credited to the HAM CB. PM will generate an inter-
nal 202 message according to the entered payment information and will

send this message to HAM, where the HAM participant is credited (Inter-
net-based participants will get no confirmation via MT 900/910).
Payments of “CB “CB customer’s accounts“ can process:

customer’s
accounts“
No. Operation
1 Payments (customer and interbank) between CB customer’s accounts held at the

same central bank
2 Payments (customer and interbank) between CB customer’s accounts held at

different central banks
3 Payments (customer and interbank) from CB customer’s accounts to RTGS ac-

counts (held at the same or at a different CB)
4 Payments (customer and interbank) from RTGS accounts to CB customer’s ac-

counts (held at the same or at a different CB)
The processing of transactions No. 1 to No. 4 is described in the following

diagrams and tables and please consider in every image also MT 202 COV.

Payments Payments (customer and interbank) between CB customer’s accounts held

between “CB at the same central bank (No. 1):
customer’s
accounts“ (same
CB) CB customer A CB customer B
SWIFTNet FIN
MT 202/
MT 202/ MT 103/
MT 103/ MT103+ MT 910
MT 103+ MT 900 3 4
1 4
2 Booking
Payment processing
optional message
HAM

Step Description
1 Sender (CB customer A) generates a payment message (MT 202/202 COV/103/

103+) and addresses it to HAM, with beneficiary CB customer B.
2 HAM debits CB customer A’s account and credits CB customer B’s account.
3 HAM sends the payment message (MT 202/202 COV/103/103+) to CB customer

B.
4 On an optional basis the debit notification (MT 900) is sent to CB customer A and
the credit notification (MT 910) is sent to CB customer B.
Note:
• Sender SWIFT-based - Receiver Internet-based participan:
Only steps 1 and 2 applicable.
• Sender Internet-based participant - Receiver SWIFT-based:
The Internet-based CB customer can enter MT 103(+) and MT 202
(COV) via new dedicated ICM screens. The ICM forwards the payment
information (fields will be similar to MT 103(+)/202 (COV) message struc-
ture) to HAM, where the necessary booking information is extracted.
Then the rest of the SWIFT message flow will follow and the payment will
be settled.
• Sender Internet-based participant - Receiver Internet-based participant:
(COV) via new dedicated ICM screens. The ICM forwards the payment
information (fields will be similar to MT 103(+)/202 message structure) to
HAM, where the necessary booking information is extracted. Then the
payment will be settled and no other message will follow.

Payments Payments between CB customer’s accounts held at different central banks

between “CB (No. 2):
customer’s
accounts“ CB A CB B
(different CBs) Customer A Customer B
1 SWIFTNet FIN 5
11
MT 202/ MT 202/
MT103/ 12
MT 103/
MT103+ MT 103+ MT 910 9
MT 202/
MT 103/
3
MT 096
MT 097
MT 103+
MT 900 4 6 8
MT 202/
MT 103/
MT 103+
(Y-copy)
2 Booking 10 Booking 77 Booking

CB B in HAM
Addressed to
HAM PM
optional message
Step Description

103+) and addresses it to HAM, with beneficiary CB customer B.
2 HAM debits CB customer A’s account and credits the relevant CB account (CB A’s
account).
3 On an optional basis the debit notification (MT 900) is sent to CB customer A and

Step Description
4 HAM sends the payment message (MT 202/202 COV/103/103+) to SWIFT, ad-
dressed to the BIC TRGTXECBccX (where cc is the country code representing CB
B + “X“).
7 PM debits the account of the CB of CB customer A and credits the account of the
CB of CB customer B.
9 SWIFT sends the stored payment (MT 202/202 COV/103/103+) to the BIC
TRGTXECBccX.
10 HAM debits the account of the CB of CB customer B and credits CB customer B

account.
11 HAM sends the payment message (MT 202/202 COV/103/103+) to CB customer

B.
12 On an optional basis the credit notification (MT 910) is sent to CB customer B and
the debit notification (MT 900) is sent to the CB.
Note:
• Sender SWIFT-based - Receiver Internet-based participant:
Steps 11 and 12 not applied;
(COV) via new dedicated ICM screens. Then the rest of the normal
SWIFT message flow will follow.
The Internet-based CB customer can enter MT 103(+) and M 202 (COV)
via new dedicated ICM screens. Then the normal SWIFT message flow

will take place except for the input SWIFT message from the sender and
the notification to the receiver.
Payments from Payments from CB customers to RTGS accounts (No. 3):

“CB customer’s
accounts“ to
SWIFTNet
RTGS accounts in 1
FIN 5 9
PM Customer MT 202/ MT 103/ MT 103+ 4 MT 202/ MT 103/ MT 103+ MT 202/ MT 103/ MT 103+
Bank B
A
3
MT 900
MT 096
MT 097
6 8
Participant Interface Participant Interface (Y-copy)
2 Booking 7 Booking
HAM PM
optional message
Step Description

103+) and addresses it to HAM, with beneficiary Bank B.
2 HAM debits CB customer A’s account and credits the relevant CB account (CB A’s
account).
3 On an optional basis the debit notification (MT 900) is sent to CB customer A, and
4 HAM sends the payment message (MT 202/202 COV/103/103+) to SWIFT.

Step Description
7 PM debits the account of the CB of CB customer A and credits the Bank B’s ac-
count.
9 SWIFT sends the stored payment (MT 202 (COV)/103/103+) to Bank B.
Note:
the normal SWIFT message flow will take place except for the notification
to the receiver.
(COV) via new dedicated ICM screens. Then the rest of the normal
SWIFT message flow will follow.
(COV) via new dedicated ICM screens. Then the normal SWIFT mes-
sage flow will take place except for the input SWIFT message from the
sender and the notification to the receiver.

Payments from Payments from RTGS accounts to CB customer’s accounts (No. 4):
RTGS accounts in
PM to CB 8
customer’s SWIFTNet FIN
2 1
accounts Customer MT 202/ MT 103/ MT 103+ 6 MT 202/ MT 103/ MT 103+ MT 202/ MT 103/ MT 103+
Bank B
A
9
MT 910
MT 096
MT 097
3 5
Participant Interface Participant Interface (Y-copy)
7 Booking 4 Booking
HAM PM
optional message
Step Description
1 Sender (Bank B) generates a payment message (MT 202/202 COV/103/103+) and

addresses it to HAM, using the specific BIC of the CB in HAM, with beneficiary CB
customer A.
4 PM debits the Bank B’s account and credits the relevant CB account (CB of CB
customer A).

Step Description
6 SWIFT sends the stored payment (MT 202/202 COV/103/103+) to HAM.
7 HAM debits the account of the CB of CB customer A and credits the CB customer
A’s account.
8 HAM sends the notification (MT 202/202 COV/103/103+) to CB customer A.
9 On an optional basis the credit notification (MT 910) is sent by HAM to CB cus-
tomer A and the debit notification (MT 900) is sent to the CB.
Note:
The Internet-based CB customer will get no confirmation via MT 910
(step 9). All other steps are applicable as described above.
The Internet-based PM participant can enter MT 103(+) and MT 202
(COV) via new dedicated screens. PM generates a Y-copy output to the
specific BIC of the CB in HAM according to the entered payment infor-
mation (instead of step 1). All other steps (steps 2 - 9) are applicable as
described above.
The Internet-based PM participant can enter MT 103(+) and MT 202
(COV) via new dedicated ICM screens. PM generates a Y-copy output to
the specific BIC of the CB in HAM according to the entered payment in-
formation (instead of step 1). All other steps (steps 2 - 9) are applicable
as described above, except that the Internet-based CB customer will get
no confirmation via MT 910 (step 9).

Rejection of Overview
payments
A payment or a transaction will be rejected and returned to the sender in
case of:
• an incorrect payment or transaction
• the debtor or the creditor or the sender participant has been excluded
from the SSP and the message has not been inserted by the related
home CB
• a lack of liquidity till the end of the payment processing
The SWIFT-based sender of a rejected payment receives an MT 103, an
MT 202 or MT 202 COV quoting the reason (error code and description) for
the rejection and the original message user reference within tag 72.
The error codes for possible rejections are listed in chapter 14.4.2 Error
codes, page 204.
Note: In case of an Internet-based participant as sender, the rejection is on-
ly visible via ICM.
Information in the ICM
The information on payments rejected at the end of the payment processing
is available for the sending, the debtor and the creditor participants. Incor-
rect payments are also displayed for the sending, the debtor and the credi-
tor participants.
As the ICM access is still possible for excluded participants, payments in-
volving an excluded participant are also available for both the sending and
the receiving participant.
Incorrect payments
Syntactical validations will be conducted in
• the SWIFT network and

12.1.5 Cash reservation function
• in HAM
These entry validations will be reflected in the list of error codes described
in chapter 14.4.2 Error codes, page 204.
Payments will be rejected if they are not made up according to these stand-
ards.
12.1.5 Cash reservation function

HAM account holders are able to reserve a certain amount for cash with-
drawals. They can manage in real-time, through the ICM only, the parame-
ters of the reservation process in order to set and change the amount re-
served.
The cash reservation function can be activated:
• for the current business day, until the cut-off time for the cash reservation
function, being set by the respective CB. The request is immediately pro-
cessed.
• for future dates, on the basis of a daily value or a default value. The res-
ervation request is stored and it is processed at the start of the relevant
business day.
When processing the request, the system checks whether the amount of li-
quidity on the HAM account is sufficient for the reservation:
Enough liquidity available Not enough liquidity available
Requested amount will be reserved. • The liquidity available on the account is

reserved.
• The rest of the liquidity will be blocked
when the account is credited until the bal-
ance reaches the level of the reservation
request.

12.1.6 Queue management
After each cash withdrawal transaction the amount reserved is reduced by a

correspondent amount.
The cash reservation function is managed by each credit institution for its
account, however, the CB is able to reserve funds on a credit institution
HAM account for cash withdrawals on behalf of the same credit institutions
(for contingency reasons or on the basis of a permanent authorisation).
At the cut-off time for the cash reservation function the liquidity reserved be-
comes available for any kind of payment.
The information about the cash reservation is available through ICM (only
pull mode).
Other forms of reservation (eg for urgent payments) are not possible; fur-
thermore, no liquidity saving features are available.
12.1.6 Queue management

HAM provides a centralised queuing mechanism for transactions temporari-
ly without cover. The main features of the queuing system are as follows:
• Queued transactions are settled according to a first-in-first-out (FIFO)
principle whenever an increase in the liquidity available on the accounts
occurs.
• All transactions have the same priority except for cash withdrawals,
which benefit from a pre-defined higher priority in the queuing mecha-
nism in order to avoid to be blocked by “normal“ transactions in presence
of funds reserved for them.
• Cancellation of transactions is carried out, only in case of errors, by each
CB on behalf of its credit institutions/customers; the latter are not author-
ised to cancel transactions pending in the queue. The cancellation is ex-
ecuted by the CB via ICM. The way of communication between the CIs
and the CB is up to each CB.
• “CB customer’s account holders“ can ask their CB to change, via ICM,
the order of queued transactions.

12.1.7 Operational day management
No gridlock resolution mechanism is available (only queue scanning).
12.1.7 Operational day management

HAM operating days are the same as for the PM. HAM follows also the
same opening and closing time of the operating days of the PM, both under
normal and exceptional circumstances; other few cut-off times are common
to HAM and PM (eg cut-off for customer payments).
Furthermore, specific cut-off times can be added by each CB for internal
reasons.
An automatic and flexible agenda is available (events, triggers, dependen-
cies). The agenda can be changed on request; for example it is possible to
postpone automatically all the events starting from a certain point in time.
12.1.8 Interaction and reporting

Information via Through the Information and Control Module credit institutions/CB custom-
ICM ers have real-time access to the functions listed in the following table re-
garding the current business day.
Type of infor- Content HAM CB custom-

mation account er’s
account
Liquidity position • Account balance X X
• Reserved funds for cash withdrawals X
• Funds above a pre-defined threshold X
Transactions pro- • Transaction details X X

cessing
• Status of transactions X X
• Content of the outgoing queue X X
• Content of the incoming queue X X

Type of infor- Content HAM CB custom-

mation account er’s
account
• View of transactions delivered in ad- X X

vance
Status of the Sys- • TARGET2 directory X X

tem
• System availability X X
• Operating day cut-off times X X
• System broadcast X X
• System status X X
Parameters • Management of the reservation func- X

tion for cash withdrawals
• Management of the standing order for X

liquidity transfers from the HAM ac-
count to the RTGS account
Liquidity transfers • Transfers from/by the RTGS account X

of the same participant
• Transfers with the Standing Facilities X

Module
Regular transac- • Interbank transfer within HAM or X

tions from/to RTGS account of another par-
ticipant
Note: HAM account holders are not present in the TARGET2 directory as
account holders in HAM, but they can be included as indirect participants in
PM. CB customers can be registered in TARGET2 directory and addressed
through the CB where the preferred CB customer’s account is kept.
In general, participants have access to real-time information through the
ICM (pull mode); optionally real-time notifications (MT 900/910) can be sent
via push mode (not valid for Internet-based participants).

Furthermore, end-of-day statements (MT 940 or 950) are sent in push

mode. Concerning Internet-based participants, no statement files/messages
will be sent in push mode. The Internet-based participant/CB customer will
get its account statement containing the booking information of the current
business day via a file which can be downloaded via his ICM Internet inter-
face. The complete SWIFT string will be saved in the file and provided to the
participants for download.
The download of the statement files will be available for the last 10 business
days. After this period the statements will be deleted. It is in the responsibil-
ity of the Internet-based participant/CB customer to download and store the
files before deletion.
End-of-day transfers of all relevant data to the CRSS platform are provided
for the production of statistical reports. End-of-day transfers of the same raw
data are provided to those CBs that decide to use an internal data ware-
house. Data sent to these CBs are limited to their own data.

12.1.9 Administration
12.1.9 Administration
Administration CBs have the responsibility of the administration of the Home Accounting
via ICM Module with reference to their own “CB customer’s/HAM account holders“.
Through the Information and Control Module CBs have, furthermore, real-
time access to the administration functions listed in the table below regard-
ing the current business day (functions available for credit institutions/CB
customers are also available for CBs if acting on behalf of CI/CB custom-
ers). Obviously each CB is able to manage only the account of its own credit
institutions/customers.
Type of information Content
Administration • Opening/closing of accounts in HAM

• Management of the TARGET2 directory
• Management of the co-management directory
• Management of threshold for “CB customer’s account“
• Exclusion of participants
• Creation/Modification of daily time schedule
• Execution of liquidity transfers/regular transactions on behalf
of the HAM account holders in contingency situations (back-
up transactions)
• Production of a number of reports
• Inquiries on messages received/sent
• Management of queued transactions on behalf of their cus-
tomers
• Cancellation of queued transactions on behalf of their credit
institutions/customers
• Sending of broadcasts
• Monitoring tools (operational, liquidity and technical monitor-
ing) in order to verify the smooth functioning of the system
with reference to the respective credit institutions

12.1.10 Exclusion of an HAM participant
CBs can administer the system as follows:

• Different authorisation profiles (ie reading vs updating)
• Audit logs of all critical events and interventions (ie cancellation of
queued payments, modification of daily time schedule, etc.)
12.1.10 Exclusion of an HAM participant

In HAM the same criteria as in PM are used for the exclusion of participants.
Also the following principles are to be the same as in PM:
• The exclusion will become effective immediately.
• Payments to be booked on the HAM account of the excluded participant
have to be confirmed by the related CB, before the EoD otherwise they
will be rejected.
• Warehoused payments with future value date would stay in the ware-
housed payment queue and would be earmarked when they reach the
value date.
• As regards the co-management function, if the excluded PM participant is
a co-manager for HAM accounts it will not be possible for him any more
to act as co-manager from the time the exclusion becomes effective. It is
up to the co-managed account holders in HAM to nominate a new co-
manager. In the meantime the related CB can act for them on request.
When it is the co-managed HAM participant that is excluded, the relation
between the co-managed account holder in HAM and the co-manager
will remain. The transactions already instructed by the co-manager be-
fore his exclusion will be in the waiting queue for confirmation by the cen-
tral bank of the HAM account holder before the EoD, otherwise they will
be rejected.

12.2 User Guide for Reserve Management (Module) (RM)
12.2.1 General features
12.2 User Guide for Reserve Management

(Module) (RM)
Overview The Reserve Management Module (RM) enables the CBs to perform some
functionality for the reserve requirements management and for the excess
of reserve management.
The module is accessible through a SWIFTNet interface or dedicated Inter-
net access and can interact with PM, HAM and proprietary home accounting
systems.
The RM does not manage any kind of accounts. It only receives - automati-
cally at the end-of-day - from PM, HAM and proprietary home accounts the
end-of-day accounts’ balances in order to manage minimum reserves and
excess of reserve.
The RM will mainly:
• verify the minimum reserve fulfilment,
• calculate the interest to be paid to credit institutions for minimum re-
serves,
• calculate the penalties related to the reserve requirements infringement
to be submitted to the relevant CB’s validation process,
• calculate negative interest on excess of reserve (only the balance from
the account declared in SD as “Source of Minimum Reserve“ is taken in-
to account for the calculation of excess reserve),
• notify the CBs on the minimum reserve fulfilment, due interest and possi-
ble penalties for the pertaining credit institutions,
• create automatically the related credit and debit instructions for minimum
reserve fulfilment (the latter only after the CB validation process) and
send them to PM or HAM (at the end of the maintenance period).

• create automatically the related credit and debit instructions for excess of
minimum reserve and send them to PM or HAM (at the end of the
maintenance period).
Note: Interest for minimum reserve and for excess of minimum reserve are
credited/debited 2 working days after the closing of each maintenance peri-
od, taking as reference the TARGET2 calendar. Penalties related to in-
fringement of minimum reserve are sent for settlement immediately after the
validation process. No credit and debit instructions will be sent to PHA.
A CI using RM can maintain its reserves either on a PM account or on a
HAM/PHA account, but not on both.
Indirect reserve The RM offers also the possibility of managing indirectly the reserve re-
quirements and the excess reserve according to the “General documenta-
tion on Eurosystem monetary policy instruments and procedures“.
On the basis of the list of credit institutions that decide to fulfil indirectly min-
imum reserves and of the banks selected for its management, the RM is
able to verify the fulfilment of minimum reserves and to calculate the excess
reserve.
In case of indirect reserve management the total amount of the due Com-
pulsory Reserve (Direct + Indirect) will be taken into account, albeit at the
end of the period the balance of the direct participant only (the one of the
indirect will not be summed) will be considered for the possible infringement.
The direct participant only will be debited in case of penalty.
Pool of reserve Within RM the so-called “pool of reserve accounts of a Monetary Financial
accounts of an Institution (MFI)“, which enables the fulfilment of reserve requirements for a
MFI group of participants (which are part of the same MFI) can be used.
In this case, the fulfilment of reserve requirements by the MFI is evaluated
on the basis of the sum of balances of all the participant accounts (either in
PM, HAM or in PHA) belonging to the pool, even if from a technical point of
view the minimum reserve of the MFI is linked only to a single pre-defined
account indicated by the MFI (ie MFI leader).

No consolidation is possible on a cross-border basis. At the end of the

maintenance period the accrued interest is credited on the account associ-
ated to the minimum reserve indicated by the MFI.
The same account would be debited in case of infringement penalty, once
validated by the relevant CB.
The balances of all participant accounts belonging to a pool are considered
for the calculation of the excess of reserve. But only the leader account will
be debited in case of negative interest.
It is not possible for the single participants to have access to both functions
“pool of reserve accounts of a MFI“ and indirect reserve management. As a
consequence participants belonging to the same MFI and availing them-
selves of the minimum reserve “pooling“ functionality cannot make use of
the indirect reserve management.
NCB
End-of-day balances €
Reserve
Management Minimum reserve
HAM/PM Module Remuneration rate
Penalties
or
RM
Payment order
(at the end of the maintenance period)
- interest
- penalties für infringement after
CB validation process

12.2.2 Interaction and reporting for credit institutions
12.2.2 Interaction and reporting for credit institutions

Through the Information and Control Module credit institutions have access
to the information listed in the following table:
Minimum reserve • Amount of required reserve
Balances • End-of-day balances of the previous busi-

ness day
• Running average up to the previous busi-
ness day
Adjustment Balance • Balance necessary to fulfil the minimum

reserve
These information are provided to:

• the institutions holding the minimum reserve directly on their account
• the co-manager also on the co-managed institutions
• the institutions holding the minimum reserve indirectly through an inter-
mediary (only its own minimum reserve; end-of-day balance, running av-
erage and adjustment balance are not shown)
• the intermediary holding the minimum reserve directly on its own and on
behalf of other institutions (with a detail of the individual minimum re-
serves of the represented institutions)
• the participants belonging to the same MFI (with the detail of the individ-
ual balances of participants belonging to the MFI)

12.2.3 Administration tool for CBs
12.2.3 Administration tool for CBs

Through the Information and Control Module CBs have access to the func-
tions listed in the following table:
Minimum reserve • Amount of required reserve
Balances • End-of-day balance of the previous busi-

ness day
• Running average up to the previous busi-
ness day
Adjustment balance • Balance necessary to fulfil the minimum

reserve
Administration functions • Management of the list of credit institu-

tions subject to reserve requirements (in-
cluding the MFI grouping and indirect re-
lationships)
• Entry of the value of the minimum reserve
(both application-to-application and user-
to-application mode)
• Management of the infringement penalties
validation process
• Entry of the minimum reserve remunera-
tion and penalties rates (common param-
eters for all CBs that can be inserted by a
single point, that could be the SSP opera-
tional team)
• Monitoring tools to have access to sum-
marised information concerning minimum
reserves (eg Minimum reserve, Running
average and End-of-day balances at the
system level)

12.3 User Guide for Standing Facilities (Module) (SF)
12.3 User Guide for Standing Facilities

(Module) (SF)
Overview The Standing Facilities Module (SF) enables the CBs to manage the stand-
ing facilities (deposit facility and marginal lending facility).
The module is accessible through a SWIFTNet interface (only via ICM) or
dedicated Internet access and can interact with both PM and HAM. No in-
teraction with proprietary home accounts is envisaged.
For the CI with account both in PM and in HAM (or PHA) it is necessary to
indicate which is the account to be used for the settlement of SF operations;
only this account will be used for the settlement of SF operations and of the
related interests. Obviously for the automatic marginal lending only PM ac-
count will be used since intraday credit is not provided in HAM.
The SF module manages two kind of accounts:
• overnight deposit accounts
• marginal lending accounts, for marginal lending “on request“ and auto-
matic marginal lending (automatic transformation of intraday credit in
overnight credit at the end of the day)
The collateral management function is managed outside the SSP and under
the responsibility of the relevant CB. The SSP acts therefore executing in-
structions received from the collateral manager empowered by the relevant
CB to provide collateral management services. As a consequence the SSP
does not perform any control on the collateralisation procedure (eg evalua-
tion process accuracy) carried out by the collateral manager. The SSP only
checks the formal correctness of the message sent by the collateral manag-
er. A single collateral manager can act on behalf of more CBs but in this
case different BIC11 have to be used by the collateral manager.

The following diagram provides a general overview of the SF module func-

tioning:
HAM/PM SF
NCB
Overnight deposit
Overnight deposit €
End-of-day transfer to SF
(business day d
account
Account Transfer of capital and inte-
rest to HAM/PM
(start ob business d+1)
Marginal lending Collateral management
Marginal Lending account for marginal lending
Transfer to HAM/PM
(business day d)
Transfer to SF and debiting

of interest in HAM/PM
(start of business day d+1)
Overnight deposit As to the overnight deposit, credit institutions can transfer, via ICM, liquidity
from HAM or PM to the SF module. It is also possible to activate the reverse
transaction in order to reduce the amount deposited in the overnight ac-
count; the SF calculates the interest to be paid on the overnight deposit and,
at the start of the next business day, sends automatically the capital amount
and the interest to PM or HAM. In case of a negative interest rate the SF
module calculates the interest to be paid by the credit institutions on the
overnight deposit and, at the start of the next business day, sends automati-
cally the capital amount to PM or HAM and debits the interest from PM or
HAM.

The process related to the overnight deposit is described in the following di-
agram and tables:
€ 1 € 1 €
Modify Modify
CI CI CI
2 2
ICM Transfer ICM Transfer ICM
order order
3 1
3
Liquidity Liquidity
SF Direct SF transfer
SF transfer
debit
4 4 2
4 ACK ACK
4 ACK 2
PM PM PM
MT 900 (HAM) MT 910 (HAM) MT 910 (HAM)
SSP SSP SSP

Reverse
Setting up Refunding + interest
(SF credits the overnight
transaction (at start-of-day)
deposit account) (SF debits the overnight
deposit account)
Setting up
Step Description
1 The credit institution (CI) sends (via ICM) an order with an indication of the ac-
count to be debited in order to transfer liquidity from HAM/PM to overnight deposit
account. The possibility to make overnight deposit via SWIFTNet FIN is not envis-
aged.

Setting up
Step Description
2 The order is transferred from ICM to SF.
3 The SF sends a direct debit internal message to PM/HAM. PM/HAM debits the CI
account and credits the CB account.
4 PM/HAM sends an acknowledgement to SF. SF debits the CB account and credits

the CI account. HAM/PM sends (optionally) the MT 900 to CI and the MT 910 to
the CB.
Reverse transaction
Step Description
1 The CI sends (via ICM) an order to transfer liquidity from overnight deposit ac-
count to the HAM/RTGS account.
3 The SF debits the CI account, credits CB account and sends a distinct internal
message to PM/HAM. PM/HAM debits CB account and credits CI account.
4 PM/HAM sends a notification to SF and (optionally) the MT 910 to the CI and the
MT 900 to the CB.

Refunding and interest payment - start of the following business day
Step Description
1 SF calculates the interest to be paid on the overnight deposit. At the start of the
following business day, the CI account is debited and the CB account is credited
for the capital amount. The same happens for the interest in case of positive OD
rate. In case of negative OD rate the CI account is debited and the CB account is
credited for the interest. Two distinct internal messages to PM/HAM (capital
amount and interest) are sent.
2 PM/HAM sends a notification to SF and (optionally) the MT 910 to the CI and the
MT 900 to the CB.
Note: Internet-based participants will get no confirmation via MT 900/910.
Overnight deposit The overnight deposit function is available also for out countries. The pro-
for outs cess for the setting up and the refunding is the same described in the above
picture and tables but interest will be paid on a monthly basis instead that
on a daily basis: that means, that at the start of the following business day
SF module will send automatically to PM/HAM only the capital amount while
the cumulated interest will be credited only after the end of the month. Con-
sidering that interest can be credited not the first business day of the follow-
ing month but some days later, they will be inserted within warehoused
payments, with settlement date five business days later; the respective out
CB will have the possibility to check the interest calculated and to cancel
them from the warehoused payments if the calculation is not correct (using
the functions envisaged for the cancellation of warehoused payments via
ICM).
Furthermore, as regards the liquidity transfer from PM/HAM to SF, a control
will be in place in order to verify that the total amount envisaged for each
country will not be exceeded. Each CB will decide whether the access to the
function will be allowed only for CB on behalf of the CI or directly to the CI.

Marginal lending The process related to marginal lending “on request“ is described in the fol-
facility “on lowing diagram and table:
request“
€ €
Collateral Collateral
manager 1 CI manager
CI
Modify
2
ICM Transfer ICM
Request
3
3 4 Notify
SF Liquidity refunding
SF 1 2
transfer MT 910 Direct
debit MT 900
4 2
ACK ACK
PM PM
(HAM) (HAM)
SSP SSP

(SF debits the marginal
(at start-of-day)
lending account)
Setting up
Step Description
1 The Credit institution deposits collateral to the relevant collateral manager, who,
after the collateral evaluation procedures, sends an order to ICM for the setting up
of the marginal lending facility transfers.

Setting up
Step Description
3 SF debits the CI marginal lending account, credits the CB account and sends an
internal message to PM/HAM. PM/HAM debits the CB account and credits the CI
account.
4 PM/HAM sends the acknowledgement to SF and sends (optionally) the MT 910 to

the credit institution and the MT 900 to the CB.
In case of errors the SSP operator will be able, on behalf of the Collateral
Manager, to operate a reverse transaction from PM/HAM to SF. After the
settlement a notification of the refunding of the marginal lending facility will
be sent, via ICM, to the relevant collateral manager, which releases the col-
lateral.
Step Description
1 SF calculates the interest to be paid by the CI on the marginal lending and, at the
start of the following business day, sends two distinct internal messages to
PM/HAM for debiting the capital amount and the interest (direct debit); PM/HAM
debits the CI account for capital and interest and credits the CB account.
2 PM/HAM sends a notification to SF. SF debits the CB account for capital amount
and credits the CI marginal lending account; PM/HAM sends (optionally) the MT
900 to the credit institution and the MT 910 to the CB.
3 SF sends a notification of the refunding of the marginal lending facility, via ICM, to
the relevant collateral manager, which releases the collateral.
Note: Internet-based participants will get no confirmation via MT 900/910.

Automatic The process related to the automatic marginal lending facility is described in
marginal lending the following diagram and table:
facility
Collateral € €
CB Collateral
manager manager
CI CI
2b
ICM Notify ICM
spillover 3 Notify increase
credit limit and
Notify decrease MT 900
refunding marginal
credit limit 2 lending
and setting up 3
of marginal lending Credit
SF 2
SF transfer 1 Direct debit
and decrease 3 and increase MT 900
credit limit credit limit
1 3 MT 910
Notify 2a 2
intraday ACK
credit not ACK
returned PM
PM
SSP SSP

(SF debits the marginal
(at start-of-day)
lending account)
Setting up - end-of-business day
Step Description
1 At the end of the business day, a specific PM function singles out the amount of
intraday credit not returned by each credit institution and communicates it to SF
through an internal message.

Setting up - end-of-business day
Step Description
2a SF, if the credit institution is endorsed to access the marginal lending facilities,
debits the CI marginal lending account, credits the CB account and sends an in-
ternal message to PM in order to transfer the liquidity to the RTGS account and
simultaneously decrease the respective credit line (connected payment).
2b If the credit institution is not allowed to access the automatic marginal lending
facility SF notifies, through an interact message the spillover to the relevant CB
responsible for applying the penalty procedure.
3 PM debits the CB account, credits the CI account and simultaneously decreases

the respective credit line; hence, sends a notification to SF and (optionally) the MT
910 to the credit institution and the MT 900 to the CB.
Moreover, SF sends, via ICM, a notification to the relevant collateral manager,
who has to move the collateral already posted as an intraday credit guarantee to
the marginal lending facility guarantee.
Step Description
1 SF calculates the interest to be paid by the credit institutions on the marginal lend-
ing and, at the start of the following business day, sends automatically to PM a
debit instruction for the interest and a connected payment for the refunding of the
capital (debit of the RTGS account and increase of the intraday credit line).
2 PM debits the CI account for the capital amount and the interest and credits the
CB account and simultaneously increases the respective credit line. PM sends a
notification to SF which credits the CI marginal lending account for the capital
amount and debits the CB account. Moreover, PM sends (optionally) an MT 900 to
the credit institution and the MT 910 to the CB. SF sends a notification, via ICM, to
the relevant collateral manager, who attributes the collateral already posted as an
overnight guarantee to the intraday credit guarantee.

In all the cases described, the SF module does not send to the CI neither
settlement notification (MT 900/910) nor statements of accounts at the end
of the day (MT 940/950) since all these notifications are sent by PM or HAM
(settlement notification on an optional basis).

12.3.2 Interaction
12.3.2 Interaction
Overview Through the ICM credit institutions have access to the information listed in
the following table, regarding the current business day:
Balances • Current balance of the overnight deposit account

• Current balance and available liquidity of the marginal lend-
ing account
Transactions processing • Transactions details
Liquidity transfers • Transfers with the HAM/PM
Through the ICM CBs have access to the functions listed in the following ta-
ble, regarding the current business day:
Balances • Current balance of the overnight deposit account

• Current balance and available liquidity of the marginal lend-
ing account
Transactions processing • Transactions details
Liquidity transfers • Transfers with the HAM/PM
Administration • Updating of the register of participants eligible to make use

of standing facilities
• Monitoring tools to have access to summarised information
concerning the use of standing facilities (eg balances at
system level of overnight deposit, marginal lending “on re-
quest“ and automatic marginal lending).

13 ICM User Handbook
13.1 Overview on ICM
13 ICM User Handbook

13.1 Overview on ICM
Detailed infor- Detailed information on the ICM, the related screens and the user roles is
mation provided in a separate document “ICM User Handbook I“.

14 Technical Specifications
14.1 SWIFTNet FIN related issues
14.1.1 SWIFTNet FIN - General aspects
14.1.1.1 Business Identifier Codes (BICs) for SSP
Overview The SSP uses several BICs for different purposes. The following diagram
gives an overview of all BICs (SSP core and optional modules):
S: BIC of participant
R: TRGTXEPMHAM /
TRGTXEPMASI / S: BIC of participant
TRGTXEPMLVP / R: TRGTXEHMXXX / TRGTXECBccX
TRGTXEPMT2S
PM HAM
participant participant
S: TRGTXEPMXXX / S: TRGTXEHMXXX /
TRGTXEPMASI / TRGTXECBccX
TRGTXEPMLVP / R: BIC of participant
TRGTXEPMT2S
R: BIC of participant
PAPSS
PM HAM
no BICs used
S: TRGTXEPMXXX
no BICs R: BIC of CB
used
S: BIC of CB
R: TRGTXEPMXXX
Proprietary Home
Accounting
T2S CB
payment
liquidity transfer
ccc SWIFT service code
ccX country code + X
S Sender
R Receiver

BICs of PM The following table lists the different purposes and the BICs used:
Purpose BIC Usage Maintenance
Sending of messag- TRGTXEPMXXX Used as sender in the SWIFT permanent

es directly from PM header for all messages sent
to PM participants directly from PM to PM partici-
pants using SWIFTNet FIN (no
Y-copy!):
• MT 900
• MT 910
• MT 202 (Backup payment)
• MT 202 (Liquidity transfer
from PM to proprietary
home accounting system)
Sending of MT TRGTXE2MXXX Used as sender in the SWIFT permanent

940/950 from PM to Or header; for technical reasons
PM participants the account statements are
TRGTXE3MXXX sent out to the participants by
two different BICs.
Incoming liquidity TRGTXEPMXXX Used as receiver in the SWIFT permanent

transfers from pro- header for payments (liquidity
prietary home ac- transfers) exchanged between
counting systems proprietary home accounting
systems and PM.
Liquidity transfer TRGTXEPMXXX Used as receiver in the SWIFT permanent

from one PM partici- header of MT 202 (liquidity
pant to another PM transfers). Ordering institution
participant in field 52 is equal to the bene-
ficiary institution in field 58 (ie
creditor).
Incoming fund trans- TRGTXEPMHAM Used as receiver in the SWIFT permanent

fer from a PM partic- header for payments (fund

Purpose BIC Usage Maintenance

ipant to HAM transfers) exchanged between
a PM participant and a HAM
account holder.
Liquidity transfer via TRGTXEPMASI Used as sender/receiver in the permanent

ASI SWIFT header for liquidity
transfers exchanged between a
participant and an ancillary
system (AS).
Liquidity transfer via TRGTXEPMT2S Used as sender/receiver in the permanent

T2SI SWIFT header for liquidity
transfers exchanged between a
participant and T2S.
Note: The MT 202 is part of
value added services the par-
ticipant must have opted for. In
account statements
MT940/MT950 incoming liquidi-
ty transfers from T2S are listed
with BIC TRGTXEPMBAH in
field 61, subfield 9.
Payments from or to TRGTXEPMLVP Used as sender/receiver in the permanent

an Internetbased SWIFT header for Y-copy pay-
direct participant ments exchanged between a
PM participant and an Internet-
based direct participant.
Sending of MT TRGTXEPMCON Used as sender in the SWIFT permanent

940/950 from CM to Header for MT 940/950 sent
PM participants from CM to PM participants.

BICs of HAM The following table lists the different purposes and the BICs used:
Purpose Purposed BIC Usage Maintenance
Messages sent TRGTXEHMXXX Used when FIN messages are permanent

from/received by sent/received by this module
HAM participants via SWIFTNet FIN. In the
header of the following SWIFT
messages sent by the HAM this
BIC will be used as send-
er/receiver:
• MT 202 simplified
• MT 900
• MT 910
• MT 940
• MT 950
Payments from HAM TRGTXECBccX ccX: country code + “X“ of the permanent;
to PM and vice ver- different central banks used as: member of the
sa for CB customer • Receiver in the HAM for the PM Y-copy
payments payments sent by the CB CUG
customer.
• Sender in the HAM for the
notification of the payments
received from PM partici-
pants.
• Sender/receiver in the mes-
sages exchanged between
HAM and PM for the CB
customer traffic
Messages sent to TRGTXECBccX In the header of the following permanent

CB customers SWIFT messages:
• MT 900
• MT 910

Purpose Purposed BIC Usage Maintenance
• MT 940
• MT 950
• MT 103/103+
• MT 202/MT 202 COV
BICs used by CBs The following table lists the different purposes and the BICs used:
Purpose Usage Maintenance
BICs for proprietary These BICs do not need to be changed. It is up to permanent

home accounting each CB keeping a proprietary home accounting
systems system to decide whether the old BIC should remain
valid or a new BIC should be used.
Usage of the TARGET2 supports the use of STP rules envisaging the use of format A for
format D in bank all bank fields. Nevertheless, in order to avoid operational difficulties for the
fields processing of payments coming from /sent to outside the EU the use of for-
mat D is allowed in specific fields.
14.1.1.2 Public Key Infrastructure (PKI)
Use of PKI in the The SSP uses the core PKI provided by SWIFT, no additional information is
SSP environment provided in the User Detailed Functional Specifications. All information
needed is available in the documentation provided by SWIFT.
The SWIFTNet FIN access control and user-to-user security mechanisms is
based on PKI while the relationship management capability is based on the
Relationship Management Application (RMA) service on a BIC8 basis. Con-
sidering that the Closed User Group feature can effectively prevent unsolic-
ited traffic and in order to reduce the operational burden for the users, the
bilateral relationships provided by the RMA is not be requested for the user
to user messages MT 103/202/204 in the FIN Copy service for TARGET2

(RMA by-pass). Like for the BKE, RMA bilateral relationships are necessary
vis-à-vis the SSP BICs, therefore, in order to properly manage all the as-
pects of the FIN security for TARGET2 the users have to exchange the
SWIFT RMA between their BIC8 and the SSP BICs both in live and T&T
environments depending on the used modules.
RMA policy The following rules are applicable for the RMA exchange with the SSP:
Live T&T
PM users
SSP Correspondent BIC TRGTXEPM TRGTXEP0
Signing BIC for T&T - TRGTXEPM
SWIFT Service swift.fin swift.fin!p
Frequency of exchange Permanent authorisation Permanent authorisation
Granularity All message category/type All message category/type
Type of RMA both send/receive both send/receive
HAM users
SSP Correspondent BIC TRGTXEHM TRGTXEH0
Signing BIC for T&T - TRGTXEHM
CB customers
SSP Correspondent BIC TRGTXECB TRGTXEC0
Signing BIC for T&T - TRGTXECB

Live T&T
14.1.1.3 SWIFTNet FIN messages
14.1.1.3.1 Structure
General SWIFTNet FIN messages are structured in blocks. Each block of a message
contains a special type of data.
Definition of the Each block begins and ends with a brace ({}). The first two characters
structure of in a block are its number and the separator (:).
blocks
A SWIFT message therefore has the following structure:
• {1: Basic Header Block}
• {2: Application Header Block}
• {3: User Header Block}
• {4: Text Block}
• {5: Trailer}
Building up of Header and trailer are always build up following the same schema. For the
header and trailer different message types they differ only slightly.
The building up of the header and trailer is described in chapter 14.1.2
SWIFTNet FIN Messages - Details, page 69.

The specific message is contained in the text block. It is described for each
message type in a separate chapter.
14.1.1.3.2 Formatting rules for fields
General For describing the message formats in this document the same conventions
as in the SWIFT User Handbooks are used. The individual fields are speci-
fied by their length and the permitted contents.
Specification of The following table summarises the display formats for the field length:
the field length
Field length Meaning
n Maximum n characters
n! Exact n characters
n*m n lines at a maximum of m characters each
Specification of The following table summarises the display formats of the field contents:
the field content
Field content Meaning
n Digits from 0 to 9
a Capital letters from A to Z
x Any character of the SWIFT character font, capital and small letters
c Capital letters from A to Z, and digits between 0 and 9
d Digits from 0 to 9 and comma for showing currency amounts
h Hexadecimal number:
Digits from 0 to 9 and capital letters from A to F
Optional field contents are shown in brackets (eg [34x]).

Field Status The following table summarises the display formats for the field status:
Status Meaning
M Mandatory field
O Optional field
----> Repetitive sequence in a message.

The following fields may appear several times (up to a given maxi-
mum).
----| End of the repetitive sequence

14.1.2 SWIFTNet FIN Messages - Details

14.1.2.1 Header and Trailer
14.1.2.1.1 Header
14.1.2.1.1.1 Basic Header

Usage The basic header is used in every message type sent to or received from
the SSP.
Structure The basic header has the following structure:
Basic Header
Status Field name Format Use in SSP
M Block Identifier 1: -
M Application Iden- F F = FIN

tifier
M Service Identifier 01 -
M LT Address 4!a2!a2!c1!c3!c BIC+LT, 12 digits

Message from participant to FIN:
• Sender’s LT address
Message from FIN to participant:
• Receiver’s LT address
M Session Number 4!n -
M Sequence Num- 6!n -

ber

14.1.2.1.1.2 Application Header

Usage The application header is used in every message type sent to received from
the SSP. It has different formats depending on whether the participant de-
livers a message to, or receives one from, the SWIFT network.
Structure when The following table describes the structure of the application header when a
sending a participant sends a message to the SWIFT network. (It is an outgoing pay-
message ment from the participant’s point of view.)
Application Header
M Block Identifier 2: -
M Input/Output l I = Input for SWIFT

Identifier
M Message Type 3!n 103, 202, 204
M Destination Ad- 4!a2!a2!c1!c3!c BIC+LT, 12 digits

dress • (Receiver’s LT address)
Message to PM participant:
• Receiving bank
Message to proprietary home accounts kept
by a CB in its proprietary home accounting
system:
• BIC of the CB
Message to HAM accounts:
• BIC of the HAM in the SSP
(TRGTXEHMXXX, TRGTXECBccX)

Application Header
M Message Priority N or U PM:

Not relevant!
O Delivery Monitor- 1!n -

ing
O Obsolescence 3!n -
Period
Structure when The following table describes the application header when the participant
receiving a receives the message from the SWIFT network. (It is an incoming message
message from the participant’s point of view.)
Application Header
Field name Format Use in SSP
Block Identifier 2: -
Input/Output O O = Output for SWIFT

Identifier
Message Type 3!n 012, 019, 103, 202, 204, 900, 910, 940, 950
Input Time HHMM Input time
Message Input 6!n4!a2!a2!c1!c Input date, local to the sender, LT address of sender,
Reference 3!c4!n6!n session and sequence number of sender
Date YYMMDD Output date, local to the receiver
Time HHMM Output time, local to the receiver
Message Priority N, U or S N or U = sender’s message priority

S = system (MT 012 and MT 019)

14.1.2.1.1.3 User Header
Usage The user header is basically optional, but it is used in all message types of
SSP.
It has a different format depending on whether the participant delivers a
message to, or receives one from the SWIFT network. Every field in the us-
er header is put in braces ({}).
Note: The individual fields are described in detail in the SWIFT User Hand-
book “FIN System Messages“.
Structure when The following table describes the user header when the participant sends
sending a the message to the SWIFT network (It is an outgoing payment from the par-
message ticipant’s point of view):
User Header
Status Tag Field Name Content/ Use in SSP

Options
M - Block Identi- 3: -
fier
M 103 Service Code {103:3!a} PM:

TGT = Code for the FIN-copy service of the
SSP
If this field is not present, the message will
be delivered directly to the receiver without
processing in the Payments Module (PM).
O 113 Banking {113:4!x} Character 1:

Priority H = highly urgent payment
U = urgent payment
N = normal payment
Character 2:
Y = MT 012 requested

User Header

Options
N = MT 012 not requested

Flag will be ignored and a MT 012 will al-
ways be returned, if the message is ad-
dressed to TRGTXEPMT2S for initiation of a
pull liquidity transfer from T2S and if the
payment is only partially executed by T2S.
So this important information is always re-
ported via an MT 012.
Character 3 + 4:
see note
If character 2 has been given “N“, character
1 must be filled with “H“, “U“ or “N“, other-
wise the default value “NYNN“ will be set.
If the field is not available, SSP treats this
payment as a normal payment and the
sender receives an MT 012 (equivalent to
value “NYNN“).
In messages addressed to TRGTXEPMT2S
this field with character 1 = "H" is mandato-
ry. (Liquidity transfers to T2S are always
highly urgent.)
Character 1 can be entered by the IBP (U or
N). All other characters are not available
and will be set to "N" in the outgoing Y-copy
message sent by PM.
HAM:
If the first character is equal to “H“ the mes-
sage is for cash withdrawal. The other char-
acters have to be filled with “NNN“.
If the field is not available, SSP treats this
payment as a normal payment (equivalent to

User Header

Options
value NNNN“).
O 108 Optional {108:16x} Field is not available for Internet-based

Message participants as this field is used by PM to
User Refer- match the incoming MT 096 from SWIFT
ence (derived from the sent Y-copy message) to
the ICM order (entered by the Internet
based participant in the ICM screens).

User Header

Options
O 119 Validation {119:8c} Use in MT 103:

Flag The participant may request SWIFT valida-
tion according to the rules of the MT 103+
by using {119:STP}.
If this field is not available, MT 103 core will
follow.
Use in MT 202 COV:
The placement of field 119 with code COV is
mandatory.
{119: REMIT} is not allowed in SSP.
In case of payments from Internet-based
participants the validation flag will be as-
signed by the usage of the respective
screen (dedicated screens for MT 103, MT
103+, MT 202 and MT 202 COV are provid-
ed).
O 111 Service type {111:3!n} This field identifies the applicable global
indentifier payment service type.
PM:
Use in MT 103, MT 103+, MT 202, MT 202
COV, MT 204.
HAM:
Use in MT 103, MT 103+. This field is ac-
cepted but not forwarded.
Note: Sender must be member of GPI
closed user group when populating field
111. In that case field 121 must be populat-
ed too: a message that contains only one of
these two fields will not be accepted.

User Header

Options
O 121 Unique end- {121:36!x} This field provides an end-to-end reference

to-end trans- across a payment transaction.
action refer- PM:
ence Use in MT 103, MT 103+, MT 202, MT 202
COV, MT 204.
HAM:
use in MT 103, MT 103+. This field is ac-
cepted but not forwarded.
Note: Sender must be member of GPI
closed user group when populating field
121. In that case field 111 must be populat-
ed too: a message that contains only one of
these two fields will not be accepted.
Note: The third and fourth characters of the field 113 are not used (and not
checked by the SSP). Based on an agreement at national level they can be
used to support specific needs like the indication that in the payment mes-
sage the ordering and/or the beneficiary are non-resident in the country of
the sender (regular reporting purposes).
Structure when The following table describes the user header when the participant receives
receiving a the message from the SWIFT network. (It is an incoming message from the
message participant’s point of view.)
User Header
Tag Field name Content/ Op- Use in SSP

tions
- Block Identifier 3:

User Header

tions
103 Service Code {103:TGT} PM:

TGT = code for SSP in MT 103, 202, 204
Stating “TGT“ is synonymous with settling
payments via Payments Module (PM). All
other MT will not contain field 103.
HAM:
Not present in messages received by HAM
account holders and CB customers.
113 Banking Priority {113:4!x} Banking Priority as set by the sender of the
message. It can be ignored by the receiver.
MT 012, 019, 900, 910, 940, 950 will contain
no field 113.
HAM:
For CB customers it is set to “NNNN“ by
HAM. For HAM account holders, in case of
payments from PM to HAM, it is set to
“NNNN“ by HAM; in the other cases (pay-
ments between HAM accounts) HAM sends
what was set by the sender of the message.
It can be ignored by the receiver.
108 Optional Mes- {108:16x} Only present when filled by the sender of the
sage User Ref- message.
erence HAM:
For messages sent by HAM it is automatical-
ly generated by HAM. It is always equal to
the TRN (tag 20).
111 Service type {111:3!n} This field identifies the applicable global
identifier payment service type.
PM:

User Header

tions
Use in MT 103, MT 103+, MT 202, MT 202
COV, MT 204.
HAM:
HAM does not forward this field even if it is
present in the message sent to HAM.
Note: Participants must be able to receive
field 111 even if they are no member of the
GPI closed user group. In case field 111 is
present, field 121 is present too.

User Header

tions
121 Unique end-to- {121:36!x} This field provides an end-to-end reference

end transaction across a payment transaction.
reference PM:
Use in MT 103, MT 103+, MT 202, MT 202
COV, MT 204.
HAM:
HAM does not forward this field even if it is
present in the message sent to HAM.
Note: Participants must be able to receive
field 121 even if they are no member of the
GPI closed user group. In case field 121 is
present, field 111 is present too.
119 Validation Flag {119:8c} Use in MT 103: The participant may request
SWIFT validation according to the rules of
the MT 103+ by using {119:STP}. If this field
is not available, MT 103 core will follow.
Use in MT 202 COV:
The placement of field 119 with code COV is
mandatory.
{119: REMIT} is not allowed in SSP.
HAM:
If used by the sender of the message, it will
be present in messages received by CB
customers.
115 Addressee In- {115: This field is present when the receiver re-
formation HHMMSS ceives this message via Y-copy service. This
HHMMSS is synonymous with settling the payment in
2!a the PM.
16x} It contains information from the PM:

User Header

tions
• Time of crediting RTGS account of re-

ceiver
• Time of debiting RTGS account of sender
• Country code of sender
• SSP internal posting reference for unique
identification
Credit and debit time are same for payments
inside PM and between PM and HAM or
proprietary home accounting system.
HAM:
Not present in messages received by HAM
account holders and CB customers.
14.1.2.1.2 Trailer
14.1.2.1.2.1 General description

General infor- The trailer of a message differs according to the following cases:
mation
• the participant sends a message to the SWIFT network,
• the participant receives a message from the SWIFT network via Y-copy
or
• the participant receives a message from the SWIFT network, but not via
Y-copy.
All fields in the trailers are put in braces ({}).
Note: The individual fields (tags) of the trailers are described in detail in the
SWIFT User Handbook “FIN System Messages“.

Structure when The following table describes the trailers when the participant sends the
sending a message to the SWIFT network. (It is an outgoing payment from the partici-
message pant’s point of view.)
Trailer
Status Tag Field name Content/ Use in SSP

Options
- - Block Identi- 5: -
fier
M MAC Authentica- {MAC:8!h} -

tion Code
M PAC Proprietary {PAC:8!h} -

Authentica-
tion Code
M CHK Checksum {CHK:12!h} -
O TNG Training {TNG:} Only in test and training mode.
O PDE Possible {PDE:[<time> -

Duplicate <mir>]}
Emission
Structure when The following table describes the trailers when the participant receives a
receiving a payment message from the SWIFT network. (It is an incoming payment via
message via Y-copy from the participant’s point of view, User Header contains
Y-copy {103:TGT}.)
Trailer

Options

Trailer

Options
fier
M MAC Authentica- {MAC:8!h} -

tion Code
M PAC Proprietary {PAC:8!h} -

Authentica-
tion Code
O TNG Training {TNG:} Only in test and training mode.

Duplicate <mir>]}
Emission
O PDM Possible {PDE:[<time> -

Duplicate <mor>]}
Message
O DLM Delayed {DLM:} -

Message
Structure when The following table describes the trailers when the participant receives a
receiving a message via the SWIFT network from the SSP. (It is an incoming message
message via from the participant’s point of view, no Y-copy.)
normal FIN
(no Y-copy)
Trailer

Options
fier

Trailer

Options
O MAC Authentica- {MAC:8!h} -

tion Code
O TNG Training {TNG:} Only in test and training mode

Duplicate <mir>]}
Emission
O PDM Possible {PDM:[<time -

Duplicate ><mor>]}
Message
O DLM Delayed {DLM:} -

Message
14.1.2.1.2.2 Handling of PDM/PDE Trailer
PDM Trailer (Pos- PDM trailer is set by SWIFT. It is used to warn the receiver that the same
sible Duplicate message may already have been delivered by the SWIFT. The reason for
Message Trailer) sending a message with PDM trailer is, that SWIFT does not know whether
the payment message was already sent.
If PM or HAM receives a message it checks in addition to the double entry
check whether the payment message is delivered twice (without PDM trailer
and with PDM trailer):
• If the payment message without PDM trailer was already delivered then
the message with the PDM trailer will be discovered by PM or HAM. It will
get a final status (“closed - duplicate input“) without any further pro-
cessing. The message with PDM trailer will not be delivered to the re-
ceiver.

• If the payment message without PDM trailer was not yet delivered then
the message with the PDM trailer will be processed and delivered to the
receiver after settled successfully.
• If the message without PDM trailer is delivered after the message with
the PDM trailer it will be discovered by PM or HAM and will get a final
status (“closed - duplicate input“) without any further processing. It will
not be delivered to the receiver.
PDE Trailer (Pos- PDE trailer is set by the sender of the message. It is used to warn the re-
sible Duplicate ceiver that the same message may already have been received. The reason
Emission Trailer) for sending a message with PDE trailer is that the sender is not sure,
whether the payment message was already sent.
If PM receives a message it checks in addition to the double entry check
whether the message is delivered twice (without PDE trailer and with PDE
trailer):
• If the original payment message (without PDE trailer) was already deliv-
ered, the message with PDE trailer will be discovered by PM. It will be re-
jected. PM will send a negative MT 097 to SWIFT and consequently the
sender will receive an MT 019 with a unique error code.
Note: In case of PDE trailer HAM will behave as in case of PDM trailer.

Example:
PDE processing
- payment message (without PDE trailer) was already delivered
-
SWIFTNet FIN
1 MT 103/103+&/202 COV/
204 4 MT 103/103+/202 COV/204
Bank A Bank B
MT 103/103+/202 COV/204
6 (PDE)
2 MT 096
7 MT 096 (PDE)
3 MT 097
8 neg. MT 097
9
MT 019
PM
Participant Interface (Y-copy)
PDM/PDE processing
first message
second message
Step Description
1 Bank A sends a payment message to PM
2 SWIFT delivers the settlement request (MT 096) to PM
3 PM checks whether the same payment message with PDE trailer already arrived.
Because it is not the case PM settles the payment, creates a positive settlement

Step Description
confirmation (MT 097) and sends it to SWIFT
4 SWIFT delivers the payment message to Bank B
5 If Bank A requested to receive a sender notification (MT 012) it will be delivered by

SWIFT
6 Bank A sends the same payment message with PDE trailer
7 SWIFT delivers the MT 096 with PDE trailer to PM
8 PM recognises that the message was already received without PDE trailer and
creates a negative MT 097 with a unique error code
9 Consequently SWIFT sends an MT 019 containing the error code to Bank A.
• If the payment message without PDE trailer was not yet delivered, the
message with the PDE trailer will be processed in PM and delivered to
the receiver after settled successfully.

Example:
PDE processing with positive MT 097

- original payment message is not yet delivered -
SWIFTNet FIN
Bank A Bank B
1 MT 103/103+/202 COV/204 4 MT 103/103+/202 COV/204
(PDE) (PDE)
2 MT 096 (PDE)
3 MT 097
5 MT 012 (PDE) (opt.)
PM
PDM/PDE processing
first message
second message
Step Description
1 Bank A sends a payment message with a PDE trailer to PM
2 SWIFT delivers the settlement request (MT 096) with PDE trailer to PM

Step Description
3 PM checks whether the payment message without PDE trailer already arrived.
Because it is not the case PM settles the payment, creates a positive settlement
confirmation (MT 097) with PDE trailer and sends it to SWIFT
4 SWIFT delivers the payment message with the PDE trailer to Bank B, which has to
check in the result if he has already received the original message (see SWIFT-
User Handbook FIN Service Description, Chapter 5 Message Structures 5.10.5)
5 If requested SWIFT sends a sender notification (MT 012) to Bank A
• If the payment message (without PDE trailer) is delivered after the mes-
sage with the PDE trailer then the message without the PDE trailer will
be discovered by PM. It will create a negative settlement confirmation
(MT 097).

Example:
PDE processing with positive MT 097

- original payment message is not yet delivered -
SWIFTNet FIN
9 MT 019
1 MT 103/103+/202 COV/204
Bank A Bank B
5 MT 103/103+/202 COV/204
2 MT 103/103+/202 COV/204 (PDE)
(PDE)
7 MT 096 (PDE)
3 MT 096 (PDE)
4
6 MT 012 (opt.)
MT 097
neg. MT 097 PM
PDM/PDE processing
first message
second message
Step Description
1 Bank A sends a payment message to PM
2 After a while Bank A sends the same payment message with PDE trailer
3 SWIFT delivers the settlement request (MT 096) with PDE trailer to PM
4 PM checks whether the same payment message without PDE trailer already ar-

Step Description
rived. Because it is not the case, PM settles the payment with PDE trailer and
creates a positive settlement confirmation (MT 097) with PDE trailer
5 SWIFT delivers the payment message with the PDE trailer to Bank B, which has to
check whether it has already received the payment message without PDE trailer
(see SWIFT-User Handbook FIN Service Description, Chapter 5 Message Struc-
tures 5.10.5)
6 If requested SWIFT sends a sender notification (MT 012) to Bank A
7 In the meantime SWIFT creates an MT 096, which is based on the payment mes-
sage without PDE trailer (see step 1)
8 PM checks whether the same payment message without PDE trailer already ar-
rived. Because it is the case, PM creates a negative settlement confirmation (MT
097) with a unique error code
9 SWIFT sends an Abort Notification (MT 019) with a unique error code to Bank A

14.1.2.2 Textblock of the different message types
14.1.2.2.1 Payment messages
14.1.2.2.1.1 MT 103
Usage This message type is used to execute a payment order if the ordering party
or the beneficiary, or both, are non-financial institutions.
In the following table the standard validation profile for MT 103 is described.
The STP validation profile (MT 103+) is separately described (see chapter
14.1.2.2.1.2 MT 103+, page 98).
HAM Operations settled through “CB customer’s accounts“ can be triggered via
“MT 103“:
• payments of CB customers to and from RTGS accounts
• payments between CB customer’s accounts, in the same central bank or
in different central banks
Structure The following table describes the structure of MT 103 (standard format)
used in SSP:
SWIFT standard SSP Specifications
Status Field Field name Status Format Use in SSP
M 20 Sender’s M 16x
Reference
--->
O 13C Time Indica- O /8c/4!n1!x 4!n PM:

tion The following codes in addition to
the SWIFT standard can be used
to set an execution time:
• /TILTIME/hhmm+/-iinn

• /FROTIME/hhmm+/-iinn
• /REJTIME/hhmm+/-iinn
hhmm must be before the cut-off
time for customer payments (17.00
under normal circum-stances)
Note: This field has to be filled in
according to the SWIFT standard. ii
and nn are the hours and minutes
of UTC shift whereas the “hhmm“
are to be filled with the local time of
the user. This is valid for the code-
words TILTIME, REJTIME and
FROTIME.
If TILTIME and REJTIME are both
mentioned only the first one is
used by SSP.
However, the codeword / CLS-
TIME/ has to be used in field 72
and not according to the SWIFT
standard in field 13C.
HAM:
In the outgoing messages it con-
tains the Settlement Time.
The format is:
• /SNDTIME/hhmm+iinn
Note: ii and nn are the hours and
minutes of UTC shift t
----|
M 23B Bank Opera- M 4!c

tion Code

---->
O 23E Instruction O 4!c[/30x]

Code
----|
O 26T Transaction O 3!c

Type Code
M 32A Value Date/ M 6!n3!a15d Payments can be sent for the cur-
Currency/ rent business day and up to five
Interbank TARGET working days in advance.
Settled Payments must be denominated in
Amount euro only.
Exception:
Value date check is switched off for
the sender‘s RTGS account by the
responsible CB or SSP-OT.
O 33B Currency/ O 3!a15d Network Validated Rules in SWIFT

Instructed User Handbook.
Amount
O 36 Exchange O 12d If the currency code is different

Rate from the currency code in field
32A, field 36 must be present,
otherwise field 36 is not allowed.
M 50a Ordering M Option A:

Customer [/34x]4!a2!
a2!c[3!c]
Option F:
35x4*35x
Option K:
[/34x]4*35x

O 51A Sending - - Must not be used

Institution
O 52a Ordering O Option A: HAM:

Institution [/1!a][/34x] In the outgoing message it con-
4!a2!a2!c[3! tains:
c] • On the first line: the BIC of the
Option D: account debited and the TRN of
the incoming message.
[/1!a][/34x]
4*35x • On the second line: the BIC
mentioned in the incoming 52A
(if present), else the BIC of the
sender of the incoming mes-
sage.
Format: //HAM<BIC><TRN>
<BIC>.
O 53a Sender’s O Option A: HAM:

Correspond- [/1!a][/34x] If the sender is a central bank, the
ent 4!a2!a2!c[3! 53a (with option A) has to contain
c] the BIC of a CB’s customer to be
Option B: debited.
[/1!a][/34x]
[35x]
Option D:
[/1!a][/34x]
4*35x
O 54a Receiver’s O Option A:

Correspond- [/1!a][/34x]
ent 4!a2!a2!c[3!
c]
Option B:
[/1!a][/34x]


[35x]
Option D:
[/1!a][/34x]
4*35x
O 55a Third Reim- O Option A:

bursement [/1!a][/34x]
Institution 4!a2!a2!c[3!
c]
Option B:
[/1!a][/34x]
[35x]
Option D:
[/1!a][/34x]
4*35x
O 56a Intermediary O Option A: Only option A is allowed. Other

Institution [/1!a][/34x] options are rejected.
4!a2!a2!c[3! HAM:
c] When present identifies the ac-
count to be credited. In addition, if
tag 57a is used in option D, tag
56a becomes mandatory, on the
contrary, when tag 57a is used in
option A tag 56a is optional.
O 57a Account With O Option A: Only option A or D is allowed.

Institution [/1!a][/34x] Other options are rejected.
4!a2!a2!c HAM:
[3!c] The tag is mandatory for HAM. If
Option D: tag 56a is not present tag 57a
[/1!a][/34x] specifies the account to be credited
4*35x and must be used with option A.
On the contrary option D is accept-


ed only if the field 56A is present.
M 59A Beneficiary M Option A:

Customer [/34x]
4!a2!a2!c
[3!c]
Option F:
[/34x]
4*(1!n/33x)
no letter
option:
[/34x] 4*35x
M 70 Remittance M 4*35
Information
M 71A Details of M OUR / SHA /

Charges BEN
---->
O 71F Sender’s O 3!a15d

Charges
----|
O 71G Receiver’s O 3!a15d

Charges

O 72 Sender to O 6*35x HAM:

Receiver In case field 52D is used in original
Information MT 103 the related information are
provided as follows:
• /INS/ “content of field 52D“, if
enough space is available.
For outgoing messages, in case of
rejection, it contains the following
code words providing details about
the reason for the rejection.
The format is:
• /REJT/ followed by the identifi-
cation of the field causing the
reject or /RETN/ followed by the
identification of the field caus-
ing the return (used for incom-
ing payments from PM and di-
rected to CB customers; if a
payment is rejected in HAM for
any reason, a reverse payment
is sent from HAM to PM).
• Reason Code, followed by a
text description of the preced-
ing reason code.
• /MREF/ Sender’s Reference, ie
field 20 of the original message
(Transaction Reference Num-
ber of File Reference).
O 77B Regulatory O 3*35x

Reporting
O 77T Envelope - 9000z Must not be used

Contents

14.1.2.2.1.2 MT 103+
Usage This message type is used to execute a payment order if the ordering party
or the beneficiary, or both, are non-financial institutions.
In the following table the STP validation profile of MT 103+ is described.
The standard validation profile (MT 103) is described separately (see chap-
ter 14.1.2.2.1.1 MT 103, page 91).
HAM Operations settled through “CB customer’s accounts“ can be triggered via
“MT 103+“:
Structure The following table describes the structure of MT 103+ (STP format) used in
SSP:
M 20 Sender‘s M 16x
Reference
--->



time for customer payments (17.00
under normal circumstances)
according to the SWIFT standard.
ii and nn are the hours and minutes
FROTIME.
used by SSP.
However, the codeword /CLSTIME/
has to be used in field 72 and not
according to the SWIFT standard
in field 13C.
HAM:
tains the Settlement Time.
The format is:
minutes of UTC shift
----|
M 23B Bank Opera- M 4!c

tion Code
-->
O 23E Instruction O 4!c[/30x] Only the codewords

Code • CORT

• INTC
• SDVA
• REPA
are allowed.
----|
O 26T Transaction O 3!c

Type Code
M 32A Value Date/ M 6!n3!a15d Payments can be sent for the cur-
Currency/ rent business day and up to five
Interbank TARGET working days in advance.
Settled Payments must be denominated in
Amount euro only.
Exception:
Subsequent delivery of individual
O 33B Currency/ O 3!a15d Network Validated Rules in SWIFT

Instructed User Handbook.
Amount
O 36 Exchange O 12d If the currency code is different

Rate from the currency code in field
32A, field 36 must be present,
otherwise field 36 is not allowed.

a2!c[3!c]
Option F:


35x
4*35x
Option K:
[/34x]4*35x
O 52A Ordering O Option A: HAM:

Institution [/1!a][/34x] In the outgoing message it con-
4!a2!a2!c[3! tains on the first line: the BIC of the
c] account debited and the TRN of
On the second line: the BIC men-
tioned in the incoming 52A (if pre-
sent, else the BIC of the sender of
the incoming message)
Format:
//HAM<BIC><TRN>
<BIC>
O 53a Sender’s O Option A: HAM:

Correspond- [/1!a][/34x] If the sender is a central bank, the
ent 4!a2!a2!c[3! 53a (with option A) has to contain
c] the BIC of a CB’s customer to be
Option B: debited
[/1!a][/34x]
[35x]
O 54A Receiver’s O Option A:

Correspond- [/1!a][/34x]4!
ent a2!a2!c[3!c]
O 55A Third Reim- O Option A:

bursement [/1!a][/34x]4!
Institution a2!a2!c[3!c]
O 56A Intermediary O Option A: HAM:


Institution /1!a][/34x] When present identifies the ac-
4!a2!a2!c[3! count to be credited.
c]
O 57A Account With O Option A: HAM:

Institution [/1!a][/34x]4! The tag is mandatory for HAM. If
a2!a2!c[3!c] tag 56a is not present tag 57a
specifies the account to be credit-
ed.
M 59a Beneficiary M Option A: An account line must be stated.

Customer [/34x]4!a2!a2
!c[3!c]
Option F:
[/34x]
4*(1!n/33x)
no letter
option:
[/34x]4*35x
O 70 Remittance O 4*35x
Information
M 71A Details of M OUR /

Charges SHA /
BEN
--->
O 71F Sender‘s O 3!a15d

Charges
---|

O 71G Receiver’s O 3!a15d

Charges
O 72 Sender to O 6*35x Code words REJT and RETN or

Receiver ERI details are not allowed.
Information
O 77B Regulatory O 3*35x

Reporting
14.1.2.2.1.3 MT 202
Usage This message type is used to transfer credit balances between financial in-
stitutions.
HAM Operations settled in the HAM accounts can be initiated via “simplified MT
202“ (= an MT 202 message with a limitation in the format):
• HAM to HAM payments
• cash withdrawals
• HAM to PM payments
• PM to HAM payments
The message must quote dedicated HAM BIC in block 2 (receiver). Only
Tag 58a (Beneficiary Institution) is used to identify the creditor institution.
The latter is the addressee of the MT 202 message which the HAM sends to
notify the transaction (not in case of Internet-based participant).
A co-management agreement can be reached between the holder of an
RTGS account (co-manager) and a holder of a HAM account (co-managed).
The institution quoted in Tag 53a (Sender’s Correspondent), is the debtor.
Only Tag 58a (Beneficiary Institution) is used to identify the creditor institu-

tion. If co-management agreement between the sender and the institution

quoted in Tag 53a is not known the message is rejected. The home CB is
always co-manager of all the HAM accounts of their credit institutions.
The tag 57a has to be filled with the BIC of the home CB if the followed field
58a contains the BIC code of a PM participant.
Operations settled through “CB customer’s accounts“ can be triggered via
“standard MT 202“:
The receiver of the outgoing message is equal to tag 56a of the incoming
message, if specified, otherwise to tag 57a, if specified, or at last to tag 58a.
Structure The following table describes the structure of the MT 202:

Note: The incoming messages linked to AS settlement must be sent with
the priority "highly urgent" and with the current business day, same is true
for liquidity transfers with T2S.
M 20 Transaction M 16x HAM:

Reference The incoming message must be
Number unique for sender, date (32A) and
TRN. In the outgoing message it is
an SSP progressive number.
M 21 Related M 16x PM:

Reference for outgoing messages linked to
AS settlement: copy of EndToEn-
dIdentification contained in Pay-
mentTransaction
For liquidity transfers with T2S:


Copy to or from EndToEndIdentifi-
cation of the XML message ex-
changed with T2SS
HAM:
In the outgoing message it is equal
to tag 21 of the incoming message.
--->
O 13C Time Indica- O /8c/4!n1!x PM:

tion 4!n The following codes in addition to
time for bank-to-bank payments
(18.00 under normal circumstanc-
es) and in case of messages ad-
dressed to TRGTXEPMT2S also
before the cut-off time for liquidity
transfers to T2S (17.45 under nor-
mal circumstances).
Note:
• For incoming messages
linked to the liquidity credit
transfer to technical account
– procedure 6 – real-time in
AS settlement: the authorised
codes are
– /FROTIME/hhmm+/-iinn
– /REJTIME/hhmm+/-iinn

• For outgoing messages

linked to AS settlement: not
relevant
FROTIME.
used by SSP.
For incoming messages ad-
dressed to TRGTXEPMT2S:
• F13C settlement times are only
accepted during day trade
phase
• F13C settlement times cannot
be processed in case of Pull Li-
quidity from T2S
However, the codeword /CLSTIME/
has to be used in field 72 and not
according to the SWIFT standard
in field 13C.
HAM:
tains the settlement time. The
format is:


minutes of UTC shift.
---|
M 32A Value Date, M 6!n3!a15d Payments can be sent for the cur-
Currency rent business day and up to five
Code, TARGET working days in advance.
Amount Payments must be denominated in
euro only.
PM:
Exceptions:
• Value date check is switched
off for the sender‘s RTGS ac-
count by the responsible CB or
SSPOT.
• Messages with future value
date may not be addressed to
TRGTXEPMT2S. Warehoused
liquidity transfers to T2S are not
supported. (Standing orders
may be used/adjusted instead.)
ASI:
Exceptions:
TRGTXEPMASI. Warehoused
liquidity transfers to ASI are not
supported.
HAM:
Exceptions:
TRGTXEPMHAM. Warehoused
liquidity transfers to HAM are
not supported.

52a Ordering O Option A: PM:

Institution [/1!a][/34x] • For incoming messages
4!a2!a2!c[3! linked to AS settlement: may
c] be used to pass on information
on the debtor.
Option D:
[/1!a][/34x]4* • For outgoing messages
linked to AS settlement: If a
35x
valid BIC is indicated as debtor
in the ASTransferInitiation.
Option A: Copy of the account
(adjusted to format /34x) from
the Debt-or Account (if filled)
and copy of the BIC indicated
as debtor. If no BIC is indicat-
ed as debtor the field 52A will
be empty.
(payments from HAM): BIC of
the debtor in HAM.
• For incoming messages ad-
dressed to TRGTXEPMT2S to
initiate liquidity transfers
with T2S:
– If used option A is mandato-
ry and a valid BIC of an
RTGS account holder has
to be indicated and option-
ally the related RTGS ac-
count ID
• For outgoing messages due
to liquidity transfers from
T2S:
– Option A is used by default.
Filled with Dedicated Cash
Account ID received from


T2S and related account
owner BIC
– Option D will be used if the
DCA ID received from T2S
is unknown in TARGET2.
The account ID and con-
stant "unknown DCA owner"
will be mentioned.
HAM:
For all outgoing messages it con-
tains
• on the first line: the BIC of the
account debited and the TRN of
• on the second line: the BIC
mentioned in the incoming 52A
(if present, else the BIC of the
sender of the incoming mes-
sage).
• Format:
//HAM<BIC><RN>
<BIC>
O 53a Sender’s O Option A: PM:

Correspond- [/1!a][/34x]4! For outgoing messages (payments
ent a2!a2!c[3!c] from HAM) it contains the BIC of
Option B: the debtor’s CB.
[/1!a][/34x] Must not be filled in messages
[35x] linked to ancillary system settle-
ment.
Option D:
[/1!a][/34x] For incoming messages addressed
4*35x to TRGTXEPMT2S used to pull
liquidity from the indicated DCA in
T2S: Option A with the BIC of the


DCA holder and the DCA ID to be
debited is mandatory.
HAM:
If the sender is a central bank, the
53a (with option A) has to contain
the BIC of a CB’s customer to be
debited.
O 54a Receiver’s O Option A: PM:

Correspond- [/1!a][/34x]4! Must not be filled in messages
ent a2!a2!c[3!c] linked to ancillary system settle-
Option B: ment.
[/1!a][/34x][3 Must not be used in messages
5x] addressed to TRGTXEPMT2S.
Option D:
[/1!a][/34x]
4*35x

[/1!a][/34x] options are rejected.
4!a2!a2!c[3! PM:
c] Must not be filled in messages
linked to ancillary system settle-
ment
Must not be used in messages
addressed to TRGTXEPMT2S.
HAM:
When present identifies the ac-
count to be credited.

O 57a Account With O Option A: Only option A is allowed. Other

4!a2!a2!c[3! PM:
c]
• For incoming messages
linked to AS settlement:
mandatory for the real-time
model; it must be the BIC of a
technical account – procedure
6 – real-time linked to the
sender (settlement bank) not
filled for the interfaced model
linked to AS settlement: not
filled
• Must not be used in messages
addressed to TRGTXEPMT2S.
HAM:
If tag 56a is not present tag 57a
specifies the account to be credited
and must be used with option A.
When tag 58a is used in option D
tag 57A it becomes mandatory.
When tag 58a is used in option A
tag 57a is optional.
M 58a Beneficiary M Option A: PM:

Institution [/1!a][/34x] • For incoming messages
4!a2!a2!c[3! linked to AS settlement: may
c] be used to pass on information
on the creditor in the AS. For
Option D: the interfaced AS Option A only
[/1!a][/34x] is allowed (BIC of the RTGS
4*35x account of the sender and sub-
account of this RTGS account)


linked to AS settlement:
If a valid BIC is indicated as
creditor in the ASTransferInitia-
tion
Option A:
Copy of the account (adjusted
to format /34x) from the Cred-
itorAccount (if filled) and Copy
of the BIC indicated as Creditor
If no BIC is indicated as
Creditor, the field 58A will be
filled only with the BIC of the
FinalAgent
• For incoming messages ad-
Option A is mandatory
– BIC of the DCA holder and
the DCA ID to be credited
(push liquidity),
– Or BIC of the RTGS ac-
count to be credited (pull li-
quidity).
• For outgoing messages due
to liquidity transfers from
T2S:
BIC of the RTGS account cred-
ited due to incoming liquidity
transfer from T2S.
• For outgoing messages (pay-
ments from HAM) it contains
the BIC of the creditor in PM.
Exception: For outgoing mes-
sages from co-managed HAM
account to RTGS account of
co-manager it contains the BIC
of the co-managed HAM ac-
count owner (debtor in HAM).

HAM:
If field 56A and 57A are not pre-
sent, it is the BIC of the account to
be credited.
Option D is accepted only if field
57A is present.
O 72 Sender to O 6*35 PM:

Receiver /BUP/ = codeword to indicate
Information backup payments.
/CLSTIME/hhmm
If hhmm is present it must be be-
fore the cut-off time for bank-to-
bank payments (18.00 under nor-
mal circumstances). Automatic
notification is triggered via ICM 15
minutes prior the defined time. But
note that codeword CLSTIME is
ignored by SSP, if codeword
TILTIME or REJTIME is used in
field 13C.
/MANPAY/ = codeword to indicate
a mandated payment
Note: For ASI, the codeword /
ASINF/ must be added before /
MANPAY/).
/INS/ followed by BIC of the tech-
nical account – procedure 6 – real-
time from FirstAgent field = code-
word used in outgoing payments
linked to AS settlement /ASDB/
(Debtor Name or, if neither Debtor
BIC nor Debtor Name present in
the ASTransferInitiation message,


Debtor Domestic Account)
/ASCR/ (Creditor Name or, if nei-
ther Creditor BIC nor Creditor
Name present in the ASTransferI-
nitiation message, Creditor Domes-
tic account)
[The Debtor Name (70x) and
Creditor Name (70x) are truncated
to 62 characters]
/ASINF/ + optional free text =
codeword used in incoming and
outgoing payments linked to AS
settlement
/ESCBSTAT / followed by “2I“ for
setting up or reimbursement of
repo operations with the central
bank for intraday credit
For incoming messages ad-
The only codeword that may be
used is /MANPAY/. Other codes
must not be used.
HAM:
In case field 52D is used in original
MT 202 the related information are
provided as follows:
the reason for the rejection. The


format is:
ing reason code.
Note: Unless otherwise stated, fields related to incoming messages linked

to AS settlement are mapped to the ASTransferNotice message sent by ASI
to the AS and fields related to outgoing messages linked to AS settlement
are mapped from the ASTransferInitiation sent by the AS to the ASI.
14.1.2.2.1.4 MT 202 COV
Usage This message type is used to transfer credit balances between financial in-
stitutions.
It must only be used to order the movement of funds related to an underly-
ing customer credit transfer that was sent with the cover method.
The MT 202 COV must not be used for any other interbank transfer or li-
quidity transfer addressed to any PM BIC (eg TRGTXEPMT2S). For these
transfers the MT 202 must be used.

MT 202 COV in connection with HAM can be used only for CB customer
transactions.
Structure The MT 202 COV consists of two sequences

• Sequence A - General Information which contains information on the fi-
nancial institution transfer between the ordering institution and benefi-
ciary institution and
• Sequence B - Underlying Customer Credit Transfer is used to provide
details on an individual underlying customer credit transfer that was sent
with the cover method.
Note: Sequence B is not displayed in ICM.
The following table describes the structure of the MT 202 COV:
Sequence A General Information
M 20 Transaction M 16x
Reference
Number
M 21 Related M 16x
Reference
--->



es)
according to the SWIFT standard.
ii and nn are the hours and minutes
FROTIME.
used by SSP.
However, the codeword / CLS-
TIME/ has to be used in field 72
and not according to the SWIFT
standard in field 13C.
---|
euro only.
PM:
Exception:
HAM:
Exception:


Messages with future value date
may not be addressed to
liquidity transfers to HAM are not
supported.
O 52a Ordering O Option A:

Institution [/1!a][/34x]
4!a2!a2!c
[3!c]
Option D:
[/1!a][/34x]
4*35x
O 53a Sender's O Option A:

ent 4!a2!a2!c
[3!c]
Option B:
[/1!a][/34x]
[35x]
Option D:
[/1!a][/34x]
4*35x
O 54a Receiver's O Option A:

ent 4!a2!a2!c
[3!c]
Option B:
[/1!a][/34x]
[35x]
Option D:
[/1!a][/34x]


4*35x

[/1!a][/34x] options are rejected
4!a2!a2!c
[3!c]

4!a2!a2!c
[3!c]
M 58a Beneficiary M Option A:

4!a2!a2!c
[3!c]
Option D:
[/1!a][/34x]
4*35x
O 72 Sender to O 6*35x PM
Receiver /BUP/ = codeword to indicate
Information backup payments.
/CLSTIME/hhmm
If hhmm is present it must be be-
fore the cut-off time for bank-to-
bank payments (18.00 under nor-
mal circumstances). Automatic
notification is triggered via ICM 15
minutes prior the defined time. But
note that codeword CLSTIME is
ignored by SSP, if codeword
TILTIME or REJTIME is used in
field 13C.
/MANPAY/ = codeword to indicate
a mandated payment.

Sequence B underlying customer credit transfer details

a2!c[3!c]
Option F:
35x4*35x
Option K:
[/34x]4*35x
O 52a Ordering O Option A:

4!a2!a2!c
[3!c]
Option D:
[/1!a][/34x]
4*35x
O 56a Intermediary O Option A:

4!a2!a2!c
[3!c]
Option C:
/34x
Option D:
[/1!a][/34x]
4*35x
O 57a Account With O Option A:

4!a2!a2!c
[3!c]
Option B:


[/1!a][/34x]
[35x]
Option C:
/34x
Option D:
[/1!a][/34x]
4*35x
M 59a Beneficiary M Option A:

Customer [/34x]
4!a2!a2!c
[3!c]
Option F:
[/34x]
4*(1!n/33x)
no letter
option:
[/34x] 4*35x
O 70 Remittance O 4*35x
Information
O 72 Sender to O 6*35x
Receiver
Information
O 33B Currency/ O 3!a15d

Instructed
Amount

14.1.2.2.1.5 MT 202 simplified (HAM only)

Structure The following table describes the structure of the MT 202 simplified:
M 20 Transaction M 16x The incoming message must be

Reference unique for sender, date (32A) and
Number TRN. In the outgoing message it is
an SSP progressive number.
M 21 Related M 16x In the outgoing message it is equal

Reference to tag 21 of the incoming message.
---->
O 13c Time Indica- O /8c/4!n1!x 4!n In the outgoing messages it con-

tion tains the settlement time.
The format is:
minutes of UTC shift.
euro only.
Exception:
Messages with future value date
may not be addressed to
liquidity transfers to HAM are not
supported.
O 52a Ordering O Option A: In the incoming message it is not

Institution [/1!a][/34x] allowed. For all outgoing messages


4!a2!a2!c it contains
[3!c] • on the first line: the BIC of the
account debited and the TRN of
• on the second line: the BIC of
the sender of the incoming
message
Format:
//HAM<BIC><TRN>
<BIC>
O 53a Sender’s O Option A: If specified it contains the BIC of

Correspond- [/1!a][/34x] the account to be debited. The
ent 4!a2!a2!c sender must be an authorised
[3!c] participant (co-manager or CB).
O 54a Receiver’s O Option A: Not allowed

ent 4!a2!a2!c
[3!c]
O 56a Intermediary O Option A: Not allowed

[/1!a][/34x]
4!a2!a2!c
[3!c]

O 57a Account With O Option A: It is present only for liquidity trans-

Institution [/1!a][/34x] fers from HAM account to RTGS
4!a2!a2!c account in PM. It has to be filled
[3!c] with the BIC of the home CB, fol-
lowed in field 58A with the BIC
code of the PM participant.
M 58a Beneficiary M Option A: It contains the account to be cred-

Institution [/1!a][/34x] ited.
4!a2!a2!c For HAM to HAM and PM to HAM
[3!c] payments it is the HAM creditor
BIC. For HAM to PM payment it is
the BIC of the PM participant.
Only option A
O 72 Sender to O 6*35x HAM:

Receiver In case field 52D is used in original
Information MT 202 simplified the related in-
formation are provided as follows:
the reason for the rejection.
The format is:


ing reason code.

14.1.2.2.1.6 MT 204
Usage This message type is used by banks, central banks and ancillary systems to
withdraw money from the account of counterparties that agreed on in ad-
vance.
The sender of the message is the creditor and the receiver is the debtor.
In case of an Internet-based direct participant as receiver (receiver in the
header of the SWIFT message is "TRGTXEPMLVP" and BIC of Internet-
based direct participant is quoted in field 53 of sequence B) repetitive se-
quence B can only be used once.
This message cannot be used to pull liquidity from a Dedicated Cash Ac-
count in T2S. To initiate such a transfer an MT 202 has to be used.
Sequence A Common Elements - Reimbursement Details
Reference
Number
M 19 Sum of M 17d The amount in field 19 must be

Amounts equal to the sum of the amounts in
all fields 32B. This is the amount
actually settled.
M 30 Value Date M YYMMDD The date can be the current busi-

ness day or up to five TARGET
working days in advance.



4!a2!a2!c
[3!c]
O 58a Beneficiary O Option A:

4!a2!a2!c
[3!c]
Option D:
[/1!a][/34x]
4*35x
O 72 Sender to O 6*35x PM:

Receiver The following codes can be used to
Information set an execution time:
es)
words TILTIME, REJ-TIME and
FROTIME.
used by SSP. /ESCBSTAT/ code
followed by “2I“ to be used for


setting up or reimbursement of
repo operations with the central
bank for intraday credit.
----> Repetitive Sequence B - Transaction Details
Reference
Number
O 21 Related O 16x
Reference
M 32B Transaction M 3!a15d The currency must always be euro.

Amount
M 53a Debit Institu- M Option A:

tion [/1!a][/34x]
4!a2!a2!c
[3!c]
Option B:
[/1!a][/34x]
[35x]
Option D:
[/1!a][/34x]
4*35x
O 72 Sender to O 6*35x
Receiver
Information
----|

14.1.2.2.2 Cash flow management messages
14.1.2.2.2.1 MT 900
Usage This message type is used to show the account holder the debit entry in the
• RTGS account in PM as a consequence of a liquidity operation, a backup
payment made by the account holder, a payment instruction sent by an
ancillary system, mandated payment or a liquidity transfer to T2S not ini-
tiated via MT 202 or camt.050 sent by the account holder himself (ie
standing orders, ICM current orders, MT 202 Mandated Payments or
camt.050 sent by another entity on behalf).
• sub-account of an RTGS account in PM as a consequence for a liquidity
operation or a payment instruction sent by an ancillary system.
• HAM account.
The message is sent out after debiting took place on the respective account.
The booking is confirmed again on the account statement. Debit entries
from payments processed via the FIN-copy service of Payments Module
(PM) are not confirmed with MT 900. When FIN-copy is not used, issuing of
MT 900 is optional (a global parameter can be selected by the participant
and a special parameter for T2S related business).
HAM HAM sends, if requested, an MT 900 message to the debtor and to the co-
manager (and to CB too, if it is not the debtor but the sender of a generated
payment.)
M 20 Transaction M 16x For payments linked to AS: The

Reference TRN is built with “AS“ followed by
Number
(ddhhmmss) and the last 6 digits of


the PM transaction reference
(nnnnnn):
“ASddhhmmssnnnnnn“
For all other payments:
The SSP Business Case ID (up
to 16 numeric characters)
M 21 Related M 16x Content of field 20 (in case of di-

Reference rect debit field 21)
For payments linked to AS settle-
ment:
• Execution of Standing orders
and current orders sent via
ICM screens (U2A):
Internal SSP reference
• Execution of LiquidityCredit-
Transfer and SBTransferIniti-
ation sent in A2A via ICM:
Copy of MessageIdentification
• Back Transfer of liquidity
ordered with End of Proce-
dure:
Copy of BusinessInformation-
Reference of the Return-
GeneralBusinessInformation
message or 'NONREF' if End of
procedure is triggered on ICM.
• End of Procedure by SSP at
End of Business day:
Related internal reference at-
tributed by the SSP specifically
to each AS for the procedure
which has to be closed by the
SSP.
• Other cases: Copy of
EndToEndIdentification con-


tained in the ASTransferInitia-
tion messages
For liquidity transfers to T2S:
• Initiated via XML message
LiquidityCreditTransfer:
Copy of EndToEndIdentification
• Initiated via MT 202:
Copy of field 21
• Execution of standing or-
ders:
SSP Business Case ID
• Current orders sent via ICM
screens (U2A):
End-to-end identification, if en-
tered; else: SSP Business
Case ID
For transactions received via ICM
(A2A) the first 16 characters of the
MsgId.
(U2A) the internal reference.
“NEW“:
• for internal payments generated
directly by the SSP modules
(SF interest, RM interest and
penalties);
“HAM”
• When the receiver of the MT
900 is different from the sender
of the payment message
M 25 Account M 35x Usage up to 34 digit account num-

Identification ber related to RTGS main account
or sub-account debited for ancillary
system.

In case the MT 900 is sent to indi-

cate a debit on a HAM account, the
account number of the respective
HAM account is entered in the
field.
O 13D Date, Time 6!n4!n1!x4! n Not used by SSP

Indication
M 32A Value Date, M 6!n3!a15d Only current day.

Currency Only EUR.
Code, Settled amount.
Amount If confirmation is sent out due to a
credit line decrease initiated by the
CB via ICM U2A or A2A (codeword
"/CREDITLINE/" in field 72 of MT
900): Amount of the credit line
change (delta).
O 52A Ordering O Option A: PM:

Institution [/1!a][/34x] For the debit entries stemming
4!a2!a2!c from the AS settlement depending
[3!c] on their nature, the following BICs
are contained:
and current orders sent by
Settlement Banks via ICM:
BIC of the Settlement Bank
dure:
BIC of the AS if procedure was
closed via ICM
BIC of the AS in field Subject-
Details (if filled) else BIC AS
sender of the ReturnGeneral-


BusinessInformation.
• LiquidityCreditTransfer and
SBTransferInitiation
BIC of Settlement Bank
BIC TRGTXEPMASI
• Other cases:
BIC of the AS in Initiating Party
(if filled) else BIC sender of the
ASTransferInitiation.
For the debit entries stemming
from liquidity transfers to T2S:
• LiquidityCreditTransfer:
BIC matching to the sender DN
- optionally given "works as"
BIC in the application header.
• Execution of standing or-
ders:
BIC of the account holder
• Current orders sent via ICM
(U2A):
IC of the working user; selected
"works as" BIC
• MT 202:
BIC of the sender
HAM:
It contains the sender of the related
payment message. For internal
payments generated directly by the
SSP modules (SF interest, RM
interest and penalties) it contains
the BIC of the central bank of the
debtor.


Receiver • /BUP/ for backup payments
Information
• /LIQUIT2S/ (followed by Dedi-
cated Cash Account number to
be credited in T2S) for liquidity
transfers to T2S.
In case 35 characters per line
are exceeded, the account
number will be continued in fol-
lowing line starting with //.
Example:
/LIQUIT2S/CBEEURAAAABE
BBXXXEXAMPLE1
//2345678
• /CRDTLN/15d to indicate the
change of credit line to the us-
er.
• /CREDITLINE/ for credit line
change via ICM order (U2A and
A2A)
• /MANPAY/ for mandated pay-
ments
• /ASDEBT/ used by the AS. See
“Normalization of AS code-
words for field 72”. Not used in
case of standing orders to sub-
accounts and current orders to
sub-accounts sent via ICM and
back transfer of liquidity at end
of procedure or end of day.
• /ASINF/ used by the AS. See


• /SFMLAINT/ for “Automatic
Marginal Lending Interest“
• /BALANCM/ for the confirma-
tion on turnover stemming from
CM
PM and HAM:
• /LIQUIINP/ for a liquidity trans-
fer
• /LIQUIOUT/ for liquidity for-
warding from PM (except at
end-of-day)
• /SFOVDINT/ for “Overnight
Deposit Interest“
• /SFMLOINT/ for “Marginal
Lending On-Request Interest“
• /RMRESINT/ for “Interest on
minimum reserve“
• /RMRESPEN/ for “Penalties for
infringements“
• /RMRESEXC/ for “Interest on
excess of reserve“
• /LIQUISF/ for liquidity transfer
to/from standing facilities mod-
ule
The following lines are filled in
with one of the 3 string:
//AUTOMATIC MARGINAL
LENDING 0004
//MARGINAL LENDING ON
REQUEST 0004
//OVERNIGHT DEPOSIT 0003
followed in the 3rd line by
Debtor and Creditor BIC

• /LIQUIEOD/ for liquidity for-

warding at the end-of-day
• /SSPBIL/ for CRISP TARGET2
fees
• /SSPT2SBIL for CRISP T2S
fees
• /LIQUISOD/ for liquidity transfer
at the start-of-day from HAM to
PM
• Information about the counter-
part involved in SF operations
is provided in a new line and
structured as follows: //DEB
BIC1 CRED BIC2 where BIC1
is the BIC of the debited ac-
count and BIC2 is the BIC of
the credited account
• Information regarding reverse
operations in SF is provided at
the end of the corresponding
line with an “R“(eg //OVER-
NIGHT DEPOSIT nnnn “R“)
HAM:
The first line contains the time.
Format:
• /SETTIME/HHMMSSCC
• /HAMINT/ for “HAM interest“
(managed within HAM)
• /INTERMOD/ for transfer of
liquidity from PM to HAM ac-
count of different participants
(sent to the CB)
As a general rule the remaining 5
lines will contain the first 5 lines of


tag 72 of the incoming message.
Therefore tag 72 may contain
codewords from tag 72 of the in-
coming message.
RM:
The complete information provided
by RM and forwarded by PM/HAM
is:
For the compulsory reserve:
PENALTY
/RMRESPEN/
//PENALTY FOR COMPUL-
SORY RESERVE
//IN THE PERIOD:
//YYYY-MM-DD - YYYY-MM-
DD// DEB CI_BIC CRE
CB_BIC
INTEREST
/RMRESINT/
// INTEREST FOR COMPUL-
SORY RESERVE
//IN THE PERIOD:
DD// DEB CB_BIC CRE
CI_BIC
For the excess of reserve:
INTEREST
/RMRESEXC/
//INTEREST ON EXCESS OF
RESERVE
//IN THE PERIOD:
DD


// DEB CI_BIC CRE CB_BIC
14.1.2.2.2.2 MT 910
Usage This message type is used to show the account holder the credit entry in the
• RTGS account in PM as a consequence of a liquidity operation or a
payment instruction sent by an ancillary system.
• sub-account of an RTGS account in PM as a consequence of a liquidity
operation or a payment instruction sent by an ancillary system.
• HAM account.
The message is sent out after crediting took place on the respective ac-
count. The booking is confirmed again on the account statement. Credit en-
tries from payments received via the FIN-copy service of Payments Module
(PM) are not confirmed with MT 910.
When FIN-copy is not used, issuing of MT 910 is optional (a global parame-
ter can be selected by the participant).
HAM HAM sends, if requested, an MT 910 message to the creditor and the co-
manager.
M 20 Transaction M 16x For payments linked to AS:

Reference The TRN is built with “AS“ followed
Number by the 8 characters of the
timestamp


(ddhhmmss) and the last 6 digits of
the PM transaction reference
(nnnnnn):
“ASddhhmmssnnnnnn“
M 21 Related M 16x Content of field 21 (in case of di-

Reference rect debit field 20). For payments
linked to AS settlements:
and current orders sent via
ICM screens (U2A):
Internal SSP reference
• Execution of LiquidityCredit-
Transfer sent in A2A via ICM:
Copy of MessageIdentification
dure:
Copy of BusinessInformation-
Reference of the ReturnGen-
eralBusinessInformation mes-
sage or 'NONREF' if End of
procedure is triggered on ICM.
Related internal reference at-
tributed by the SSP specifically
to each AS for the procedure
which has to be closed by the
SSP.
• MT 202 to credit Sub- or
Technical account – proce-
dure 6 – real time:
Copy of field 20 of the MT 202
• Other cases:
Copy of EndToEndIdentification
contained in the ASTransferI-


nitiation messages
(A2A) the first 16 characters of the
MsgId.
For liquidity transfer PHA to PM
received via ICM (A2A) the content
of field 20 of the FIN message sent
by the CB (PHA) initiated by the
ICM (A2A) order.
(U2A) the internal reference.
“NEW“:
• for internal payments generated
directly by the SSP modules
(SF interest, RM interest and
penalties);
“HAM“(in case of REJECT/ RE-
TURN):
• When the receiver of the MT
910 is different from the sender
of the payment message.
M 25 Account M 35x Usage up to 34 digit account num-

Identification ber related to RTGS main account
or sub-account credited for ancil-
lary system.
In case the MT 910 is sent to indi-
cate a credit on a HAM account,
the account number of the respec-
tive HAM account is entered in the
field.
O 13D Date, Time 6!n4!n1!x4! n Not used by SSP


Indication
M 32A Value Date, M 6!n3!a15d Only current day.

Currency Only EUR.
Code, If confirmation is sent out due to a
Amount credit line increase initiated by the
CB via ICM U2A or A2A (codeword
"/CREDITLINE/" in field 72 of MT
910): Amount of the credit line
change (delta).
O 50a Ordering O Option A: Not used

Customer [/34x]
4!a2!a2!c
[3!c]
Option F:
35x 4*35x
Option K:
[/34x] 4*35x

O 52a Ordering M Option A: PM:

Institution [/1!a][/34x] Content of field 52 of the related
4!a2!a2!c payment message or its sender of
[3!c] the credited payment. For the cred-
it entries stemming from the AS
settlement depending on their
nature, the following BICs are
contained:
• MT 202 to Sub- or Technical
Account – procedure 6 – real-
time, execution of Standing
orders and current orders
sent by the Settlement Banks
via ICM:
BIC of the Settlement Bank
dure:
BIC of the AS which procedure
was closed via ICM
BIC of the AS filled in field Sub-
ject-Details (if filled) else BIC
AS sender of the Return- Gen-
eralBusinessInformation
BIC TRGTXEPMASI
• Other cases:
BIC of the AS in Initiating Party
(if filled) else BIC sender of the
ASTransferInitiation.
HAM:
It contains the sender of the related
payment message.
For internal payments generated
directly by the SSP modules (SF


interest, RM interest and penalties)
it contains the BIC of the central
bank of the debtor.
O 56a Intermediary O Option A: HAM:

[/1!a][/34x] It is equal to the account debited if
4!a2!a2!c different from the Ordering Institu-
[3!c] tion.

Reciever • /CRDTLN/15d to indicate the
Information change of credit line to the us-
er.
• /CREDITLINE/ for credit line
change via ICM order (U2A and
A2A)
• /MANPAY/ for mandated pay-
ments
• /ASCRED/ used by the AS. See
• /ASINF/ used by the AS. See
• /SFMLAINT/ for “Automatic
Marginal Lending Interest“

• /BALANCM/ for the confirma-

tion on turnover stemming from
CM
PM and HAM:
• /SFOVDINT/ for “Overnight
Deposit Interest“
• /SFMLOINT/ for “Marginal
Lending On-Request Interest“
• /RMRESINT/ for “Interest on
minimum reserve“
• /RMRESPEN/ for “Penalties for
infringements“
• /LIQUINP/ for a liquidity transfer
• /LIQUIOUT/ for liquidity for-
warding from PM (except at the
end-of-day)
• /LIQUISF/ for liquidity transfer
to/from standing facilities mod-
ule
The following lines are filled in
with one of the 3 string:
//AUTOMATIC MARGINAL
LENDING 0005
//MARGINAL LENDING ON
REQUEST 0005
//OVERNIGHT DEPOSIT 0010
followed in the 3rd line by
Debtor and Creditor BIC
• /LIQUIEOD/ for liquidity for-
warding at the end-of-day
• /SSPBIL/ for CRISP TARGET2
fees
• /SSPT2SBIL for CRISP T2S
fees

• /LIQUISOD/ for liquidity transfer

at the start-of-day from HAM to
PM
• Information about the counter-
part involved in SF operations
is provided in a new line and
structured as follows: //DEB
BIC1 CRED BIC2 where BIC1
is the BIC of the debited ac-
count and BIC2 is the BIC of
the credited account
• Information regarding reverse
operations in SF is provided at
the end of the corresponding
line with an “R“(eg //OVER-
NIGHT DEPOSIT nnnn R“)
HAM:
The first line contains the time.
Format:
• /SETTIME/HHMMSSCC
• /HAMINT/ for “HAM interest“
(managed within HAM)
• /INTERMOD/ for transfer of
liquidity from HAM to PM ac-
count of different participants
(sent to the CB)
As a general rule the remaining 5
lines will contain the first 5 lines of
tag 72 of the incoming message.
Therefore tag 72 may contain
codewords from tag 72 of the in-
coming message.
RM:
The complete information provided


by RM and forwarded by PM/HAM
is:
For the compulsory reserve:
PENALTY
/RMRESPEN/
//PENALTY FOR COMPUL-
SORY RESERVE
//IN THE PERIOD:
DD// DEB CI_BIC CRE
CB_BIC
INTEREST
/RMRESINT/
// INTEREST FOR COMPUL-
SORY RESERVE
//IN THE PERIOD:
DD// DEB CB_BIC CRE
CI_BIC
For the excess of reserve:
INTEREST
/RMRESEXC/
//INTEREST ON EXCESS OF
RESERVE
//IN THE PERIOD:
DD
// DEB CI_BIC CRE CB_BIC

Normalization of The optional elements (Debtor, Creditor and RemittanceInformation) of the

AS codewords for ASTransferInitiation and SBTransferInitiation are mapped in the field 72 of
field 72 the MT 900/910.
For the AS real-time, the fields 52/58 and 72 of the standing orders and the
liquidity transfer to technical account – procedure 6 – real-time are also
mapped in the field 72 of the MT 900. For the standing orders and current
orders executed via ICM for the AS interfaced, the field 52 of MT 900/910 is
filled in with the BIC of the settlement bank and no information is mapped in
the field 72.
Specific fields of MT 202 sent by a settlement bank to credit its sub-account
or to credit the technical account – procedure 6 – real-time are also mapped
in the MT 900/910: Field 20 of the MT 202 is mapped in field 21 of the MT
900/910, Field 52a contains the BIC of the settlement bank, and fields 52 or
58 of the MT 202 are mapped to the field 72 as explained below.
Codewords If debtor (or field 52) and creditor (or field 58) are filled, they are sent in field
72 with the following codewords:
• In the MT 900: /ASDEBT/ (debtor or 52)
• In the MT 910: /ASCRED/ (creditor or 58)
If RemittanceInformation (field 72) is filled, it is sent in field 72 with the fol-
lowing codeword:
• In MT 900/910: /ASINF/ (RemittanceInformation or 72)
Normalization for Debtor and creditor contain the following optional elements:
codewords
/ASDEBT/ • Debtor
and/ASCRED/ – Name (62x)
– BIC (11x)
– DomesticAccountIdentification (35x)
• Creditor

– Name (62x)
– BIC (11x)
– DomesticAccountIdentification (35x)
The separator “+“ is used to distinguish the 3 optional elements of debtor
and creditor.
The maximal length of each allowed data combination for debtor or creditor
parameters is:
Data combinations Maximal length
Name+BIC+DomesticAccountIdentification 100x
Name+BIC+ 74x
Name+DomesticAccountIdentification 99x
Name++ 62x
+BIC+DomesticAccountIdentification 48x
+BIC+ 12x
++DomesticAccountIdentification 37x
In case of field 52 or field 58, the data is “+BIC“.

The data relative to debtor and creditor are sent in MT 900/910 without trun-
cation.
These data are always mapped at the beginning of the field 72, according to
their length they occupy from the 1st to the 4th line.
Example with the maximum data length (110x):
/ASDEBT/ 27x
// 33x
// 33x
// 17x

Normalization for The contents of tag RemittanceInformation of the ASTransferInitiation, as

the codeword well as field 72 of the liquidity transfers, are mapped to field 72 of the MT
/ASINF/ 900/910, following code word /ASINF/.
However, as the field 72 is limited to 6 lines of 35x, the information will be
truncated according to a dynamically handling of the remaining lines of field
72 after the codewords /ASDEBT/ or /ASCRED/.
The length of the RemittanceInformation will be from 61 characters to 140
characters according to the number of free lines following /ASDEBT/
or/ASCRED/.
Minimum and maximum lengths of RemittanceInformation
Minimum: 61 characters Maximum: 140 characters

(Maximum truncation) (No truncation)
/ASDEBT/ 27x /ASDEBT/ 27x

// 33x /ASINF/ 28x
// 33x // 33x
// 17x // 33x
/ASINF/ 28x // 33x
// 33x // 13x
Examples of field Field 72 for MT 900

72
Tag M/O Data
72 O /ASDEBT/ Bank DEBSPART++123456DBSP

/ASINF/Document XYZ

Field 72 for MT 910
Tag M/O Data
72 O /ASCRED/+CREDFRPPXXX+CRED789
/ASINF/Document XYZ
14.1.2.2.2.3 MT 940
Usage This message type is used to show the account holder the bookings in the
• RTGS account in PM
• sub-accounts of the RTGS account
• HAM account
• CB customer’s account
• Contingency Module account (in case the Contingency Module has been
activated).
• Issuing of MT 940 is optional for the account holder and for the co-
manager.

Reference SSP progressive
Number
O 21 Related - - Must not be used

Reference

M 25 Account M 35x Usage up to 34 digits;

Identification • account number related to
RTGS main account or sub-
account debited by an ancillary
system.
• relevant HAM account number.
M 28C Statement M 5n[/5n] Statement Number:

Number/ At the beginning of the year and for
Sequence the first message of a new partici-
Number pant starting with 00001
PM and HAM:
Sequence Number:
Starting daily with 00001 In case of
overflow of the sequence number
on the same business day the
statement number increases by 1
and the sequence number starts
again from 1.
M 60a Opening MO Option F: F = First Opening Balance

Balance 1!a6!n3!a15 D/C Mark, Date (current business
d day), Currency, Amount
Option M: M = Intermediate Opening Bal-
1!a6!n3!a15 anceD/C Mark, Date (current busi-
d ness day), Currency, Amount
---->
O 61 Statement O 6!n[4!n]2a[1
Line !a]15d1!a3!
c16x[//
16x][34x]
Sub- For- PM:


field mat
1 6!n Value date (YYMMDD)
2 [4!n] Business day date (MMDD)
3 2a • Characters for Debit/Credit (D

or C)
• Characters for Reversal of Deb-
it/Credit (RD or RC)
4 [1!a] Code for money type (not being

used)
5 15d Amount in euro
6 1!a3!c Origination type of turnover (S3!n).

3!n is filled with the respec-tive
SWIFT message type (eg S103)
AS transactions:
“S202“for transactions sent by a
settlement bank (MT 202,
SBTransferInitiation, Liquidi-
tyCreditTransfer, U2A) to debit its
own RTGS account
“S204“for all others operations
ordered by a third party (AS, CB or
PM)
7 16x Ordering party’s reference (field

20)
Origin of payment is within SSP:
(eg liquidity retransfer at EoD to
HAM, PHA or other participants;
EOD settlement on ECB account
levelling out,
Liquidity transfer from PM to HAM


and PHA during the day or be-
tween GoA members, backup
payments, internal payments from
HAM/SF/RM/CM/CRISP to PM)
• reference (field 20) of the inter-
nal message
• if field is not available/filled:
PM reference
AS transactions:
• “Tag 20“ for MT 202
• “Message Identification“ for
SBTransferInitiation and Liquid-
ityCreditTransfer
• “SSP internal reference“ for
U2A, standing orders and op-
erations ordered by PM
• “BusinessInformationRefer-
ence“ for end of procedure re-
quested via ReturnGeneral-
BusinessInformation
• “EndToEndIdentification“ for all
other cases (requested by
ASTransferInitiation)
8 [//16x] Reference for the institution main-

taining the account: SSP internal
posting reference for unique identi-
fication
AS transactions:
“SSP internal reference“
9 [34x] <BIC of the sender from the SWIFT

Header>
/<settlement time HHMMSS>[/


<BIC from field 52>] optional[/
BUP/] optional; only for backup
payments
[/MANPAY/] optional; only for
mandated payments
<PM BIC> for payments initiated
by PM (eg liquidity retransfer at
EoD to HAM, PHA or other partici-
pants, EOD settlement on ECB
account levelling out)
<BIC customer of ICM request>
for payments initiated via ICM (eg
liquidity transfer from PM to HAM
payments)
<BIC of field 53 of the internal
message> for internal payments
from HAM/SF/RM/CM/CRISP to
PM
AS transactions:
<SB BIC>/HHMMSS for “S202“
messages
<PM BIC>/HHMMSS for standing
orders and for emergency proce-
dure launched automatically by PM
(ex: if End of Procedure has not
been sent by the AS before the
end of day)
<AS BIC>/HHMMSS for messages
sent by AS
<CB BIC>/HHMMSS/<AS BIC> for
messages sent by CB on behalf of


the AS
Note: The postings (debit entries

and credit entries) are sorted in
ascending order of the amount.
HAM:
1 6!n Transaction accounting date in

YYMMDD format
2 [4!n] Not used
3 2a Sign:
• C - Credit
• D - Debit
• RC - Reverse Credit
• RD - Reverse Debit
4 [1!a] Not used
5 15d Amount
6 1!a3! Transaction type:

c it reports, in S3!n format, the
SWIFT message type originating
the transaction. XML messages
and internal messages will be
indicated using the corresponding
FIN message types (202). If the
user did not receive any MT 202
the codeword NMSC will be indi-
cated.
7 16x Tag 20 of the message to which

the transaction type is referred. For
XML messages first 16 characters


of the MsgID.
8 [//16x] Tag 20 of the MT 900 - MT 910

sent
9 [34x] Tag 21 of the incoming MT 202

message.

and credit entries) are sorted ac-
cording to the sequence of the
settlement.
O 86 Information O 6*65x Not used by the SSP

to Account
Owner
----|
M 62a Closing Bal- M Option F: F = Final Closing Balance D/C

ance 1!a6!n3!a15d Mark, Date, Currency, Amount
(Booked Option M: M = Intermediate Closing Bal-
Funds) 1!a6!n3!a15d anceD/C Mark, Date, Currency,
Amount
O 64 Closing O 1!a6!n3!a15 Not used by the SSP

Available d
Balance
(Available
Funds)
---->

O 65 Forward O 1!a6!n3!a15 Not used by the SSP

Available d
Balance
----|
O 86 Information O 6*65x Not used by the SSP

to Account
Owner
14.1.2.2.2.4 MT 950
Usage This message type is used to show the account holder the bookings in the
• RTGS account in PM
• sub-accounts of an RTGS account
• HAM account
• CB customer’s account
• Contingency Module account (in case the Contingency Module has been
activated).
Issuing of MT 950 is optional for the account holder and for the co-manager.

Number

M 25 Account M 35x Usage up to 34 digits;

Identification • account number related to
RTGS main account or sub-
account debited by an ancillary
system.
• relevant HAM account number.
M 28C Statement M 5n[/5n] Statement Number:

Number pant starting with 00001
PM and HAM:
Sequence Number:
Starting daily with 00001 In case of
overflow of the sequence number
on the same business day the
again from 1.
M 60a Opening M Option F: F = First Opening Balance D/C

Balance 1!a6!n3!a15 Mark, Date (current business day),
d· Currency, Amount
1!a6!n3!a15 anceD/ C Mark, Date (current
d business day), Currency, Amount
---->
O 61 Statement O 6!n[4!n]2a[1
Line !a]15d1!a3!
c16x[//
16x][34x]
Sub- For- PM


field mat

or C)
Characters for Reversal of Debit/
Credit (RD or RC)

used)
5 15d Amount in euro
6 1!a3! Origination type of turnover (S3!n).

c 3!n is filled with the respective
SWIFT message type (eg S103)
AS transactions:
“S202“ for transactions sent by a
settlement bank (MT 202,
SBTransferInitiation, Liquidity
CreditTransfer, U2A) to debit its
own RTGS account
“S204“for all others operations
ordered by a third party (AS, CB or
PM)

20)
(eg liquidity retransfer at EoD to
HAM, PHA or other participants;
EOD settlement on ECB account
levelling out,
Liquidity transfer from PM to HAM


payments, internal payments from
HAM/SF/RM/CM/CRISP to PM)
nal message
• if field is not available/filled: PM
reference
AS transactions:
• “Tag 20“ for MT 202
SBTransferInitiation and Liquid-
ityCreditTransfer
• “BusinessInformationRefer-
ence“ for end of procedure re-
quested via ReturnGeneral
BusinessInformation
8 [//16x Reference for the institution main-

taining the account: SSP internal
fication
AS transactions:

Header>


payments
[/MANPAY/] optional; only for
mandated payments
pants; EOD settlement on ECB
account, levelling out)
tween GoA members; backup
payments)
PM
AS transactions:
<SB BIC>/HHMMSS for “S202“
messages
end of day)
sent by AS


the AS

HAM:
Information about a single transac-
tion in the following:

YYMMDD format
2 [4!n] Not used
3 2a Sign:
• C - Credit
• D - Debit
4 [1!a] Not used
5 15d Amount
6 1!a3! it reports, in S3!n format, the

c SWIFT message type originating
cated.



of the MsgID.
8 [//16x] Tag 20 of the MT 900 - MT 910

sent

message.

cording to the sequence of settle-
ment.
----|
M 62a Closing Bal- M Option F: F = Final Closing BalanceD/C

Amount
O 64 Closing O 1!a6!n3!a15 Not used by the SSP

Available d
Balance
(Available
Funds)

14.1.2.3 SWIFT system messages
14.1.2.3.1 MT 012
Usage This message type is used to show the sender of a payment message that
the payment has been released by the Payments Module (PM). An MT 012
is always sent by the SWIFT system.
If a MT 202 is used to pull liquidity from T2S, the MT 012 will not confirm
settlement in TARGET2 but it will indicate that the transfer order has been
forwarded and - possibly partially - settled in T2S. Settlement on the RTGS
account is only done after reception of the LiquidityCreditTransfer XML
message from T2S. The only reference in this LiquidityCreditTransfer from
T2S, which refers to the instructing message sent by TARGET2 (EndTo-
EndId) may not be unique. Therefore, PM cannot check correlation with an
existing business case. Consequently, the account owner has to check his
RTGS booking entries if the expected credit entry has been settled. He may
use ICM screens or GetTransaction XML requests for this.
For each payment, the presenting party can specify whether an MT 012 is
required. In field 113, the flag in the second byte of the user header of the
relevant payment must be set to “Y“ (= MT 012 required) or “N“ (= MT 012
not required).
If the presenting party leaves the field blank, an MT 012 is issued as stand-
ard. It is also issued even if the flag is set to "N" by the sender, if the mes-
sage is used for initiation of pull liquidity transfer from T2S and if the pay-
ment is only partially executed by T2S. So this important information is al-
ways reported via an MT 012.

M 175 Time M HHMM Input time of the original user mes-

sage local to the sender.
M 106 MIR M 6!n4!a2!a2! MIR, identifying the sender’s Copy

c1!c3!c4!n6! message copied to the PM and
n released by PM.
O 108 MUR O 16x Optional MUR, identifying the

sender’s copy message copied to
the PM and released by PM.

M 102 SWIFTAddre M 4!a2!a2!c1! Destination of the sender’s mes-

ss c3!c sage
M 103 Service- M TGT

Code
M 114 Payment M 6!n2!a16x Used in SSP (SWIFT format: 32x)

Release Regular TARGET2 usage:
Information • Credit time HHMMSS,
Sender
• Debit time HHMMSS,
• Country code of sender,
• Reference of original payment
message
In case "Pull liquidity from T2S":
• T2S Receipt entry time
HHMMSS
• T2S settlement status:
"SSET" (settled) or
"SPAS" (partially settled)
• SSP Business Case ID
14.1.2.3.2 MT 019
Usage This message type is used to show the sender that the message could not
be passed on to the receiver. An MT 019 is always sent by the SWIFT sys-
tem.
Returning the message can either be initiated by the SWIFT system or PM.
The reason for the return is specified by an error code in MT 019.
The receipt of MT 019 cannot be precluded.

In certain select situations the SSP has accepted to settle the transaction,
but SWIFT is not able to deliver the original message to the intended re-
ceiver.
The sender is aware because SWIFT generates an MT 019 containing one
the following error codes:
11 Message is too old, but was authorised
12 Too many delivery attempts, but message was authorised
13 Destination is disabled, but message was authorised
14 Message is too long, but was authorised
Therefore should the sender receive an MT 019 with the above mentioned
error codes, the payment has to be considered settled by the SSP. It should
also be highlighted that there is no guarantee that the MT 012, if requested,
will arrive before the MT 019.
Should the above situation happen (whatever the underlying reason) then
the sender must contact the National Service Desk that will take care of in-
forming the receiver and the SSP Operational Team.
SWIFT standard SSP Specification
M 175 Time M HHMM Input time of the aborted message

local to the sender.
M 106 MIR M 6!n8!c4!c4! MIR, identifying the aborted mes-

n6!n sage.
O 108 MUR O 16x The MUR identify the aborted

message (if present). If no MUR
was present:
• tag 108 will contain the con-

SWIFT standard SSP Specification

tents of field 20 of the original
message when the alphabetical
characters used were all in up-
per case
• tag 108 will not be present,
when contents of field 20 could
not be used
M 102 SWIFT Ad- M 4!a2!a2!c1! Destination of the aborted mes-

dress c3!c sage
O 107 MOR O 6!n8!c4!c4! MOR identifying the aborted mes-

n6!n sage. If several delivery attempts
have been made, field 107 con-
tains the last valid MOR.
M 432 Abort Rea- m 2!c Abort reason (specified in the

son SWIFT manual FIN error codes) or
reason for the message being
rejected by PM.
O 619 VAS code M 3!x FIN Copy service code: code of

field TAG 103 of the aborted mes-
sage
14.1.2.4 Examples for addressing payments
Addresses in In PM, since the FIN Y-copy service is used, payments will be addressed to
TARGET2 the receiving direct PM participant by indicating the BIC in the respective
field of the header. Payments for indirect PM participants will have to be
sent, in general, to the respective direct PM participant. The information
needed for the correct addressing is provided in the TARGET2 directory
(see chapter 9.3 TARGET2 directory in book 1).

In HAM, payments are issued to HAM via normal FIN (V-shape). Using this
method, FIN messages (MT 103, MT 103+, MT 202 and MT 202 COV) are
sent directly from the sender to the SSP. The same message types are sent
from the SSP to the receiver HAM account holders or CB customers for no-
tification purposes (after the settlement).
The following table shows details of the recipient’s address in the SWIFT
Application Header of the payment record from a PM participant’s point of
view:
Receiving party Address
SWIFT-based direct PM participant BIC of the direct PM participant

Note: It is possible that the direct PM partici-
pant sends and receives payments from
another location using a different BIC (tech-
nical reasons).
Internet-based direct PM participant Special BIC of PM dedicated for Internet-

based participants “TRGTXEPMLVP“
indirect PM participant BIC of the respective direct PM participant
HAM account holder TRGTXEHMXXX
proprietary home account holder BIC of the respective CB
In the following examples the BIC listed below are used:
BIC Explanation
BKAAFRPPXXX direct PM participant (co-manager)
BKEEFRPPXXX direct PM participant
BKBBITRRXXX direct PM participant (co-manager)
BKCCDEFFXXX direct PM participant

BIC Explanation
BKDDDEDDXXX direct PM participant
BKCCDEFF425 second BIC used by the direct PM participant (BKCCDEFFXXX) to

send and receive messages at an other location (for technical reasons)
BKBBITRR321 second BIC used by the direct PM participant (BKBBITRRXXX) to send

and receive messages at an other location (for technical reasons)
BKDDDEM1XXX indirect PM participant (related direct PM participant BKDDDEDDXXX)
BKHHFRP1XXX indirect PM participant (related direct PM participant BDCCDEFFXXX)
BKLLITROXXX indirect PM participant (related direct PM participant BKBBITRRXXX)
BKEEITRRXXX HAM account holder (related to Banca d’Italia)
BKMMITSSXXX HAM account holder (related to Banca d’Italia)
BKNNFRWWXXX HAM account holder (related to Banque de France)
BKGGDEFFXXX HAM account holder (related to Deutsche Bundesbank)
BKFFITAAXXX Central bank customer with an account in HAM (related to Banca

d’Italia)
BKOOITKKXXX Central bank customer with an account in HAM (related to Banca

d’Italia)
NCBIITRRXXX CB using HAM
NCBFFRPPXXX CB using HAM
NCBKLULUXXX CB with proprietary home accounting system
BKFFLULUXXX account holder in proprietary home accounting system

14.1.2.4.1 Payments between HAM and PM
Sender direct PM In the following examples the direct PM participant (BKAAFRPP) sends the
participant SWIFT message (MT 202).
Case Receiver Field Entry Effect
1 HAM account holder S: BKAAFRPPXXX • Debit entry in the

BKNNFRWWXXX R: TRGTXEPMHAM RTGS account in PM
of BKAAFRPPXXX
52:
56: • Credit entry in the
57: RTGS account in PM
of the CB
58: BKNNFRWWXXX
Note: The payment will be delivered to HAM via an internal link. In HAM the
account of the CB will be debited and the account of the HAM account hold-
er will be credited.
2 HAM account holder S: BKAAFRPPXXX • Debit entry in the

BKAAFRPPXXX R: TRGTXEPMHAM RTGS account in PM
of BKAAFRPPXXX
52:
of the CB
58: BKAAFRPPXXX
account of the CB will be debited and its own account in HAM will be cred-
ited.

3 Central bank customer S: BKAAFRPPXXX • Debit entry in the

with CB customer’s ac- R: TRGTXECBITX RTGS account in PM
of BKAAFRPPXXX
count BKFFITAAXXX 52:
57: RTGS account of the
central bank cus-
58: BKFFITAAXXX
tomer’s CB
Note: The payment will be delivered to HAM via SWIFT. In HAM the ac-
count of the central bank customer’s CB will be debited and the account of
the central bank customer will be credited.
Sender direct PM In the following examples the direct PM participant (BKAAFRPP) sends the
participant co- SWIFT messages (MT 202) to the HAM to transfer funds from the co-man-
manager of a aged account to the PM.
HAM account
holder
4 RTGS account holder of S: BKAAFRPPXXX • Debit entry in the

BKAAFRPPXXX R: TRGTXEHMXXX HAM account of
BKNNFRWWXXX
52:
53: BKNNFRWWXXX • Credit entry in the
56: HAM account of the
CB
57: NCBFFRPPXXX
58: 58: BKAAFRPPXXX
Note: The presence of tag 57 means that the receiver is in PM. The pay-
ment will be delivered to PM via an internal link. In PM the account of the
CB will be debited and the account of the RTGS account holder will be cred-
ited.

5 RTGS account holder of S: BKAAFRPPXXX • Debit entry in the

BKEEFRPPXXX R: TRGTXEHMXXX HAM account of
BKNNFRWWXXX
52:
53: BKNNFRWWXXX • Credit entry in the
CB
57: NCBFFRPPXXX
58: BKEEFRPPXXX
Note: The presence of tag 57 means that the receiver is in PM. The pay-
ment will be delivered to PM via an internal link. In PM the account of the
CB will be debited and the account of the RTGS account holder will be cred-
ited.
Sender is direct In the following examples the direct PM participant (BKCCDEFFXXX) uses
PM participant a second BIC (BKCCDEFF425) for sending SWIFT messages (MT 202).
using a second
BIC
6 HAM account holder S: BKCCDEFF425 • Debit entry in the

BKEEITRRXXX R: TRGTXEPMHAM RTGS account in PM
of BKCCDEFFXXX
52:
of the CB
58: BKEEITRRXXX
account of the CB will be debited and the account of the HAM account hold-
er will be credited.

7 Central bank customer S: BKCCDEFF425 • Debit entry in the

of BKCCDEFFXXX
count BKFFITAAXXX 52:
of the central bank
58: BKFFFITAAXXX
customer’s CB
Originator is In the following examples the indirect PM participant (BKHHFRP1XXX) or-

indirect PM ders its related direct PM participant (BKCCDEFFXXX) to send the SWIFT
participant message (MT 202).
8 HAM account holder S: BKCCDEFFXXX • Debit entry in the

BKGGDEFFXXX R: TRGTXEPMHAM RTGS account in PM
of BKCCDEFFXXX
52: BKHHFRP1XXX
of the HAM account
58: BKGGDEFFXXX
holder’s CB
account of the HAM account holder’s CB will be debited and the account of
the HAM account holder will be credited.

9 Central bank customer S: BKCCDEFFXXX • Debit entry in the

of BKCCDEFFXXX
count BKFFITAAXXX 52: BKHHFRP1XXX
of the central bank
58: BKFFFITAAXXX
customer’s CB
Sender HAM In the following examples the HAM account holder (BKEEITRRXXX) sends
account holder the SWIFT message (MT 202).
10 Direct PM participant S: BKEEITRRXXX • Debit entry in the

BKBBITRRXXX R: TRGTXEHMXXX HAM account of
BKEEITRRXXX
52:
57: NCBIITRRXXX HAM account of the
HAM account holder’s
58: BKBBITRRXXX
CB
Note: The payment will be delivered to PM via an internal link. In PM the

account of the HAM account holder’s CB will be debited and the account of
the direct PM participant will be credited.

Sender central In the following examples the central bank customer (BKFFITAAXXX) sends
bank customer the SWIFT message (MT 202).
11 Direct PM participant S: BKFFITAAXXX • Debit entry in the

BKBBITRRXXX R: TRGTXECBITX HAM account of BKF-
FITAAXXX
52:
central bank custom-
58: BKBBITRRXXX
er’s CB
12 Second BIC S: BKFFITAAXXX • Debit entry in the

(BKBBITRR321) of a R: TRGTXECBITX HAM account of BKF-
FITAAXXX
direct PM participant, BIC 52:
of the related direct PM 56: • Credit entry in the
participant BKBBIT- 57: HAM account of the
RRXXX 58: BKBBITRR321
er’s CB
13 Indirect PM participant S: BKFFITAAXXX • Debit entry in the

BKLLITROXXX R: TRGTXECBITX HAM account of BKF-
FITAAXXX
52:
58: BKLLITROXXX
er’s CB
Note: It is also possible for a CB customer to send payments in favour of a

PHA participant. In this case the first credit field must be filled in with the
BIC of the NCB “owning“ the PHA and the following credit field with the PHA
participant BIC.

14.1.2.4.2 Payments between account holders in HAM
Sender HAM In the following examples the HAM account holder (BKEEITRRXXX) sends
account holder the SWIFT message (MT 202).
14 HAM account holder S: BKEEITRRXXX • Debit entry in the

BKMMITSSXXX R: TRGTXEHMXXX HAM account of
BKEEITRRXXX
52:
57: HAM account of
BKMMITSSXXX
58: BKMMITSSXXX
Sender RTGS In the following examples the RTGS account holder (BKBBITRRXXX), co-
account holder manager of the HAM account holder (BKEEITRRXXX) sends the SWIFT
co-manager of a message (MT 202) in favour of another HAM account holder (BKM-
HAM account MITSSXXX).
holder
15 HAM account holder S: BKBBITRRXXX • Debit entry in the

BKMMITSSXXX R: TRGTXEHMXXX HAM account of
BKEEITRRXXX
52:
53: BKEEITRRXXX • Credit entry in the
56: HAM account of
BKMMITSSXXX
57:
58: BKMMITSSXXX

Sender central In the following examples the central bank customer (BKFFITAAXXX) sends
bank customer the SWIFT message (MT 202).
16 CB customer with ac- S: BKFFITAAXXX • Debit entry in the

count BKOOITKKXXX R: TRGTXECBITX HAM account of BKF-
FITAAXXX
52:
57: HAM account of
BKOOITKKXXX
58: BKOOITKKXXX
Note: It is also possible for the central bank customer to send payments in
favour of central bank customers of other CBs than its “home“ CB. In this
case the tag 57 has to be filled in with the BIC TRGTXECBccX referring to
the other CB.
14.1.2.4.3 Payments with proprietary home accounts
Sender direct PM In the following example the direct PM participant (BKAAFRPPXXX) sends
participant the SWIFT message (MT 202).
Case Receiver Field entry Effect
17 Account holder in the S: BKAAFRPPXXX • Debit entry in the

PHA BKFFLULUXXX R: NCBKLULUXXX RTGS account in PM
of BKAAFRPPXXX
52:
56: • Credit entry in the PM
57: of NCBKLULUXXX
58: BKFFLULUXXX
Note: In the proprietary home accounting system the account of the CB will
be debited and the account of the account holder in the proprietary home
accounting system (BKFFLULUXXX) will be credited.

Sender direct PM In the following example the direct PM participant (BKCCDEFFXXX) sends
participant using the SWIFT message (MT 202) using its second BIC.
a second BIC
18 Account holder in the S: BKCCDEFF425 • Debit entry in the

of BKCCDEFFXXX
52:
57: of NCBKLULUXXX
58: BKFFLULUXXX
Originator is In the following example the indirect PM participant (BKLLITROXXX) orders

indirect PM its related direct PM participant (BKBBITRRXXX) to send the SWIFT mes-
participant sage (MT 202).
19 Account holder in the S: BKBBITRRXXX • Debit entry in the

of BKBBITRRXXX
52: BKLLITROXXX
57: of NCBKLULUXXX
58: BKFFLULUXXX

Sender In the following examples the proprietary home account holder (BKFFLU-
proprietary home LUXXX) orders its CB to send the SWIFT message (MT 202). The field en-
account holder tries describe how the message has to be filled in by the sending CB.
Note: The way the account holder in the proprietary home accounting sys-
tem has to send the payment instruction to its CB is outside the scope of
SSP. Therefore it is not described in the User Detailed Functional Specifica-
tions.
20 Direct PM participant S: NCBKLULUXXX • Debit entry in the

BKAAFRPPXXX R: BKAAFRPPXXX RTGS account in PM
of the CB
52: BKFFLULUXXX
of BKAAFRPPXXX
58: BKAAFRPPXXX
21 Second BIC of direct PM S: NCBKLULUXXX • Debit entry in the

participant R: BKBBITRR321 RTGS account in PM
of the CB
BKBBITRR321 52: BKFFLULUXXX
of BKBBITRRXXX
58: BKBBITRR321
22 Indirect PM participant S: NCBKLULUXXX • Debit entry in the

BKDDDEM1XXX R: BKDDDEDDXXX RTGS account in PM
of the CB
52: BKFFLULUXXX
of BKDDDEDDXXX
58: BKDDDEM1XXX

Sender In the following example the proprietary home account holder (BKFFLU-
proprietary home LUXXX) orders its CB to send the SWIFT message (MT 202) as liquidity
account holder transfer. The field entries describe how the message has to be filled in by
(liquidity transfer) the sending CB.
Note: The way the account holder in the proprietary home accounting sys-
tem has to send the payment instruction to its CB is outside the scope of
SSP (also the booking in PHA: debit PHA account holder, credit CB account
in PHA). Therefore it is not described in the User Detailed Functional Speci-
fications.
23 Direct PM participant S: NCBKLULUXXX • Debit entry in the

BKFFLULUXXX R: TRGTXEPMXXX RTGS account in PM
of the CB
52: BKFFLULUXXX
of BKFFLULUXXX
58: BKFFLULUXXX

14.2 SWIFTNet InterAct and FileAct related issues
14.2.1 Overview
14.2 SWIFTNet InterAct and FileAct related

issues
14.2.1 Overview
General aspects Participants have the possibility to connect their back office to the ICM using
the application-to-application approach. This is possible by using SWIFTNet
InterAct and SWIFTNet FileAct exclusively. The back office must be linked
via a host adapter with SWIFT’s Secure IP Network (SIPN).
The processing of the use cases requires an application, which can “inter-
pret“ the various XML messages. This application can be developed by the
participant or can be bought from software providers.
XML structures The various information and control options are setup as XML messages.
A detailed description of these XML elements and data type definitions will
be provided in book 4 of the UDFS. Schema files will be made available via
Internet for download.

14.2.2 How to use the application-to-application approach
Use of SWIFTNet In the following table an overview is given for what purposes the XML mes-
services sages are transferred via SWIFTNet InterAct and/or SWIFTNet FileAct:
Purpose SWIFTNet service Remarks
Requests and responses InterAct or (FileAct)(pull The request XML message is

related to ICM (A2A) mode) sent via InterAct (see UDFS
book 4, chapter 2.1). Due to
the fact that some responses
might exceed the maximum
volume of InterAct messages
(defined by SWIFT at the
level of 99,953 Bytes), it is
necessary to return the re-
sponse using FileAct.
14.2.2 How to use the application-to-application

approach
System require- The system requirements, which must be fulfilled to implement an applica-
ments tion-to-application solution, vary a lot depending on the solution sought by
the individual SSP participant.
Access to the Secure IP Network (SIPN) of SWIFT is required for using
SWIFTNet InterAct/SWIFTNet FileAct.
To secure communication and data, SWIFT’s Public Key Infrastructure (PKI)
is used.
Further details of the various SWIFTNet services and the required infra-
structures are available on the www.swift.com homepage or from a regional
SWIFT branch.
It is up to the participants to setup these infrastructures with SWIFT or with
any other provider of SIPN access software.

14.2.3 Use cases
Tests The applications developed for the A2A approach must be tested in accord-
ance with the specified extent prior to being used.
14.2.3 Use cases

Use cases are examples of requests in order to provide information or modi-
fy operations on the current business day (HAM, RM, SF, SD).
The required role is not underlined for each use case, since it is always the
“application“ role for credit institutions (“APPLICATE“).
14.2.3.1 Home Accounting Module
14.2.3.1.1 Modify reservation
Aim It is used to request modifications in the details of one particular reservation,

current or default, set by the participant.
Precondition • The user is logged in

• The requestor can be:
– the owner of the account
– the co-manager of an account owner
– the CB of the account owner
• Each message can change only one of the following types of reservation:
– reservation for cash withdrawal (current or default reservation)
– threshold for advice of investment
Postcondition • The value of the reservation is changed accordingly to the request.
Success
• To verify the outcome of the request the member may submit a Get Res-
ervation message with the appropriate search criteria
Postcondition An error message with the relevant code is issued.

Failure

14.2.3 Use cases
XML Request ModifyReservation
XML Response Receipt
14.2.3.1.2 Modify standing order
Aim It is used to manage the standing order for the transfer of funds from HAM
to RTGS account in PM of the same participant at the start of day.
Precondition • The user is logged in.

– the CB of an account owner
Postcondition The amount of the standing order is accepted as requested.
Success

Failure
XML Request ModifyStandingOrder

14.2.3 Use cases
14.2.3.1.3 Liquidity transfer (between accounts belonging to the same

participant in HAM and PM)
Aim It is used to transfer funds from the HAM account to the RTGS account of
the same participant.

– the CB of an account owner
Postcondition • The request is queued/settled.
Success
• To verify the outcome of the request the member may submit a Get
Transaction or Get Account message with the appropriate search criteria

Failure
XML Request LiquidityCreditTransfer
14.2.3.1.4 Regular transactions (interbank transfer between accounts
Aim It is used for:

• Interbank transfers from a HAM account to an RTGS account of another
participant
• Interbank transfers between HAM accounts held by different participants
• Transactions done by the CB on behalf of the HAM account holders and
CB customers in contingency situation


14.2.3 Use cases

– the co-manager of the account owner
Postcondition • The request is queued/settled.
Success
• To verify the outcome of the request the member may submit a Get
Transaction or Get Account message with the appropriate search criteria

Failure
14.2.3.1.5 Get account
Aim It is used to request information on:

• HAM accounts balances
• standing orders for liquidity transfers from HAM to PM

– the account owner
Postcondition It provides information on:
Success
• HAM account balance
• standing orders for liquidity transfers from HAM to PM

14.2.3 Use cases

Failure
XML Request GetAccount
XML response ReturnAccount
14.2.3.1.6 Get reservation
Aim It is used to request information on reservations (cash withdrawal and

threshold for investment).

Postcondition It provides information on:
Success
• reservation for cash withdrawal (current and default reservations)
• threshold for advice of investment

Failure
XML Request GetReservation
XML Response ReturnReservation

14.2.3 Use cases
14.2.3.1.7 Get transaction
Aim It is used to request information about transactions details.

• It is possible to select a specific transaction or transactions according to
the following criteria:
– debit or credit indicator
– status of payments
– payments settled within a time range
– payment type
– payments with a specific counterpart
– payments with future settlement date
– greater or equal than a specific amount
Note: Several selections can be combined together.
Postcondition It provides information as follows:

Success
• Debit/credit indicator
• Transaction Identifier
• Amount
• Status (settled, rejected, revoked, queued, earmarked)
• Payment type
• Counterpart BIC

14.2.3 Use cases
• Date

Failure
XML Request GetTransaction
XML Response ReturnTransaction
14.2.3.1.8 Get business day information
Aim
It is used to know the current status of the system, the events planned dur-
ing the HAM operational day and when they will take place.
According to the requestor nationality, in addition to the common PM daily
events, information about the specific cut-off envisaged by its own CB it will
be provided.

– the CB
Note: Each requestor can get data related to its own CB.
Postcondition It provides the following information:

Success
• the CB
• the status of the system (closed, active, suspended)
• the list of daily events with, for each event, the scheduled time and the
effective event time

Failure
XML Request GetBusinessDayInformation

14.2.3 Use cases
XML Response ReturnBusinessDayInformation
14.2.3.2 Reserve Management
14.2.3.2.1 Get account RM
Aim It is used to request information about the value of the minimum reserve, the
end of day balance, the running average and the adjustment balance.

Postcondition It provides information concerning:
Success
• the value of the minimum reserve
• the end of day balance
• the running average
• the adjustment balance

Failure
XML Response ReturnAccount

14.2.3 Use cases
14.2.3.3 Standing Facilities
14.2.3.3.1 Liquidity transfer between SF and PM/HAM account
Aim It is used to transfer funds from a PM/HAM account to the SF account of the
same participant (setting up of overnight deposit) or from the SF account to
the PM/HAM account of the same participant (reverse transaction of over-
night deposit).

• The CB of the account owner (on behalf of the account owner as contin-
gency measure)
Postcondition • The request is settled.

Success
• To verify the outcome of the request the member may submit a Get Ac-
count message with the appropriate search criteria

Failure

14.2.3 Use cases
14.2.3.3.2 Get account SF
Aim It is used to request information on the balance of the overnight deposit ac-
count and of the marginal lending account.

Postcondition It provides Information on
Success
• Overnight deposit account balance
• Marginal lending account balance

Failure
XML Respone ReturnAccount
14.2.3.3.3 Get transaction SF
Aim It is used to request information about standing facilities transactions details.

Postcondition • It provides information as follows:
Success

14.2.3 Use cases
– Transaction type
– Transaction Identifier
– Amount
– Status
– Date

Failure
XML Request GetTransaction
XML Response ReturnTransaction
14.2.3.4 Static Data

Use cases described below are dedicated to Static Data messages related
to optional modules and available to CIs as well as to central banks.
14.2.3.4.1 Get HAM account
Aim It is used to get information on HAM account held by a participant or HAM

accounts co-managed by a participant.
Precondition • The user is logged in and is allowed, thanks to his pre-defined role, to
use this transaction.
• The requestor must know precisely the responsible Central Bank and
BIC-11 identifying either the related participant, owner of the HAM ac-
count, or the Co-Manager, a direct participant able to manage the HAM
account.
• Data used by requestor to get information on HAM account may be:
– Account status (eg active, future, archived/rejected, ...)
Postcondition The information on the requested HAM account or co-managed HAM ac-
success counts is delivered to the application.

14.2.3 Use cases
Postcondition An error message with the relevant error code is issued.

failure
XML Request GetHAMaccount
XML Return ReturnHAMaccount
14.2.3.4.2 Get SF account
Aim It is used to get information on SF account.
Precondition • The user is logged in and is allowed, thanks to his pre-defined role, to
use this transaction.
• The requestor must know precisely the BIC-11 identifying the related par-
ticipant, owner of the SF Account and the responsible Central Bank.
• Data used by requestor to get information on SF account may be:
– Account status (eg active, future, archived/rejected, ...)
Postcondition The information on the requested SF accounts is delivered to the applica-
success tion.
Postcondition An error message with the relevant error code is issued.

failure
XML Request GetSFAccount
XML Return ReturnSFAccount
14.2.3.4.3 Get participant

This message, described in chapter 9.2.5.3 Get participant in book 1, allows
to obtain information on HAM participants, participants using RM and partic-
ipants using SF.

14.3 Internet access related issues
14.3.1 Overview

14.3.1 Overview
General Aspects The Internet access allows the participation in TARGET2 without SWIFT
connection. The participants will have access to a dedicated ICM U2A Inter-
net interface for information and control purposes as well as for issuing
credit transfers to other TARGET2 participants. As Internet-based partici-
pants are not connected to SWIFT, they will receive no messages from
TARGET2 (no MT 103(+), MT 202 (COV), MT 204, MT 900/910, MT
940/950, MT 012/019). Therefore Internet-based participants have to moni-
tor all activities on their accounts via ICM during the business day. Never-
theless an account statement will be provided for download at start of day
containing the turnover of the previous business day.
14.3.2 Account statement
Usage Internet-access banks will not receive statement files by TARGET2 in push
mode. The Internet-based participant will get the account statement contain-
ing the booking information of the HAM account of the previous business
day in a file, which can be downloaded via the ICM Internet interface at start
of day. The SWIFT string of the textblock (Block 4) of incoming payments
from SWIFT-based participants as well as a generated SWIFT string of the
textblock (Block 4) for incoming payments from other Internet-based partici-
pants will be saved in the file (field 86 in the repetitive statement line) and
provided to the participants for download and archiving (see structure de-
scription for details). The file will be formatted on the basis of the structure
of an MT 940 with usage of full SWIFT character set. The file will be provid-
ed in ASCII format.
The file is divided into repetitive sequences (because statement file genera-
tion is based on SWIFT MT 940 generation). All repetitive sequences of one
account are stored in one file.

The download of the statement files will be available for the last 10 business
days. After this period the statements will be deleted. It is in the responsibil-
ity of the Internet-based participant to download and store the files before
deletion.
Filename The filename of the statements will be formatted as follows:

<Business day date (YYYYMMDD/8!n)>_<Account Identification (34x)>.sta
Examples: 20100120_FIORITF1XXX123456789.sta
Structure The following table describes the structure of the account statement file:
Status Field Field Name Status Format Use in SSP

Number
O 21 Related - - Must not be used.

Reference
M 25 Account M 35x Usage up to 34 digits; account

Identification number related to HAM / CB cus-
tomer account debited by an ancil-
lary system.
M 28c Statement M 5n[/5n] Statement Number:

Number pant starting with 00001.
PM and HAM:
Sequence Number:
Starting daily with 00001. In case
of overflow of the sequence num-
ber on the same business day the


again from 1.
M 60a Opening M Option F: F = First Opening BalanceD/C

Balance 1!a6!n3!a15d Mark, Date, Currency, Amount
1!a6!n3!a15d anceD/C Mark, Date, Currency,
Amount
---->
23O 61 Statement O 6!n[4!n]2a[1

Line !a]15d1!a3!
c16x[//
16x][34x]
Sub- For- PM
field mat

or C)
• Characters for Reversal of Deb-
it/Credit (RD or RC)

used)
5 15d Amount in Euro
6 1!a3! Origination type of turnover (S3!n).

c 3!n is filled with the respective
SWIFT message type (eg S103).
“S204“for all other operations


ordered by a third party.

20)
• (eg liquidity retransfer at EoD to
HAM, PHA or other partici-
pants; EOD settlement on ECB
account levelling out,
Liquidity transfer from PM to
HAM during the day, backup
payments, internal payments
from HAM/SF/ RM/CM/CRISP
to PM)
nal message
• if field is not available/filled: PM
reference
AS transactions:
• “Tag 20“ for MT 202
LiquidityCreditTransfer
8 [// Reference for the institution main-

16x] taining the account: SSP internal
fication
AS transactions:


Header>
payments
/MANPAY/ for mandated payments
pants)
and PHA during the day backup
payments)
PMAS transactions:
end of day)
sent by AS
the AS


HAM:

YYMMDD format
2 [4!n] Not used
3 2a Sign:
• C - Credit
• D - Debit
4 [1!a] Not used
5 15d Amount
6 1!a3! Transaction type:

c it reports, in S3!n format, the
SWIFT message type originating
cated.

of the MsgID.
8 [//16x] Internal HAM reference


message.

cording to the sequence of the
settlement.
O 86 Information O 10240x Original SWIFT string of textblock

to Account (Block 4) of incoming SWIFT mes-
Owner sages from SWIFT-based partici-
pants as well as generated SWIFT
string of textblock (Block 4) in case
of payments from other Internet-
based participants
----|
M 62a Closing Bal- M Option F: F = Final Closing BalanceD/C

Amount
O 64 Closing O 1!a6!n3!a15 Not used by the SSP.

Available d
Balance
(Available
Funds)
---->

O 65 Forward O 1!a6!n3!a15 Not used by the SSP.

Available d
Balance
----|
O 86 Information O 6*65x Not used by the SSP.

to Account
Owner

14.4 Entry check
14.4.1 Double entry check for HAM
14.4 Entry check

14.4.1 Double entry check for HAM
Basics HAM carries out a duplicate submission control. This control includes vari-
ous SWIFT fields. Viewed together, they must be clearly filled in for each
business day. Otherwise the payment is rejected because of duplicate sub-
mission.
Details The details are gathered from the following fields of the SWIFT message
types:
Details Part of the SWIFT message Field
Sender Basic Header BIC (extracted from LT)
TRN Text Block :20
Value Date Text Block :32A (first 6 characters)
14.4.2 Error codes

Error codes A complete list of error codes is provided in UDFS book 1, chapter 9.5.2.

15 Test procedure
15 Test procedure
General remark The optional modules will be tested according to the same testing proce-
dures as mandatory modules.

Glossary and Abbreviations

Note: Terms and abbreviations are listed in alphabetical order. In the case
only the abbreviation is used in the ICM User Handbooks the term is ex-
plained afterwards, otherwise a reference is made.
3CB Banca d‘ Italia, Banque de France, Deutsche Bundesbank
4CB network The 4CB network is the common internal technical network of the TARGET2
and T2S providers Banca d'Italia, Banque de France, Deutsche Bundes-
bank and Banco de Espana.
A2A Application-to-application
In this approach, communication is directly between applications customer's
back office and the ICM of the SSP. Information and messages can be
transferred to in-house applications and used further. Control activities are
also automated.
Adjustment End of day balance of the current day which is necessary to fulfil minimum
Balance reserve under the condition that all following end of day balances are exact-
ly the minimum reserve.
Algorithm An algorithm is a mathematical method to provide a smooth, fast and liquidi-

ty saving resolution of the payment queue, for example by taking offsetting
payment flows into account.
Ancillary system Ancillary systems are:

• retail payment systems (RS)
• large value payment systems (LVPS)
• foreign exchange (FX) systems

• money market systems

• clearing houses
• securities settlement systems (SSS)
Ancillary System The Ancillary System Interface (ASI) is a standardised interface to the Pay-
Interface ments Module (PM) which can be used by ancillary systems (ASs) to per-
form the cash clearing of their business.
Ancillary system By means of the ASI the AS manager initiates the settlement procedures of
manager an AS.
ARC Asynchronous Remote Copy
AS See ancillary system
ASI See Ancillary System Interface
AS Technical Account offered in TARGET2 for specific use of ancillary systems.

Account
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.
Auto The auto collateralisation is a specific mechanism used to provide additional

collateralisation liquidity to the SSS settlement process.
This technique is based on the automatic interaction between the collateral
manager, the SSS and the SSP to perform collateralisation functions (eg el-
igibility checks, valuation of collateral) and the related increase of liquidity.

The auto collateralisation is activated during the SSS settlement process to

cope with liquidity shortage of a participant: the collateral to be transferred is
automatically selected by the SSS on behalf of the participant based on a
specific pre-authorisation.
Two distinct auto collateralisation techniques are currently used by the
SSSs:
• firm collateralisation (collateralisation on stock: participants single out the
eligible securities that could be used)
• self collateralisation (collateralisation on flows: with securities deriving
from the settlement process itself)
Available liquidity Credit balance on the account plus collateralised credit line for overdraft (if
available).

B
Backup payments Owing to a breakdown a direct PM participant's system may be unavailable
for the rest of the business day. In order to avoid liquidity concentration on
his account or rather to enable him to fulfil his payment obligations against
CLS, EURO1 or STEP2, the respective PM participant has the possibility to
make backup payments. Backup payments are initiated via ICM. Two kinds
of backup payments are available:
• Backup liquidity redistribution payments are used to realocate the liquidi-
ty that has accumulated on the defaulting participant's account. As soon
as the defaulting PM participant is once again able to do so, the original
single payments belonging to the backup liquidity redistribution payments
previously made are submitted to the PM and the recipients of such
backup liquidity redistribution payments have to return the backup liquidi-
ty redistribution payments.
• Backup contingency payments are used to fulfil obligations arising from
settlement or pre-fund payments on time. The backup contingency pay-
ment replaces the original payment.
Batch A group of orders (payment orders and/or securities transfer orders) to be

processed as a set.
BIC Business Identifier Code
BIC-8 The first 8 characters of the BIC, when used for addressing purposes, are
called destination.
BIC-11 In addition to the first 8 characters of the BIC, an optional branch code of 3
characters is used to identify any branch or reference of an institution.
BIC directory Directory published by SWIFT. It contains the business identifier codes
(BIC) of the credit institutions.

Bilateral Key A SWIFT service for the exchange of bilateral keys between correspondents
Exchange over the SWIFT network, using enciphered data carried with dedicated
messages.
BIS Bank for International Settlements
BKE See Bilateral Key Exchange
Blocked amount In PHA certain amounts may be blocked for future debits, eg in the context
of bulk payments.
A blocked amount also refers to funds on a sub-account notified to an AS
for settlement of the respective AS.
Broadcast Information message simultaneously available to all or a selected group of

SSP participants.
Business case Any kind of order of a participant (eg liquidity transfer, payment etc.) and all
the associated messages (eg MT 096, MT 097, ACK from SWIFT, ...).
Business Payment system's arrangements which aim to ensure that it meets agreed
continuity service levels even if one or more components of the system fail or if it is af-
fected by an abnormal external event. Include both preventative measures
and arrangements to deal with contingencies.
Business day The business day in PAPSS starts at 18.45 (d-1) with the Start-of-day pro-
cessing and ends at 18.45 (d) with the completion of the end-of-day pro-
cessing.

C
camt-Cash Standard for XML messages to be used by participants to manage their
management TARGET2 business.
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.
CB Central bank
CB customer Entity that is not allowed to open accounts in PM according to TARGET

Guideline (eg correspondent bank not located in EEA).
CB Customer Entity that is not allowed to open accounts in PM according to TARGET

Liquidity Bridge Guideline (eg correspondent bank not located in EEA).
CB customer's Account with a CB in the Home Accounting Module, belonging to an entity

account that is not authorised, according to TARGET Guideline, to have an RTGS
account.
Cbo Combo box
CBT SWIFT Computer Based Terminal
CCBM Correspondent Central Banking Model

A mechanism established by the European System of Central Banks
(ESCB) with the aim of enabling counterparties to obtain credit from the
central bank of the country in which they are based using collateral held in
another country. In the CCBM, a CB acts as custodian for the other CBs
with regard to the securities held in its domestic securities settlement sys-
tem.

CCP Central Counter Party

An entity that interposes itself between the counterparties to the contracts
traded in one or more financial markets, becoming buyer to every seller and
the seller to every buyer.
Central securities An entity, which holds and administrates securities and enables securities
depository transactions to be processed by book entry. Securities can be held in a
physical but immobilised or dematerialised form (ie so that they exist only as
electronic records). In addition to safekeeping and administration of securi-
ties, a central securities depository may incorporate clearing and settlement
and assets servicing functions.
CEST Central European Summer Time
CET Central European Time
CI See credit institution
Clearing The process of calculating the mutual obligations of market participants for
the exchange of securities and money. It may include the process of trans-
mitting, reconciling and, in some cases, confirming payment or securities
orders.
Clearing house An entity hosting a clearing system, which consists of a set of rules and pro-
cedures whereby financial institutions present and exchange data and/or
documents relating to funds or securities transfers to other financial institu-
tions at a single location. The procedures often also include a mechanism
for the calculation of participants' mutual positions, possibly on a net basis,
with a view to facilitating the settlement of their obligations in the settlement
system.

Closed User A subset of customers grouped for the purpose of their use of the relevant
Group SWIFT services and products when accessing the Payments Module.
CLS Continuous Linked Settlement

An entity that interposes itself between the counterparties to the contracts
traded in one or more financial markets, becoming buyer to every seller and
the seller to every buyer.
CM See Contingency Module
Collateral An asset or a third party commitment that is accepted by the collateral taker
to secure an obligation to the collateral provider vis-à-vis the collateral taker.
Collateral arrangements may take different legal forms; collateral may be
obtained using the method of title transfer or pledge.
Collateral A system managed by the central bank or by a third party (on behalf of the
manager central bank) that interacts with the SSP in order to manage the intraday
credit line in PM and the access to the marginal lending function in the
Standing Facilities (Module).
Collateral pool Assets owned by members of a transfer system that are collectively availa-
ble to the systems collateral to enable it to obtain funds in circumstances
specified in its rules.
Co-Management The aim is to allow small banks to manage directly their reserve require-
function ments, but delegate cash flow management to another bank. Such a bank
has to be a direct participant in the SSP and is the so-called co-manager.
Confidentiality The quality of being protected against unauthorised disclosure.
Connected Payments by a CB or AS to a participant that trigger a change in the credit

payment line of this participant and an immediate debit/credit of its account to com-
pensate the change in this credit line.

Contingency Common mandatory tool for the CBs for the management of the emergency
Module situations in order to process critical and very critical payments.
Contingency The Contingency Network is an alternative network to access the TARGET2

Network system in case of an regional or global outage of the SWIFT network to en-
sure that a limited number of very critical and critical payments would be
processed by the NCBs in contingency situations. The Contingency Network
is based on CoreNet.
CoreNet CoreNet is an ESCB closed network interconnecting all National Central

Banks and providing them multiple services. In the SSP context CoreNet is
used as a contingency network for PAPSS access. It is also used to access
CRSS reporting service as an alternative to the Swift access.
Country Code Two letter code to identify the country where the respective entity is located;
eg a country code is used in the SWIFT BIC (digits 5 and 6) of the 8-digit or
11-digit BIC.
CRAKS Customer Relationship And Knowledge of System

It gathers all services needed to support customer relationship and
knowledge of payment systems by the central banks.
CRAKS1 SSP block of services dedicated to CBs and to be used on an optional basis
by them, which provides services of queries and reports on historical data.
CRAKS3 SSP service dedicated to CBs and to be used on an optional basis by them,
which provides support to the CBs in their business relationship with their
customers. It consists of the customer support and of the Events & Com-
ments services.
Credit institution The definition given to a “bank“ in the European Union. The First EC Bank-
ing Directive defines it as an undertaking whose business is to receive de-
posits or other repayable funds from the public and to grant credits for its
own account.

Credit line Maximum collateralised overdraft position of the balance on an RTGS ac-
count in PM or on the PHA.
The respective participants can get information about changes regarding
their credit lines via the ICM. Changes of credit lines will be executed imme-
diately. In case of a reduction of a credit line this change has a “pending“
status if the reduction would lead to an uncovered overdraft position. The
change will be executed when the overdraft position is covered by the re-
duced credit line.
Credit transfer A transfer of funds made on the basis of a payment order or sometimes a
sequence of payment orders made for the purpose of placing funds at the
disposal of the payee. The payment order may be processed via several in-
termediaries and/or via one or more funds transfer system.
CRISP Consumption Report and Invoicing Support Process

SSP block of services dedicated to CBs and to be used on an optional basis
by them which provides billing services.
CRM See Customer Relationship Management
CROSS Core Requirements on Statistics and Storage

SSP service dedicated to CBs and to be used on a mandatory basis by
them which comprises archiving and storage services, files for billing calcu-
lation. The CROSS is offered on the CRSS platform.
Cross AS Procedure enabling an Ancillary System (normally CSDs) using ASI proce-
settlement dure 6 to move dedicated liquidity of a settlement bank to another.
Ancillary System using ASI using procedure 6. The settlement takes place
on the technical account – procedure 6 real-time for real-time AS and on the
sub-accounts for interfaced AS.

Cross CSD See Cross AS settlement
Cross-CB Payments between participants of different CB on the SSP.

payments
Cross-PM Payments between one participant of a CB on the SSP and another partici-
payments pant of an external CB which migrates later on (use of the interlinking).
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 the core and optional services
reserved to central banks only are totally or partly implemented, ie archiving
and other CRSS mandatory services (CROSS), billing optional services
(CRISP), query and report optional services (CRAKS1), customer relation-
ship optional services (CRAKS3).
Cryptography The application of mathematical theory to develop techniques and algo-

rithms that can be applied to data to ensure goals such as confidentiality,
data integrity and/or authentication.
CSD See central securities depository
CUG See Closed User Group
Customer Entity which is not a participant (direct or indirect) and which uses the ser-
vice of a participant to exchange transactions in the system. The CBs as
participants can also have customers.
Customer Term referring to the management by CBs of customer-oriented information

Relationship related to participants and customers (CIs, AS, other customers eg CB cus-
Management tomers in HAM). The SSP provides in particular two optional modules for
customer relationship management: billing optional services (CRISP), and
customer relationship optional services (CRAKS3), which are partly imple-
mented on the CRSS platform.

D
Daylight See Day Trade Phase
processing
Day trade phase Period of time in PAPSS between 7.00 and 18.00.
Dedicated Account in the PM on which dedicated liquidity for ancillary system settle-
account ment is held. This can be either a sub-account (interfaced model) or a tech-
nical account – procedure 6 real-time (real-time model).
Dedicated Liquidity held on a PM sub-account or technical account – procedure 6 real-

liquidity time to allow the settlement of an ancillary system.
Delivery Conditional or unconditional transfer of financial instruments by book entry

of physical exchange.
Delivery versus A link between securities transfers and funds transfers system that ensures
payment that delivery occurs if, and only if, payment occurs.
Deposit facility A standing facility of the Eurosystem which counterparties may use to make
overnight deposits at a national central bank, which are remunerated at a
pre-specified interest rate.
Depository An agent with the primary role of recording securities either physically or
electronically and may keep records of the ownership of these securities.
Direct debit An authorised debit on the payer's bank account initiated by the payee.
Direct participant A participant in a system that directly carries out transactions with other par-
ticipants in the system. He can perform all activities allowed in the system
without intermediary. In some systems direct participants also carry out
transactions on behalf of indirect participants.

Distinguished The X.500 notation for an entity.

name
The SWIFTNet identifiers (for example, institution‘s address, certicate‘s
name of an application or a user) follow this standard. The left part always
contains the most detailed information.
Example: certicate name of a user: cn=john-smith,o=bicabebb,o=swift
DN Distinguished name
DN Suffix The first part of a complete DN which is used to assign a BIC-8 or BIC-11 to
a requesting DN. Therefore, in general the DN suffix consists of the first two
levels of the DN tree in case of BIC-8 (ie o=swift o=BIC8) or up to the level
of the branch identifier in case of BIC-11 (eg o=swift o=BIC8 ou=branch
identifier or o=swift o=BIC8 ou=orgunit ou=branch identifier).
DVP See delivery versus payment
EBA Euro Banking Association
ECB European Central Bank
ECB account See NCB‘s ECB account
ECB mirror Account held by the ECB for each CB in the PM on which the bookings
account done on the NCBs‘ ECB accounts will be “mirrored“.
ECSDA European System of Central Banks
EEA European Economic Area
Encryption The use of cryptographic algorithms to encode clear text data (plaintext) into
ciphertext to prevent unauthorised observation.
EPC European Payments Council

ESCB European System of Central Banks
EU European Union
Favourites Counterpart BICs which are dealt with very frequently. Users of a direct SSP
participant are able to define them as “favourites“. Those favourites are valid
for all users of the respective participant. In case a participant BIC has been
selected via the Profile Selection of ICM, the favourites of the selected par-
ticipant BIC are displayed.
FIFO First In, First Out: processing sequence in which the payment orders are
treated in the same sequence as they arrived (ie: the first payment arrived is
treated first, the latest one is treated at the end). The relevant timestamp of
each payment is arrival in the SWIFT Interface of SSP
FIFO by-passing The system tries to process the first transfer in the queue, but if that cannot
be executed owing to lack of funds it then tries to settle the next transfer in-
stead; also called Bypass FiFo.
Final settlement The discharge of an obligation by a transfer of funds and a transfer of secu-
rities that have become irrevocable, irreversible, or not annullable.
Firewall A hardware- and/or software-based system that is used as an interface be-

tween the internet and a computer system to monitor and filter incoming and
outgoing communication.
GARI MT Component of the SWIFT Interface. Communication software for the ex-
change of SWIFT FIN messages.
GARI NT Component of the SWIFT Interface. Communication software for the ex-
change of XML messages.

General Ledger The General Ledger sometimes known as nominal ledger, is the main ac-
counting record of a business which uses double-entry bookkeeping.
Gridlock A situation that can arise in a funds or securities transfer system in which
the failure of some transfer orders to be executed (because the necessary
funds or securities are unavailable) prevents a substantial number of other
orders from other participants from being executed.
Gross settlement A transfer system in which the settlement of funds or securities transfer or-
system ders occurs individually (on an order by order basis).
Group of See liquidity pooling functionality

accounts
Guarantee fund Mechanism to provide the complementary liquidity needed according to pre-
mechanism defined rules in case an AS cannot settle using the settlement banks liquidi-
ty only.
Guarantee funds Account held on the SSP for maintaining or collecting funds allocated to the
account settlement of balances of an ancillary system in case of failure of settlement
bank(s).
HAM See Home Accounting Module
Home account Account held by CBs outside of the Payments Module, eg

• for entities that cannot have the status of a direct participant in PM
• for entities allowed to open RTGS accounts that are indirect PM partici-
pants (or do not participate in PM neither as direct nor indirect)
• for RTGS account holders for the settlement of operations which are not
processed in the Payments Module
The home accounts are managed by the HAM or by a proprietary account-
ing system.

Home Accounting The Home Accounting Module (HAM) is an optional module. In the case, a
Module central bank opts for the use of this module different standardised account
services are offered for the central bank and its customers.
Home CB CB, where the direct participant is located.
Host CB CB, via which a direct participant uses the possibility of remote access.
HTTPS Hyper Text Transfer Protocol Secure

It is a protocol which is used to secure the data exchange in case of access
over internet.
IAM See Identity and Access Management
IBP See Internet-based participant
ICM See Information and Control Module
Identity and Identity and Access Management (IAM) is the evolution of the current ESCB
Access Manage- Directory Services and provisioning tool (namely EUMIDES). IAM is created
ment as a comprehensive platform for managing secure access and associated
rights to Eurosystem and ESCB applications. TARGET2 uses the security
services for user authentication and authorisation as well as the certificate
management provided by IAM to access the Contingency Network and the
CRSS reporting services via CoreNet.
Indirect Indirect participants are distinguished from direct participant by their inability
participant 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 (set-
tling the payments input to the transfer system).

Information and Mandatory and unique functional interface between the direct participants
Control Module and the Payments Module (PM) and the other optional modules like
• Home Accounting Module (HAM)
• Reserve Management (Module) (RM)
• Standing Facilities (Module) (SF)
• Static Date (Management) Module (SD)
Integrity The quality of being protected against accidental or fraudulent alteration of

transmission and of storage, or the quality of indicating whether or not alter-
ation has occurred.
Internet-based An entity which is connected to the SSP via Internet. ICM offers via U2A
participant customised functions with regard to the needs of the Internet-based partici-
pant.
Intra-CB payment Payment between participants of the same CB on the SSP.
Intraday credit Credit extended and reimbursed within a period of less than one business
day; in a credit transfer system with end-of-day final settlement, intraday
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
Intraday liquidity Funds which can be accessed during the business day, usually to enable fi-
nancial institutions to make payments on an intraday basis.

ISO International Organisation for Standardization

The TARGET2 to T2S connectivity will be based on the ISO20022 standard
foreseen by T2S specifications. TARGET2 implements a set of ISO20022
cash management messages which are necessary to properly interact with
T2S.
Legal entity Credit institution directly participating in the SSP through (also AS when par-
ticipating as a direct participant) one or more participants/accounts in the
PM and/or HAM is called a legal entity. This allows to group general infor-
mation about this credit institution in the Static Data (Management) Module.
Limit Amount for normal payments a direct PM participant is willing to pay to an-
other participant (bilateral limit) or to the other participants (multilateral - limit
towards whom no bilateral limit is defined), without having received pay-
ments (that are credits) first. For a direct participant it is possible to establish
standing orders or current bilateral (respectively multilateral) limits.
A normal payment can only be settled if it does not breach the respective
limit. Setting limits is only possible vis-à-vis RTGS account holders (in case
of a group of accounts: only possible vis-à-vis the virtual account) in the
SSP. It is not possible to use limits vis-à-vis participating CBs. Incoming ur-
gent payments from a participant towards whom a bilateral/multilateral limit
is defined also affect the bilateral/multilateral position.
Liquidity pooling A facility, based on the idea of allowing TARGET2 participants to pool their
functionality RTGS accounts in an account group. Such an account group consists of
one or more account(s) held by a direct PM participant(s) which has a capi-
tal and/or management link.
The following three options are offered:
• virtual accounts (only for euro area participants) and

• consolidated information (available also to participants from non-euro ar-

ea countries).
• banking group monitoring (only for CB)
Liquidity transfer Transfer of funds between accounts of the same participant or between two
accounts of a group of accounts.
There are two kinds of liquidity transfers available:
• current:
transfers executed immediately after entry if sufficient liquidity is available
• standing order
transfers of fixed amounts executed regularly at certain points of time, eg
liquidity injections from HAM accounts to RTGS accounts at the start of
the business day. Changes of standing orders become effective on the
following business day.
It is also a generic settlement procedure (procedure 1), where liquidity is
transferred from/to a technical account – procedure 6 real-time to/from a
settlement bank’s RTGS account.
Note: Although still present in TARGET2, procedure 1 should not be used
anymore since it is limited to daylight processing only. For details please re-
fer to the Guideline on TARGET2 and its amendments
(https:/www.ecb.europa.eu/ecb/legal/1003/1349/html/index.en.html).

M
MAC Message Authentication Code
Mandated Payment initiated by an entity that is not party to the transaction (typically by
payment a CB or an AS in connection with ancillary system settlement) on behalf of
another entity. A CB sends a credit transfer (with specific message struc-
ture) on behalf of the failed direct participant (only in case of contingency
situations).
Marginal lending A standing facility of the Eurosystem which counterparties may use to re-
facility ceive overnight credit from a CB at a pre-specified interest rate against eli-
gible assets.
In general possible options:
• Marginal lending on request
Use on request of the participant in general needed for the fulfilment of
reserve requirement.
• Automatic marginal lending
Automatic transformation of intraday credit in overnight credit at the end
of the day.
Message type A specific type of SWIFT messages as identified by a three-digit number.

The first digit defines the message category, indicating the general use of
the message, the second digit defines the message group and the third digit
defines particular message function.
MFI See Monetary Financial Institution
MIR Message Input Reference
Mirror account See Technical account – procedure 6 real-time

Monetary A Monetary Financial Institution (MFI) comprise resident credit institutions

Financial Institu- as defined in Common law, and other resident financial institutions whose
tion business is to receive deposits and/or close substitutes for deposits from
entities other than MFIs, and for their own account (at least in economic
terms), to grant credits and/or make investment in securities.
MOR Message Output Reference
MT see message type
NCB National Central Bank
NCB‘s ECB Account which is necessary to record the CB‘s asset/liability position vis-à-
account vis the ECB in respect of cross-border transactions.
Netting An agreed offsetting of positions or obligations by participants in a clearing

or settlement system. The netting reduces large number of individual posi-
tions 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 An agreement where obligations from individual transfer orders are netted
novation and replaced by new obligations. The parties to the new obligations may be
the same as those to the existing obligations, or, in the context of some
clearing house arrangements, there may be additionally substitution of par-
ties.
Night time Period of time for settlement of AS transactions (settlement procedure 6)

processing between 19.30 h and 6.45 h (interruption for technical maintenance between
22.00 h and 1.00 h).
Non-SWIFT-BIC The business identifier code of a financial institution not connected to the
SWIFT network. Non-SWIFT-BICs are identified by a 1 as the eighth char-
acter.

Offsetting Offsetting in TARGET2 aims to increase the capacity of the system to settle
payments, thereby reducing queues, speeding up the settlement process
and reducing the need of intraday liquidity. A bilateral or multilateral offset-
ting mechanism considers payments in the queues of participants and tries
to settle them simultaneously on a gross basis within one legal and logical
second.
Overnight credit See marginal lending facility
Overnight deposit Deposits with next-day maturity
P
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 (CM)
• Home Accounting Module (HAM)
• Information and Control Module (ICM)
• Payments Module (PM, including the interface for ancillary systems)
• Reserve Management (Module) (RM)
• Standing Facilities (Module) (SF)
• Static Data (Management) Module (SD)
Parts of the following services are also implemented on the PAPSS:
• CRISP
• CRAKS3

Participant An entity which is identified/recognised by the system, is bound by rules of

the system and is allowed to send and capable to receive transfer orders,
either directly (as a direct participant) or indirectly (as an indirect partici-
pant).
Payment In the SSP two general kinds of payments are possible for direct partici-
pants:
• customer payments (MT 103, MT 103+)
• bank-to-bank payments (MT 202, MT 202 COV, MT 204)
Payment An order or message to transfer funds (in the form of a monetary claim on a
message/ party) to the order of the beneficiary. In TARGET2 the order may relate ei-
instruction ther to a credit transfer or a direct debit.
Payments Module Mandatory module which allows the settlement of payments in the RTGS
account, held by all direct participants. In addition, it offers advanced ser-
vices for liquidity management, for the communication with participants and
ancillary systems.
PHA See proprietary home account
PKI Public Key Infrastructure
Pledge A delivery of assets to secure the performance of an obligation owed by one

party (debtor) to another (secured party). A pledge creates a security inter-
est (lien) in the assets delivered, while leaving ownership with the debtor.
PM See Payments Module

Priority In general, payments are settled immediately, if sufficient liquidity is availa-

ble on the RTGS account of the participant. Considering their urgency, they
can be submitted by the sender using priorities:
• highly urgent payments (priority class 0)
• urgent payments (priority class 1)
• normal payments (priority class 2).
Payments which cannot be settled immediately are queued according to
their priority (highly urgent queue, urgent queue, normal queue). Priorities
can be changed via the ICM.
Profiling Information delivered to CBs on the past behaviour of a participant or a

information group of participants, aggregated over a past period, and aimed at being
comparable with current business day information.
Proprietary home Account held by CBs outside the SSP eg

account
• for entities that cannot have the status of direct participants in PM
• for entities allowed to open RTGS accounts that are indirect PM partici-
pants (or do not participate in PM neither as direct nor as indirect)
• for RTGS account holders for the settlement of operations which are not
processed in the PM
The proprietary home accounts are not implemented in the SSP but within
every CB.
Proxy Component of the SWIFT Interface
PSMN See Payment Settlement Message Notification
PSMR See Payment Settlement Message Request

Queuing An arrangement whereby transfer orders are held pending by the sending
participant or by the system until it can be processed according the rules of
the system.
R
RAD Restart after disaster
Raw data file The raw data file

• serves as check file for the verification of the positions of the General
Ledger
• can be used for archiving purposes of CBs not using CRAKS1 services
• can be used for own reports of the CBs
RBAC Role Based Access Control

An optional SWIFTNet facility for controlling end users‘ and applications‘ ac-
cess to service functions.
Real-time gross The continuous (real-time) settlement of funds or securities transfers indi-
settlement vidually on an order by order basis (without netting).
Real-time gross settlement (RTGS) system
A settlement system in which processing and settlement take place in
realtime on a gross basis. An RTGS system may provide centralised
queues for orders which cannot be settled at the time of the submission due
to insufficient funds or quantitative limits on the funds.
Remote A direct participant in the SSP which does not have any representation in
participant the SSP country via he takes part in the SSP.

Repo See repurchase agreement
Repurchase A contract to sell and subsequently repurchase securities at a specified date

agreement and price.
Reservation With the usage of the reservation facility liquidity can be reserved by RTGS
account holders for the execution of special transactions with a certain prior-
ity class. HAM account holders can use the reservation facility to reserve li-
quidity for the execution of cash withdrawals. Reservations can be effected
and adjusted using the ICM.
Reserve holdings Liquidity intraday and overnight maintained on the RTGS account at the
end-of-day.
Reserve Module enabling CBs to perform some functionalities for the reserve re-
Management quirements management, eg verify the minimum reserves fulfilment or cal-
(Module) culate the interest to be paid to credit institutions for minimum reserves.
Reserve The obligation of euro area credit institutions to hold minimum reserves on
requirement reserve accounts with their home NCBs. The reserve requirement is deter-
mined in relation to certain elements of the credit institutions' balance sheet.
Institutions' holding of required reserves are remunerated at the rate of the
Eurosystem's main refinancing operations.
RM See Reserve Management (Module)
RM Interest and Account held by a CB for performing bookings related to the payment of in-
Penalty Account terest on minimum reserves and to the payment of penalties of a CI which
has not fulfilled minimum reserve requirements (optional).
RTGS See real-time gross settlement
RTGS account Account managed within the PM and maintained by a direct participant to
settle all transactions submitted to and processed by the PM (except for
transactions of the AS settlement procedure 6 which are settled on sub-
accounts).

SAA SWIFT Alliance Access

SWIFT Alliance Access is a messaging interface that allows the user to
connect in-house applications with SWIFTNet FIN (MT) and MX-based
SWIFTSolutions.
SAG SWIFT Alliance Gateway

SWIFT Alliance Gateway is the single window to all SWIFTNet communica-
tions. All SWIFTNet message flows can be concentrated through one inter-
face. This includes applications connected via WebSphere MQ, and also
those designed for linking to SWIFTNet Link or based on SWIFTAlliance
WebPlatform.
SB See settlement bank
SD See Static Data (Management) Module
Securities The full set of institutional arrangements for confirmation, clearing, settle-
settlement ment, custody and registration of securities.
system
Self See auto collateralization

collateralisation
SEPA See Single Euro Payments Area
Settlement bank Direct participant which pertains to one or more AS and manages the AS
settlement process (eg the determination of settlement positions, monitoring
of the exchange of payments, etc.) not only for own purposes but also for
other AS participants on its RTGS account (main/sub-accounts).
SF See Standing Facilities (Module)

SF Interest Account held by a CB for performing bookings related to the payment of in-
Account terest on Standing Facilities (optional).
Single Euro Term to describe a statues where the euro area has achieved the same de-
Payments Area gree of integration of payment systems, payment instruments and payment
infrastructure as that which is usually in a single-country currency area.
Single Shared TARGET2 is based on a single technical platform, known as the Single
Platform Shared Platform which includes the PAPSS (Payment and Accounting Pro-
cessing Services Systems) and the CRSS (Customer Related Services Sys-
tem).
SIPN Secure Internet Protocol Network

Secure, high-availability and worldwide virtual private network by SWIFT-
based on the International Protocol (IP) and related technologies and pro-
vides transfer services required by SWIFTNet services.
SLA Service Level Agreement
SSP See Single Shared Platform
SSP OT SSP Operational Team
SSS See securities settlement system
Standing The Standing Facilities (Module) is an optional module and enables to man-
Facilities age the overnight standing facilities (deposit facility, marginal lending facili-
(Module) ty).
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) and also from the RTGS (main)
account to the sub-accounts (interfaced model) or to a technical account –
procedure 6 real-time (real-time model) or to a T2S Dedicated Cash Ac-
count.
Static Data This module ensures a proper and reliable management of static data by
(Management) storing all statistic data actually used. It caters for data consistency between
Module all modules of the SSP. Inter alia the Static Data (Management) Module is
used to generate the TARGET2 directory.
Sub-account Specific account, belonging to an RTGS account, holding dedicated liquidity

to allow the settlement of an ancillary system.
SWIFT Society for Worldwide Interbank Financial Telecommunication
SWIFT-based An entity which is connected to the SSP via SWIFT's Secure IP Network.
participant
SWIFT-BIC A business identifier code of a financial institution connected to the SWIFT

network.
SWIFTNet Browse SWIFT service based on the “https“ internet standard protocol, enabling us-
ers to browse remote web servers. In SSP the use of the Browse service
provides access to the Information and Control Module (ICM) via the Secure
IP Network (SIPN) of SWIFT.
SWIFTNet FileAct File transfer service provided by SWIFT, typically used to exchange batches
of structured financial messages and large reports. In the SSP, eg the
TARGET2 directory is transferred via the Secure IP Network (SIPN) by
SWIFT using the FileAct service.
SWIFTNet SWIFT interactive messaging service supporting the exchange of messages

InterAct between two parties. On the SSP the InterAct service is used for the trans-
fer of XML requests via the Secure IP Network (SIPN) by SWIFT to the ICM.

SWIFT payment An instruction to transfer funds; the exchange of funds (settlement) subse-
message quently takes place over a payment system or through correspondent bank-
ing relationships; used for all payments and the related transactions on the
SSP.
T
T2S See TARGET2-Securities
T2S Actor in The T2S Actor in TARGET2 is special type of participation in A2A mode
TARGET2 which gives CSDs and other credit institutions (eg regional institutions of
credit cooperatives or Landesbank for saving banks) which are authorised
by the direct participant to offer the service to submit current order liquidity
transfers to T2S using XML messages on behalf of TARGET2 direct partici-
pants. The T2S Actors in TARGET2 are registered by linking their DN with
the BIC of a direct participant in Static Data.
T2S DCA See T2S Dedicated Cash Account
T2S Dedicated The euro denominated Dedicated Cash Accounts in T2S are used for the
Cash Account settlement of the cash leg of security transactions in central bank money
(euro). They are opened by a CB for itself and for the T2S participants un-
der its responsibility and are linked to the respective RTGS accounts of the
direct participants in TARGET2. A direct PM participant can send current
and standing order liquidity transfers to any euro denominated Dedicated
Cash Account in T2S, except DCAs belonging to an excluded participant. At
the end of the business day all T2S DCAs must have a balance of zero. The
available liquidity on the T2S DCA is automatically transferred to the linked
RTGS account in TARGET2.
T2S transit The T2S transit account is an offset account in PM used for the routing of all
account current and standing order liquidity transfers to T2S and vice versa. The
T2S transit account is under the responsibility of the ECB.

T2SI The T2S interface is a dedicated interface build in PM for the processing of
pushed and pulled liquidity transfers to T2S using XML messages in the
standard required by T2S.
TARGET Trans-European Automated Real-time Gross settlement Express Transfer.
TARGET2- The single technical platform of the Eurosystem providing core borderless
Securities and neutral securities settlement services in central bank money to central
securities depositories and NCBs in Europe.
TARGET working The TARGET working day (d) equals the calendar day with the exception of
day the days when the TARGET system is not operated.
TARGET2 Directory used by participants to find out where a payment has to be ad-
directory dressed 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.
TARGET2 Fees Account held by a CB for the collection of TARGET2 fees of direct partici-
Account pants (optional).
Task Via the ICM it is possible to transmit

• action orders (eg all kinds of entries) and
• information orders (eg “display“)
to the different modules of the SSP. Action orders transmitted via the ICM
are defined as “tasks“.
Technical Account used in the context of ancillary systems operations as intermediary

account account for the collection of debits/credits resulting from the settlement of
balances or DVP operations. The balance of such an account is always zero
because debits (resp. credits) are always followed by credits (resp. debits)
of an overall equal amount.

Technical In fact specific RTGS accounts opened to CBs for the specific use of ACHs,
account – with the real-time model funds held on the technical accounts – procedure 6
procedure 6 real-time are mirrored in the books of ACHs. It is debited or credited in case
real-time of liquidity transfer between a participant‘s RTGS account in PM and its ac-
count in an ACH.
Transaction An alphanumeric reference of up to 16 characters assigned by the sender to

Reference messages sent over the SWIFT network.
Number
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 fi-
nancial instrument being transferred.
TRN See Transaction Reference Number
TSRC TARGET Security Requirements and Controls
U2A User-to-application
The objective is to permit direct communication between a participant‘s us-
ers and the ICM. The information is displayed in a browser running on a PC
system. Control activities are performed manually by the user.
User Each participant (direct and indirect)

UTC Universal Time Coordinates

A standard adopted by SWIFT for encoding date and time.
Virtual account Method for aggregating data among accounts within a group of accounts
that are held on the books of euro area CBs. Payments made by holders of
an account within a virtual account are checked against the global liquidity
of the virtual account, which is the sum of the available liquidity of all ac-
counts composing it.
V-shape Type of transmission of SWIFT messages on the SSP which is mostly used
in the context of payments processed via HAM.
Warehoused Payments submitted up to five TARGET working days in advance. In this

Payment case, the payment message will be warehoused until the day trade phase of
SSP with the respective date starts.
Wildcards In Select Criteria screens and Select screens of the ICM it is possible to
search with the following wildcards:
• “*“ = one or more characters are missing
• “?“ = one character is missing
WOM Write Once Medium

Medium (eg digital disk) used to archive data. Data cannot be deleted from
such medium once written.

XML Acronym for Extensible Markup Language

Subset of Standard Generalized Markup Language (SGML - ISO 8879) de-
signed especially for use on the Web and in Web-based applications.
Y-copy Standard type of transmission of SWIFT messages on the SSP which is

used in the context of payments processed via PM.

T2 UDFS Book 2 v11.01 20171030 PDF

Uploaded by

Copyright:

Available Formats

T2 UDFS Book 2 v11.01 20171030 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T2 UDFS Book 2 v11.01 20171030 PDF

Uploaded by

Copyright:

Available Formats

Single Shared Platform

User Detailed Functional Specifications

12 User Guide for optional modules ............................ 5

12.2 User Guide for Reserve Management (Module) (RM) .........43

12.3 User Guide for Standing Facilities (Module) (SF) ...............48

13 ICM User Handbook ................................................ 59

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 ii

13.1 Overview on ICM ................................................................... 59

14 Technical Specifications ........................................ 60

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 iii

14.1.2.2.2.4 MT 950................................................................................................... 157

14.2 SWIFTNet InterAct and FileAct related issues ..................182

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 iv

14.3 Internet access related issues ........................................... 196

14.4 Entry check .......................................................................... 204

15 Test procedure ...................................................... 205

Glossary and Abbreviations ................................. 206

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 v

Services provided to all users

• Payments processing in the Pay- • Liquidity pooling Scope of

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 1

• Standing Facilities (Module) (SF) • Home Accounting Module (HAM) Scope of

Services provided only to central banks

• Monitoring • Billing optional services (CRISP) Scope of

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 2

mandatory services for CBs

Payments Module (PM) Standing Static Data (SD)

Central Credit Ancillary T2S actors in

Scope of this book

Structure The present document is structured as follows:

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 3

er technical aspects for the optional modules (including their interaction

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 4

12 User Guide for optional modules

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 5

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 6

Functional HAM is accessible through a SWIFTNet interface based on a V-shape mod-

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 7

"HAM accounts "CB customer’s

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 8

12.1.2 Participation in HAM

CUG A Closed User Group (CUG) is set up in order to:

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 9

others input is done by the central bank or by the co-manager (Internet-

12.1.3 Account management

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 10

On an optional basis the co-manager will be able to receive the settlement

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 11

12.1.4 Transactions processing

8 Interbank transfers from RTGS accounts to HAM accounts (accounts of different

10 Automatic transactions stemming from the RM (remuneration and penalties)

11 Automatic transactions related to billing (stemming from CRISP) (not available

Note: In the operations No. 3 and 7 same participant means a participant

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 12

The processing of transactions No. 1 to No. 8 is described in the following

optional Payment processing

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 13

3 HAM sends the payment message (MT 202 simplified) to Bank B.

Version 11.01 - 30 October 2017 - TARGET2 UDFS Book 2 14