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.
Hello,
Pl guide me in export transaction.
I will be buying goods from a seller in Dubai and selling to a buyer in Dubai only. The goods will not come to India. They will be handed over locally in Dubai.
What should be the Purpose Code for inward and outward remittance.
Please guide.
Respected sir,
if wrongly i have mention P1017 / Publishing and printing services instead of P0103 / Advance receipts against export contracts other than Nepal and Bhutan , please advise how i will correct purpose code.
Respected Sir,
What purpose code should be used when receiving inward remittance which has been paid as a reimbursement for the office expenses. E.g If I bought some office supplies like headphones and my foreign client reimbursed it.
Best regards,
Ravi Soni
Nice my bro