ecb ezb ekt bce ekp - european central bank7.2.3 do i need to exchange swift keys with banks to...

INFORMATION GUIDEFOR CREDIT

INSTITUTIONS USINGTARGET

July 2003

EC

B

EZ

B

EK

T

BC

E

EK

P

INFORMATION GUIDEFOR CREDIT

INSTITUTIONS USINGTARGET

July 2003

© European Central Bank, 2003

Address Kaiserstrasse 29

D-60311 Frankfurt am Main

Germany

Postal address Postfach 16 03 19

D-60066 Frankfurt am Main

Germany

Telephone +49 69 1344 0

Internet http://www.ecb.int

Fax +49 69 1344 6000

Telex 411 144 ecb d

All rights reserved. Reproduction for educational and non-commercial purposes is permitted provided that the source is acknowledged.

ISBN 92-9181-373-7 (print)

ISBN 92-9181-374-5 (online)

3ECB • Information guide for credit institutions using TARGET • July 2003

1 Introduction 7

2 TARGET 72.1 Definition 72.2 Legal framework 72.3 Principles 82.4 Access criteria 82.5 Structure of TARGET 9

2.5.1 National RTGS / TARGET Interlinking 102.5.2 Credit institutions 112.5.3 SWIFT 11

3 TARGET Payments 133.1 Payments in TARGET 133.2 Customer payments 133.3 Interbank payments 153.4 Validation of customer and interbank payments 153.5 Remote access banks 153.6 Return payments 15

3.6.1 The sending side 163.6.2 The return key 163.6.3 The returning side 173.6.4 Recommendations 17

4 The TARGET Day 184.1 The TARGET information system (TIS) 184.2 Opening balances in TARGET 184.3 Messages exchanged between NCBs/ECB 194.4 Settlement of ancillary systems 194.5 End-of-day procedures 19

4.5.1 Cut-off for customer payments 194.5.2 Cut-off for interbank payments 204.5.3 Finalisation of payment account balances for RTGS system participants 214.5.4 Abnormal circumstances: delayed closing 21

5 Incident management 225.1 Business Logic of TARGET Incident Management 22

5.1.1 Redundancy as a way to achieve business continuity 225.1.2 Business continuity as the preferred option 225.1.3 The need for core payment settlement functions in TARGET in a

contingency 235.2 The scope of contingency processing 235.3 Preconditions For Processing Payments in Contingencies 24

5.3.1 The recommendations for CLS payments in euro (the normal framework) 245.3.2 TARGET contingency testing and end-to-end live trials 245.3.3 A streamlined decision-making process 24

5.4 Operational Responsibilities and Decision-Making Process In TARGET 255.4.1 Operational responsibilities 255.4.2 The internal decision-making process 255.4.3 Communication with banks and settlement systems 26

5.5 Who can be contacted with a problem or query? 26

Contents

ECB • Information guide for credit institutions using TARGET • July 20034

6 TARGET Compensation scheme 266.1 Introduction 266.2 Scope of the Scheme 276.3 Compensation under the Scheme 276.4 Applying for Compensation 286.5 Receiving the Compensation 296.6 Example 29

7 Frequently asked questions on TARGET 307.1 TARGET operating times 30

7.1.1 Working days and non-business days 307.1.2 Opening hours 307.1.3 Are all credit institutions obliged to be open when TARGET is open? 30

7.2 Sending and receiving TARGET payments 307.2.1 Is there a daily volume limit in TARGET? 307.2.2 Is there a minimum value for payments to be processed in TARGET? 317.2.3 Do I need to exchange SWIFT keys with banks to which I wish to send

payments? 317.2.4 Do I need to use the code “//RT”? 317.2.5 When are payments received by indirect participants? 31

7.3 Queuing mechanisms 327.4 Liquidity 327.5 TARGET fees 32

8 Business practices 338.1 European Banking Federation 33

8.1.1 European Banking Federation Guidelines on Liquidity Management 338.1.2 European Banking Federation Guidelines on Interbank Compensation 34

8.2 Recommendations for CLS Payments In Euro 348.2.1 Scope of the recommendations 348.2.2 Recommendation 1 358.2.3 Recommendation 2 358.2.4 Recommendation 3 358.2.5 Recommendation 4 35

8.3 Applying value 368.4 Bank-to-bank charges for customer payments 36

9 Documentation 379.1 ECB Publications 37

9.1.1 TARGET – basic texts 379.1.2 TARGET – general information 37

9.2 Other websites providing information on payments systems 379.2.1 European Banking Federation website 379.2.2 Bank for International Settlements website: Documents from the

Committee on Payment and Settlement Systems 37


10 Annexes 3910.1 Reactions where the NCB/ECB BIC appears in the first credit field 3910.2 Validation of Euro Related Information 3910.3 Payments to an NCB 4010.4 Routing to remote access banks 4110.5 Customer payment 42

10.5.1 General format of MT100 Interlinking messages 4210.5.2 General format of MT103 Interlinking Messages 4310.5.3 Example of a customer’s payment : 45

10.6 Interbank payment 4610.6.1 General format of MT202 Interlinking messages 4610.6.2 Example of a bank-to-bank payment : 47

10.7 Return payments 4710.8 Queuing mechanisms 4810.9 TARGET - Processing in Contingencies 48

10.9.1 TARGET components and potential failures 4810.9.2 Scenario 1: failure of the credit institution component 4910.9.3 Scenario 2: Failure of a TARGET access point 49

10.10 TARGET contingency procedures 5010.10.1 General overview of contingency processing 5010.10.2 “Interlinking contingency” 5010.10.3 “Contingency using Correspondent Accounts” (CoCA) 5110.10.4 Resuming normal operations 51

10.11 Explanatory Memorandum on The Recommendations Concerning CLSPayments in Euro 5210.11.1 Introduction 5210.11.2 TARGET contingency and CLS-related payments 5210.11.3 The general framework for CLS-related payments 5310.11.4 Recommendations for CLS-related payments 54

10.12 Settlement times for ancillary systems settling in TARGET 5610.13 Mapping of Domestic Messages to and from the Interlinking Format 60

11 Glossary of terms 169


1 Introduction

This Information Guide aims to provide creditinstitutions using TARGET with a standardset of information, in order to give them abetter understanding of the overallfunctioning of the system and enable them tomake use of it as efficiently as possible. Itanswers the most frequently asked questionsrelating to TARGET and tries, in particular,to give users a clear understanding of whichfeatures are common and which are specificto each country.1

This Information Guide has been designedspecifically with a view to being updated asnecessary and as a document to which nationalcentral banks (NCBs), the European CentralBank (ECB) and TARGET users can contribute.It is intended to serve as a dynamic tool,

reflecting such market tendencies andrecommendations of best practice as mayemerge either from the national TARGET UserGroups2 or from meetings organised forTARGET users at the euro area level by theEuropean System of Central Banks (ESCB). Aworking group composed of representatives ofbanks, designated by the banking associations,and of the NCBs/ECB has collected commentson the document and undertaken its revision.

The contents of this document confer nolegal rights on participants/operations orany other person or entity.

All times given in this document refer toCentral European Time (C.E.T.).

2 TARGET

2.1 Definition

TARGET, the acronym for “Trans-European Automated Real-time Grosssettlement Express Transfer”, is theEurosystem interbank funds transfer system,which is designed to support theEurosystem’s objectives of defining andimplementing the monetary policy of the euroarea and promoting the smooth operation ofpayment systems, thus contributing to theintegration and stability of the euro areamoney market. The system has been designedin such a way that it is able to process cross-border payments denominated in euro assmoothly as if they were domestic payments.

TARGET processes only credit transfersdenominated in euro. The aim is to allowpayments – especially large-value paymentssuch as those relating to foreign exchangeand money market transactions – to be madethroughout the euro area at low cost withhigh security and very short processing times.

As it is a real-time gross settlement (RTGS)system, payments are handled individually.

Unconditional payment orders areautomatically processed one at a time on acontinuous basis. Therefore, TARGETprovides for the immediate and finalsettlement of all payments, provided thatthere are sufficient funds or overdraftfacilities available on the sending institution’saccount with its central bank. There is no setminimum amount for a payment madethrough TARGET.3

2.2 Legal framework

The legal framework of TARGET is based on:(i) a Guideline of the European Central Bank

1 Where possible, the differences between the countries aredescribed so that users will know what to expect when dealingwith senders or beneficiaries in each country. Furthermore, theelectronic version of this TARGET Information Guide on theECB’s website provides links to NCBs’ websites.

2 Organised by the NCB in each euro area country to exchangeinformation and views on issues relating to TARGET.

3 In exceptional circumstances, a lower limit may be implementedtemporarily to limit the number of payments handled by thesystem, as mentioned in the document entitled “Minimumcommon performance features of RTGS systems withinTARGET”.


on a Trans-European Automated Real-timeGross settlement Express Transfer systemaddressed to NCBs of Member States whichhave adopted the euro (“the TARGETGuideline”); (ii) the Agreement on a Trans-European Automated Real-time Grosssettlement Express Transfer system,concluded between the ECB and the NCBs,which provides a mechanism whereby theNCBs of Member States which have notadopted the euro can connect to TARGETand adhere to the rules and procedures ofthe system (“the TARGET Agreement”); and(iii) each of the sets of rules and procedureslaid down in national regulations and/orcontractual provisions applying to each of thenational RTGS systems which are componentparts of TARGET (“the national RTGS rules”).For participants in a national RTGS systemparticipating in or connected to TARGET,the applicable rules continue to be thenational RTGS rules for that system, as theserules have been amended to reflect theTARGET Guideline and the TARGETAgreement.

2.3 Principles

When the TARGET system was first devised,several guiding principles were identified. Asthey have important practical consequences,they are listed below.

a) The market principle

In line with the main objective of the TARGETsystem (i.e. to facilitate the implementation ofthe single monetary policy in Stage Three ofEMU), the use of TARGET is only mandatoryfor payments directly relating to monetarypolicy operations (in which the ESCB is involvedeither on the receiving or on the sending side).The use of TARGET is not mandatory for eitherinterbank payments or commercial payments.However, in order to contain the systemic riskinherent in large-value net settlement systems,all such systems operating in euro are requiredto settle through TARGET.

b) Irrevocability

The national rules of each RTGS system inTARGET stipulate that payment orders areirrevocable at the latest4 from the momentwhen the RTGS account of the sendingparticipant is debited by the sending NCB/ECB for the amount of the payment order.5

c) Finality

TARGET provides a firm foundation for themanagement of payment system risks. It givesparticipants the possibility of settlingpayments in central bank money withimmediate finality, thus eliminating thesettlement risk between participants which isinherent in other payment mechanisms.

TARGET payments become final for receivingparticipants once they have been credited totheir account held at the receiving NCB/ECB.This means that participants are able to passon customer payments they receive to thefinal beneficiary immediately and withoutcredit risk.

2.4 Access criteria

Access criteria continue to vary according tothe approach in the country concerned (forlegal, technical and supervisory reasons),subject to compliance with the generalframework adopted by EU central banks,which has been further specified in the“TARGET Guideline”.

The main access criteria are as follows:

– Only supervised credit institutions asdefined in Article 1(1) of Directive 2000/12/EC of the European Parliament and ofthe Council of 20 March 2000 relating tothe taking up and pursuit of the business

4 “At the latest” is used here to reflect the fact that national RTGSsystem rules may determine that irrevocability occurs at anearlier point in time.

5 Otherwise, they become irrevocable at the moment at which theblocking of funds is performed by those national RTGS systemswhich apply this procedure.


of credit institutions, and which areestablished in the European Economic Area(EEA), can be admitted as participants in anational RTGS system. As an exception,the following entities may also be admittedas participants in a national RTGS systemsubject to the approval of the relevantNCB;

– Treasury departments of central orregional governments of Member Statesactive in money markets;

– Public sector bodies6 of Member Statesauthorised to hold accounts for customers;

– Investment firms7 established in the EEAand authorised and supervised by arecognised competent authority (with theexclusion of the institutions defined underArticle 2.2 of the above-mentionedDirective), provided the investment firmin question is entitled to carry out theactivities referred to under items 1(b), 2or 4 of Section A of the Annex to theCouncil Directive 93/22/EEC of 10 May1993 on investment services in thesecurities field;

– Organisations providing clearing orsettlement services and subject tooversight by a competent authority maybe eligible.

The other access criteria are as follows:

– There can be no discrimination with regardto credit institutions registered in thehome country and those licensed in otherEU countries as long as the latter meet therelevant legal, technical and otherprovisions of the host country;

– Depending on the structure and legalorganisation of each RTGS system, a creditinstitution may need to comply withadditional criteria, such as adequatefinancial strength, a minimum number oftransactions or the payment of an entryfee. However, such access criteria must bemade public.

– Participants in national RTGS systems areentitled to send payments via TARGET.They are obliged to accept paymentsprocessed through TARGET. TARGETfacilitates the return of payments inthe event that the receiving RTGS systemparticipant cannot apply funds (seeSection 3.6).

2.5 Structure of TARGET

TARGET is a decentralised payment system,consisting of national RTGS systems and theECB payment mechanism (EPM), which areconnected to each other by the Interlinkingsystem.

The TARGET system makes use of theinfrastructures in place in the EU MemberStates. RTGS system participants’ settlementaccounts are held at national central banks(NCBs). Individual payment messages areexchanged bilaterally and directly betweenthe two central banks concerned, usingreciprocal accounts for debiting and crediting.Only a few overall centralised functions areundertaken by the ECB (e.g. TARGET co-ordination and end-of-day procedures).

National RTGS systems have retained theirspecific features to the extent that they arecompatible with both the singleness of theEurosystem’s monetary policy and the levelplaying-field for credit institutions. In addition,they must comply with the “MinimumCommon Performance Features of RTGSSystems within TARGET”, the “InterlinkingSpecifications” and the “TARGET SecurityRequirements”. To enable the different RTGSsystems to process and settle cross-bordereuro payments, a number of common featureshave been agreed upon and implemented inthe TARGET Interlinking.

6 As defined in Article 3 of Council Regulation 3603/93 of13 December 1993.

7 As defined in Article 1.2 of Council Directive 93/22/EEC of10 May 1993.


Over and above these technical features,harmonisation is concentrated in four keyareas:

– the provision of intraday liquidity for euroarea RTGS system participants;

– operating times;

– TARGET cross-border holidays; and

– pricing policies for TARGET payments.

The RTGS system in each country isrepresented by the NCB concerned.

2.5.1 National RTGS / TARGETInterlinking

The TARGET system is composed of:

– One national RTGS system in each of the EUcountries that have adopted the euro. RTGSsystems in those EU Member States whichwere already members of EU at the start ofStage Three, but which have not yet adoptedthe single currency are allowed to beconnected to TARGET, provided that they areable to process the euro currency alongsidethe national currency.

– The ECB payment mechanism (EPM).

– The Interlinking system, which interconnectsthe RTGS systems and the ECB paymentmechanism. It consists of an IT system whichprovides inter-NCB accounts for recordingmutual claims and liabilities between NCBsstemming from payment transfers, and atelecommunications network for the real-timetransmission of Interlinking data.

Each national RTGS system and the EPM iscomposed of:

– An IT system which provides final andirrevocable debiting and crediting functionsalong with some optional features such asqueue management, gridlock resolution,provision of debit or credit advice;

– Telecommunications facilities for thereal-time transmission of payment ordersand additional information betweenRTGS system participants and the NCBs/ECB.

Only NCBs and the ECB – with regard to theEPM – may be members of the TARGETInterlinking.

RTGS RTGS

12

3

TARGET

TARGET Cross-border RTGS processing... Essential features

S.W.I.F.T.FIN

National RTGS National RTGSInterlinking system

Cre

dit i

nstit

utio

ns

Credit institutions

Que

uing

+ c

ash

man

agem

ent f

acili

ties

Inte

rlin

king

Interlinking


for this system. There are other participantsin a variety of legal and technical situationswhere credit institutions which are not directparticipants but which may hold an accountat the NCB (albeit not an RTGS settlementaccount), can nevertheless access and receivefunds from TARGET. They may choose toparticipate in their local RTGS system and/orto participate as a remote access participantin another RTGS system. All TARGET RTGSsystem participants must be identified by aunique published Bank Identifier Code (BIC).

2.5.3 SWIFT

The logical and physical technical platform forthe TARGET Interlinking is based on the SWIFTFIN/SWIFTnet FIN network. SWIFT has beenselected as the preliminary network providerfor the TARGET Interlinking. The national RTGSsystem user interface may also be SWIFT-basedor may use another network provider.

Participant banks send payment instructionsusing domestically agreed message formatsto their RTGS system. NCBs exchangemessages through the Interlinking using theCommon Interlinking Message formats.

Payment messages are mapped to an MT1009/103 – standard or straight-through processing(STP) – or an MT202 Interlinking specificationmessage. The messages are enveloped in anMT198 proprietary message format by thesending NCB for sending via the Interlinking10.They are then unwrapped by the receivingNCB and forwarded to the final beneficiary.

Bank Identifier Codes

TARGET promotes STP. To ensure thatvalidation takes place early on in the paymentprocess, it was necessary to define a commonreference which could be used by all TARGET

Country TARGET components

Austria ARTIS

Belgium ELLIPS

Denmark KRONOS

ECB EPM

Finland BoF-RTGS

France TBF

Germany RTGSplus

Great Britain CHAPS Euro

Greece HERMES

Ireland IRIS

Italy BI-REL

Luxembourg LIPS-Gross

Netherlands TOP

Portugal SPGT

Spain SLBE

Sweden Euro-RIX

RTGS systems in or connected to TARGET

The following countries and the ECB haveimplemented the corresponding RTGSsystems for processing and settling domesticand cross-border euro payments:

8 Provided that they meet the NCB criteria.9 As of 15 November 2003, MT100 will no longer be supported

by SWIFT. As a consequence, TARGET will also no longertransport MT100.

10 A time stamp and an Interlinking Internal Reference, which arecompulsory in TARGET, have been added.

2.5.2 Credit institutions

National provisions continue to regulate therelations and operations between NCBs andtheir RTGS system participants.

Credit institutions access TARGET via RTGSsystems participating in or connected toTARGET. The interface with creditinstitutions is determined by the NCBconcerned. In order to send and receivecross-border euro payments, creditinstitutions must either be:

• direct participants in an RTGS system orbe represented by a direct participant8 (inthe latter case the institution is sometimesreferred to as an “indirect participant”),or;

• they must be customers of a participant orof an NCB connected to TARGET.

Credit institutions which are directparticipants in an RTGS system maintainsettlement accounts at the NCB responsible


RTGS systems and also by banks usingTARGET.

For this reason it was decided to use BICaddresses published by SWIFT as the meansof identifying the sender bank, receiving bankand, where appropriate, the intermediarybank. Although the BIC is used to identifybanks, it does not imply that the banks haveto use SWIFT as their message carrier.

BICs are listed in the widely available “SWIFTBIC Directory” of published codes, which isavailable both in electronic and in paper form.The latest version is taken as reference. Inthe period between two SWIFT updates, theNCBs/ECB simultaneously update the list onthe basis of periodical SWIFT broadcasts.Unpublished BICs were created forconfidential or bilateral usage and are notincluded in the SWIFT BIC Directory. Theyare therefore not valid for use in TARGET.

TARGET directory

In co-operation with SWIFT, the ECB haspublished the TARGET Directory,11 whichlists those credit institutions which areaddressable through TARGET. They are listedalphabetically by name of institution and arealso sorted by BIC address. The line belowthis information indicates, in square brackets,in which TARGET RTGS systems eachinstitution participates,12 whether it is a directparticipant in the system concerned and, ifso, in which system it prefers to receive fundswhen no other instructions have been given.

For example:

BANK A XXXXXXXXXXX

– Town– [ABC, DE+, XYZ]

where:• “BANK A” is the name of the credit

institution as reported to SWIFT for usein the BIC Directory;

• “XXXXXXXXXXX” is the eight oreleven-character published BIC addresswhich is recognised by the TARGETRTGS system in which the creditinstitution is a participant;

• “Town” is the location of the creditinstitution;

• “ABC” is the three-character identifierof a TARGET RTGS system in which thecredit institution participates as a directparticipant;

• “DE+” is the three-character identifier ofanother TARGET RTGS system in whichthe credit institution also participates, butnot as a direct participant;

• “XYZ” is an indication13 to sending banksthat where no other settlementinstructions exist, the named creditinstitution would prefer to receive fundsat this TARGET RTGS system.

Further details are given in the preface to theTARGET Directory.

A credit institution addressable throughTARGET may be listed in the TARGETDirectory. Listing is, however, optional (at therequest of the credit institution concerned).Therefore, some credit institutions may beaddressable through TARGET but not listed inthe TARGET Directory.

A TARGET Addressable Institution is either adirect or an indirect participant (it cannot be acustomer) in a TARGET RTGS system whichcan be accessed through the routing table ofthe receiving RTGS system without additionalinformation being supplied by the orderinginstitution. For example, if Bank A is listed inthe TARGET Directory as an indirect participantin an RTGS system, it is not necessary to knowby whom Bank A is represented or to insertthis information in the payment instruction.

11 This can be obtained from SWIFT, Customer Order Services,Avenue Adèle 1, B 1310 La Hulpe, Belgium.

12 Each TARGET RTGS system has been designated a three-character identifier: BEL (ELLIPS); DKC (DEBES); RTG (RTGS+);SLB (SLBE); TBF(TBF); CBL (IRIS); BRL (BIREL); LGS (LIPSGROSS); TOP (TOP); ART (ARTIS); SPG (SPGT), BOF (BOF); SEC(RIX); CHP (CHAPS EURO).

13 This information is not mandatory.


Those TARGET Addressable Institutionswhich wish to make public the fact that theycan be accessed via TARGET may be listed inthe TARGET Directory, subject to theagreement of the relevant NCB for routingpurposes. The form which should be used toapply to the NCB for its consent is includedin the TARGET Directory and may also beobtained from SWIFT. As credit institutionsmay join or leave RTGS systems between

updates, NCBs are notified of these eventsand pass this information on to theirparticipants.

If a beneficiary bank is not listed in theTARGET Directory, contact should be madewith the beneficiary bank in order to identifythe BIC of the institution which representsit. The BIC of the receiving NCB should notbe used in this case.

3 TARGET Payments

3.1 Payments in TARGET

TARGET processes customer and interbankcross-border payments in euro. Data inTARGET payments are transmitted withoutany alteration of the content from end toend, although the order in which dataappear may be altered slightly, becausepayment messages are mapped from domesticformats to TARGET Interlinking formatsand vice versa. Information on the mappingof domestic payment messages to andfrom Interlinking formats is included inAnnex 10.13.

If, for any reason, a beneficiary is unable toapply a payment order that it has received viaTARGET, there is a mechanism whichprovides information so that the payment canbe returned by the receiving RTGS systemparticipant to the TARGET participant whichintroduced it into TARGET. This mechanismis described in Section 3.6.

As described in the formatting rules (seeAnnexes 10.5 and 10.6), TARGET has beendesigned to support STP to the greatestpossible extent. Thus, TARGET participantsmust address cross-border payments directlyto the receiving bank in its RTGS system (thereceiving RTGS system). If this participant islisted in the TARGET Directory, no additionalrouting information is necessary, regardlessof whether the beneficiary bank is a directparticipant. However, it is particularlyimportant to remember that the NCBmanaging the receiving RTGS system does

not act as intermediary bank or bank of thebeneficiary, and that payments to be made toTARGET participants should include thepublished BIC of the credit institutionconcerned in the first credit field of a SWIFTpayment message (and not the BIC of theNCB through the RTGS system of which theparticipant accesses TARGET). If the NCBBIC is placed in the first credit field, this mayresult in the payment being rejected ordelayed in reaching its final beneficiary.

However, a credit institution which wishesto make a payment to an NCB or an NCB’scustomer should always use the InternationalStandards Organisation (ISO) BIC of thatNCB in the first credit field (see Annex 10.3).

Therefore, except in cases where specialinstructions have been given by the orderingcustomer/ordering bank, the NCB of thereceiving RTGS system should not bementioned in the TARGET payment, eitheras an intermediary or as the bank of thebeneficiary (i.e. in SWIFT-based RTGSsystems, fields 56 and 57 should not containthe published BIC of a central bank).

3.2 Customer payments

Customer payments are defined as paymentsin the SWIFT MT103 format, standard orSTP, or equivalent national message formats.TARGET will also support the SWIFT MT100message format, or its national equivalent,until its deletion from the SWIFT FIN service


on 15 November 2003.14 A typical example isgiven above:

Customer payments can be transmitted viaTARGET from 07:00 until 17:00 C.E.T. The17:00 cut-off time applies to both domesticand cross-border customer payments (seeSection 4.5.1).

The participants send their payment ordersto the euro RTGS system in which theyparticipate using the SWIFT (MT100 or)MT103 formats (standard or STP), or theequivalent national message format forTARGET payments, which is converted bythe RTGS system into the commonInterlinking message format.

The Interlinking uses SWIFT proprietaryMT198 messages as its message framework.

MT198 messages are “envelope” messageswhich contain free space that can beformatted by the users (the NCBs/ECB inTARGET) according to rules agreedbilaterally. SWIFT does not validate thecontent of the envelope, except to verify that

14 The MT103 message format is a refinement of the MT100,redefining and restricting how some fields are used in order toaddress euro payments market practices and to maximisestraight-through processing by making automation easier on thereceiver’s side. The immediate benefit which is expected is lowerprocessing costs.

the characters used belong to the SWIFTcharacter set, that the length of each linedoes not exceed 78 characters and that thetotal number of characters in each messagedoes not exceed 10,000.

Such a framework provides high flexibility,facilitating the use of current data formats,confidentiality and changes in data formats.

The general format of the Interlinkingmessage type MT198 sub 100 and 103(standard or STP) – Customer Transfers (seeAnnex 10.5) is used to transmit a customerpayment through the Interlinking system. Thepresentation of the data may differ from thatof the domestic message format, whichfollows the requirements of the nationalnetwork. However, all data will becommunicated in their entirety from thesending participant to the receiving one.

Cross border euro customer payment trough TARGET

T A R G E T IN T E R L IN K IN G

O R D E R IN G P A R T Y

S E N D IN G B A N K

P A R T IC IP A N T IN

D O M E S T IC R T G S

S end ing R T G S R ec eiv ing R T G S

R E C E IV IN G

B A N K

P A R T IC IPA N T IN

D O M E S T IC R T G S

B E N E F IC IA R Y

B E N E FIC IA R Y


3.3 Interbank payments

Interbank payments are defined as paymentmessages in the SWIFT MT202 format orequivalent national message formats forTARGET payments. This type of message issent by or on behalf of the orderinginstitution either directly or through anycorrespondent(s) to the financial institutionof the beneficiary institution.

Interbank payments are payments, such asthe payment leg of money market, foreignexchange and derivatives transactions, whichtake place between credit institutions orbetween NCBs/ECB and credit institutions.Interbank payments can be transmitted viaTARGET from 07:00 until 18:00 C.E.T.

The MT198 sub 202 General Financial InstitutionTransfer is used to transmit an interbankpayment message through the Interlinking. Itsgeneral format is described in Annex 10.6. Thesending and receiving RTGS systems processinterbank payments in the same manner as thatoutlined for customer payments.

3.4 Validation of customer andinterbank payments

The sending RTGS system checks the syntax ofthe data according to the appropriate standard,the value date of the payment order (the onlyvalue date for the TARGET system is “today”)and the availability of the receiving NCB/ECB. Ifsyntax errors or other grounds for rejectionare detected, the sending NCB/ECB handlesthe data according to domestic rules and returnsthe error information in the agreed domesticformat. The receiving RTGS system checks allthose parts which are necessary to successfullycredit the account of the beneficiary institutionin line with its own national provisions. If thecrediting of the beneficiary institution in theRTGS system is successfully completed, thereceiving NCB/ECB sends a positiveacknowledgement to the sending NCB/ECB. Inthe event that an error occurs during theprocessing and it cannot be completed, anegative acknowledgement is sent to the sending

NCB/ECB stating the reason. These reasonscan be either the absence of any information bywhich to identify the receiving institution or aninvalid format. The sending NCB/ECB thenhandles the data according to domestic rules.

3.5 Remote access banks

TARGET provides appropriate features forcommunicating with remote access EU banksand non-EU banks. Each NCB is able tocollect data on the identity of the receivingNCB if it is different from the country codeof the receiving RTGS system participant. Thisenables the NCB to route payments toremote access participants. Owing to thespecific history of each RTGS system, themechanisms are different; details of these canbe found in Annex 10.4.

3.6 Return payments

TARGET follows SWIFT standards for theTransaction Reference Number (TRN).According to these rules, Field 20 – TRN – isthe unambiguous reference number for thesender. Therefore, each time a paymentmessage moves from one SWIFT sender toanother (e.g. from an ordering bank to acorrespondent bank) the sender must ensurethat when this message is next forwardedthrough SWIFT the TRN is unique. In somecases, the sender may thus replace theoriginal content of Field 20 with a newreference number.

To assist banks with automated reconciliationand with investigating payment queries,TARGET ensures that the TRN contained inthe payment message remitted by the RTGSsystem participant to the TARGET RTGSsystem is made available to the receivingRTGS system participant. If, for any reason, abeneficiary bank is unable to apply a paymentthat it has received via TARGET, then thispayment should be returned to the orderinginstitution via the original route. TARGETfacilitates this process and recommends that“return payments” are handled as described


below, although NCBs cannot be heldresponsible for ensuring that this procedureis followed by individual institutions. Fulldetails are contained in the originatingInterlinking payment message to allow thebeneficiary institution to identify the returnroute without difficulty.

3.6.1 The sending side

The sequence of information flow is as follows:

– The original sender of the payment maynot be the RTGS system participant. Inthis case, the RTGS system participant mayreplace the original TRN of Field 20 andinsert the sending institution BIC in Field52A of the payment order in accordancewith normal SWIFT standards.

– The payment order is forwarded by thesending RTGS system participant to theRTGS system of the sending NCB, at whichpoint the TRN previously shown in Field 20may be replaced. However, the TRN in Field20 as supplied by the RTGS systemparticipant is not lost, as this TRN is alwaysincluded in the “return key” of the TARGETInterlinking message. The return key (seeSection 3.6.2) is a code line which containsall the information that a receiving TARGET

RTGS system participant needs to be able toreturn the funds to the sending TARGETRTGS system participant. In the Interlinkingmessage, this information is contained in theaccount number line of Field 52A.

3.6.2 The return key

Each Interlinking payment includes, in additionto the BIC of the ordering institution, a returnkey, which is transmitted in the accountnumber line of Field 52A of the Interlinkingmessage. The return key comprises:

– The prefix “//TA”

– The country code of the sending NCB;

– The BIC (11 characters, i.e. including thebranch code or “XXX”) of the bank thathas sent the payment message to thesending NCB. If necessary, the sendingNCB will fill in the field with the BIC ofthe sending credit institution;

– The TRN provided by the sending creditinstitution.

The return key is forwarded to the receivingcredit institution according to local rules andstandards.

TARGET and Return Payments

BnkA BnkB NCB1 DE

:20:

:21:

…

:52A:

:57A:

:58A:

RefBankA

RelRef

BNKCXXYY

BNKDXXYY

RefBankB

RelRef

BNKAXXYY

BNKCXXYY

BNKDXXYY

RefNCB1

RelRef

//TADEBNKBXXYYXXXRefBankB

BNKAXXYY

BNKCXXYY

BNKDXXYY

On the sending side, the following messages are sent:

Sender

Receiver BnkB NCB1 DE NCB2 FR


3.6.3 The returning side

– The receiving NCB forwards the paymentmessage to the receiving RTGS systemparticipant according to domesticstandards. Therefore, if the receivingNCB is using a SWIFT-based systemdomestically, the TRN in Field 20, asreceived from the sending NCB, may bechanged. However, the TRN of the sendingRTGS system participant is preserved inthe return key and this information will beforwarded to the receiving RTGS systemparticipant in accordance with domesticstandards.

– This means that the information is notnecessarily forwarded either in the formator in the field used for the Interlinkingmessage. However, the full content is madeavailable to the receiving RTGS systemparticipant.

– If the receiving RTGS system participantneeds to forward this information to athird party, the TRN in Field 20 may bealtered. In addition, TARGET does nothave any control over whether or not thereturn key information is passed on.

3.6.4 Recommendations

– When a credit institution returns funds itis advisable to send a new MT202 TARGETpayment in accordance with the normalformatting rules for TARGET payments.

– The Related Reference Number (RRN) inField 21 should contain the reference“NEW”.

– Field 72 of a returned payment should becompleted according to the SWIFTguidelines on returned/rejected payments(see Annex 10.7).

TARGET and Return Payments

BnkC

:20:

:21:

…

:52A:

:57A:

:58A:

On the Receiving side, the following messages are sent:

NCB2 FR

RefNCB2

RelRef

//TADEBNKBXXYYXXXRefBankB

BNKAXXYY

BNKDXXYY

BnkC

Return payment

RefBankC

RefBankB

BNKBXXYY

BNKAXXYY

/RETN/58A

/BE03/

/MREF/RefBankB

:20:

:21:

…

:52A:

:57A:

:58A:

:72:

Sender

Receiver NCB2 FR

Sender

ReceiverBnkC ???


4 The TARGET day

Timetable of a typical TARGEToperating day

07:00 Start of TARGET operations

17:00 Cut-off time for Customer payments

18:00 Close of TARGET

18:10 *) End-of-day control procedures(Only the ECB and NCBs are directlyinvolved in these procedures)

*) Indicative time.

4.1 The TARGET information system(TIS)

During the day, TARGET participants canaccess information on the status of theTARGET system simultaneously and in astandardised way through a commoninformation tool, the TARGET Informationsystem (TIS). It provides up-to-dateinformation on the national TARGETcomponents, whereby users can see whetherTARGET is fully operational and, if it is not,which component has failed or is experiencinga slowdown. The TIS is an additionalinformation resource to the communicationchannels that already exist at the domesticlevel.

The TIS consists of an information page whichis published by the providers Reuters (pageECB46), Telerate/Bridge (pages 47556/47557)and Bloomberg (page ECB17). These pagescan be accessed by TARGET participants bysubscribing to the relevant services andconfiguring their information pagesaccordingly.

The information is input centrally by the ECB.The information is transmitted by all theproviders at the same point in time. Thus it isaccessible to all TARGET participants havingaccess to the above information services.

The following status information is providedfor each RTGS system and for the ECBpayment mechanism (EPM) at the ECB:

Closed: The TARGET component has closed(typically at 18:00);

Operational: The TARGET componentin the relevant country is operating normally(normally between 07:00 and 18:00);

Failure – Under investigation, nextupdate at hh:mm at the latest or

Slowdown – Under investigation, nextupdate at hh:mm at the latest:

The relevant national TARGET component istemporarily not or not fully available toprocess payments. An update on the situationwill be provided as soon as more informationis available, at the latest by hh:mm. Theintervals between updates should not exceed30 minutes. Estimates of downtime will onlybe given if the nature of the problem and themeans to solve it is clear.

Today’s operations suspended: Therelevant RTGS system or the EPM hasstopped processing TARGET payments and isnot expected to resume processing on thesame day.

In addition to the status of the individualsystems, at the bottom of the screen thereis free space to accommodate free textinformation, if further details are deemednecessary.

4.2 Opening balances in TARGET

The opening balances of credit institutionsthat are participants in an RTGS systemreflects the closing balance on the previousday. Each central bank checks this balance inline with its local rules. Intraday liquidity isprovided by collateralised overdrafts orintraday repos in accordance with localpractices.


4.3 Messages exchanged betweenNCBs/ECB

In the Interlinking, messages are classifiedeither as requests, as notifications or as freeformat messages.

For requests, a structure has been designedwhich defines the action or actions triggeredby the request. For notifications that follow arequest, a structure has been designed whichinforms the sender whether or not it waspossible to comply with the request and whataction was taken. A request is completedwhen the sender has received the appropriatematching notification. By definition,notifications never require an answer.

The normal settlement of cross-borderpayments involves the exchange of PaymentSettlement Message Requests (PSMR) fromthe sending NCB and Payment SettlementMessage Notifications (PSMN) from thereceiving NCB. A PSMN is normally positive(indicating that the receiving beneficiary’ssettlement account in the receiving NCBsbooks has been successfully credited). It maybe negative, in which case it is returned tothe sending NCB with an error code. Thedetails of the way in which error codes arehandled may differ from one NCB to another.

This cycle is usually completed within amatter of minutes. A payment cycle becomescomplete either when a positive PSMN isreceived from the receiving NCB by thesending NCB or if a negative PSMN isreceived and the inter-NCB account isdebited and the sending participant’s accountre-credited.

4.4 Settlement of ancillary systems

Although ancillary systems are not part ofthe TARGET system, the interdependencieswithin payment systems and the possibleimpact on liquidity necessitate carefulmonitoring of the orderly and timely

settlement of these systems at the level ofeach NCB. NCBs monitor the settlement ofdomestic netting systems in euro in order toensure the smoothness of the business day.Settlement times are listed in Annex 10.12.

4.5 End-of-day procedures

End-of-day procedures in TARGET includethe cut-off times for customer and interbankpayments (17:00 and 18:00 respectively).

4.5.1 Cut-off for customer payments

Before 17:00, customer payments areprocessed provided that funds or overdraftsare available; otherwise they are queued orrejected depending on the features of theRTGS system concerned. RTGS systems stopaccepting customer payments from creditinstitutions participating in their system at17:00 C.E.T. This cut-off time is valid forboth domestic and cross-border customerpayments. Customer payments are defined aspayment messages either in the MT100/103format or in the equivalent national messageformat (which would use the MT198 sub 100/103 in order to be transmitted cross-border).

Depending on local circumstances, domesticcustomer payments which were already in aqueue at 17:00 may still be debited if andwhen funds or overdraft facilities becomeavailable. After 17:00 only those customerpayments which have been accepted before17:00 are debited. Cross-border paymentsshould be presented to the computer-basedterminal (CBT) of the sending NCB before17:07:30 and, in any case, cross-bordercustomer payments in a queue are cancelledat the latest at 17:07:30.

Credit institutions receiving third partypayments after the cut-off time are obligedto accept them, but it is left to theirdiscretion whether or not to apply same-dayvalue to these transactions.


4.5.2 Cut-off for interbank payments

On normal operating days the “externalclosing of TARGET”, i.e. the closing time forall national RTGS systems participating in (orconnected to) TARGET is 18:00 C.E.T. Nofurther payments are accepted for processingafter the closing time.

Payments which are presented after 18:00are rejected. However, cross-borderinterbank payments which have beenaccepted can be sent until 18:07:30 at thelatest. All NCBs continue to credit receivingRTGS system participants with paymentsreceived through the Interlinking. Domesticinterbank payments which are in a queue at18:00 can still be processed, because fundsreceived through the Interlinking after theclosing time might release them. The finalattempt to process domestic payments in aqueue must take place immediately after theInterlinking component has been allowed toclose by the ECB:

In summary;

– before 18:00 payments are processedprovided that funds or overdrafts areavailable; otherwise they are queued orrejected depending on the features of theRTGS system concerned;

– at 18:00, central banks stop accepting newpayment orders from their participants;

– after 18:00, only payments accepted before18:00 are debited15. In principle, cross-border payments should be processed bythe CBT of the sending NCB before18:07:30 and, in any case, cross-borderpayments in a queue are cancelled at thistime, at the latest. Depending on localcircumstances, domestic interbankpayment orders which were already in aqueue at 18:00 may still be debited if andwhen funds or overdraft facilities becomeavailable.

As a rule, all payments debited at one NCBneed to be credited the same day at another

NCB. However, payments received throughthe Interlinking after the end-of-dayprocedures are handled according to the latepayment procedures.

Negative acknowledgement received after18:00 C.E.T.

If a negative acknowledgement is received(by the sending NCB) and the error codeshows that the responsibility for the errorlies with the sending credit institution, thenthe payment is definitely rejected. Thesending NCB re-credits the funds of the non-settled cross-border payment in the accountof the sending credit institution as soon aspossible.16

However, if the error code shows that theerror (the reason for rejection on thereceiving side) is the responsibility of (or iscaused by) the sending or receiving NCB (e.g.it appeared when the domestic messageformat was converted into the Interlinkingformat or the receiving NCB rejected it whenit should not have done so), then the sendingNCB may, in accordance with domestic rules,try to correct the error and re-send thepayment, provided that this can be donebefore the start of the end-of-day controlprocedures.

This means that the corrected message needsto be debited by the sending NCB before18:10. If this is not possible, then the paymentis rejected. The sending or receiving NCB, asappropriate, may then be liable for charges,depending on local documentation.

15 If an NCB is unable to provide queuing facilities, it should ensurethat if payments are rejected owing to a “stop sending” period,they can be re-entered later. In the event that delayed closing isrefused, the relevant NCB must ensure that no new paymentsare entered after the appropriate cut-off time. This could bechecked ex post by the other NCBs/ECB.

16 NCBs may decide to credit a “transit” account instead of thecustomer account if they expect to re-send the payment within afew minutes.


4.5.3 Finalisation of payment accountbalances for RTGS systemparticipants

To ensure that each business day is closed inan indisputable way, the ECB operates areconciliation procedure called the end-of-dayapplication. This must be run successfully for allparticipants before their systems may be closed.The primary function of the matching procedureis to confirm that all bilateral operationsconducted during the day concur.

Account balances of direct RTGS systemparticipants are final only after successfulcompletion of all end-of-day control proceduresmade by NCBs and the end-of-day applicationat the ECB (i.e. after it has been verified that nofurther funds are to be debited or credited inthe RTGS accounts). The end-of-day closing forthe Interlinking does not necessarily coincidewith the end-of-day procedure for the RTGSsystem (in particular if domestic payments heldin queues are cancelled only after thecompletion of the end-of-day procedures forthe Interlinking).

The standing facilities of each euro area NCBwill remain open to credit institutions toreceive deposits or to grant collateralisedovernight loans until 30 minutes after theTARGET closing time, except on the last dayof each minimum reserve period when it willremain open until one hour after TARGETcloses. This means that on normal TARGETdays, when TARGET stops accepting newpayments at 18:00, the standing facility willremain open until 18:30 (19:00 on the lastday of the reserve period). If the closing ofTARGET is delayed until 19:00, then thestanding facility will remain open until 19:30(20:00 on the last day of the reserve period).

4.5.4 Abnormal circumstances: delayedclosing

The delayed closing time procedure is for use inexceptional circumstances and in general onlyfor systemic risk reasons or when there is a riskof severe disruption to financial markets. A

delayed closing of TARGET does not have animpact on the cut-off time for customerpayments, which remains at 17:00.17

Credit institutions will be informed via thenormal communication channel of their NCBsin the event of a delay in the closing of TARGET.This information is published on Reuters (pageECB46), Moneyline-Telerate (pages 47556/47557) and Bloomberg (page ECB17).

An NCB may request a postponement of theclosing time for a maximum of one hour (i.e.up to 19:00) to allow new (critical) paymentsto be received and debited after the 18:00closing time. In order to do so, the NCBmust see that the delayed closing time requestis agreed by the ECB before 17:45. Therefore,although it is highly unlikely thatTARGET closing will ever be delayedowing to problems at a single creditinstitution, any credit institution requestingthat its circumstances be considered asgrounds for delayed closing must contact itslocal NCB well in advance of 17:45.

When a delayed closing time has been agreedall NCBs and the ECB must also postponetheir closing. In special circumstances the ECBmay extend the closing time to 20:00.

During a delayed closing time procedure allNCBs may accept new cross-borderinterbank payments to be sent to all otherNCBs and all NCBs must receive anyTARGET cross-border interbank paymentswhich are sent to them. Credit institutionsshould remain in close contact with theirNCB for information on the situation.

After the end of the delayed closing timeprocedure, the end-of-day controlprocedures start as soon as possible – usuallyaround 10 minutes after the new closing time.Standing facilities will remain available until30 minutes (or one hour on the last day ofthe minimum reserve period) after theextended closing time.

17 If, due to any extraordinary circumstance, the customer cut-offis delayed, credit institutions will be informed by their NCB.


5 Incident management

5.1 Business Logic of TARGETIncident Management

5.1.1 Redundancy as a way to achievebusiness continuity

From the outset, TARGET has beenrecognised as a system that is subject to highavailability. This is due to its very specificobjectives with regard to cross-borderinterbank euro payments. In order to meetthese requirements, TARGET has been builton the principle of “no single point of failure”.Within each RTGS environment, this conceptis applied consistently and comprehensively,and has materialised in a duplication of ITcomponents, commonly referred to as thesecondary site infrastructure.

In view of the technically complex nature ofsystems such as TARGET, the failingcomponent may well be determined, but itmay be impossible to identify or rectify theactual cause of a service interruption. In suchcases, in order not to wait for the problemto be solved, arrangements are made toswitch over to another “site” (or system orcomponent) with the aim of resuming normalprocessing as soon as possible.

With regard to the notion of a “secondarysite”, it is recognised that differentimplementations are in place across theTARGET infrastructure. Some NCBs haveadhered to a very strict interpretation,meaning that they have a secondary site inplace that can reasonably be expected not tobe impacted by the same incident (or a directconsequence thereof) that is causing theunavailability of (some components at) theprimary site. Other NCBs have (temporarily)limited themselves to the installation of fulldual processing and communicationsequipment that is physically distributed overseparate locations within the same (primary)site. In such cases, best efforts are made toreduce the risk of both locations beingaffected by the same incident.

External services used for TARGET functionsare examined according to the same “nosingle point of failure” logic. For theInterlinking Network services provided byS.W.I.F.T., fully redundant access points tothe service have been established. For theSWIFT FIN network itself, a fully redundantinfrastructure is provided.

The main objective behind this duplication ofcomponents is to retain a normal end-to-endpayments processing chain and thus to ensurethe principle of (normal) business continuity.As soon as the failing component is taken outof the chain and the backup component isactivated, normal processing continues,creating complete transparency towardscounterparts.

5.1.2 Business continuity as the preferredoption

The ultimate aim of business continuityfunctions is to minimise the serviceinterruption to a period of time which doesnot require the use of any contingencyprocedures during the period of systemunavailability and thus offers a service levelwhich has very limited implications for itsusers. Therefore TARGET prefers the use ofbusiness continuity functions as the mainmeans of overcoming infrastructure failures.In most cases, severe component failurestrigger an immediate switch-over to anothercomponent, generally without that beingrealised by the system users.

However, although the main objective is andalways will be to resume or continue normalautomated operations, relying completely onthe above-mentioned business continuityfunctions, in particular for processing criticalpayments, would imply extremely high costsfor developing, maintaining and operating thesystem. In addition, duplication of ITcomponents may not always be a solution,e.g. in the case of problems within theapplication software or the related databases.


Therefore, NCBs limit those high marginalcosts by putting in place efficient contingencyprocedures. Depending on the scale of thesystem, the number of users connected andthe transactions to be processed, this can bea more or less demanding solution. However,it is unavoidable in the current TARGETenvironment in which a variety of systemsare interconnected. The unavailability of oneRTGS system within TARGET does notprevent the other systems from continuingprocessing, but – depending on thecircumstances – this may generate liquidityimbalances (between RTGS systems) withinthe euro area, in which case contingencyprocessing is used as a means to minimisethese potential imbalances. In this respect,the worldwide nature of CLS’s activitiesstrongly contributes to the need for thesecontingency solutions.

5.1.3 The need for core paymentsettlement functions in TARGETin a contingency

During the period required to resume normaloperations, critical payments may have to beprocessed. Therefore, the provision of a(limited) payment processing capability duringthe unavailability phase is considered to bevital for the continuation of key settlementtransactions with systemic implications.

This is the case, in particular, towards theend of the business day when major systems(including the EBA’s Euro 1) settle and creditinstitutions square their positions accordingto their needs in terms of acceptable orenvisaged overnight positions and minimumreserve requirements. CLSB adds a very-critical intra-day settlement phase during themorning in which TARGET unavailability mayseverely disturb the settlement transactionsacross currencies.

Consequently, each TARGET RTGS systemhas arrangements in place, which allow theprocessing of a limited number of criticalcross-border payment instructions. Inprinciple, they are based on the availability of

account information in order to continue tomake payments on the basis of available fundsor overdraft facilities.

At the domestic level, these contingencymeasures are not harmonised. Nevertheless,following the general concept in TARGET,namely “to avoid as much as possibleexporting problems from the failing RTGSsystem”, cross border contingencyprocedures are fully compatible throughoutTARGET. However, due to the constraintsof processing payments under contingencyconditions, systems which are still inoperation have to limit their transactions tothe failing NCB to a reasonable minimum ofprimarily core settlement transactions andliquidity shifts of utmost importance.

5.2 The scope of contingency processing

Due to the specific treatment of payments incontingencies, the procedures in place areonly able to process a limited number ofpayments. Consequently, the paymentinstructions that will be processed incontingency situations have to be selectedaccording to the domestic arrangements,primarily on the basis of their systemicimportance.18 In particular, settlementsystems-related payments (e.g. the EBA’sEuro 1 and CLS), monetary policy operations,liquidity transfers to non-euro area EUcountries and other large-value liquiditytransfers19 are considered systemicallyimportant, as they are essential for thesmooth functioning of a uniform euro moneymarket. Although there are volumerestrictions, the NCBs/ECB have contingencyprocedures in place to enable them, toprocess at least the above-mentioned typesof payments in a timely manner, apart from inexceptional circumstances. Once thesepayments are processed, and if spare capacity

18 More information on the definition of systemic importance canbe found in the publication of the Bank for InternationalSettlements: Core Principles for Systemically Important PaymentSystems, ISBN 92-9131-610-5.

19 Particularly when they are meant to create sufficient paymentcapacity on Settlement Members/Nostro Agents RTGS accountsin order to process CLS related payments.


is still available, the NCBs/ECB may decide,upon agreement with the credit institutions,to process other types of payments.

As previously mentioned, TARGET failureswill trigger the activation of contingencyprocedures mainly towards the end of thebusiness day (when major systems settleand credit institutions manage their positionsto comply with the minimum reserverequirements). CLS introduces anothercritical intra-day settlement phase in whichthe unavailability of TARGET, or of any otherRTGS systems involved in CLS’s settlement,has implications for other currency zones.Therefore, in a contingency, priority is givento CLS-related payments.

5.3 Preconditions for processingpayments in contingencies

5.3.1 The recommendations for CLSpayments in euro(the normal framework)

It must be recognised that contingencyprocedures can only meet the objectives theyare designed for if they are embedded in aframework of sound business practices.Therefore, in order to ensure that theseprocedures are operationally effective,especially in terms of the time neededfor decision-making and activation, theEurosystem, in co-operation withrepresentatives of the credit institutions,formulated a set of recommendations for CLSpayments in euro (Section 8.2) as well as anexplanatory memorandum on theserecommendations (Annex 10.11). They do notsupersede any rules agreed in domesticsystems, nor any legally binding bilateralagreements, and their observance will be leftto the interested market participants (i.e. CLSsettlement members and/or nostro agents).Nevertheless, they encompass an importantframework for CLS settlement under normaland abnormal circumstances.

One of the aims of the recommendations isto stipulate the expected time frame for

payment processing under normalcircumstances and, consequently, to definereasonable margins if a contingency is invokedby any of the parties involved. If these timeframes are observed, sufficient time will beavailable for contingency processing, which inturn would have a positive effect on anysettlement delay.

In addition, the recommendations coverissues related to the roles of each party incontingencies, in order to facilitate theprocess and to avoid undesirable impacts (e.g.delays in the pay-in). It is neverthelessimportant to stress that, whatever theimplications of the implementation of theserecommendations at the local level may be,the main approach towards processing time-critical payments should be supported by allparties involved, i.e. settlement members,nostro agents, CLS Bank, the NCBs and theECB.

5.3.2 TARGET contingency testing andend-to-end live trials

Taking into account the new level of timecriticality raised by the CLS and in order tocope with the additional requirementsresulting from this situation, a need is seento ensure that contingency processing by allparties involved meets these requirements.Verification of the whole processing chain,including the interfaces between the systems,operational aspects as well as timing andvolume issues are of utmost importance. Inorder to have a reliable outcome, thisverification should take place in the liveenvironment, once the testing phase (internaland interface testing) has successfully takenplace.

5.3.3 A streamlined decision-makingprocess

In order to minimise the impact on themarket, TARGET needs clear decision-makingstructures and “what if” scenarios enablingits users to react in a well understood and


consistent manner to TARGET and RTGSsystem failures. Against this background,TARGET users and service providers willmaintain and improve quick and efficientcommunication channels for decision-makingand the announcement of contingencyprocedures in case of need.

5.4 Operational responsibilities anddecision-making process InTARGET

5.4.1 Operational responsibilities

Each NCB and the ECB is responsible formanaging its infrastructure and the processingof payments according to the defined servicelevel for TARGET. Given the decentralisednature of TARGET, incidents may happenwithin the individual NCB’s/ECB’senvironment, the national network or thecross-border network. The management ofthese incidents is primarily a task for theindividual NCBs/ECB, in co-operation withtheir RTGS participants/customers. However,because of the high cross-border traffic ofTARGET (42% of the value and 21% of thevolumes are processed cross border), thefailure of individual systems requires acommon decision-making process of theNCBs and the ECB.

5.4.2 The internal decision-making process

TARGET operates under clearly definedsystem management rules. In each decision-making layer, the bodies involved can preparedecisions via permanently availableteleconference facilities. The hierarchy ofproblem management in TARGET is asfollows:

Day-to-day management of TARGET is theresponsibility of the NCB’s settlementmanagers (in the case of the EPM, the ECBsettlement manager). This is steered bythe TARGET co-ordinator nominated by theECB. The settlement managers and theTARGET co-ordinator communicate via ateleconference facility or via alternativemeans of communication.

In the event of problems, which cannot beaddressed within the scope of the existingprocedures, these are passed on to theTARGET crisis managers for furtherassessment. This group is steered by the ECBDirector General – Payment Systems. Thelatter will, if necessary, refer problems to theExecutive Board of the ECB, for presentationto the Governing Council.

For very-critical payments (currently only CLSpayments), notwithstanding any decisions thatare pending in the relevant bodies mentionedearlier, activation of contingency processingshould be immediately prepared by theparties involved, at the latest when therelevant deadline20 for making these paymentshas been reached. If the final deadline issubsequently at risk, the payment should be

Governing Council

ECB Board

Director GeneralPayment Systems

CrisisManager

TARGETCo-ordinator

SettlementManager

▲

▲

▲

20 These are the “intermediate” deadlines, which are recommendedfor normal operations, in order to give subsequent intermediariessufficient time to activate their contingency procedures. For CLSrelated payments, these deadlines are described in a documententitled “Recommendations for CLSB related payments in euro”.which is available on the ECB Website.


forwarded, using prepared contingencyprocedures, without any delay due todecision-making.

5.4.3 Communication with banks andsettlement systems

In general, communication with the bankingcommunity will take place via the normalcommunication channels between the RTGSsystems and the credit institutions, as well asvia the TARGET Information System.

In case of need, there will also be bilateralcontacts between the respective settlementmanager of the NCB/ECB and the RTGSparticipant(s). For this purpose, all NCBsoperate a dedicated helpdesk via which the

local banking community is informed orassisted in case of RTGS problems. The issuecan afterwards be escalated to the higherlevel, where the crisis manager at the NCBscan be reached directly by a similar rankedmanager at the credit institution’s side.

5.5 Who can be contacted with aproblem or query?

Queries arising from TARGET paymentsshould be treated in the same way as anyother payment queries and credit institutionsshould communicate directly with each other.In the event that further information isrequired, credit institutions should contactthe NCB which runs the RTGS system inwhich they participate.

6 TARGET Compensation scheme

6.1 Introduction

The following section of the InformationGuide is a description of the TARGETCompensation Scheme which was adoptedby the Governing Council on 4 April 2003. Itis a single scheme to apply to all paymentsmade through TARGET and is offered toparticipants21 in both the euro area and non-euro area countries. In order to make theTARGET Compensation Scheme as simpleand attractive as possible, it has been builtupon market practices, in particular theEuropean Interbank CompensationGuidelines, and where possible includesfeatures requested by the banking sector. TheTARGET Compensation Scheme replaces theformer TARGET reimbursement scheme.

Although the TARGET CompensationScheme and the European InterbankCompensation Guidelines are independent ofeach other, it is also clear that they are,complementary. Banks are stronglyencouraged to settle claims, including anywhich may be due to a malfunction inTARGET, among each other according to therevised European Interbank Compensation

21 In this description of the TARGET Compensation Scheme,“participant” refers to both direct and indirect participants.

Guidelines, regardless of whether or not aclaim relating to the same payments is beingsubmitted to the ESCB.

In order to keep the process of making aclaim as straightforward as possible and tofacilitate an overview of claims and offers forthe claimants, the ESCB has designed a singleform which will be used for the entire processfrom making a claim to accepting an offer.This form includes everything needed for themaking of a claim by a TARGET participant,the calculation and making of offers by theECB Governing Council and a standardparagraph which the claimant must sign toindicate acceptance of an offer.

The description given in this information guideis only a summary of the binding text found inthe TARGET Guideline and is not a substitutefor the original, which can be found on theECB website (www.ecb.int) under PublicationsLegal Document. Hence, the TARGET Guidelineand its national implementation provisions shallalways prevail.


6.2 Scope of the scheme

The TARGET Compensation Scheme isintended to cover all events where, due to amalfunction in TARGET, the processing ofTARGET payment orders could not becompleted on the same day. The Schemeapplies to all TARGET payments, both at thedomestic and cross-border level, and todirect and indirect participants in TARGETcomponents of both euro area and non-euroarea NCBs.

In case of malfunctioning of TARGET, theESCB shall not make other compensationoffers than the one specified under theTARGET Compensation Scheme. Participantsmay avail themselves of other legal means toclaim compensation. However, if they acceptan offer made under the TARGETCompensation Scheme they must accept it asfull and final settlement of their claim andwaive all claims (including claims forconsequential damages) they may have againstany member of the ESCB in accordance withnational laws or otherwise.

Compensation offers and payments madeunder the TARGET Compensation Schemeshall not constitute an admission of liabilityof any of the NCBs/the ECB involved for themalfunctioning of TARGET.

The Scheme will as a rule not apply if themalfunction is caused by external eventsoutside the control of the ESCB or the failureof third parties (such as network providers).In such events the ESCB will use its discretionas to whether and how the Scheme shouldapply.

6.3 Compensation under the scheme

In normal banking practice and accordingto the European Interbank CompensationGuidelines, the sending bank recompensesthe receiving bank in the event of a paymentnot being delivered on the due date. TheTARGET Compensation Scheme complementsthese practices in cases where a malfunction

in TARGET prevents the execution of apayment on the processing date.

The TARGET Compensation Scheme aims asa general principle to compensate the sendingbank, under some specified conditionshowever, a compensation offer could be madeto the receiving TARGET participant.

For sending participants

The ESCB will consider compensation claimsfor payment orders that could not beexecuted on the processing date due to amalfunction in TARGET. Alternatively if aTARGET participant can demonstrate, by anymeans, to the satisfaction of the ESCB, that itintended to enter a payment order into thesystem but could not do so due to a nationalRTGS system being on stop sendingcompensation would also be considered.

The compensation offer would consist ofinterest compensation calculated on the basisof whichever is lower of the EONIA rate(the euro overnight index average) or theEurosystem’s marginal lending rate on eachday of the TARGET malfunctioning. The rateused is referred to as “reference rate”. TheESCB will take into account the proceeds ofany use of funds that the TARGET participantmaking the claim might have had by havingrecourse to the deposit facility (orremuneration received for positive balanceson settlement accounts or RTGS accounts incase of the non-euro area NCBs). If fundswere placed in the market or used to meetthe minimum reserve requirements nointerest compensation will be paid. Thecalculation of interest compensation is basedon the following method:

[(Principal amount in euro) × (rate ofcompensation) × (period of malfunctioning)/ 100 x 360] – the amount received for useof the funds.

In addition to the interest compensation offeras defined above, the ESCB offers to pay anadministration fee for any single payment


order which, owing to the TARGETmalfunctioning, could not be executed on theprocessing date and for which a compensationoffer will be made. This administration feeshall be calculated for each bilateralrelationship the sending TARGET participanthas with a receiving TARGET participant ona degressive scale of €100 for the firstpayment order not executed on theprocessing date, €50 for each of the nextfour, and €25 for each payment as from thesixth onwards. This scale shall apply tomultiple payment adjustments to be made toone single receiving bank in connection withpayments from one single sending bank.

For claims from participants which are innon-euro area countries, limits to theremuneration on the aggregate amount ofovernight deposits of their RTGS accountswill be disregarded, if the excess can beshown to be due to the malfunctioning.

For receiving participants

Compensation offers to receiving participantsare meant to compensate the higherrefinancing costs (with the central bank) thanwhen the receiver would have been able torefinance in the market. Hence, the receiverwill only be compensated by the Scheme inthe event of a malfunction in the RTGSsystem in the country of the receivingparticipant, or if a malfunction occurs so latein the TARGET operating day that recourseto the money market is technically impossibleor impractical. Furthermore, the receivingparticipant must be able to demonstrate that,due to the non receipt of an expectedpayment, it had to make use of the marginallending facility or, if the participant does nothave access to the marginal lending facility,was left with a debit balance or spillover intoovernight credit, or had to borrow from itsNCB at the end of day.

Offers will consist only of interestcompensation. The amount will be calculatedusing the same method as for sendingparticipants, however, the interest

compensation will be based on the differencebetween the marginal lending rate and thereference rate and will be calculated on theamount of recourse to the marginal lendingfacility resulting from the malfunction.

For participants which are not counterpartiesto Eurosystem monetary policy operations orwhich are in RTGS systems of non-euro areacountries, in the event of a debit balance orspillover from intraday to overnight credit orthe need to borrow from the central bank, thepart of the penalty rate greater than the marginallending rate, according to local RTGS rules, willbe waived and disregarded in future cases ofspillover, if the participant can show this wasdue to the malfunction. For participants in RTGSsystems in non-euro area countries, spillover,debit balances or borrowing from the NCB willnot lead to restrictions in future access tointraday credit and/or participation in thenational RTGS system.

6.4 Applying for compensation

Claims for compensation under the TARGETCompensation Scheme must be presented bythe claimant to its “home” NCB, i.e. the NCBwhere the account is held which was, orshould have been debited or credited. Aseparate claim form must be submitted foreach bilateral relationship for which apayment (or payments) was (were) notexecuted on the processing date due to themalfunction, the claim form may thereforecontain several individual claims. Each claimmust be made using the template claim formand sent to the “home NCB” within twoweeks of the date of the malfunction,together with any relevant information andevidence to back up the claim.

If the home NCB requests additionalinformation and evidence, this must besupplied within two weeks of such requestbeing made.

The claimant will normally be informed aboutthe claim assessment of the GoverningCouncil of the ECB, in writing, within


14 weeks of the malfunction. Thiscommunication will come directly from themalfunctioning NCB.

6.5 Receiving the compensation

Offers of compensation will be receiveddirectly from the malfunctioning NCB andwill be made in respect of individual paymentswithin a claim form i.e. if a single claim formcontains five payments, i.e. claims, of whichfour are accepted, then four individual offerswill be made. The offer will be made usingthe same standard form which the claimantused to make the claim. If the claimant wishesto accept a compensation offer, it must tickthe offers which it accepts and sign and returnthe form to the NCB which made the offer,within four weeks of receipt.

Likewise, if a claimant wishes to reject theoffer, the malfunctioning NCB making theoffer should be notified. However, if thesigned letter of acceptance has not beenreceived by the malfunctioning NCB withinfour weeks of making the offer, it will beassumed that the claimant has rejected theoffer.

Payments in respect of the compensationoffers will be made by the malfunctioningNCB on receipt of the signed form(s)indicating the claimants acceptance of theoffers.

6.6 Example

General assumptions underlying the example

The sender, participant A, makes a paymentof €9,000,000 to participant B. The paymentis not received due to a malfunction inTARGET.

Scenario

The payment is returned to participant Awho only has the possibility to place it on thedeposit facility (“use of funds”) and receives€750 in interest.

Participant B has a deficit on its RTGS accountof the full amount and must make use of themoney market to cover it, incurring €1,125interest charges (at the market rate for whichEONIA rate is always used as a proxy).

In line with the EBF Interbank CompensationGuidelines, which states that “where a claimfor compensation is identified, … no bankshould be unjustly enriched or injured by theactions of another bank”, participant Arecompenses participant B22 the sum of€1125 plus the administration fee of €100.

Participant A will make the compensationclaim to its home NCB. The claim is acceptedby the ECB and Participant A receivescompensation from the malfunctioning NCBof the difference between EONIA (€1,125)and the deposit facility (€750), in this case€375, plus the administration fee (€100 forthe first payment).

Payment: €9,000,000

Execution delay as aresult of themalfunctioning: one calendar day

Deposit rate: 3.0% = interest of €750for one day

EONIA: 4.5% = interest of €1,125for one day

Marginal Lending Rate: 5.0% = interest of €1,250for one day

Administration fee: AF

22 If the malfunction occurred too late in the day for Participant Bto go to the money market and it therefore had to make use ofthe Marginal Lending Facility, it may also be entitled to €125compensation from the ESCB.


7 Frequently asked questions on TARGET

7.1 TARGET operating times

7.1.1 Working days and non-business days

The Governing Council of the EuropeanCentral Bank (ECB) has decided that from2002 until further notice, in addition toSaturdays and Sundays, TARGET will beclosed on New Year’s Day, Good Friday(Catholic/Protestant), Easter Monday(Catholic/Protestant), 1 May (Labour Day),Christmas Day and 26 December. In addition,the Greek RTGS system (HERMES) will beoperational on those Catholic/ProtestantGood Fridays and Easter Mondays which donot coincide with the Greek Orthodox EasterFridays and Mondays, but only for thefollowing limited range of operations:settlement services offered by HERMES onthese days will only cover domestic customerpayments of a retail nature, including thesettlement of retail payment systems. Noother type of payments, such as cross-border,interbank, money market, capital market orforeign exchange transactions, will beprocessed through HERMES. The Bank ofGreece will not normally offer access tostanding facilities on these days and it willonly be granted if absolutely necessary, e.g.to avoid a failure in the settlement of anancillary system. Greece’s situation will bereassessed in 2005.

On TARGET closing days no standing facilitieswill be available (except at the Bank of Greeceas described above) and these days are notsettlement days for the euro money market orfor foreign exchange transactions involvingthe euro. The EONIA and EURIBOR arenot published on TARGET closing days.Furthermore, the correspondent central bankingmodel (CCBM) for the cross-border use ofcollateral is closed on TARGET closing days.

7.1.2 Opening hours

The opening hours cover the full EU workingday for financial markets and overlap partially

with both the North American markets andthe Asian markets.

Normal TARGET opening hours are from07:00 C.E.T. until 18:00 C.E.T. Customerpayment orders in TARGET may be madeuntil 17:00 C.E.T. End-of-day proceduresusually commence at 18:10 and should becompleted within a short period of time.Some restrictions on liquidity apply to thenon-euro area countries of the EU whichinvolve, essentially, earlier liquidity cut-offtimes than those for the euro area countries.There are procedures for dealing withabnormal circumstances – these are detailedin Section 5.

7.1.3 Are all credit institutions obliged tobe open when TARGET is open?

There is an obligation for all creditinstitutions to be able to receive fundswhenever their RTGS system is open forconnection to TARGET. If the local RTGSrules allow for the crediting of funds, there isno obligation for the credit institutions to beopen while TARGET is open. However, thosecredit institutions which are liable to receivelarge amounts of liquidity during a TARGETworking day are strongly encouraged to be ina position to deal with these funds during theworking day and to prevent an accumulationof liquidity on their RTGS system account.Depending on the internal organisation ofthe credit institutions it may suffice to have alimited treasury management facility availablein such situations.

7.2 Sending and receiving TARGETpayments

7.2.1 Is there a daily volume limit inTARGET?

TARGET has been designed to handle theanticipated volume of traffic in large-valuepayments in euro. It has also been designed


to be able to adapt rapidly and easily toincreases in this volume of traffic. There isno specific limit on volumes in TARGET.

7.2.2 Is there a minimum value forpayments to be processed inTARGET?

Although TARGET is designed as a large-value RTGS system, there is no specificminimum value limit for payments processed.For various reasons, some banks may wish touse TARGET exclusively for large-valuepayments, while others may decide to channelall their cross-border euro operationsthrough TARGET.

7.2.3 Do I need to exchange SWIFT keyswith banks to which I wish to sendpayments?

It is not necessary to exchange SWIFT keyswith a bank in order to be able to sendpayments to it via TARGET.

As TARGET is a decentralised system, eachcredit institution has a relationship with anRTGS system which participates in TARGET.23

Each credit institution needs to observe localrules in this relationship, which may in somecases require an exchange of SWIFT keys withthe NCB responsible for the RTGS system.With regard to the execution of TARGETpayments, the role of ensuring confidentialityand security in the exchange of paymentmessages is entrusted to those NCBsparticipating in TARGET. These NCBs belongto a Message User Group and SWIFT keys areexchanged between them within this group.Consequently, payments can be communicatedin a secure and confidential way to beneficiarybanks without the ordering bank needing toexchange keys with the beneficiary bank.

7.2.4 Do I need to use the code “//RT”?

The code “//RT” is used to indicate that thepayment should be executed in an RTGS

system. It is intended to be used for paymentexecution information. Often it is used wherethe confirmation of a Treasury or moneymarket transaction has indicated that thefunds will be received through an RTGSsystem or where an institution wished toinstruct its correspondent to execute thepayment through an RTGS system.

This code is not used in the TARGETInterlinking message. Should it appear, it isnot validated.

7.2.5 When are payments received byindirect participants?

Payments in TARGET are settled with same-day value between direct participants ofRTGS systems participating in TARGET.

The value applied by the direct participant toother participants in the RTGS systemdepends on the contract between the twoparties. In particular, arrangements may varyconcerning late payments or payments onpublic holidays, even between indirectparticipants represented by the same directparticipant in the same RTGS system.

All payments executed via TARGET areirrevocable for the sending credit institutionat the latest from the moment when theRTGS account of the sending participant isdebited by the sending NCB/ECB for theamount of the payment order.

Once a TARGET payment has been creditedto the RTGS account of the direct participant,that direct participant will be able to pass onthe payment to its indirect participant. Theposition of the indirect participant dependson the arrangement between the direct andindirect participant and falls outside the scopeof TARGET.

23 Either directly or via a direct participant.


7.3 Queuing mechanisms

Domestic RTGS systems have evolvedindependently and therefore each uses thequeuing mechanism best suited to the countryconcerned. Queuing mechanisms are usuallyused where there are insufficient fundsavailable on the RTGS account of theparticipant to execute the paymentinstruction. Queues may also be used ifthe receiving NCB/ECB is temporarilyunavailable to avoid the need for creditinstitutions to re-input data once the systemis operational.

Annex 10.8 summarises the queuingmechanisms used by each NCB when an NCB/ECB is temporarily unavailable, which may bedistinct from those used for queuing in theevent of lack of funds.

7.4 Liquidity

In the euro area unlimited intraday credit,based on eligible collateral, is provided freeof interest charges to those directparticipants which fulfil the general monetarypolicy counterparty eligibility criteria of theESCB. Unlimited intraday credit, providedthat this intraday credit remains limited tothe day in question and that no extension toovernight credit is possible, may also begranted to Treasury departments of centralor regional governments active in the moneymarket, to public sector bodies authorised tohold accounts for customers, to clearing andsettlement organisations and to investmentfirms. Intraday credit is not granted to remoteaccess participants.

The non-euro area NCBs may, subject tolimits and rules set by the Governing Council,provide collateralised intraday credit in euroto the participants in their national euroRTGS systems. Such collateral must meet thesame requirements as those prescribed foreligible collateral for monetary policyoperations under the Guideline of theEuropean Central Bank on monetary policyinstruments and procedures of the

Eurosystem, dated 7 March 2002. At any timeafter the liquidity deadline, which is set at17:00, a participant in the national RTGS of anon-euro area NCB is allowed to makepayments in euro only to the extent thatthose payments are made from creditbalances on the participant’s RTGS accountafter the exclusion of any balances thatare attributable to the provision ofcollateralised intraday credit. Participantswhich are overdrawn when TARGETcloses will be subject to penalties. Non-euroarea NCBs may remunerate credit balancesat the rate applicable to the ESCB depositfacility.

7.5 TARGET fees

The TARGET fee covers the sending of thepayment message from one RTGS systemacross the Interlinking to another RTGSsystem.

The fee to be charged for cross-borderpayments via TARGET between directparticipants is based on the number oftransactions, according to the followingregressive scale:

€1.75 per transaction for the first 100transactions per month;€1.00 per transaction for the next 900transactions per month;€0.80 per transaction beyond 1,000transactions per month.

The fee is charged by the sending NCB onlyand is always the same, irrespective of thedestination or size of the payment. It coversall the Interlinking and processing costs ofthe transaction (including those of the sendingRTGS system, the Interlinking system and thereceiving RTGS system) with the exceptionof the cost of communication between theordering participant and the sending NCB.No additional entry or periodic fees arecharged to users of the cross-borderTARGET service. However, the possibilityexists for RTGS systems to charge extra feesfor any additional services they may provide


Processing included in the price

Covered by transaction fee

Not covered by transaction fee

Receiving RTGSparticipant

Sending NCB Receiving NCB

Sending RTGSparticipant

The scope of TARGET fees (e.g. the entering of paper-based paymentinstructions).

TARGET fees are charged to the RTGSsystem participant that introduces thepayment into TARGET. Fees are chargedseparately from the TARGET payment. Thismeans that there is no alteration to theamount field in any TARGET payment.

The ECB also recommends that bank chargesfor commercial payments are handledseparately from the underlying payment.

8 Business practices

8.1 European Banking Federation

Best banking practice and guidelines onliquidity management, which encourage riskreduction and promote efficient liquiditymanagement, are the responsibility of thebanking sector. The European BankingFederation (EBF) has published guidelines on“Liquidity management in the framework ofTARGET” (September 1999), which havebeen endorsed by the three European creditsector associations (ECSAs). For furtherdetails, credit institutions should consult thefull document.

8.1.1 European Banking FederationGuidelines24 on LiquidityManagement

Scope of these guidelines

The following guidelines are intended tocover all euro payments made throughTARGET and any other euro payment system.They are not intended to supersede anyguidelines or rules agreed in domesticsystems, nor any bilateral agreement.Monitoring the observance of the EuropeanBanking Federation Guidelines is left tomarket forces. Accordingly, these Guidelinesdo not give rise to any legally enforceablerights or obligations.

First Guideline

– Euro payments related to interbanktransactions such as the payment leg of moneymarket, foreign exchange and derivativetransactions which are traded before the valuedate (i.e. on date X-1 or prior) should be senton value date (i.e. day X) with sufficientliquidity coverage as early as possible in theday and no later than 12 .00 C.E.T.

– Commercial payments received from theordering party before the value date (i.e. ondate X-1 or prior) should be sent on valuedate (i.e. day X) with sufficient liquiditycoverage as early as possible in the day andno later than 12.00 C.E.T.

Second Guideline

– Euro payments related to interbanktransactions such as the payment leg of moneymarket, foreign exchange and derivativetransactions which are traded on the valuedate before 10.00 C.E.T., should be sent onthe value date, with sufficient liquidity coverageas fast as possible and, at the latest, before

24 The text of the EBF Guidelines is provided for informationpurposes only. These guidelines may change from time to time.The present version reflects the situation at the time of finalisingthis Information Guide and the latest version is not guaranteedto be reflected in this document. All interested parties shouldcontact to the European Banking Federation for further details.


12.00 C.E.T. Any of those euro paymentsrelated to interbank transactions traded onthe value date after 10.00 C.E.T., should besent on the value date, with sufficient liquiditycoverage as fast as possible and, at the latest,two hours after the transaction has beenagreed, or before 17.00 C.E.T., whichever isearlier.

– Commercial payments received from theordering party on the value date should besent on the value date with sufficient liquiditycoverage as fast as possible and, at the latest,two hours after the payment is received, orbefore 17.00 C.E.T., whichever is earlier.

– euro payments related to interbank liquidityposition squaring transactions (for ESCBaccounts) which are traded on the value dateat 15.00 C.E.T. or later should be sent on thevalue date with sufficient liquidity coverage asfast as possible and, at the latest, two hoursafter the transaction has been agreed, orbefore the cut-off time of 18.00 C.E.T.,whichever is earlier.

Third Guideline

A receiving clearing bank is not obliged togive same day value for a Late Payment(payment with a debit/execution time stamp of17.00 C.E.T. or later) of a non-Own AccountReceipt with two exceptions:

– The Sending Clearing Bank pre-agrees withthe receiving Clearing Bank that same dayvalue will apply (pre-agreed Late Payment). Ifpre-agreed Late Payment arrives on the agreedday, no compensation is due. However, if pre-agreed Late Payment does not arrive on theagreed day, the Sending Clearing Bank willpay special compensation, based on aminimum of the ECB Lending Rate plus anadministrative fee.

– If the Receiving Clearing Bank, at its owndiscretion, chooses to give same day value fora non-pre-agreed Late Payment, or is obligedto do so according to local law/guidelines. Inthese instances, the Sending Clearing Bankwill pay special compensation to the Receiving

Clearing Bank-based on the ECB Lending Rateless the ECB Deposit Rate, plus anadministrative fee.

8.1.2 European Banking FederationGuidelines on interbankcompensation

In 2001 the European Banking Federation(EBF) published a document entitled“European interbank compensationguidelines”. The guidelines were developed,first, to respect the principle that no bankshould unjustly benefit from or beinconvenienced by the action/error ofanother bank; second, as a recommendedbasis for the settlement of claims forcompensation arising from payments in euromade between banks and, third, for thecategorisation and calculation of interestclaims to compensate for misdirected euro-denominated payments or euro-denominatedpayments sent on the wrong value date. Forfurther details, credit institutions shouldconsult the EBF.

8.2 Recommendations for CLSpayments in euro

8.2.1 Scope of the recommendations

The following recommendations are intendedto cover payments relating to CLS Bank(CLSB) which are made through TARGETand are thus denominated only in euro.

These recommendations do not give rise toany legally enforceable rights or obligationsand are therefore not intended to supersederules agreed in domestic systems, or anylegally binding bilateral agreements. If acontradiction arises between those rulesor bilateral agreements and therecommendations hereafter, the latter shouldbe used as a basis for an update of the rulesand agreements. Observance of theserecommendations (covering normal andabnormal circumstances) and the monitoringthereof will be left to the interested market


participants, i.e. to CLS settlement membersand/or nostro agents, wherever applicable.25

8.2.2 Recommendation 1

a) Settlement members should prepare theirfirst pay-in deadline26 payments immediatelyafter receipt of their final pay-in scheduleand, where applicable, instruct their nostroagents as soon as possible, at the latest by7 a.m.

b) Settlement members/nostro agents shouldsubmit CLSB payments for the first pay-indeadline as early as possible, with sufficientfunds on their accounts to ensure that theirlocal RTGS system can settle the paymentand that the sender’s account is debited by7.15 a.m. at the latest.27

c) Settlement members/nostro agents should,if the funds available for payments allow themto do so, accelerate their remaining pay-insas much as possible; since the last pay-in (at12 noon CET) is expected to be relativelysmall, settlement members/nostro agentsshould attempt to make this payment by the11 a.m. CET deadline (in one go, togetherwith the pay-in due at that time).

d) If CLSB issues a revised pay-in schedule ora pay-in call28, the settlement members/nostroagents concerned should react promptly bysending the relevant payment instruction(s)and by closely monitoring the correspondingdebit in their relevant central bank account.If they cannot trace the posting of thetransaction(s) to this account, they shouldcontact the local NCB as soon as possible.


In the event of problems29 impacting CLSBand triggering contingency processing,settlement members/nostro agents should beprepared to accumulate funds for CLS-relatedpayments in order to aggregate and acceleratetheir pay-ins to CLSB, so as to enable theirfunding to be completed as quickly as possible

under contingency conditions, with a reducednumber of payments.


If a settlement member/nostro agent is facingproblems and an expected pay-in has notbeen received by CLSB (and if this isconfirmed by the ECB/NCB concerned), thesettlement member/nostro agent should beprepared to submit the payment to its RTGSsystem, using the agreed contingency channel,once it has been confirmed that its RTGSaccount has not been debited. The settlementmembers/nostro agents should then ensurethat the necessary actions are taken in orderto neutralise the initial payment instruction.The local NCB and the ECB will, on a best-effort basis, also try to avoid the doubleprocessing of the instruction, if need be.

As a mechanism to process payments in atimely manner, settlement members/nostroagents might also use alternative access pointsto TARGET when experiencing problems intheir own systems.


If an NCB is facing problems and an expectedpay-in has not been received (and if this isconfirmed by the ECB), settlement members/nostro agents should be prepared to resubmitthe payment to their RTGS system (via the

25 Only these two types of entities can be involved in payments toand from CLSB.

26 As laid down in CLSB’s pay-in schedule, the first pay-in is due at8 a.m.

27 Settlement members wishing to fulfil their own CLS euro paymentobligations from an EU Member State that has not adopted thesingle currency should, if necessary, step up their early-morningliquidity arrangements. Nostro agents for euro payments (andeuro liquidity providers) should act from a country where theyhave unrestricted access to central bank credit in euro.

28 For account value, for settlement or for currency close.29 Including one or more of the following situations:

a) system problems at the credit institution level;b) RTGS connection problems (between credit institutions and

NCBs);c) problems in any of the TARGET components (RTGS,

Interlinking, CBT or others) at the NCBs/ECB.While generally associated with problem scenarios, an acclerationof pay-ins may also take place in normal circumstances.


normal or the contingency channel, as agreedat a bilateral level), as long as it is confirmedthat their central bank account has not beendebited. The NCB should then ensure thatthe necessary actions are taken to neutralisethe effect of the initial payment instruction,in order to avoid double processing.

On the other hand, if the settlement member/nostro agent is able to confirm that the debithas already taken place, a copy of thisconfirmation (including the payment details)should immediately be sent to the NCB, forfurther investigation and processing, without anadditional debit on the settlement member’s/nostro agent’s central bank (RTGS) account.

As an optional mechanism to processpayments in a timely manner, settlementmembers/nostro agents might also usealternative access points to TARGET whenexperiencing problems in their RTGS system.Where necessary, the failing NCB will providethe necessary assistance to allow thesettlement members/nostro agents to shiftliquidity to the RTGS system serving as theiralternative access point to TARGET.

8.3 Applying value

Current practices for applying value tointerbank payments by direct participants in

Country/ECB Common practice or formal agreement No formal agreementfor applying same-day value

Belgium XDenmark XGermany XGreece XSpain XFrance X (Individual banks’ practices vary according

to their correspondent/customer terms and conditions)Ireland XItaly XLuxembourg XAustria XNetherlands XPortugal XFinland X (However, where possible banks can usually

be expected to credit customers the same day)Sweden XUnitedKingdom XECB X

RTGS systems to their indirect participantsand customers are outlined below.

8.4 Bank-to-bank charges forcustomer payments

The way in which banks’ customers arecharged for TARGET payments is left toeach bank to decide. Nevertheless, toavoid confusion about the original amountpaid through TARGET and to enhancetransparency, it is recommended thatTARGET participants credit the full value ofcustomer payments to the account of therecipient and that any charges to the receivingcustomer be debited separately.

There is an ongoing common effort by banksto move towards a common position and topublish information collectively on chargesto enable the sending bank to notify thecustomer in advance of the full charges wherethe sender opts to pay the charges (“OUR”option).

(There is an ongoing euro area-wide discussionon the possibility of a “Multilateral InterchangeFee” or “MIF”, which should be applicable to allpayment systems in the euro area. Once suchan agreement is concluded, reference to thiswill be included in this Information Guide.)


9 Documentation

9.1 ECB Publications30

9.1.1 TARGET – basic texts

TARGET – Release 2001: Guideline of theEuropean Central Bank of 27 February 2002amending Guideline ECB/2001/3 on a Trans-European Automated Real-time Grosssettlement Express Transfer system(TARGET) (ECB/2002/1)

TARGET – Release 2001: Technical annexesto the guideline of the European Central Bankof 27 February 2002 amending GuidelineECB/2001/3 on a Trans-European AutomatedReal-time Gross settlement Express Transfersystem (TARGET) (ECB/2002/1):

TARGET Annual Report 2002; April 2003,press release

TARGET Minimum common performancefeatures of RTGS systems within TARGET,November 2001 ed., June 2002.

TARGET interlinking data dictionary,November 2001 ed., June 2002.

TARGET interlinking specification, November2001 ed., June 2002.

TARGET interlinking user requirement,November 2001 ed., June 2002.

9.1.2 TARGET – general information

Derogation for Greece from the long-termcalendar for TARGET closing days; 28 Feb.2002

TARGET: the Trans-European AutomatedReal-Time Gross settlement Express Transfersystem – update 2001, (Brochure); Nov. 2001

Long Term Calendar for TARGET ClosingDays; Press release 14 December 2002

9.2 Other websites providinginformation on payments systems

9.2.1 European Banking Federationwebsite

European Interbank Compensation Guidelines

Remote Access for Collateral Management

Services Available on National Holidays In1999

EBF Guidelines on Liquidity Management

Questionnaire: Services available on nationalholidays in 1999

The EBF paper on payment systems in theEuro zone

Document de la FBE sur les Systemes dePaiement dans la Zone Euro

Recommendation on handling reciprocal Eurocorrespondent banking accounts

FBE guidelines on liquidity management in theframework of Target

Lignes directrices de la FBE sur la gestion dela liquidité dans le cadre de target

9.2.2 Bank for International Settlementswebsite: Documents from theCommittee on Payment andSettlement Systems

Statistics on Payment and Settlement Systemsof selected countries – Figures for 2001, April2003

Survey of Electronic Money Developments,May 2001

30 The updated full list of documents can be found on the ECB’swebsite (www.ecb.int).


Core Principles for Systemically ImportantPayment Systems, January 2001

The Contribution of Payment Systems toFinancial Stability, September 2000

Report on OTC Derivatives: Settlementprocedures and counterparty riskmanagement (Joint report by the Committee

on Payment and Settlement Systems and theEuro-currency Standing Committee),September 1998

Reducing foreign exchange settlement risk: aprogress report, July 1998, ISBN 1024-3380

Real-time gross settlement systems, March1997, ISBN 92-9131-502-8


* if correct account number specified

NCB Credit NCB Credit beneficiary incurrent account next credit field

BE X

DK X

DE X

GR X

ES X

FR X

IE X

IT X

LU X

NL X

AT X

PT X

FI X

SE X

UK X*

EU X

10 Annexes

10.1 Reactions where the NCB/ECBBIC appears in the first credit field

(of incoming cross-border payments)

10.2 Validation of Euro RelatedInformation

SWIFT applies the following validation rulesin MT100 for ERI information in field 72:

Formats/OCMT/3a15n//CHGS/3a15n/

where

• 3a must be a valid ISO currency code

• the amount component 15n must beformatted according to the FieldFormatting Rules for Numbers (amounts –mandatory to have a decimal comma, andbetween 0 and 2 decimals after thecomma)

• 15n will not be checked on the maximumnumber of digits allowed for the relevantcurrency code

• ERI validation for the code word /CHGS/will be performed only if it immediatelyfollows /OCMT/3n15n/ in the sameoccurrence of that field (on the same lineor the next line).

• /OCMT/ should not be present more thanonce in the field

• /CHGS/ should not be present more thanonce in a field after /OCMT/

Remarks

• /CHGS/ may appear on the same line asthe /OCMT/ code word, but will not bevalidated in case it is before /OCMT/.

• If the /CHGS/ code word does notimmediately follow the /OCMT/ code word(on the same line or the next line), then/CHGS/ will not be validated.

• In SWIFT the keywords /OCMT/ and/CHGS/ do not have to be at the beginningof a line.

• No ERI validation is performed if the/REJT/ or /RETN/ code words are used. Inthat case the REJT/RETN validation forfield 72 prevails.

Examples:

Example 1:Field 72: /OCMT/DKK2345,/

/CHGS/DKK10,50/

Example 2:Field 72: / O C M T / D K K 1 2 3 4 5 , / C H G S /

DKK10,50/


BE NBBEBEBB

DK DKNBDKKK

DE MARKDEFF

ES ESPBESMM

FI SPFBFIHH is the Bank of Finland’s BIC code, and should be used in the payments where thebeneficiary institution holds the account at the Bank of FinlandSPFBFIHR is used for payments where the beneficiary institution holds an account in BOF-RTGS

FR BDFEFRPPCCT and BDFEFRPPSCC: current accounts for customers

GR BNGRGRAA

IE IRCEIE2DAPS

IT BITAITRR

LU BCLXLULL

NL FLORNL2A (for credit to the Dutch Central Bank or to customers of the Dutch Central Bank which arenot TARGET Addressable Institutions)

AT NABAATWW

PT BGALPTPL

SE RIKSESS.

GB BKENGB24 Any payments to this BIC require an account number to be quoted but no payments shouldbe made to this BIC unless a specific agreement has been made with the Bank of England in which casethe account number will be specified.BKENGB33 All payments to the Bank of England as a CHAPS Euro participant must be made to thisBIC address. Payments should not be made to BKENGB2L

10.3 Payments to an NCB

A credit institution willing to make a paymentto an NCB or an NCB’s customer should usethe following ISO BICs in the first credit field:


10.4 Routing to remote access banks

NCB Routing by credit institutions

BE Credit institution may insert //TA + country code of receiving NCB or TG BIC of the receiving NCB inaccount line of first credit field. This information would not be forwarded. If no specific routinginformation is given, the country code of the BIC in the first credit field would be used.

DK ISO BIC of receiving NCB in field 54A.

DE Credit institution inserts BIC of receiving NCB in Field 54A

GR Credit institution inserts TA followed by ISO country code of receiving NCB in account sub field of firstcredit field

ES Credit institution indicates the receiving NCB in a domestic field (when no using SWIFT to reachSLBE). When using SWIFT, they should include the BIC of receiving NCB in field 54A.

FR Payment addressed to BdF BIC + Receiving NCB branch code (e.g. BDFEFRCTESX)

IE Credit institution inserts BIC of receiving NCB in Field 54A

IT SWIFT based Cis Credit institution indicates //TA + country code of the receiving NCB in the accountline of the 1st credit field. non SWIFT based Cis Credit institutions can use code //TACC (CC =Country code) to indicate receiving NCB in the account line of the first credit field. This code is notforwarded. If no specific routing information is given, the country code of the BIC in the first creditfield will be used.

LU Credit institution inserts BIC of receiving NCB in Field 54A

NL If the payment is to be addressed to an NCB other than the one corresponding to the country code of thebeneficiary BIC, this must specified in field 72 following the TOP code word.

AT If the payment is to be addressed to an NCB other than the one corresponding to the country code of thebeneficiary BIC, this is specified either in Field 54A or in Field 56/57 of the domestic message, thenremoved for the Interlinking.

PT Receiving country code forwarded in domestic message (non-SWIFT), not forwarded in Interlinking.

FI Credit institutions can use code //TACC (CC = Country code) to indicate receiving NCB in the accountline of the first credit field. This code is not forwarded. If no specific routing information is given, thecountry code of the BIC in the first credit field will be used.

SE Credit institution indicates //TA + country code of the receiving NCB in the account line of the 1st creditfield.

UK Credit institution indicates BIC of receiving NCB in Field 54A of CHAPS message

EU Customer indicates BIC of receiving NCB in Field 54A


10.5 Customer payment

10.5.1 General format of MT100Interlinking messages

31 Where:<CC> is the country code for the sending NCB;<BIC> is the BIC in 11 characters of the bank that has sent thepayment message to the sending NCB;<TRN> is the TRN assigned to the message by the directparticipant that has sent the payment to the sending NCB.Normally it is the same as the TRN contained in Field 20 insidethe field 77E of the Interlinking message; andBIC on the second line is the one of the ordering institution asper SWIFT standard specifications. The information contained inthe first line of this field must be provided by the sending creditinstitution or the sending NCB depending on the national rules.

32 The presence of the account number is validated but the contentis not.

When sending a customer payment message,the following guidelines must be observed bythe sending credit institution:

• Either the Ordering Customer (field 50 orthe domestic equivalent) or the BeneficiaryCustomer (field 59 or the domesticequivalent) must be a non-financialinstitution.

• All credit institutions have to beidentified by BICs using the Format Ain Fields 52, 56, 57 of the SWIFTmessage.

The original ordering institution hasto be mentioned in field 52A (or thedomestic equivalent). If this information isnot provided by the sending participant andthe sending NCB is not able to provide theinformation, the payment will be rejected bythe sending NCB.

The account number line of Field 52Awill contain the “return key”(see also 3.6.2)

The beneficiary institution must bementioned in field 57A (or the domesticequivalent), and the beneficiary’saccount number must be present infield 59 (or the domestic equivalent)32.If either one of these items of information isnot available, the payment will be rejected bythe sending NCB.

If field 56A (or the domestic equivalent) is filledin, and the receiving NCB is able to identify theinstitution as a TARGET participant in thereceiving NCB’s RTGS system, the payment willbe forwarded to that institution or theparticipant which represents it, otherwise thepayment will be rejected.

M/O Field Tag Field Name Interlinking Format

Interlinking Header

M 20 Transaction Reference Number of Sending Credit 16xInstitution

M 32A Value Date 6nCurrency Code 3aAmount 15n

M 50 Ordering Customer 4*35x

M 52A Ordering Institution //TA<CC> <BIC> <TRN>31

BIC

O 56A Intermediary [/1a][/34x]<BIC>

M 57A Account With Institution [/1a][/34x]<BIC>

M 59 Beneficiary Customer /34x4*35x

O 70 Details of Payments 4*35x

O 71A Details of Charges 3a

O 72 Sender to Receiver Information 6*35x

M= Mandatory O = Optional


If field 56A (or the domestic equivalent) isnot present but the receiving NCB is able toidentify the institution in field 57A as aTARGET participant in the receiving NCB’sRTGS system, the payment will be forwardedto that bank or the bank which represents it,otherwise the payment will be rejected.

If the first field out of fields 56A and 57A (orthe domestic equivalents) containing a BICcannot be used to identify a participant in thereceiving RTGS system, the receiving NCBwill reject the payment.33

In addition, both the sending and receivingNCB will ensure that all BICs are validotherwise the payment message will berejected. Unpublished BICs are invalid. Thelatest release of the SWIFT BIC Directory34

will be taken as the reference.


For additional information, refer “SWIFT UserHandbook, Standards Category 1”.

When sending a customer payment message,the following guidelines must be observed bythe sending credit institution:

• If fields 32A and 33B have differentcurrencies, then field 36 must be present.

• If fields 32A and 33B have the samecurrency, then field 36 is not allowed.

• If field 71A contains “OUR”, field 71F isnot allowed and field 71G is optional.

33 The Italian procedure follows a bottom-up approach: wheneverthe bank indicated in field 57 is recognised as a participant inthe RTGS system, its account is credited regardless of thecontent of the field 56.

34 In its electronic form including all updates.35 Business Entity Identifier. Part of the ISO draft Standard (ISO-

13735) to identify non-financial institutions.


Interlinking Header

O 119 STP flag 8x

M 20 Transaction Reference Number of Sending 16xCredit Institution

O 13C Time indication /8b/4n1x4n

M 23B Bank Operation Code 4b

O 23E Instruction Code 4b[/30x]O 26T Transaction Type Code 3b

M 32A Amount 6n3a15n

M 33B Currency/Instructed Amount 3a15n

O 36 Exchange Rate 12nM 50K Ordering Customer [/34x]

4*35x

Or 50A [/34x]<BEI>35

M 52A Ordering Institution //TA<CC><BIC11><TRN><BIC>

O 56A Intermediary Institution [/1a][/34x]<BIC>

M 57A Account with Institution [/1a][/34x]<BIC>

M 59 Beneficiary Customer /34x4*35x

Or 59A /34x<BEI>

O 70 Remittance Information 4*35xM 71A Details of Charges 3a

O 71F Sender’s Charges 3a15n

O 71G Receiver’s Charges 3a15n

O 72 Sender to Receiver Information 6*35xO 77B Regulatory Reporting 3*35x


• If field 71A contains “SHA”, field 71F(multiple occurrences) is optional and field71G is not allowed.

• If field 71A contains “BEN”, at least onefield 71F is mandatory and field 71G is notallowed.

• The currency code in field 71G must beequal to the currency code in field 32A.

• If field 71G is present, the amount in thesub-field of 71G cannot be equal to 0.

• Either field 50 (ordering customer) or field59 (beneficiary customer) must be a non-financial institution.

• Field 52A, optional for SWIFT, ismandatory for Interlinking. The sendingNCB/ECB should ensure that the originalordering institution is mentioned in field52A (or the domestic equivalent). If thesending institution does not provide thisinformation and the sending NCB/ECBcannot supply it, the sending NCB/ECBshould reject the payment order.

• Field 57A, optional for SWIFT, ismandatory for Interlinking. If this field ismissing, the sending NCB/ECB shouldreject the payment order.

• If the first field containing a bank’s identifiercannot be used to identify an (in)directparticipant in the receiving RTGS system,the receiving NCB/ECB must reject thePSMR. The negative acknowledgementmust show the appropriate error code.

• The sending NCB/ECB should ensure thatthe beneficiary’s bank is mentioned in field57A and the beneficiary’s account numberis present in field 59. If either of theseitems of information is not available, thesending NCB/ECB should reject thepayment.

• If field 56A has been completed and thereceiving NCB/ECB can identify the bankas a direct or indirect participant in its

RTGS system, it should forward thepayment to that bank or its representative/correspondent, otherwise it should rejectthe payment.

• If field 56A is not present but the receivingNCB/ECB can identify the bank in field57A as a direct or indirect participant inits RTGS system, the receiving NCB/ECBshould forward the payment to that bankor its representative/correspondent,otherwise it should reject the payment.

• In addition, both the sending and receivingNCB/ECB must ensure that all BIC codesare valid. They should refer to the currentissue of the SWIFT BIC Directory.

• If field 23B is SPRI, then field 23E isoptional, and if used can contain onlySDVA or INTC.

• If field 23B is SSTD or SPAY, then field23E is not allowed.

• If field 23B is SPRI, then field 56A is notallowed.

• A code word in field 23E can be used onlyonce.

• If field 23E is used more than once, thecodes must be in the following order:SDVA, INTC, REPA, CORT. It is notmandatory to use all possible code wordsevery time.

• If field 23E is used more than once, thecombination of the code words REPA andCORT is not allowed.

• If field 119 is present and is equal to “STP”,then if the code word /INS/ is used at thestart of a line in field 72, it may be followedonly by a valid BIC. In addition, it cannotbe used again at the start of any other linein field 72.

• If field 119 is present and is equal to “STP”,then the code words /RETN/ and /REJT/are not allowed.


• If field 119 is present and is equal to “STP”,then the code word /OCMT/ is not allowedin field 72.

• If field 119 is present and is equal to “STP”,and the country code of the BIC in field57A is either AD, AT, BE, BV, CH, DE,DK, ES, FI, FR, GB, GF, GI, GP, GR, IE, IS,IT, LI, LU, MC, MQ, NL, NO, PM, PT, RE,SE, SJ, SM, TF or VA, then the accountnumber in field 59 or 59A should be avalid IBAN. This means that the countrycode of the IBAN must be a valid ISOcountry code and the check digits of theIBAN must be valid.

• 13C may occur up to five times.

• The code words SNDTIME and RNCTIMEare not allowed in field 13C.

10.5.3 Example of a customer’s payment

Bank X Bank Y

ELLIPSBelgium National Bank

BIRELBanca d’Italia

Customer

Belgian Bank X is sending a TARGET transferto Italian Bank Y, for the benefit of customerZ.

The TARGET payment should be formattedin this way:

• Ordering customer: W

• Sending bank: bank X

• Bank of the beneficiary: bank Y

• Beneficiary customer: Z

The Banca d’Italia should not be mentionedas intermediary bank of Bank Y in TARGET.

In a SWIFT based RTGS system, the domesticTARGET payment would have the followingformat:

36 Field 59 must always include an account number.

Tag Field name M/O Content

20 Transaction M TRN123456789ABCDReferenceNumber

13C Time Indication O

23B Bank Operation M CREDCode

23E Instruction Code O

26T Transaction Code O

32A Value Date, M YYMMDDEUR1000,Currency Code,Amount

33B Currency/ M EUR1000,InstructedAmount

36 Exchange Rate O

50K Ordering M Customer W(or Customer50A)

52A Ordering M BNKXBEBBInstitution

53 Followingnational standard

54 Followingnational standard

56A Intermediary O

57A Account With M BNKYITRRInstitution

5936 Beneficiary M Customer ZCustomer

70 Details Oof Payment

71A Details of Charges M OUR

71F Sender’s Charge O

71G Receiver’s OCharges

72 Sender to Receiver OInformation

77B Regulatory OReporting


10.6 Interbank payment



Interlinking header

M 20 Transaction Reference Number of Sending 16xCredit Institution

M 21 Related Reference 16x

O 13C Time Indication /8b/4n1x4n

M 32A Value Date 6nCurrency Code 3aAmount 15n

M 52A Ordering Institution //TA <CC> <BIC> <TRN><BIC>

O 56A Intermediary [/1a][/34x]<BIC>

O 57A Account With Institution [/1a][/34x]<BIC>

M 58A Beneficiary Institution [/1a][/34x]<BIC>

O 72 Sender to receiver information 6*35x

M = MandatoryO = Optional

When sending an interbank payment message,the following guidelines must be observed bythe sending credit institution:

• The original ordering institution hasto be mentioned in field 52A (orthe domestic equivalent). If thisinformation is not provided by thesending institution and the sending NCBis not able to provide the information,the payment will be rejected by thesending NCB.

• The account number line of Field 52Awill contain the “return key”(see also 3.6.2)

• All parties to the transaction mustbe financial institutions and addressedby published BICs using the FormatA in Fields 52, 56, 57, 58 of theSWIFT message.

• If field 56A is filled in, field 57A mustbe present too.

• If field 56A is filled in, and the receivingNCB is able to identify the institution as a

TARGET RTGS participant in the receivingNCB’s RTGS system, the payment will beforwarded to that institution or theparticipant which represents it, otherwisethe payment will be rejected.

• If field 56A is not present, but field 57A isfilled in, and the receiving NCB is able toidentify the institution in field 57A as aparticipant in its TARGET RTGS system, thepayment will be forwarded to that institutionor the participant which represents it,otherwise the payment will be rejected.

• If neither field 56A nor field 57A is present,and the receiving NCB is able to identifythe institution in field 58A as a participantin its RTGS system, the payment will beforwarded to that institution or theparticipant which represents it, otherwisethe payment will be rejected.

• In addition, both the sending and receivingNCB must ensure that all BICs are validotherwise the payment message will berejected. Unpublished BICs are invalid. Thelatest release of the SWIFT BIC Directoryhas to be taken as the reference.


• Field 13C may occur up to five times.

• The code words SNDTIME and RNCTIMEare not allowed in field 13C.

10.6.2 Example of a bank-to-bankpayment

Bank X Bank Y

ELLIPSBelgium National Bank

BIRELBanca d’Italia

Belgian Bank X is sending a TARGET transferto Italian Bank Y, for example to settle amoney market transaction between them.The TARGET payment should be formattedin this way:

• Sending bank: bank X

• Beneficiary bank: bank Y

Tag Field name M/O Content

20 Transaction M TRN123456789ABCDReference Number

21 Related Reference M REFxxxxxxxxxxxxx

13C Time Indication O

32A Value Date, M YYMMDDEUR1000,Currency Code,Amount

52A Ordering Institution O

53 Following nationalstandard

54 Following nationalstandard

56A Intermediary O

57A Account With OInstitution

58 Beneficiary M BNKYITRRInstitution

72 Sender to ReceiverInformation O

Banca d’Italia should not be mentioned asintermediary bank of Bank Y in TARGET.

In a SWIFT based RTGS system the domesticTARGET payment would have the followingformat:

Line 1 /REJT/ 2n[1a][/2b] M /REJT/ means a reject and is followed by the identification of theor field causing the reject (see SWIFT guidelines)/RETN/ OR

/RETN/ means a return and is followed by the identification ofthe field causing the return (see S.W.I.F.T guidelines)

Line 2 /2a 2n/ [29x] M Reason code (see SWIFT guidelines) optionally followed(for field 72) by a text description of the preceding reason code.or [44x] forfield 79)

Line 3 /MREF/ 16x M Sender’s reference i.e. field 20 of the original message(e.g. /MREF/RefBankB)

Line 4 /TREF/ 16x O Transaction reference i.e field 21 of the actual transaction,(MT 202)

Line 5 /CHGS/ 3a15n O ISO currency code and charges amount. This may contain relevant,levied reject/return charges, i.e. charges that have been applied tothe rejected/returned transaction (e.g. deducted from the returnedprincipal)

Line 6 /TEXT/ [29x] O some further narrative details(for field 72)or 44x forfield 79)

10.7 Return payments

Field 72: Sender to Receiver informationFormat: 6*35x (field 72) / 35*50x (field 79)

Definition: The field contains the reason forthe return/reject.


10.8 Queuing mechanisms

NCB Mechanism used in case of Credittemporary unavailability institutionsof NCB/ECB informed

BE Queued Yes

DK New payments cannot be input, Yesthose received before the incidentbut not processed are queued

DE New payments can be input, Yesand are queued (without debiting)until the stop sending is released.The RTGSplus participant has thepossibility to cancel these paymentsvia the information and controlsystem.

GR Queued Yes

ES Queued Yes

FR New payments cannot be input, Yesthose received before the incidentbut not processed are queued

IE Queued Yes

IT Queued Yes

LU New payments cannot be input Yes

NL Queued Yes

AT Queued Yes

PT Queued Yes

FI Queued Yes

SE Queued Yes

UK Queued Yes

10.9 TARGET – Processing inContingencies

10.9.1 TARGET components and potentialfailures

Regardless of the technical infrastructure inplace on the credit institutions’ side, or onthe central bank’s side, the following genericsystem diagram can be used to identify therelevant components and potential failurescenarios. Each of the components mentionedbelow can consist of several applications,which can run on several computers, locatedin different sites, etc. In this context, theword “component” should be understood asrepresenting a business function, rather thana technical component.

Based on this diagram, two main failurescenarios can be identified, namely the failureof a credit institution’s component or thefailure of one of the TARGET components.Within the latter, it is appropriate todistinguish three sub-scenarios: a failureof either the RTGS communicationcomponent, or the RTGS/Interlinkingprocessing component, or the Interlinkingcommunication component.

The next paragraph will describe in generalterms what the business requirements forthe relevant contingency procedures should

• Validation of payments• Liquidity management• Accounting• Generation of payment instructions

• Transmission of payment instructions• (Printout)

• Transmission of payment instructions• (Printout)

• Validation of payments• Check availability of funds• Accounting• Generation of payment instruction

*

* In some systems this is an indirect link via an Entrusted Third Party, e.g. using FIN-copy

Credit institution TARGET access point

Processingcomponent

Communicationcomponent

RTGSprocessingcomponent

RTGScommunication

component

InterlinkingcommunicationInterlinking

processing


look like. The requirements for failurescenario 2 (failure of a TARGET access point)are described in greater detail Section 10.9.3.

10.9.2 Scenario 1: failure of the creditinstitution component

As long as the credit institution’scommunication component is not affected, afailure of the credit institution’s infrastructureshould not have any direct impact onTARGET. However, payment instructions tobe submitted by the failing credit institutionare likely to be delayed (as normal/automaticprocessing would be affected), and theirnumber and volume might be limited, witha higher priority being given to the mosttime-critical transactions. In addition, sinceincoming payments continue to be creditednormally on the failing credit institution’scentral bank account, liquidity might beblocked, reducing the payment capacity forits counterparts.

In case the communication channel is (also)unavailable, the pre-agreed domesticcontingency channel will have to be used,which may have an operational impact on thelocal RTGS system.

In any event, the credit institution would needto be able to:

• select time-critical payments;

• transmit these time-critical payments toits RTGS system or instruct anotherinstitution to make the payments on itsbehalf;

• authorise the RTGS system operator tomake liquidity transfers to counterparts inthe case of major liquidity imbalances;

In addition, these functions should beembedded in a framework that allows forswift and efficient decision-making andinformation exchanges with the RTGS systemoperator.

10.9.3 Scenario 2: Failure of a TARGETaccess point

In the subsequent paragraphs, three sub-scenarios are described, related to failureson the NCB’s/ECB’s side. As for scenario 1,the arrangements in place can only workproperly if the communication and decision-making structure, as described in Section 5.4,is applied consistently. The time when afailure occurs will principally dictate whichcontingency arrangements will be activated,and what technical means will be utilised,when one of the following circumstancesoccurs. The choice of contingency procedurewill also depend on the range of contingencyprocedures a NCB has available.

In addition, it is of utmost importance thatskilled and well-trained staff is available andthat the possible contingency procedures areclearly documented, both on an operationaland on a technical level, and that they areverified regularly, in situations as close toreality as possible.

Scenario 2.1: failure of the RTGScommunication component (includingthe domestic network)

In order to cope with a failure of the RTGScommunication component, secure alternativecommunication channels are put in place atthe local level, in order to allow for thetransmission of critical payments to the RTGSsystems. Since the RTGS system operators,in co-operation with their bankingcommunity, have a considerable degree ofdiscretion – within the framework of theTARGET security requirements – as to whichchannel(s) to use, these alternativecommunication means are not harmonised.

Scenario 2.2: failure of the RTGS/Interlinking processing component

Each NCB has a (automated or manual)contingency processing mechanism in place toensure the following business functions:selection and validation of critical paymentinstructions (as a minimum CLS and EBA related


payments), checking funds availability37, updatingaccount balances (with new messages sent/received) and sending out the relevant paymentrelated messages. The extent to which thisprocessing mechanism is automated, as well asthe technical routing mechanism to/from theappropriate communication channels, is thesole responsibility of each NCB/the ECB.Analogously, it is the responsibility of each NCB/the ECB to ensure that its contingencyprocessing mechanism has sufficient capacity tohandle the required number of time-criticalpayments.

A more detailed explanation of thecontingency procedures that can be activatedat cross border level is given in Annex 10.10.

Scenario 2.3: failure of the Interlinkingcommunication component (includingthe Interlinking network)

In this case, as explained in Annex 1, the onlyTARGET contingency method applicable is themechanism of contingency via correspondentaccounts (CoCA mechanism). It is based on anarrangement whereby the failing NCB (theservice user) uses a normal correspondentaccount relationship (as opposed to the specificTARGET accounts) with one other non-failingNCB (the service provider).

Service users and service providers agreebilaterally on the communication means theyintend to use in the case of unavailability of theSWIFT service on the service user’s side;therefore, a variety of communication means iscurrently in place. Depending on the domesticarrangements, and in addition to the volumerestrictions, this might also have an operationalimpact on the RTGS participants.

10.10 TARGET contingencyprocedures

10.10.1 General overview of contingencyprocessing

A crucial element when activating contingencymechanisms is the availability of accurate

account balances, either from (a copy of) thedatabase, or by using an account balancerebuilding mechanism.

Once the balances are known, the strickenNCB/ECB can start selecting which paymentswill be performed in contingency. In somecases (as described in 5.2) this selection isobvious based on the systemic importance ofthe payments involved. In other cases, anagreement will have to be found between theNCB/ECB and the users in order to definethe best way forward, taking into accountthe constraints involved.

Once the identification process has beenfinalised, the failed NCB/ECB needs to decidehow the payments (incoming or outgoing)will be processed. There are two possibilitiesat present:

• either the payment instructions (in bothways) are received/submitted “directly” toTARGET, or

• the NCB/ECB uses another NCB/ECB asan intermediary in the process (acting as amere customer of the chosen NCB/ECB).

The first option is known as the “Interlinkingcontingency” and the second as the “CoCA”mechanism (“contingency using correspondentaccounts”, due to its similarity to thecorrespondent banking procedures38).

10.10.2 “Interlinking contingency”

If this alternative is followed, the failed NCB/ECB will submit its instructions to TARGETby sending correctly formatted messagesdirectly from the CBT. As the SWIFT

37 This function can only be performed if accurate account balancesare available, or if additional payment capacity is made availableduring contingency processing, e.g. by processing incomingTARGET funds, by granting additional intra-day credit, etc.

38 In this context the notion “correspondent accounts” is usedas opposed to the “interlinking accounts”. Both are heldbetween – and impact – NCBs only. Whereas interlinkingaccounts can only be accessed using specific interlinking paymentmessages, the “normal” correspondent accounts can be usedupon reception of a variety of payment instruction, MT202,authenticated fax, Cebamail, and fax with bilateral teleconferencecall.


network is supposed to be available, “normal”TARGET messages will be forwarded to thereceiving NCBs/ECB for further processing.

On the non-failing side, some constraints insending payments might be faced as mostprobably a “stop sending” to the failing NCB/ECB will be implemented by the other NCBs/ECB as a matter of precaution. If somespecific payments have nevertheless to besent (such as EBA or CLS-related payments),an ad-hoc arrangement will need to be madein order to enable the failed NCB/ECB toreceive those payments.

At the same time, the failed NCB/ECB has toreflect the relevant account entries in a parallel“system” (normally, a simple tool to reflectdebits/credits if, in fact, the RTGS accountsmanagement system is down) and to check onthe CBT if the payments have been completed(as this implies the reception of certain messagetypes). The ordering institutions have then tobe informed accordingly (either by normal orvia alternative means).

10.10.3 “Contingency using CorrespondentAccounts” (CoCA)

Under the CoCA mechanism, each NCB/ECBuses a correspondent account in the booksof the ECB/other NCBs acting as serviceproviders, in order to process paymentsdirectly as a customer of those serviceproviders. Under this scheme, the failingNCB/ECB submits its critical transactions viathe correspondent account after the relatedaccount entries have been made in its books(i.e. the credit institution has been debitedand the mirror correspondent account hasbeen credited). The payments are thenexecuted by the service provider in TARGET(normal processing is possible between theservice provider and the non-failed NCBs/ECB, as both are operational). Incoming fundscan also be received through thesecorrespondent accounts.

The communication of the paymentinstructions between the failing NCB and theservice provider will be made either viaSWIFT (if available) or via alternative (andsecure) communication channels.39 Thenormal requirements concerning security,non-repudiation and confidentiality, as definedfor TARGET, will be applicable to thecorrespondent banking services.

The use of this scheme is subject to clearrules concerning pre-advice of payments andvolume limitations, as manual processing willbe necessary in many cases.

10.10.4 Resuming normal operations

In both cases, as soon as the normal businessenvironment is operational again, the accountbalances between the two environments haveto be synchronised. This can be done bymaking one adjustment booking per account,in order to be able to restart normalprocessing as soon as possible. The transferof the individual contingency transactionsto the normal environment (and theneutralisation of the adjustment bookings) canthen be carried out after the payment systemhas closed (before the account statementsare sent out to the participants/customers).In case sufficient time is available during thebusiness day, the individual contingencytransactions can be transferred immediatelyto the normal environment. Before normalprocessing restarts, the failing NCB/ECB willtry to prevent any double processing ofpayment instructions (that have already beenprocessed in contingency)40, by carefullymanaging the instructions that are queuedand will be processed by the RTGS systemonce it is restarted.

39 CoCA procedures will have to be used if the SWIFT network isunavailable, but they can also be used if the RTGS system isdown and the network is still available. The decision to use oneor the other rests wholly with the failed NCB/ECB.

40 This will depend on the circumstances (time, in which part of thesystem the payment is queued).


10.11 Explanatory Memorandum onThe RecommendationsConcerning CLS Paymentsin Euro

10.11.1 Introduction

CLS Bank (CLSB) provides global multi-currencysettlement services for foreign exchangetransactions (FX transactions), using a paymentversus payment (PVP) mechanism (i.e. onecurrency leg is settled if, and only if, the leg inthe other currency is also settled). Settlementin the CLSB’s books will start immediately whenTARGET opens. The funding of its settlementmembers’ short positions is fixed to certaindeadlines. The CLSB intends to pay out suchreceipts to its settlement members with longpositions in the relevant currencies as soon aspossible. By 10 a.m. CET, the short positions ofthe settlement members in the “Far Eastcurrencies” (e.g. Japan, Australia) should becompletely funded and short positions in othercurrencies should be sufficiently funded, so thatall payments in AUD or JPY could be executedby the CLSB. This is essential since the RTGSsystems in those countries close shortly after10 a.m. CET under normal circumstances. Forthe European and the American currenciesthere is some leeway to fund short positionscompletely (and, accordingly, for the CLSB topay out long balances) until 12 noon CET (orlater, if need be).

The CLSB has an account with the EuropeanCentral Bank (ECB) and processes all europayments via the ECB payment mechanism(EPM). Therefore, short banks pay in favourof their account with the CLSB via TARGET/EPM. Long banks are paid from this account.If CLS-related payments cannot be made intime, it is likely that trades will not settle andthat long positions will not be paid out by theCLSB. Consequently, this could createliquidity imbalances in the affected systemsand entail serious liquidity risks, which mightbe particularly severe for Japan andAustralia.41 Depending on the size of failedtransactions, it may even affect the stabilityof the markets.

10.11.2 TARGET contingency andCLS-related payments

Considerable efforts have been undertakento analyse and manage the risk ofunavailability of the various TARGETcomponents. All national central banks(NCBs) participating in TARGET and the ECBhave taken preventive measures to ensurebusiness continuity. The central idea toensure the achievement of this goal consistsof duplicating as much as possible thetechnical infrastructure, including the datacommunication channels, interfaces, datastorage and processing facilities. However,due to the time-criticality of a limited numberof payments, e.g. CLS-related payments, thetime needed to switch over to a secondaryIT component may be considered too long.In order to avoid systemic risk, alternativecontingency mechanisms aimed at processinga limited number of time-critical paymentshave been implemented in each NCB and theECB.

However, it must be recognised that thesefailure arrangements can only meet theobjectives they are designed for if they areembedded in a framework of sound businesspractices. Therefore, in order to ensure thatthese measures will be operationally effective,especially in terms of the time needed fordecision-making and activation, a set of“recommendations” for CLS-related paymentshas been proposed by the Eurosystem. Thismemorandum provides the background forthese recommendations, explains therationale behind them and describes theirscope, as well as the pre-conditions, whererelevant, for them to be applied.

41 It may be possible to ask Far East RTGS systems to stay openlonger. However, this should not be considered an option fornormal processing but should be kept in reserve in case of adisaster.


10.11.3 The general framework forCLS-related payments

Systemically important payments

Apart from CLS-related payments, there areseveral types of systemically importantpayments, e.g. payments to be settled bydomestic (net) settlement systems, whichmight be equally important. There is,however, a difference of possible impact:when the CLS pay-in deadlines for the eurocannot be met due to a TARGET failure, thishas implications for other currency zones,which will not be the case for the othertypes of payments, given their “domestic”(euro area) nature. This certainly cannot beignored (in the CLS context) and, therefore,CLS pay-ins should always be given highpriority in a contingency situation.

For similar reasons, it would seem logical tohandle pay-ins with a higher priority thanpay-outs. Indeed, all pay-ins should beconsidered equally critical, irrespective of theamount involved, because of the possibleknock-on effects on the efficiency of thesettlement process. The shortage of euroresulting from the non-fulfilment of therequired pay-ins blocks the settlementprocess and may delay or prevent pay-outs inother currencies. In addition, it will triggerthe activation of the CLSB’s emergencyprocedures (i.e. revised pay-in calls).Ultimately, this may require recourse toliquidity providers, which may have to step into allow the CLSB to complete the pay-out ina currency, the RTGS system of which isabout to close. On the other hand, thecriticality of pay-outs in terms of systemicrisk tends to decrease along with the amountinvolved. Delays in the pay-out phase willcertainly have liquidity implications for thelong banks, but these implications will onlyhave a significant systemic impact if the valueof the receivable funds prevents the banksconcerned from making other importantpayments, which may, in turn, haveimplications for other banks, etc. In addition,the pay-outs in euro are less time critical,since the time available for processing them

is much longer than for Asian/Pacificcurrencies.

Serial integration of several links

The complete processing chain of CLS-relatedpayments consists of several links. First of all,the CLSB has to issue a final pay-in schedule.Upon receipt of this schedule, the CLSBsettlement members prepare and sendpayment instructions either directly to theRTGS systems concerned or via their nostroagents. In the case of euro payments, thereceiving NCB processes the paymentinstruction and generates a TARGET paymentinstruction for the ECB, which processes thisrequest and sends the credit advice to theCLSB.

In such a serial mechanism, it is clear thatdelays built up in the first stages of theprocess reduce the ability of subsequentparties to meet the deadline if one of themhas to revert to contingency measures.

CLS settlement schedule

The settlement scheme for the euro followsthe operational time line described below:

• Although a preliminary payment schedulefor the pay-ins is sent to the settlementmembers at midnight, the final pay-inschedule is only sent to the settlementmembers at 6.30 a.m.42

• Settlement in the CLSB starts at 7 a.m.

• There are five consecutive pay-in deadlinesscheduled, the first one being at 8 a.m.,with the others following at hourlyintervals until 12 noon.

• Based on the above-mentioned schedule,the shortest (and earliest) lead time forthe preparation and normal settlement ofpay-ins is 90 minutes; this is the timebetween the receipt of the final pay-inschedule (6.30 a.m.) and the first pay-indeadline (8 a.m.).

42 The times are always given in CET, unless stated otherwise.


10.11.4 Recommendations for CLS-relatedpayments

Against the background of the frameworkdescribed above, it should be recognised thatthe following considerations can be a validoperational basis to increase the probabilityof CLS-related euro payments beingprocessed within the required deadlines.However, it is important to stress that,whatever the implementation nature of theserecommendations at the local level may be,the main approach towards processing time-critical payments should be supported by aco-operative attitude among all partiesinvolved, i.e. settlement members, nostroagents, the CLSB, the NCBs and the ECB. Inorder for this attitude to be sustained on along-term basis, normal operations, as wellas failure situations, should be guided by thislogic, with the main objective being toestablish settlement arrangements in aconstructive manner.

Introduction of “grace periods”

The idea to introduce a so-called “graceperiod” is presented in order to reduce therisk of late CLS-related payments due totechnical failures. It consists of creating anadditional time window that is left forsubsequent intermediaries in a payment chaindue to the fact that the previous (or first)payment leg was processed before theultimate deadline. As already mentioned, CLS-related payments are highly time criticalpayments. The CLSB requires “timely”payments every full hour. Even in an RTGScontext, it cannot be assumed that paymentsissued by the credit institutions can alwaysbe processed within seconds.

On the other hand, nor is it conceivable torequest the credit institutions to process allpayments related to the CLSB at 7 a.m. inorder to eliminate the risk of possibletechnical failures. Between both extremes, abusiness practice for all the parties involvedshould be elaborated43. One basic feature ofcommon business practices is the agreementon a payment schedule, which would give all

43 This would include nostro agents.44 Lead time for the preparation and normal settlement of

payments.

parties involved scope to activate contingencyprocedures. Based on the shortest lead timeof 90 minutes44, the schedule might look asfollows:

• 6.30 a.m. – receipt of final pay-in scheduleby the settlement members;

• 7.15 a.m. – receipt of CLS-related paymentinstructions by the local NCB;

• 7.30 a.m. – receipt of CLS-relatedpayments by the ECB;

• 7.45 a.m. – credit advice sent to the CLSBupon crediting of its account at the ECB.

When one of the above-mentioned deadlinesis not met, this should trigger a decision-making process with a view to activatingcontingency procedures.

Reduce the number of pay-ins

Banks should be prepared, in the case of apayment system failure, to accelerate theirpay-ins (using contingency processing) and toreduce the number of payments needed tocomplete their funding, in order to ensurethe timely settlement of their transactions, asthe duration of the failure is normally notknown. This would be of considerable help inthe event of contingency procedures beingactivated, as it could solve the possiblecapacity constraints that manual or semi-automated contingency procedures wouldnaturally entail. Ideally, once contingency isinvoked, banks should be ready to send allremaining pay-ins in one payment.

However, this could have liquidityimplications for banks. Therefore, it isimportant to find a balance between liquidityimplications and operational convenience.

A valid compromise might be to pay in theamount for the first deadline as soon aspossible, according to the above-mentioned


45 Therefore, the credit institution should re-submit the sameinstruction to the local RTGS system (in line with item 5.3), whilethe aggregation of the remaining payments (for other deadlines)should be part of a new payment instruction.

schedule, and to aggregate the remainingamounts as much as possible, so that, forinstance, all pay-ins are completed by the“settlement completion target time” (9 a.m.),with only two or three payments. Thiscompromise is based on the assumption thatthe first two deadlines are the mostimportant ones in terms of pay-in obligation,whereas the subsequent ones are presumedto have a substantially lower impact in termsof liquidity.

In order to enable the ECB and the NCBs tomonitor the payment flow during acontingency situation and to react promptlyin the case of pay-in delays, it is seen asextremely useful for the ECB/NCBs to knowwhich banks have to pay in which amounts tothe CLSB, by which time.

“Double” payments

If the CLSB does not receive the expectedfunds and if the ECB/NCB concerned cannotidentify the related payment instruction(s)due to a failure, it should be acceptable forthe credit institution concerned, in order tocater for timely payment, to send a copy ofthe payment details to the local RTGS systemimmediately (if the account has been debited)or to re-submit the payment instruction itself(using either the normal or the alternativecommunication channel, as bilaterally agreedwith the NCB). In the latter case, later pay-inobligations should not be added to thepayment instruction that is due for re-submission.45

However, the request for a payment re-submission can only be considered reasonableafter the following measures have been taken:

• thorough attempts to locate the initialpayment instruction; and

• neutralisation of the initial paymentinstruction so as to prevent doubleprocessing.

It should be clear that the failing entity,irrespective of whether it is a credit

institution, an NCB or the ECB, must take allnecessary precautions in order to minimisethe risk of double processing payments.

No matter which preventive measures aretaken, however, there will always be aresidual risk that, when a failing system isrestarted, “hidden” payments are released,potentially causing “double” payments(assuming that some of these payments werealready performed in contingency).

When the CLSB receives a “double” paymentit will not reject it and will normally processit as a regular pay-in. However, although theCLSB has no validation mechanism in placeto identify double payments, it automaticallypays back the liquidity in excess of the totalaccumulated pay-in obligation in the next pay-out round (shortly after the next hourly pay-in deadline at the latest), subject to theoverall positive account value rule. In anyevent, unless exceptional situations occur, theCLSB will have completed the final pay-outphase shortly after 12 noon.

Alternative access points to TARGET

Since most settlement members have accessto alternative payment channels, the idea ofusing these channels for time-criticalpayments in the case of a failure at thesettlement member/nostro agent concernedhas been raised with the credit institutions.

However, the use of alternative paymentchannels cannot be viewed in isolation fromthe “payment capacity” problem. In addition,it is not realistic to assume that all creditinstitutions will be able simply to re-routetheir critical payments to an alternative accesspoint in the event of a failure. The use ofalternative payment channels may also triggerother problems e.g. the risk of “double”payments, receipt of incoming funds, etc.


Although the use of an alternative accesspoint, either through an own branch (orsubsidiary) or through a “nostro agent” (inthe euro area), is seen primarily as acontingency arrangement for severe failuresin the credit institutions’ infrastructure, itmay also be considered the “solution of lastresort” if a TARGET component fails. Underthese circumstances, the NCB concernedshould be able to make at least one “capacitypayment” to the relevant alternative TARGETcomponent(s).

10.12 Settlement times for ancillarysystems settling in TARGET

The table overleaf gives a timetable of thesettlement of the ancillary systems (domesticnetting, FOREX, SSS) settling via TARGET.All these systems settle in euro.


Las

t upd

ate:

17

June

200

3

An

nex

10

.12

Sett

lem

ent t

imes

of s

yste

ms

affe

ctin

g T

AR

GE

T s

ettl

emen

t

Syst

emIS

ON

ame

settl

emen

t tim

e

06:30

07:00

07:30

08:00

08:15

08:30

08:45

09:00

09:30

09:45

10:00

10:15

10:30

11:00

11:15

11:30

11:45

12:00

12:30

12:45

13:00

13:30

14:00

14:15

14:30

14:45

15:00

15:15

15:30

15:45

15:50

16:00

16:15

16:30

16:45

17:00

17:30

18:00

18:30

19:00

SSS

AT

DS/

WSB

18

:00

XX

XX

X

LV

AR

SB

EC

EC

15:3

0

X

LV

AR

SB

E

Cle

arin

g H

ouse

of

B. (

excl

. C

EC

)15

:30

X

SSS

BE

Secu

ritie

s C

lear

ing

Syst

em o

f th

e N

BB

16:3

0X

XX

XX

XX

X

SSS

BE

Eur

onex

t/Eur

ocle

ar F

MS

(net

)06

:30

to 1

4:00

XX

XX

XX

X

SSS

BE

Eur

onex

t/Eur

ocle

ar E

MSS

(g

ross

)06

:30

to 1

5:00

XX

XX

XX

XX

XX

XX

XX

XX

XX

SSS

DE

Cle

arst

ream

Ban

king

AG

. Fr

ankf

urt

10:3

0/11

:15

and

betw

een

13:0

0/14

:00

XX

XX

XX

LV

SD

K

Inqu

iry

and

tran

sfer

sys

tem

K

RO

NO

S7:

00 to

18:

00X

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

X

RS

DK

DN

Ret

ail c

lear

ing

in E

UR

9:00

X

SSS

DK

Dan

ish

Secu

ritie

s C

entr

e

8:45

/11:

30/

13:0

0

X

X

X

CE

S

FUT

UR

OS

S/ C

ITR

ICO

S Y

M

ER

CA

DE

RIA

S D

E

VA

LE

NC

IA, C

omm

oditi

es

Mar

ket C

lear

ing

8:15

X

DE

SM

EFF

9:

00X

SSS

ES

SCL

V-L

AT

IBE

X11

:15

X

SSS

ES

VA

LE

NC

IA S

tock

Exc

hang

e C

lear

ing

9:45

X

LV

SE

SSP

I, M

adri

d C

lear

ing

Hou

se16

:10

X

RS

ES

SNC

E11

:30

X

SSS

ES

SCL

V10

:00

X

SSS

ES

CA

DE

8:00

to 1

7:00

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

X

SSS

ES

BA

RC

EL

ON

A S

tock

Exc

hang

e C

lear

ing

10:3

0X

LV

SE

UC

LS

sett

lem

ent

7:00

to

13:0

0X

XX

XX

XX

XX

XX

XX

XX

XX

XX

X

LV

SE

U

Eur

o1 C

lear

ing

and

Settl

emen

t Sy

stem

16:0

0X

LV

AR

SFI

The

Ban

ks' C

lear

ing

Syst

em14

:30

X


Las

t upd

ate:

17

June

200

3

An

nex

10

.12

(co

nt’

)Se

ttle

men

t tim

es o

f sys

tem

s af

fect

ing

TA

RG

ET

set

tlem

ent

Syst

emIS

ON

ame

settl

emen

t tim

e

06:30

07:00

07:30

08:00

08:15

08:30

08:45

09:00

09:30

09:45

10:00

10:15

10:30

11:00

11:15

11:30

11:45

12:00

12:30

12:45

13:00

13:30

14:00

14:15

14:30

14:45

15:00

15:15

15:30

15:45

15:50

16:00

16:15

16:30

16:45

17:00

17:30

18:00

18:30

19:00

LV

SFI

BO

F Sy

stem

7:00

to 1

8:00

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

X

LV

SFI

POPS

cle

arin

g7:

00 to

15:

30X

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

X

mor

eFI

HM

MC

7:00

to 1

8:00

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

X

SSS

FIK

AT

I (p

ay-i

n)9:

30X

SSS

FIK

AT

I (p

ay-o

ut)

13:3

0X

RS

FIPM

J N

IGH

T c

lear

ing

00:0

0 to

02:

00

RS

FIPM

J da

y cl

eari

ng14

:45

X

NSS

FRPN

S16

:10

X

RS

FR

Inte

rban

k T

elec

lear

ing

Syst

em

(SIT

)15

:10

X

SSS

FRR

EL

IT

11:0

0/15

:25/

17:0

5X

X

X

SSS

FRR

GV

11:0

0/15

:20/

16:3

0/17

:45

XX

X

X

SSS

FRE

uron

ext/C

lear

net s

yste

ms

7:00

/10:

00X

LV

AR

SG

RA

then

s C

lear

ing

Off

ice

15:4

5X

RS

GR

DIA

S SA

16:0

0X

SSS

GR

Secu

ritie

Cle

arin

g Sy

stem

15:3

0X

LV

SG

RH

ER

ME

S -

dom

estic

7:00

to 1

8:00

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

X

LV

SIE

Spec

ial P

rese

ntat

ions

16:0

0 to

16:

30X

XX

RS

IED

ublin

Ban

kers

' Cle

arin

g15

:00

to 1

7:00

XX

XX

XX

XX

XX

LV

AR

SIT

Loc

al C

lear

ing

13:3

0X

LV

SIT

BIR

/ B

OE

7:00

to 1

7:00

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

X

LV

SIT

GE

C7:

00 to

18:

00X

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

LV

SIT

MID

7:00

to 1

8:00

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

X

LV

SIT

Inte

rban

k tr

ansf

er7:

00 to

18:

00X

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

RS

ITR

etai

l sub

-sys

tem

12:0

0X

SNSS

ITL

DT

- L

iqui

dazi

one

dei T

itoli

12:3

0X


Las

t upd

ate:

17

June

200

3

An

nex

10

.12

(co

nt’

)Se

ttle

men

t tim

es o

f sys

tem

s af

fect

ing

TA

RG

ET

set

tlem

ent

Syst

emIS

ON

ame

settl

emen

t tim

e

06:30

07:00

07:30

08:00

08:15

08:30

08:45

09:00

09:30

09:45

10:00

10:15

10:30

11:00

11:15

11:30

11:45

12:00

12:30

12:45

13:00

13:30

14:00

14:15

14:30

14:45

15:00

15:15

15:30

15:45

15:50

16:00

16:15

16:30

16:45

17:00

17:30

18:00

18:30

19:00

LV

AR

SL

UC

lear

ing

Hou

se

7:30

/10:

00/1

2:00

/14:

00/1

6:00

XX

XX

X

NSS

NL

Secu

ritie

s C

lear

ing

10:0

0X

RS

NL

Urg

ent P

aym

ents

(In

terp

ay)

16:3

0X

RS

NL

Mas

s Pa

ymen

ts (

Inte

rpay

) 11

:00

X

SSS

NL

Nec

igef

/Cle

arin

g In

stitu

tion

12:0

0X

SSS

NL

EO

C10

:00

X

NSS

PTA

TM

/ PO

S (S

ICO

I)10

:30

X

NSS

PTB

ill o

f ex

chan

ge (

SIC

OI)

10:3

0X

NSS

PTC

hequ

es (

SIC

OI)

10:3

0X

NSS

PTT

EI

(SIC

OI)

10:3

0X

NSS

PTD

irec

t Deb

its (

SIC

OI)

10:3

0X

NSS

PTT

EI

Cro

ss b

orde

r (S

ICO

I)16

:00

X

NSS

PTE

uron

ext L

isbo

n 1

10:3

0X

SSS

PTIn

terb

olsa

13:3

0X

SSS

PTE

uron

ext L

isbo

n 2

13:3

0X

SSS

PTE

uron

ext L

isbo

n / S

Lrt

09:3

0 to

17:

30X

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

LV

SPT

SIT

EM

E08

:00

to 1

8:30

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

mor

eSE

VPC

- C

entr

al S

ecur

ities

D

epos

itory

12:4

5X

RS

SEB

ank

Gir

o Sy

stem

12:3

0X

SSS

SEO

M S

tock

holm

AB

11:4

5X

UK

EC

HO

LV

SU

KC

HA

PS e

uro

7:00

to 1

6:45

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

XX

NSS

UK

CR

EST

17:0

0X

RS

UK

BA

CS

(e)

10:3

0X

RS

UK

Che

que

and

Cre

dit C

lear

ings

(e)

13:0

0X

SSS

UK

CG

O -

Cen

tral

Gilt

s O

ffic

e17

:45

X

SSS

UK

CM

O -

Cen

tral

Mon

eym

arke

t O

ffic

e17

:45

X


10.13 Mapping of Domestic Messagesto and from the InterlinkingFormat

The information given in the table overleaf isintended as a guide only. It is subject tochange without prior notice and is notbinding. It is given here to assist creditinstitutions in their bilateral contacts.


1 National Bank van België/Banque Nationale de Belgique

1.1 Rules for conversion from national RTGS format to interlinking format

1.1.1 MT100

Field

20

32A

50

52A

56A

57A

59

70

71A

72

Description

Transaction ReferenceNumber of Sending CreditInstitution

Value dateCurrency codeAmount

Ordering Customer

Ordering Institution

Intermediary

Account with Institution

Beneficiary Customer

Details of Payment

Details of Charges

Sender to Receiver Information

�

Mapping rules

Unchanged

Unchanged

Unchanged

Mandatory. Unchanged ifpresent in the incoming message.Otherwise the BIC of the sender.

If the field contains the TARGETBIC (TG) of a NCB, this field isremoved. Otherwise, unchanged.

Unchanged

Unchanged

Unchanged

Unchanged

Optional. Some nationalinformation is suppressed. Theidentification of the intermediaryindirect participant (six firstdigit of the BIC) remainsunchanged if present, but thecode word is replaced by /INS/.The other lines in the incomingmessage remain unchanged. Ifthe sending direct participant isnot the ordering institution (field52 is filled in with a BIC differentfrom the sender), the BIC of thisparticipant is added after thecode word /INS/ only if at leastone line is free.

National RTGS

Field Description



Ordering Customer

Optional

Intermediary. Optional

Account with Institution.Mandatory.

Beneficiary Customer. Mandatory.

Details of Payment. Optional.

Details of Charges. Optional.

Optional. It may contain, amongother things, national code wordsused in the context of the nationalTarget system (e.g. messagepriority code, identification ofindirect participant when notordering institution, etc.).

Interlinking MT198


Field

119

13C

20

23B

23E

26T

32A

33B

36

50Kor A

52A

56A

57A

59or 59A

70

71A

71F

71G

72

77B

Description

STP Flag

Time Indication

Transaction ReferenceNumber of SendingCredit Institution

Bank Operation Code

Instruction Code

Transaction Type Code


Currency/InstructedAmount

Exchange Rate

Ordering Customer


Intermediary Institution



Remittance Information

Details of Charges

Sender’s Charges

Receiver’s Charges


Regulatory Reporting

�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged



Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged


Unchanged

National RTGS

Field Description

STP Flag

Time indication optional


Bank Operation Code

Instruction Code



Currency codeAmount

Exchange Rate

Ordering Customer Mandatory

Ordering Institution Optional

Intermediary Institution Optional

Account with Institution Mandatory

Beneficiary Customer Mandatory

Remittance Information Optional

Details of Charges Mandatory

Sender’s Charges Optional

Receiver’s Charges Optional



Interlinking MT198

1.1.2 MT103(+)


Field

20

21

13C

32A

52A

56A

57A

58A

72

Description


Related Reference

Time Indication



Intermediary


Beneficiary Institution


�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged




Unchanged


National RTGS

Field Description


Related Reference

Time Indication optional


Optional

Intermediary. Optional.

Account with Institution. Optional.

Beneficiary Institution. Mandatory.

Optional. It may contain, amongother things, national code wordsused in the context of the nationalTarget system (e.g. messagepriority code, identification ofindirect participant when notordering institution, etc.).

Interlinking MT198

1.1.3 MT202


Field

913

20

32A

50

52A

56A

57A

59

70

71A

72

Description

Time stamp



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

see field 72

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged if different from theBIC of the direct participantidentified as the receiver, else thefield disappears


Unchanged

Unchanged

Unchanged

The lines present in theInterlinking incoming messageremain unchanged.The debittimestamp (incoming field 913) isadded after the code word /SNDTIME/ only if at least oneline is free.The BIC ‘NBBEBETG’ is addedafter the code word /REC/PART/only if at least one line is free.

National RTGS

Field Description



Ordering Customer


Intermediary



Details of Payment

Details of Charges


Interlinking MT198

1.2 Rules for conversion from interlinking format to national RTGS format

1.2.1 MT100


1.2.2 MT103(+)

Field

119

913

13C

20

23B

23E

26T

32A

33B

36

50Kor 50A

52A

56A

57A

59or 59A

70

71A

71F

71G

72

77B

Description

STP Flag

Time stamp

Time Indication


Bank Operation Code

Instruction Code


Amount

Currency/Instructed Amount

Exchange Rate

Ordering Customer






Details of Charges

Sender’s Charges




�

Mapping rules

Unchanged

See field 13C

Information is extracted fromfield 913 + credit time stampELLIPS

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged



Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

The lines present in theInterlinking incoming messageremain unchanged.The BIC‘NBBEBETG’ is added after thecode word /REC/PART/ only ifat least one line is free.

Unchanged

National RTGS

Field Description

STP Flag

Time Indication


Bank Operation Code

Instruction Code



Currency codeAmount

Exchange Rate

Ordering CustomerMandatory






Details of Charges

Sender’s Charges




Interlinking MT198


Field

913

20

21

13C

32A

52A

56A

57A

58A

72

Description

Time stamp


Related Reference

Time Indication



Intermediary




�

Mapping rules

See field 13C

Unchanged

Unchanged

Information is extracted fromfield 913 + credit time stampELLIPS

Unchanged

Unchanged

Unchanged if different from theBIC of the direct participantidentified as the receiver, else thefield disappears.

Unchanged if different from theBIC of the direct participantidentified as the receiver, else thefield disappears.

Unchanged

The lines present in theInterlinking incoming messageremain unchanged.The BIC‘NBBEBETG’ is added after thecode word /REC/PART/ only ifat least one line is free.

National RTGS

Field Description


Related Reference

Time Indication



Intermediary




Interlinking MT198

1.2.3 MT202

The PSMN is not mapped into a national message. The information of the PSMN is only used to update the status of a cross-border payment and/or to create a reimbursement. The participants can see the status of the PSMR in the cash managementapplication.

1.2.4 PSMN


2 Danmarks Nationalbank


2.1.1 MT100

Interlinking MT198 � National RTGS

Field Description Mapping rules (see our cover letter) Field Description

20 Transaction Reference Unchanged Transaction ReferenceNumber of Sending Number of SendingCredit Institution Credit Institution

32A Value date Unchanged Value dateCurrency code Currency codeAmount Amount

50 Ordering Customer Unchanged Ordering Customer

52A Ordering Institution Unchanged if present in incoming message. OptionalOtherwise the BIC of the sender

56A Intermediary Unchanged Intermediary

57A Account with Institution Unchanged Account with Institution

59 Beneficiary Customer Unchanged Beneficiary Customer

70 Details of Payment Unchanged Details of Payment

71A Details of Charges Unchanged Details of Charges

72 Sender to Receiver Information Unchanged Optional


2.1.2 MT103(+)

119 STP Flag Unchanged STP flag


23B Bank Operation Code Unchanged Bank Operation Code

23E Instruction Code Unchanged Instruction Code

26T Transaction Type Code Unchanged Transaction Type Code

32A Amount Unchanged Amount

33B Currency/Instructed Amount Unchanged Currency/Instructed Amount

36 Exchange Rate Unchanged Exchange Rate

50K Ordering Customer Unchanged Ordering Customer

50A Ordering Customer Unchanged Ordering Customer

52A Ordering Institution Unchanged if present in incoming message. Ordering InstitutionOtherwise the BIC of the sender

56A Intermediary Institution Unchanged if present Intermediary Institution



59A Beneficiary Customer Unchanged Beneficiary Customer

70 Remittance Information Unchanged Remittance Information


71F Sender’s Charges Unchanged Sender’s Charges

71G Receiver’s Charges Unchanged Receiver’s Charges

72 Sender to Receiver Information Unchanged Sender to Receiver Information

77B Regulatory Reporting Regulatory Reporting Unchanged


Field Description Mapping rules Field Description


2.1.3 MT202


21 Related Reference Unchanged Related Reference


52A Ordering Institution Unchanged if present. Ordering InstitutionOtherwise the BIC of the sender is added.

56A Intermediary Unchanged if present. Intermediary

57A Account with Institution Unchanged if present. Intermediary

58A Beneficiary Institution Unchanged Beneficiary Institution

72 Sender to Receiver Information Unchanged if present. Sender to Receiver Information





2.2.1 MT100

913 Time stamp A unique TRN is created Transaction ReferenceNumber of SendingCredit Institution in this caseDanmarks Nationalbank

20 Transaction Reference Unchanged Value dateNumber of Sending Currency codeCredit Institution Amount

32A Value date Unchanged Ordering CustomerCurrency codeAmount

50 Ordering Customer Unchanged Ordering Institution

52A Ordering Institution Unchanged Intermediary

56A Intermediary Unchanged Account with Institution

57A Account with Institution Unchanged Beneficiary Customer

59 Beneficiary Customer Unchanged Details of Payment

70 Details of Payment Unchanged Details of Charges

71A Details of Charges Unchanged

72 Sender to Receiver Information The lines remain unchanged. Sender to Receiver InformationThe following two lines are added. If thereis’nt space for these, they are not added:Line 1: /REC/EUR/‘amount’ from field 32Ais inserted for currency statistic purposes.Line 2: //U is inserted for currency statisticpurposes.




2.2.2 MT103(+)



119 STP Flag

913 Time stamp A unique TRN is created

20 Transaction Reference Unchanged TRN of Sending CreditNumber of Sending InstitutionCredit Institution









52A Ordering Institution Unchanged Ordering Institution

56A Intermediary Institution Unchanged Intermediary Institution








72 Sender to Receiver Information The lines remains unchanged.The following two lines are added. If there isnot any space for these, they are not added:Line 1: /REC/EUR/‘amount’ from field 32Ais inserted for currency statistic purposes.Line 2: //U is inserted for currency statisticpurposes.

77B Regulatory Reporting Unchanged Regulatory Reporting


2.2.3 MT202

2.2.4 PSMN

913 Time stamp A unique TRN is created Transaction ReferenceNumber of Sending CreditInstitution in this caseDanmarks Nationalbank

20 Transaction Reference Field 20 from original payment message is Related ReferenceNumber of Sending insertedCredit Institution

21 Related Reference Unchanged Value dateAmount Currency code

32A Value date Unchanged Ordering InstitutionCurrency codeAmount

52A Ordering Institution Unchanged Intermediary

56A Intermediary Unchanged Account with Institution

57A Account with Institution Unchanged Beneficiary Institution

58A Beneficiary Institution Unchanged Sender to Receiver Information

72 Sender to Receiver Information



900 Interlinking Internal Reference Unchanged Interlinking Internal Reference

913 Time stamp Unchanged Time stamp

901 Referred Interlinking Unchanged Referred Interlinking InternalInternal Reference Reference

910 ECB date and time of receipt Unchanged ECB date and time of receipt

990 Acceptance code Unchanged Acceptance code

991 Reason code for rejection Unchanged Reason code for rejection

72 Sender to Receiver Information Unchanged to Central Bank. The field is Sender to Receiver Informationnot passed on to national participantin any cases

Interlinking MT198/110 � National RTGS



3 Deutsche Bundesbank


3.1.1 MT100






52A Ordering Institution Account number line1 Ordering InstitutionSecond line (BIC) unchanged







1 The account number line of field 52 will be filled by the Bundesbank as sending NCB as follows: prefix“//TA” (positions 1-4);ISO country code of the sending central bank (positions 5-6; e.g. “DE”);BIC of the submitting institution (positions 7-17; 8-figure BICs will be padded with “XXX” to 11 positions);TRN of the submitting institution (from position 18; max. 16 positions).


3.1.2 MT103(+)

119 STP Flag Payment Type Flag of the national format is Payment Type Flagshifted to field 119 of the Interlinking message

13c Time Indication Unchanged Time Indication










52A Ordering Institution Account number line1 Ordering InstitutionSecond Line (BIC) unchanged















3.1.3 MT202

13c Time Indication Unchanged Time Indication




52A Ordering Institution Account number line1 Ordering InstitutionSecond line (BIC) unchanged







1 The account number line of field 52 will be filled by the Bundesbank as sending NCB as follows: prefix”//TA” (positions 1-4); ISO country code ofthe sending central bank (positions 5-6; e.g. “DE”); BIC of the submitting institution (positions 7-17; 8-figure BICs will be padded with “XXX” to11 positions); TRN of the submitting institution (from position 18; max. 16 positions).




3.2.1 MT100

913 Time stamp Shifted to field 72 of the SWIFT message – if Sender to Receiver Informationspace available –














3.2.2 MT103(+)



119 STP Flag Unchanged Payment Type Flag

913 Time stamp Shifted to field 13c Sender to Receiver Information

13c Time Indication Unchanged plus SNDTIME and RNCTIME Time Indicationof the sending and receiving NCB






















3.2.3 MT202

3.2.4 PSMN

913 Time stamp Shifted to field 13c Sender to Receiver Information

13c Time Indication Unchanged plus SNDTIME and RNCTIME Time Indicationof the sending and receiving NCB











900 Interlinking Internal Reference Not mapped Interlinking Internal Reference

913 Time stamp Not mapped Time stamp

901 Referred Interlinking Not mappedInternal Reference

910 ECB date and time of receipt Not mapped

990 Acceptance code Not mapped

991 Reason code for rejection Not mapped

72 Sender to Receiver Information Not mapped

Interlinking MT198/110 2� National RTGS


2 The SWIFT standard MT 012/019 is used as Payment System Message Notification.


3.2.5 Routing rules

From national RTGS system Describe routing rules List message field thatto European countries are used for routing, if any

In general the BIC in the first credit field isused for the routing.For addressing remoteaccess EU banks and non-EU banks theordering institution inserts the BIC of thereceiving NCB in field 54 A which is useddomestically only.


4 Bank of Greece


4.1.1 MT100






52A Ordering Institution Account line: Return key. Ordering Institution (Optional)BIC line: Unchanged if present in theincoming message. Otherwise the BICof the sender.






72 Sender to Receiver National information is suppressed (/REC/). Sender to ReceiverInformation All other information is transferred Information

unchanged.


4.1.2 MT103(+)

119 STP Flag Unchanged Validation (119)




















unchanged.





4.1.3 MT202




52A Ordering Institution Account line: Return key. Ordering InstitutionBIC line: Unchanged if present in theincoming message. Otherwise the BICof the sender.





unchanged.





4.2.1 MT100



913 Time stamp

20 Transaction Reference Unchanged Message User Reference (108)Number of SendingCredit Institution




56A Intermediary Eliminated

57A Account with Institution Eliminated if this is the First Credit Field. Account with InstitutionOtherwise unchanged.






4.2.2 MT103(+)



119 STP Flag Unchanged Validation (119)

913 Time stamp











56A Intermediary Institution Eliminated Intermediary Institution











4.2.3 MT202

4.2.4 PSMN

913 Time stamp





56A Intermediary Eliminated


58A Beneficiary Institution Eliminated if this is the First Credit Field. Beneficiary InstitutionOtherwise unchanged.




900 Interlinking Internal Reference

913 Time stamp For positive PSMN Field 72 of MT199 or MT299

901 Referred InterlinkingInternal Reference

910 ECB date and time of receipt

990 Acceptance code

991 Reason code for rejection For negative PSMN (recredit of thesending C.I) Field 72 of MT910

72 Sender to Receiver Information




4.2.5 Routing rules


Account line of the First Credit Field /TACC where CC is the country code ofthe receiving NCB


5 Banco de España3


5.1.1 MT100

Field

20

32A

50

52A

56A

57A

59

70

71A

72

Description



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

Unchanged

The 32A field is always built withthe content of those two fields,adding the EUR currency code

Unchanged

UnchangedThe return key is built adding thecontent of two fields to the fixedstructure //TAES. Those fieldsare the BIC of the sendinginstitution (which is automaticallyfilled in the National RTGSapplication), and theTransaction Reference Numberof the sending institution.

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description


Value dateAmount stated in Euro

Ordering Customer


Intermediary



Details of Payment

Details of Charges


Interlinking MT198

3 Besides SWIFT, the Spanish RTGS provide their credit institutions with two additional ways to send/receive payments orders to/from SLBE. These are the on-lineconnection to the Banco de España computer for transmission of payments one-by-one or in batches (File transfer tool) using the main Spanishtelecommunication network provider. So, when using these two alternatives, credit institutions key in their orders in a domestic application whose formats areabsolutely compatible with the Interlinking ones. This information is automatically handled by the Banco de España to build a TARGET message which complywith the Interlinking specifications. On the other hand, the TARGET messages received are converted into domestic format before arriving to the institutionsscreens. Those conversions are detailed in the tables below. When Spanish credit institutions use SWIFT to communicate with SLBE, the messages are the samethan those used in Interlinking, and all fields remain “Unchanged” in both directions except in those fields for which additional information is provided in italicsin the tables below.


Field

119

20

13C

23B

23E

26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A

70

71A

71F

71G

72

77B

Description

STP Flag


Time Indication

Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged


Unchanged

Unchanged

Unchanged

Unchanged

UnchangedThe return key is built addingthe content of two fields to thefixed structure //TAES. Thosefields are the BIC of the sendinginstitution (which is automaticallyfilled in the National RTGSapplication), and theTransaction Reference Numberof the sending institution.

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

STP Flag

Transaction Numberof Sending Credit Institution

Time Indication

Bank Operation Code

Instruction Code




Exchange Rate

Ordering Customer (50K)

Ordering Customer (50A)


Intermediary



Beneficiary Customer (59A)


Details of Charges

Sender’s Charges




Interlinking MT198

5.1.2 MT103(+)


Field

20

21

13C

32A

52A

56A

57A

58A

72

Description


Related Reference

Time Indication



Intermediary




�

Mapping rules

Unchanged

Unchanged

Unchanged


UnchangedThe return key is built addingtwo fields to the fixed structure//TAES. Those fields are the BICof the sending institution (whichis automatically filled in theNational RTGS application), andthe Transaction ReferenceNumber of the SendingInstitution.

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description


Related Reference

Time Indication



Intermediary




Interlinking MT198

5.1.3 MT202


Field

900

913

20

32A

50

52A

56A

57A

59

70

71A

72

Description

Interlinking Internal Reference

Time stamp



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

UnchangedFor Credit Institutions usingSWIFT, the IIR is reported in field53A together with the debit timestamp and the BIC code of thesending NCB

Unchanged

Unchanged

The field 32A is split up in twodifferent fields: value date andamount stated in euro

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

Sending NCB IIR

Debit Time



Ordering Customer


Intermediary



Details of Payment

Details of Charges


Interlinking MT198


5.2.1 MT100


5.2.2 MT103(+)

Field

900

913

119

20

13C

23B

23E

26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A

70

71A

71F

71G

72

77B

Description

Interlinking InternalReference (IIR)

Time stamp

STP Flag


Time indication

Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




�

Mapping rules

UnchangedFor Credit Institutions usingSWIFT, the IIR is reported in field53A together with the debit timestamp and the BIC code of thesending NCB

Unchanged

Unchanged

Unchanged

UnchangedIn addition to the content of field13C, credit and debit time isalways reported to the CI usingthe Banco de Españaworkstation or file transfer.For CI using SWIFT,/SNDTIME/and/RNCTIME/are added to field13C with debit and credit timestamps

Unchanged

Unchanged

Unchanged


Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

Sending NCB IIR

Debit Time

STP Flag


Time indication.

Bank Operation Code

Instruction Code




Exchange Rate

Ordering Customer (50K)

Ordering Customer (50A)




Beneficiary Customer (59)

Beneficiary Customer (59A)


Details of Charges

Sender’s Charges




Interlinking MT198


Field

900

913

20

21

13C

32A

52A

56A

57A

58A

72

Description

Interlinking InternalReference (IIR)

Time stamp


Related Reference

Time Indication



Intermediary




�

Mapping rules

UnchangedFor CIs using SWIFT the IIR isreported in field 53A together withthe debit time stamp and the BICcode of the sending NCB

Unchanged

Unchanged

Unchanged

UnchangedIn addition to the content of field13C, credit and debit time isalways reported to the CI usingthe Banco de Españaworkstation or file transfer.For CI using SWIFT, /SNDTIME/and /RNCTIME/ are added to field13C with debit and credit timestamps


Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

Sending NCB IIR

Debit Time

Identification

Related Reference

Time Indication



Intermediary




Interlinking MT198

5.2.3 MT202

Spanish credit institutions do not receive the PSMNs related to their PSMRs. They just can see in their screens the differentstatus of the payment. When the PSMN has not still arrived, the payment status is sent. When a positive PSMN arrives, itchanges to settled and the IIR of the received PSMN is incorporated.

5.2.4 PSMN

Field

900

913

901

910

990

991

72

Description


Time stamp

Referred Interlinking InternalReference

ECB date and time of receipt

Acceptance code

Reason code for rejection

Sender to receiver information

�

Mapping rules

National RTGS

Field Description

Interlinking MT198/110


5.2.5 Routing rules

From national RTGS Describe routing rules List message fields that are used forsystem to European routing, if anycountries

When using the Banco de España workstation, Receiver Central Bankthe field “Receiver Central Bank” should bekeyed in with the first four characters of theBIC of every National Central Bank, only forrouting purposes.When using the File transmission tool, this field 54Ashould include the complete BIC of receivingNCB. When using SWIFT, receiving NCBshould be included in field 54A.


6 Banque de France


6.1.1 MT100

Field

20

32A

50

52A

56A

57A

59

70

71A

72

Description



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

Unchanged

Unchanged

Unchanged

Mandatory.Account line: The return key iscreated.The BIC is unchanged if presentin the incoming message.Otherwise the BIC of the senderis copied from the header of theSWIFT message only if it can betranslated from a BIC MUGTBF into a public BIC.

Unchanged. It is checked if theBIC is in the BIC directory. Ifnot the message is sent back tothe originator.

Unchanged. If the BIC is notpresent the message is returnedto the originator.

Unchanged

Unchanged

Unchanged

Unchanged except for the CRIspecific information that is notcopied.

National RTGS

Field Description



Ordering Customer

Optional

Intermediary



Details of Payment

Details of Charges. The allowedfields are ‘BEN’ and ‘OUR’. Thefirst implies that the charges arepaid by the beneficiary customer,the second implies that the chargesare paid by the ordering customer.

Mandatory. Sender to ReceiverInformation

Interlinking MT198


Field

119

20

23B

23E

26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A

70

71A

71F

71G

72

77B

Description

STP Flag


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




�

Mapping rules

Unchanged

Unchanged

Unchanged

field [/30x] is ignored

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

It is checked if the BIC is in theBIC directory.

Mandatory.The return key is created.The BIC is unchanged if BIC ispresent in the incoming message.Otherwise the BIC of the senderis copied from the header of theSWIFT message only if it can betranslated from a BIC MUGTBF into a public BIC.

Unchanged. It is checked if theBIC is in the BIC directory. Ifnot the message is sent back tothe originator.


Unchanged

Unchanged.It is checked if the BEI is in theBIC directory. If not the messageis sent back to the originator.

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged except for the CRIspecific information that is notcopied.

Unchanged

National RTGS

Field Description

STP Flag


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer

Optional


OptionalAccount with Institution




Details of Charges

Sender’s Charges


Mandatory.Sender to Receiver Information


Interlinking MT198

6.1.2 MT103(+)


Field

20

21

32A

52A

56A

57A

58A

72

Description


Related Reference



Intermediary




�

Mapping rules

Unchanged

Unchanged

Unchanged

Mandatory.The return key is created.The BIC is unchanged if presentin the incoming message.Otherwise the BIC of the senderis copied from the header of theSWIFT message only if it can betranslated from a BIC MUGTBF into a public BIC.

Unchanged. It is checked if theBIC is in the BIC directory. Ifnot the message is sent back tothe originator. If this field ispresent also the field 57A mustbe present.

Unchanged. If present the BICmust be in the BIC directory.


Unchanged except for thespecific information that is notcopied.

National RTGS

Field Description


Related Reference


Optional

Intermediary



Mandatory. Sender to ReceiverInformation

Interlinking MT198

6.1.3 MT202


Field

913

20

32A

50

52A

56A

57A

59

70

71A

72

Description

Time stamp



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

If the content of field 72 receivedis different of five lines, a new lineis created with /SNDTIME/<timestamp>.

The original TRN is present inthe Return Key (field 52A) and infield 20. It is replaced in field 20by the Interlinking InternalReference (IIR).

Unchanged

Unchanged

Mandatory. Unchanged after theBIC validation.

Unchanged. If present the BICmust be in the BIC directory andin the TBF Participant database.If not, the message is notforwarded to the receiver and anegative PSMN is sent back to theoriginator.

Unchanged. If present the BICmust be in the BIC directory andif field 56A is not present then theBIC must also be in the TBFParticipant database. If theresult of this validation isnegative, the message is notforwarded to the receiver and aPSMN is sent back to theoriginator.

Unchanged

Unchanged

Unchanged

When the content exceeds fivelines it is truncated. The five firstlines are placed after the linecreated for national routing andbilling information. The entirecontent of the field 72 of thereceived PSMR is forwarded tothe receiver in a MT199 messageformatted as follows::20: BdF Interlinkingcomponent’s TRN:21: TRN of the MT100 paymentorder received by the TBFparticipant:79: /Target-72/<entire content ofthe original field 72 of the receivedPSMR>

National RTGS

Field Description

Optional



Ordering Customer

Optional

Intermediary



Details of Payment

Details of Charges. The allowedfields are ‘BEN’ and ‘OUR’. Thefirst implies that the charges arepaid by the beneficiary customer,the second implies that the chargesare paid by the ordering customer.


Interlinking MT198


6.2.1 MT100


6.2.2 MT103(+)

Field

119

913

20

23B

23E

26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A

70

71A

71F

71G

Description

STP Flag

Time stamp


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges


�

Mapping rules

Unchanged

If the content of field 72 receivedis different of five lines, a newline is created with /SNDTIME/<time stamp>.

The original TRN is present inthe Return Key (field 52A) andin field 20. It is replaced in field20 by the Interlinking InternalReference (IIR).

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged after BIC/BEIvalidation.

Unchanged after BIC validation.

Unchanged. If present the BICmust be in the BIC directory andin the TBF Participant database.If not, the message is notforwarded to the receiver and aPSMN is sent back to theoriginator.

Unchanged. The BIC ismandatory and it must be in theBIC directory and if field 56A isnot present then the BIC mustalso be in the TBF Participantdatabase. If the result of thesevalidations is negative, themessage is not forwarded to thereceiver and a PSMN is sentback to the originator.

Unchanged

Unchanged after BIC/BEIvalidation.

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

STP Flag

Optional


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges


Interlinking MT198


Field

72

77B

Description



�

Mapping rules

When the content exceeds fivelines it is truncated. The five firstlines are placed after the linecreated for national routing andbilling information.The entire content of the field 72 ofthe received PSMR is forwardedto the receiver in a MT199message formatted as follows::20: BdF Interlinkingcomponent’s TRN:21: TRN of the MT103(+)payment order received by theTBF participant:79: /Target-72/<entire content ofthe original field 72 of the receivedPSMR>

Unchanged

National RTGS

Field Description



Interlinking MT198

6.2.2 MT103(+) (cont’)


Field

913

20

21

32A

52A

56A

57A

58A

72

Description

Time stamp


Related Reference



Intermediary




�

Mapping rules

If the content of field 72 receivedis different of five lines, a new lineis created with /SNDTIME/<timestamp>.

The original TRN is present inthe Return Key (field 52A) and infield 20. It is replaced in field 20by the Interlinking InternalReference (IIR).

Unchanged

Unchanged

Mandatory. Unchanged aftervalidation.

Unchanged. If present the BICmust be in the BIC directory andin the TBF Participant database.If not, the message is notforwarded to the receiver and aPSMN is sent back to theoriginator.

Unchanged. If present the BICmust be in the BIC directory andif field 56A is not present then theBIC must also be in the TBFParticipant database. If theresult of this validation isnegative, the message is notforwarded to the receiver and aPSMN is sent back to theoriginator.

Unchanged. If present the BICmust be in the BIC directory andif field 57A is not present then theBIC must also be in the TBFParticipant database.

When the content exceeds fivelines it is truncated. The five firstlines are placed after the linecreated for national routing andbilling information.The entire content of the field 72 ofthe received PSMR is forwardedto the receiver in a MT299message formatted as follows::20: BdF Interlinkingcomponent’s TRN:21: TRN of the MT202 paymentorder received by the TBFparticipant:79: /Target-72/<entire content ofthe original field 72 of the receivedPSMR>

National RTGS

Field Description

Optional


Related Reference


Ordering Institution. Optional

Intermediary




Interlinking MT198

6.2.3 MT202


6.2.4 PSMN

6.2.5 Routing rules

From national RTGS Describe routing rules List message fields that are usedsystem to European for routing, if anycountries

The sending TBF participant addresses NoneMT100/202s to a specific branch code for eachTARGET country in the Interlinking component.

Field

900

913

901

910

990

991

72

Description


Time stamp



Acceptance code



�

Mapping rules

When a positive PSMN isreceived, the interface sends tothe TBF Participant a MT199/299 formatted as follows :20:BdF interlinking component’sTRN21 : Sender’s reference ofMT100/202 TRN79 : /TARGET-FINALITE/<field 913 of PSMN>

When a negative PSMN isreceived this field is copied tofield 72 after the code word/RETN/ of the MT202 sent backto the TBF Participant.

National RTGS

Field Description

Interlinking MT198


7 Central Bank of Ireland


7.1.1 MT100




32A Value date Unchanged Value DateCurrency code Currency CodeAmount Amount


52A Ordering Institution Mandatory – RTGS generated //TA, Country Code, BIC ofsending Credit Institution, TRN(as in 20 above)



59 Beneficiary Customer Unchanged Beneficiary Institution





7.1.2 MT103(+)

119 STP Flag Unchanged STP Flag





32A Value Date/Currency/ Unchanged Value Date/Currency/Interbank Settled Amount Interbank Settled Amount

33B Currency/Original Ordered Unchanged Currency/Original OrderedAmount Amount




52A Ordering Institution Mandatory – Unchanged if supplied in the Ordering Institutionincoming message, otherwise the BIC ofthe submitting participant – Inclusion of returnpayment information (//TA…) in the accountnumber line














7.1.3 MT202




52A Ordering Institution Mandatory – RTGS generated //TA, Country Code, BIC ofsending Credit Institution, TRN(as in 20 above)









7.2.1 MT100

913 Time stamp Field 115 in Message Header Server to ReceiverInstructions

20 Transaction Reference RTGS generated (to avoid duplicates) – Transaction Reference NumberNumber of Sending original copied to field 115 in Message of RTGSCredit Institution Header













7.2.2 MT103(+)




913 Time stamp Copied to Field 115 in the Message Header Server to Receiver Instructions

20 Transaction Reference Generated by RTGS (to avoid duplicates) Transaction ReferenceNumber of Sending Number of RTGSCredit Institution




32A Value Date/Currency/Interbank Unchanged Value Date/Currency/InterbankSettled Amount Settled Amount

















7.2.3 MT202

7.2.4 PSMN

913 Time stamp Moved to field 115 in Message Header Server to Receiver Instructions

20 Transaction Reference RTGS generated (to avoid duplicates) – Transaction ReferenceNumber of Sending original copied to field 115 in Message Number of RTGSCredit Institution Header










900 Interlinking Internal Reference Not Forwarded

913 Time stamp Not Forwarded

901 Referred Interlinking Not ForwardedInternal Reference

910 ECB date and time of receipt Not Forwarded

990 Acceptance code Field L10 of MT298/702 RTGS Message Status

991 Reason code for rejection Field L10 of MT298/702 RTGS Message Status

72 Sender to receiver information Not Forwarded




7.2.5 Routing rules


Routing to a specific RTGS is done by 54Aincluding the Target BIC (XXXXXXTG) of thedestination NCB in field 54A of the domesticmessage (mandatory)


8 Banca d’Italia

The following rules apply only to the SWIFT access to the BI-REL system. For the domestic format pleaserefer to the national documentation available at the web site of the Società Interbancaria per l’Automazione(www.sia.it).


8.1.1 MT100

Field

20

32A

50

52A

56A

57A

59

70

71A

72

Description



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

Unchanged

Unchanged

Unchanged

Line 1 – Return key information– added according to TARGETrules://TAIT, BIC of the sender,TRN Line 2 – Unchanged ifpresent in the incoming message.Otherwise the BIC of the sender

Unchanged. It is checked if theBIC is in the BIC directory. Ifnot the message is sent back tothe sender. If this field is presentalso the field 57A must bepresent. Clearing-code //TACC,if present in the account line, isremoved

Unchanged. If the BIC is notpresent or the BIC is not in theBIC directory, the message isreturned to the sender. Clearing-code //TACC, if present in theaccount line, is removed

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description



Ordering Customer


Intermediary



Details of Payment

Details of Charges


Interlinking MT198


Field

119

20

23B

23E

26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A

70

71A

71F

71G

72

77B

Description

STP Flag


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Line 1 – Return key information– added according to TARGETrules://TAIT, BIC of the sender,TRN Line 2 – Unchanged ifpresent in the incoming message.Otherwise the BIC of the sender

Unchanged. It is checked if theBIC is in the BIC directory. Ifnot the message is sent back tothe sender. If this field is presentalso the field 57A must bepresent. Clearing-code //TACC,if present in the account line, isremoved

Unchanged. If the BIC is notpresent or the BIC is not in theBIC directory, the message isreturned to the sender. Clearing-code //TACC, if present in theaccount line, is removed

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

STP Flag


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




Interlinking MT198

8.1.2 MT103(+)


Field

20

21

32A

52A

56A

57A

58A

72

Description


Related Reference



Intermediary




�

Mapping rules

Unchanged

Unchanged

Unchanged

Line 1 – Return key Information– added according to TARGETrules: //TAIT, BIC of the sender,TRN. Line 2 – Unchanged ifpresent in the incoming message.Otherwise the BIC of the sender

Unchanged. It is checked if theBIC is in the BIC directory. Ifnot the message is sent back tothe sender. If this field is presentalso the fields 57A and the 58Amust be present

Unchanged. If the BIC is not inthe BIC directory, the message isreturned to the sender

Unchanged. If the BIC is not inthe BIC directory, the message isreturned to the sender

Unchanged

National RTGS

Field Description


Related Reference



Optional. The field must be filledin with the BIC of the NCB of thecountry in which the beneficiaryparticipates.




Interlinking MT198

8.1.3 MT202


Field

913

20

32A

50

52A

56A

57A

59

70

71A

72

Description

Time stamp



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

Added to the field 72 with thecode word: /SNDTIME/<DT>The information will only madeavailable when one line will be leftavailable by the ordering party.



Ordering Customer


Intermediary



Details of Payment

Details of Charges


Interlinking MT198


8.2.1 MT100


8.2.2 MT103(+)

Field

119

913

20

23B

23E

26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A

70

71A

71F

71G

72

77B

Description

STP Flag

Time stamp


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

STP Flag



Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




Interlinking MT198


Field

913

20

21

32A

52A

56A

57A

58A

72

Description

Time stamp


Related Reference



Intermediary




�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description



Related Reference



Intermediary




Interlinking MT198

8.2.3 MT202


8.2.4 PSMN

8.2.5 Routing rules


CIs using SWIFT Fields 56A or 57A or 58A.Credit institution indicates //TA + country codeof the receiving NCB in the account line of the1st credit field. If the country code is equal to ITthe payment is processed as domestic transaction.

CIs not using SWIFTCredit institutions can use code //TACC(CC = Country code) to indicate receiving NCBin the account line of the first credit field. Thiscode is not forwarded. If no specific routinginformation is given, the country code of theBIC in the first credit field will be used.

Field

900

913

901

910

990

991

72

Description


Time stamp



Acceptance code



�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS (MT198/155)

Field Description

Time stamp


Acceptance code


Added in the field 72 of thereturned payments.


When a negative PSMN is received, than the original message (MT100/103 or MT202) isreturned to the originator.All fields in the original message are left unchanged with the exception of the field 72.The original content of the field 72 is overwrite with the SWIFT format for the rejected/returned payments.


9 Banque Centrale du Luxembourg


9.1.1 MT100




32A Value Date/Currency Unchanged Value Date/Currencycode/Amount code/Amount


52A Ordering Institution Mandatory – Unchanged if supplied in the Ordering Institution (optional)incoming message, otherwise the BIC of thesubmitting participant – Inclusion of returnpayment information (//TA…) in the accountnumber line








9.1.2 MT103(+)






32A Value Date/Currency/ Unchanged Value Date /Currency/Interbank Settled Amount Interbank Settled Amount

33B Currency/Original Ordered Unchanged Currency/Original OrderedAmount Amount




52A Ordering Institution Mandatory – Unchanged if supplied in the Ordering Institutionincoming message, otherwise the BIC of thesubmitting participant – Inclusion of returnpayment information (//TA…) in the accountnumber line














9.1.3 MT202

20 Transaction Reference Number Unchanged Transaction Reference Numberof Sending Credit Institution of Sending Credit Institution



52A Ordering Institution Mandatory – Unchanged if supplied in the Ordering Institutionincoming message, otherwise the BIC of thesubmitting participant – Inclusion of returnpayment information (//TA…) in the accountnumber line









9.2.1 MT 100















9.2.2 MT103(+)









32A Value Date/Currency/ Unchanged Value Date/Currency/InterbankInterbank Settled Amount Settled Amount

















9.2.3 MT202

9.2.4 PSMN




32A Value Date/Currency code/ Unchanged Value Date/Currency code/Amount Amount

52A Ordering Institution Unchanged Odering Institution







900 Interlinking Internal Reference Not Forwarded

913 Time stamp Not Forwarded

901 Referred Interlinking Not ForwardedInternal Reference

910 ECB date and time of receipt Not Forwarded

990 Acceptance code Field L10 of MT 298/702 RTGS Message Status

991 Reason code for rejection Field L10 of MT 298/702 RTGS Message Status

72 Sender to Receiver Information Not Forwarded

Interlinking MT198/110 � National RTGS (MT198/155)



9.2.5 Routing rules


Routing to a specific RTGS is done by 54Aincluding the TARGET BIC (xxxxxxTG)of the destination NCB in field 54A of thedomestic message (mandatory)


10 De Nederlandsche Bank


10.1.1 MT100

Field

20

32A

50

52A

56A

57A

59

70

71A

72

Description



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

Unchanged

Unchanged

Unchanged

Line 1 is filled with returninformation: //TANL followedby: <BIC of owner of debitaccount> and <TransactionReference Number of SendingCredit Institution>.Line 2 is filled with the OrderingInstitution if present. If notpresent, the BIC of the owner ofthe debit account is used.

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description



Ordering Customer


Intermediary



Details of Payment

Details of Charges


Interlinking MT198


Field

119

20

23B

23E

26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A

70

71A

71F

71G

72

77B

Description

STP Flag


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged


Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

STP Flag


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




Interlinking MT198

10.1.2 MT103(+)


Field

20

21

32A

52A

56A

57A

58A

72

Description


Related Reference



Intermediary




�

Mapping rules

Unchanged

Unchanged

Unchanged


Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description


Related Reference



Intermediary




Interlinking MT198

10.1.3 MT202


Field

913

20

32A

50

52A

56A

57A

59

70

71A

72

Description

Time stamp



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

Reference Number ofDe Nederlandsche Bank

Unchanged

Unchanged

Unchanged

If this is the first credit field, thecontents will always be removed


Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description



Ordering Customer


Intermediary



Details of Payment

Details of Charges


Interlinking MT198


(Credit Advice of Advice of Refusal to Credit Institution)

10.2.1 MT100


10.2.2 MT103(+)

Field

119

913

20

23B

23E

26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A

70

71A

71F

71G

72

77B

Description

STP Flag

Time stamp


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




�

Mapping rules

Unchanged


Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged



Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

STP Flag

Time stamp


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




Interlinking MT198


Field

913

20

21

32A

52A

56A

57A

58A

72

Description

Time stamp


Related Reference



Intermediary




�

Mapping rules


Unchanged

Unchanged

Unchanged



Unchanged

Unchanged

National RTGS

Field Description


Related Reference



Intermediary




Interlinking MT198

10.2.3 MT202


10.2.4 PSMN

(In case of NACK)

10.2.5 Routing rules


If field 72 contains the codeword /TOP/+NCB Field 72, 56, 57 or 58+CC+ (for ‘CC’ is filled in the countrycode ofthe European country), then the transactionwill be routed to the RTGS system of thatcountry.If field 72 does not contain the codewordmentioned, then the countrycode of the BICof the first credit field (field 56, 57 or 58) willbe used. The transaction will be routed to theRTGS system of that country.

Field

900

913

901

910

990

991

72

Description


Time stamp



Acceptance code



�

Mapping rules

Only the Settlement Managerreceives this information.The credit institution receives aMT195 or MT295 if a payment isnot acknowledged by the otherNCB. Field 20 of this message isfilled with the TransactionReference Number of therejected transaction. Field 79 isfilled with a general message.

Only the Settlement Managerreceives this information.

Only the Settlement Managerreceives this information. TheCredit Institution can inquire theSettlement Manager about thereason for rejection.

Only the Settlement Managerreceives this information. TheCredit Institution can inquire theSettlement Manager about thereason for rejection.

National RTGS

Field Description







11 Oesterreichische Nationalbank


11.1.1 MT100

The MT100 will be used until 26 September 2003 only.



20 Transaction Reference unchanged reference of sending CINumber of SendingCredit Institution

32A Value date converted to SWIFT-format Value date; currency codeCurrency code only EUR possible (only EUR possible);Amount Amount

50 Ordering Customer account number is removed, rest unchanged ordering customer

52A Account Number supply the //TA-information in the first line ordering institutionOrdering Institution second line filled with BIC

56A Intermediary unchanged intermediary institution

57A Account with Institution “/” is placed before the account number, account with institutionrest unchanged

59 Beneficiary Customer “/” is placed before the account number, beneficiary customerrest unchanged

70 Details of Payment Unchanged details of payment

71A Details of Charges Unchanged Details of charges

72 Sender to Receiver Information The first line (containing /REC/NB/..., i.e. sender-to-receiverbalance of payments information) is stripped, informationthe rest remains unchanged.


11.1.2 MT103(+)

119 STP Flag

20 Transaction Reference Unchanged reference of sending CINumber of SendingCredit Institution

23B Bank Operation Code Unchanged bank operation code



32A Amount Unchanged value date; currencyonly EUR possible (only EUR possible)

amount

33B Currency/Instructed Amount Unchanged currency/instructed amount

36 Exchange Rate Unchanged exchange rate

50K Ordering Customer Unchanged ordering customer

50A Ordering Customer Unchanged ordering customer

52A Ordering Institution Unchanged ordering institution

56A Intermediary Institution Unchanged intermediary institution

57A Account with Institution Unchanged account with institution

59 Beneficiary Customer Unchanged beneficiary customer

59A Beneficiary Customer Unchanged beneficiary customer

70 Remittance Information Unchanged remittance information

71A Details of Charges Unchanged details of charges

71F Sender’s Charges Unchanged sender’s charges

71G Receiver’s Charges Unchanged receiver’s charges

72 Sender to Receiver The first and the second line (containing sender to receiver informationInformation /REC/NB/... and /REC/RTGS/..., i.e.

balance of payment information) is stripped,the rest remains unchanged.

77B Regulatory Reporting Unchanged regulatory reporting




11.1.3 MT202

The field numbers

20 Transaction Reference Unchanged reference of sending CINumber of SendingCredit Institution

21 Related Reference Unchanged related reference

32A Value date converted to SWIFT-format value date; currency codeCurrency code only EUR possible (only EUR possible);Amount amount

52A Account Number supply the //TA-information in the first line BIC of the ordering CIOrdering Institution second line filled with BIC

56A Intermediary Unchanged BIC of the intermediary CIon the beneficiary side

57A Account with Institution “/” is placed before the account number, BIC of the account withrest unchanged institution on the beneficiary

side (account number lineoptional)

58A Beneficiary Institution “/” is placed before the account number, BIC of the beneficiary CIrest unchanged (account number line optional)

72 Sender to Receiver The first line (containing /REC/NB/…) is sender-to-receiver informationInformation stripped, the rest remains unchanged.





11.2.1 MT100

As of 29 September 2003 all incoming Interlinking MT198/100 will be converted to MT103 until the removal of the MT100from the SWIFT network.

913 Time stamp


32A Value date converted to ISO-Format (YYYYMMDD) value date; currencyCurrency code unchanged (only EUR possible); amountAmount unchanged

50 Ordering Customer unchanged ordering customer

52A Account Number //TA-information is moved into field 570 ordering institutionOrdering Institution with code /RETI/, BIC unchanged, or field 72

in the SWIFT Format

56A Intermediary unchanged intermediary institution

57A Account with Institution unchanged account with institution

59 Beneficiary Customer “/” is stripped from the account number, beneficiary customerrest unchanged

70 Details of Payment unchanged details of payment

71A Details of Charges unchanged details of charges

72 Sender to Receiver /REC/NB/ is added in the first line (necessary sender-to-receiver informationInformation for the balance of payments reporting to the

OeNB)/RETI/ - information is generated fromfield 52AIf there are not enough lines availablefor the information above, the last two linesare stripped.




11.2.2 MT103(+)



119 STP Flag

913 Time stamp


23B Bank Operation Code unchanged bank operation code

23E Instruction Code unchanged Instruction Code

26T Transaction Type Code unchanged Transaction Type Code

32A Amount unchanged value date currencyunchanged (only EUR possible)unchanged amount

33B Currency/Instructed Amount unchanged currency/instructed amount

36 Exchange Rate unchanged exchange rate

50K Ordering Customer unchanged ordering customer

50A Ordering Customer unchanged ordering customer

52A Ordering Institution //TA-information is moved into field 72 with ordering institutioncode /RETI/, BIC unchanged

56A Intermediary Institution unchanged intermediary institution

57A Account with Institution unchanged account with institution

59 Beneficiary Customer unchanged beneficiary customer

59A Beneficiary Customer unchanged beneficiary customer

70 Remittance Information unchanged remittance information

71A Details of Charges unchanged details of charges

71F Sender’s Charges unchanged sender’s charges

71G Receiver’s Charges unchanged receiver’s charges

72 Sender to Receiver /REC/NB/ is added in the first line (necessary sender to receiver informationInformation for the balance of payments reporting to the

OeNB)/RETI/ - information is generatedfrom field 52AIf there are not enough lines available forthe information above, the last two linesare stripped.

77B Regulatory Reporting unchanged regulatory reporting


11.2.3 MT202

913 Time stamp


21 Related Reference unchanged reference of the ordering party

32A Value date converted to ISO-Format (YYYYMMDD) value date; currencyCurrency code unchanged (only EUR possible);Amount unchanged amount

52A Account Number //TA-information is moved into field 570 BIC of ordering CIOrdering Institution with code /RETI/

BIC unchanged

56A Intermediary unchanged BIC of the intermediary CI onthe beneficiary side

57A Account with Institution unchanged BIC of the account withinstitution of the beneficiary

58A Beneficiary Institution unchanged BIC of the beneficiaryinstitution

72 Sender to Receiver /REC/NB/ is added in the first line (necessary sender-to-receiver informationInformation for the balance of payments reporting to the

OeNB)/RETI/ - information is generated fromfield 52AIf there are not enough lines available for theinformation above, the last two linesare stripped.




11.2.4 PSMN

The PSMN is not forwarded to the sending CI of the underlying payment order, the CI receives a debitingconfirmation (only if it is requested) when the (positive) PSMN arrives.


900 Interlinking Internal Reference

913 Time stamp

901 Referred InterlinkingInternal Reference

910 ECB date and time of receipt

990 Acceptance code

991 Reason code for rejection

72 Sender to receiver information



From national RTGS Describe routing rules List message fieldssystem to European that are used forcountries routing, if any

The BIC in the first credit field is looked up in the TARGET-Directory.If the BIC has a preferred service, the payment is forwarded to theNCB/ECB which runs this service (e.g. preferred service is RTP =>message is forwarded to MARKDETG). If there is no preferred servicethe following rules are applied:If only one service is registered the payment is sent to the NCB/ECBwhich runs this service.If more than one services are registered and one of these servicesbelongs to the NCB with the same ISO-country code as the one in theBIC of the CI in the first credit field the payment is sent to this NCB;otherwise the payment is sent to the NCB running the first serviceregistered in the TARGET-Directory.Should the payment have to be sent to a bank’s RTGS account in acountry, which is not registered as a preferred service, the BIC of theNCB/ECB is entered in field 54A for routing purposes. Field 54A willbe deleted by OeNB before sending the message into the Interlinkingnetwork.

If the first credit field contains the TARGET-BIC of an NCB/ECB, themessage is forwarded to this BIC. In the event that the second creditfield contains the BIC of an RTGS participant of this NCB/ECB theNCB/ECB BIC is removed from the message.

No field in additionto the first creditfield and field 54A(only for specialpurposes) is usedfor routingpurposes.


12 Banco de Portugal


12.1.1 MT100 4

Field

20

32A

50

52A

56A

57A

59

70

Description



Ordering Customer


Intermediary



Details of Payment

�

Mapping rules

Mapped from ‘TRNORD’

Value date is mapped from DT-LIQAlways EURAmount mapped from IMPORT

Line 1 mapped from CLIORDLine 2 mapped from MORORD1Line 3 mapped from MORDOR2Line 4 mapped from MORDOR3

Line 1 Mapped from INFBDEBLine 2 Mapped from ESWORD

Line 1 mapped from CONTBRLine 2 mapped from ESWFBR

Line 1 mapped from CONTBDLine 2 mapped from ESWFBD

Line 1 mapped from CONTBENLine 2 mapped from CLIDSTLine 3 mapped from MORDST1Line 4 mapped from MORDST2Line 5 is mapped from MORDST3

Line 1 is mapped from MOTTRS1Line 2 is mapped from MOTTRS2Line 3 is mapped from MOTTRS3Line 4 is mapped from MOTTRS4

National RTGS

Field Description

FIELD TAG = TRNORDof message 63

FIELD TAG = DT-LIQof message 63NO FIELD TAGFIELD TAG = IMPORTof message 63

FIELD TAG = CLIORDof message 63FIELD TAG = MORORD1of the addenda message 1FIELD TAG = MORORD2of the addenda message 2FIELD TAG = MORORD3of the addenda message 3

FIELD TAG = INFBDEBof message 63FIELD TAG = ESWORDof message 63

FIELD TAG = CONTBRof the addenda message 2FIELD TAG = ESWFBRof message 63

FIELD TAG = CONTBDof the addenda message 2FIELD TAG = ESWFBDof message 63

FIELD TAG = CONTBENof message 63FIELD TAG = CLIDSTof message 63FIELD TAG = MORDST1of the addenda message 1FIELD TAG = MORDST2of the addenda message 1FIELD TAG = MORDST3of the addenda message 2

FIELD TAG = MOTTRS1of the addenda message 1FIELD TAG = MOTTRS2of the addenda message 1FIELD TAG = MOTTRS3of the addenda message 2FIELD TAG = MOTTRS4of the addenda message 3

Interlinking MT198

4 The Interlinking message MT 100 is converted in one national message and three addenda messages.


12.1.1 MT100 4 (cont’)

FIELD TAG = INDDSPof the addenda message 1

FIELD TAG = INFO1of the addenda message 1FIELD TAG = INFO2of the addenda message 2FIELD TAG = INFO3of the addenda message 3FIELD TAG = INFO4of the addenda message 3FIELD TAG = INFO5of the addenda message 3FIELD TAG = INFO6of the addenda message 3

Mapped from INDDSP

Line 1 mapped from INFO1Line 2 mapped from INFO2Line 3 mapped from INFO3Line 4 mapped from INFO4Line 5 mapped from INFO5Line 6 mapped from INFO6

Details of Charges


71A

72

Field Description

�

Mapping rules

National RTGS

Field Description

Interlinking MT198

Field

119

13C

20

23B

23E

Description

STP Flag

Time indication

Transaction Reference Number ofSending Credit Institution

Bank Operation Code

Instruction Code

�

Mapping rules

Mapped from STPFLAG

Line 1 Mapped from INFTIME1Line 2 Mapped from INFTIME2Line 3 Mapped from INFTIME3Line 4 Mapped from INFTIME4Line 5 Mapped from INFTIME5

Mapped from TRNORD

Mapped from OPCODE

Line 1 Mapped from ICODE01and IINFO01Line 2 Mapped from ICODE02and IINFO02Line 3 Mapped from ICODE03and IINFO03Line 4 Mapped from ICODE04and IINFO04Line 5 Mapped from ICODE05and IINFO05Line 6 Mapped from ICODE06and IINFO06Line 7 Mapped from ICODE07and IINFO07Line 8 Mapped from ICODE08and IINFO08Line 9 Mapped from ICODE09and IINFO09Line 10 Mapped from ICODE10and IINFO10

National RTGS

Field Description

FIELD TAG = STPFLAGof message 63

FIELD TAG = INFTIME 1of the addenda message 1FIELD TAG = INFTIME 2of the addenda message 2FIELD TAG = INFTIME 3of the addenda message 3FIELD TAG = INFTIME 4of the addenda message 4FIELD TAG = INFTIME 5of the addenda message 5


FIELD TAG = OPCODEof message 63

FIELD TAG = ICODE01 + IINFO01of the addenda message 1FIELD TAG = ICODE02 + IINFO02of the addenda message 5FIELD TAG = ICODE03 + IINFO03of the addenda message 5FIELD TAG = ICODE04 + IINFO04of the addenda message 5FIELD TAG = ICODE05 + IINFO05of the addenda message 6FIELD TAG = ICODE06 + IINFO06of the addenda message 6FIELD TAG = ICODE07 + IINFO07of the addenda message 6FIELD TAG = ICODE08 + IINFO08of the addenda message 6FIELD TAG = ICODE09 + IINFO09of the addenda message 6FIELD TAG = ICODE10 + IINFO10of the addenda message 6

Interlinking MT198

12.1.2 MT103(+)


Field Description

�

Mapping rules

National RTGS

Field Description

Interlinking MT198

12.1.2 MT103(+) (cont’)

FIELD TAG = TTCODEof the addenda message 5


FIELD TAG = CDVINSof the addenda message 1FIELD TAG = IMPINSof the addenda message 1

FIELD TAG = EXCHRATEof the addenda message 1

FIELD TAG = CONTORDof the addenda message 3FIELD TAG = CLIORDof message 63FIELD TAG = MORORD1of the addenda message 1FIELD TAG = MORORD2of the addenda message 2FIELD TAG = MORORD3of the addenda message 2

FIELD TAG = CONTORDof the addenda message 3FIELD TAG = CLIORDof message 63





FIELD TAG = CONTBENof message 63FIELD TAG = CLIDSTof message 63

Mapped from TTCODE

Value date Mapped from DT-LIQAlways EURAmount Mapped from IMPORT

Currency Mapped from CDVINSInstructed Amount Mapped fromIMPINS

Mapped from EXCHRATE

Line 1 Mapped from CONTORDLine 2 Mapped from CLIORDLine 3 Mapped from MORORD1Line 4 Mapped from MORORD2Line 5 Mapped from MORORD3

Line 1 Mapped from CONTORDLine 2 Mapped from CLIORD

Mapped from INFBDEBMapped from ESWORD

Line 1 Mapped from CONTBRLine 2 Mapped from ESWFBR

Line 1 Mapped from CONTBDLine 2 Mapped from ESWFBD

Line 1 Mapped from CONTBENLine 2 Mapped from CLIDSTLine 3 Mapped from MORDST1Line 4 Mapped from MORDST2Line 5 Mapped from MORDST3

Line 1 Mapped from CONTBENLine 2 Mapped from CLIDST


Value DateCurrency CodeAmount


Exchange Rate

Ordering Customer

Ordering Customer






26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A




FIELD TAG = CDVDEMI1of the addenda message 2FIELD TAG = DESPEMI1of the addenda message 2FIELD TAG = CDVDEMI2of the addenda message 3FIELD TAG = DESPEMI2of the addenda message 3FIELD TAG = CDVDEMI3of the addenda message 3FIELD TAG = DESPEMI3of the addenda message 3FIELD TAG = CDVDEMI4of the addenda message 5FIELD TAG = DESPEMI4of the addenda message 5FIELD TAG = CDVDEMI5of the addenda message 5FIELD TAG = DESPEMI5of the addenda message 5

FIELD TAG = CDVDBRECof the addenda message 2FIELD TAG = DESPBRECof the addenda message 2


FIELD TAG = REGLTRY1of the addenda message 2FIELD TAG = REGLTRY2of the addenda message 4FIELD TAG = REGLTRY3of the addenda message 5

Field Description

�

Mapping rules

National RTGS

Field Description

Interlinking MT198

12.1.2 MT103(+) (cont’)

Line 1 Mapped from MOTTRS1Line 2 Mapped from MOTTRS2Line 3 Mapped from MOTTRS3Line 4 Mapped from MOTTRS4

Mapped from INDDSP

1º Currency Mapped fromCDVDEMI11º Amount Mapped fromDESPEMI12º Currency Mapped fromCDVDEMI22º Amount Mapped fromDESPEMI23º Currency Mapped fromCDVDEMI33º Amount Mapped fromDESPEMI34º Currency Mapped fromCDVDEMI44º Amount Mapped fromDESPEMI45º Currency Mapped fromCDVDEMI55º Amount Mapped fromDESPEMI5

Currency Mapped fromCDVDBRECAmount Mapped fromDESPBREC

Line 1 Mapped from INFO1Line 2 Mapped from INFO2Line 3 Mapped from INFO3Line 4 Mapped from INFO4Line 5 Mapped from INFO5Line 6 Mapped from INFO6

Line 1 Mapped from REGLTRY1Line 2 Mapped from REGLTRY2Line 3 Mapped from REGLTRY3


Details of Charges

Sender’s Charges




70

71A

71F

71G

72

77B


Field

13C

20

21

32A

52A

56A

57A

58A

72

Description

Time indication


Related Reference



Intermediary




�

Mapping rules

Line 1 Mapped from INFTIME1Line 2 Mapped from INFTIME2Line 3 Mapped from INFTIME3Line 4 Mapped from INFTIME4Line 5 Mapped from INFTIME5

Mapped from TRNORD

Mapped from RELTRN

Value date is mappedfrom DT-LIQAlways EURAmount is mapped fromIMPORT

Line 1 Mapped from INFBDEBLine 2 Mapped from ESWORD

Line 1 is mapped from CONTBRLine 2 is mapped from ESWFBR

Line 1 mapped from CONTBDLine 2 mapped from ESWFBD

Line 1 mapped from CONTBBLine 2 is mapped from ESWBEN

Line 1 mapped from INFO1Line 2 mapped from INFO2Line 3 mapped from INFO3Line 4 mapped from INFO4Line 5 mapped from INFO5Line 6 mapped from INFO6

National RTGS

Field Description

FIELD TAG = INFTIME1of the addenda message 1FIELD TAG = INFTIME2of the addenda message 2FIELD TAG = INFTIME3of the addenda message 2FIELD TAG = INFTIME4of the addenda message 2FIELD TAG = INFTIME5of the addenda message 2


FIELD TAG = RELTRNof message 63





FIELD TAG = CONTBBof the addenda message 1FIELD TAG = ESWBENof message 63


Interlinking MT198

12.1.3 MT2025

5 The Interlinking message MT 202 is converted in one national message and two addenda messages.


Field

913

20

32A

50

52A

56A

57A

59

70

Description

Time stamp



Ordering Customer


Intermediary



Details of Payment

�

Mapping rules

Mapped to TSDEBITO

Mapped to ‘TRNORD’

Value date mapped to DT-LIQAlways EURAmount is to IMPORT

Line 1 mapped to CLIORDLine 2 mapped to MORORD1Line 3 mapped to MORORD2Line 4 mapped to MORORD3

Line 1 Mapped to INFBDEBLine 2 Mapped to ESWORD

Line 1 mapped to CONTBRLine 2 mapped to ESWFBR

Line 1 mapped to CONTBDLine 2 mapped to ESWFBD

Line 1 mapped to CONTBENLine 2 mapped to CLIDSTLine 3 mapped to MORDST1Line 4 mapped to MORDST2Line 5 mapped to MORDST3

Line 1 mapped to MOTTRS1Line 2 mapped to MOTTRS2Line 3 mapped to MOTTRS3Line 4 mapped to MOTTRS4

National RTGS

Field Description

FIELD TAG = TSDEBITOof message 52



FIELD TAG = CLIORDof message 52FIELD TAG = MORORD1of the addenda message 1FIELD TAG = MORORD2of the addenda message 2FIELD TAG = MORORD3of the addenda message 3






Interlinking MT198


12.2.1 MT100 6

6 The Interlinking message MT 100 is converted in one national message and three addenda messages.


Field

71A

72

Description

Details of Charges


�

Mapping rules

Mapped to INDDSP

Line 1 mapped to INFO1Line 2 mapped to INFO2Line 3 mapped to INFO3Line 4 mapped to INFO4Line 5 mapped to INFO5Line 6 mapped to INFO6

National RTGS

Field Description



Interlinking MT198

12.2.2 MT103(+)

Field

913

119

13C

20

23B

23E

Description

Time Stamp

STP Flag

Time indication


Bank Operation Code

Instruction Code

�

Mapping rules

Mapped to TSDEBITO

Mapped to STPFLAG

Line 1 Mapped to INFTIME1Line 2 Mapped to INFTIME2Line 3 Mapped to INFTIME3Line 4 Mapped to INFTIME4Line 5 Mapped to INFTIME5

Mapped to TRNORD

Mapped to OPCODE

1º Mapped to ICODE01 andIINFO012º Mapped to ICODE02 andIINFO023º Mapped to ICODE03 andIINFO034º Mapped to ICODE04 andIINFO045º Mapped to ICODE05 andIINFO056º Mapped to ICODE06 andIINFO067º Mapped to ICODE07 andIINFO07

National RTGS

Field Description


FIELD TAG = STPFLAGof message 52



FIELD TAG = OPCODEof message 52

FIELD TAG = ICODE01of the addenda message 1FIELD TAG = ICODE02of the addenda message 5FIELD TAG = ICODE03of the addenda message 5FIELD TAG = ICODE04of the addenda message 5FIELD TAG = ICODE05of the addenda message 6FIELD TAG = ICODE06of the addenda message 6FIELD TAG = ICODE07of the addenda message 6

Interlinking MT198

12.2.1 MT100 (cont’)


12.2.2 MT103(+) (cont’)

Field

26T

32A

33B

36

50K

50A

52A

56A

57A

59

Description


Value DateCurrency CodeAmount


Exchange Rate

Ordering Customer

Ordering Customer





�

Mapping rules

8º Mapped to ICODE08 andIINFO089º Mapped to ICODE09 andIINFO0910º Mapped to ICODE10 andIINFO10

Mapped to TTCODE

Value Date Mapped to DT-LIQAlways EURMapped to IMPORT

Currency Mapped to CDVINSInstructed Amount Mapped toIMPINS

Mapped to EXCHRATE

Line 1 Mapped to CONTORDLine 2 Mapped to CLIORDLine 3 Mapped to MORORD1Line 4 Mapped to MORORD2Line 5 Mapped to MORORD3

Line 1 Mapped to CONTORDLine 2 Mapped to CLIORD

Mapped to INFBDEBMapped to ESWORD

Line 1 Mapped to CONTBRLine 2 Mapped to ESWFBR

Line 1 Mapped to CONTBDLine 2 Mapped to ESWFBD

Line 1 Mapped to CONTBENLine 2 Mapped to CLIDSTLine 3 Mapped to MORDST1Line 4 Mapped to MORDST2Line 5 Mapped to MORDST3

National RTGS

Field Description

FIELD TAG = ICODE08of the addenda message 6FIELD TAG = ICODE09of the addenda message 6FIELD TAG = ICODE10of the addenda message 6

FIELD TAG = TTCODEof the addenda message 5


FIELD TAG = CDVINSof the addenda message 1FIELD TAG = IMPINSof the addenda message 1

FIELD TAG = EXCHRATEof the addenda message 1

FIELD TAG = CONTORDof the addenda message 3FIELD TAG = CLIORDof message 52FIELD TAG = MORORD1of the addenda message 1FIELD TAG = MORORD2of the addenda message 2FIELD TAG = MORORD3of the addenda message 2

FIELD TAG = CONTORDof the addenda message 3FIELD TAG = CLIORDof message 52





Interlinking MT198


12.2.2 MT103(+) (cont’)

Field

59A

70

71A

71F

71G

72

77B

Description



Details of Charges

Sender’s Charges




�

Mapping rules

Line 1 Mapped to CONTBENLine 2 Mapped to CLIDST

Line 1 Mapped to MOTTRS1Line 2 Mapped to MOTTRS2Line 3 Mapped to MOTTRS3Line 4 Mapped to MOTTRS4

Mapped to INDDSP

1º Currency Mapped toCDVDEMI11º Amount Mapped toDESPEMI12º Currency Mapped toCDVDEMI22º Amount Mapped toDESPEMI23º Currency Mapped toCDVDEMI33º Amount Mapped toDESPEMI34º Currency Mapped toCDVDEMI44º Amount Mapped toDESPEMI45º Currency Mapped toCDVDEMI55º Amount Mapped toDESPEMI5

Currency Mapped toCDVDBRECAmount Mapped to DESPBREC

Line 1 Mapped to INFO1Line 2 Mapped to INFO2Line 3 Mapped to INFO3Line 4 Mapped to INFO4Line 5 Mapped to INFO5Line 6 Mapped to INFO6

Line 1 Mapped to REGLTRY1Line 2 Mapped to REGLTRY2Line 3 Mapped to REGLTRY3

National RTGS

Field Description

FIELD TAG = CONTBENof message 52FIELD TAG = CLIDSTof message 52



FIELD TAG = CDVDEMI1of the addenda message 2FIELD TAG = DESPEMI1of the addenda message 2FIELD TAG = CDVDEMI2of the addenda message 3FIELD TAG = DESPEMI2of the addenda message 3FIELD TAG = CDVDEMI3of the addenda message 3FIELD TAG = DESPEMI3of the addenda message 3FIELD TAG = CDVDEMI4of the addenda message 5FIELD TAG = DESPEMI4of the addenda message 5FIELD TAG = CDVDEMI5of the addenda message 5FIELD TAG = DESPEMI5of the addenda message 5

FIELD TAG = CDVDBRECof the addenda message 2FIELD TAG = DESPBRECof the addenda message 2


FIELD TAG = REGLTRY1of the addenda message 2FIELD TAG = REGLTRY2of the addenda message 4FIELD TAG = REGLTRY3of the addenda message 5

Interlinking MT198


Field

913

13C

20

21

32A

52A

56A

57A

58A

72

Description

Time stamp

Time indication


Related Reference



Intermediary




�

Mapping rules

Mapped to TSDEBITO

Line 1 Mapped to INFTIME1Line 2 Mapped to INFTIME2Line 3 Mapped to INFTIME3Line 4 Mapped to INFTIME4Line 5 Mapped to INFTIME5

Mapped to TRNORD

Mapped to RELTRN

Value date is mapped to DT-LIQAlways EURAmount mapped to IMPORT

Line 1 Mapped to INFBDEBLine 2 Mapped to ESWORD

Line 1 mapped to CONTBRLine 2 mapped to ESWFBR

Line 1 mapped to CONTBDLine 2 mapped to ESWFBD

Line 1 mapped to CONTBBLine 2 mapped to ESWBEN

Line 1 mapped to INFO1Line 2 mapped to INFO2Line 3 mapped to INFO3Line 4 mapped to INFO4Line 5 mapped to INFO5Line 6 mapped to INFO6

National RTGS

Field Description




FIELD TAG = RELTRNof message 52





FIELD TAG = CONTBBof the addenda message 1FIELD TAG = ESWBENof message 52


Interlinking MT198

12.2.3 MT202 7

7 The Interlinking message MT 202 is converted in one national message and two addenda messages.


12.2.4 PSMN



The routing rule is as follows: FIELD TAG = PAÍCTP of message 63 isIdentify if the country code of the receiver is providedprovided in the original message. PAÍCTP of message 63 is the country code ofIf yes, route the message to the related National the receiverCentral Bank FIELD TAG = FIRST_OF {ESWFBR,Otherwise identify the first credit field between ESWFBD, ESWBEN}ESWFBR, ESWFBD, ESWBEN. Identify the POSITION (5th to 6th) (FIRST_OF {ESWFBR,country code on that BIC (position 5th to 6th). ESWFBD, ESWBEN}Route the message to the related National The country code defined above is the countryCentral Bank. code of the receiver

Field

900

913

901

910

990

991

72

Description


Time stamp



Acceptance code



�

Mapping rules

Not mapped

Not mapped

Not mapped

Not mapped

Transformed in CODEST

Transformed in CRTARGET

Not mapped

National RTGS

Field Description

FIELD TAG = CODESTof message 53

FIELD TAG = CRTARGETof message 53



13 Suomen Pankki


13.1.1 MT100

Field

20

32A

50

52A

56A

57A

59

70

71A

72

Description



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

Unchanged. TRN has to beunique for each CI within eachvalue day.

Unchanged

Unchanged

Unchanged if present, otherwiseBIC of the sender. Target‘return’ key is added.

Unchanged. Clearing-code//TACC, if present in the accountline, is removed. If SPFBFIHR orSPFBFITG then removed.

Unchanged. Clearing-code//TACC, if present in the accountline, is removed.

Unchanged

Unchanged

Unchanged

Unchanged. If the first fieldbegins with codeword /REC/ it isremoved, as it only containsBoF-RTGS relevant info.

National RTGS

Field Description

Interlinking MT198


Field

119

20

23B

23E

26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A

70

71A

71F

71G

72

77B

Description

STP Flag


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




�

Mapping rules

Unchanged


Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged




Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged


Unchanged

National RTGS

Field Description


Interlinking MT198

13.1.2 MT103(+)


Field

20

21

32A

52A

56A

57A

58A

72

Description


Related Reference



Intermediary




�

Mapping rules


Unchanged

Unchanged






National RTGS

Field Description

Interlinking MT198

13.1.3 MT202


Field

IIR

913

20

32A

50

52A

56A

57A

59

70

71A

72

Description


Time stamp



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged, except if same asreceiver of domestic SWIFT-message or SPFBFIHR orSPFBFITG, then removed.

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

Forwarded in Block 3 field 108

Interlinking MT198


13.2.1 MT100


13.2.2 MT103(+)

Field

119

913

20

23B

23E

26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A

70

71A

71F

71G

72

77B

Description

STP Flag

Time stamp


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged, except if same asreceiver of domestic SWIFT-message or SPFBFIHR orSPFBFITG, then removed.

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

Interlinking MT198


Field

IIR

913

20

21

32A

52A

56A

57A

58A

72

Description


Time stamp


Related Reference



Intermediary




�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged, except if SPFBFIHRor SPFBFITG or same as receiverof domestic SWIFT-message andaccount number line is empty, thenremoved.

Unchanged, except if SPFBFIHRor SPFBFITG or same as receiverof domestic SWIFT-message andaccount number line is empty, thenremoved.

Unchanged

Unchanged

National RTGS

Field Description

Interlinking MT198

13.2.3 MT202



If first bank field (i.e. 56A or 57A) is SPFBFIHR, 56A, 57A, 58Athen we look at the next bank field and route thepayment to the RTGS indicated by the countrycode in the BIC of the second bank field.If first bank field has //TACC (CC = CountryCode) in the account line, then we route thepayment to the RTGS indicated by the countrycode.Else we route the payment to the RTGS indicatedby the country code in the BIC of the first bankfield.


14 Sveriges Riksbank


14.1.1 MT100

Field

20

32A

50

52A

56A

57A

59

70

71A

72

Description



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged. It is checked if theBIC is in the BIC directory. Ifnot the message is sent back tothe sender. If this field is presentalso the field 57A must bepresent. Clearing-code //TACC,if present in the account line, isremoved.

Unchanged. If the BIC is notpresent or the BIC is not in theBIC directory, the message isreturned to the sender. Clearing-code //TACC, if present in theaccount line, is removed.

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description



Ordering Customer


Intermediary



Details of Payment

Details of Charges


Interlinking MT198


Field

119

20

23B

23E

26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A

70

71A

71F

71G

72

77B

Description

STP Flag


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged. It is checked if theBIC is in the BIC directory. Ifnot the message is sent back tothe sender. If this field is presentalso the field 57A must bepresent. Clearing-code //TACC,if present in the account line, isremoved.

Unchanged. If the BIC is notpresent or the BIC is not in theBIC directory, the message isreturned to the sender. Clearing-code //TACC, if present in theaccount line, is removed.

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

STP Flag


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




Interlinking MT198

14.1.2 MT103(+)


Field

20

21

32A

52A

56A

57A

58A

72

Description


Related Reference



Intermediary




�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged. It is checked if theBIC is in the BIC directory. Ifnot the message is sent back tothe sender. If this field is presentalso the fields 57A and the 58Amust be present.

Unchanged. If the BIC is not inthe BIC directory, the message isreturned to the sender. If thisfield is present also the field 58Amust be present.

Unchanged. If the BIC is not in theBIC directory, the message isreturned to the sender.

Unchanged.

National RTGS

Field Description


Related Reference







Interlinking MT198

14.1.3 MT202


Field

913

20

32A

50

52A

56A

57A

59

70

71A

72

Description

Time stamp



Ordering Customer


Intermediary



Details of Payment

Details of Charges


�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged. It is checked if theBIC is in the BIC directory andthat it belongs to one of theparticipants in the RIX-system.If not a negative PSMN is sentback to the sender. If this field ispresent also the field 57A mustbe present.

Unchanged. It is checked if theBIC is in the BIC directory. Ifthe field 56A is not present thenthis field must contain the BIC ofa participant in the RIX-system.If not a negative PSMN is sentback to the sender.

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description



Ordering Customer


Intermediary



Details of Payment

Details of Charges


Interlinking MT198


14.2.1 MT100


14.2.2 MT103(+)

Field

119

913

20

23B

23E

26T

32A

33B

36

50K

50A

52A

56A

57A

59

59A

70

71A

71F

71G

72

77B

Description

STP Flag

Time stamp


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged. It is checked if theBIC is in the BIC directory. Ifnot a negative PSMN is sent backto the sender.

Unchanged

Unchanged. It is checked if theBIC is in the BIC directory andthat it belongs to one of theparticipants in the RIX-system.If not a negative PSMN is sentback to the sender. If this field ispresent also the field 57A mustbe present.

Unchanged. It is checked if theBIC is in the BIC directory. Ifthe field 56A is not present thenthis field must contain the BIC ofa participant in the RIX-system.If not a negative PSMN is sentback to the sender.

Unchanged. It is checked if theBIC is in the BIC directory. Ifnot a negative PSMN is sent backto the sender.

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged

National RTGS

Field Description

STP Flag


Bank Operation Code

Instruction Code


Amount


Exchange Rate

Ordering Customer

Ordering Customer







Details of Charges

Sender’s Charges




Interlinking MT198


Field

913

20

21

32A

52A

56A

57A

58A

72

Description

Time stamp


Related Reference



Intermediary




�

Mapping rules

Unchanged

Unchanged

Unchanged

Unchanged

Unchanged. It is checked if theBIC is in the BIC directory. Ifnot a negative PSMN is sent backto the sender. If this field ispresent also the fields 57A and58A must be present.

Unchanged. It is checked if theBIC is in the BIC directory. Ifthe field 56A is not present thenthis field must contain the BIC ofa participant in the RIX-system.If not a negative PSMN is sentback to the sender. If this field ispresent also the field 58A mustbe present.

Unchanged. If neither the field56A nor the field 57A are presentthen this field must contain theBIC of a RIX participant. If nota negative PSMN is sent back tothe sender.

Unchanged

National RTGS

Field Description


Related Reference



Intermediary




Interlinking MT198

14.2.3 MT202


When a negative PSMN is received, than the original message (MT100 or MT202) is returnedto the originator – RIX participant.

All fields in the original message are left unchanged with the exception of the field 72.

The original content of the field 72 is overwrite with the following information:

Line 1: /RETN/ + field identifier of the field in which error occurred or 00

Line 2: /X + TARGET Rejection Code + Line number in field in which error occurred +occurrence in a repeating field + Signification

Line 3: /MRF/ + field 20 from the original message

14.2.4 PSMN

Field

900

913

901

910

990

991

72

Description


Time stamp



Acceptance code



�

Mapping rules

National RTGS

Field Description





MT100: Fields 56A or 57A or 58A.If field 56A is present routing is basedon the country code in the BIC-code (position5-6 of the BIC-code). If field 56A is notpresent than routing is based on the countrycode in the BIC-code in the field 57A (position5-6 of the BIC-code).

MT103:If field 56A is present routing is basedon the country code in the BIC-code (position5-6 of the BIC-code). If field 56A is notpresent than routing is based on the countrycode in the BIC-code in the field 57A (position5-6 of the BIC-code).

MT202:If field 56A is present, routing is basedon the country code in the BIC-code (position5-6 of the BIC-code). If field 56A is notpresent than routing is based on the countrycode in the BIC-code in the field 57A (position5-6 of the BIC-code).If neither field 56A nor field 57A are presentthan routing is based on the country code inthe BIC-code in the field 58A (position 5-6 ofthe BIC-code).

Remote access:If: //TA + country code of receiving NCB ispresent in the account line of first credit fieldthan routing is based on that information.


15 Bank of England


15.1.1 MT100



20 Transaction Reference unchanged Transaction ReferenceNumber of Sending NumberCredit Institution

32A Value date unchanged Value Date,Currency code Currency Code,Amount Amount

50 Ordering Customer unchanged Ordering Customer

52A Ordering Institution BIC subfield mapped unchanged from Ordering Institution,Ordering Institution (mandatory) Sender,Account number subfield formatted by Transaction Referenceconcatenating “//TA”, “GB”, Sender & NumberTransaction Reference Number

56A Intermediary unchanged Intermediary

57A Account with Institution unchanged Account With Institution

59 Beneficiary Customer unchanged Beneficiary Customer

70 Details of Payment unchanged Details of Payment

71A Details of Charges unchanged Details of Charges

72 Sender to Receiver unchanged Sender To ReceiverInformation Information


15.1.2 MT103(+)

119 STP Flag unchanged STP Flag


23B Bank Operation Code unchanged Bank Operation Code




33B Currency/Instructed unchanged Currency/InstructedAmount Amount

36 Exchange Rate unchanged Exchange Rate

50K Ordering Customer unchanged Ordering Customer

50A Ordering Customer unchanged Ordering Customer


56A Intermediary Institution unchanged Intermediary



59A Beneficiary Customer unchanged Beneficiary Customer

70 Remittance Information unchanged Remittance Information


71F Sender’s Charges unchanged Sender’s Charges

71G Receiver’s Charges unchanged Receiver’s Charges

72 Sender to Receiver Information unchanged Sender to Receiver Information

77B Regulatory Reporting unchanged Regulatory Reporting




15.1.3 MT202


21 Related Reference unchanged Related Reference



56A Intermediary unchanged Intermediary


58A Beneficiary Institution unchanged Beneficiary Institution






15.2.1 MT100

913 Time stamp mapped into Information to Receiver Information to Receiver(concatenated together with local settlement (field 115)time, Country Code & TRN of SendingCredit Institution)

20 Transaction Reference mapped into Information to Receiver Information to ReceiverNumber of Sending (concatenated together with local settlement (field 115)Credit Institution time, other NCB’s settlement time &

Country Code)


50 Ordering Customer unchanged Ordering Customer

52A Ordering Institution BIC subfield – mapped unchanged to Ordering Ordering Institution,Institution (mandatory) Sender’s CorrespondentAccount Number subfield – Country Code and (field 53A)Transaction Reference Number are not mappedas the same information is obtained fromelsewhere. Participant’s BIC is mappedunchanged to Sender’s Correspondent

56A Intermediary if present and not a direct participant, mapped Intermediaryunchanged into Intermediary, with the (or Receiver)corresponding direct participant mapped intoReceiverif present and a direct participant, mapped intoReceiver (with default branch code added ifa BIC-8)

57A Account with Institution mapped unchanged to Account With Institution. Account With Institutionif Intermediary is missing, then (a) if a direct (also Receiver)participant, also mapped into Receiver (withdefault branch code added if a BIC-8),or (b) if not a direct participant, thecorresponding direct participant mapped intoReceiver


70 Details of Payment unchanged Details of Payment






15.2.2 MT103(+)



119 STP Flag unchanged STP Flag



Country Code)

23B Bank Operation Code unchanged Bank Operation Code



32A Value date unchanged Value Date,Currency code, Currency code,Amount Amount

33B Currency/Instructed Amount unchanged Currency/Instructed Amount

36 Exchange Rate unchanged Exchange Rate

50K Ordering Customer unchanged Ordering Customer

50A Ordering Customer unchanged Ordering Customer

52A Ordering Institution BIC subfield – mapped unchanged to Ordering Ordering Institution,Institution (mandatory) Sender’s CorrespondentAccount Number subfield – Country Code (field 53A)and Transaction Reference Number are notmapped as the same information is obtainedfrom elsewhere. Participant’s BIC is mappedunchanged to Sender’s Correspondent

56A Intermediary Institution if present and not a direct participant, mapped Intermediaryunchanged into Intermediary, with the (or Receiver)corresponding direct participant mapped intoReceiverif present and a direct participant, mapped intoReceiver (with default branch code added ifa BIC-8)

57A Account with Institution mapped unchanged to Account With Institution. Account With Institutionif Intermediary is missing, then (a) if a direct (also Receiver)participant, also mapped into Receiver(with default branch code added if a BIC-8),or (b) if not a direct participant, thecorresponding direct participant mappedinto Receiver


59A Beneficiary Customer unchanged Beneficiary Customer

70 Remittance Information unchanged Remittance Information


71F Sender’s Charges unchanged Sender’s Charges

71G Receiver’s Charges unchanged Receiver’s Charges

72 Sender to Receiver Information unchanged Sender to Receiver Information

77B Regulatory Reporting unchanged Regulatory Reporting


15.2.3 MT202



Country Code)

21 Related Reference unchanged Related Reference


52A Ordering Institution BIC subfield – mapped unchanged to Ordering Institution,Ordering Institution (mandatory) Sender’s CorrespondentAccount Number subfield – Country Code (field 53A)and Transaction Reference Number are notmapped as the same information is obtainedfrom elsewhere. Participant’s BIC is mappedunchanged to Sender’s Correspondent

56A Intermediary if present and not a direct participant, mapped Intermediaryunchanged into Intermediary, with the (or Receiver)corresponding direct participant mapped intoReceiverif present and a direct participant, mapped intoReceiver (with default branch code added ifa BIC-8)

57A Account with Institution if Intermediary is present, Account With Account With InstitutionInstitution mapped unchanged to Account (or Receiver)with Institutionotherwise, if Intermediary is missing andAccount with Institution is present, then(a) if a direct participant, mapped into Receiver(with default branch code added if a BIC-8), or(b) if not a direct participant, mappedunchanged to Account with Institution and thecorresponding direct participant mapped intoReceiver

58A Beneficiary Institution mapped unchanged to Beneficiary Institution, Beneficiary Institutionif Account with Institution is missing, then (also Receiver)(a) if a direct participant, mapped into Receiver(with default branch code added if a BIC-8), or(b) if not a direct participant, the correspondingdirect participant mapped into Receiver

72 Sender to Receiver unchanged Sender to ReceiverInformation Information




15.2.4 PSMN



CHAPS Euro to TARGET The TARGET BIC of the receiving NCB/ECB Receiver’s Correspondentmust be inserted into Receiver’s Correspondent (Field 54A)of the CHAPS Euro payment. If valid, thisfield is mapped directly to the Receiver fieldof the TARGET payment (with default branchcode added if a BIC-8).No validation is performed on Fields 56A,57A, 58A other than that they exist in the BICDirectory.

900 Interlinking Internal Reference not mapped

913 Time stamp not mapped

901 Referred Interlinking not mappedInternal Reference

910 ECB date and time of receipt not mapped

990 Acceptance code mapped unchanged into Accept/Reject Accept/Reject(field 451) of Outward TARGET SettlementStatus Message (MT298/001).This is a proprietary CHAPS Euro messagesent to notify the sending direct participant thatthe outward TARGET payment has completed

991 Reason code for rejection inserted into the line 2 codeword (preceded Sender to Receiverby “X”) of field 72 of the corresponding Informationreturn CHAPS Euro MT202 payment

72 Sender to receiver information not mapped




ACK – See positive acknowledgement.

ARTIS – The Austrian Real-Time Interbank Settlement system; this is Austria’s RTGSsystem. See also RTGS system.

Authentication – A generic term for a check performed to ensure that two parties arecommunicating with each other and not with a fraudulent third party. Successful authenticationof SWIFT messages also confirms that the message content has not been changed duringtransmission.

Bank Identifier Code – A universal method of identifying financial institutions in order tofacilitate the automated processing of telecommunication messages in financial environments.

BI-REL – The Banca d’Italia Regolamento Lordo; this is Italy’s RTGS system. See also RTGSsystem.

BIC – See Bank Identifier Code.

BIC Directory – The official reference book in which the BICs are published, which is alsoavailable in electronic form.

BKE – Bilateral Key Exchange.

BoF RTGS – The Bank of Finland Interbank Funds Transfer System; this is Finland’s RTGSsystem. See also RTGS system.

Business Calendar – This calendar, compiled by the ECB on the basis of information fromnational central banks, includes all operating dates and times of RTGS systems participating inTARGET/EPM.

CBT – See Computer-based terminal.

CHAPS Euro – The Clearing House Automated Payment System; this is the United Kingdom’seuro RTGS system. See also RTGS system.

Checksum – A method used to check that no data have been lost or changed during thecommunication process.

CI – See credit institution.

CLS – Continuous Linked Settlement is a cross-border settlement service in major globalcurrencies provided by CLS Bank (CLSB).

Computer-based terminal – A network interface device, provided and operated by theuser, consisting of both hardware and software.

Confidentiality – The characteristic of that data which are not to be disclosed to those notauthorised to see them.

Contingency procedures – Procedures to ensure that a minimum service is provided in theevent of an operational failure (e.g. in the event of the failure of a secondary site).

Glossary of terms


Correspondent banking – An arrangement under which one bank provides payment andother services to another. Payments through correspondents are often executed throughreciprocal accounts (“nostro” and “loro” accounts), to which standing credit lines may beattached. Correspondent banking services are primarily provided across international borders.

Counterparty – The opposite party in a financial transaction (e.g. in a transaction with thecentral bank).

Credit institution – In this document this refers to an institution covered by the definitioncontained in Article 1 (1) of Directive 200/12/EC of the European Parliament and of theCouncil of 20 March 2000, i.e. “an undertaking whose business is to receive deposits or otherrepayable funds from the public and to grant credit for its own account”.

Cross-border payments – Payments involving at least one party which is non-resident.

CSD – Central Securities Depository.

Customer transfer – A payment where either the ordering customer, the final beneficiarycustomer or both are non-financial institutions.

Cut-off time – The deadline for performing a given action on a given day (e.g. for acceptingpayment messages from RTGS participants).

Domestic payments – Payments where only resident parties are involved.

EBA – See Euro Banking Association.

EBA clearing banks – Settlement banks for the EBA’s Euro 1 system.

ECB – The European Central Bank.

ELLIPS – The Electronic Large-value Interbank Payment System; this is Belgium’s RTGSsystem. See also RTGS system.

Encryption – A process whereby the characters which constitute a readable message areencoded using a cipher so as to render that message unintelligible to other parties.

End-to-end encryption – A method used to ensure the confidentiality of data at theapplication level; the encryption algorithms are implemented together with the application.

EPM – The ECB payment mechanism, although this is not an RTGS system, it is a participantin TARGET.

ESCB – See European System of Central Banks.

Euro area – The geographical area covered by those EU countries which have adopted theeuro as their currency.

Euro Banking Association – An association which, on behalf of its members, i.a. maintainsthe EURO 1 clearing system.


European System of Central Banks – In this document this refers to the EuropeanCentral Bank and the national central banks of the EU Member States.

Fallback – The process of returning to the mode of operation, or of network connection,previously used, in the event of a serious problem.

Field – A data element for which the identification, description and value representation havebeen pre-defined. Each element constitutes an indivisible unit. Where a field consists of morethan one element, each forms a sub-field.Fields may be:• Fixed or variable in length;• Mandatory or optional;• Restricted in terms of the character set which may be used.A field can appear only once in a message, unless the rules specify otherwise. Some fieldsconsists of several sub-fields.

FIN – See Financial application.

Financial application – The SWIFT II application within which all SWIFT II user-to-usermessages are input and output. Certain user-to-SWIFT and SWIFT-to-user messages may alsobe sent and received within FIN.

FOREX – foreign exchange.

Format – The rules governing the layout; e.g. for a message type or a field within a messagetype.

Format checking – That part of SWIFT processing which checks that a message formatconforms to the rules for the type of message concerned.Such checks include, among others:• presence of mandatory fields;• absence of forbidden fields;• field length restrictions;• character restriction.

General purpose message – See Interlinking free format message.

Header – That part of the message envelope which precedes the message text. Its primepurpose is to identify the receiver to SWIFT and the sender to the receiver. The sender andthe receiver are identified only in the header. The information contained in the header isnetwork dependent.

HERMES – The Hellenic Real-time Money transfer Express System; this is the Greek RTGSsystem. See also RTGS system.

ICC – See Interlinking communication component.

IL – See Interlinking System.

ILC – The Interlinking component.


Integrity – The characteristic of data whereby they have not been deleted, changed, added toor otherwise tampered with.

Interbank payments – Transfers of funds where all parties involved are credit institutions.

Interlinking processing component – The component used to implement validation andother Interlinking processes and to communicate with the domestic RTGS system processingcomponents.

Interlinking system – The infrastructure and procedures which are used within each RTGSsystem or in addition to the RTGS systems to process cross-border payments within TARGET.

Intraday credit – Credit extended and reimbursed within a period of less than one businessday. The ESCB will extend intraday credit (based on eligible assets) to eligible counterparties forpayment systems purposes.

Intraday liquidity – Available funds consisting in intraday credit plus cash balances.

IPC – See Interlinking processing component.

IRIS – The Irish Real-time Interbank Settlement system; this is Ireland’s RTGS system. Seealso RTGS system.

ISO – International Standards Organisation.

KMA – Key manager authority.

KRONOS – Denmark’s RTGS system for EUR and DKK. See also RTGS system.

Large-value payments – Payments, usually but not always interbank ones, for large amounts.

Line encryption – A method used to ensure the confidentiality of data at the communicationlevel; the encryption algorithms are implemented outside the application (e.g. in an encryptionbox).

LIPS-Gross – The Luxembourg Interbank Payment System/Gross settlement; this isLuxembourg’s RTGS system. See also RTGS system.

MAC – Message authentication code.

Message – A collection of data in SWIFT format, consisting of a header (and optionally, textand footers) sent by a user or by SWIFT.

Message category – A group of message types in SWIFT relating to a particular class oftransaction, as indicated by the first digit of the MT number.

Message priority – In SWIFT, a one-letter code assigned by the sender of a message toindicate the priority of the message. Possible values are: S (System), U (Urgent), and N(Normal).

Message text standard – The rules laid down for the format and content of a particularmessage.


Message type – The specification of each Interlinking message by a three-digit numbershowing the major area (category), the function (group) and the specific details (format).There is a set of rules for each message type.

Message User Reference – A free-format field in the optional user header, allowing thesender to add its own reference of up to 16 characters.

Monetary policy operations – Either liquidity-providing or liquidity-absorbing operations,executed by national central banks with the banking system, with a view to achieving theobjective of price stability.

MT – See message type.

MUG – See message user group.

NAK – See negative acknowledgement.

Narrative – This field may contain any kind of instruction or information.

National central bank – Refers in this document to a central bank of an EU Member Statein accordance with the Treaty.

NCB – See national central bank.

Negative acknowledgement – A negative acknowledgement, sent by the system to thesender of an input message, notifying them that their message has been rejected. The reasonfor rejection is indicated by an error code. In the case of a payment message, the senderremains responsible for the payment.

Net settlement system – A payment system in which payment orders may be exchangedon a multilateral or bilateral basis over a given period of time, but do not become final untilthe net settlement balances of the participants have been settled after the end of a definedperiod.

Non-delivery warning – A system-generated message, warning that a payment message, forwhich delivery monitoring has been requested, has not been delivered within the obsolescenceperiod specified for that message.

Non-euro area – The geographical area covered by those EU countries which have notadopted the euro as their currency.

Non-repudiation – A principle according to which the receiver of a message cannot denyhaving received that message, and the sender cannot deny having sent it.

NSS – See net settlement system.

Obsolescence period – A period of time, expressed in units of five minutes and specified bythe sending user, after which, if that message remains undelivered, a non-delivery warning isgenerated and sent to the sender.

OPC – SWIFT’s operating centre.


Operating dates and times – Information exchanged in the end-of-day messages betweenthe ECB and the other participants, in order to confirm the operational involvement of eachTARGET participant for the next three business days. The times refer to the moments atwhich the participants will be ready to start accepting Interlinking payments (start of day) andthe final cut-off for sending Interlinking payments (end of day).

Payment settlement message notification – The response to a PSMR, which can beeither positive or negative. In the case of a positive PSMN, responsibility is passed over to thereceiver, in the case of a negative PSMN the sender remains responsible for the payment.

Payment settlement message request – The sender of such a message is requesting thatthe receiver process a payment. This message requires a positive or negative response fromthe receiver.

PDE trailer – A possible duplicate emission trailer. This user trailer warns the receiver thatthe same message may already have been input and received via SWIFT.

Positive acknowledgement – A positive acknowledgement, sent by the receiving system tothe sender, that a request message has been successfully processed.

Proprietary message – This SWIFT message type is used for formats defined and agreedbetween users for those messages not (yet) live.

PSMN – See payment settlement message notification.

PSMR – See payment settlement message request.

PSTN – public switched telephone network.

RCC – See RTGS communication component.

Regional processor – The node of the SWIFT II system which is primarily responsible forinput message validation and output message queues.

Remote access – Describes connection to an RTGS system which is not located in thehome country of the credit institution.

RIX – The RIX system; this is Sweden’s RTGS system. See also RTGS system.

RP – See regional processor.

RPC – See RTGS system processing component.

RTGS communication component – The component within the RTGS system used forimplementing the communication process with its participants.

RTGS operator – A function assumed by a person or persons in each RTGS systemparticipating in TARGET/EPM, who is/are responsible for the daily operation of the domesticand/or cross-border RTGS system.

RTGS participants – Credit institutions which have satisfied the access criteria for obtaininga settlement account in the RTGS system.


RTGS processing component – A component within the RTGS system used forimplementing the processing of payments at the domestic level.

RTGS system – Real-time gross settlement system.

RTGSplus – Germany’s RTGS system. See also RTGS system.

SWIFT – Society for World-wide Interbank Financial Telecommunication.

SWIFT access point – The local node of the distributed SWIFT II network, primarily usedto provide users’ connections, input message validation, and output message queues.

SWIFT character set – This character set is described in the SWIFT User Handbook“Standards – General Information”.

SWIFT field – See Field.

SWIFT transport network – The collection of SWIFT-controlled equipment and circuits,located world-wide, which provides the user organisation with access to SWIFT services, byfacilitating physical communication between user CBTs and SWIFT sites.

SAK – SWIFT acknowledgement that, a syntactically correct payment message has reachedthe network.

SAP – See SWIFT access point.

SCC – See system control centre.

SCP – See System Control Processor.

Securities settlement system – A system in which stocks, bonds and other assets areexchanged.

Settlement account – An account which is only used for TARGET/RTGS payments.

Settlement manager – A function assumed by a person or persons in each RTGS systemparticipating in TARGET/EPM who has/have overall responsibility for all decisions relating toTARGET day-to-day operation and management within the system concerned.

SLBE – The Servicio de Liquidación del Banco de España; this is Spain’s RTGS system. Seealso RTGS system.

SPGT – The Sistema de Pagamentos de Grandes Transaccoes; this is Portugal’s RTGSsystem. See also RTGS system.

SSS – See securities settlement system.

STN – See SWIFT transport network.

Sub-field – A data element which constitutes the smallest indivisible unit within a field andconsisting of more than one data element. A group of two or more sub-fields constitutes afield.


System control centre – One of the two manned sites from which the SWIFT II system isoperated and controlled.

System Control Processor – A large computer, within the SWIFT II network, whichmonitors and controls the entire SWIFT II network as well as access to that network.

System message – A message from a user to SWIFT or from SWIFT to a user.

Tag – A two-digit identifier for a field, sometimes followed by a letter. It marks the presenceand start of the field. A letter indicates the format option chosen for the field.

TARGET (Trans-European Automated Real-time Gross settlement ExpressTransfer) system – A payment system consisting of one real-time gross settlement (RTGS)system in each of the Member States participating in the euro area at the start of Stage Three ofEconomic and Monetary Union. The national RTGS systems are interconnected via theInterlinking mechanism so as to enable same-day cross-border transfers throughout the euroarea. RTGS systems of non-euro area EU Member States may also be connected to TARGET,provided that they are able to process euro.

TARGET business day – Any day other than a Saturday or Sunday on which the TARGETsystem is defined as being operational to effect payments (when at least two RTGS systemsare open).

TBF – Transferts Banque de France; this is France’s RTGS system. See also RTGS system.

Terminal – Any communication equipment approved by SWIFT which is connected to aSWIFT regional processor.

Text – That part (Block 4) of a SWIFT II message which contains the substance of themessage. The text format varies according to the message type in question. It is enclosedbetween the header and the trailer.

TOP – The Netherlands’ RTGS system. See also RTGS system.

Trailer – That part of a message envelope which follows the message text. It provides thereceiver with additional information about the message. The information contained in theheader is network dependent.

Transaction reference number – Field 20 in all messages. The sender’s unambiguousidentification of the transaction. Details of its form and content are at the discretion of thesender.

TRN – See transaction reference number.

Validation – The class of check performed by the SWIFT system upon data transmitted toensure that such data conform to the standards laid down in the SWIFT User Handbook andelsewhere.

X.25 – The standardised communication protocol for the networked computers.