Swift Message vs Purpose codes

SWIFT mechanism

Introduction

Before 1990 money was used to transfer electronically through cable message service from one bank to another using ‘Telegraphic Transfer’ mode. But unfortunately, this was found not secured and in absence of automated system SWIFT was founded in 1973 to replace the telex or telegraphic transfer. It was founded with 239 banks in 15 countries in 1973 but in 2022 there is more than 11,000 customers hailing from 200 countries joined the network. India is the 74th country to join SWIFT network on 2nd December, 1991. SWIFT enable banks to pass on remittance information with no loss of date and makes it easy for end users to reconcile incoming funds with invoices payable.

Precaution

Wire transfer is definitely safe and secure provide we know the person from whom the transfer is coming and who is receiving them. Each person involved in wire transaction should be required to prove their identity so that illegal transfer can be stopped and authorized dealer can freeze the fund. Further AD bank should make sure that the money sent overseas is not being used to fund terrorist activities i.e. the transfer should be made to safe- haven countries.

Advantages

• Wire transfers offer a convenient, quicker and easier way to send money. The settlement is done in faster way even across borders.
• Remittances are sent all across the globe in huge amounts.
• No physical money is transferred between banks or financial institutions when conducting a wire transfer.

Disadvantages

• Banks often charge a flat fee for wire transfers, which can range between $15 and $45 and make wires impractical and costly. They eat up a large percentage of the transferred amount, especially for smaller transactions.
• Wire transfers cannot be reversed so it’s important to make sure at the time of sending money that money has been sent to the intended recipient.

How does a SWIFT message work?

• A wire transfer is used to transfer funds from one bank or financial institution to another.
• The sender first pays for the transaction upfront at their bank.
• The sending bank sends a message to the recipient’s bank with payment instructions through SWIFT.
• The recipient’s bank receives all the necessary information from the initiating bank and deposits its own reserve funds into the correct account.
• The two banking institutions then settle the payment on the back end (after the money has already been deposited).

Format of SWIFT message

Swift messages consist of five blocks of data including three headers, message content and a trailer. Message types are crucial to identifying content. All SWIFT messages include the literal “MT” (message type/text). This is followed by a three-digit number that denotes the message category, group and type.

For example, the SWIFT code for Tashkent, Uzbekistan would look like this:

JSCLUZ22XXX Swift code Breakdown
Bank Code	JSCL
Country Code	UZ
Location & Status	22 represents location , second digit 2 means active code
Branch Code	XXX or not assigned indicating that this a Head Office

SWIFT categories

The table below shows the nine (9) different categories and the message type descriptions.

Category	Message Type	Description
0	MTOXX	System message
1	MT1XX	Customer Payments and Cheques
2	MT2XX	Financial Institution Transfer
3	MT3XX	Treasury Markets, Foreign Exchange, Money Markets
4	MT4XX	Collection
5	MT5XX	Securities Markets
6	MT6XX	Treasury Markets-metals
7	MT7XX	Documentary credits and guarantees
8	MT8XX	Travellers cheques
9	MT9XX	Cash management and customer status

There are nine types of message under which SWIFT transaction happens. Out of nine message types here we are discussing swift message type MT101 and MT103 with the type designation MT1XX

SWIFT Message Type	Description
MT 101	Request for Transfer
MT 103	Single Customer Credit Transfer

MT101

Under MT01 message is sent from the Forwarding Bank to the Executing Bank. The request for transfer (MT101) is requesting the receiving financial institution or account servicing financial institution to initiate and settle a payment instruction (domestically or internationally) on behalf of the ordering customer.

This is the case where banks open accounts with each other (Nostro/Vostro) and settle funds directly. The prerequisite here is that banks need to open accounts with each other or in other words they need to have an accounting relationship with the other bank.

Now, let us try to understand the connection between sending/receiving SWIFT messages and the movement of funds from one party to another during the entire payment chain.

In this example, we will take a payment settle through correspondent banking

MT103

An MT103 is a standardised SWIFT payment message used specifically for cross border/international wire transfers. MT103s are globally accepted as proofs of payment and include all payment details such as date, amount, currency, sender and recipient.

The Serial method is simply a chain of single transactions between each bank in the chain with each bank having an account at the other bank. The payment information and the settlement instruction travel together in the MT 103 message (the most common SWIFT standard)

What is the difference between MT01 and MT103?

MT101 has been designed for corporates and allows for bulk payments. MT103 has been designed for a single customer credit transfer.

Components of SWIFT message

There are two main components in SWIFT message i.e., Tag and field. The field generally refers to the complete fields with its name and value. While the tag usually refers to the name of the field, including the number. All general information along with transaction details are mentioned against each tag based on which Authorised Dealer as well as end user can locate and identify the transaction along with sender’s details and the purpose under which payment is routed.

SWIFT MT101 Format:

Tag20	Sender’s Reference	Mandatory	when you make a payment it will later appear in bank account statement
Tag 21	Customer specified Reference/Transaction Reference	Optional	a unique number generated for every transaction to recognize transactions involving fund transfer
Tag 21F	F/X deal Reference	Optional	specifies the foreign exchange contract reference between the Ordering Customer and the Account Servicing Financial Institution
Tag 23E	Instruction Code	Optional	four-character field to specify the instruction type. CORT for a payment to be made in the settlement of a transaction; INTC for a payment to be made between two companies of the same group; and. SDVA for a payment to be made to the final beneficiary.
Tag 25A	Charge Amount	Optional	This field specifies the Ordering Customer’s account number to which applicable transaction charges should be separately applied.
Tag 28D	Message Index	Mandatory	In this case: always 1/1 This field chains different messages by specifying the sequence number in the total number of messages. Both the message index and the total number of messages allow the receiver to check that all transactions to be executed have been received
Tag 30	Requested execution date	Mandatory	The requested execution date represents the date on which the Ordering Customer’s account(s) is (are) to be debited.
Tag 32B	Currency/Transaction Amount	Mandatory	This field specifies the currency and the amount of the subsequent transfer to be executed by the Receiver. The amount is subject to deduction of the Receiver’s/Beneficiary’ s Bank’s charges if field :71A: is BEN or SHA
Tag 33B	Currency/Original Ordered Amount	Optional	This field specifies the original currency and amount as specified by the Ordering Customer, when different from the transaction currency and amount specified
Tag 36	Exchange Rate	Optional	This field specifies the exchange rate applied by the ordering customer/instructing party when converting the original ordered amount to the transaction amount.
Tag 50C/50L	Instructing Party	Optional	this field identifies the initiator(s) of the transaction if anyone is instructing on behalf of another or more of his clients, or if he is acting as a custodian or settlement agent.
Tag 50F/50G	Ordering Customer	Optional	this field identifies the name and address of the customer (i.e. not a financial institution) that initiated the transaction.
Tag 51A	Sending Institution	Optional	A sending institution needs to know only the receiving institution’s SWIFT code, and the recipient’s own bank account number, to complete the transaction
Tag 56A/56C/56D	Intermediatory	Optional	This field specifies the Financial Institution between the receiver and the account with institution through which the transaction must pass
Tag 59/59A	Beneficiary	Mandatory	This field identifies the beneficiary
Tag 70	Remittance information	Optional	This field specifies details of the individual transactions which are to be transmitted to the Beneficiary Customer. One of the following codes may be used, placed between slashes: INV Invoice (followed by the date, reference and details of the invoice). RFB Reference for the beneficiary customer (followed by up to 16 characters). ROC Ordering customer’s reference. EXAMPLE :70:/RFB/BET072 :70:/INV/abc/SDF96//1234-234///ROC/98I U87
Tag 71A	Details of charge	Mandatory	This field specifies which party will bear the applicable charges for the subsequent transfer of funds. One of the following code words must be used: OUR (All transaction charges for the subsequent credit transfer are to be borne by the ordering customer.) SHA (All transaction charges other than the charges of the financial institution servicing the ordering customer account are borne by the beneficiary customer.) BEN (All transaction charges, including the charges of the financial institution servicing the ordering customer’s account, for the subsequent credit transfer(s) are to be borne by the beneficiary customer.)

SWIFT MT103 Format:

Tag20	Sender’s Reference	Mandatory	when you make a payment it will later appear in bank account statement
Tag 23B	Bank Operation Code	Mandatory	There are four-character field to specify the type of operation to which your instruction relates: CRED for a credit transfer that involves no SWIFT Service Level; SPAY for a credit transfer to be processed according to the SWIFT Pay Service Level; SSTD for a credit transfer to be processed according to the SWIFT Standard Service Level; and SPRI  for a credit transfer to be processed according to the SWIFT Priority Service Level.
Tag 23E	Instruction Code	Optional	four-character field to specify the instruction type. CORT for a payment to be made in the settlement of a transaction; INTC for a payment to be made between two companies of the same group; and. SDVA for a payment to be made to the final beneficiary.
Tag 26T	Transaction type code	Optional	this is a three-letter field to specify the nature of, the purpose of, and the reason for the transaction.
Tag 32A	Value Date/Currency/Interbank Settled Amount	Mandatory	This field, which contains three subfields, to provide more information on the cash amount of your wire transfer instruction. In the first six-digit subfield, indicate the value date of your instruction in the format year-month-day. In the second three-letter subfield, indicate the currency code of one of the currencies accepted for settlement in Euroclear Bank In the third subfield, indicate the cash amount. This subfield may contain up to 12 digits, followed by a decimal comma and up to two decimals. For JPY, decimals are not allowed. The three subfields cannot be separated by any blanks (e.g. :32A:001019USD1500000,).
Tag 33B	Currency/Original Ordered Amount	Optional	This field specifies the original currency and amount as specified by the Ordering Customer, when different from the transaction currency and amount specified
Tag 36	Exchange rate	Optional	This is a 12-character field to indicate the exchange rate used to convert the instructed amount (specified in :33B:) into the currency of the cash amount (specified in :32A:
Tag 50a	Ordering Customer	Mandatory	This field is used to identify the name and address of the customer
Tag 52a	Ordering Institution	Optional	This means the ordering customer is not customer of the Sender.
Tag 53a	Sender’s correspondent	Optional	This field to indicates the sender’s correspondent. A to specify the correspondent’s BIC B, if the BIC is not known, to specify the correspondent’s location; or D to specify the correspondent’s name and address in a maximum of three lines of 35 characters.
Tag 54a	Receiver’s correspondent	Optional	This field indicates the financial institution that has been designated by the ordering institution as the final beneficiary of the funds.
Tag 56A/56C/56D	Intermediatory	Optional	This field specifies the Financial Institution between the receiver and the account with institution through which the transaction must pass
Tag 59/59A	Beneficiary	Mandatory	This field identifies the beneficiary
Tag 70	Remittance information	Optional	This field specifies details of the individual transactions which are to be transmitted to the Beneficiary Customer. One of the following codes may be used, placed between slashes: INV Invoice (followed by the date, reference and details of the invoice). RFB Reference for the beneficiary customer (followed by up to 16 characters). ROC Ordering customer’s reference. EXAMPLE :70:/RFB/BET072 :70:/INV/abc/SDF96//1234-234///ROC/98I U87
Tag 71A	Details of charge	Mandatory	This field specifies which party will bear the applicable charges for the subsequent transfer of funds. One of the following code words must be used: OUR (All transaction charges for the subsequent credit transfer are to be borne by the ordering customer.) SHA (All transaction charges other than the charges of the financial institution servicing the ordering customer account are borne by the beneficiary customer.) BEN (All transaction charges, including the charges of the financial institution servicing the ordering customer’s account, for the subsequent credit transfer(s) are to be borne by the beneficiary customer.)

Purpose Code Declaration

A purpose code is a code issued by a country’s central bank that is required for successful cross-border transactions. The code is assigned to each transaction involving foreign currency and states the purpose for which the transaction is being made.

The “Purpose Code” has become mandatory for SWIFT cross-border payments effective 31 May 2021. All receipts for exports and re-exports between residents and non-residents of goods regardless of when the goods are shipped and the settlement type.

In India, the purpose codes issued by the RBI are of two categories:

Payments received by Indians or for inward remittances in foreign currency

Payments sent by Indians or for outward remittance in foreign currency

In other words, the purpose code assists regulators in determining the precise nature of a cross-border transaction. For example, if the purpose of your foreign transaction is ‘purchases for travel,’ you must use the code P0301 when processing the transfer.

The RBI has a specified list of Purpose codes that are required to be included in the details for every remittance so as to specify the nature of the transaction and the individual reason for which the transfer is being made. These codes allow the RBI to classify remittances.

Central Bank of India listed one hundred thirty six (136) purpose codes against seventeen incidents towards inward receipt of fund and similarly for outward payment listed one hundred forty two (142) purpose codes against seventeen incidents . The purpose codes against export and import transactions are mentioned below:

S.No.	Purpose	Purpose Name	Purpose Code		Description	Purpose	Purpose Name	Purpose Code		Description
01	Receipt Purpose	Export (of goods)	P0101	Value of export bills negotiated / purchased/discounted etc. (covered under GR/PP/SOFTEX/EC copy of shipping bills Other than Nepal and Bhutan		Payment Purpose	Imports	S0101	Advance Payment against imports made to countries other than Nepal and Bhutan
	Receipt Purpose	Export (of goods)	P0102	Realisation of export (full invoice value) – bills (in respect of goods) sent Other than Nepal and Bhutan		Payment Purpose	Imports	S0102	Payment towards imports – settlement of invoice other than Nepal and Bhutan
	Receipt Purpose	Export (of goods)	P0103	Advance receipts against export later by GR/PP/SOFTEX/SDF – contracts, which will other than Nepal and be covered Bhutan		Payment Purpose	Imports	S0103	Imports by diplomatic missions other than Nepal and Bhutan
	Receipt Purpose	Export (of goods)	P0104	Receipts against export/SOFTEX /EC copy of trade, i.e., third country of goods not covered by the GR /PP shipping bill etc. (under Intermediary/transit export passing through India		Payment Purpose	Imports	S0104	Intermediary trade / transit trade, i.e., third country export passing through India
	Receipt Purpose	Export (of goods)	P0105	Export bills (in respect Nepal and Bhutan		Payment Purpose	Imports
	Receipt Purpose	Export (of goods)	P0107	Realisation of NPD export bills other than Nepal and Bhutan		Payment Purpose	Imports
	Receipt Purpose	Export (of goods)	P0108	Goods sold under merchanting merchanting trade*		Payment Purpose	Imports	S0108	Goods acquired under merchanting / payment against import leg of merchanting trade*
	Receipt Purpose	Export (of goods)	P0109	Export realisation on account of exports to Nepal and Bhutan, if any		Payment Purpose	Imports	S0109	Payments made for Imports from Nepal and Bhutan, if any

On receipt of SWFT message regarding inward remittance from abroad authorised dealer sends this message to customer to validate the transaction and asks them to declare inward remittance under proper purpose code template.

A purpose code is a code issued by a country’s central bank that is required for successful cross-border transactions. The code is assigned to each transaction involving foreign currency and states the purpose for which the transaction is being made.

If the customer doesn’t declare the remittance with purpose code , banks won’t be able to make the transaction secure . In that case bank do not accept the fund and returned the same to originating bank. Similarly the customer knowingly or unknowingly declare the inward receipt against wrong purpose code , bank has the authority to ask the customer to resubmit the declaration post receipt of corresponding supported documents.