This is the third and last article about a SWIFT MT103 serial payment (so settled via the serial method). We already studied the cover method and how it is used to settle that payment. Read the series of articles to which I refer you in this article if you want to learn more about the cover method.
When the transaction is settled with the serial method, the payment moves from one party to the next in the payment chain until it reaches the beneficiary bank. We examined the content of the first MT103 message in details in this article. The second MT103 message was considered in the previous article. Now we will look at the third SWIFT MT103 serial payment exchanged between Bank of New York Mellon and Santander and its meaning. The following picture depicts the different parties involved and their roles in the third MT103.
The table below contains the fields that are transported in the third SWIFT MT103 serial payment. 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 IRVTUS3N The Sender BIC appears in header block (Block 1) in the MT103 Input and in the application block (Block 2) in the MT103 Output. Message Type 103 The message type is the second field of the block 2. Receiver BSCHESMM The Receiver BIC appears in header block (Block 1) in the MT103 Output and in the application block (Block 2) in the MT103 Input. Unique End-to-end Transaction Reference 121:c95a7574-863a-494d-bfad-4084bf7704d4 This reference is provided in the user block (Block 3) and transported end-to-end. Message text This introduces the Text block (block 4). All the fields below are in the text block of the MT103 message. Sender's Reference :20:103REF378245 It is mandatory and of format 16x. See all the allowed charaters on this page. Bank Operation Code :23B:CRED It is mandatory and of format 4!c. Instruction Code :23E:PHOB/+34.91.397.6789 It is optional and of format :
4!c[/30x] (Instruction Code)(Additional Information)
Code PHOB means Phone Beneficiary. The sender requests the beneficiary bank to advise/contact beneficiary/claimant by phone when the funds will be received. Value Date, Currency, Interbank Settled Amount :32A:090829USD367532,90 It is mandatory and of format:
6!n3!a15d (Date)(Currency)(Amount) Currency, Instructed Amount :33B:USD367574,90 Normally optional in the standard. It must be provided here because Sender has taken charges from original settlement amount. See field 71F below.
Format 3!a15d (Currency)(Amount) Ordering Customer :50F:/01234567890
1/Company France SAS
2/28 RUE DENIS PAPIN
3/FR/CRETEIL 94400 Ordering customer information is mandatory and can be provided in three different formats according to the options A, F and K. Option F is chosen in this case with format:
35x (Party Identifier)
4*(1!n/33x) (Number/Name and Address) Ordering Institution :52A:BNPAFRPP Ordering institution is provided, so the receiver knows it is the initial originator of the instruction. Beneficiary Customer :59:/ES6300491800132710387658
Company Spain S.A.
Santa Hortensia 26-28
28002 MADRID
SPAIN 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 takes 3 values: BEN, OUR and SHA. SHA means charges are shared between Ordering and beneficiary customers. Sender's Charges :71F:USD20, Former sender (PNBPUS3N) has debited 20 USD from the amount he received. These charges are borne ultimately by the beneficiary customer. Sender's Charges :71F:USD22, The sender (IRVTUS3N) has debited 22 USD from the amount he received. These charges are borne ultimately by the beneficiary customer. Sender to receiver information :72:/INS/PNBPUS3N This is an optional field. It takes the format 6*35x.
INS is a code indicating that PNBPUS3N is the Instructing institution. This field indicates to Santander came through IRVTUS3N and not directly from BNPAFRPP. 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, 4!c and the format of the field options mean.
Narratives and notes on this SWIFT MT103 serial payment
As usual, we should always consider each SWIFT MT103 serial payment carefully. They seem to be the same. But there are differences. The following narrative and notes allow to get a deeper understanding of the message content.
Narrative and note 1 (Main purpose of this SWIFT MT103 serial payment)
The Sender (IRVTUS3N) is informing the Receiver (BSCHESMM) that his account has been credited and funds are for the beneficiary customer. So the receiver should credit the beneficiary account with the funds received. Do you note the difference between this message and the previous ones? In the previous one, the sender was asking the beneficiary to debit his account and credit someone else’s account. So we see that an incoming MT103 has a different meaning for a bank when it is received from its correspondent.
Narrative and note 2 (Fields 53a, 54a are not in the SWIFT MT103 serial payment)
Fields 53A and 54A (Sender’s and receiver’s correspondents) are not present. So we are not going through any correspondent. This means IRVTUS3N has an account relationship with BSCHESMM. Serial messages do not contain F53 and F54.
Narrative and note 3 (Ordering and account with institution in this SWIFT MT103 serial payment)
The ordering institution (52A) is provided in this message. That means the ordering customer is not customer of the Sender, IRVTUS3N . The sender kept the field 52a in the message (It was added by PNBPUS3N), so that the receiver is aware of this.
Now the message reached BSCHESMM, which was the account with institution in previous messages. The Beneficiary customer account (:59:/ES6300491800132710387658) is now held by the receiver (BSCHESMM). So no need to provide a field 57a anymore since the beneficiary customer is customer of the receiver (BSCHESMM).
Narrative and note 4 (Details of charges in this SWIFT MT103 serial payment)
Details of charges (71A) is SHA. The charges are shared between Ordering and beneficiary customer. Sender pays charges to ordering bank. Beneficiary pays to receiving and other intermediary banks.
Another field 71F was added to this message (:71F:USD22), so that it now contains two fields 71F (:71F:USD20 and :71F:USD22). The sender IRVTUS3N is indicating to the receiver and the next party (the beneficiary) that he charged USD 22 as fees for the transaction processing. Note that Interbank Settled Amount (USD367532,90) = Instructed Amount (:33B:USD367574,90) – first Sender’s Charges (USD20,) – second Sender’s Charges (USD22,). In this case, the sender must also provide the optional instructed amount field.
This ends our analysis of the third MT103 serial payment. Isn’t fascinating to see how much we say about these messages each time? The next articles will be about the SWIFT MT101, another key message in the SWIFT world. So stay tuned !!!
Went through your article on MT 103. Can you explain with examples starting from Sender right down to the last field, what fields are mandatory in the following cases :
1. e.g. ABC Bank wants to transfer USD through its correspondent in New York. The USD correspondent of the receiving bank is also in New York.
2. ABC bank wants to transfer USD through its correspondent in New York. However, the receiving bank has an Euro account in Paris.
Moreover, examples of plain MT 202 (not cover 202) will also be appreciated
There are 3 articles in total. Read all the three to get the complete view.
MT202 examples will be provided later. If you have subscribed to the newsletter, you will receive a notification when articles about MT202 will be published on the blog.
1. e.g. ABC Bank wants to transfer USD through its correspondent in New York. The USD correspondent of the receiving bank is also in New York.
Sender – ABC Bank, EX – BSCHESMM
Receiver – ABC Bank’s Correspondent Bank in New York , Ex – CITIUS33
TAG 57 – The USD correspondent of the receiving bank is also in New York., EX – IRVTUS3N
TAG 58 – Beneficiary Bank (Receiving Bank) , ex – HSBCAEAD (UAE) or HSBCUS33
es una pagina fantastica
it is fantastic block
Thank you Antonio. I am happy to see that the content is valuable.
This is really a fantastic block! I’ve learnt a lot on the MT103 in this blog. Thanks Jean!
Thank You Cindy for your appreciation!
Hi Jean,
Would you please help me understand the difference between 103 and 103 STP. Most of the sites state that 103 STP is a straight through processing message without human intervention and has some restricted fields, when compared to MT103. Could you please elaborate this a little more and make me understand more clearly.
Hi Sumita, Yes the MT 103 STP has some restrictions. When you compare the specifications of both MT103 and MT103 STP, you see for example that in the MT103 STP, only the option A is allowed for F52 (Ordering Institution), F54 (Receiver’s correspondent), F57 (Account with institution), etc. In the classic MT103, the same fields have up to three options. Some options do not allow to process the payment STP. In option A, the party identifier and the BIC are provided and this allow STP processing. I hope this clarifies. I have added the MT103 STP format specifications on the website. Let me know if you have further questions.
Thanks for you prompt response Jean, but would you further clarify why some options do not allow to process the payment STP, while option A is allowed.
Also, with STP, what possible stages can be skipped by the transaction.
Hi Sumita, option A is required for STP processing as it will have BIC Code which will eliminate manual intervention as its easier to identify a bank with BIC, other options doesnt have BIC code hence manual intervention would be required.
Hi.
I’m in a position where I’m receiving an mt103 blocked funds for my business. The buyer has worked well with me in the past and wants to send the funds to me. However I need to get them to the seller. Guess I’m the middle man.
Is there away like a back to back similar to am LC. So the seller knows the money will arrive subject to in this case proof of docs at port.
i have a question related to Tag 55 and Tag 56. in which scenarios we use these tags in MT103? Could you please give me few real life examples?
Great article Paul. Very clear and discreet explanation. Superbly sequenced.
I have a query in this last chain. Shouldn’t the last chain message be MT910 or MT950/940, as Bank of Newyork is merely informing Santandar that Santandar’s account with BoNY has been credited, instead of using MT103 which is typically used to instruct the other bank to debit your nostro and make payment.
Just my two cents.
this is a completely fake and fraud. it takes money then never deliver products. and never even refunded the amount.
Hi Jean, thanks for the sharing, really learn a lot from the blog.
In this example, the Sender (IRVTUS3N) is informing the Receiver (BSCHESMM) that his account has been credited and funds are for the beneficiary customer. So the receiver should credit the beneficiary account with the funds received.
And in Example https://www.paiementor.com/basic-swift-mt103-message-decrypted/, sender (CRESCHZZ80A) is asking receiver (BNPAFRPP) to debit sender’s account and credit beneficiary account.
When there’s a direct account relationship between sender and receiver, and sender has account with receiver, and sender holds account of receiver at the same time, how would receiver know whether it is a request to debit sender’s account and credit beneficiary, or it is a information that money has been credited to receiver’s account and credit beneficiary? Thanks.
Hello,
We offer Swift MT760 BG/SBLC, FC MTN, BCL, KTT, Bank Draft, Letter of Credit (LC) , MT103 Etc.
N/B : Provider’s Bank move first.
Let me know if you have any need for the above offers.
Thanks
Name:Patrick Altman
Email :patrickaltman999@gmail.com