The SWIFT MT101 message can be used for various purposes. We saw in previous articles how the SWIFT MT101 is used:
[unordered_list style=”bullet”]
- to pay multiple transactions from a single account
- to pay multiple transactions from different accounts
- by a parent company to pay own bills from a subsidiary account
- by a parent company to pay bills on behalf of subsidiaries
[/unordered_list]
SWIFT MT101 usage for funds repatriation
There is another possibility: funds repatriation. And that is the topic of this article where we will see how corporations can use the SWIFT MT101 to repatriate funds. 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.
We will consider a simple example to explain the basic concepts behind funds repatriation and cash pooling.
Essilor is a multinational corporation with multi-bank relationship in Europe and worldwide. In the example, we consider two accounts owned by Essilor: one account is with BNP Paribas in France and the other account is with Dresdner Bank in Germany. Funds available on the Dresdner Bank account are to be repatriated to the BNP Paribas account. For this SWIFT MT101, the forwarding bank and the creditor Bank is the same. These two concepts were analyzed in detail in this article.
[box type=”info” size=”large” style=”rounded” border=”full”]BNP Paribas account is called centralized account, master account or leader account. The Dresdner Bank account is called secondary account or slave account.[/box]
The table below contains the fields that are transported in the MT101 Message. The last column (comments) provides further explanation about the fields. Read them carefully.
Explanation Format Comments Sender ESITFR2P 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 BNPAFRPP 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:CSHPOOL276763 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:181102CSHPOOL 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. Requested Execution Date :30:181102 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:REF503TRX1DE Mandatory and of format 3!a15d (Currency)(Amount) Instruction Code :23E:CMZB Code to Zero balance the account. This transaction contains a cash management instruction, requesting to zero balance the account of the ordering customer, so Dresdner Bank account in our case. Instruction Code :23E:INTC Code for Intra-Company Payment. Payment between two accounts of the same company or between two companies belonging to the same group. Currency, Transaction Amount :32B:EUR0, The transaction amount is zero. The Sender wants all the available funds on the ordering customer account to be repatriated to the beneficiary account. Ordering Customer :50F:/DE20700800000333880000
1/Essilor International
2/147 Rue de Paris
3/FR/Charenton-le-Pont, 94220 The ordering customer is Essilor. It is the same as the beneficiary below. So this is an intra-company payment.
Ordering customer information is optional and can be provided in three different formats: No letter option, Option A and Option F. Option F is chosen in this case with format:
Line 1 (subfield Party Identifier) /34x (Account)
Lines 2-5 (subfield Number/Name and Address) 1!n/33x (Number)(Details) Account Servicing Institution :52A:DRESDEFF Essilor has an account with Dresdner Bank in Germany. The funds available on that account, called secondary account or slave account, are to be repatriated to the account of Essilor with BNP Paribas. Account With Institution :57A:BNPAFRPP Essilor has an account with BNP Paribas in France, called centralized account, master account or leader account because it receives funds repatriated from the other accounts. Beneficiary :59F:/FR7630004000031234567890143
1/Essilor International
2/147 Rue de Paris
3/FR/Charenton-le-Pont, 94220 Beneficiary customer information is mandatory and can be provided in three different formats: No letter option, Option A and Option F. Option F is chosen in this case with format:
Line 1 (subfield Party Identifier) /34x (Account)
Lines 2-5 (subfield Number/Name and Address) 1!n/33x (Number)(Details) Details of Charges :71A:SHA It is mandatory and of format 3!a. It can takes 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 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 MT101)
Essilor (ESITFR2P) wants to repatriate funds from its Dresdner bank account to its BNP Paribas account. So it instructs the receiver (BNPAFRPP) to request Dresdner bank (DRESDEFF) to transfer funds available on its account with DRESDEFF. The amount should be credited on Essilor’s account with BNP Paribas. BNP Paribas forwards the MT101 instruction since it does hold the account to be debited. DRESDEFF, as debtor Bank, executes the instruction and send a MT103 to BNP Paribas, the creditor Bank.
Narrative and note 2 (Instruction codes this MT101)
The sender provides two instruction codes in the message. The first one (:23E:CMZB) is the most important one. It is the one informing the debtor bank that the instruction is for funds repatriation. The presence of this code allows to put a zero amount in the field 32B. The second instruction code (:23E:INTC) indicates that the transfer is between accounts of the same company of between accounts of companies belonging to the same Group.
The two instruction codes are used for cash pooling. That is why the accounts involved in funds repatriation must belong to the same company or to the same group. When the accounts are with different banks, generally the Banks involved sign an agreement. Parent company and the subsidiary companies must sign an agreement too before performing cash pooling transactions. However, note that regulations about Cash pooling are various and multiple in the different countries. There are countries where Cash pooling is not allowed all. In other countries, Cash pooling can be carried out only under certain conditions.
Cash pooling is a key topic in payment that will be addressed in detail later in this blog. In the next articles, we want to take a closer look at negotiable instruments.
Thank you for great article 🙂
I have went through MT101 specifications but struggling to understand the difference between tag 20 and 21R.
As per description:
Tag 20 – reference assigned by sender to identify the payment
Tag 21R – reference assigned by Ordering customer/Instructing party to identify the payment
Isn’t Ordering Customer(21R) itself is MT101 sender(20) ? Request you to put some light on it.
Read MT101 again and I think 20 and 21R will come into play when tag 28D marks more than 1 messages.
:20: is specific to ‘current’ message.
:21R: should be common across all messages(1 to 5) that is initiated for a single order
Not sure how much correct is understanding though.
Hi,
Not always. The ordering customer may not be the sender of the message. A sender (different from Ordering customer) can send the MT101 on its behalf.
In a case were the sender and ordering customer is same, will the two values be same – 20 and 21 R?
Hi Jean,
Nice article. I have a doubt regarding the point mentioned in the article “BNP Paribas forwards the MT101 instruction since it does hold the account to be debited.” BNP paribas is actually not holding the account which needs to be debited right? According to the example, Dresdner Bank in Germany is holding the debtor account right?