Target2 SSP Udfs Book 2 Version 4.01 - tcm46-242572

Single Shared Platform
User Detailed Functional Specifications - Optional Services2nd book Version 4.01 29 October 2010
Table of Contents
Table of Contents
11 12
12.1
12.1.1 12.1.2 12.1.3 12.1.4 12.1.5 12.1.6 12.1.7 12.1.8 12.1.9 12.1.10
Introduction User Guide for optional modules

User Guide for Home Accounting Module (HAM) ............. 4
Overview and functional architecture ................................................. 4 Participation in HAM ............................................................................. 8 Account management ......................................................................... 10 Transactions processing .................................................................... 12 Cash reservation function .................................................................. 34 Queue management ............................................................................ 36 Operational day management ............................................................ 37 Interaction and reporting .................................................................... 38 Administration ..................................................................................... 40 Exclusion of an HAM participant ....................................................... 41
12.2
12.2.1 12.2.2 12.2.3
User Guide for Reserve Management (Module) (RM) ..... 42

General features .................................................................................. 42 Interaction and reporting for credit institutions ............................... 45 Administration tool for CBs ................................................................ 46
12.3
12.3.1 12.3.2
User Guide for Standing Facilities (Module) (SF) ........... 47

General features .................................................................................. 47 Interaction ............................................................................................ 56
13
13.1
ICM User Handbook

Overview on ICM ................................................................ 57
Version 4.01 - 29 October 2010 - TARGET2 UDFS Book 2
Table of Contents
14
14.1
14.1.1 14.1.1.1 14.1.1.2 14.1.1.3 14.1.1.3.1 14.1.1.3.2 14.1.2 14.1.2.1 14.1.2.1.1 14.1.2.1.1.1 14.1.2.1.1.2 14.1.2.1.1.3 14.1.2.1.2 14.1.2.1.2.1 14.1.2.1.2.2 14.1.2.2 14.1.2.2.1 14.1.2.2.1.1 14.1.2.2.1.2 14.1.2.2.1.3 14.1.2.2.1.4 14.1.2.2.1.5 14.1.2.2.1.6 14.1.2.2.2 14.1.2.2.2.1 14.1.2.2.2.2 14.1.2.2.2.3 14.1.2.2.2.4 14.1.2.3 14.1.2.3.1 14.1.2.3.2 14.1.2.4 14.1.2.4.1
Technical Specifications
SWIFTNet FIN related issues ............................................ 58
SWIFTNet FIN - General aspects ........................................................ 58 Bank Identifier Codes (BICs) for SSP .................................................... 58 Public Key Infrastructure (PKI) .............................................................. 61 SWIFTNet FIN messages ...................................................................... 63 Structure ................................................................................................ 63 Formatting rules for fields ...................................................................... 63 SWIFTNet FIN Messages - Details ...................................................... 65 Header and Trailer ................................................................................. 65 Header ................................................................................................... 65 Basic Header ......................................................................................... 65 Application Header ................................................................................ 65 User Header .......................................................................................... 67 Trailer .................................................................................................... 73 General description ............................................................................... 73 Handling of PDM/PDE Trailer ................................................................ 75 Textblock of the different message types .............................................. 82 Payment messages ............................................................................... 82 MT 103 .................................................................................................. 82 MT 103+ ................................................................................................ 90 MT 202 .................................................................................................. 95 MT 202 COV ........................................................................................ 105 MT 202 simplified (HAM only) ............................................................. 110 MT 204 ................................................................................................ 113 Cash flow management messages ..................................................... 115 MT 900 ................................................................................................ 115 MT 910 ................................................................................................ 122 MT 940 ................................................................................................ 133 MT 950 ................................................................................................ 139 SWIFT system messages .................................................................... 145 MT 012 ................................................................................................ 145 MT 019 ................................................................................................ 146 Examples for addressing payments .................................................... 148 Payments between HAM and PM ........................................................ 150
ii
Table of Contents
14.1.2.4.2 14.1.2.4.3
Payments between account holders in HAM ....................................... 154 Payments with proprietary home accounts .......................................... 156
14.2
14.2.1 14.2.2 14.2.3 14.2.3.1 14.2.3.1.1 14.2.3.1.2 14.2.3.1.3 14.2.3.1.4 14.2.3.1.5 14.2.3.1.6 14.2.3.1.7 14.2.3.1.8 14.2.3.2 14.2.3.2.1 14.2.3.3 14.2.3.3.1 14.2.3.3.2 14.2.3.3.3 14.2.3.4 14.2.3.4.1 14.2.3.4.2 14.2.3.4.3
SWIFTNet InterAct and FileAct related issues .............. 159

Overview ............................................................................................. 159 How to use the application-to-application approach ..................... 160 Use cases ........................................................................................... 161 Home Accounting Module ................................................................... 161 Modify reservation ............................................................................... 161 Modify standing order .......................................................................... 162 Liquidity transfer (between accounts belonging to the same participant in HAM and PM) ................................................................. 162 Regular transactions (interbank transfer between accounts belonging to different participants) ...................................................... 163 Get account ......................................................................................... 164 Get reservation .................................................................................... 165 Get transaction .................................................................................... 165 Get business day information .............................................................. 167 Reserve Management ......................................................................... 168 Get account RM ................................................................................... 168 Standing Facilities ............................................................................... 169 Liquidity transfer between SF and PM/HAM account .......................... 169 Get account SF .................................................................................... 170 Get transaction SF ............................................................................... 170 Static Data ........................................................................................... 171 Get HAM account ................................................................................ 171 Get SF account .................................................................................... 172 Get participant ..................................................................................... 173
14.3
14.3.1 14.3.2
Internet access related issues ........................................ 174

Overview ............................................................................................. 174 Account statement ............................................................................ 175
14.4
14.4.1 14.4.2
Entry check ....................................................................... 182

Double entry check for HAM ............................................................ 182 Error codes ........................................................................................ 183
iii
Table of Contents
15
Test procedures Glossary and Abbreviations
iv
11 Introduction
11
Aims
Introduction
This document aims at presenting the User Detailed Functional Specifications (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 completed by the schema files provided in an electronic form. Furthermore, detailed 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

Payments Module (PM) Information and Control Module (ICM) Contingency Module (CM) Static Data (Management) Module (SD)
Liquidity pooling Limits Liquidity reservations
Scope of Book 1
Services provided to all users subject that the relevant CB has opted for these services Mandatory Optional
Standing Facilities (Module)

(SF) Reserve Management (Module) (RM)
Home Accounting Module

(HAM)
Scope of this book
11 Introduction
Services provided only to central banks Mandatory Optional
Monitoring Archiving and other manda Static Data (specific consultation/updates by the CBs) tory CRSS services (CROSS)
Billing optional services
Scope of Book 3 (CRISP) Query and report optional services (CRAKS1) Customer relationship optional services (CRAKS3)
optional services for CBs (CRISP, CRAKS1, CRAKS3)
Payments Module (PM)

mandatory services for CBs (CROSS)
storage, archiving, files for billing calculation
Standing Facilities (SF) Home Accounting Module (HAM) Reserve Management (RM)
Static Data Management (SD) Monitoring Contingency Module (CM)
payments processing participant interface (Y-copy) Ancillary Systems Interface
standard interfaces
Information and Control Module (ICM)
CBs (internal accounting, collateral management, proprietary home accounts, etc.)
credit institutions (CI)
ancillary systems (AS) Scope of this book
11 Introduction
Structure
The present document is structured as follows:
Chapter 12 User Guide for optional modules

User guide for optional modules presents the user functionality of the different optional modules proposed by the SSP.
Chapter 13 ICM User Handbook

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 provided in a separate document ICM User Handbook I.
Chapter 14 Technical Specifications

Technical specifications present the use of the SWIFT reference to PM and HAM, the description of the messages used within the SSP and other technical aspects for the optional modules (including their interaction with core modules). The use of Internet access is also present.
Chapter 15 Test procedures

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) 12.1.1 Overview and functional architecture
12
12.1
12.1.1
Overview
User Guide for optional modules

User Guide for Home Accounting Module (HAM)
Overview and functional architecture
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 customers 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 requirements 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 number 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 customers accounts, even if held at the same CB, are not allowed.

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

CB customers accounts: Transactions allowed
The following diagram shows the transactions allowed from/to CB customers accounts:
CB1 Other CBs
RTGS accounts
CB's customer accounts
Functional architecture
HAM is accessible through a SWIFTNet interface based on a V-shape model. 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). Internet-based participant are not allowed to perform MT 202 but only liquidity 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 customers accounts can be triggered via:
MT 202, MT 202 COV (Bank to Bank payment with customer credit

transfer 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
FIN msgg MT 202/900/910/940/950 (Browse/InterAct/FileAct, Reporting, Administration, Monitoring, data for general ledger, central bank operations)
"HAM accounts holders"

FIN msgg MT 202/900/910/940/950

"CB customer's accounts holders"

FIN msgg MT 202/202 COV/ 103/103+/900/910/940/950
(Browse/InterAct Cash reporting)
(Browse/InterAct Cash reporting)
SWIFTNet SWIFT Interface RM HAM Liquidity bridge SF PM
INTERNET
"HAM accounts holders"

Low volume participant
Liquidity transfer
"CB customer's accounts holders"

Low volume participant
FIN msgg MT 202/202 COV/103/103+

12.1 User Guide for Home Accounting Module (HAM) 12.1.2 Participation in HAM
12.1.2
Participants
Participation in HAM
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
directly nor indirectly) CB customers accounts can be opened by institutions (not allowed to open accounts in the PM according to TARGET Guideline) which are customers 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 customers accounts).
Allow those participants that are not full member of SWIFT to open
accounts 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 Participant (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 customers account holders taking into account that different addresses are used for sending the transactions and that the reverse billing function is used only for HAM account holders.

12.1 User Guide for Home Accounting Module (HAM) 12.1.2 Participation in HAM
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 transactions can be done directly only by participants using Internet access, for the 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.

12.1 User Guide for Home Accounting Module (HAM) 12.1.3 Account management
12.1.3
Account management
Account management
As regards the account 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 150.
The group of accounts function is dedicated to RTGS accounts in PM

and hence not available on the HAM. For CB customers accounts, a specific function is provided to CBs in order 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.
10

12.1 User Guide for Home Accounting Module (HAM) 12.1.3 Account management
Internet-based participants cannot act as co-manager even though they can be co-managed. Other features For both HAM accounts and CB customers 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 account) functionality. CBs are able to debit and credit all the accounts held by their CB customers/HAM account holders both via SWIFTNet FIN (using the MT 202 Simplified for HAM accounts and the MT 202 Standard, MT 202 COV and MT 103/103+ for CB customers accounts) and via ICM (HAM Internet-based participant can only use the ICM liquidity transfer (other account) functionality). Banks holding both an HAM account and an account in the PM have access to an automatic transfer function for start-of-day (either for the whole balance 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.
11

12.1 User Guide for Home Accounting Module (HAM) 12.1.4 Transactions processing
12.1.4
Transactions related to HAM accounts
Transactions processing
All the transactions settled through the HAM are immediately final. The following operations can be settled on the HAM accounts:
No. 1 2 3 4 5 6 7 8 9 10 11 Operation Interbank transfer between HAM accounts (held at the same central bank) including operations with the own central bank (eg cash withdrawals and deposits, etc.) Interbank transfer between HAM accounts (held at the same central bank) initiated by a PM co-manager Liquidity transfer from HAM accounts to RTGS accounts (accounts held by the same participant) Interbank transfers from HAM accounts to the RTGS account (accounts of different participants also in case the accounts are held by different CBs) Interbank transfers from HAM accounts to the RTGS account (accounts of different participants) initiated by a co-manager Interbank transfers from HAM accounts to the RTGS account of the co-manager Liquidity transfers from RTGS accounts to HAM accounts (both accounts held by the same participant) Interbank transfers from RTGS accounts to HAM accounts (accounts of different participants) Transfers with the SF in order to have access to the standing facilities (only via ICM) Automatic transactions stemming from the RM (remuneration and penalties) 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 an 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.
12

Interbank transfers between HAM accounts
Interbank transfer between HAM accounts (held at the same central bank) (No. 1):
Bank A Bank B
SWIFTNet FIN MT 202 "Simplified" 1 MT 900 4 MT 910 4
MT 202 "Simplified" 3
Participant Interface 2 optional message Booking Payment processing
HAM
Step 1 2 3 4
Description Sender (Bank A) generates a payment message (MT 202 simplified) and addresses it to HAM, with beneficiary Bank B. HAM debits Bank As account and credits Bank Bs account. HAM sends the payment message (MT 202 simplified) to Bank B. 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.
13

Note: CIs have the possibility to choose separately whether to receive the debit (MT 900) and/or credit notification (MT 910) (Internet-based participants 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 transfers between HAM accounts initiated by a co-manager Interbank transfer between HAM accounts (held at the same central bank) initiated by a co-manager (No. 2):
Co-manager
(PM participant)
Co-managed
(HAM participant)
Bank B
(HAM participant)
SWIFTNet FIN MT 900 MT 202 "Simplified" 1 MT 900 4 4 MT 202 "Simplified" 3 MT 910 4
HAM
Step 1
Description Co-manager generates a payment message (MT 202 simplified) and addresses it to HAM, with beneficiary Bank B, setting as debtor the co-managed.
14

12.1 User Guide for Home Accounting Module (HAM) 12.1.4 Transactions processing Step 2 3 4 Description HAM debits co-managed account and credits Bank Bs account. HAM sends the payment message (MT 202 simplified) to Bank B. 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 transfers from HAM accounts to RTGS accounts in PM (same participant) (SWIFT-based)
Liquidity transfer from HAM accounts to RTGS accounts (same participant) (No. 3):
SWIFTNet FIN
Bank A
3 MT 900 7 MT 910
Bank A
4 Participant Interface 2 Booking Payment processing Notification 6 Internal message 5 Participant Interface Booking Payment processing
HAM
optional message
PM
Step 1
Description 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). HAM debits the HAM account of Bank A and credits the account of the CB.
15

12.1 User Guide for Home Accounting Module (HAM) 12.1.4 Transactions processing Step 3 4 5 6 7 Description On an optional basis the debit notification (MT 900) is sent to Bank A and the credit notification (MT 910) is sent to the CB. HAM sends an internal message (MT 202 simplified) to PM. PM debits the account of the CB and credits the RTGS account of Bank A. PM sends a notification to HAM. On an optional basis, PM sends the credit notification (MT 910) to Bank A and the debit notification (MT 900) to the CB.
Interbank transfers from HAM accounts to RTGS accounts in PM (different participants also in case of accounts held at different central banks)
Interbank transfers from HAM accounts to the RTGS account of another participant (No. 4):
SWIFTNet FIN
Bank A
3 MT 900 MT 202 7
Bank B
4 Participant Interface 2 Booking Notification Payment processing 6 Payment processing Internal message 5 Participant Interface Booking
HAM
optional message
PM
16

Step 1 2 3 4 5 6 7 8
Description Sender (Bank A) generates a transfer message (MT 202 simplified) and addresses it to HAM, with beneficiary PM participant (Bank B). HAM debits the account of Bank A and credits the account of the CB of Bank A. On an optional basis the debit notification (MT 900) is sent to Bank A and the credit notification (MT 910) is sent to the CB. HAM sends an internal message (MT 202 simplified) to PM. PM debits the account of the CB of Bank A and credits the account of Bank B. PM sends a notification to HAM. PM sends an MT 202 (based on data of MT 202 simplified) to Bank B. 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)
17

Interbank transfers from HAM accounts to RTGS accounts initiated by a co-manager
Interbank transfers from HAM accounts to the RTGS account of another participant initiated by a co-manager (No. 5):
Co-managed
(HAM participant) SWIFTNet FIN
Co-manager
(PM participant) MT 202 "Simplified" 1
3 MT 900
3 MT 900
Bank B
(PM participant) MT 202 7
4 Participant Interface 2 Booking Payment processing Internal message 5 Participant Interface Booking Payment processing
Notification 6
HAM
optional message
PM
Step 1 2 3 4 5
Description 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. HAM debits the co-managed account and credits the account of the CB of the co-managed. 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 the CB. HAM sends an internal message (MT 202 simplified) to PM. PM debits the account of the CB of the co-managed and credits the account of Bank B.
18

12.1 User Guide for Home Accounting Module (HAM) 12.1.4 Transactions processing Step 6 7 8 PM sends a notification to HAM. PM sends an MT 202 (based on data of MT 202 simplified) to Bank B. On an optional basis PM sends the debit notification (MT 900) to the CB. Description
Interbank transfers from HAM accounts to the RTGS account of the co-manager
Interbank transfers from HAM accounts to the RTGS account of the co-manager (No. 6):
Co-managed
(HAM participant) SWIFTNet FIN
Co-manager
(PM participant) MT 202 "Simplified" 1
3 MT 900
3 MT 900
7 MT 202
Co-manager
(PM participant)
4 Participant Interface 2 Booking Payment processing Internal message 5 Participant Interface Booking Payment processing
Notification 6
HAM
optional message
PM
Step 1 2
Description 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. HAM debits the co-managed account and credits the account of the CB of the co-managed.
19

12.1 User Guide for Home Accounting Module (HAM) 12.1.4 Transactions processing Step 3 4 5 6 7 8 Description 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 the CB. HAM sends an internal message (MT 202 simplified) to PM. PM debits the account of the CB of the co-managed and credits the account of the co-manager. PM sends a notification to HAM. PM sends to the co-manager the MT 202 (based on data of MT 202 simplified). On an optional basis PM sends the debit notification (MT 900) to the CB.
Liquidity transfers from RTGS accounts in PM to HAM accounts (same participant)
Liquidity transfers from RTGS accounts to HAM accounts (same participant) (No. 7):
SWIFTNet FIN 2 1 MT 202 9 MT 202 MT 097 MT 096
Bank A
MT 910 10
10 MT 202 simplified
Bank A
Participant Interface 6 Booking Payment processing
5 Internal message
Participant Interface (Y-copy) 4 Booking Acknowledgement
7 Notification
Payment processing
HAM
optional message
PM
20

Step 1
Description 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. The payment is temporarily stored by SWIFT. A settlement request (MT 096) is sent to PM. PM debits the Bank As RTGS account and credits the account of the CB. On an optional basis, PM sends the credit notification (MT 910) to the CB. PM sends to HAM an internal message (MT 202 simplified). HAM debits the account of the CB and credits the HAM account of Bank A. HAM sends a notification to PM. PM generates a settlement confirmation (MT 097) and sends it to SWIFT. SWIFT sends the stored payment (MT 202) to PM (useless leg of Y-copy). 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.
2 3 4 5 6 7 8 9 10
21

Interbank transfers from RTGS accounts in PM to HAM accounts (different participants)
Transfers (interbank) from RTGS accounts to HAM accounts (different participants) (No. 8):
SWIFTNet FIN
Bank A
MT 910 11
10 MT 202 simplified 9 MT 202

MT 097 MT 096
1 MT 202
Bank B
Participant Interface 6 Booking Payment processing
5 Internal message
Participant Interface (Y-copy) 4 Booking Acknowledgement
7 Notification
Payment processing
HAM
optional message
PM
Step 1
Description 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. The payment is temporarily stored by SWIFT. A settlement request (MT 096) is sent to PM. PM debits the Bank Bs account and credits the account of the CB of Bank A. PM sends to HAM an internal message (MT 202 simplified); on an optional basis the credit notification (MT 910) is sent to the CB. HAM debits the account of the CB of Bank A and credits the HAM account of Bank A. HAM sends a notification to PM.
2 3 4 5 6 7
22

12.1 User Guide for Home Accounting Module (HAM) 12.1.4 Transactions processing Step 8 9 10 11 Description PM generates a settlement confirmation (MT 097) and sends it to SWIFT. SWIFT sends the stored payment (MT 202) to PM (useless leg of Y-copy). HAM sends the notification (MT 202 simplified) to Bank A. 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 account 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

either 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 information (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 internal 202 message according to the entered payment information and will send this message to HAM, where the HAM participant is credited (Internet-based participants will get no confirmation via MT 900/910).
23

Payments of CB customers accounts
CB customers accounts can process:

No. 1 2 3 4 Operation Payments (customer and interbank) between CB customers accounts held at the same central bank Payments (customer and interbank) between CB customers accounts held at different central banks Payments (customer and interbank) from CB customers accounts to RTGS accounts (held at the same or at a different CB) Payments (customer and interbank) from RTGS accounts to CB customers accounts (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.
24

Payments between CB customers accounts (same CB)
Payments (customer and interbank) between CB customers accounts held at the same central bank (No. 1):
CB customer A
SWIFTNet FIN MT 202/ MT 103/ MT 103+ 1 MT 202/ MT 103/ MT 103+ 3
CB customer B
MT 910 4
MT 900 4
HAM
Step 1 2 3 4
Description Sender (CB customer A) generates a payment message (MT 202/202 COV/103/ 103+) and addresses it to HAM, with beneficiary CB customer B. HAM debits CB customer As account and credits CB customer Bs account. HAM sends the payment message (MT 202/202 COV/103/103+) to CB customer B. 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 participant:

Only steps 1 and 2 applicable.
25

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 structure) 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:

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 message structure) to HAM, where the necessary booking information is extracted. Then the payment will be settled and no other message will follow.
26

Payments between CB customers accounts (different CBs)
Payments between CB customers accounts held at different central banks (No. 2):
CB A Customer A
1 MT 202/ MT 103/ MT 103+
CB B Customer B
SWIFTNet FIN 12 MT 910 MT 097 MT 096 9 MT 202/ MT 103/ MT 103+ 5
11 MT 202/ MT 103/ MT 103+ 3 MT 900
4 MT 202/ MT 103/ MT 103+
Participant Interface 2 Booking 10 Booking Addressed to CB B in HAM
Participant Interface (Y-copy) 7 Booking Payment processing
Payment processing
HAM
optional message
PM
Step 1 2 3
Description Sender (CB customer A) generates a payment message (MT 202/202 COV/103/ 103+) and addresses it to HAM, with beneficiary CB customer B. HAM debits CB customer As account and credits the relevant CB account (CB As account). On an optional basis the debit notification (MT 900) is sent to CB customer A and the credit notification (MT 910) is sent to the CB.
27

12.1 User Guide for Home Accounting Module (HAM) 12.1.4 Transactions processing Step 4 Description HAM sends the payment message (MT 202/202 COV/103/103+) to SWIFT, addressed to the BIC TRGTXECBccX (where cc is the country code representing CB B + X). The payment is temporarily stored by SWIFT. A settlement request (MT 096) is sent to PM. PM debits the account of the CB of CB customer A and credits the account of the CB of CB customer B. PM generates a settlement confirmation (MT 097) and sends it to SWIFT. SWIFT sends the stored payment (MT 202/202 COV/103/103+) to the BIC TRGTXECBccX. HAM debits the account of the CB of CB customer B and credits CB customer B account. HAM sends the payment message (MT 202/202 COV/103/103+) to CB customer B. 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.
5 6 7 8 9 10 11 12
Note:

Steps 11 and 12 not applied;

The Internet-based CB customer can enter MT 103(+) and MT 202 (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 MT 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.
28

Payments from CB customers accounts to RTGS accounts in PM
Payments from CB customers to RTGS accounts (No. 3):

1 SWIFTNet FIN MT 202 / MT 103 / MT 103+ 4 MT 202 / MT 103 / MT 103+ 5 9 MT 202 / MT 103 / MT 103+
Customer A
Bank B
MT 096
MT 900
MT 097
Participant Interface 2 Booking Payment processing 7
Participant Interface (Y-copy) Booking Payment processing
HAM
optional message
PM
Step 1 2 3 4 5 6 7
Description Sender (CB customer A) generates a payment message (MT 202/202 COV/103/ 103+) and addresses it to HAM, with beneficiary Bank B. HAM debits CB customer As account and credits the relevant CB account (CB As account). On an optional basis the debit notification (MT 900) is sent to CB customer A, and the credit notification (MT 910) is sent to the CB. HAM sends the payment message (MT 202/202 COV/103/103+) to SWIFT. The payment is temporarily stored by SWIFT. A settlement request (MT 096) is sent to PM. PM debits the account of the CB of CB customer A and credits the Bank Bs account.
29

12.1 User Guide for Home Accounting Module (HAM) 12.1.4 Transactions processing Step 8 9 Description PM generates a settlement confirmation (MT 097) and sends it to SWIFT. 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.

The Internet-based CB customer can enter MT 103(+) and MT 202 (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 MT 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.
30

Payments from RTGS accounts in PM to CB customers accounts
Payments from RTGS accounts to CB customers accounts (No. 4):

SWIFTNet FIN MT 202 / MT 103 / MT 103+ 6 MT 202 / MT 103 / MT 103+ 8 2 1 MT 202 / MT 103 / MT 103+
Customer A
Bank B
9 MT 096 MT 910 3 MT 097
Participant Interface 7 Booking Payment processing 4
Participant Interface (Y-copy) Booking Payment processing
HAM
optional message
PM
Step 1
Description 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. The payment is temporarily stored by SWIFT. A settlement request (MT 096) is sent to PM. PM debits the Bank Bs account and credits the relevant CB account (CB of CB customer A). PM generates a settlement confirmation (MT 097) and sends it to SWIFT. SWIFT sends the stored payment (MT 202/202 COV/103/103+) to HAM. HAM debits the account of the CB of CB customer A and credits the CB customer As account.
2 3 4 5 6 7
31

12.1 User Guide for Home Accounting Module (HAM) 12.1.4 Transactions processing Step 8 9 Description HAM sends the notification (MT 202/202 COV/103/103+) to CB customer A. On an optional basis the credit notification (MT 910) is sent by HAM to CB customer 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 information (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 information (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 payments Overview 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
32

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 183 of this document. Note: In case of an Internet-based participant as sender, the rejection is only 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. Incorrect payments are also displayed for the sending, the debtor and the creditor participants. As the ICM access is still possible for excluded participants, payments involving 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 in HAM

These entry validations will be reflected in the list of error codes described in chapter 14.4.2 Error codes, page 183 of this document. Payments will be rejected if they are not made up according to these standards.
33

12.1 User Guide for Home Accounting Module (HAM) 12.1.5 Cash reservation function
12.1.5
Cash reservation function
HAM account holders are able to reserve a certain amount for cash withdrawals. They can manage in real-time, through the ICM only, the parameters of the reservation process in order to set and change the amount reserved. 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 processed.
for future dates, on the basis of a daily value or a default value. The reservation 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 liquidity on the HAM account is sufficient for the reservation:
Enough liquidity available Requested amount will be reserved. Not enough liquidity available
The liquidity available on the account The rest of the liquidity will be blocked
when the account is credited until the balance reaches the level of the reservation request. is reserved.
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 becomes available for any kind of payment. The information about the cash reservation is available through ICM (only pull mode).
34

12.1 User Guide for Home Accounting Module (HAM) 12.1.5 Cash reservation function
Other forms of reservation (eg for urgent payments) are not possible; furthermore, no liquidity saving features are available.
35

12.1 User Guide for Home Accounting Module (HAM) 12.1.6 Queue management
12.1.6
Queue management
HAM provides a centralised queuing mechanism for transactions temporarily 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 mechanism 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 authorised to cancel transactions pending in the queue. The cancellation is executed by the CB via ICM. The way of communication between the CIs and the CB is up to each CB.
CB customers account holders can ask their CB to change, via ICM,

the order of queued transactions. No gridlock resolution mechanism is available (only queue scanning).
36

12.1 User Guide for Home Accounting Module (HAM) 12.1.7 Operational day management
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, dependencies). 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.
37

12.1 User Guide for Home Accounting Module (HAM) 12.1.8 Interaction and reporting
12.1.8
Information via ICM
Interaction and reporting
Through the Information and Control Module credit institutions/CB customers have real-time access to the functions listed in the following table regarding the current business day.
Type of information Liquidity position Content HAM account X X CB customers account X
Account balance Reserved funds for cash withdraw Funds above a pre-defined threshold als
X X X X X X X X X X X X X X X X X X X X X X X
Transactions processing
Transaction details Status of transactions Content of the outgoing queue Content of the incoming queue View of transactions delivered in advance TARGET2 directory System availability Operating day cut-off times System broadcast System status Management of the reservation function for cash withdrawals Management of the standing order for liquidity transfers from the HAM account to the RTGS account account of the same participant Transfers with the Standing Facilities Module from/to RTGS account of another participant
Status of the System
Parameters
Liquidity transfers
Transfers from/by the RTGS
X X X
Regular transactions
Interbank transfer within HAM or
38

12.1 User Guide for Home Accounting Module (HAM) 12.1.8 Interaction and reporting
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 customers 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 interface. 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 responsibility 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 transfer of the same raw data are provided to those CBs that decide to use an internal data warehouse. Data sent to these CBs are limited to their own data.
39

12.1 User Guide for Home Accounting Module (HAM) 12.1.9 Administration
12.1.9
Administration via ICM
Administration
CBs have the responsibility of the administration of the Home Accounting Module with reference to their own CB customers/HAM account holders. Through the Information and Control Module CBs have, furthermore, real-time access to the administration functions listed in the table below regarding the current business day (functions available for credit institutions/CB customers are also available for CBs if acting on behalf of CI/CB customers). Obviously each CB is able to manage only the account of its own credit institutions/customers.
Type of information Administration Content
Opening/closing of accounts in HAM Management of the TARGET2 directory Management of the co-management directory Management of threshold for CB customers 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 (backup transactions) Production of a number of reports Inquiries on messages received/sent Management of queued transactions on behalf of their customers Cancellation of queued transactions on behalf of their credit institutions/customers Sending of broadcasts Monitoring tools (operational, liquidity and technical monitoring) in order to verify the smooth functioning of the system with reference to the respective credit institutions
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.)
40

12.1 User Guide for Home Accounting Module (HAM) 12.1.10Exclusion of an HAM participant
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 warehoused 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 before his exclusion will be in the waiting queue for confirmation by the central bank of the HAM account holder before the EoD otherwise they will be rejected.
41

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

General features
The Reserve Management Module (RM) enables the CBs to perform some functionality for the reserve requirements management. The module is accessible through a SWIFTNet interface or dedicated Internet access and can interact with PM, HAM and proprietary home accounting systems. The RM does not manage any kind of accounts. It only receives - automatically at the end-of-day - from PM, HAM and proprietary home accounts the end-of-day accounts balances in order to manage minimum reserves. The RM will mainly:
verify the minimum reserve fulfilment. calculate the interest to be paid to credit institutions for minimum
reserves.
calculate the penalties related to the reserve requirements infringement

to be submitted to the relevant CBs validation process.
notify the CBs on the minimum reserve fulfilment, due interest and possible penalties for the pertaining credit institutions.
create automatically the related credit and debit instructions (the latter
only after the CB validation process) and send them to PM or HAM (at the end of the maintenance period). Note: Interest for minimum reserves are credited 2 working days after the closing of each maintenance period, taking as reference the TARGET2 calendar. Penalties 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 an HAM/PHA account, but not on both.
42

Indirect reserve
The RM offers also the possibility of managing indirectly the reserve requirements, according to the General documentation on Eurosystem monetary policy instruments and procedures. On the basis of the list of credit institutions that decide to fulfil indirectly minimum reserves and of the banks selected for its management, the RM is able to verify the fulfilment of minimum reserves.
Pool of reserve accounts of an MFI
Within RM the so-called pool of reserve accounts of a Monetary Financial Institution (MFI), which enables the fulfilment of reserve requirements for a 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 (i.e. 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 associated 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.
43

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 themselves of the minimum reserve pooling functionality cannot make use of the indirect reserve management.
NCB
End-of-day balances
HAM/PM
Reserve Management Module or RM
Minimum reserve Remuneration rate Penalties
Payment order (at the end of the maintenace period) - interest - penalties for infringement after CB validation process
44

12.2 User Guide for Reserve Management (Module) (RM) 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:
Type of information Minimum reserve Balances Content
Amount of required reserve End-of-day balances of the previous Running average up to the previous
business day business 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 intermediary (only its own minimum reserve; end-of-day balance, running average 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 reserves of the represented institutions)
the participants belonging to the same MFI (with the detail of the individual balances of participants belonging to the MFI)
45

12.2 User Guide for Reserve Management (Module) (RM) 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 functions listed in the following table:
Type of information Minimum reserve Balances Content
Amount of required reserve End-of-day balance of the previous Running average up to the previous
business day business day
Adjustment balance Administration functions
Balance necessary to fulfil the minimum reserve
Management of the list of credit institutions subject to reserve requirements (including the MFI grouping and indirect relationships) 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 remuneration and penalties rates (common parameters for all CBs that can be inserted by a single point, that could be the SSP operational team) Monitoring tools to have access to summarised information concerning minimum reserves (eg Minimum reserve, Running average and End-of-day balances at the system level)
46

12.3 User Guide for Standing Facilities (Module) (SF) 12.3.1 General features
12.3
12.3.1
Overview
User Guide for Standing Facilities (Module) (SF)

General features
The Standing Facilities Module (SF) enables the CBs to manage the standing 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 interaction 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 account 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 automatic 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 instructions 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 evaluation process accuracy) carried out by the collateral manager. The SSP only checks the formal correctness of the message sent by the collateral manager. 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.
47

The following diagram provides a general overview of the SF module functioning:
HAM/PM
Overnight deposit End-of-day transfers to SF (business day d)
SF
Overnight deposit account
NCB
Account
Transfers of capital and interest to HAM/PM (start of business d +1) Marginal Lending Transfers to HAM/PM (business day d) Transfers to SF and debiting of interest in HAM/PM (start of business day d+1)
Marginal lending account
Collateral management for marginal lending
48

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 account; 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. The process related to the overnight deposit is described in the following diagram and tables:
1
Modify
1
Modify
CI
CI 2
Transfer order
CI 2
Transfer order
ICM
ICM
ICM
SF 4
MT 900
3 4
ACK Direct debit
SF 4
MT 910
3 4
ACK Liquidity transfer
SF 2
MT 910
1 2
ACK Liquidity transfer
PM (HAM)
PM (HAM)
PM (HAM)
SSP
(SF credits the overnight deposit account)
SSP Setting up Reverse transaction

(SF debits the overnight deposit account)
SSP Refunding + interest

(at start-of-day)
49

Setting up Step 1 Description The credit institution (CI) sends (via ICM) an order with an indication of the account 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 envisaged. The order is transferred from ICM to SF The SF sends a direct debit internal message to PM/HAM. PM/HAM debits the CI account and credits the CB account. 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 1 2 3 4 Description The CI sends (via ICM) an order to transfer liquidity from overnight deposit account to the HAM/RTGS account. The order is transferred from ICM to SF. 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. 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 1 Description SF calculates the interest to be paid on the overnight deposit and, at the start of the following business day, debits the CI account and credits the CB account for the capital amount, and sends two distinct internal messages to PM/HAM (capital amount and interest). PM/HAM debits the CB account and credits the CI account. PM/HAM sends a notification to SF and (optionally) the MT 910 to the CI and the MT 900 to the CB.
2 3 4
Note: Internet-based participants will get no confirmation via MT 900/910.
50

Overnight deposit for outs
The overnight deposit function is available also for out countries. The process 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. Considering that interest can be credited not the first business day of the following 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.
51

Marginal lending facility on request
The process related to marginal lending on request is described in the following diagram and table:
Collateral manager
1
Modify
CI
Collateral manager
CI
ICM
2
Transfer Request
ICM 3
SF 4
ACK
Liquditiy transfer
4
MT 910
Notify refunding
SF 2
Direct debit
2
MT 900
SSP
PM (HAM)
ACK
SSP
PM (HAM)
(SF debits the marginal lending account)
Setting up
Refunding + interest
(at start-of-day)
Setting up Step 1 Description 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. The order is transferred from ICM to SF. 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. PM/HAM sends the acknowledgement to SF and sends (optionally) the MT 910 to the credit institution and the MT 900 to the CB.
2 3
52

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 collateral.
Refunding and interest payment - start of the following business day Step 1 Description 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. 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. 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.
53

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

(at start-of-day)
Setting up - end-of-business day Step 1 Description 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. 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 internal message to PM in order to transfer the liquidity to the RTGS account and simultaneously decrease the respective credit line (connected payment). 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.
2a
2b
54

12.3 User Guide for Standing Facilities (Module) (SF) 12.3.1 General features Setting up - end-of-business day Step 3 Description 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. Refunding and interest payment - start of the following business day Step 1 Description SF calculates the interest to be paid by the credit institutions on the marginal lending 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). 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).
55

12.3 User Guide for Standing Facilities (Module) (SF) 12.3.2 Interaction
12.3.2
Overview
Interaction
Through the ICM credit institutions have access to the information listed in the following table, regarding the current business day:
Type of information Balances Content
Current balance of the overnight deposit account Current balance and available liquidity of the marginal
lending account
Transactions processing Liquidity transfers
Transactions details Transfers with the HAM/PM
Through the ICM CBs have access to the functions listed in the following table, regarding the current business day:
Type of information Balances Content
Current balance of the overnight deposit account Current balance and available liquidity of the marginal
lending account
Transactions processing Liquidity transfers Administration
Transactions details Transfers with the HAM/PM Updating of the register of participants eligible to make 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 request and automatic marginal lending). use of standing facilities
56
13 ICM User Handbook

13.1 Overview on ICM
13
13.1
Detailed information
ICM User Handbook

Overview on ICM
Detailed information on the ICM, the related screens and the user roles is provided in a separate document ICM User Handbook I.
57
14 Technical Specifications
14.1 SWIFTNet FIN related issues 14.1.1 SWIFTNet FIN - General aspects
14
14.1
14.1.1
14.1.1.1
Overview
Technical Specifications
SWIFTNet FIN related issues
SWIFTNet FIN - General aspects
Bank Identifier Codes (BICs) for SSP
The SSP uses several BICs for different purposes. The following diagram gives an overview of all BICs:
S: BIC of participant R: TRGTXEPMHAM / TRGTXEPMASI / TRGTXEPMLVP
S: BIC of participant R: TRGTXEHMXXX / TRGTXECBccX
PM participant
HAM participant
S: TRGTXEPMXXX / TRGTXEPMASI / TRGTXEPMLVP R: BIC of participant
S: TRGTXEHMXXX / TRGTXECBccX R: BIC of participant
PAPSS PM
no BICs used
HAM
S: TRGTXEPMXXX R: BIC of CB S: BIC of CB R: TRGTXEPMXXX
proprietary home accounting
CB
payment liquidity transfer ccc ccX S R SWIFT service code country code + X Sender Receiver
58
BICs of PM
The following table lists the different purposes and the BICs used:
Purpose Sending of messages directly from PM to PM participants Proposed BIC TRGTXEPMXXX Usage Used as sender in the SWIFT header for all messages sent directly from PM to PM participants 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) Maintenance permanent
Sending of MT 940/950 from PM to PM participants Incoming liquidity transfers from proprietary home accounting systems Liquidity transfer from one PM participant to another PM participant Incoming fund transfer from a PM participant to HAM Liquidity transfer via ASI
TRGTXE2MXXX or TRGTXE3MXXX
Used as sender in the SWIFT permanent header; for technical reasons the account statements are sent out to the participants by two different BICs. Used as receiver in the SWIFT header for payments (liquidity transfers) exchanged between proprietary home accounting systems and PM. Used as receiver in the SWIFT header of MT 202 (liquidity transfers). Ordering institution in field 52 is equal to the beneficiary institution in field 58 (ie creditor). Used as receiver in the SWIFT header for payments (fund transfers) exchanged between a PM participant and an HAM account holder. Used as sender/receiver in the SWIFT header for liquidity transfers exchanged between a participant and an ancillary system (AS). permanent
TRGTXEPMXXX
TRGTXEPMXXX
permanent
TRGTXEPMHAM
permanent
TRGTXEPMASI
permanent
59
14.1 SWIFTNet FIN related issues 14.1.1 SWIFTNet FIN - General aspects Purpose Payments from or to an Internet-based direct participant Sending of MT 940/950 from CM to PM participants Proposed BIC TRGTXEPMLVP Usage Used as sender/receiver in the SWIFT header for Y-copy payments exchanged between a PM participant and an Internet-based direct participant. Used as sender in the SWIFT Header for MT 940/950 sent from CM to PM participants. Maintenance permanent
TRGTXEPMCON
permanent
BICs of HAM
Purpose Messages sent from/received by HAM participants Proposed BIC Usage Maintenance permanent TRGTXEHMXXX Used when FIN messages are sent/received by this module via SWIFTNet FIN. In the header of the following SWIFT messages sent by the HAM this BIC will be used as sender/receiver: MT 202 simplified MT 900 MT 910 MT 940 MT 950 TRGTXECBccX ccX: country code + X of the different central banks Used as: Receiver in the HAM for the payments send by the CB customer. Sender in the HAM for the notification of the payments received from PM participants. Sender/receiver in the messages exchanged between HAM and PM for the CB customer traffic
Payments from HAM to PM and vice versa for CB customer payments
permanent; member of the PM Y-copy CUG
60
14.1 SWIFTNet FIN related issues 14.1.1 SWIFTNet FIN - General aspects Purpose Messages sent to CB customers Proposed BIC TRGTXECBccX Usage In the header of the following SWIFT messages: MT 900 MT 910 MT 940 MT 950 MT 103/103+ MT 202/MT 202 COV Maintenance permanent
BICs used by CBs
Purpose BICs for proprietary home accounting systems Usage Maintenance These BICs do not need to be changed. It is up to permanent each CB keeping a proprietary home accounting system to decide whether the old BIC should remain valid or a new BIC should be used.
Usage of the format D in bank fields
TARGET2 supports the use of STP rules envisaging the use of format A for all bank fields. Nevertheless, in order to avoid operational difficulties for the processing of payments coming from /sent to outside the EU the use of format D is allowed in specific fields.
14.1.1.2
Use of PKI in the SSP environment
Public Key Infrastructure (PKI)
The SSP will use the core PKI provided by SWIFT, no additional information will be provided in the User Detailed Functional Specifications. All information needed will be 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. Considering that the Closed User Group feature can effectively prevent unsolicited 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
61
(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 aspects 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 PM users SSP Correspondent BIC Signing BIC for T&T SWIFT Service Frequency of exchange Granularity Type of RMA SSP Correspondent BIC Signing BIC for T&T SWIFT Service Frequency of exchange Granularity Type of RMA SSP Correspondent BIC Signing BIC for T&T SWIFT Service Frequency of exchange Granularity Type of RMA TRGTXEPM swift.fin Permanent authorisation All message category/type both send/receive HAM users TRGTXEHM swift.fin Permanent authorisation All message category/type both send/receive CB customers TRGTXECB swift.fin Permanent authorisation All message category/type both send/receive TRGTXEC0 TRGTXECB swift.fin!p Permanent authorisation All message category/type both send/receive TRGTXEH0 TRGTXEHM swift.fin!p Permanent authorisation All message category/type both send/receive TRGTXEP0 TRGTXEPM swift.fin!p Permanent authorisation All message category/type both send/receive T&T
62
14.1.1.3
14.1.1.3.1 General Definition of the structure of blocks
SWIFTNet FIN messages

Structure
SWIFTNet FIN messages are structured in blocks. Each block of a message contains a special type of data. Each block begins and ends with a brace ({}). The first two characters in a block are its number and the separator (:). A SWIFT message therefore has the following structure:

Building up of header and trailer
{1: Basic Header Block} {2: Application Header Block} {3: User Header Block} {4: Text Block} {5: Trailer}
Header and trailer are always build up following the same schema. For the 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 65. 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 specified by their length and the permitted contents.
63
Specification of the field length
The following table summarises the display formats for the field length:
Field length n n! n*m Exact n characters n lines at a maximum of m characters each Meaning Maximum n characters
Specification of the field content
The following table summarises the display formats of the field contents:
Field content n a x c d h Digits from 0 to 9 Capital letters from A to Z Any character of the SWIFT character font, capital and small letters Capital letters from A to Z, and digits between 0 and 9 Digits from 0 to 9 and comma for showing currency amounts Hexadecimal number: Digits from 0 to 9 and capital letters from A to F Meaning
Optional field contents are shown in brackets (eg [34x]). Field status The following table summarises the display formats for the field status:
Status M O ----> Mandatory field Optional field Repetitive sequence in a message. The following fields may appear several times (up to a given maximum). End of the repetitive sequence Meaning
----|
64
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details
14.1.2
14.1.2.1
14.1.2.1.1
SWIFTNet FIN Messages - Details

Header and Trailer
Header
14.1.2.1.1.1 Basic Header Usage Structure The basic header is used in every message type sent to or received from the SSP. The basic header has the following structure :
Basic Header Status M M M M Field name Block Identifier Application Identifier Service Identifier LT Address 1: F 01 4!a2!a2!c1!c3!c Format F = FIN BIC+LT, 12 digits Message from participant to FIN: Senders LT address Message from FIN to participant: Receivers LT address Use in SSP
M M
Session Number Sequence Number
4!n 6!n
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 delivers a message to, or receives one from, the SWIFT network.
65
Structure when sending a message
The following table describes the structure of the application header when a participant sends a message to the SWIFT network. (It is an outgoing payment from the participants point of view.)
Application Header Status M M M M Field name Block Identifier Input/Output Identifier Message Type Destination Address 2: I 3!n 4!a2!a2!c1!c3!c Format I = Input for SWIFT 103, 202, 204 BIC+LT, 12 digits (Receivers 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) M O O Message Priority Delivery Monitoring Obsolescence Period N or U 1!n 3!n PM: Not relevant! Use in SSP
66
Structure when receiving a message
The following table describes the application header when the participant receives the message from the SWIFT network. (It is an incoming message from the participants point of view.)
Application Header Field name Block Identifier Input/Output Identifier Message Type Input Time Message Input Reference Date Time Message Priority 2: O 3!n HHMM 6!n4!a2!a2!c1! c3!c4!n6!n YYMMDD HHMM N, U or S Format O = Output for SWIFT 012, 019, 103, 202, 204, 900, 910, 940, 950 Input time Input date, local to the sender, LT address of sender, session and sequence number of sender Output date, local to the receiver Output time, local to the receiver N or U = senders message priority S = system (MT 012 and MT 019) Use in SSP
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 user header is put in braces ({}). Note: The individual fields are described in detail in the SWIFT User Handbook FIN System Messages.
67
Structure when sending a message
The following table describes the user header when the participant sends the message to the SWIFT network (It is an outgoing payment from the participants point of view):
User Header Status M M Tag 103 Field name Block Identifier Service Identifier 3: {103:3!a} Content/ Options 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). Use in SSP
68
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details User Header Status O Tag 113 Field name Banking Priority Content/ Options {113:4!x} Use in SSP Character 1: H = highly urgent payment U = urgent payment N = normal payment Character 2: Y = MT 012 requested N = MT 012 not requested Character 3 + 4: see note If character 2 has been given N, character 1 must be filled with H, U or N, otherwise 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). HAM: If the first character is equal to H the message is for cash withdrawal. The other characters have to be filled with NNN. If the field is not available, SSP treats this payment as a normal payment (equivalent to value NNNN).
69
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details User Header Status O Tag 108 Field name Optional Message User Reference Validation Flag Content/ Options {108:16x} Use in SSP
119
{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.
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 message the ordering and/or the beneficiary are non-resident in the country of the sender (regular reporting purposes). Structure when receiving a message The following table describes the user header when the participant receives the message from the SWIFT network. (It is an incoming message from the participants point of view.)
User Header Tag Field name Block Identifier 3: Content/ Options Use in SSP
70
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details User Header Tag 103 Field name Service Identifier Content/ Options {103:TGT} Use in SSP 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 (payments between HAM accounts) HAM sends what was set by the sender of the message. It can be ignored by the receiver. 108 Optional Message User Reference {108:16x} Only present when filled by the sender of the message. HAM: For messages sent by HAM it is automatically generated by HAM. It is always equal to the TRN (tag 20).
71
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details User Header Tag 119 Field name Validation Flag Content/ Options {119:8c} Use in SSP 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 Information {115: HHMMSS HHMMSS 2!a 16x} This field is present when the receiver receives this message via Y-copy service. This is synonymous with settling the payment in the PM. It contains information from the PM: Time of crediting RTGS account of receiver 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.
72
14.1.2.1.2
Trailer
14.1.2.1.2.1 General description General information The trailer of a message differs according to the following cases:
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 sending a message The following table describes the trailers when the participant sends the message to the SWIFT network. (It is an outgoing payment from the participants point of view.)
Trailer Status M M Tag Field name Block Identifier 5: {MAC:8!h} {PAC:8!h} Content/ Options Use in SSP
MAC Authentication Code PAC Proprietary Authentication Code Checksum Training Possible Duplicate Emission
M O O
CHK TNG PDE
{CHK:12!h} {TNG:}
Only in test and training mode.
{PDE:[<time>< mir>]}
73
Structure when receiving a message via Y-copy
The following table describes the trailers when the participant receives a payment message from the SWIFT network. (It is an incoming payment via Y-copy from the participants point of view, User Header contains {103:TGT}.)
Trailer Status M M M Tag Field name Block Identifier 5: {MAC:8!h} {PAC:8!h} Content/ Options Use in SSP
MAC Authentication Code PAC Proprietary Authentication Code Checksum Training Possible Duplicate Emission
M O O
CHK TNG PDE
{CHK:12!h} {TNG:}
Only in test and training mode.
{PDE:[<time>< mir>]} {PDM:[<time> <mor>]} {DLM:} -
PDM Possible Duplicate Message DLM Delayed Message
74
Structure when receiving a message via normal FIN (no Y-copy)
The following table describes the trailers when the participant receives a message via the SWIFT network from the SSP. (It is an incoming message from the participants point of view, no Y-copy.)
Trailer Status M O M O O Tag Field name Block Identifier 5: {MAC:8!h} {CHK:12!h} {TNG:} Content/ Options Only in test and training mode Use in SSP
MAC Authentication Code CHK TNG PDE Checksum Training Possible Duplicate Emission
{PDE:[<time>< mir>]} {PDM:[<time> <mor>]} {DLM:} -
PDM Possible Duplicate Message DLM Delayed Message
14.1.2.1.2.2 Handling of PDM/PDE Trailer PDM Trailer (Possible Duplicate Message Trailer) PDM trailer is set by SWIFT. It is used to warn the receiver that the same message may already have been delivered by the SWIFT. The reason for 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 processing. The message with PDM trailer will not be delivered to the receiver.
75
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 (Possible Duplicate Emission Trailer) PDE trailer is set by the sender of the message. It is used to warn the receiver that the same message may already have been received. The reason 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):
76
If the original payment message (without PDE trailer) was already delivered, the message with PDE trailer will be discovered by PM. It will be rejected. 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 -
5 MT 012 (opt.) 1 MT 103/103+/202 COV/204
SWIFTNet FIN
4 MT 103/103+/202 COV/204
Bank A
6 MT 103/103+/202 COV/204 (PDE)
8 neg. MT 097 7 MT 096 (PDE)
Bank B
2 MT 096
3 MT 097
9 MT 019
PM
Participant interface (Y-copy)
PDM/PDE processing
first message second message
77
Step 1 2 3
Description Bank A sends a payment message to PM SWIFT delivers the settlement request (MT 096) to PM 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 confirmation (MT 097) and sends it to SWIFT SWIFT delivers the payment message to Bank B If Bank A requested to receive a sender notification (MT 012) it will be delivered by SWIFT Bank A sends the same payment message with PDE trailer SWIFT delivers the MT 096 with PDE trailer to PM PM recognises that the message was already received without PDE trailer and creates a negative MT 097 with a unique error code Consequently SWIFT sends an MT 019 containing the error code to Bank A.
4 5 6 7 8 9
78
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
1 MT 103/103+/202 COV/204 (PDE)
Bank B
4 MT 103/103+/202 COV/204 (PDE)
2 MT 096 (PDE)
3 MT 097
5 MT 012 (PDE) (opt.)
PM
Participant Interface (Y-copy)
PDE/PDM processing
79
Step 1 2 3
Description Bank A sends a payment message with a PDE trailer to PM SWIFT delivers the settlement request (MT 096) with PDE trailer to PM 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 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) If requested SWIFT sends a sender notification (MT 012) to Bank A
80
If the payment message (without PDE trailer) is delivered after the message 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
- payment message (without PDE trailer) was delivered after the message with the PDE trailer -
9 MT 019 1 MT 103/103+/202 COV/204
SWIFTNet FIN
Bank A
2 MT 103/103+/202 COV/204 (PDE) 6 MT 012 (opt.) 7 MT 096
8 neg. MT 097
Bank B
5 MT 103/103+/202 COV/204 (PDE) 3 MT 096 (PDE) 4 MT 097
PM
Participant Interface (Y-copy)
PDM/PDE processing
81
Step 1 2 3 4
Description Bank A sends a payment message to PM After a while Bank A sends the same payment message with PDE trailer SWIFT delivers the settlement request (MT 096) with PDE trailer to PM PM checks whether the same payment message without PDE trailer already arrived. Because it is not the case, PM settles the payment with PDE trailer and creates a positive settlement confirmation (MT 097) with PDE trailer 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 Structures 5.10.5) If requested SWIFT sends a sender notification (MT 012) to Bank A In the meantime SWIFT creates an MT 096, which is based on the payment message without PDE trailer (see step 1) PM checks whether the same payment message without PDE trailer already arrived. Because it is the case, PM creates a negative settlement confirmation (MT 097) with a unique error code SWIFT sends an Abort Notification (MT 019) with a unique error code to Bank A
6 7 8
14.1.2.2
14.1.2.2.1
Textblock of the different message types

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 90).
82
HAM
Operations settled through CB customers accounts can be triggered via MT 103:
payments of CB customers to and from RTGS accounts payments between CB customers 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 Status M ----> Field 20 Field name Senders Reference Status M Format 16x SSP Specifications Use in SSP
83
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 13C Field name Time Indication Status O Format /8c/4!n1!x 4!n SSP Specifications Use in SSP PM: 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 circumstances) 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 codewords TILTIME, REJTIME and FROTIME. If TILTIME and REJTIME are both mentioned only the first one is 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: In the outgoing messages it contains the Settlement Time. The format is: /SNDTIME/hhmm+iinn Note: ii and nn are the hours and minutes of UTC shift ----| M 23B Bank Operation Code M 4!c
---->
84
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O ----| O M 26T 32A Transaction Type Code Value Date/ Currency/ Interbank Settled Amount O M 3!c 6!n3!a15d Payments can be sent for the current business day and up to five TARGET working days in advance. Payments must be denominated in euro only. Exception: Subsequent delivery of individual payments after sending backup payments via ICM. This payment may have a value date older than current business day. Details see chapter 2.7.4.3 Subsequent delivery of single payments in book 1. SWIFT declares this field mandatory for all European countries (see SWIFT User Handbook). If the currency code is different from the currency code in field 32A, field 36 must be present, otherwise field 36 is not allowed. Field 23E Field name Instruction Code Status O Format 4!c[/30x] SSP Specifications Use in SSP
33B
Currency/ Instructed Amount Exchange Rate
3!a15d
36
12d
50a
Ordering Customer
Option A: [/34x]4!a2! a2!c[3!c] Option F: 35x 4*35x Option K: [/34x] 4*35x
51A
Sending Institution
Must not be used
85
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 52a Field name Ordering Institution Status O Format Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option D: [/1!a][/34x] 4*35x SSP Specifications Use in SSP HAM: In the outgoing message it contains: On the first line: the BIC of the account debited and the TRN of the incoming message. On the second line: the BIC mentioned in the incoming 52A (if present), else the BIC of the sender of the incoming message. Format: //HAM<BIC><TRN> <BIC>. PM: Not used. HAM: If the sender is a central bank, the 53a (with option A) has to contain the BIC of a CBs customer to be debited.
53a
Senders Correspondent
Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option B: [/1!a] [/34x] [35x] Option D: [/1!a][/34x] 4*35x
54a
Receivers Correspondent
Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option B: [/1!a] [/34x] [35x] Option D: [/1!a][/34x] 4*35x
Not used by the SSP
86
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 55a Field name Third Reimbursement Institution Status O Format Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option B: [/1!a] [/34x] [35x] Option D: [/1!a][/34x] 4*35x O 56a Intermediary Institution O Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Only option A HAM: When present identifies the account 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. HAM: The tag is mandatory for HAM. If tag 56a is not present tag 57a specifies the account to be credited and must be used with option A. On the contrary option D is accepted only if the field 56A is present. SSP Specifications Use in SSP Not used by the SSP
57a
Account With Institution
Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option D: [/1!a][/34x] 4*35x
59a
Beneficiary Customer
Option A: [/34x] 4!a2!a2!c[ 3!c] no letter option: [/34x] 4*35x
87
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O M Field 70 71A Field name Remittance Information Details of Charges Status O M Format 4*35 OUR / SHA / BEN 3!a15d SSP Specifications Use in SSP
----> O ----| O 71G Receivers Charges O 3!a15d 71F Senders Charges O
88
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 72 Field name Sender to Receiver Information Status O Format 6*35x SSP Specifications Use in SSP HAM: In case field 52D is used in original 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 identification of the field causing the reject or /RETN/ followed by the identification of the field causing the return (used for incoming payments from PM and directed 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 preceding reason code. /MREF/ Senders Reference, ie field 20 of the original message (Transaction Reference Number of File Reference). O O 77B 77T Regulatory Reporting Envelope Contents O 3*35x 9000z Must not be used
89
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 chapter 14.1.2.2.1.1 MT 103, page 82). HAM Operations settled through CB customers accounts can be triggered via MT 103+:
in different central banks Structure The following table describes the structure of MT 103+ (STP format) used in SSP:
SWIFT standard Status M ----> Field 20 Field name Senders Reference Status M Format 16x SSP Specifications Use in SSP
90
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 13C Field name Time Indication Status O Format /8c/4!n1!x 4!n SSP Specifications Use in SSP PM: 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 circumstances ) 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 codewords TILTIME, REJTIME and FROTIME. If TILTIME and REJTIME are both mentioned only the first one is 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: In the outgoing messages it contains the Settlement Time. The format is: /SNDTIME/hhmm+iinn Note: ii and nn are the hours and minutes of UTC shift ----| M 23B Bank Operation Code M 4!c
---->
91
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 23E Field name Instruction Code Status O Format 4!c[/30x] SSP Specifications Use in SSP Only the codewords CORT INTC SDVA REPA are allowed.
----| O 26T Transaction Type Code Value Date/ Currency/ Interbank Settled Amount O 3!c
32A
6!n3!a15d
Payments can be sent for the current business day and up to five TARGET working days in advance. Payments must be denominated in euro only. Exception: Subsequent delivery of individual payments after sending backup payments via ICM. This payment may have a value date older than current business day. Details see chapter 2.7.4.3 Subsequent delivery of single payments in book 1. SWIFT declares this field mandatory for all European countries (see SWIFT User Handbook). If the currency code is different from the currency code in field 32A, field 36 must be present, otherwise field 36 is not allowed.
33B
Currency/ Instructed Amount Exchange Rate
3!a15d
36
12d
92
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 50a Field name Ordering Customer Status M Format Option A: [/34x]4!a2! a2!c[3!c] Option F: 35x 4*35x Option K: [/34x]4*35x O 52A Ordering Institution O Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] HAM: In the outgoing message it contains on the first line: the BIC of the account debited and the TRN of the incoming message. on the second line: the BIC mentioned in the incoming 52A (if present, else the BIC of the sender of the incoming message) Format: //HAM<BIC><TRN> <BIC> PM: Not used HAM: If the sender is a central bank, the 53a (with option A) has to contain the BIC of a CBs customer to be debited Not used by the SSP SSP Specifications Use in SSP
53a
Senders Correspondent
Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option B: [/1!a] [/34x] [35x]
54A
Receivers Correspondent Third Reimbursement Institution
Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c]
55A
Not used by the SSP
93
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 56A Field name Intermediary Institution Status O Format Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option A: [/34x] 4!a2!a2!c[ 3!c] no letter option: [/34x] 4*35x O M 70 71A Remittance Information Details of Charges O M 4*35x OUR / SHA / BEN 3!a15d SSP Specifications Use in SSP Only option A HAM: When present identifies the account to be credited. HAM: The tag is mandatory for HAM. If tag 56a is not present tag 57a specifies the account to be credited. An account line must be stated.
57A
Account With Institution Beneficiary Customer
59a
----> O ----| O O 71G 72 Receivers Charges Sender to Receiver Information Regulatory Reporting O O 3!a15d 6*35x Code words REJT and RETN or ERI details are not allowed. 71F Senders Charges O
77B
3*35x
94
14.1.2.2.1.3 MT 202 Usage HAM This message type is used to transfer credit balances between financial institutions. 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 an HAM account (co-managed). The institution quoted in Tag 53a (Senders Correspondent), is the debtor. Only Tag 58a (Beneficiary Institution) is used to identify the creditor institution. 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 customers accounts can be triggered via standard MT 202:
in different central banks
95
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:
SWIFT standard Status M Field 20 Field name Transaction Reference Number Status M Format 16x SSP Specifications Use in SSP HAM: The incoming message must be unique for sender, date (32A) and TRN. In the outgoing message it is an SSP progressive number. PM: for outgoing messages linked to AS settlement: copy of EndToEndIdentification contained in PaymentTransaction HAM: In the outgoing message it is equal to tag 21 of the incoming message. ---->
21
Related Reference
16x
96
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 13C Field name Time Indication Status O Format /8c/4!n1!x 4!n SSP Specifications Use in SSP PM: 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 bank-to-bank payments (18.00 under normal circumstances) Note:
For incoming messages linked

to the liquidity credit transfer to mirror account in AS settlement: the authorised codes are /FROTIME/hhmm+/-iinn /REJTIME/hhmm+/-iinn For outgoing messages linked to AS settlement: not relevant 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 codewords TILTIME, REJTIME and FROTIME. If TILTIME and REJTIME are both mentioned only the first one is used by SSP.
97
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status Format SSP Specifications Use in SSP However, the codeword /CLSTIME/ has to be used in field 72 and not according to the SWIFT standard in field 13C. HAM: In the outgoing messages it contains the settlement time. The format is: /SNDTIME/hhmm+iinn Note: ii and nn are the hours and minutes of UTC shift. ----| M 32A Value Date, Currency Code, Amount M 6!n3!a15d Payments can be sent for the current business day and up to five TARGET working days in advance. Payments must be denominated in euro only. PM: Exception: Subsequent delivery of individual payments after sending backup payments via ICM. This payment may have a value date older than current business day. Details see chapter 2.7.4.3 Subsequent delivery of single payments in book 1.
98
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 52a Field name Ordering Institution Status O Format Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option D: [/1!a][/34x] 4*35x SSP Specifications Use in SSP PM: For incoming messages linked to AS settlement: may be used to pass on information on the debtor. For outgoing messages linked to AS settlement: If a valid BIC is indicated as debtor in the ASTransferInitiation. Option A: Copy of the account (adjusted to format /34x) from the DebtorAccount (if filled) and copy of the BIC indicated as debtor. If no BIC is indicated as debtor the field 52A will be empty. For outgoing messages (payments from HAM) it contains the BIC of the debtor. HAM: For all outgoing messages it contains on the first line: the BIC of the account debited and the TRN of the incoming message. on the second line: the BIC mentioned in the incoming 52A (if present, else the BIC of the sender of the incoming message). Format: //HAM<BIC><TRN> <BIC>
99
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 53a Field name Senders Correspondent Status O Format Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] SSP Specifications Use in SSP PM: Not used For outgoing messages (payments from HAM) it contains the BIC of the debtors CB. Must not be filled in messages linked to ancillary system settlement. HAM: If the sender is a central bank, the 53a (with option A) has to contain the BIC of a CBs customer to be debited. PM: Not used Must not be filled in messages linked to ancillary system settlement. PM: Not used Must not be filled in messages linked to ancillary system settlement HAM: When present identifies the account to be credited.
54a
Receivers Correspondent
Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c]
56a
Intermediary
100
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 57a Field name Account With Institution Status O Format Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] SSP Specifications Use in SSP PM: For incoming messages linked to AS settlement: mandatory for the integrated model; it must be the BIC of a mirror account linked to the sender (settlement bank) not filled for the interfaces model For outgoing messages linked to AS settlement: not filled 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.
101
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 58a Field name Beneficiary Institution Status M Format Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option D: [/1!a][/34x] 4*35x SSP Specifications Use in SSP PM: For incoming messages linked to AS settlement: may be used to pass on information on the creditor in the AS. For the interfaced AS Option A only is allowed (BIC of the RTGS account of the sender and sub-account of this RTGS account) For outgoing messages linked to AS settlement: If a valid BIC is indicated as Creditor in the ASTransferInitiation Option A: Copy of the account (adjusted to format /34x) from the CreditorAccount (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 HAM: If field 56A and 57A are not present, it is the BIC of the account to be credited. Option D is accepted only if field 57A is present.
102
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 72 Field name Sender to Receiver Information Status O Format 6*35 SSP Specifications Use in SSP PM: /BUP/ = codeword to indicate backup payments. /CLSTIME/hhmm If hhmm is present it must be before the cut-off time for bank-to-bank payments (18.00 under normal 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. /INS/ followed by BIC of the mirror account from FirstAgent field = codeword 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 neither Creditor BIC nor Creditor Name present in the ASTransferInitiation message, Creditor Domestic 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
103
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status Format SSP Specifications Use in SSP HAM: In case field 52D is used in original MT 202 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 identification of the field causing the reject or /RETN/ followed by the identification of the field causing the return (used for incoming payments from PM and directed 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 preceding reason code. /MREF/ Senders Reference, ie field 20 of the original message (Transaction Reference Number of File Reference).
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.
104
14.1.2.2.1.4 MT 202 COV Usage This message type is used to transfer credit balances between financial institutions. It must only be used to order the movement of funds related to an underlying customer credit transfer that was sent with the cover method. The MT 202 COV must not be used for any other interbank transfer. 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

financial institution transfer between the ordering institution and beneficiary 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:
SWIFT standard Status M Field 20 Field name Transaction Reference Number Related Reference Status M Format 16x Sequence A General Information SSP Specifications Use in SSP
M ---->
21
16x
105
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 13c Field name Time Indication Status O Format /8c/4!n1!x 4!n SSP Specifications Use in SSP PM: 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 bank-to-bank payments (18.00 under normal circumstances) 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 codewords TILTIME, REJTIME and FROTIME. If TILTIME and REJTIME are both mentioned only the first one is used by SSP. However, the codeword /CLSTIME/ has to be used in field 72 and not according to the SWIFT standard in field 13C. ----I
106
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 32A Field name Value Date, Currency Code, Amount Status M Format 6!n3!a15d SSP Specifications Use in SSP Payments can be sent for the current business day and up to five TARGET working days in advance. Payments must be denominated in euro only. PM: Exception: Subsequent delivery of individual payments after sending backup payments via ICM. This payment may have a value date older than current business day. Details see chapter 2.7.4.3 Subsequent delivery of single payments, UDFS Book I. O 52a Ordering Institution O Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option D: [/1!a][/34x] 4*35x O 53a Sender's Correspondent Receiver's Correspondent Intermediary O Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] PM: Not used
54a
PM: Not used
56a
PM: Not used
107
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 57a Field name Account With Institution Beneficiary Institution Status O Format Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option D: [/1!a][/34x] 4*35x O 72 Sender to Receiver Information O 6*35x PM: /BUP/ = codeword to indicate backup payments. /CLSTIME/hhmm If hhmm is present it must be before the cut-off time for bank-to-bank payments (18.00 under normal 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. SSP Specifications Use in SSP
58a
Sequence B underlying customer credit transfer details M 50a Ordering Customer M Option A: [/34x]4!a2! a2!c[3!c] Option F: 35x 4*35x Option K: [/34x]4*35x
108
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 52A Field name Ordering Institution Status O Format Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option D: [/1!a][/34x] 4*35x O 56A Intermediary Institution O Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option C: /34x Option D: [/1!a][/34x] 4*35x O 57A Account With Institution O Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option B: [/1!a][/34x] [35x] Option C: /34x Option D: [/1!a][/34x] 4*35x SSP Specifications Use in SSP
109
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 59a Field name Beneficiary Customer Status M Format Option A: [/34x] 4!a2!a2!c[ 3!c] no letter option: [/34x] 4*35x O O 70 72 Remittance Information Sender to Receiver Information Currency/ Instructed Amount O O 4*35x 6*35x SSP Specifications Use in SSP
33B
3!a15d
14.1.2.2.1.5 MT 202 simplified (HAM only) Structure The following table describes the structure of the MT 202 simplified:
SWIFT standard Status M Field 20 Field name Transaction Reference Number Related Reference Time Indication Status M Format 16x SSP Specifications Use in SSP The incoming message must be unique for sender, date (32A) and TRN. In the outgoing message it is an SSP progressive number. In the outgoing message it is equal to tag 21 of the incoming message. In the outgoing messages it contains the settlement time. The format is: /SNDTIME/hhmm+iinn Note: ii and nn are the hours and minutes of UTC shift.
M ----> O
21
16x
13C
/8c/4!n1!x 4!n
110
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 32A Field name Value Date, Currency Code, Amount Ordering Institution Status M Format 6!n3!a15d SSP Specifications Use in SSP Payments can be sent for the current business day and up to five TARGET working days in advance. Payments must be denominated in euro only. In the incoming message it is not allowed. For all outgoing messages it contains on the first line: the BIC of the account debited and the TRN of the incoming message. on the second line: the BIC of the sender of the incoming message Format: //HAM<BIC><TRN> <BIC> If specified it contains the BIC of the account to be debited. The sender must be an authorised participant (co-manager or CB). Not allowed
52a
Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c]
53a
Senders Correspondent Receivers Correspondent Intermediary
Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c]
54a
56a
Not allowed
57a
Account With Institution
It is present only for liquidity transfers from HAM account to RTGS account in PM. It has to be filled with the BIC of the home CB, followed in field 58A with the BIC code of the PM participant.
111
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 58a Field name Beneficiary Institution Status M Format Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] SSP Specifications Use in SSP It contains the account to be credited. For HAM to HAM and PM to HAM 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 Receiver Information O 6*35x HAM: In case field 52D is used in original MT 202 simplified 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 identification of the field causing the reject or /RETN/ followed by the identification of the field causing the return (used for incoming payments from PM and directed 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 preceding reason code. /MREF/ Senders Reference, ie field 20 of the original message (Transaction Reference Number of File Reference).
112
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 advance. The sender of the message is the creditor and the receiver is the debtor. Structure The following table describes the structure of the MT 204:
SWIFT standard Status M Field 20 Field name Transaction Reference Number Sum of Amounts Status M Format 16x SSP Specifications Use in SSP
Sequence A Common Elements - Reimbursement Details
19
17d
The amount in field 19 must be equal to the sum of the amounts in all fields 32B. This is the amount actually settled. The date can be the current business day or up to five TARGET working days in advance.
30
Value Date
YYMMDD
57a
Account With Institution Beneficiary Institution
Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option D: [/1!a][/34x] 4*35x
58a
113
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 72 Field name Sender to Receiver Information Status O Format 6*35x SSP Specifications Use in SSP PM: The following codes 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 bank-to-bank payments (18.00 under normal circumstances) 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 codewords TILTIME, REJTIME and FROTIME. If TILTIME and REJTIME are both mentioned only the first one is 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 M 20 Transaction Reference Number Related Reference M 16x
O M
21 32B
16x 3!a15d The currency must always be euro.
TransacM tion Amount
114
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 53a Field name Debit Institution Status M Format Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] Option D: [/1!a][/34x] 4*35x O 72 Sender to Receiver Information O 6*35x Not used by the SSP. SSP Specifications Use in SSP
----|
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 or mandated payments.
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).
115
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.) The following table describes the structure of the MT 900:
SWIFT standard Status M Field 20 Field name Transaction Reference Number Status M Format 16x SSP Specifications Use in SSP For payments linked to AS: The TRN is built with AS followed by the 14 last characters of the timestamp ASddhhmmssnnnnnn
Structure
116
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 21 Field name Related Reference Status M Format 16x SSP Specifications Use in SSP Content of field 20 (in case of direct debit field 21) For payments linked to AS settlement: Execution of Standing orders and current orders sent via ICM screens (U2A): Internal SSP reference Execution of LiquidityCreditTransfer and SBTransferInitiation sent in A2A via ICM: Copy of MessageIdentification Back Transfer of liquidity ordered with End of Procedure: Copy of BusinessInformationReference of the ReturnGeneralBusinessInformati on message End of Procedure by SSP at End of Business day: Related internal reference attributed by the SSP specifically to each AS for the procedure which has to be closed by the SSP. Other cases: Copy of EndToEndIdentification contained in the ASTransferInitiation messages For transactions received via ICM (A2A) the first 16 characters of the MsgId. For transactions received via ICM (U2A) the internal reference.
117
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status Format SSP Specifications Use in SSP 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 Identification Value Date, Currency Code, Amount M 35x Usage up to 34 digit account number related to RTGS main account or sub-account debited for ancillary system. Only current day. Only EUR.
32A
6!n3!a15d
118
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 52a Field name Ordering Institution Status O Format Option A: [/1!a][/34x] 4!a2!a2!c[ 3!c] SSP Specifications Use in SSP PM: For the debit entries stemming from the AS settlement depending on their nature, the following BICs are contained: Execution of Standing orders and current orders sent by Settlement Banks via ICM: BIC of the Settlement Bank Back Transfer of liquidity ordered with End of Procedure: BIC of the AS if procedure was closed via ICM BIC of the AS in field SubjectDetails (if filled) else BIC AS sender of the ReturnGeneralBusinessInformation. LiquidityCreditTransfer and SBTransferInitiation BIC of Settlement Bank End of Procedure by SSP at End of Business day: 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.
119
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 72 Field name Sender to Receiver Information Status O Format 6*35x SSP Specifications Use in SSP PM: /BUP/ for backup payments /CRDTLN/15d to indicate the change of credit line to the user. /MANPAY/ for mandated payments /ASDEBT/ used by the AS. See Normalization of AS codewords for field 72 on page 130. Not used in case of standing orders to sub-accounts and current orders to sub-accounts sent via ICM. /ASINF/ used by the AS. See Normalization of AS codewords for field 72 on page 130. Not used in case of standing orders to sub-accounts and current orders to sub-accounts sent via ICM. /SFMLAINT/ for Automatic Marginal Lending Interest /BALANCM/ for the confirmation on turnover stemming from CM PM and HAM: /LIQUIINP/ for a liquidity transfer /LIQUIOUT/ for liquidity forwarding 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 /LIQUISF/ for liquidity transfer to/ from standing facilities module
120
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status Format SSP Specifications Use in SSP
/LIQUIEOD/ for liquidity forward /SSPBIL/ for CRISP fees /LIQUISOD/ for liquidity transfer
at the start-of-day from HAM to PM Information about the counterpart 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 account 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 //OVERNIGHT DEPOSIT nnnn R) ing at the end-of-day
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 account 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.
121
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status Format SSP Specifications Use in SSP RM: The complete information provided by RM and forwarded by PM/HAM is: PENALTY /RMRESPEN/ //PENALTY FOR COMPULSORY RESERVE //IN THE PERIOD: //YYYY-MM-DD - YYYY-MM-DD // DEB CI_BIC CRE CB_BIC INTEREST /RMRESINT/ // INTEREST FOR COMPULSORY RESERVE //IN THE PERIOD: //YYYY-MM-DD - YYYY-MM-DD // DEB CB_BIC CRE CI_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 account. The booking is confirmed again on the account statement. Credit entries from payments received via the FIN-copy service of Payments Module (PM) are not confirmed with MT 910.
122
When FIN-copy is not used, issuing of MT 910 is optional (a global parameter can be selected by the participant). HAM Structure HAM sends, if requested, an MT 910 message to the creditor and the co-manager. The following table describes the structure of the MT 910:
SWIFT standard Status M Field 20 Field name Transaction Reference Number Status M Format 16x SSP Specifications Use in SSP For payments linked to AS: The TRN is built with AS followed by the 14 last characters of the timestamp ASddhhmmssnnnnnn
123
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 21 Field name Related Reference Status M Format 16x SSP Specifications Use in SSP Content of field 21 (in case of direct debit field 20). For payments linked to AS settlements: Execution of Standing orders and current orders sent via ICM screens (U2A): Internal SSP reference Execution of LiquidityCreditTransfer sent in A2A via ICM: Copy of MessageIdentification Back Transfer of liquidity ordered with End of Procedure: Copy of BusinessInformationReference of the ReturnGeneralBusinessInformation message End of Procedure by SSP at End of Business day: Related internal reference attributed by the SSP specifically to each AS for the procedure which has to be closed by the SSP. MT 202 to credit Sub- or Mirror Account: Copy of field 20 of the MT 202 Other cases: Copy of EndToEndIdentification contained in the ASTransferInitiation messages NEW: for internal payments generated directly by the SSP modules (SF interest, RM interest and penalties); HAM (in case of REJECT/RETURN): When the receiver of the MT 910 is different from the sender of the payment message.
124
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 25 Field name Account Identification Value Date, Currency Code, Amount Ordering Customer Status M Format 35x SSP Specifications Use in SSP Usage up to 34 digit account number related to RTGS main account or sub-account credited for ancillary system. Only current day. Only EUR.
32A
6!n3!a1 5d
50a
Option A: [/34x] 4!a2!a2 !c[ 3!c] Option F: 35x 4*35x Option K: [/34x] 4*35x
Not used
125
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 52a Field name Ordering Institution Status M Format Option A: [/1!a][/ 34x] 4!a2!a2 !c[ 3!c] SSP Specifications Use in SSP PM: Content of field 52 of the related payment message or its sender of the credited payment. For the credit entries stemming from the AS settlement depending on their nature, the following BICs are contained: MT 202 to Sub- or Mirror Account, execution of Standing orders and current orders sent by the Settlement Banks via ICM: BIC of the Settlement Bank Back Transfer of liquidity ordered with End of Procedure: BIC of the AS which procedure was closed via ICM BIC of the AS filled in field SubjectDetails (if filled) else BIC AS sender of the ReturnGeneralBusinessInformation End of Procedure by SSP at End of Business day: 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.
126
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 56a Field name Intermediary Status O Format Option A: [/1!a][/ 34x] 4!a2!a2 !c[ 3!c] SSP Specifications Use in SSP HAM: It is equal to the account debited if different from the Ordering Institution.
127
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 72 Field name Sender to Receiver Information Status O Format 6*35x SSP Specifications Use in SSP PM: /CRDTLN/15d to indicate the change of credit line to the user. /MANPAY/ for mandated payments /ASCRED/ used by the AS. See Normalization of AS codewords for field 72 on page 130. Not used in case of standing orders to sub-accounts and current orders to sub-accounts sent via ICM. /ASINF/ used by the AS. See Normalization of AS codewords for field 72 on page 130. Not used in case of standing orders to sub-accounts and current orders to sub-accounts sent via ICM. /SFMLAINT/ for Automatic Marginal Lending Interest /BALANCM/ for the confirmation 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 forwarding from PM (except at the end-of-day) /LIQUISF/ for liquidity transfer to/ from standing facilities module /LIQUIEOD/ for liquidity forwarding at the end-of-day /SSPBIL/ for CRISP fees
128
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status Format SSP Specifications Use in SSP
/LIQUISOD/ for liquidity transfer at Information about the counterpart

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 account 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 //OVERNIGHT DEPOSIT nnnn R) the start-of-day from HAM to PM
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 account 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.
129
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status Format SSP Specifications Use in SSP RM: The complete information provided by RM and forwarded by PM/HAM is: PENALTY /RMRESPEN/ //PENALTY FOR COMPULSORY RESERVE //IN THE PERIOD: //YYYY-MM-DD - YYYY-MM-DD // DEB CI_BIC CRE CB_BIC INTEREST /RMRESINT/ // INTEREST FOR COMPULSORY RESERVE //IN THE PERIOD: //YYYY-MM-DD - YYYY-MM-DD // DEB CB_BIC CRE CI_BIC
Normalization of AS codewords for field 72
The optional elements (Debtor, Creditor and RemittanceInformation) of the ASTransferInitiation and SBTransferInitiation are mapped in the field 72 of the MT 900/910. For the AS Integrated, the fields 52/58 and 72 of the standing orders and the liquidity transfer to mirror account 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 mirror account 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.
130
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 following codeword:
In MT 900/910: /ASINF/ (RemittanceInformation or 72)

Normalization for codewords /ASDEBT/ and /ASCRED/ Debtor and creditor contain the following optional elements:
Debtor
Name (70x) BIC (11x) DomesticAccountIdentification (35x)
Creditor
Name (70x) 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 Name+BIC+DomesticAccountIdentification Name+BIC Name+DomesticAccountIdentification Name +BIC+DomesticAccountIdentification +BIC ++DomesticAccountIdentification Maximal length 118x 82x 107x 70x 48x 12x 37x
In case of field 52 or field 58, the data is +BIC

131
The data relative to debtor and creditor are sent in MT 900/910 without truncation. 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 (118x): /ASDEBT/ 27x // // // Normalization for the codeword /ASINF/ 33x 33x 25x
The contents of tag RemittanceInformation of the ASTransferInitiation, as well as field 72 of the liquidity transfers, are mapped to field 72 of the MT 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 truncation) /ASDEBT/ 27x // 33x // 33x // 25x /ASINF/ 28x // 33x Maximum:140 characters (No truncation) /ASDEBT/ 27x /ASINF/ 28x // 33x // 33x // 25x // 13x
132
Examples of field 72
Field 72 for MT 900

Tag ... 72 O /ASDEBT/ Bank DEBSPART++123456DBSP /ASINF/Document XYZ M/O Data
Field 72 for MT 910

Tag ... 72 O /ASCRED/+CREDFRPPXXX+CRED789 /ASINF/Document XYZ M/O Data
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 customers 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. Structure The following table describes the structure of the MT 940:
SWIFT standard Status M Field 20 Field name Transaction Reference Number Related Reference Status M Format 16x SSP Specifications Use in SSP HAM: SSP progressive Must not be used
21
133
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 25 Field name Account Identification Statement Number/ Sequence Number Status M Format 35x SSP Specifications Use in SSP Usage up to 34 digits; relevant HAM account number. Statement Number: At the beginning of the year and for the first message of a new participant 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 Balance M Option F: 1!a6!n3!a15 d Option M: 1!a6!n3!a15 d ----> F = First Opening Balance D/C Mark, Date, Currency, Amount
28C
5n[/5n]
M = Intermediate Opening Balance D/C Mark, Date, Currency, Amount
134
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 61 Field name Statement Line Status O Format 6!n[4!n]2a[1 !a]15d1!a3! c16x[// 16x][34x] Sub- Forfield mat 1 2 3 6!n [4!n] 2a PM: Value date (YYMMDD) Business day date (MMDD) SSP Specifications Use in SSP
Characters for Debit/Credit Characters for Reversal of Debit/

Credit (RD or RC) (D or C)
4 5 6
[1!a] 15d
Code for money type (not being used) Amount in euro
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, LiquidityCreditTransfer, U2A) to debit its own RTGS account S204 for all others operations ordered by a third party (AS, CB or PM)
135
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status 7 Format 16x SSP Specifications Use in SSP Ordering partys 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 between GoA members, backup payments, internal payments from HAM/SF/ RM/CM/CRISP to PM) reference (field 20) of the internal message if field is not available/filled: PM reference AS transactions: Tag 20 for MT 202 Message Identification for SBTransferInitiation and LiquidityCreditTransfer SSP internal reference for U2A, standing orders and operations ordered by PM BusinessInformationReference for end of procedure requested via ReturnGeneralBusinessInformation EndToEndIdentification for all other cases (requested by ASTransferInitiation) Reference for the institution maintaining the account: SSP internal posting reference for unique identification AS transactions: SSP internal reference
[// 16x]
136
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status 9 Format SSP Specifications Use in SSP [34x] <BIC of the sender from the SWIFT Header> /<settlement time HHMMSS> [/<BIC from field 52>] optional [/BUP/] optional; only for backup payments /MANPAY/ for mandated payments Origin of payment is within SSP: <PM BIC> for payments initiated by PM (eg liquidity retransfer at EoD to HAM, PHA or other participants, EOD settlement on ECB account levelling out) <BIC customer of ICM request> for payments initiated via ICM (eg liquidity transfer from PM to HAM and PHA during the day or between GoA members, backup 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 procedure 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.
137
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status 1 2 3 Format HAM: 6!n [4!n] 2a Transaction accounting date in YYMMDD format Not used Sign: C - Credit D - Debit RC - Reverse Credit RD - Reverse Debit Not used Amount SSP Specifications Use in SSP
4 5 6
[1!a] 15d
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 indicated. 16x Tag 20 of the message to which the transaction type is referred. For XML messages first 16 characters of the MsgID. Tag 20 of the MT 900 - MT 910 sent
8 9
[// 16x]
[34x] Tag 21 of the incoming MT 202 message. Note: The postings (debit entries and credit entries) are sorted according to the sequence of the settlement.
86
Information to Account Owner
6*65x
Not used by the SSP
----|
138
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 62a Field name Closing Balance (Booked Funds) Status M Format Option F: 1!a6!n3!a15 d Option M: 1!a6!n3!a15 d O 64 Closing Available Balance (Available Funds) Forward Available Balance Information to Account Owner O 1!a6!n3!a15 d SSP Specifications Use in SSP F = Final Closing Balance D/C Mark, Date, Currency, Amount
M = Intermediate Closing Balance D/C Mark, Date, Currency, Amount Not used by the SSP
----> O 65 O 1!a6!n3!a15 d Not used by the SSP
----| O 86 O 6*65x Not used by the SSP
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 customers 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.
139
Structure
The following table describes the structure of the MT 950:

SWIFT standard Status M Field 20 Field name Transaction Reference Number Account Identification Statement Number/ Sequence Number Status M Format 16x SSP Specifications Use in SSP HAM: SSP progressive Usage up to 34 digits; relevant HAM account number. Statement Number: At the beginning of the year and for the first message of a new participant 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 Balance M Option F: 1!a6!n3!a15 d Option M: 1!a6!n3!a15 d ----> F = First Opening Balance D/C Mark, Date, Currency, Amount
25
35x
28C
5n[/5n]
140
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 61 Field name Statement Line Status O Format 6!n[4!n]2a[1 !a]15d1!a3! c16x[// 16x][34x] Sub- Forfield mat 1 2 3 6!n [4!n] 2a PM: Value date (YYMMDD) Business day date (MMDD) SSP Specifications Use in SSP
Characters for Debit/Credit

(D or C) Characters for Reversal of Debit/ Credit (RD or RC)
4 5 6
[1!a] 15d
Code for money type (not being used) Amount in euro
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, LiquidityCreditTransfer, U2A) to debit its own RTGS account S204 for all others operations ordered by a third party (AS, CB or PM)
141
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status 7 Format 16x SSP Specifications Use in SSP Ordering partys 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 between GoA members, backup payments, internal payments from HAM/SF/ RM/CM/CRISP to PM) reference (field 20) of the internal message if field is not available/filled: PM reference AS transactions: Tag 20 for MT 202 Message Identification for SBTransferInitiation and LiquidityCreditTransfer SSP internal reference for U2A, standing orders and operations ordered by PM BusinessInformationReference for end of procedure requested via ReturnGeneralBusinessInformation EndToEndIdentification for all other cases (requested by ASTransferInitiation) Reference for the institution maintaining the account: SSP internal posting reference for unique identification AS transactions: SSP internal reference
[// 16x]
142
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status 9 Format SSP Specifications Use in SSP [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 Origin of payment is within SSP: <PM BIC> for payments initiated by PM (eg liquidity retransfer at EoD to HAM, PHA or other participants; EOD settlement on ECB account, levelling out) <BIC customer of ICM request> for payments initiated via ICM (eg liquidity transfer from PM to HAM and PHA during the day or between GoA members; backup 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 procedure 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.
143
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status Field Field name Status Format SSP Specifications Use in SSP HAM: Information about a single transaction in the following: 1 2 3 6!n [4!n] 2a Transaction accounting date in YYMMDD format Not used Sign: C - Credit D - Debit RC - Reverse Credit RD - Reverse Debit Not used Amount
4 5 6
[1!a] 15d
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 indicated. 16x Tag 20 of the message to which the transaction type is referred. For XML messages first 16 characters of the MsgID. Tag 20 of the MT 900 - MT 910 sent
8 9
[// 16x]
[34x] Tag 21 of the incoming MT 202 message. Note: The postings (debit entries and credit entries) are sorted according to the sequence of settlement.
----|
144
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status M Field 62a Field name Closing Balance (Booked Funds) Status M Format Option F: 1!a6!n3!a15 d Option M: 1!a6!n3!a15 d O 64 Closing Available Balance (Available Funds) O 1!a6!n3!a15 d SSP Specifications Use in SSP F = Final Closing Balance D/C Mark, Date, Currency, Amount
M = Intermediate Closing Balance D/C Mark, Date, Currency, Amount Not used by the SSP
14.1.2.3
14.1.2.3.1 Usage
SWIFT system messages

MT 012
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. 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 standard.
145
Structure
The following table describes the structure of the MT 012:

SWIFT standard Status M M Field 175 106 Field name Time MIR Status M M Format HHMM SSP Specifications Use in SSP Input time of the original user message local to the sender.
6!n4!a2!a2! MIR, identifying the senders Copy c1!c3!c4!n6! message copied to the PM and n released by PM. 16x Optional MUR, identifying the senders copy message copied to the PM and released by PM. Destination of the senders message
108
MUR
M M M
102 103 114
SWIFTAddress ServiceCode
M M
4!a2!a2!c1! c3!c TGT 6!n 6!n 2!a 16x
PaymentM ReleaseInformationSender
Used in SSP (SWIFT format: 32x) Credit time HHMMSS, Debit time HHMMSS, Country code of sender, Reference of original payment message
14.1.2.3.2 Usage
MT 019
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 system. 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 receiver.
146
The sender is aware because SWIFT generates an MT 019 containing one the following error codes: 11 12 13 14 Message is too old, but was authorised Too many delivery attempts, but message was authorised Destination is disabled, but message was authorised 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 informing the receiver and the SSP Operational Team. Structure The following table describes the structure of the MT 019:
SWIFT standard Status M M O Field 175 106 108 Field name Time MIR MUR Status M M O Format HHMM 6!n8!c4!c4! n6!n 16x SSP Specifications Use in SSP Input time of the aborted message local to the sender. MIR, identifying the aborted message. The MUR identify the aborted message (if present). If no MUR was present: tag 108 will contain the contents of field 20 of the original message when the alphabetical characters used were all in upper case tag 108 will not be present, when contents of field 20 could not be used Destination of the aborted message
102
SWIFTAddress
4!a2!a2!c1! c3!c
147
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details SWIFT standard Status O Field 107 Field name MOR Status O Format 6!n8!c4!c4! n6!n SSP Specifications Use in SSP MOR identifying the aborted message. If several delivery attempts have been made, field 107 contains the last valid MOR. Abort reason (specified in the SWIFT manual FIN error codes) or reason for the message being rejected by PM. FIN Copy service code: code of field TAG 103 of the aborted message
432
Abort Reason
2!c
619
VAS code
3!x
14.1.2.4
Addresses in TARGET2
Examples for addressing payments
In PM, since the FIN Y-copy service is used, payments will be addressed to the receiving direct PM participant by indicating the BIC in the respective field of the header. 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 notification purposes (after the settlement). The following table shows details of the recipients address in the SWIFT Application Header of the payment record from a PM participants point of view:
Receiving party direct PM participant Address BIC of the direct PM participant Note: It is possible that the direct PM participant sends and receives payments from another location using a different BIC (technical reasons). BIC of the respective direct PM participant
indirect PM participant
148
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details Receiving party HAM account holder proprietary home account holder Address TRGTXEHMXXX BIC of the respective CB
In the following examples the BIC listed below are used:

BIC BKAAFRPPXXX BKEEFRPPXXX BKBBITRRXXX BKCCDEFFXXX BKDDDEDDXXX BKCCDEFF425 direct PM participant direct PM participant (co-manager) direct PM participant direct PM participant second BIC used by the direct PM participant (BKCCDEFFXXX) to send and receive messages at an other location (for technical reasons) second BIC used by the direct PM participant (BKBBITRRXXX) to send and receive messages at an other location (for technical reasons) indirect PM participant (related direct PM participant BKDDDEDDXXX) indirect PM participant (related direct PM participant BDCCDEFFXXX) indirect PM participant (related direct PM participant BKBBITRRXXX) HAM account holder (related to Banca dItalia) HAM account holder (related to Banca dItalia) HAM account holder (related to Banque de France) HAM account holder (related to Deutsche Bundesbank) Central bank customer with an account in HAM (related to Banca dItalia) Central bank customer with an account in HAM (related to Banca dItalia) CB using HAM CB using HAM CB with proprietary home accounting system Explanation direct PM participant (co-manager)
BKBBITRR321
BKDDDEM1XXX BKHHFRP1XXX BKLLITROXXX BKEEITRRXXX BKMMITSSXXX BKNNFRWWXXX BKGGDEFFXXX BKFFITAAXXX BKOOITKKXXX NCBIITRRXXX NCBFFRPPXXX NCBKLULUXXX
149
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details BIC BKFFLULUXXX Explanation account holder in proprietary home accounting system
14.1.2.4.1 Sender direct PM participant
Payments between HAM and PM
In the following examples the direct PM participant (BKAAFRPP) sends the SWIFT message (MT 202).
Case 1 Receiver HAM account holder BKNNFRWWXXX Field entry S: BKAAFRPPXXX R: TRGTXEPMHAM 52: 56: 57: 58: BKNNFRWWXXX Effect
Debit entry in the RTGS

account in PM of BKAAFRPPXXX Credit entry in the RTGS account in PM of the CB
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 holder will be credited.
Case 2 Receiver HAM account holder BKAAFRPPXXX Field entry S: BKAAFRPPXXX R: TRGTXEPMHAM 52: 56: 57: 58: BKAAFRPPXXX Effect

account in PM of BKAAFRPPXXX Credit entry in the RTGS account in PM of the CB
Note: The payment will be delivered to HAM via an internal link. In HAM the account of the CB will be debited and its own account in HAM will be credited.
Case 3 Receiver Field entry Effect Central bank customer S: BKAAFRPPXXX with CB customers R: TRGTXECBITX account BKFFITAAXXX 52: 56: 57: 58: BKFFITAAXXX

account in PM of BKAAFRPPXXX Credit entry in the RTGS account of the central bank customers CB
150
Note: The payment will be delivered to HAM via SWIFT. In HAM the account of the central bank customers CB will be debited and the account of the central bank customer will be credited. Sender direct PM participant co-manager of an HAM account holder In the following examples the direct PM participant (BKAAFRPP) sends the SWIFT messages (MT 202) to the HAM to transfer funds from the co-managed account to the PM.
Case 4 Receiver RTGS account holder of BKAAFRPPXXX Field entry S: BKAAFRPPXXX R: TRGTXEHMXXX 52: 53: BKNNFRWWXXX 56: 57: NCBFFRPPXXX 58: BKAAFRPPXXX Effect
Debit entry in the HAM

account of BKNNFRWWXXX Credit entry in the HAM account of the CB
Note: The presence of tag 57 means that the receiver is in PM. The payment 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 credited.
Case 5 Receiver RTGS account holder of BKEEFRPPXXX Field entry S: BKAAFRPPXXX R: TRGTXEHMXXX 52: 53: BKNNFRWWXXX 56: 57: NCBFFRPPXXX 58: BKEEFRPPXXX Effect

account of BKNNFRWWXXX Credit entry in the HAM account of the CB
Note: The presence of tag 57 means that the receiver is in PM. The payment 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 credited.
151
Sender is direct PM participant using a second BIC
In the following examples the direct PM participant (BKCCDEFFXXX) uses a second BIC (BKCCDEFF425) for sending SWIFT messages (MT 202).
Case 6 Receiver HAM account holder BKEEITRRXXX Field entry S: BKCCDEFF425 R: TRGTXEPMHAM 52: 56: 57: 58: BKEEITRRXXX Effect

account in PM of BKCCDEFFXXX Credit entry in the RTGS account in PM of the CB
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 holder will be credited.
Case 7 Receiver Field entry Effect Central bank customer S: BKCCDEFF425 with CB customers R: TRGTXECBITX account BKFFITAAXXX 52: 56: 57: 58: BKFFFITAAXXX

account in PM of BKCCDEFFXXX Credit entry in the RTGS account in PM of the central bank customers CB
Note: The payment will be delivered to HAM via SWIFT. In HAM the account of the central bank customers CB will be debited an the account of the central bank customer will be credited. Originator is indirect PM participant In the following examples the indirect PM participant (BKHHFRP1XXX) orders its related direct PM participant (BKCCDEFFXXX) to send the SWIFT message (MT 202).
Case 8 Receiver HAM account holder BKGGDEFFXXX Field entry S: BKCCDEFFXXX R: TRGTXEPMHAM 52: BKHHFRP1XXX 56: 57: 58: BKGGDEFFXXX Effect

account in PM of BKCCDEFFXXX Credit entry in the RTGS account in PM of the HAM account holders CB
152
Note: The payment will be delivered to HAM via an internal link. In HAM the account of the HAM account holders CB will be debited and the account of the HAM account holder will be credited.
Case 9 Receiver Central bank customer with CB customers account BKFFITAAXXX Field entry S: BKCCDEFFXXX R: TRGTXECBITX 52: BKHHFRP1XXX 56: 57: 58: BKFFFITAAXXX Effect

account in PM of BKCCDEFFXXX Credit entry in the RTGS account in PM of the central bank customers CB
Note: The payment will be delivered to HAM via SWIFT. In HAM the account of the central bank customers CB will be debited an the account of the central bank customer will be credited. Sender HAM account holder In the following examples the HAM account holder (BKEEITRRXXX) sends the SWIFT message (MT 202).
Case 10 Receiver Direct PM participant BKBBITRRXXX Field entry S: BKEEITRRXXX R: TRGTXEHMXXX 52: 56: 57: NCBIITRRXXX 58: BKBBITRRXXX Effect

account of BKEEITRRXXX Credit entry in the HAM account of the HAM account holders CB
Note: The payment will be delivered to PM via an internal link. In PM the account of the HAM account holders CB will be debited and the account of the direct PM participant will be credited. Sender central bank customer In the following examples the central bank customer (BKFFITAAXXX) sends the SWIFT message (MT 202).
Case 11 Receiver Direct PM participant BKBBITRRXXX Field entry S: BKFFITAAXXX R: TRGTXECBITX 52: 56: 57: 58: BKBBITRRXXX Effect

account of BKFFITAAXXX Credit entry in the HAM account of the central bank customers CB
153
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details Case 12 Receiver Second BIC (BKBBITRR321) of a direct PM participant, BIC of the related direct PM participant BKBBITRRXXX Indirect PM participant BKLLITROXXX Field entry S: BKFFITAAXXX R: TRGTXECBITX 52: 56: 57: 58: BKBBITRR321 S: BKFFITAAXXX R: TRGTXECBITX 52: 56: 57: 58: BKLLITROXXX Effect

account of BKFFITAAXXX Credit entry in the HAM account of the central bank customers CB account of BKFFITAAXXX Credit entry in the HAM account of the central bank customers CB
13
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 Sender HAM account holder Payments between account holders in HAM
In the following examples the HAM account holder (BKEEITRRXXX) sends the SWIFT message (MT 202).
Case 14 Receiver HAM account holder BKMMITSSXXX Field entry S: BKEEITRRXXX R: TRGTXEHMXXX 52: 56: 57: 58: BKMMITSSXXX Effect

account of BKEEITRRXXX Credit entry in the HAM account of BKMMITSSXXX
154
Sender RTGS account holder co-manager of an HAM account holder
In the following examples the RTGS account holder (BKBBITRRXXX), co-manager of the HAM accont holder (BKEEITRRXXX) sends the SWIFT message (MT 202) in favour of another HAM account holder (BKMMITSSXXX).
Case 15 Receiver HAM account holder BKMMITSSXXX Field entry S: BKBBITRRXXX R: TRGTXEHMXXX 52: 53: BKEEITRRXXX 56: 57: 58: BKMMITSSXXX Effect

account of BKEEITRRXXX Credit entry in the HAM account of BKMMITSSXXX
Sender central bank customer
In the following examples the central bank customer (BKFFITAAXXX) sends the SWIFT message (MT 202).
Case 16 Receiver CB customer with account BKOOITKKXXX Field entry S: BKFFITAAXXX R: TRGTXECBITX 52: 56: 57: 58: BKOOITKKXXX Effect

account of BKFFITAAXXX Credit entry in the HAM account of 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.
155
14.1.2.4.3 Sender direct PM participant
Payments with proprietary home accounts
In the following example the direct PM participant (BKAAFRPPXXX) sends the SWIFT message (MT 202).
Case 17 Receiver Account holder in the PHA BKFFLULUXXX Field entry S: BKAAFRPPXXX R: NCBKLULUXXX 52: 56: 57: 58: BKFFLULUXXX Effect

account in PM of BKAAFRPPXXX Credit entry in the PM of NCBKLULUXXX
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 participant using a second BIC In the following example the direct PM participant (BKCCDEFFXXX) sends the SWIFT message (MT 202) using its second BIC.
Case 18 Receiver Account holder in the PHA BKFFLULUXXX Field entry S: BKCCDEFF425 R: NCBKLULUXXX 52: 56: 57: 58: BKFFLULUXXX Effect

account in PM of BKCCDEFFXXX Credit entry in the PM of NCBKLULUXXX
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.
156
Originator is indirect PM participant
In the following example the indirect PM participant (BKLLITROXXX) orders its related direct PM participant (BKBBITRRXXX) to send the SWIFT message (MT 202).
Case 19 Receiver Account holder in the PHA BKFFLULUXXX Field entry S: BKBBITRRXXX R: NCBKLULUXXX 52: BKLLITROXXX 56: 57: 58: BKFFLULUXXX Effect

account in PM of BKBBITRRXXX Credit entry in the PM of NCBKLULUXXX
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 proprietary home account holder In the following examples the proprietary home account holder (BKFFLULUXXX) orders its CB to send the SWIFT message (MT 202). The field entries describe how the message has to be filled in by the sending CB. Note: The way the account holder in the proprietary home accounting system 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 Specifications.
Case 20 Receiver Direct PM participant BKAAFRPPXXX Field entry S: NCBKLULUXXX R: BKAAFRPPXXX 52: BKFFLULUXXX 56: 57: 58: BKAAFRPPXXX S: NCBKLULUXXX R: BKBBITRR321 52: BKFFLULUXXX 56: 57: 58: BKBBITRR321 Effect
Debit entry in the RTGS Credit entry in the RTGS

account in PM of BKAAFRPPXXX account in PM of the CB
21
Second BIC of direct PM participant BKBBITRR321

account in PM of BKBBITRRXXX account in PM of the CB
157
14.1 SWIFTNet FIN related issues 14.1.2 SWIFTNet FIN Messages - Details Case 22 Receiver Indirect PM participant BKDDDEM1XXX Field entry S: NCBKLULUXXX R: BKDDDEDDXXX 52: BKFFLULUXXX 56: 57: 58: BKDDDEM1XXX Effect

account in PM of BKDDDEDDXXX account in PM of the CB
Sender proprietary home account holder (liquidity transfer)
In the following example the proprietary home account holder (BKFFLULUXXX) orders its CB to send the SWIFT message (MT 202) as liquidity transfer. The field entries describe how the message has to be filled in by the sending CB. Note: The way the account holder in the proprietary home accounting system 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 Specifications.
Case 23 Receiver Direct PM participant BKFFLULUXXX Field entry S: NCBKLULUXXX R: TRGTXEPMXXX 52: BKFFLULUXXX 56: 57: 58: BKFFLULUXXX Effect

account in PM of BKFFLULUXXX account in PM of the CB
158
14.2 SWIFTNet InterAct and FileAct related issues 14.2.1 Overview
14.2
14.2.1
General aspects
SWIFTNet InterAct and FileAct related issues

Overview
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 SWIFTs Secure IP Network (SIPN). The processing of the use cases requires an application, which can interpret 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.
Use of SWIFTNet services
In the following table an overview is given for what purposes the XML messages are transferred via SWIFTNet InterAct and/or SWIFTNet FileAct:
Purpose Requests and responses related to ICM (A2A) SWIFTNet service InterAct or (FileAct) (pull mode) Remarks The request XML message is 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 response using FileAct.
159
14.2 SWIFTNet InterAct and FileAct related issues 14.2.2 How to use the application-to-application approach
14.2.2
System requirements
How to use the application-to-application approach
The system requirements, which must be fulfilled to implement an application-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, SWIFTs Public Key Infrastructure (PKI) is used. Further details of the various SWIFTNet services and the required infrastructures 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.
Tests
The applications developed for the A2A approach must be tested in accordance with the specified extent prior to being used.
160
14.2 SWIFTNet InterAct and FileAct related issues 14.2.3 Use cases
14.2.3
Use cases
Use cases are examples of requests in order to provide information or modify 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
14.2.3.1.1 Aim Precondition
Home Accounting Module

Modify reservation
It is used to request modifications in the details of one particular reservation, current or default, set by the participant.
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 Success
The value of the reservation is changed accordingly to the request. To verify the outcome of the request the member may submit a Get Reservation message with the appropriate search criteria An error message with the relevant code is issued. ModifyReservation
Postcondition Failure XML Request
161
XML Response
Receipt 14.2.3.1.2 Modify standing order
Aim Precondition
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.

the owner of the account the CB of an account owner
Postcondition Success Postcondition Failure XML Request XML Response
The amount of the standing order is accepted as requested. An error message with the relevant code is issued. ModifyStandingOrder Receipt 14.2.3.1.3 Liquidity transfer (between accounts belonging to the same participant in HAM and PM)
Aim Precondition
It is used to transfer funds from the HAM account to the RTGS account of the same participant.

the owner of the account the CB of the account owner
162
Postcondition Success
The request is queued/settled. To verify the outcome of the request the member may submit a Get
Transaction or Get Account message with the appropriate search criteria An error message with the relevant code is issued. LiquidityCreditTransfer Receipt 14.2.3.1.4 Regular transactions (interbank transfer between accounts belonging to different participants)
Postcondition Failure XML Request XML Response
Aim
It is used for:
Interbank transfers from an 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 Precondition
The user is logged in The requestor can be:

the owner of the account the co-manager of the account owner the CB of the account owner
The request is queued/settled. To verify the outcome of the request the member may submit a Get
Transaction or Get Account message with the appropriate search criteria
163
An error message with the relevant code is issued. LiquidityCreditTransfer Receipt 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
Precondition

the account owner the co-manager of the account owner the CB of the account owner
It provides information on:
HAM account balance standing orders for liqidity transfers from HAM to PM
An error message with the relevant code is issued. GetAccount ReturnAccount
164
Get reservation
It is used to request information on reservations (cash withdrawal and threshold for investment).

reservation for cash withdrawal (current and default reservations) threshold for advice of investment
An error message with the relevant code is issued. GetReservation ReturnReservation 14.2.3.1.7 Get transaction
Aim Precondition
It is used to request information about transactions details.

165
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 Success It provides information as follows:
Debit/credit indicator Transaction Identifier Amount Status (settled, rejected, revoked, queued, earmarked) Payment type Counterpart BIC Date
An error message with the relevant code is issued. GetTransaction ReturnTransaction
166
14.2.3.1.8 Aim
Get business day information
It is used to know the current status of the system, the events planned during 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.
Precondition

the owner of the account the CB Note: Each requestor can get data related to its own CB.
It provides the following information:
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 An error message with the relevant code is issued. GetBusinessDayInformation ReturnBusinessDayInformation
167
14.2.3.2
Reserve Management
Get account RM
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.

the account owner the CB of the account owner the co-manager of the account owner
It provides information concerning:
the value of the minimum reserve the end of day balance the running average the adjustment balance
An error message with the relevant code is issued. GetAccount ReturnAccount
168
14.2.3.3
14.2.3.3.1 Aim
Standing Facilities
Liquidity transfer between SF and PM/HAM account
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 overnight deposit).
Precondition

the account owner the co-manager of an account owner
The CB of the account owner (on behalf of the account owner as contingency measure) Postcondition Success
The request is settled. To verify the outcome of the request the member may submit a Get
Account message with the appropriate search criteria An error message with the relevant code is issued. LiquidityCreditTransfer Receipt
169
Get account SF
It is used to request information on the balance of the overnight deposit account and of the marginal lending account.

the account owner the co-manager of an account owner the CB of the account owner
Overnight deposit account balance Marginal lending account balance

An error message with the relevant code is issued. GetAccount ReturnAccount 14.2.3.3.3 Get transaction SF
Aim Precondition
It is used to request information about standing facilities transactions details.

the account owner the co-manager of an account owner the CB of the account owner
170
It provides information as follows:

Transaction type Transaction Identifier Amount Status Date
An error message with the relevant code is issued. GetTransaction 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 Aim Precondition Get HAM account
It is used to get information on HAM account held by a participant or HAM accounts co-managed by a participant.
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 account, 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, ...)
171
Postcondition success Postcondition failure XML Request XML Response
The information on the requested HAM account or co-managed HAM accounts is delivered to the application. An error message with the relevant error code is issued. GetHAMaccount ReturnHAMaccount 14.2.3.4.2 Get SF account
Aim Precondition
It is used to get information on SF account.
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
participant, 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 success Postcondition failure XML Request XML Response The information on the requested SF accounts is delivered to the application. An error message with the relevant error code is issued. GetSFAccount ReturnSFAccount
172
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 participants using SF.
173
14.3 Internet access related issues 14.3.1 Overview
14.3
14.3.1
General aspects
Internet access related issues

Overview
The Internet access allows the participation in TARGET2 without SWIFT connection. The participants will have access to a dedicated ICM U2A Internet interface for information and control purposes as well as for issuing credit transfers to other TARGET2 participants. As Internet-based participants 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 monitor all activities on their accounts via ICM during the business day. Nevertheless an account statement will be provided for download at start of day containing the turnover of the previous business day.
174
14.3 Internet access related issues 14.3.2 Account statement
14.3.2
Usage
Account statement
Internet-access banks will not receive statement files by TARGET2 in push mode. The Internet-based participant will get the account statement containing 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 participants will be saved in the file (field 86 in the repetitive statement line) and provided to the participants for download and archiving (see structure description 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 provided in ASCII format. The file is divided into repetitive sequences (because statement file generation 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 responsibility 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:
SWIFT standard Status M Field 20 Field name Transaction Reference Number Related Reference Status M Format 16x SSP Specifications Use in SSP HAM: SSP progressive Must not be used.
21
175
14.3 Internet access related issues 14.3.2 Account statement SWIFT standard Status M Field 25 Field name Account Identification Statement Number/ Sequence Number Status M Format 35x SSP Specifications Use in SSP Usage up to 34 digits; account number related to HAM / CB customer account debited by an ancillary system. Statement Number: At the beginning of the year and for the first message of a new participant 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 Balance M Option F: 1!a6!n3!a15 d Option M: 1!a6!n3!a15 d ----> F = First Opening Balance D/C Mark, Date, Currency, Amount
28C
5n[/5n]
176
14.3 Internet access related issues 14.3.2 Account statement SWIFT standard Status O Field 61 Field name Statement Line Status O Format 6!n[4!n]2a[1 !a]15d1!a3! c16x[// 16x][34x] Sub- Forfield mat 1 2 3 6!n [4!n] 2a PM: Value date (YYMMDD) Business day date (MMDD) SSP Specifications Use in SSP
Characters for Debit/Credit Characters for Reversal of Debit/

Credit (RD or RC) (D or C)
4 5 6
[1!a] 15d
Code for money type (not being used) Amount in Euro
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.
177
14.3 Internet access related issues 14.3.2 Account statement SWIFT standard Status Field Field name Status 7 Format 16x SSP Specifications Use in SSP Ordering partys 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 during the day, backup payments, internal payments from HAM/SF/ RM/CM/CRISP to PM) reference (field 20) of the internal message if field is not available/filled: PM reference AS transactions: Tag 20 for MT 202 Message Identification for LiquidityCreditTransfer SSP internal reference for U2A, standing orders and operations ordered by PM EndToEndIdentification for all other cases (requested by ASTransferInitiation) Reference for the institution maintaining the account: SSP internal posting reference for unique identification AS transactions: SSP internal reference
[// 16x]
178
14.3 Internet access related issues 14.3.2 Account statement SWIFT standard Status Field Field name Status 9 Format SSP Specifications Use in SSP [34x] <BIC of the sender from the SWIFT Header> /<settlement time HHMMSS> [/<BIC from field 52>] optional [/BUP/] optional; only for backup payments /MANPAY/ for mandated payments Origin of payment is within SSP: <PM BIC> for payments initiated by PM (eg liquidity retransfer at EoD to HAM, PHA or other participants, <BIC customer of ICM request> for payments initiated via ICM (eg liquidity transfer from PM to HAM and PHA during the day backup payments) <BIC of field 53 of the internal message> for internal payments from HAM/SF/RM/CM/CRISP to PM AS transactions: <PM BIC>/HHMMSS for standing orders and for emergency procedure 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.
179
14.3 Internet access related issues 14.3.2 Account statement SWIFT standard Status Field Field name Status 1 2 3 Format HAM: 6!n [4!n] 2a Transaction accounting date in YYMMDD format Not used Sign: C - Credit D - Debit RC - Reverse Credit RD - Reverse Debit Not used Amount SSP Specifications Use in SSP
4 5 6
[1!a] 15d
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 indicated. 16x Tag 20 of the message to which the transaction type is referred. For XML messages first 16 characters of the MsgID. Internal HAM reference
8 9
[// 16x]
[34x] Tag 21 of the incoming MT 202 message. Note: The postings (debit entries and credit entries) are sorted according to the sequence of the settlement.
180
14.3 Internet access related issues 14.3.2 Account statement SWIFT standard Status O Field 86 Field name Information to Account Owner Status O Format 10240x SSP Specifications Use in SSP Original SWIFT string of textblock (Block 4) of incoming SWIFT messages from SWIFT-based participants as well as generated SWIFT string of textblock (Block 4) in case of payments from other Internet-based participants F = Final Closing Balance D/C Mark, Date, Currency, Amount
----| M 62a Closing Balance (Booked Funds) M Option F: 1!a6!n3!a15 d Option M: 1!a6!n3!a15 d O 64 Closing Available Balance (Available Funds) Forward Available Balance Information to Account Owner O 1!a6!n3!a15 d
M = Intermediate Closing Balance D/C Mark, Date, Currency, Amount Not used by the SSP.
----> O 65 O 1!a6!n3!a15 d Not used by the SSP.
----| O 86 O 6*65x Not used by the SSP.
181
14.4 Entry check 14.4.1 Double entry check for HAM
14.4
14.4.1
Basics
Entry check
Double entry check for HAM
HAM carries out a duplicate submission control. This control includes various SWIFT fields. Viewed together, they must be clearly filled in for each business day. Otherwise the payment is rejected because of duplicate submission. The details are gathered from the following fields of the SWIFT message types:
Details Sender TRN Value date Part of the SWIFT message Basic Header Text Block Text Block :20 :32A (first 6 characters) Field BIC (extracted from LT)
Details
182
14.4 Entry check 14.4.2 Error codes
14.4.2
Error codes
Error codes
A complete list of error codes is provided in UDFS book 1, chapter 9.5.2.
183
15 Test procedures
15
General remark
Test procedures
The optional modules will be tested according to the same testing procedures as mandatory modules.
184
Glossary and Abbreviations

Note: Terms and abbreviations are listed in alphabetical order. In the case only the abbreviation is used in the User Detailed Functional Specification the term is explained afterwards, otherwise a reference is made. 3CB Banca dItalia, Banque de France, Deutsche Bundesbank
A
A2A Application-to-application In this approach, communication is directly between applications customers 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 Balance Algorithm Amount needed at the end of each day in order to fulfil the reserve requirement. An algorithm is a mathematical method to provide a smooth, fast and liquidity saving resolution of the payment queue, for example by taking offsetting payment flows into account. Ancillary systems are:
Ancillary system
retail payment systems (RS) large value payment systems (LVPS) foreign exchange (FX) systems
Version 4.01
money market systems clearing houses securities settlement systems (SSS)

Ancillary System Interface The Ancillary System Interface (ASI) is a standardised interface to the Payments Module (PM) which can be used by ancillary systems (ASs) to perform the cash clearing of their business. By means of the ASI the AS manager initiates the settlement procedures of an AS. Asynchronous Remote Copy See ancillary system See Ancillary System Interface Account offered in TARGET2 for specific use of ancillary systems.
Ancillary system manager ARC AS ASI AS Technical 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. The auto collateralisation is a specific mechanism used to provide additional liquidity to the SSS settlement process.
Auto collateralisation
Version 4.01
II
This technique is based on the automatic interaction between the collateral manager, the SSS and the SSP to perform collateralisation functions (eg eligibility 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).
Version 4.01
III
B
Backup payments Owing to a breakdown a direct PM participants 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 lump-sum payments are used to redistribute the liquidity that has
accumulated on the defaulting participants account. As soon as the defaulting PM participant is once again able to do so, the original single payments belonging to the backup lump-sum payments previously made are submitted to the PM and the recipients of such backup lump-sum payments have to return the backup lump-sum payments.
Backup contingency payments are used to fulfil obligations arising from

settlement or pre-fund payments on time. The backup contingency payment replaces the original payment. Batch A group of orders (payment orders and/or securities transfer orders) to be processed as a set. Bank Identifier Code The first 8 characters of the BIC, when used for addressing purposes, are called destination. 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 BIC-8
BIC-11
Version 4.01
IV
BIC directory
Directory published by SWIFT. It contains the bank identifier codes (BIC) of the credit institutions. A SWIFT service for the exchange of bilateral keys between correspondents over the SWIFT network, using enciphered data carried with dedicated messages. Bank for International Settlements See Bilateral Key Exchange 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.
Bilateral Key Exchange
BIS BKE Blocked amount
Broadcast
Information message simultaneously available to all or a selected group of SSP participants. 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, ). Payment systems arrangements which aim to ensure that it meets agreed service levels even if one or more components of the system fail or if it is affected by an abnormal external event. Include both preventative measures and arrangements to deal with contingencies.
Business case
Business continuity
Version 4.01
Business day
The business day in PAPSS starts at 18.45 (d-1) with the Start-of-day processing and ends at 18.45 (d) with the completion of the end-of-day processing.
C
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. Central bank Entity that is not allowed to open accounts in PM according to TARGET Guideline (eg correspondent bank not located in EEA). Mandatory account held by a CB which has opted for HAM. The account is used to manage CB customer payments between PM and HAM. Account with a CB in the Home Accounting Module, belonging to an entity that is not authorised, according to TARGET Guideline, to have an RTGS account. SWIFT Computer Based Terminal
CB CB customer
CB Customer Liquidity Bridge CB customers account
CBT
Version 4.01
VI
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 system.
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 depository
An entity, which holds and administrates securities and enables securities 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 securities, a central securities depository may incorporate clearing and settlement and assets servicing functions. Central European Summer Time Central European Time See credit institution The process of calculating the mutual obligations of market participants for the exchange of securities and money. It may include the process of transmitting, reconciling and, in some cases, confirming payment or securities orders.
Version 4.01
CEST CET CI Clearing
VII
Clearing house
An entity hosting a clearing system, which consists of a set of rules and procedures whereby financial institutions present and exchange data and/or documents relating to funds or securities transfers to other financial institutions 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. A subset of customers grouped for the purpose of their use of the relevant SWIFT services and products when accessing the Payments Module. Continuous Linked Settlement Global settlement system for foreign exchange transactions, providing participants with simultaneous processing of both sides of the transaction and thereby eliminating the settlement risk.
Closed User Group CLS
CM Collateral
See Contingency Module 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. A system managed by the central bank or by a third party (on behalf of the 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 manager
Version 4.01
VIII
Collateral pool
Assets owned by members of a transfer system that are collectively available to the systems collateral to enable it to obtain funds in circumstances specified in its rules. The aim is to allow small banks to manage directly their reserve requirements, 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. The quality of being protected against unauthorised disclosure. Payments by a CB or AS to a participant that trigger a change in the credit line of this participant and an immediate debit/credit of its account to compensate the change in this credit line. Common mandatory tool for the CBs for the management of the emergency situations in order to process critical and very critical payments. 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. Customer Relationship And Knowledge of System It gathers all services needed to support customer relationship and knowledge of payment systems by the central banks.
Co-Management function
Confidentiality Connected payment
Contingency Module Country Code
CRAKS
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.
Version 4.01
IX
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 & Comments services. The definition given to a bank in the European Union. The First EC Banking Directive defines it as an undertaking whose business is to receive deposits or other repayable funds from the public and to grant credits for its own account. Maximum collateralised overdraft position of the balance on an RTGS account 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 immediately. 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 reduced credit line.
Credit institution
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 intermediaries and/or via one or more funds transfer system. 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.
CRISP
CRM
See Customer Relationship Management
Version 4.01
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 calculation, files for statistics on intraday credit and profiling information. The CROSS is offered on the CRSS platform.
Cross CSD Cross DVP settlement
See Cross DVP settlement. Procedure enabling an Ancillary System (normally CSDs) using ASI procedure 6 to move dedicated liquidity of a settlement bank to another. Ancillary System using ASI using procedure 6. The settlement takes place on the mirror account for integrated AS and on the sub-accounts for interfaced AS.
Cross-CB payments CRSS
Payments between participants of different CB on the SSP.
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 relationship optional services (CRAKS3).
Cryptography
The application of mathematical theory to develop techniques and algorithms that can be applied to data to ensure goals such as confidentiality, data integrity and/or authentication.
Version 4.01
XI
CSD CUG Customer
See central securities depository See Closed User Group Entity which is not a participant (direct or indirect) and which uses the service of a participant to exchange transactions in the system. The CBs as participants can also have customers. Term referring to the management by CBs of customer-oriented information related to participants and customers (CIs, AS, other customers eg CB customers 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 implemented on the CRSS platform.
Customer Relationship Management
D
Daylight processing Day Trade Phase Dedicated account See Day Trade Phase
Period of time in PAPSS between 7.00 and 18.00. Account in the PM on which dedicated liquidity for ancillary system settlement is held. This can be either a sub-account (interfaced model) or a mirror account (integrated model).
Version 4.01
XII
Dedicated liquidity
Liquidity held on a PM sub-account or mirror account to allow the settlement of an ancillary system. Conditional or unconditional transfer of financial instruments by book entry of physical exchange. A link between securities transfers and funds transfers system that ensures that delivery occurs if, and only if, payment occurs. 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. An agent with the primary role of recording securities either physically or electronically and may keep records of the ownership of these securities. An authorised debit on the payers bank account initiated by the payee. A participant in a system that directly carries out transactions with other participants 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. The X.500 notation for an entity. The SWIFTNet identifiers (for example, institutions address, certicates 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
Delivery
Delivery versus payment Deposit facility
Depository
Direct debit Direct participant
Distinguished name
Version 4.01
XIII
DN DN Suffix
Distinguished Name 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). See delivery versus payment
DVP
E
EBA ECB ECB Account ECB Mirror Account ECSDA EEA Euro Banking Association European Central Bank See NCBs ECB account Account held by the ECB for each CB in the PM on which the bookings done on the NCBs ECB accounts will be mirrored. European Central Securities Depositories Association European Economic Area
Version 4.01
XIV
Encryption
The use of cryptographic algorithms to encode clear text data (plaintext) into ciphertext to prevent unauthorised observation. European Payments Council European System of Central Banks European Union
EPC ESCB EU
F
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 participant BIC are displayed. 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. 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 instead; also called Bypass FiFo.
FIFO
FIFO by-passing
Version 4.01
XV
Final settlement
The discharge of an obligation by a transfer of funds and a transfer of securities that have become irrevocable, irreversible, or not annullable. A hardware- and/or software-based system that is used as an interface between the internet and a computer system to monitor and filter incoming and outgoing communication.
Firewall
G
GARI MT Component of the SWIFT Interface. Communication software for the exchange of SWIFT FIN messages. Component of the SWIFT Interface. Communication software for the exchange of XML messages. The General Ledger sometimes known as nominal ledger, is the main accounting record of a business which uses double-entry bookkeeping. 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. A transfer system in which the settlement of funds or securities transfer orders occurs individually (on an order by order basis). See Liquidity pooling functionality
GARI NT
General Ledger
Gridlock
Gross settlement system Group of accounts
Version 4.01
XVI
Guarantee fund mechanism
Mechanism to provide the complementary liquidity needed according to pre-defined rules in case an AS cannot settle using the settlement banks liquidity only. Account held on the SSP for maintaining or collecting funds allocated to the settlement of balances of an ancillary system in case of failure of settlement bank(s).
Guarantee funds account
H
HAM Home account See Home Accounting Module 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 participants (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 Payments Module The home accounts are managed by the HAM or by a proprietary accounting system. Home Accounting Module The Home Accounting Module (HAM) is an optional module. In the case, a central bank opts for the use of this module different standardised account services are offered for the central bank and its customers. CB, where the direct participant is located.
Home CB
Version 4.01
XVII
Host CB HTTPS
CB, via which a direct participant uses the possibility of remote access. Hyper Text Transfer Protocol Secure It is a protocol which is used to secure the data exchange in case of access over Internet.
I
IBP ICM Indirect participant See Internet-based participant. See Information and Control Module Indirect participants are distinguished from direct participant by their inability to perform some of the system activities performed by direct participants, in particular they do not hold RTGS accounts. Indirect participants require the services of direct participants to perform those activities on their behalf (settling the payments input to the transfer system). Mandatory and unique functional interface between the direct participants and the Payments Module (PM) and the other optional modules like
Information and Control Module
Home Accounting Module (HAM) Reserve Management (Module) (RM) Standing Facilities (Module) (SF) Static Data (Management) Module (SD)
Version 4.01
XVIII
Integrity
The quality of being protected against accidental or fraudulent alteration of transmission and of storage, or the quality of indicating whether or not alteration has occurred. An entity which is connected to the SSP via Internet. ICM offers via U2A customised functions with regard to the needs ot the Internet-based participant Payment between participants of the same CB on the SSP. 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:
Internet-based participant
Intra-CB payment Intraday credit
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 financial institutions to make payments on an intraday basis.
L
Legal entity Credit institution directly participating in the SSP through (also AS when participating 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 information about this credit institution in the Static Data (Management) Module.
Version 4.01
XIX
Limit
Amount for normal payments a direct PM participant is willing to pay to another participant (bilateral limit) or to the other participants (multilateral limit towards whom no bilateral limit is defined), without having received payments (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 urgent payments from a participant towards whom a bilateral/multilateral limit is defined also affect the bilateral/multilateral position.
Liquidity pooling functionality
A facility, based on the idea of allowing TARGET2 participants to pool their 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 capital and/or management link. The following two options are offered: virtual accounts (only for euro area participants) and consolidated information (available also to participants from non-euro area countries). Transfer of funds between accounts of the same participant or between two accounts of a group of accounts. It is also a generic settlement procedure (procedure 1), where liquidity is transferred from/to a mirror account to/from a settlement banks RTGS account. There are two kinds of liquidity transfers available:
Liquidity transfer
current:
transfers executed immediately after entry if sufficient liquidity is available
Version 4.01
XX
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.
M
MAC Mandated payment Message Authentication Code Payment initiated by an entity that is not party to the transaction (typically by 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 structure) on behalf of the failed direct participant (only in case of contingency situations). A standing facility of the Eurosystem which counterparties may use to receive overnight credit from a CB at a pre-specified interest rate against eligible assets. In general possible options:
Marginal lending facility
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.
Version 4.01
XXI
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. See Monetary Financial Institution Message Input Reference In fact specific RTGS accounts opened to CBs for the specific use of AS. Mirror accounts are mirrored by another account opened in the SSS. It is debited or credited in case of liquidity transfer between a participants RTGS account in PM and its account in an ancillary system. A Monetary Financial Institution (MFI) comprise resident credit institutions as defined in Common law, and other resident financial institutions whose 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. Message Output Reference See Message type
MFI MIR Mirror account
Monetary Financial Institution
MOR MT
Version 4.01
XXII
N
NCB NCBs ECB account Netting National Central Bank Account which is necessary to record the CBs asset/liability position vis--vis the ECB in respect of cross-border transactions. An agreed offsetting of positions or obligations by participants in a clearing or settlement system. The netting reduces large number of individual positions or obligations to a smaller number of obligations or positions. Netting may take several forms which have varying degrees of legal enforceability in the event of default of one of the parties. An agreement where obligations from individual transfer orders are netted 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 parties. Period of time for settlement of AS transactions (settlement procedure 6) between 19.30 h and 6.45 h (interruption for technical maintenance between 22.00 h and 1.00 h). The bank identifier code of a financial institution not connected to the SWIFT network. Non-SWIFT-BICs are identified by a 1 as the eighth character.
Netting by novation
Night time processing
Non-SWIFT-BIC
Version 4.01
XXIII
O
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 offsetting mechanism considers payments in the queues of participants and tries to settle them simultaneously on a gross basis within one legal and logical second. See marginal lending facility Deposits with next-day maturity.
Overnight credit Overnight deposit
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)
Version 4.01
XXIV
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 participant). In the SSP two general kinds of payments are possible for direct participants:
Payment
customer payments (MT 103, MT 103+) bank-to-bank payments (MT 202, MT 204)
Payment message/ instruction An order or message to transfer funds (in the form of a monetary claim on a party) to the order of the beneficiary. In TARGET2 the order may relate either to a credit transfer or a direct debit. Mandatory module which allows the settlement of payments in the RTGS account, held by all direct participants. In addition, it offers advanced services for liquidity management, for the communication with participants and ancillary systems. See proprietary home account Public Key Infrastructure
Payments Module
PHA PKI
Version 4.01
XXV
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 interest (lien) in the assets delivered, while leaving ownership with the debtor. See Payments Module In general, payments are settled immediately, if sufficient liquidity is available on the RTGS account of the participant. Considering their urgency, they can be submitted by the sender using priorities:
PM Priority
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 Information delivered to CBs on the past behaviour of a participant or a group of participants, aggregated over a past period, and aimed at being comparable with current business day information. Account held by CBs outside of the SSP eg
Proprietary home account
for entities that cannot have the status of direct participants in PM for entities allowed to open RTGS accounts that are indirect PM participants (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.
Version 4.01
XXVI
Proxy
Component of the SWIFT Interface
Q
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 Raw data file Restart after disaster 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 access to service functions. Real-time gross settlement The continuous (real-time) settlement of funds or securities transfers individually on an order by order basis (without netting).
Version 4.01
XXVII
Real-time gross settlement (RTGS) system
A settlement system in which processing and settlement take place in real-time 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. A direct participant in the SSP which does not have any representation in the SSP country via he takes part in the SSP. See repurchase agreement A contract to sell and subsequently repurchase securities at a specified date and price. With the usage of the reservation facility liquidity can be reserved by RTGS account holders for the execution of special transactions with a certain priority class. HAM account holders can use the reservation facility to reserve liquidity for the execution of cash withdrawals. Reservations can be effected and adjusted using the ICM. Liquidity intraday and overnight maintained on the RTGS account at the end-of-day. Module enabling CBs to perform some functionalities for the reserve requirements management, eg verify the minimum reserves fulfilment or calculate the interest to be paid to credit institutions for minimum reserves.
Remote participant
Repo Repurchase agreement Reservation
Reserve holdings
Reserve Management (Module)
Version 4.01
XXVIII
Reserve requirement
The obligation of euro area credit institutions to hold minimum reserves on reserve accounts with their home NCBs. The reserve requirement is determined 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. See Reserve Management (Module) Account held by a CB for performing bookings related to the payment of interest on minimum reserves and to the payment of penalties of a CI which has not fulfilled minimum reserve requirements (optional). See real-time gross settlement 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).
RM RM Interest and Penalty Account
RTGS RTGS account
S
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.
Version 4.01
XXIX
SAG
SWIFT Alliance Gateway SWIFT Alliance Gateway is the single window to all SWIFTNet communications. All SWIFTNet message flows can be concentrated through one interface. This includes applications connected via WebSphere MQ, and also those designed for linking to SWIFTNet Link or based on SWIFTAlliance WebStation/ Web Platform.
SB SD Securities settlement system Self collateralisation SEPA Settlement bank
See settlement bank See Static Data (Management) Module The full set of institutional arrangements for confirmation, clearing, settlement, custody and registration of securities. See auto collateralisation
See Single Euro Payments Area 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). See Standing Facilities (Module) Account held by a CB for performing bookings related to the payment of interest on Standing Facilities (optional).
SF SF Interest Account
Version 4.01
XXX
Single Euro Payments Area
Term to describe a statues where the euro area has achieved the same degree of integration of payment systems, payment instruments and payment infrastructure as that which is usually in a single-country currency area. TARGET2 is based on a single technical platform, known as the Single Shared Platform which includes the PAPSS (Payment and Accounting Processing Services Systems) and the CRSS (Customer Related Services System). Secure Internet Protocol Network Secure, high-availability and worldwide virtual private network by SWIFT based on the International Protocol (IP) and related technologies and provides transfer services required by SWIFTNet services.
Single Shared Platform
SIPN
SLA SSP SSP OT SSS Standing Facilities (Module)
Service Level Agreement See Single Shared Platform SSP Operational Team See securities settlement system The Standing Facilities (Module) is an optional module and enables to manage the overnight standing facilities (deposit facility, marginal lending facility).
Version 4.01
XXXI
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 mirror account (integrated model). This module ensures a proper and reliable management of static data by storing all statistic data actually used. It caters for data consistency between all modules of the SSP. Inter alia the Static Data (Management) Module is used to generate the TARGET2 directory. Specific account, belonging to an RTGS account, holding dedicated liquidity to allow the settlement of an ancillary system. Society for Worldwide Interbank Financial Telecommunication An entity which is connected to the SSP via SWIFT's Secure IP Network.
Static Data (Management) Module
Sub-account
SWIFT SWIFT-based participant SWIFT-BIC
A bank identifier code of a financial institution connected to the SWIFT network.
Version 4.01
XXXII
SWIFTNet Browse
SWIFT service based on the https internet standard protocol, enabling users 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. 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. SWIFT interactive messaging service supporting the exchange of messages between two parties. On the SSP the InterAct service is used for the transfer of XML requests via the Secure IP Network (SIPN) by SWIFT to the ICM. An instruction to transfer funds; the exchange of funds (settlement) subsequently takes place over a payment system or through correspondent banking relationships; used for all payments and the related transactions on the SSP.
SWIFTNet FileAct
SWIFTNet InterAct
SWIFT payment message
T
TARGET TARGET working day Trans-European Automated Real-time Gross settlement Express Transfer The TARGET working day (d) equals the calendar day with the exception of the days when the TARGET system is not operated.
Version 4.01
XXXIII
TARGET2 directory
Directory used by participants to find out where a payment has to be addressed by SWIFTNet Y-copy mode. On a domestic level, it could be used to find the relation between the national sorting codes and the related BICs. Account held by a CB for the collection of TARGET2 fees of direct participants (optional). Via the ICM it is possible to transmit
TARGET2 Fees Account Task
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 Account used in the context of ancillary systems operations as intermediary 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. An alphanumeric reference of up to 16 characters assigned by the sender to messages sent over the SWIFT network. 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
Transaction Reference Number Transfer
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.
Version 4.01
XXXIV
The act of transfer affects the legal rights of the transferor, transferee and possibly third parties in relation to the money balance, security or other financial instrument being transferred. TRN TSRC See Transaction Reference Number TARGET Security Requirements and Controls
U
U2A User-to-application The objective is to permit direct communication between a participants users and the ICM. The information is displayed in a browser running on a PC system. Control activities are performed manually by the user. User UTC Each participant (direct and indirect). Universal Time Coordinates A standard adopted by SWIFT for encoding date and time.
Version 4.01
XXXV
V
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 accounts composing it. Type of transmission of SWIFT messages on the SSP which is mostly used in the context of payments processed via HAM.
V- Shape
W
Warehoused Payment Payments submitted up to five TARGET working days in advance. In this case, the payment message will be warehoused until the day trade phase of SSP with the respective date starts. In Select Criteria screens and Select screens of the ICM it is possible to search with the following wildcards:
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.
Version 4.01
XXXVI
X
XML Acronym for Extensible Markup Language Subset of Standard Generalized Markup Language (SGML - ISO 8879) designed especially for use on the Web and in Web-based applications.
Y
Y-copy Standard type of transmission of SWIFT messages on the SSP which is used in the context of payments processed via PM.
Version 4.01
XXXVII

Target2 SSP Udfs Book 2 Version 4.01 - tcm46-242572

Uploaded by

Copyright:

Available Formats

Target2 SSP Udfs Book 2 Version 4.01 - tcm46-242572

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

Target2 SSP Udfs Book 2 Version 4.01 - tcm46-242572

Uploaded by

Copyright:

Available Formats

Single Shared Platform

Introduction User Guide for optional modules

User Guide for Reserve Management (Module) (RM) ..... 42

User Guide for Standing Facilities (Module) (SF) ........... 47

ICM User Handbook

Version 4.01 - 29 October 2010 - TARGET2 UDFS Book 2

Version 4.01 - 29 October 2010 - TARGET2 UDFS Book 2

SWIFTNet InterAct and FileAct related issues .............. 159

Internet access related issues ........................................ 174

Entry check ....................................................................... 182

Version 4.01 - 29 October 2010 - TARGET2 UDFS Book 2

Test procedures Glossary and Abbreviations

Version 4.01 - 29 October 2010 - TARGET2 UDFS Book 2

Payments processing in the

Liquidity pooling Limits Liquidity reservations

Standing Facilities (Module)

Home Accounting Module

Scope of this book

Version 4.01 - 29 October 2010 - TARGET2 UDFS Book 2

Services provided only to central banks Mandatory Optional

Billing optional services

optional services for CBs (CRISP, CRAKS1, CRAKS3)

Payments Module (PM)

Static Data Management (SD) Monitoring Contingency Module (CM)

payments processing participant interface (Y-copy) Ancillary Systems Interface

Information and Control Module (ICM)

CBs (internal accounting, collateral management, proprietary home accounts, etc.)

credit institutions (CI)

ancillary systems (AS) Scope of this book

Version 4.01 - 29 October 2010 - TARGET2 UDFS Book 2

The present document is structured as follows:

Chapter 12 User Guide for optional modules

Chapter 13 ICM User Handbook

Chapter 14 Technical Specifications

Chapter 15 Test procedures

Version 4.01 - 29 October 2010 - TARGET2 UDFS Book 2

12 User Guide for optional modules

User Guide for optional modules

CB customers (correspondents and others) not allowed, according to the

Version 4.01 - 29 October 2010 - TARGET2 UDFS Book 2

12 User Guide for optional modules

HAM accounts: Transactions allowed

Version 4.01 - 29 October 2010 - TARGET2 UDFS Book 2

12 User Guide for optional modules

CB customers accounts: Transactions allowed

CB's customer accounts

Information and Control Module (ICM) at the initiative of the account

MT 202, MT 202 COV (Bank to Bank payment with customer credit

12 User Guide for optional modules

The functional architecture of HAM is illustrated in the following slide:

"HAM accounts holders"

"CB customer's accounts holders"

(Browse/InterAct Cash reporting)

(Browse/InterAct Cash reporting)

SWIFTNet SWIFT Interface RM HAM Liquidity bridge SF PM

"HAM accounts holders"

"CB customer's accounts holders"

Version 4.01 - 29 October 2010 - TARGET2 UDFS Book 2

12 User Guide for optional modules