In the previous article, we saw how corporations use the SWIFT MT101 message to transfer funds either domestically or internationally. Now we want to go deeper and look at the content of SWIFT MT101 messages. The SWIFT MT101 message specifications is of great help to understand the messages content. Take few minutes to read it if you have not done it yet.
In this article, we will study a basic SWIFT MT101 message which contains 2 transactions: one transaction where the beneficiary account is held by the debtor bank and one transaction where the beneficiary account is held by another bank in the same country. In our example, the MT101 is sent by Saint Gobain Corporation, a french multinational company that has an account in GBP with Royal Bank of Scotland (RBS).
The table below contains the fields that are transported in the MT101 Request for Transfer. An additional column (comments) provides further explanation, so that it is easy to understand each field and what it is used for.
Explanation Format Comments Sender SGOBFRPP The Sender BIC appears in header block (Block 1) in the MT103 Input and in the application block (Block 2) in the MT101 Output. Message Type 101 The message type is the second field of the block 2. Receiver RBOSGB2L The Receiver BIC appears in header block (Block 1) in the MT101 Output and in the application block (Block 2) in the MT101 Input. Message text: General Information (Sequence A) This introduces the Text block (block 4). All the fields below are in the text block of the MT101 message. 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. See all the allowed characters on this page. Customer Specified Reference :21R:UKSUPPLIERSPAYM 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. See all the allowed characters on this page. Message Index/Total :28D: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. Ordering Customer :50H:/31926819
Compagnie de Saint Gobain
118 Rue Lauriston
75016 Paris It is optional and can be provided in three different formats according to the options F, G, or H. Option H is chosen in this case with format: :
/34x (Account)
4*35x (Name and Address) Requested Execution Date :30:181017 Mandatory and of format 6!n (Date, a valid date expressed as YYMMDD)
It is the date on which all subsequent transactions should be initiated by the executing bank. Transaction Details 1 (Sequence B first occurrence) This introduces the Mandatory Repetitive Sequence B Transaction Details. At least one occurrence must be provided. 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. See all the allowed characters on this page. Currency, Transaction Amount :32B:GBP50000, Mandatory and of format 3!a15d (Currency)(Amount) Beneficiary :59:/10078074
Company One
CITY STREET 50
LONDON, UK Beneficiary customer information is mandatory and can be provided in three different formats: No letter option, Option A and Option F. No letter option is chosen in this case with format:
[/34x] (Account) here in IBAN format
4*35x (Name and Address) Details of Charges :71A:OUR It is mandatory and of format 3!a. It can take 3 values: BEN, OUR and SHA. OUR means charges are paid exclusively by the Ordering customer. Transaction Details 2 (Sequence B second occurrence) This is the second occurrence of the Mandatory Repetitive Sequence B Transaction Details. Transaction Reference :21:56372REFOFTRX2 This field is mandatory and of format 16x. It is a reference assigned by the Sender to unambiguously identify a unique transaction. See all the allowed characters on this page. Currency, Transaction Amount :32B:GBP10000, Mandatory and of format 3!a15d (Currency)(Amount) Account With Institution :57A:BARCGB22XXX The Account with Institution is provided because the beneficiary does not have an account with the RBS, the debtor bank. The beneficiary account is with Barclays Bank. Beneficiary :59:/00072583
Company two
Bridge STREET 52
LONDON, UK Beneficiary customer information is mandatory and can be provided in three different formats: No letter option, Option A and Option F. No letter option is chosen in this case with format:
[/34x] (Account) here in IBAN format
4*35x (Name and Address) Details of Charges :71A:SHA It is mandatory and of format 3!a. It can take 3 values: BEN, OUR and SHA. SHA means charges are shared between Ordering and beneficiary customers. End of message text/trailer
Read this page on the SWIFT formatting rules and Character sets of MT Messages to get additional information and understand what 16x, 5n, 34x and the format of the field options mean.
Narratives and notes on this SWIFT MT101 message
As usual, there is more in this message than meets the eye. The following narrative and notes allow to get a deeper understanding of the message content.
Narrative and note 1 (Main purpose of this SWIFT MT101 message)
The Sender (SGOBFRPP), Saint Gobain is instructing the Receiver (RBOSGB2L), its bank, to debit its account and credit the account of two beneficiaries (since the order contains two transactions). The execution of this order may result either in one single debit with the total amount of all transactions (GBP 60000,) or in two debits for each transaction on the account provided in the field 50H of the sequence A.
Narrative and note 2 (Field 50a is not present this SWIFT MT101 message)
There is no field 50a (Instructing Party) in the message neither in the sequence A nor in the sequence B. The sender of the message owns the account to be debited.
Narrative and note 3 (Field 57A is present only in the second transaction of the SWIFT MT101)
In the first transaction, the field 57A is not provided. The sender did that because the beneficiary account is held by Royal Bank of Scotland (RBS), the debtor Bank. As a consequence, this transaction results in a book transfer for RBS.
The sender has indicated the field 57A in the second transaction because the beneficiary account is not with the Debtor Bank, but with another Bank, Barclays, which is the account with institution. RBS must therefore send a MT103 transaction to barclays either through SWIFT or through a local clearing system. A MT103 must be used because sender and receiver are financial institutions and the transaction involves end customers that are not financial institutions.
Narrative and note 4 (Details of charges in the SWIFT MT101 message)
Details of charges (71A) is OUR in the first transaction and SHA in the second transaction.
OUR means the transaction charges are to be borne by the ordering customer. The ordering customer pays charges to ordering bank, intermediary bank(s) and receiving bank.
SHA means the charges are shared between Ordering and beneficiary customer. Ordering customer pays charges to ordering bank. Beneficiary pays to receiving and other intermediary banks.
This ends our analysis of this SWIFT MT101 message. In the next article, we will analyze a SWIFT MT101 Message where ordering customer account appears in the Sequence B Transaction Details.
Can accounting be done on MT101 itself? What I have seen is always an MT103 is generated out of MT101 and accounting (dr customer cr either bene account or nos/vos account of other bank) is done on MT103 and not on MT101.
Is there is any scenario or is it appropriate to perform accounting on MT101?
Hi Prashant,
Accounting is done on the MT101 but partly. It consists of debiting the debtor account and putting the funds on an intermediary account.
When the MT103 is generated and processed, funds are debited from the intermediary account and forwards to the destination.
Thank you great article Jean.
I don’t fully agree with your comment. In a case where ‘Debtor’ bank has both originator/Beneficiary accounts, wouldn’t a single MT101 is enough for end-to-end accounting ? The bank will debit the ‘Debtor’ account and credit the ‘Beneficiary’.
Hi Amit,
Thanks for your careful reading. You are completely right. In case of an intrabank payment (meaning the same bank plays both the role of debtor bank and beneficiary bank), a single MT101 would be enough. I was assuming that the beneficiary bank is different from the debtor bank. In that case, a MT103 is required for the interbank transfer.
Hi Jean, to share my knowledge on this topic,
For MT101 or Pain001
Dr Debtor Account
Cr Intermediary Account
Up on generation of MT103 and receipt of Ack from swift,
Dr Intermediary Account
Cr Nostro Mirror Account
And in case of book to book transfer,
MT101 or Pain001, would result in,
Dr Debtor Account
Cr Bene Account
Hi Jean,
I just realized that I have not even thanked you for this nice article. I got a query and just fired it without even a hi note 🙂
Thank you so much for all the payment information you have shared. They are very clear & informative.
Thank you Prashant!
When you write a comment, You are already saying hi.🙂
I love reading comments from my readers.
Thanks Jean.
Hi Jean,
PAIEMENTOR is playing a big role as a teacher in my life. Really loving all the articles. The most important point is everything is explained with examples.
Thanks so much!!
Hi Hemant, Thank you very much.
I am very happy to read your comment. I am truly passionate and I want to help others too.
Great to see that you are benefiting from my blog.
Hi Jean ,
Is there a limit on the amount of payments you can make for an mt101 message?
Hi Miguel,
The standard does not set a limit on number of transactions (Repetitive Sequence B Transaction Details) you can put in an MT101 message.
But the maximum message length is 10,000 characters. So if you have an high number of transactions, you must split the MT101 into multiple messages (See Field 28D).
However, Banks do set own limits for many reasons (performance or SLA for example). If you send a MT101 with 1 Million transactions 15 minutes before the cut-off, I doubt that your bank will be able to process and exchange them in 15 minutes. Before sending a MT101 with a high number of transactions, I would first ask the bank if they are able to process it.
Regards,
Jean Paul
Hi,
it depends on the Debtor bank’s payments software technical capability to process bulk payments in a reasonable time interval. Because all the 1 million transactions will have to pass through various stages like routing rules, compliance checks, other basic validations etc.
Thanks Jean for this great explanation. I have a question – for more than one message in an order (where 28D is 1/5 and then 2/5 and so on), which field is used to tie them together and identify them to belong to the same order? Is it 21R?
Thanks and regards
Hi Anindita,
21R is an optional field. I would use the mandatory M20 (Sender’s Reference) instead as recommended in the SWIFT standards: “In case field 28D indicates that messages are chained, all messages belonging to the same chain must have exactly the same sender’s reference in field 20.”
All the best,
Jean Paul
Hi Jean, is there a reason to stop processing of a single element of the chain until all the elements of the same chain are received/verified. I.e. if we (as bank) receive the 1st MT101 with 1/5 in 28D – are we in position to process it immediately (independently from 2/5, 3/5 etc. messages). Is there official SWIFT clarification for that?
Hi Peter, Generally, bank systems are configured to fail such messages until all messages in the series are received. It can can assumed that it is based on swift standards as banks would follow the same.
Hi Jean, Your article is NOT one of the best, but it is the best informative article on such tricky and complex message type such as MT 101. I really appreciate your usage of the real life example with crystal clear explanation on the scenario and minute information on every field. Not only this article but also all other articles and videos deserve equal appreciation. Please continue the good work.
I have one suggestion on MT 101 articles. All articles talk about the scenario from a corporate point of view. It would be better if you could post an article when such MT 101 is received by a bank, for example: Concentrating bank, and how data received in MT 101 is transported into subsequent messages such as MT 101 and MT 103. Such article would be really useful for all banking professionals and they would be thankful to you.
Thank you Raj for your encouraging comment and for the suggestion.
Can someone help me to understand how can we format Tag 57 to populate a beneficiary bank account?
Hi Jean,
Hope you are doing well can you please share your view on the below –
MT101 can be used to move fund
a. Between ordering customer accounts
b. In favor of a third party, either domestically.
c. In favor of a third party, either internationally.
d. All of the above
Hi Jean,
Thanks for the guidance, I really appreciate your efforts:)
One query: in the tag :71A:SHA, we are indicating the charge type but how we are informing the proportion of sharing charges?
How Debtor bank ensure that the sharing proportion is correct? what if the decided sahre was 50:50 and sender guided 40:60?
Hi Jean Paul, great article always.
Do you have any materials that will compare or map MT101 messages to their ISO equivalent (pain.001)? Really eager to read through such if available .
Thanks and Regards