niceideas.ch
Technological Thoughts by Jerome Kehrli

Dissecting SWIFT Message Types involved in payments

by Jerome Kehrli


Posted on Friday Apr 05, 2019 at 11:40AM in Banking


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

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 Name Space Reference document
MT 101 Request for Transfer Customer-to-Bank and Interbank Standards MT November 2018
MT 103 Single Customer Credit Transfer Interbank
MT 202 General Financial Institution Transfer Interbank
MT 202 COV General Financial Institution Transfer Interbank
MT 9XX - Confirmations and statements Customer-to-Bank 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.

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

Meaning SWIFT Example Comment
Field Variant
AppID Block1/ApplId F The Application Identifier identifies the application within which the message is being sent or received. The available options are: F = FIN , A = GPA, etc.
These values are automatically assigned by the SWIFT system and the user's CBT
ServiceID Block1/Servid 01 The Service Identifier consists of two numeric characters. It identifies the type of data that is being sent or received and, in doing so, the type of the following message
Sender (Sending bank / BIC) Block1/ LTaddrBlk1 (I)
Or
Block2/ LTaddrBlk2 (O)
SGOBFRPP Sender BIC appears in header block (Block 1) in the MT101 Input and in the application block (Block 2) in the MT101 Output
(Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out
Message Type Block2/ Msgtype 101 SWIFT Message Type = MT 101
Receiver (Receiving Bank / BIC) Block2/ LTaddrBlk21 (I)
Or
Block1/ LTaddrBlk1 (O)
RBOSGB2L The Receiver BIC appears in header block (Block1) in the MT101 Output and in the application block (Block 2) in the MT101 Input.
(Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out.
The receiver of the message is the eventual beneficiary only if no field 57 says otherwise.
Sender's Reference 20 ORDERREF1234 This field is mandatory and of format 16x. It is a reference assigned by the Sender to unambiguously identify the message.
Customer Specified Reference 21 R GBSUPPLIERS5668 The field is optional and of format 16x. It is a reference to the entire message assigned by either the instructing party, when present or by the ordering customer, when the instructing party is not present.
Message Index/Total 28 D 1/1 It is mandatory and of format : 5n/5n for (Message Index)/(Total) If you send 5 messages for the same order, this field will take the value 1/5 in the first message, 2/5 in the second message, and so on.
1/1 means there is only one message sent for this order.
Sender Msg. Sending Timestamp (O) Block2 / ‘ Intime + Inmate (I) System.time() 1538070522 (O) = Output only : SWIFT timestamp for an Output message (HHMMYYMMDD) or local date/time for an Input Message.
In / Out-put flag Block2 / Inoutind I Single letter ‘I' or ‘O'
Ordering Customer 50 F /DE20700800000...
1/Essilor International
2/147 Rue de Paris
3/FR/Charenton 94220
Line 1 (subfield Party Identifier)
    /34x (Account)
Lines 2-5 : (Number/Name and Address)
    1!n/33x (Number)(Details)
The field ordering customer is mandatory. In can be given either in the message details (here) or per transaction in the repeating sequence
G /31926819
UBSCH123FNX
Line 1 (subfield Party Identifier)
    /34x (account)
Line 2 (subfield bank)
    BIC (8 or 11 characters)
H /31926819
Compagnie de Saint Gobain
118 Rue Lauriston
75016 Paris
Line 1 (subfield Party Identifier)
    /34x (Account)
Lines 2-5 : (Number/Name and Address)
    4*35x (Name and Address)
Authorization 25 12DF64BG345A Optional, 35x (authorization code)
Requested Execution Date 30 181017 The value date, mandatory and of format 6!n (YYMMDD). It is the date on which all subsequent transactions should be initiated by the executing bank.
Repeating Sequence
Transaction Reference 21 35863REFOFTRX1 This field is mandatory and of format 16x. It is a reference assigned by the Sender to unambiguously identify a unique transaction.
F/X Deal Reference 21 F FXDEALID78685 Optional, if there is an underlying foreign exchange deal to this transaction, then this field specifies the FX deal reference
Instruction Code 23 E CMZB (= Code to Zero balance the account. This transaction contains a cash Management instruction, requesting to zero balance the account of the ordering customer)
INTC =( Code for Intra-Company Payment.)
It is optional and of format :4!c[/30x] (Instruction Code)(Additional Info.)
Optional instruction codes that identifies the operation types.
Caution : there can be several instruction codes (all with same code) in the SWIFT message.
Charges Account 25 A /FR763000402837... This is the ordering customer's account number to which applicable transaction charges should be separately applied by the debtor.
Currency,
Transaction Amount
32 B GBP50000 Mandatory and of Format 3!a15d (Currency)(Amount)
Currency, Original Ordered Amount 33 B EUR200000 This optional field is provided in format 3!a15d. It specifies the original currency and amount as specified by the ordering customer.
Exchange Rate 36 1,1382 Mandatory since field 33B is present and 'amount' in field 32B is not equal to zero. Provided in format 12d. The integer part of Rate must contain at least one digit. A decimal comma is mandatory and is included in the maximum length.
Instructing Party 50 L Compagnie de Saint Gobain
118 Rue Lauriston
75016 Paris
This field is optional and to be provided if the sending customer (instructing party) is different than the owner of the account (but has an authorization to make payment on account given by owner)
Compagnie de Saint Gobain instructs the payment but does not own the account to be debited. It is authorized by it's the owner (e.g. a subsidiary) to pay form the ordering customer account provided below.
Ordering Customer 50 F /DE207008000...
1/Essilor International
2/147 Rue de Paris
3/FR/Charenton 94220
Line 1 (subfield Party Identifier)
    /34x (Account)
Lines 2-5 : (Number/Name and Address)
    1!n/33x (Number)(Details)
The field ordering customer is mandatory. In can be given either in the message details or per transaction in the repeating sequence (here)
G /31926819
UBSCH123FNX
Line 1 (subfield Party Identifier)
    /34x (account)
Line 2 (subfield bank)
    BIC (8 or 11 characters)
H /31926819
Compagnie de Saint Gobain
118 Rue Lauriston
75016 Paris
Line 1 (subfield Party Identifier)
    /34x (Account)
Lines 2-5 : (Number/Name and Address)
    4*35x (Name and Address)
Account Servicing Institution 52 A //083098 (BSB)
NATAAU33 (bic)
This is to notify the receiving bank that the institution owning the account to debit is another institution So the MT101 needs to be transferred to that other institution identified here.
The BSB (Bank State Branch) code and the BIC are provided.
Even if it is not mandatory in the SWIFT standards to use the BSB code preceded by a double slash. Many banks impose it.
We need to parse the BIC out of it
Format :
&bnsp;&bnsp;&bnsp;&bnsp;[/1!a][/34x] (Party Identifier)
&bnsp;&bnsp;&bnsp;&bnsp;4!a2!a2!c[3!c] (Identifier Code)
Intermediary Institution 56 A PNBPUS3N (bic) This is the Correspondent of the Creditor Bank. It holds the account in currency of the creditor bank.
It is optional and can be provided in option A, C or D.
Formats C or D are rarely used and most of the time not supported by banks.
Option A is formatted [/1!a][/34x] (Party Identifier)
4!a2!a2!c[3!c] (Identifier Code / BIC)
Account With Institution 57 A BARCGB22XXX (bic)
or e.g.
//939400 (BSB)
AMPBAU2SXXX (bic)
We need to parse the BIC out of it
Format :
    [/1!a][/34x] (Party Identifier )
    4!a2!a2!c[3!c] (Identifier Code)
Optional. The Account with Institution is provided because the beneficiary does not have an account with the debtor bank, but with another bank .(i.e. an MT103 will be sent further)
It can be provided in option A, B, C or D.
Formats B, C are rarely used and most of the time not supported by banks.
For instance, in case the Creditor bank is not the same as the debtor bank (most of the time), it is identified in field 57a. The BSB (Bank State Branch) code and the BIC of AMP Bank are provided.
We need to parse the BIC out of it or hash the address
(priority over header)
D Hong Kong Banking Assoc.
Avenue du Léman
1204 Genève - CH
Switzerland
If no BIC is available to identify the target institution, option D is used.
In principle minimum 3 lines with name and address should be provided
Format:
    [/1!a][/34x] (Party Identifier)
    4*35x (Name and Address)
In this case, take country from receiver BIC
Beneficiary 59 (no letter) /26351-38947
Company One
CITY STREET 50
LONDON, UK
Line 1 :
    [/34x] (Account) IBAN format or else
Line 2-5:
    4*35x (Name and Address)
Beneficiary customer information is Mandatory
A NBPUS3N
or e.g.
/12345678901
PNBPUS3N
Option A is formatted
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code / BIC)
F /10078074
1/Company One
2/CITY STREET 50
3/GB/LONDON
Line 1 (subfield Party Identifier)
    [/34x] (Account)
Lines 2-5 : (Number/Name and Address)
    4*(1!n/33x) (name and address)
Remittance Information 70 Payment from
Compagnie de Saint Gobain
/INV/7828728292
Remittance information is optional and provided in format 4*35x if available. Up to 4 lines of up to 35 X characters each. The name of the parent company is provided here, so that the beneficiary can see it is the parent company that is paying.
Details of Charges 71 A OUR 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.
  • SHA means charges are shared between Ordering and beneficiary customers.
  • BEN means charges are to be borne 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.

Meaning SWIFT Example Comment
Field Variant
AppID Block1/ApplId F The Application Identifier identifies the application within which the message is being sent or received. The available options are: F = FIN , A = GPA, etc.
These values are automatically assigned by the SWIFT system and the user's CBT.
ServiceID Block1/Servid 01 The Service Identifier consists of two numeric characters. It identifies the type of data that is being sent or received and, in doing so, the type of the following message
Sender (Sending bank / BIC) Block1/ LTaddrBlk1 (I)
Or
Block2/ LTaddrBlk2 (O)
SGOBFRPP Sender BIC appears in header block (Block 1) in the MT103 Input and in the application block (Block 2) in the MT103 Output
(Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out
Message Type Block2/ Msgtype 103 SWIFT Message Type = MT 103
Cover or Serial Transfer Type If field 56a or 57a are present : then transfer type = "serial"
If field 53a (ex 53B) or 54a are present : then transfer type = "announce (cover)"
(Default : serial)
Knowing whether the MT103 is a serial transfer or the announce preceding a cover transfer is important. For a given use case, we actually expect a banking institution always to use the very same method.
Receiver (Receiving Bank / BIC) Block2/ LTaddrBlk2(I)
Or
Block1/ LTaddrBlk1 (O)
RBOSGB2L The Receiver BIC appears in header block (Block1) in the MT103 Output and in the application block (Block 2) in the MT103 Input.
(Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out.
The receiver of the message is the eventual beneficiary only if no field 57 says otherwise.
Unique End-to-end Transaction Reference Block3/ Tag 121 b03c6901-bbed-4aa9-afdh-A5bc26d19257 This reference is provided in the user block (Block 3) and transported end-to-end. It is mandatory in MT103 but can still be missing as well as have duplicates.
Sender's Reference 20 ORDERREF1234 This field is mandatory and of format 16x. It is a reference assigned by the Sender to unambiguously identify the message.
Sender Msg. Sending Timestamp (O) Block2 / ‘ Intime + Indate
(I) Sys.time()
1538070522 (O) = Output only : SWIFT timestamp for an Output message (HHMMYYMMDD)
or local date/time for an Input Message.
In / Out-put flag Block2 / Inoutind I Single letter ‘I' or ‘O'
Bank operation code 23 B CRED It is mandatory and of format 4!c.
Instruction code 23 E PHOB/+34.91.397.6789 It is optional and of format :4!c[/30x] (Instruction Code)(Additional Info.)
Code PHOB means Phone Benef.. The sender requests the benef. bank to contact benef. by phone when funds are received.
Value Date / currency / interbank settled amount 32 A 180816USD2325, It is mandatory and of format 6!n3!a15d (Date)(Currency)(Amount).
Note the trailing coma (i.e. decimal part is not mandatory if 0)
Currency / Instructed Amount 33 B USD2350, Normally optional in the standard. It may be provided for instance because the sender has taken fees. See field 71F below.
Format 3!a15d (Currency)(Amount)
Ordering Customer 50 A /DE3750070010...
DEUTDEFF
Line 1 (subfield Party Identifier)
    /34x (account)
Line 2 (subfield bank)
    4!a2!a2!c[3!c] (Identifier Code)
The field ordering customer is mandatory. In can be given either in the message details (here) or per transaction in the repeating sequence.
The ordering customer is customer of the sender only if there is no field 52. The ordering customer remains constant in the message chain.
F /DE207008000...
1/Essilor International
2/147 Rue de Paris
3/FR/Charenton-le-Pont, 94220
Line 1 (subfield Party Identifier)
    /34x (Account)
Lines 2-5 : (Number/Name and Address)
    1!n/33x (Number)(Details)
K /CH570483509...
GALLMAN COMPANY GMBH
RAEMISTRASSE, 71
8006 ZURICH
SWITZERLAND
Line 1 : (subfield party identified)
    /34x (Account)
Line 2-5 (subfield Address)
    4*35x (Name and Address)
Ordering institution 52 A BNPAFRPP
or e.g.
/FR123509321...
BNPAFRPP
Format
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code)
Ordering institution is optional and can be provided in two options A (usual) and D (less common).
The sender populates this field to indicate that the initial instruction comes from another institution (ordering institution).
The ordering institution remains constant in the message chain.
(priority over header)
D BANQUE DELUBAC ET CIE
16 PL SALEON
TERRAS
07160 LE CHEYLARD
Format
    [/1!a][/34x] (Party Identifier)
    4*35x (Name and Address)
Sender's correspondent 53 A PNBPUS3N
or e.g.
/12345678901
PNBPUS3N
Cover payments only
Correspondent of sender. Sender has an account in Currency with this banking institution.
Option A is formatted
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code / BIC)
B /12345678901 Caution : Serial and cover payments.
Field 53B indicates the account number of the Sender, serviced by the Receiver, which is to be used for reimbursement (debit) in the 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 practice, the account number is almost always provided.
Receiver's correspondent 54 A IRVTUS3N
or e.g.
/9876412-1234/123
IRVTUS3N
Cover payments only.
Correspondent of receiver. Receiver has an account in currency with this banking institution.
Option A is formatted
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code / BIC)
Intermediary Institution 56 A IRVTUS3N (bic)
or e.g.
/939400 (BSB or account)
AMPBAU2SXXX (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) in case of a serial payment transfer.
It is optional and can be provided in option A, C or D.
Formats C or D are rarely used and most of the time not supported by banks.
Option A is formatted
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code / BIC)
Account With Institution 57 A BARCGB22XXX (bic)
or e.g.
//939400 (BSB)
AMPBAU2SXXX (bic)
We need to parse the BIC out of it
Format :
    [/1!a][/34x] (Party Identifier )
    4!a2!a2!c[3!c] (Identifier Code)
Serial payments only.
Account with institution is optional and can be provided in option A, B, C or D.
Formats B, C are rarely used and most of the time not supported by banks.
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.
We need to parse the BIC out of it or hash the address
(priority over header)
D Hong Kong Banking Assoc.
Avenue du Léman
1204 Genève - CH
Switzerland
If no BIC is available to identify the target institution, option D is used.
In principle minimum 3 lines with name and address should be provided
Format :
    [/1!a][/34x] (Party Identifier )
    4*35x (Name and Address)
In this case, take country from receiver BIC.
Beneficiary 59 (no letter) /26351-38947
Company One
CITY STREET 50
LONDON, UK
Line 1 :
    [/34x] (Account) (IBAN format or else)
Line 2-5:
    4*35x (Name and Address)
Beneficiary customer information is Mandatory.
The beneficiary remains constant in the message chain.
A PNBPUS3N
or e.g.
/12345678901
PNBPUS3N
Option A is formatted
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code / BIC)
F /10078074
1/Company One
2/CITY STREET 50
3/GB/LONDON
Line 1 (subfield Party Identifier)
    [/34x] (Account)
Lines 2-5 : (Number/Name and Address)
    4*(1!n/33x) (name and address)
Remittance Information 70 /INV/18042-090715 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 the beneficiary and sent to the ordering customer (or debtor). The beneficiary requests the debtor to provide it the payment message, so that the beneficiary can easily reconcile the payment with an invoice for instance.
Details of Charges 71 A OUR 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.
  • SHA means charges are shared between Ordering and beneficiary customers.
  • BEN means charges are to be borne by the beneficiary
Sender's charges 71 F EUR2,50 Optional. When 71A is BEN (or SHA), 71G contains amount of the charges due, which have been deducted from the interbank settlement amount.
Interbank settled amount = Instructed amount - Sender's charges.
Format 3!a15d
Caution: there can be several different 71F in a same MT103.
Receiver's charges 71 G EUR2,50 Optional. When 71A is OUR (or SHA), 71G contains amount of the charges due, which have been prepaid and included in the interbank settlement amount.
Format 3!a15d
Caution : there can be several different 71G in a same MT103.
Sender to Receiver Information 72 /INS/BNPAFRPP 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 institution. Without field 72, the receiver may not know it 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.

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

Meaning SWIFT Example Comment
Field Variant
AppID Block1/ApplId F The Application Identifier identifies the application within which the message is being sent or received. The available options are: F = FIN , A = GPA, etc.
These values are automatically assigned by the SWIFT system and the user's CBT.
ServiceID Block1/Servid 01 The Service Identifier consists of two numeric characters. It identifies the type of data that is being sent or received and, in doing so, the type of the following message
Sender (Sending bank / BIC) Block1/ LTaddrBlk1 (I)
Or
Block2/ LTaddrBlk2 (O)
SGOBFRPP Sender BIC appears in header block (Block 1) in the MT202 Input and in the application block (Block 2) in the MT202 Output
(Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out
Message Type Block2/ Msgtype 202 SWIFT Message Type = MT 202
Validation Flag Block3/Tag119 COV (if MT202 is a cover payment) This validation flag is provided the user block (Block 3) and transported end-to-end. It indicates that the message is a MT202 Cover.
Receiver (Receiving Bank / BIC) Block2/ LTaddrBlk2(I)
Or
Block1/ LTaddrBlk1 (O)
RBOSGB2L The Receiver BIC appears in header block (Block1) in the MT292 Output and in the application block (Block 2) in the MT202 Input.
(Input and output related to the SWIFT network, not the bank). Need to use field Block2 / Inoutind to find out.
The receiver of the message is the eventual beneficiary only if no field 57 says otherwise.
Unique End-to-end Transaction Reference Block3/ Tag 121 b03c6901-bbed-4aa9-afdh-A5bc26d19257 This reference is provided in the user block (Block 3) and transported end-to-end. It is mandatory in MT103 but can still be missing as well as have duplicates.
Sequence A - General Information (Matching MT 202 format)
Sender's Reference 20 ORDERREF1234 This field is mandatory and of format 16x. It is a reference assigned by the Sender to unambiguously identify the message.
Related reference 21 123456789ABCDEF This field is mandatory and of format 16x.
Sender Msg. Sending Timestamp (O) Block2 / ‘ Intime + Indate
(I) Sys.time()
1538070522 (O) = Output only : SWIFT timestamp for an Output message (HHMMYYMMDD)
or local date/time for an Input Message.
In / Out-put flag Block2 / Inoutind I Single letter ‘I’ or ‘O’
Value Date / currency / interbank settled amount 32 A 180816USD2325, It is mandatory and of format 6!n3!a15d (Date)(Currency)(Amount).
Note the trailing coma (i.e. decimal part is not mandatory if 0)
Ordering institution 52 A BNPAFRPP
or e.g.
/FR1235093212...
BNPAFRPP
Format
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code)
Ordering institution is optional and can be provided in two options A (usual) and D (less common).
The sender populate this field to indicate that the initial instruction comes from another institution (ordering institution).
The ordering institution remains constant in the message chain.
(priority over header)
D BANQUE DELUBAC ET CIE
16 PL SALEON
TERRAS
07160 LE CHEYLARD
Format
    [/1!a][/34x] (Party Identifier)
    4*35x (Name and Address)
Sender's correspondent 53 A PNBPUS3N
or e.g.
/12345678901
PNBPUS3N
Cover payments only
Correspondent of sender. Sender has an account in Currency with this banking institution.
Option A is formatted
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code / BIC)
B /12345678901 Caution : Serial and cover payments.
Field 53B indicates the account number of the Sender, serviced by the Receiver, which is to be used for reimbursement (debit) in the 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 practice, the account number is almost always provided.
Receiver’s correspondent 54 A IRVTUS3N
or e.g.
/9876412-1234/123
IRVTUS3N
Cover payments only.
Correspondent of receiver. Receiver has an account in currency with this banking institution.
Option A is formatted
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code / BIC)
Intermediary Institution 56 A IRVTUS3N (bic)
or e.g.
/939400 (BSB or account)
AMPBAU2SXXX (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) in case of a serial payment transfer.
It is optional and can be provided in option A, C or D.
Formats C or D are rarely used and most of the time not supported by banks.
Option A is formatted
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code / BIC)
Account With Institution 57 A BARCGB22XXX (bic)
or e.g.
//939400 (BSB)
AMPBAU2SXXX (bic)
We need to parse the BIC out of it
Format :
    [/1!a][/34x] (Party Identifier )
    4!a2!a2!c[3!c] (Identifier Code)
Serial payments only.
Account with institution is optional and can be provided in option A, B, C or D.
Formats B, C are rarely used and most of the time not supported by banks.
Option A is formatted
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code / BIC)
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.
We need to parse the BIC out of it or hash the address
(priority over header)
D Hong Kong Banking Assoc.
Avenue du Léman
1204 Genève - CH
Switzerland
If no BIC is available to identify the target institution, option D is used.
In principle minimum 3 lines with name and address should be provided
Format :
    [/1!a][/34x] (Party Identifier )
    4*35x (Name and Address)
Beneficiary Institution 58 A BNPAFRPP
or e.g.
/FR123509321...
BNPAFRPP
Format
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code)
Beneficiary Institution is a mandatory field.
In the Case of MT 202 and MT 202.COV, beneficiary institution is the most reliable and straightforward way to identify the eventual beneficiary institution of the founfs.
D BANQUE DELUBAC ET CIE
16 PL SALEON
TERRAS
07160 LE CHEYLARD
Format
    [/1!a][/34x] (Party Identifier)
    4*35x (Name and Address)
Sender to Receiver Information 72 /INS/BNPAFRPP 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 institution. Without field 72, the receiver may not know it 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.
Sequence B - Underlying Customer Credit Transfer Detail
Currency / Instructed Amount 33 B USD2350, Normally optional in the standard. It may be provided for instance because the sender has taken fees. See field 71F below.
Format 3!a15d (Currency)(Amount)
Ordering Customer 50 A /DE3750070010...
DEUTDEFF
Line 1 (subfield Party Identifier)
    /34x (account)
Line 2 (subfield bank)
    4!a2!a2!c[3!c] (Identifier Code)
The field ordering customer is mandatory. In can be given either in the message details (here) or per transaction in the repeating sequence.
The ordering customer is customer of the sender only if there is no field 52. The ordering customer remains constant in the message chain.
F /DE207008000...
1/Essilor International
2/147 Rue de Paris
3/FR/Charenton-le-Pont, 94220
Line 1 (subfield Party Identifier)
    /34x (Account)
Lines 2-5 : (Number/Name and Address)
    1!n/33x (Number)(Details)
K /CH5704835098...
GALLMAN COMPANY GMBH
RAEMISTRASSE, 71
8006 ZURICH
SWITZERLAND
Line 1 : (subfield party identified)
    /34x (Account)
Line 2-5 (subfield Address)
    4*35x (Name and Address)
Beneficiary 59 (no letter) /26351-38947
Company One
CITY STREET 50
LONDON, UK
Line 1 :
    [/34x] (Account) (IBAN format or else)
Line 2-5:
    4*35x (Name and Address)
Beneficiary customer information is Mandatory.
The beneficiary remains constant in the message chain.
A PNBPUS3N
or e.g.
/12345678901
PNBPUS3N
Option A is formatted
    [/1!a][/34x] (Party Identifier)
    4!a2!a2!c[3!c] (Identifier Code / BIC)
F /10078074
1/Company One
2/CITY STREET 50
3/GB/LONDON
Line 1 (subfield Party Identifier)
    [/34x] (Account)
Lines 2-5 : (Number/Name and Address)
    4*(1!n/33x) (name and address)
Remittance Information 70 /INV/18042-090715 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 the beneficiary and sent to the ordering customer (or debtor). The beneficiary requests the debtor to provide it the payment message, so that the beneficiary can easily reconcile the payment with an invoice for instance.
Details of Charges 71 A OUR 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.
  • SHA means charges are shared between Ordering and beneficiary customers.
  • BEN means charges are to be borne by the beneficiary
Sender's charges 71 F EUR2,50 Optional. When 71A is BEN (or SHA), 71G contains amount of the charges due, which have been deducted from the interbank settlement amount.
Interbank settled amount = Instructed amount - Sender's charges.
Format 3!a15d
Caution: there can be several different 71F in a same MT202 COV.
Receiver's charges 71 G EUR2,50 Optional. When 71A is OUR (or SHA), 71G contains amount of the charges due, which have been prepaid and included in the interbank settlement amount.
Format 3!a15d
Caution : there can be several different 71G in a same MT202 COV.
Sender to Receiver Information 72 /INS/BNPAFRPP 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 institution. Without field 72, the receiver may not know it 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.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.



No one has commented yet.

Leave a Comment

HTML Syntax: Allowed