Dissecting SWIFT Message Types

involved in payments
In my current company, we implement a state-of-the art banking Fraud
Detection system using an Artificial Intelligence running on a Big Data
Analytics platform. When working on preventing banking fraud, looking at
SWIFT messages is extremely interesting. 98% of all cross-border
(international) funds transfers are indeed transferred using the SWIFT
Network.
The SWIFT network enables financial institutions worldwide to send and
receive information about financial transactions in a secure, standardized
and reliable environment. Many different kind of information can be
transferred between banking institution using the SWIFT network.

In this article, I intend to dissect the key SWIFT Messages Types involved
in funds transfers, present examples of such messages along with use
cases and detail the most essential attributes of these payments.

These key messages are as follows:

MT 101 - Request for Transfer

MT 103 - Single Customer Credit Transfer
MT 202 - General Financial Institution Transfer
 MT 202 COV - General Financial Institution Transfer for Cover
payments

This article presents each and every of these messages, discuss their
typical use cases and details key SWIFT fields involved.

Summary

1. Introduction to SWIFT
1.1 Key SWIFT aspects
1.2 Correspondent banking
1.2.1 Correspondent Bank
1.2.2 Transferring Money Using a Correspondent Bank
1.2.3 VOSTRO and NOSTRO accounts
1.3 Key SWIFT Message Types
1.3.1 Detailed presentation of key SWIFT messages
1.3.2 Typical situation and use cases in banking institutions
1.4 Serial and cover payments
1.4.1 Cover method details
1.4.2 Serial method details
1.5 SWIFT Message Structure
1.6 SWIFT BIC Code
1.6.1 Structure of the SWIFT BIC Code
1.7 Other specific details
2. Dissecting key SWIFT Mesages involved in payments (Funds
Transfers)
2.1 SWIFT MT101 Detailed Analysis
2.1.1 MT101 Introductory examples
2.1.1.1 MT101 Example 1: Simplest case
2.1.1.2 MT101 Example 2: beneficiary with another
institution
2.1.1.3 MT101 Example 3: Multiple payments in MT101
2.1.1.4 MT101 Example 4: Payment from a subsidiary
account
2.1.1.5 MT101 Example 5: Fund repatriation
 2.1.2 MT101 Parsing and Data Mapping
2.1.3 Additional notes on MT101
2.2 SWIFT MT103 Detailed Analysis
2.2.1 MT103 Introductory examples
2.2.1.1 MT103 Example 1: Simplest case
2.2.1.2 MT103 Example 2: more realistic example
2.2.1.3 MT103 Example3: forwarded serial message
2.2.1.4 MT103 Example 4: Announce message (cover
method)
2.2.2 MT103 Parsing and Data Mapping
2.2.3 Additional notes on MT103
2.3 SWIFT MT202 Detailed Analysis
2.3.1 SWIFT MT202 Introductory Exampkes
2.3.1.1 MT202 Example 1: simplest case
2.3.1.2 MT202 Example 2: other bank case
2.3.1.3 MT202 Example 3: routed message
2.3.2 MT202 Parsing and Data Mapping
2.3.3 Additional notes on MT202
2.4 SWIFT MT202 COV Detailed Analysis
2.4.1 MT202 COV Introductory examples
2.4.1.1 MT202 COV Example: Cover payment
2.4.2 MT202 COV Parsing and Data Mapping
2.4.3 Additional notes on MT202 COV
3. Conclusion

1. Introduction to SWIFT
SWIFT - Society for Worldwide Inter-bank Financial Telecommunication -
is a Belgian company, located in Belgium, and is a trusted and closed
network used for communication between banks around the world. It is
overseen by a committee composed of the US Federal Reserve, the Bank
of England, the European Central Bank, the Bank of Japan and other major
banks.
SWIFT is used by around 11 thousands institutions in more than 200
countries and supports around 25 million communications a day, most of
them being money transfer transactions, the rest are various other types
of messages.

The majority of international inter-bank messages use the SWIFT network.

SWIFT does not facilitate funds transfer: rather, it sends payment orders,
which must be settled by correspondent accounts that the institutions
have with each other. For two financial institutions to exchange banking
transactions, they must have a banking relationship beforehand.

1.1 Key SWIFT aspects

Internationally standardized messaging means that every transaction

between every financial institution is recorded in exactly the same way,
providing all the details in a clear and transparent manner.
Every financial institution has its own unique code that provides
information on the name and location of the bank. Each transaction
contains a unique reference number, bank operation code and details of
charges incurred during the transaction.

Because SWIFT uses internationally standardized messages, it is a

transparent way for institutions to communicate between each other and
securely relay the details of any transaction. There are a number of known
benefits to using SWIFT:

Transparency. SWIFT payments clearly detail the amounts involved in

the transaction, the route it takes between banks, the details of all
charges and the nature of the payment (along with many other
details). This information allows all parties involved to track the
transaction and to understand the costs and time period involved.
Traceability. Because SWIFT details the route of the transaction
between banks and the amount of money involved, it provides clear
and recognized proof of payment.
Consistency. Due to the consistency of how messages are
structured, payment information is easy to decipher regardless of
 country or language barriers.

1.2 Correspondent banking

Correspondent banking is an important aspect of international banking

and a key concept underneath the SWIFT network.

1.2.1 Correspondent Bank

A correspondent bank is a financial institution that provides services on

behalf of another financial institution. It can facilitate wire transfers,
conduct business transactions, accept deposits and gather documents on
behalf of another financial institution. Correspondent banks are most likely
to be used by domestic banks to service transactions that either originate
or are completed in foreign countries, acting as a domestic bank's agent
abroad.

Generally speaking, the reasons domestic banks employ correspondent

banks include:

limited access to foreign financial markets and the inability to service

client accounts without opening branches abroad,
act as intermediaries between banks in different countries or as an
agent to process local transactions for customers abroad,
accept deposits, process documentation and serve as transfer
agents for funds.

The ability to execute these services relieves domestic banks of the need
to establish a physical presence in foreign countries.

1.2.2 Transferring Money Using a Correspondent Bank

International wire transfers often occur between banks that do not have an
established financial relationship. When agreements are not in place
between the bank sending a wire and the one receiving it, a
correspondent bank must act as an intermediary. For example, a bank in
Geneva that has received instructions to wire funds to a bank in Japan
cannot wire funds directly without a working relationship with the
receiving bank.
Most if not all international wire transfers are executed through SWIFT.
Knowing there is not a working relationship with the destination bank, the
originating bank can search the SWIFT network for a correspondent bank
that has arrangements with both banks.

Interestingly, when a bank wants to send some funds to another bank on

the other side of the world, it happens often that the sending bank has no
banking relationships with any bank having itself a relationship with the
target bank. In this case, the order needs to be transferred through
several, sometimes many, distinct banking institutions through the SWIFT
network.
These intermediate banks are called routing banks.

1.2.3 VOSTRO and NOSTRO accounts

General usage of NOSTRO/VOSTRO (they refer to the same account but

different bank perspective):
A NOSTRO account is a reference used by Bank A to refer to "our"
account held by Bank B. NOSTRO, is a shorthand way of talking about
"our money that is on deposit at your bank."
VOSTRO is the term used by Bank B, where bank A's money is on deposit.
VOSTRO is a reference to "yours" and refers to "your money that is on
deposit at our bank."

1.3 Key SWIFT Message Types

When it comes to fund transfers, only a subset of the SWIFT messages

are relevant:

Message Identification and Reference

Space
Name document
Customer-to-Bank
MT 101 Request for Transfer
and Interbank
MT 103 Single Customer Credit
Interbank
 Transfer
Standards MT
MT 202 General Financial November 2018
Interbank
Institution Transfer
MT 202 COV General Financial
Interbank
Institution Transfer
MT 9XX - Confirmations and Customer-to-Bank
statements and Interbank

1.3.1 Detailed presentation of key SWIFT messages

These SWIFT messages are described as follows:

The SWIFT MT101 message is a request for transfer, enabling the

electronic transfer of funds from one account to another. Funds are
transferred from ordering customers account to a receiving financial
institution or account servicing financial institution. For us right now,
the important thing to note is that the message format that enables
this transfer is the SWIFT MT101 format.
The MT103 is a SWIFT message format used for making payments.
MT103 SWIFT payments are known as international wire transfers,
telegraphic transfers, standard EU payments (SEPA payments), LVTS
in Canada, etc.
Swift MT202 Requests the movement of funds between financial
institutions, except if the transfer is related to an underlying customer
credit transfer that was sent with the cover method, in which case the
MT 202 COV must be used.
MT202 COV is a SWIFT message format for financial institution (FI)
funds transfer between financial institutions. MT202's are used
primarily for two purposes, bank-to-bank payments (i.e. interest
payments and settlement of FX trades) and Cover Payments.
MT202 COV was implemented in 2009 to create traceability of the
origination of funds (institution and account) through to the
destination of funds (institution and account.) This was in response to
anti-money laundering and associated banking requirements.
Prior to MT202 COV, The message format, MT202, did not include
origination/destination financial institution information. Particularly for
 Cover Payments, where a combination of MT103 and MT202 are
used to direct funds transfers to a beneficiary account, the
intermediate banks in the MT202 had no ability to understand and
perform risk analysis/AML/compliance checks on the funds transfer
based on the original and destination of the funds. Thus, intermediate
banks could be unwittingly involved in illegal transactions under new
regulations.

1.3.2 Typical situation and use cases in banking institutions

In regards to this set of messages, the various situations that a banking

institution is confronted to can be represented as follows:

With the following details:

A customer can request a fund transfer on his behalf using either a

bank native channel (email, EBanking, branch, etc.) or by sending an
MT101 to the bank. Big corporate customers can indeed be
connected themselves to the bank network and send requests to the
bank using the MT101 Message Type which is intended for this
purpose.
Most of the time, the reception of an MT101 by the bank will make it
issue an MT103 to proceed further with the Fund Transfers. But if the
account to be debited is not by the bank, it can as well transfer the
MT101 further to the other institution owning the account to be
 debited.
MT103 are sent following a customer request to transfer the funds
further (serial method) or announce to the receiving institution that
the funds will be coming following an MT202.COV (cover method).
An MT202 is sent on behalf of bank itself and not following a
customer request, in contrary to MT103.
If the bank is a routing bank in the middle of a routing chain, MT103
and MT202 are sent further. Actually new messages are sent, the
sent MT103 or MT202 can be different than the received one.

1.4 Serial and cover payments

SWIFT Serial and Cover payments originate from the two methods that are
used to settle transactions in the SWIFT network and specifically in the
field of correspondent banking: Serial method and Cover method.
When sender and receiver are located in different currency zones, they
send or receive funds through their correspondents. And in this case,
either of both methods can be used.

With the cover method, two different messages are initiated by the sender
to settle the funds, an MT103 and an MT202.COV. The MT101 message is
used to inform the creditor bank that funds are coming, it is an
announcement. The MT202.COV, called cover message, moves the funds
between correspondent accounts.
With the serial method, one single message is initiated by the sender to
settle the funds, an MT103. That MT103 is in this case not an announce,
but the fund transfer itself that moves for one party to the next in the
payment chain until it reaches the beneficiary bank.

1.4.1 Cover method details

The MT103 announcement is sent to the beneficiary bank to announce

that funds are coming for a specific beneficiary. It does not carry the
funds but rather just informs the bank of the beneficiary that funds are
coming for which beneficiary customer and which correspondent (of the
beneficiary bank) will receive the funds.
The cover payment (MT202 COV) is sent by the sender to its
correspondent. This is the message that really moves the funds. The
MT202 COV enables the sender to ask its correspondent to debit its
account (of the sender, with the correspondent) and credit the beneficiary
bank's account with its correspondent.

Most of the time, the announcement is created and sent before the cover
but that is not a requirement so receiving the cover payment before the
announce is a situation that needs to be taken into account by the
receiver.

1.4.2 Serial method details

Using an MT103, the funds moves from one party to another until it
reaches the final beneficiary. Following a customer request, the sender
sends an MT103 serial to its correspondent which transfers the funds to
the intermediary institution. The intermediary institution is the
correspondent of the beneficiary most of the time. The intermediary
institution on its turn credits the account of the creditor bank and
eventually the beneficiary account.

In the SWIFT MT103 Serial Message, the fields 56a and 57a are used
while the fields 53a and 54a are used in the MT103 Announcement
Message (cover method).
Intermediary institution and receiver's correspondent are usually two
names to designate the same thing. The account with institution is the
bank that holds the beneficiary account, so just another name for Creditor
bank.

1.5 SWIFT Message Structure

This section presents how an ISO 15022 message looks like and
decomposes it to its particular parts. The description of the structure is
intended as a guidance to build a SWIFT message parser.

A message consists of blocks enclosed in curly braces. The first colon

separates the block name and content. The block content can consist of
sub-blocks.

Mandatory
Block Block
or Description Comments
Ident. Name
Optional
The only mandatory
block is the basic
header. The basic
header contains the
Common to all
general information
SWIFT messages.
Basic that identifies the
1 M It contains five
Header message, and some
fields that are all
additional control
mandatory.
information. The FIN
interface automatically
builds the basic
header.
The application header Common to all
contains information SWIFT messages.
that is specific to the There are two
application. The variations: One
application header is block for input
Application required for messages messages which
2 O
Header that users, or the may contain up to
system and users, six fields and one
exchange. Exceptions for output
are session messages which
establishment and may have up to
session closure. seven fields.
Common to all
SWIFT messages.
All fields of the
user header
User The user header is an (except the tag
3 O
Header optional header. 103 for FINCopy
Service) are
optional. Fields
are populated in
specific situations.
This is the block
The text is the actual found in the
 4 Text O data to transfer. Message
Reference Guide.

Common to all
The trailer either SWIFT messages.
indicates special Like the block 3,
circumstances that this block consists
5 Trailers O
relate to message of only non-
handling or contains mandatory fields
security information. except the
checksum.

The various header blocks contain different kinds of information but not all
of them are interesting for our use cases in my current company. The next
chapters will present which field we extract and for what usage.

1.6 SWIFT BIC Code

The SWIFT BIC code is much more than an entity identifier. It is used to
route the financial messages from the issuing institution to the receiving
institutions. The SWIFT BIC Code therefore plays a crucial role in payment
messaging. Without it, a message cannot be transported to the receiving
entity over SWIFT Net.

The BIC code contains the identity and the location of the participants
that are used to find out and reach the message destination.

The SWIFT BIC code is composed of exactly 8 or 11 alphanumeric

characters structured as followed:

1.6.1 Structure of the SWIFT BIC Code

The structure of the BIC code is as follows:

alphabetical characters that indicate the identification of the

institution (bank or corporate)
2 alphabetical characters for the ISO code of the country in which the
 institution is located
2 alphabetic or numeric characters used to locate the institution head
office in the country or the head office in a particular region in the
country.
When the second character takes the value "0", it is typically a
test BIC used in test systems as opposed to a BIC used on the
live network (also production).
When the second character takes the value "1", it denotes a
passive participant in the SWIFT network. Passive participants
cannot be contacted directly over the SWIFT Network. These
BICs are sometimes referred to as ‘BIC1', ‘non-SWIFT BIC' and
‘non-connected BIC'. A non-connected BIC is not allowed in the
header of a SWIFT message, otherwise the message is rejected
by the SWIFT system.
When second character takes the value "2", it indicates a
reverse billing BIC, where the recipient pays for the message as
opposed to the more usual mode where the sender pays for the
message.
3 alphabetical or numeric characters to indicate a branch or agency
of the institution. Unlike the first 8 characters, these last 3 are not
mandatory. They are mainly used by banks and less by corporations.

Few examples to illustrate the above explanations:

DEUTDEFF is the BIC of Deutsche Bank (DEUT) / in Germany (DE) /

Main office of Frankfurt (FF)
DEUTDESS is the BIC of Deutsche Bank (DEUT) / in Germany (DE) /
Main office of Stuttgart (SS)
DEUTDESS648 is the BIC of Deutsche Bank (DEUT) / in Germany
(DE) / Main office of Stuttgart (SS). 648 is the branch located in
Vaihingen-Enz in the same region.
DEUTDES0 and DEUTDES0648 are test BIC for DEUTDESS and
DEUTDESS648
LAFAFRPP is the BIC of Lafarge (LAFA) / in France (FF) / Main office
of Paris (PP)
1.7 Other specific details

Below are some specific noteworthy details about SWIFT messages in a

raw fashion:

Caution: about the little "a" in field names

Very often in documents and papers about SWIFT, fields are
indicated with a little "a" as suffix, such as 54a, 56a, etc.
This lower case "a" needs not to be confused with the upper case "A"
which indicates the variant of the field.
For instance, Field 50a exists in 3 variants: 50A, 50F, 50K. The little
suffix "a" is just a convention to mention the field 50, it is not the
indication of the variant "A"
About SWIFT Input and Output messages
In SWIFT, the notion of output and input related to the SWIFT
network, not to the bank.
A SWIFT input message is an outbound message: a message emitted
by the bank and send to another bank on the SWIFT network.
A SWIFT output message is an inbound message: a message
received to a bank from the SWIFT network.
Qualifying messages as Input or Output is relative to the SWIFT
network, i.e. inverse to the bank perspective (Input are messages
sent by the bank, Output are messages received by the bank)

2. Dissecting key SWIFT Mesages involved in

payments (Funds Transfers)
This chapter presents key SWIFT messages as well as some examples
aimed at understanding the meaning and usage of most important SWIFT
fields.

2.1 SWIFT MT101 Detailed Analysis

The SWIFT MT101 Request for Transfer is a payment initiation message

used to send domestic and/or international payments instructions to their
banks.

The situation of SWIFT MT101 in a banking institution is as follows:

Most of the time when the bank receives an MT101 it will either perform
the operation if both debited and credited accounts are with itself, or it will
issue an MT103 to proceed with the crediting of the destination account
with another banking institution.

But there are situations as well where the account to be debited is not by
the bank itself, in which case the MT101 can be routed further.

2.1.1 MT101 Introductory examples

This section presents various examples of SWIFT MT101 corresponding to

different situations

2.1.1.1 MT101 Example 1: Simplest case

A corporate customer - Robert Corporation - of bank XYZ located in

Switzerland wants to send 50k CHF to Vinino SARL in Geneva, another
customer of bank XYZ. Robert Corporation being a big corporation, it is
connected to the SWIFT network and trades on his account by the bank
using SWIFT MT 101 messages.

In this situation, there is no SWIFT messages emitted further whatsoever

since both customers are customer of bank XYZ.

Details of the MT101:

There is one single transaction in this MT101.

Both accounts are with bank XYZ so no Account with Institution or
Account Servicing Institution need to be indicated.
2.1.1.2 MT101 Example 2: beneficiary with another institution

A corporate customer - Robert Corporation - of bank XYZ located in

Switzerland wants to send 500k EUR to Dupont SARL in Paris.
The corporation Dupont SARL is not a customer of bank XYZ, it is a
customer of bank BNP Parisbas in Paris.
Bank XYZ and BNP Paribas have a direct banking relationship.

Since Bank XYZ and BNP Paribas have a direct banking relationship, Bank
XYZ can send an MT103 to BNP Paribas to make it credit the customer
account from its VOSTRO account by BNP Paribas.

Details of the MT101:

There is one single transaction in this MT101.

The beneficiary account to be credit is not by bank XYZ, so the
eventual banking institution the funds need to be sent to is indicated
in Account With Institution - 57A.

2.1.1.3 MT101 Example 3: Multiple payments in MT101

In this third example, Corporation Robert Corp of bank XYZ located in

Switzerland wants to send a first payment of 100k EUR to Dupont Sarl in
Paris and a second payment of 200 K to Jacob SA in France.
Dupont Sarl is a customer of Bank BNP Paribas in Paris and Jacob SA is a
customer of bank Credit Agricole in France as well.

Bank XYZ in Switzerland and BNP Paribas Paris have a direct banking
relationship, and BNP Paribas and Credit Agricole have a direct banking
relationship as well.

He wants to use different accounts for both transactions and he is

submitting both transactions in the very same MT101.
The MT101 makes it possible to input as many transaction in a single
message, having at least one occurrence of the repetitive sequence is
mandatory.

Since Credit Agricole and Bank XYZ have no direct banking relationship,
the second transaction, crediting Jacob SA has to go through BNP Paribas
as well.

Details of the MT101:

This MT101 contains two distinct transactions

In both case Account with Institution - field 57A - identifies the
eventual destination of the funds for both transactions
The ordering customer - field 50H - is the same from a customer
perspective but the accounts used for both fund transfers are
different. For this reason the ordering customer is indicated in the
repetitive sequence, not in sequence A.

2.1.1.4 MT101 Example 4: Payment from a subsidiary account

A parent company can also use the SWIFT MT101 to pay from own
account on behalf of multiple subsidiaries.

In this example, the parent company Robert Corp located in Switzerland

has received an invoice from Jacob SA for various services that Jacob SA
provided to the local company Robert Corp France SARL, a subsidiary of
Robert Corp located in France.

The parent company Robert Corp decides to use the account of the
subsidiary company in France to pay for the invoice (there can be various
reasons for that).
The subsidiary has granted permission to the parent company for trading
with its account with BNP Paris.

The trick here is in the field 50a Instructing Party. In the SWIFT standard
we read the following under the usage rules of that field: "This field must
only be used when the instructing customer is not also the account
owner."
The field 50a Instructing Party specifies the subsidiary company -
FR12983459182931 / Robert Corp France Sarl - on behalf of which the
parent company, RBCPCHAA02A, sends the payment instruction.

Details of the MT101:

Account Servicing Institution - field 52A - is identifying the fact that

the MT101 needs to be transferred further to the institution owning
the account of the subsidiary where the funds need to be debited
from: BNP Paris / BNPSFRZA93B.
The Account with institution - field 57A - is identifying the eventual
recipient of the funds, the institution owning the account to be
credited: Bank Credit Agricole / CACIFRXA12C.
Instructing Party - field 50L - identifies that the parent corporation is
actually the one at the origin of this MT101, acting on behalf of the
ordering customer - 50 H - the subsidiary in France.

2.1.1.5 MT101 Example 5: Fund repatriation

There is another possibility: funds repatriation.

Funds repatriation simply means to move the funds available on one
account to another account held either by the same financial institution or
by another financial institution. Funds repatriation is performed for cash
pooling inside a company or a group of companies. Corporations resort to
cash pooling to optimize the liquidity usage.

In this example, Robert Corp (a corporate customer) has an account by

bank XYZ in Switzerland and an account by bank BNP Paribas Paris which
he uses for his operations in EUR.
Robert Corp. wants to repatriate all the funds he has on his BNP Paris
account back to his Bank XYZ Account.
Bank XYZ account is called centralized account, master account or leader
account. The BNP Paris account is called secondary account or slave
account.

In this case the MT101 is transmitted further to the bank owning the
debited account and the funds are repatriated with the MT103.

Details of the MT101:

Account Servicing Institution - field 52A - is identifying the fact that

the MT101 needs to be transferred further to the institution owning
the account: BNP Paris / BNPSFRZA93B.
The Account with institution - field 57A - is identifying the eventual
recipient of the funds, the institution owning the account to be
credited: Bank XYZ / BXYZCHZZ80A.
Using the instruction code - field 23 - CMZB - Code to Zero Balance,
it is not necessary to specify any amount, the code will be balanced
down to zero and all the available funds repatriated.

2.1.2 MT101 Parsing and Data Mapping

The MT101 parsing details are presented in the table below. Only most
essential fields are discussed.

SWIFT
Meaning Example Comment
Field Variant
The Application Identifier identifie
application within which the mess
being sent or received. The availa
AppID Block1/ApplId F
options are: F = FIN , A = GPA, etc
These values are automatically as
by the SWIFT system and the use
The Service Identifier consists of
numeric characters. It identifies t
ServiceID Block1/Servid 01 of data that is being sent or recei
in doing so, the type of the follow
message
Block1/ Sender BIC appears in header blo
Sender LTaddrBlk1 (I) 1) in the MT101 Input and in the a
(Sending Or SGOBFRPP block (Block 2) in the MT101 Outp
bank / BIC) Block2/ (Input and output related to the S
LTaddrBlk2 network, not the bank). Need to u
(O) Block2 / Inoutind to find out
Message Block2/
101 SWIFT Message Type = MT 101
Type Msgtype
The Receiver BIC appears in head
(Block1) in the MT101 Output and
Block2/
application block (Block 2) in the
LTaddrBlk21
Input.
Receiver (I)
(Input and output related to the S
(Receiving Or RBOSGB2L
network, not the bank). Need to u
Bank / BIC) Block1/
Block2 / Inoutind to find out.
LTaddrBlk1
The receiver of the message is th
(O)
eventual beneficiary only if no fie
says otherwise.
This field is mandatory and of for
Sender's
20 ORDERREF1234 It is a reference assigned by the S
Reference
unambiguously identify the mess
The field is optional and of forma
Customer a reference to the entire message
Specified 21 R GBSUPPLIERS5668 assigned by either the instructing
Reference when present or by the ordering c
when the instructing party is not
It is mandatory and of format : 5n
(Message Index)/(Total) If you sen
messages for the same order, this
Message
28 D 1/1 take the value 1/5 in the first mes
Index/Total
in the second message, and so o
1/1 means there is only one mess
for this order.
(O) Block2 / ‘
Sender Msg. (O) = Output only : SWIFT timesta
Intime +
Sending 1538070522 an Output message (HHMMYYMM
Inmate (I)
Timestamp local date/time for an Input Messa
System.time()
In / Out-put Block2 /
I Single letter ‘I' or ‘O'
flag Inoutind
Line 1 (subfield
Party Identifier)
/DE20700800000... /34x
 1/Essilor (Account)
International Lines 2-5 :
F 2/147 Rue de Paris (Number/Name
3/FR/Charenton and Address)
94220 1!n/33x
(Number)
(Details)

Line 1 (subfield The field order

Party Identifier) customer is m
/34x In can be given
Ordering
50 /31926819 (account) the message d
Customer G
UBSCH123FNX Line 2 (subfield (here) or per
bank) transaction in
BIC (8 or 11 repeating sequ
characters)
Line 1 (subfield
Party Identifier)
/31926819 /34x
Compagnie de Saint (Account)
H Gobain Lines 2-5 :
118 Rue Lauriston (Number/Name
75016 Paris and Address)
4*35x (Name
and Address)
Authorization 25 12DF64BG345A Optional, 35x (authorization code
The value date, mandatory and o
Requested
6!n (YYMMDD). It is the date on w
Execution 30 181017
subsequent transactions should b
Date
initiated by the executing bank.
Repeating Sequence
This field is mandatory and of for
Transaction It is a reference assigned by the S
21 35863REFOFTRX1
Reference unambiguously identify a unique
transaction.
Optional, if there is an underlying
F/X Deal
21 F FXDEALID78685 exchange deal to this transaction
Reference
this field specifies the FX deal ref
CMZB (= Code to
Zero balance the
account. This
 transaction contains It is optional and of format :4!c[/3
a cash Management (Instruction Code)(Additional Info
Instruction instruction, Optional instruction codes that id
23 E
Code requesting to zero the operation types.
balance the account Caution : there can be several
of the ordering instruction codes (all with sam
customer) in the SWIFT message.
INTC =( Code for
Intra-Company
Payment.)
This is the ordering customer's ac
Charges number to which applicable trans
25 A /FR763000402837...
Account charges should be separately app
the debtor.
Currency,
Mandatory and of Format 3!a15d
Transaction 32 B GBP50000
(Currency)(Amount)
Amount
Currency, This optional field is provided in f
Original 3!a15d. It specifies the original cu
33 B EUR200000
Ordered and amount as specified by the o
Amount customer.
Mandatory since field 33B is pres
'amount' in field 32B is not equal
Exchange Provided in format 12d. The integ
36 1,1382
Rate Rate must contain at least one dig
decimal comma is mandatory and
included in the maximum length.
This field is optional and to be pro
the sending customer (instructing
different than the owner of the ac
(but has an authorization to make
Compagnie de Saint
payment on account given by ow
Instructing Gobain
50 L Compagnie de Saint Gobain instr
Party 118 Rue Lauriston
payment but does not own the ac
75016 Paris
be debited. It is authorized by it's
owner (e.g. a subsidiary) to pay fo
ordering customer account provid
below.
Line 1 (subfield
Party Identifier)
/DE207008000... /34x
 F 1/Essilor (Account)
International Lines 2-5 :
2/147 Rue de Paris (Number/Name
3/FR/Charenton and Address)
94220 1!n/33x
(Number)
(Details)
The field order
Line 1 (subfield customer is m
Party Identifier) In can be given
Ordering /34x
50 the message d
Customer /31926819 (account)
G per transaction
UBSCH123FNX Line 2 (subfield repeating sequ
bank) (here)
BIC (8 or 11
characters)
Line 1 (subfield
Party Identifier)
/31926819 /34x
Compagnie de Saint (Account)
H Gobain Lines 2-5 :
118 Rue Lauriston (Number/Name
75016 Paris and Address)
4*35x (Name
and Address)
This is to notify the receiving ban
institution owning the account to
another institution So the MT101
be transferred to that other institu
identified here.
The BSB (Bank State Branch) cod
the BIC are provided.
Account
//083098 (BSB) Even if it is not mandatory in the S
Servicing 52 A
NATAAU33 (bic) standards to use the BSB code p
Institution
by a double slash. Many banks im
We need to parse the BIC out of i
Format :
&bnsp;&bnsp;&bnsp;&bnsp;[/1!a
(Party Identifier)
&bnsp;&bnsp;&bnsp;&bnsp;4!a2
(Identifier Code)
This is the Correspondent of the
Bank. It holds the account in curr
 the creditor bank.
Intermediary It is optional and can be provided
56 A PNBPUS3N (bic)
Institution A, C or D.
Formats C or D are rarely used an
of the time not supported by ban
Option A is formatted [/1!a][/34x]
Identifier)
4!a2!a2!c[3!c] (Identifier Code / B
We need to
parse the BIC Optional. The
BARCGB22XXX with Institution
out of it
(bic) provided beca
Format :
or e.g. beneficiary do
A [/1!a][/34x]
//939400 (BSB) have an accou
(Party Identifier
AMPBAU2SXXX the debtor ban
)
(bic) with another b
4!a2!a2!c[3!c]
(Identifier Code) an MT103 will
further)
If no BIC is It can be provi
available to option A, B, C
identify the Formats B, C a
target used and mos
Account institution, time not suppo
With 57 option D is banks.
Institution used. For instance, i
In principle the Creditor ba
Hong Kong Banking minimum 3 lines the same as th
Assoc. with name and bank (most of
D Avenue du Léman address should time), it is iden
1204 Genève - CH be provided field 57a. The
Switzerland Format: (Bank State Br
[/1!a][/34x] code and the B
(Party Identifier) AMP Bank are
4*35x (Name provided.
and Address) We need to pa
In this case, BIC out of it or
take country address
from receiver (priority over h
BIC
Line 1 :
[/34x]
/26351-38947
(Account) IBAN
(no Company One
format or else
letter) CITY STREET 50
Line 2-5:
 LONDON, UK 4*35x (Name
and Address)

Option A is
formatted
NBPUS3N [/1!a][/34x]
or e.g. (Party Identifier) Beneficiary cu
A
Beneficiary 59 /12345678901 4!a2!a2!c[3!c] information is
PNBPUS3N (Identifier Code Mandatory
/ BIC)

Line 1 (subfield
Party Identifier)
[/34x]
/10078074 (Account)
1/Company One Lines 2-5 :
F
2/CITY STREET 50 (Number/Name
3/GB/LONDON and Address)
4*(1!n/33x)
(name and
address)
Remittance information is optiona
provided in format 4*35x if availa
Payment from
to 4 lines of up to 35 X character
Remittance Compagnie de Saint
70 The name of the parent company
Information Gobain
provided here, so that the benefic
/INV/7828728292
see it is the parent company that
paying.
It is mandatory and of format 3!a.
take 3 values: BEN, OUR and SHA

OUR means charges are to b

by the ordering customer.
Details of
71 A OUR SHA means charges are sha
Charges
between Ordering and bene
customers.
BEN means charges are to b
by the beneficiary

2.1.3 Additional notes on MT101

Some complementary notes:

 MT 101 have a repeating sequence (several transactions in same
message). In my currently company, we consider every repeating
sequence B (repeating) as a different transaction. The common
sequence (A) is duplicated for each.
We still need a way identify uniquely a message. Unfortunately SWIFT
doesn't have such thing as a unique transaction identified. We usually
use as "business_reference" = [Transaction Reference / 21 /
transaction_business_reference] concatenated to a UUID as suffix.
What to do in case of 57D if we cannot find a country code? One way
is to use the SWIFT message Receiver BIC country (sometimes
wrong but better than nothing, only sometimes since when 57D is
used we are likely in the same country

2.2 SWIFT MT103 Detailed Analysis

The MT103 is a SWIFT message format used for making payments.

MT103 SWIFT payments are known as international wire transfers,
telegraphic transfers, standard EU payments (SEPA payments), LVTS in
Canada, etc.

The situation of SWIFT MT103 in a banking institution is as follows:

There can be many different situations:

An MT103 can be sent after a request from a customer of the bank to

send funds cross-border to another institution. The customer request
can come from any channel including the reception of an MT101.
The MT103 can be a routed message in case the bank is simply a
routing bank in the chain or an explicit intermediary institution.
Then MT103 can be simple announces - in the cover method - or
actual funds transfers - in the serial method.

2.2.1 MT103 Introductory examples

This section presents various examples of SWIFT MT101 corresponding to
different situations

2.2.1.1 MT103 Example 1: Simplest case

In this example, the customer "John Robert" of bank XYZ in Switzerland

wants to send 500k EUR to Dupont SARL, a corporation located in Paris
which is a BNP Paribas customer.

Bank XYZ and BNP Paribas have a direct banking relationship.

A single MT103 is sufficient to implement the fund transfer.

2.2.1.2 MT103 Example 2: more realistic example

This example is a more realistic example. The previous one is from a pure
SWIFT specification perspective entirely valid. But in practice, a few more
fields are almost always present in a SWIFT message.

This example is more or less the same as the previous one: the customer
"John Robert" of bank XYZ in Switzerland wants to send 30k EUR to
Dupont SARL, a corporation located in Paris which is a BNP Paribas
customer.
Bank XYZ and BNP Paribas have a direct banking relationship.

The first thing is that Bank XYZ obviously has several VOSTRO account by
BNP Paribas, and it wants to choose which of these accounts it wants to
use for the reimbursement. It wants to use account 12345678901.

The field 53 normally indicates the Sender's correspondent (i.e. a banking

institution), but it's common practice to use the variant 53B to indicate the
account by the receiving institution to be used for the reimbursement.

In addition, in this more realistic example the charges details are indicated
as well as remittance information.

2.2.1.3 MT103 Example3: forwarded serial message

In the case the bank we are operating within is neither the ordering
institution (initial sender) neither the eventual beneficiary institution, it is
just a routing bank. In this case, specific fields are used to identify the
initial sending institution as well as the eventual beneficiary institution.
These fields are illustrated in this example.

In this example, customer Max Prank of bank BCVs in Switzerland wants

to send 30k EUR to Alfred SARL in Samoens (France), a customer of
"Banque Populaire" in France.
BCVs in Switzerland and Banque Populaire in France have no direct
relationship together so the fund transfer has to go through several
routing bank, one of them being bank XYZ.

We are here interested in the MT 103 sent by Banque XYZ, a routing bank
to the next bank in the routing chain: BNP Paribas.

Since bank XYZ is not the initial sending institution, and the receiver of the
SWIFT message, bank BNP Paribas is not the eventual beneficiary
institution, these two other institutions (initial sending and eventual
beneficiary) needs to be indicated in the SWIFT messages.

Details of the SWIFT MT103:

The field Ordering institution - field 52A - is clearly identifying the

initial sending institution, bank BCVs
The field Account with institution - field 57A - is clearly identifying the
eventual beneficiary institution of the funds

It is relevant to look at the two other SWIFT messages from the chain to
be able to compare them:
Another noteworthy field is the field Intermediary account - field 56A -
which identified that the message has to go through BNP Paribas after
Bank XYZ.

2.2.1.4 MT103 Example 4: Announce message (cover method)

We'll now go through a case where the MT103 is just an announce as part
of the cover payment method. This is the case when the initial sending
institution and the eventual beneficiary institution have no relationship
together and decide to go through their correspondent.

In case the MT103 is just an announce, it can be sent directly from the
initial sending institution to the eventual beneficiary institution regardless
of the fact that they have no banking relationship with each other.

In this example, the customer John Trump of bank XYZ in Switzerland

wants to send 1'000'000 USD to Cowboy Corp. in Kensas City, a customer
of "Kensas Credit"
Due to the nature of the transaction and their missing banking relationship
together, they decide to go through correspondent banks :

An MT103 is sent directly to the beneficiary bank, regardless of the

fact they have no banking relationship together
An MT202.COV will be routed through correspondent(s) and routing
banks

We are here interested in the MT 103 sent by Bank XYZ, the

announcement, which can be sent directly to beneficiary bank

The MT103 announce clearly indicates that the fund transfer will go
through correspondents with the usage of the fields Sender's
correspondent - field 53A - and Receiver's Correspondent - field 54A.
Aside from this, there is no specific difference between this announce and
a serial MT103 fund transfer.

2.2.2 MT103 Parsing and Data Mapping

The MT103 parsing details are presented in the table below. Only most
essential fields are discussed.

SWIFT
Meaning Example Comment
Field Variant
The Application Identifier
identifies the application
within which the message is
being sent or received. The
available options are: F = FIN
AppID Block1/ApplId F
A = GPA, etc.
These values are
automatically assigned by the
SWIFT system and the user's
CBT.
The Service Identifier consist
of two numeric characters. It
identifies the type of data tha
ServiceID Block1/Servid 01
is being sent or received and
in doing so, the type of the
following message
Sender BIC appears in heade
block (Block 1) in the MT103
Block1/
Input and in the application
LTaddrBlk1 (I)
Sender block (Block 2) in the MT103
Or
(Sending bank SGOBFRPP Output
Block2/
/ BIC) (Input and output related to
LTaddrBlk2
the SWIFT network, not the
(O)
bank). Need to use field
Block2 / Inoutind to find out
Block2/ SWIFT Message Type = MT
Message Type 103
Msgtype 103
If field 56a or 57a are Knowing whether the MT103
present : then transfer is a serial transfer or the
type = "serial" announce preceding a cover
Cover or Serial If field 53a (ex 53B) or transfer is important. For a
Transfer Type 54a are present : then given use case, we actually
 transfer type = expect a banking institution
"announce (cover)" always to use the very same
(Default : serial) method.
The Receiver BIC appears in
header block (Block1) in the
MT103 Output and in the
application block (Block 2) in
Block2/
the MT103 Input.
LTaddrBlk2(I)
Receiver (Input and output related to
Or
(Receiving RBOSGB2L the SWIFT network, not the
Block1/
Bank / BIC) bank). Need to use field
LTaddrBlk1
Block2 / Inoutind to find out.
(O)
The receiver of the message
is the eventual beneficiary
only if no field 57 says
otherwise.
This reference is provided in
Unique End- the user block (Block 3) and
b03c6901-bbed-
to-end Block3/ Tag transported end-to-end. It is
4aa9-afdh-
Transaction 121 mandatory in MT103 but can
A5bc26d19257
Reference still be missing as well as hav
duplicates.
This field is mandatory and o
format 16x. It is a reference
Sender's
20 ORDERREF1234 assigned by the Sender to
Reference
unambiguously identify the
message.
(O) = Output only : SWIFT
(O) Block2 / ‘
Sender Msg. timestamp for an Output
Intime +
Sending 1538070522 message (HHMMYYMMDD)
Indate
Timestamp or local date/time for an Input
(I) Sys.time()
Message.
In / Out-put Block2 /
I Single letter ‘I' or ‘O'
flag Inoutind
Bank
It is mandatory and of format
operation 23 B CRED
4!c.
code
It is optional and of format
:4!c[/30x] (Instruction Code)
(Additional Info.)
Instruction Code PHOB means Phone
code 23 E PHOB/+34.91.397.6789 Benef.. The sender requests
the benef. bank to contact
benef. by phone when funds
are received.

It is mandatory and of format

Value Date /
6!n3!a15d (Date)(Currency)
currency /
(Amount).
interbank 32 A 180816USD2325,
Note the trailing coma (i.e.
settled
decimal part is not mandator
amount
if 0)
Normally optional in the
standard. It may be provided
Currency / for instance because the
Instructed 33 B USD2350, sender has taken fees. See
Amount field 71F below.
Format 3!a15d (Currency)
(Amount)
Line 1 (subfield The field
Party Identifier) ordering
/34x customer
/DE3750070010... (account) is
A
DEUTDEFF Line 2 (subfield mandatory
bank) In can be
4!a2!a2!c[3!c] given
(Identifier Code) either in
the
Line 1 (subfield
message
Party Identifier)
details
/34x
/DE207008000... (here) or
(Account)
1/Essilor International per
Lines 2-5 :
F 2/147 Rue de Paris transactio
(Number/Name
3/FR/Charenton-le- in the
and Address)
Pont, 94220 repeating
1!n/33x
sequence
(Number)
Ordering The
50 (Details)
Customer ordering
customer
is
customer
of the
Line 1 : (subfield sender
/CH570483509... party identified) only if
 GALLMAN COMPANY /34x there is no
K GMBH (Account) field 52.
RAEMISTRASSE, 71 Line 2-5 The
8006 ZURICH (subfield ordering
SWITZERLAND Address) customer
4*35x (Name remains
and Address) constant i
the
message
chain.

Format Ordering
BNPAFRPP
[/1!a][/34x] institution
or e.g.
A (Party Identifier) is optional
/FR123509321...
4!a2!a2!c[3!c] and can b
BNPAFRPP
(Identifier Code) provided i
two
options A
(usual) an
D (less
common).
The sende
populates
this field t
indicate
that the
initial
Ordering instruction
52
institution comes
BANQUE DELUBAC ET Format
from
CIE [/1!a][/34x]
another
D 16 PL SALEON (Party Identifier)
institution
TERRAS 4*35x (Name
(ordering
07160 LE CHEYLARD and Address)
institution
The
ordering
institution
remains
constant i
the
message
chain.
(priority
over
 header)
Cover payments only
Correspondent of sender.
Sender has an account in
PNBPUS3N Currency with this banking
or e.g. institution.
A
/12345678901 Option A is formatted
PNBPUS3N [/1!a][/34x] (Party Identifie
4!a2!a2!c[3!c] (Identifier
Code / BIC)

Caution : Serial and cover

payments.
Sender's Field 53B indicates the
53
correspondent account number of the
Sender, serviced by the
Receiver, which is to be used
for reimbursement (debit) in
the transfer. This the accoun
B /12345678901
of the sender by the receiver
(VOSTRO)
Option B Format is:
[/1!a][/34x] (Party Identifie
[35x] (Location)
The field is optional but In
practice, the account numbe
is almost always provided.
Cover payments only.
Correspondent of receiver.
Receiver has an account in
IRVTUS3N
currency with this banking
Receiver's or e.g.
54 A institution.
correspondent /9876412-1234/123
Option A is formatted
IRVTUS3N
[/1!a][/34x] (Party Identifie
4!a2!a2!c[3!c] (Identifier
Code / BIC)
Serial payments only.
This is the Correspondent of
Creditor Bank. It holds the
account in currency of the
creditor bank. It is used
instead of over 54a
(Receiver's Correspondent) i
 IRVTUS3N (bic) case of a serial payment
Intermediary or e.g. transfer.
56 A
Institution /939400 (BSB or It is optional and can be
account) provided in option A, C or D.
AMPBAU2SXXX (bic) Formats C or D are rarely
used and most of the time no
supported by banks.
Option A is formatted
[/1!a][/34x] (Party Identifie
4!a2!a2!c[3!c] (Identifier
Code / BIC)

We need to Serial
parse the BIC payments
out of it only.
BARCGB22XXX (bic)
Format : Account
or e.g.
A [/1!a][/34x] with
//939400 (BSB)
(Party Identifier institution
AMPBAU2SXXX (bic)
) is optional
4!a2!a2!c[3!c] and can b
(Identifier Code) provided i
option A,
B, C or D.
Formats B
C are
rarely use
and most
of the time
not
supported
by banks.
Field 57 is
used when
If no BIC is the
available to receiver o
identify the the SWIFT
target MT103
institution, doesn't
option D is own the
Account With beneficiar
57 used.
Institution account
In principle
minimum 3 lines and needs
Hong Kong Banking with name and to send th
Assoc. address should Message
 D Avenue du Léman be provided Further. In
1204 Genève - CH Format : the final
Switzerland [/1!a][/34x] MT103 on
(Party Identifier the chain,
) the holder
4*35x (Name of the
and Address) account
In this case, will be the
take country receiver
from receiver and no
BIC. field 57 wi
be
required
anymore.
We need
to parse
the BIC ou
of it or
hash the
address
(priority
over
header)

Line 1 :
[/34x]
/26351-38947
(Account) (IBAN
(no Company One
format or else)
letter) CITY STREET 50
Line 2-5:
LONDON, UK
4*35x (Name
and Address)
Beneficiar
Option A is customer
formatted informatio
PNBPUS3N
[/1!a][/34x] is
or e.g.
A (Party Identifier) Mandatory
/12345678901
4!a2!a2!c[3!c] The
Beneficiary 59 PNBPUS3N
(Identifier Code beneficiar
/ BIC) remains
constant i
Line 1 (subfield
the
Party Identifier)
message
[/34x]
chain.
/10078074 (Account)
1/Company One Lines 2-5 :
F
 2/CITY STREET 50 (Number/Name
3/GB/LONDON and Address)
4*(1!n/33x)
(name and
address)
Remittance information is
optional and provided in
format 4*35x if available. Up
to 4 lines of up to 35 X
characters each.
Usually the remittance
information is generated by
Remittance the beneficiary and sent to
70 /INV/18042-090715 the ordering customer (or
Information
debtor). The beneficiary
requests the debtor to
provide it the payment
message, so that the
beneficiary can easily
reconcile the payment with a
invoice for instance.

It is mandatory and of format

3!a. It can take 3 values: BEN
OUR and SHA.

OUR means charges are

to be borne by the
ordering customer.
Details of
71 A OUR SHA means charges are
Charges
shared between
Ordering and beneficiar
customers.
BEN means charges are
to be borne by the
beneficiary

Optional. When 71A is BEN (o

SHA), 71G contains amount o
the charges due, which have
been deducted from the
interbank settlement amount
Sender's Interbank settled amount =
71 F EUR2,50
charges Instructed amount - Sender's
 charges.
Format 3!a15d
Caution: there can be
several different 71F in a
same MT103.
Optional. When 71A is OUR
(or SHA), 71G contains
amount of the charges due,
which have been prepaid and
Receiver's included in the interbank
71 G EUR2,50 settlement amount.
charges
Format 3!a15d
Caution : there can be
several different 71G in a
same MT103.

This is an optional field. It

takes the Format 6*35x.
There can be many codes
indicating additional
information.
INS is a code indicating that
BNPAFRPP is the instructing
Sender to
institution. Without field 72,
Receiver 72 /INS/BNPAFRPP
the receiver may not know it
Information
since that information is not
provided somewhere else in
the message when sender is
the next bank on the routing
chain and ordering institution
is another bank before the
instructing one.

2.2.3 Additional notes on MT103

Some complementary notes:

The option field 53B (only variant B) is really only used to indicate
which account at the correspondent (receiver) should be debited.
Fields 51A seems to be not supported by most banks (at least all I
found such as UBS, etc.)
When no correspondent is used neither on sender side (Tag 53A) nor
on receiver side (Tag 54A) and No reimbursement party (Tags 56a
and 57a) is indicated in the SWIFT MT103 message. It means
there is a direct account relationship, in the currency of the
transfer, between the Sender and the Receiver. Money will be
taken from account and credited to the beneficiary.
Beneficiary customer account (:59) is hold by the receiver.
The fields 56a and 57a are used for serial transfers while the fields
53a (ex 53B) and 54a are used in the MT103 Announcement
Message (cover method).
What to do in case of 57D if we cannot find a country code? We Use
SWIFT message Receiver BIC country (sometimes wrong but better
than nothing, only sometimes since when 57D is used we are likely in
the same country)
Routing
When there is no ordering institution (Tag 52) in the SWIFT
MT103 message. That means implicitly that the ordering
customer is customer of the Sender.
When the ordering institution (Tag 52D) is provided in the MT103
SWIFT Message. This means the ordering customer is not
customer of the Sender.
Either the sending institution sends the MT103 on behalf of
the ordering institution in 52D. This happens when the
ordering institution is a small bank that has an agreement
with a major bank (sending bank) for the processing and
settlement of currency transactions. The small bank can
use the correspondent network of sending institution.
Or the Sender is a routing bank on the chain
Field 57 is used when the receiver of the SWIFT MT103 doesn't own
the beneficiary account and needs to send the Message Further.
In the final MT103 on the chain, the holder of the account will be the
receiver and no field 57 will be required anymore.
This indicates that Sender and Beneficiary customer's Bank do
not have direct account relationship in the currency of the
transaction (USD). Otherwise the sender would send the
 message directly to the beneficiary customer's Bank.
Sender's reference is new for every message in the routing chain, but
end-to-end reference remains constant.

2.3 SWIFT MT202 Detailed Analysis

SWIFT MT202 Messages are used for interbank funds transfers. There is
no customer involved when issuing an MT202. Funds are not sent on
behalf of a customer but on behalf of the initial sending banking institution
itself.

The situation of SWIFT MT202 in a banking institution is as follows:

There can be two different situations:

Either the bank is the initial sending institution, in which case it will be
identified both as the sender of the SWIFT message and perhaps as
the Ordering Institution (52a)
Or the bank is just a routing bank in the routing chain in which case it
is the sender but shall be different that the Ordering Institution (52a)

2.3.1 SWIFT MT202 Introductory Exampkes

This section presents various examples of SWIFT MT202 corresponding

to different situations

2.3.1.1 MT202 Example 1: simplest case

In this first example, bank XYZ wants to send 1 million euros from its
general VOSTRO account 1234-5678 by BNP Paribas to another of its
own account FR982381827331 also by BNP Paribas.
The field "Receiver's Correspondent" - 53B - is diverted for the usage of
identifying the source account to use for debit.
Details of the SWIFT MT202:

The beneficiary institution is a field that doesn't exist in MT103 and

introduced by MT202. It does not identify the eventual institution
owning the account to be credited but the Banking institution owning
that account, actually the bank being the customer of the institution
owning its correspondent account.

2.3.1.2 MT202 Example 2: other bank case

In this second example, bank XYZ wants to send 1 million euros from its
general VOSTRO account 1234-5678 by BNP Paribas to an account
belonging to another financial institution: Banque Populaire in France. This
other banking institution also owns an account by BNP Paribas.
The account of Banque Populaire by BNP Paribas is FR98238182733.

The field "Receiver's Correspondent" - 53B - is diverted for the usage of

identifying the source account to use for debit.

The details of this SWIFT MT 202 are fundamentally similar to the one
from the previous example:

The field Beneficiary Institution - 58A - identifies clearly the eventual

beneficiary institution owning the account by the Account with
Institution - field 57A, in this case Banque Populaire.

2.3.1.3 MT202 Example 3: routed message

In this example we’ll see how a routed MT202 looks like. In this example,
bank BCVs wants to send money to Banque Populaire. They are not using
correspondent, the initial account debited is by BCVs and the eventual
beneficiary account is by Banque Populaire.

Since BCVs and Banque Populaire have no relationship together, the

MT202 needs to be routed through banks having a banking relationship. In
this example we look at the MT202 forwarded by bank XYZ, one of the
bank on the routing chain.

Details of this SWIFT MT202 message:

The field account with Institution - 57A has the same value than the
field beneficiary institution - 58A - since the funds make it to Banque
Populaire.

2.3.2 MT202 Parsing and Data Mapping

The MT202 parsing details are presented in the table below. Only most
essential fields are discussed.

SWIFT
Meaning Example Comment
Field Variant
The Application Identifier identif
the application within which the
message is being sent or receive
The available options are: F = FIN
AppID Block1/ApplId F
A = GPA, etc.
These values are automatically
assigned by the SWIFT system a
the user's CBT.
The Service Identifier consists o
two numeric characters. It
identifies the type of data that is
ServiceID Block1/Servid 01
being sent or received and, in
doing so, the type of the followin
message
Sender BIC appears in header
Block1/ block (Block 1) in the MT202 Inp
LTaddrBlk1 (I) and in the application block (Blo
Sender 2) in the MT202 Output
Or
(Sending bank SGOBFRPP (Input and output related to the
Block2/
/ BIC) SWIFT network, not the bank).
LTaddrBlk2
(O) Need to use field Block2 / Inouti
 to find out
Block2/
Message Type 202 SWIFT Message Type = MT 202
Msgtype
This validation flag is provided th
user block (Block 3) and
COV (if MT202 is a
Validation Flag Block3/Tag119 transported end-to-end. It
cover payment)
indicates that the message is a
MT202 Cover.
The Receiver BIC appears in
header block (Block1) in the
MT292 Output and in the
Block2/ application block (Block 2) in the
LTaddrBlk2(I) MT202 Input.
Receiver
Or (Input and output related to the
(Receiving RBOSGB2L
Block1/ SWIFT network, not the bank).
Bank / BIC)
LTaddrBlk1 Need to use field Block2 /
(O) Inoutind to find out.
The receiver of the message is t
eventual beneficiary only if no fi
57 says otherwise.
This reference is provided in the
Unique End- user block (Block 3) and
b03c6901-bbed-
to-end Block3/ Tag transported end-to-end. It is
4aa9-afdh-
Transaction 121 mandatory in MT103 but can sti
A5bc26d19257
Reference be missing as well as have
duplicates.
Sequence A - General Information (Matching MT 202 format)
This field is mandatory and of
format 16x. It is a reference
Sender's
20 ORDERREF1234 assigned by the Sender to
Reference
unambiguously identify the
message.
Related This field is mandatory and of
21 123456789ABCDEF
reference format 16x.
(O) = Output only : SWIFT
(O) Block2 / ‘
Sender Msg. timestamp for an Output messag
Intime +
Sending 1538070522 (HHMMYYMMDD)
Indate
Timestamp or local date/time for an Input
(I) Sys.time()
Message.
In / Out-put Block2 /
I Single letter ‘I’ or ‘O’
flag Inoutind
Value Date / It is mandatory and of format
currency / 6!n3!a15d (Date)(Currency)
interbank 32 A 180816USD2325, (Amount).
settled Note the trailing coma (i.e. decim
amount part is not mandatory if 0)
Format Ordering
BNPAFRPP
[/1!a][/34x] institution is
or e.g.
A (Party Identifier) optional and
/FR123509321...
4!a2!a2!c[3!c] can be provid
BNPAFRPP
(Identifier Code) in two option
(usual) and D
(less commo
The sender
populate this
field to indica
that the initia
Ordering instruction
52 BANQUE DELUBAC
institution Format comes from
ET CIE another
[/1!a][/34x]
16 PL SALEON institution
D (Party Identifier)
TERRAS (ordering
4*35x (Name
07160 LE institution).
and Address)
CHEYLARD The ordering
institution
remains
constant in th
message cha
(priority over
header)
Cover payments only
Correspondent of sender. Sende
PNBPUS3N has an account in Currency with
or e.g. this banking institution.
A
/12345678901 Option A is formatted
PNBPUS3N [/1!a][/34x] (Party Identifier)
4!a2!a2!c[3!c] (Identifier Code
BIC)
Caution : Serial and cover
payments.
Sender's Field 53B indicates the account
53 number of the Sender, serviced
correspondent
 the Receiver, which is to be used
for reimbursement (debit) in the
B /12345678901 transfer. This the account of the
sender by the receiver (VOSTRO
Option B Format is:
[/1!a][/34x] (Party Identifier)
[35x] (Location)
The field is optional but In pract
the account number is almost
always provided.
Cover payments only.
Correspondent of receiver.
Receiver has an account in
IRVTUS3N
currency with this banking
Receiver’s or e.g.
54 A institution.
correspondent /9876412-1234/123
Option A is formatted
IRVTUS3N
[/1!a][/34x] (Party Identifier)
4!a2!a2!c[3!c] (Identifier Code
BIC)
Serial payments only.
This is the Correspondent of
Creditor Bank. It holds the accou
in currency of the creditor bank.
is used instead of over 54a
IRVTUS3N (bic) (Receiver's Correspondent) in c
or e.g. of a serial payment transfer.
Intermediary /939400 (BSB or It is optional and can be provide
56 A
Institution account) in option A, C or D.
AMPBAU2SXXX Formats C or D are rarely used a
(bic) most of the time not supported
banks.
Option A is formatted
[/1!a][/34x] (Party Identifier)
4!a2!a2!c[3!c] (Identifier Code
BIC)
We need to Serial
parse the BIC payments on
BARCGB22XXX
out of it Account with
(bic)
Format : institution is
or e.g.
A [/1!a][/34x] optional and
//939400 (BSB)
(Party Identifier can be provid
AMPBAU2SXXX
) in option A, B
(bic)
4!a2!a2!c[3!c] or D.
 (Identifier Code) Formats B, C
are rarely use
and most of t
time not
supported by
banks.
Option A is
formatted
[/1!a][/34x]
(Party Identif
If no BIC is 4!a2!a2!c[3
available to (Identifier Co
identify the / BIC)
target Field 57 is us
Account With
57 institution, when the
Institution
option D is receiver of th
used. SWIFT MT10
Hong Kong Banking doesn’t own
In principle
Assoc. beneficiary
minimum 3 lines
D Avenue du Léman account and
with name and
1204 Genève - CH needs to sen
address should
Switzerland the Message
be provided
Format : Further. In the
[/1!a][/34x] final MT103 o
(Party Identifier the chain, the
) holder of the
4*35x (Name account will b
and Address) the receiver a
no field 57 w
be required
anymore.
We need to
parse the BIC
out of it or ha
the address
(priority over
header)

Format Beneficiary
BNPAFRPP
[/1!a][/34x] Institution is a
or e.g.
A (Party Identifier) mandatory fie
/FR123509321...
4!a2!a2!c[3!c] In the Case o
BNPAFRPP
(Identifier Code) MT 202 and M
202.COV,
Beneficiary beneficiary
58 institution is t
Institution BANQUE DELUBAC
ET CIE Format most reliable
16 PL SALEON [/1!a][/34x] and
D TERRAS (Party Identifier) straightforwa
07160 LE 4*35x (Name way to identif
CHEYLARD and Address) the eventual
beneficiary
institution of
founfs.
This is an optional field. It takes
Format 6*35x.
There can be many codes
indicating additional information
INS is a code indicating that
BNPAFRPP is the instructing
Sender to
institution. Without field 72, the
Receiver 72 /INS/BNPAFRPP
receiver may not know it since th
Information
information is not provided
somewhere else in the message
when sender is the next bank on
the routing chain and ordering
institution is another bank befor
the instructing one.

2.3.3 Additional notes on MT202

Some complementary notes:

When no correspondent is used neither on sender side (Tag 53A) nor

on receiver side (Tag 54A) and No reimbursement party (Tags 56a
and 57a) is indicated in the SWIFT MT103 message. It means
There’s a direct account relationship, in the currency of the
transfer, between the Sender and the Receiver. Money will be
taken from account and credited to the beneficiary.
Beneficiary customer account (:59:/00012367493) is hold by the
receiver.
What to do in case of 57D if we cannot find a country code? We Use
SWIFT message Receiver BIC country (sometimes wrong but better
than nothing, only sometimes since when 57D is used we are likely in
 the same country
Routing
When there is no ordering institution (Tag 52) in the SWIFT
MT202 message. That means implicitly that the ordering
customer is customer of the Sender.
When the ordering institution (Tag 52D) is provided in the
MT202 SWIFT Message. This means the ordering customer is
not customer of the Sender.
Either the sending institution sends the MT202 on behalf of
the ordering institution in 52D. This happens when the
ordering institution is a small bank that has an agreement
with a major bank (sending bank) for the processing and
settlement of currency transactions. The small bank can
use the correspondent network of sending institution.
Or the Sender is a routing bank on the chain
Field 57 is used when the receiver of the SWIFT MT103 doesn’t own
the beneficiary account and needs to send the Message Further.
In the final MT103 on the chain, the holder of the account will be the
receiver and no field 57 will be required anymore.
This indicates that Sender and Beneficiary customer's Bank do
not have direct account relationship in the currency of the
transaction (USD). Otherwise the sender would send the
message directly to the beneficiary customer's Bank.
The field 58a identifies in a unique way the beneficiary institution. To
be perfectly honest, it does not have the same meaning as the 57a in
103 for instance, it rather has the same beaning as 59 to identify the
beneficiary, when the beneficiary is an institution and not a customer.
We shall use the 58 for 202 and 202.cov to identify the eventual
beneficiary institution.

2.4 SWIFT MT202 COV Detailed Analysis

MT202 COV is a SWIFT message format for financial institution (FI) funds
transfer between financial institutions. MT202's are used primarily for two
purposes, bank-to-bank payments (i.e. interest payments and settlement
of FX trades) and Cover Payments.
MT202 COV was implemented in 2009 to create traceability of the
origination of funds (institution and account) through to the destination of
funds (institution and account.) This was in response to anti-money
laundering and associated banking requirements.

Prior to MT202 COV, The message format, MT202, did not include
origination/destination financial institution information. Particularly for
Cover Payments, where a combination of MT103 and MT202 are used to
direct funds transfers to a beneficiary account, the intermediate banks in
the MT202 had no ability to understand and perform risk
analysis/AML/compliance checks on the funds transfer based on the
original and destination of the funds. Thus, intermediate banks could be
unwittingly involved in illegal transactions under new regulations.

The situation of SWIFT MT202 COV in a banking institution is as follows:

There can be two different situations:

Either the bank is the initial sending institution, in which case it will be
identified both as the sender of the SWIFT message and perhaps as
the Ordering Institution (52a)
Or the bank is just a routing bank in the routing chain in which case it
is the sender but shall be different that the Ordering Institution (52a)

2.4.1 MT202 COV Introductory examples

This section presents various examples of SWIFT MT202 COV

corresponding to different situations

2.4.1.1 MT202 COV Example: Cover payment

We’ll now go through a case where the MT202 COV followed as the
MT103 sent as an announce as part of the cover payment method as
introduced in section [6.2.2.4 Example 4: Announce message (cover
method)]. This is the case when the initial sending institution and the
eventual beneficiary institution have no relationship together and decide
to go through their correspondent.
The MT 202 COV in this case is the message actually carrying the funds.

In this example, the customer John Trump of bank XYZ in Switzerland

wants to send 1’000’000 USD to Cowboy Corp. in Kensas City, a customer
of “Kensas Credit”
Due to the nature of the transaction and their missing banking relationship
together, they decide to go through correspondent banks :

An MT103 is sent directly to the beneficiary bank, regardless of the

fact they have no banking relationship together
An MT202.COV will be routed through correspondent(s) and routing
banks

We are here first having a look at the initial MT202 COV sent by bank XYZ,
the sending institution:

Details of the SWIFT MT 202 COV message:

The field account with institution- 57a - ends up by Wells Fargo. The
MT 202 chain doesn’t carry the funds any further.
But the account by Wells Fargo is the correspondent account of
Kensas Credit by Well Fargo, the field Beneficiary Institution - 58a -
identified the institution owning that account by Wells Fargo, hence
Kensas Credit.
The field 59 identifies the beneficiary customer for which the funds
are transferred, Cowbow corp, a customer of Kensas Credit.

We shall have a look at all the MT202 COV of the chain to see how they
differ from each other’s:
2.4.2 MT202 COV Parsing and Data Mapping

The MT202 COV parsing details are presented in the table below. Only
most essential fields are discussed.

SWIFT
Meaning Example Comment
Field Variant
The Application Identifier identif
the application within which the
message is being sent or receive
The available options are: F = FIN
AppID Block1/ApplId F
A = GPA, etc.
These values are automatically
assigned by the SWIFT system a
the user's CBT.
The Service Identifier consists o
two numeric characters. It
identifies the type of data that is
ServiceID Block1/Servid 01
being sent or received and, in
doing so, the type of the followin
message
Sender BIC appears in header
Block1/ block (Block 1) in the MT202 Inp
LTaddrBlk1 (I) and in the application block (Blo
Sender
Or 2) in the MT202 Output
(Sending bank SGOBFRPP
Block2/ (Input and output related to the
/ BIC)
LTaddrBlk2 SWIFT network, not the bank).
(O) Need to use field Block2 / Inouti
to find out
Block2/
Message Type 202 SWIFT Message Type = MT 202
Msgtype
This validation flag is provided th
user block (Block 3) and
COV (if MT202 is a
Validation Flag Block3/Tag119 transported end-to-end. It
cover payment)
indicates that the message is a
MT202 Cover.
The Receiver BIC appears in
header block (Block1) in the
MT292 Output and in the
Block2/ application block (Block 2) in the
Receiver LTaddrBlk2(I) MT202 Input.
(Receiving Or RBOSGB2L (Input and output related to the
Bank / BIC) Block1/ SWIFT network, not the bank).
LTaddrBlk1 Need to use field Block2 /
(O) Inoutind to find out.
The receiver of the message is t
eventual beneficiary only if no fi
57 says otherwise.
This reference is provided in the
Unique End- user block (Block 3) and
b03c6901-bbed-
to-end Block3/ Tag transported end-to-end. It is
4aa9-afdh-
Transaction 121 mandatory in MT103 but can sti
A5bc26d19257
Reference be missing as well as have
duplicates.
Sequence A - General Information (Matching MT 202 format)
This field is mandatory and of
format 16x. It is a reference
Sender's
20 ORDERREF1234 assigned by the Sender to
Reference
unambiguously identify the
message.
Related This field is mandatory and of
21 123456789ABCDEF
reference format 16x.
(O) = Output only : SWIFT
(O) Block2 / ‘
Sender Msg. timestamp for an Output messag
Intime +
Sending 1538070522 (HHMMYYMMDD)
Indate
Timestamp or local date/time for an Input
(I) Sys.time()
Message.
In / Out-put Block2 /
I Single letter ‘I’ or ‘O’
flag Inoutind
Value Date / It is mandatory and of format
currency / 6!n3!a15d (Date)(Currency)
interbank 32 A 180816USD2325, (Amount).
settled Note the trailing coma (i.e. decim
amount part is not mandatory if 0)
Format Ordering
BNPAFRPP
[/1!a][/34x] institution is
or e.g.
A (Party Identifier) optional and
/FR1235093212...
4!a2!a2!c[3!c] can be provid
BNPAFRPP
(Identifier Code) in two option
(usual) and D
(less commo
 The sender
populate this
field to indica
that the initia
Ordering instruction
52 BANQUE DELUBAC
institution Format comes from
ET CIE another
[/1!a][/34x]
16 PL SALEON institution
D (Party Identifier)
TERRAS (ordering
4*35x (Name
07160 LE institution).
and Address)
CHEYLARD The ordering
institution
remains
constant in th
message cha
(priority over
header)
Cover payments only
Correspondent of sender. Sende
PNBPUS3N has an account in Currency with
or e.g. this banking institution.
A
/12345678901 Option A is formatted
PNBPUS3N [/1!a][/34x] (Party Identifier)
4!a2!a2!c[3!c] (Identifier Code
BIC)
Caution : Serial and cover
payments.
Sender's Field 53B indicates the account
53
correspondent number of the Sender, serviced
the Receiver, which is to be used
for reimbursement (debit) in the
transfer. This the account of the
B /12345678901
sender by the receiver (VOSTRO
Option B Format is:
[/1!a][/34x] (Party Identifier)
[35x] (Location)
The field is optional but In pract
the account number is almost
always provided.
Cover payments only.
Correspondent of receiver.
IRVTUS3N Receiver has an account in
currency with this banking
Receiver’s 54 A or e.g. institution.
correspondent /9876412-1234/123 Option A is formatted
IRVTUS3N [/1!a][/34x] (Party Identifier)
4!a2!a2!c[3!c] (Identifier Code
BIC)

Serial payments only.

This is the Correspondent of
Creditor Bank. It holds the accou
in currency of the creditor bank.
is used instead of over 54a
IRVTUS3N (bic) (Receiver's Correspondent) in c
or e.g. of a serial payment transfer.
Intermediary /939400 (BSB or It is optional and can be provide
56 A
Institution account) in option A, C or D.
AMPBAU2SXXX Formats C or D are rarely used a
(bic) most of the time not supported
banks.
Option A is formatted
[/1!a][/34x] (Party Identifier)
4!a2!a2!c[3!c] (Identifier Code
BIC)
We need to Serial
parse the BIC payments on
BARCGB22XXX
out of it Account with
(bic)
Format : institution is
or e.g.
A [/1!a][/34x] optional and
//939400 (BSB)
(Party Identifier can be provid
AMPBAU2SXXX
) in option A, B
(bic)
4!a2!a2!c[3!c] or D.
(Identifier Code) Formats B, C
are rarely use
and most of t
time not
supported by
banks.
Option A is
formatted
[/1!a][/34x]
(Party Identif
4!a2!a2!c[3
If no BIC is
(Identifier Co
available to
/ BIC)
identify the
Field 57 is us
Account With 57 target when the
Institution institution, receiver of th
option D is SWIFT MT10
Hong Kong Banking used. doesn’t own
Assoc. In principle beneficiary
D Avenue du Léman minimum 3 lines account and
1204 Genève - CH with name and needs to sen
Switzerland address should the Message
be provided Further. In the
Format : final MT103 o
[/1!a][/34x] the chain, the
(Party Identifier holder of the
) account will b
4*35x (Name the receiver a
and Address) no field 57 w
be required
anymore.
We need to
parse the BIC
out of it or ha
the address
(priority over
header)

Format Beneficiary
BNPAFRPP
[/1!a][/34x] Institution is a
or e.g.
A (Party Identifier) mandatory fie
/FR123509321...
4!a2!a2!c[3!c] In the Case o
BNPAFRPP
(Identifier Code) MT 202 and M
202.COV,
beneficiary
Beneficiary institution is t
58 BANQUE DELUBAC
Institution Format most reliable
ET CIE and
[/1!a][/34x]
16 PL SALEON straightforwa
D (Party Identifier)
TERRAS way to identif
4*35x (Name
07160 LE the eventual
and Address)
CHEYLARD beneficiary
institution of
founfs.
This is an optional field. It takes
Format 6*35x.
There can be many codes
 indicating additional information
INS is a code indicating that
Sender to BNPAFRPP is the instructing
Receiver 72 /INS/BNPAFRPP institution. Without field 72, the
Information receiver may not know it since th
information is not provided
somewhere else in the message
when sender is the next bank on
the routing chain and ordering
institution is another bank befor
the instructing one.
Sequence B - Underlying Customer Credit Transfer Detail
Normally optional in the standar
Currency / It may be provided for instance
Instructed 33 B USD2350, because the sender has taken
Amount fees. See field 71F below.
Format 3!a15d (Currency)(Amou
Line 1 (subfield
Party Identifier)
/34x
/DE3750070010... (account) The field
A
DEUTDEFF Line 2 (subfield ordering
bank) customer is
4!a2!a2!c[3!c] mandatory. In
(Identifier Code) can be given
either in the
Line 1 (subfield
message det
Party Identifier)
(here) or per
/DE207008000... /34x
transaction in
1/Essilor (Account)
the repeating
International Lines 2-5 :
Ordering F sequence.
50 2/147 Rue de Paris (Number/Name
Customer The ordering
3/FR/Charenton-le- and Address)
customer is
Pont, 94220 1!n/33x
customer of t
(Number)
sender only if
(Details)
there is no fie
Line 1 : (subfield 52. The
/CH5704835098... party identified) ordering
GALLMAN /34x customer
COMPANY GMBH (Account) remains
K RAEMISTRASSE, 71 Line 2-5 constant in th
8006 ZURICH (subfield message cha
SWITZERLAND Address)
 4*35x (Name
and Address)
Line 1 :
[/34x]
/26351-38947
(Account) (IBAN
(no Company One
format or else)
letter) CITY STREET 50
Line 2-5:
LONDON, UK
4*35x (Name
and Address)
Option A is
formatted Beneficiary
PNBPUS3N
[/1!a][/34x] customer
or e.g.
A (Party Identifier) information is
/12345678901
4!a2!a2!c[3!c] Mandatory.
Beneficiary 59 PNBPUS3N
(Identifier Code The beneficia
/ BIC) remains
constant in th
Line 1 (subfield
message cha
Party Identifier)
[/34x]
/10078074 (Account)
1/Company One Lines 2-5 :
F
2/CITY STREET 50 (Number/Name
3/GB/LONDON and Address)
4*(1!n/33x)
(name and
address)
Remittance information is option
and provided in format 4*35x if
available. Up to 4 lines of up to 3
X characters each.
Usually the remittance informati
is generated by the beneficiary a
Remittance
70 /INV/18042-090715 sent to the ordering customer (o
Information
debtor). The beneficiary reques
the debtor to provide it the
payment message, so that the
beneficiary can easily reconcile
payment with an invoice for
instance.
It is mandatory and of format 3!a
can take 3 values: BEN, OUR an
SHA.
 OUR means charges are to
borne by the ordering
Details of customer.
71 A OUR
Charges SHA means charges are
shared between Ordering a
beneficiary customers.
BEN means charges are to
borne by the beneficiary

Optional. When 71A is BEN (or

SHA), 71G contains amount of th
charges due, which have been
deducted from the interbank
settlement amount.
Sender's Interbank settled amount =
71 F EUR2,50
charges Instructed amount - Sender's
charges.
Format 3!a15d
Caution: there can be several
different 71F in a same MT202
COV.
Optional. When 71A is OUR (or
SHA), 71G contains amount of th
charges due, which have been
prepaid and included in the
Receiver's
71 G EUR2,50 interbank settlement amount.
charges
Format 3!a15d
Caution : there can be several
different 71G in a same MT202
COV.
This is an optional field. It takes
Format 6*35x.
There can be many codes
indicating additional information
INS is a code indicating that
BNPAFRPP is the instructing
Sender to institution. Without field 72, the
Receiver 72 /INS/BNPAFRPP receiver may not know it since th
Information information is not provided
somewhere else in the message
when sender is the next bank on
the routing chain and ordering
 institution is another bank befor
the instructing one.

2.4.3 Additional notes on MT202 COV

Some complementary notes:

The option field 53B (only variant B) is really only used to indicate
which account at the correspondent (receiver) should be debited.
Fields 51A seems to be not supported by most banks (at least all I
found such as UBS, etc.)
When no correspondent is used neither on sender side (Tag 53A) nor
on receiver side (Tag 54A) and No reimbursement party (Tags 56a
and 57a) is indicated in the SWIFT MT202 message. It means
there is a direct account relationship, in the currency of the
transfer, between the Sender and the Receiver. Money will be
taken from account and credited to the beneficiary.
Beneficiary customer account is hold by the receiver.
What to do in case of 57D if we cannot find a country code? We Use
SWIFT message Receiver BIC country (sometimes wrong but better
than nothing, only sometimes since when 57D is used we are likely in
the same country
Routing
When there is no ordering institution (Tag 52) in the SWIFT
MT202 message. That means implicitly that the ordering
customer is customer of the Sender.
When the ordering institution (Tag 52D) is provided in the
MT202 SWIFT Message. This means the ordering customer is
not customer of the Sender.
Either the sending institution sends the MT103 on behalf of
the ordering institution in 52D. This happens when the
ordering institution is a small bank that has an agreement
with a major bank (sending bank) for the processing and
settlement of currency transactions. The small bank can
use the correspondent network of sending institution.
Or the Sender is a routing bank on the chain
 Field 57 is used when the receiver of the SWIFT MT202 doesn’t own
the beneficiary account and needs to send the Message Further.
In the final MT103 on the chain, the holder of the account will be the
receiver and no field 57 will be required anymore.
This indicates that Sender and Beneficiary customer's Bank do
not have direct account relationship in the currency of the
transaction (USD). Otherwise the sender would send the
message directly to the beneficiary customer's Bank.
Sender’s reference is new for every message in the routing chain, but
end-to-end reference remains constant.
The field 58a identifies in a unique way the beneficiary institution. To
be perfectly honest, it does not have the same meaning as the 57a in
103 for instance, it rather has the same meaning as 59 to identify the
beneficiary, when the beneficiary is an institution and not a customer.
We shall use the 58 for 202 and 202.cov to identify the eventual
beneficiary institution.

3. Conclusion
The above is a collection of the most essential information we gathered at
NetGuardians when implementing SWIFT parsing to monitor payments,
specifically cross border payments. There are more Message Types
relevant when it comes to monitoring payments than those mentioned in
this article (for instance MT 205, MT 102, MT 203, etc.) but there usage is
rarer.
In addition, the listing of fields provided in this article is far from complete
and other fields of the SWIFT messages, especially from the various
headers, may be interesting for your own business. I let the reader refer to
the SWIFT MT specifications.
Last but not least, with the coming mandatory transition to XML format
(SWIFT MX), I may well need to write a new version of this article pretty
soon :-)

For the sake of exhaustivity, I wanted to complete this article by giving a

very simplified view of how SWIFT kicks-in in a Banking Information
System:

Most importantly, the SWIFT interface is connected to the payment HUB

of the banking institution. But interestingly, it is also used as an input
channel for customers, since the later may send Transfer Requests such
as MT101 to their banking institution using SWIFT.