Technological Thoughts by Jerome Kehrli

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:

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.

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.

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.

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.

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.

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.