In a previous article, serial and cover methods were presented. Then we analyzed a concrete example of payment settled with cover method in the following articles:
- SWIFT MT103 202 Cover payment analysis – part 1
- SWIFT MT103 202 Cover payment analysis – part 2
- SWIFT MT103 202 Cover payment analysis – part 3
- SWIFT MT910 Confirmation of Credit – Detailed analysis
Now we want to see how the same payment can be settled using the serial method. In the coming series of three articles, we will consider the MT103 serial messages exchanged between the parties and their meaning. On the following figure, you can see the different parties involved and their roles in the first MT103. The second and third MT103 serial will be analyzed in the next articles.
As expected in the serial method, one message is initiated by the sender to settle the funds. That message moves from one party to the next in the payment chain until it reaches the beneficiary bank.
The table below contains the fields that are transported in this first MT103 serial message. 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 BNPAFRPP 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 PNBPUS3N 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:090828USD367574,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 because country code of Sender is FR and country code of receiver is ES. See Rule C2.
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) Intermediary Institution :56A:IRVTUS3N This is the Correspondent of Creditor Bank (Santander). It holds the account in USD of Santander. Account With Institution :57A:BSCHESMM Santander, the Bank holding the beneficiary account. 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. 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 message
As usual, there is more to this SWIFT MT103 serial 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 MT103 serial message)
The Sender (BNPAFRPP) is instructing the Receiver (PNBPUS3N) to debit its account and credit the intermediary institution (IRVTUS3N) account.
Narrative and note 2 (Fields 53a and 54a are not in the SWIFT MT103 serial message)
Fields 53A and 54A (Sender’s and receiver’s correspondents) are not present. This means payment does not go through correspondents. So BNPAFRPP has an account with PNBPUS3N. The intermediary institution IRVTUS3N (56A) is the next party in the chain. It will receive the funds from PNBPUS3N, the receiver of this message. BSCHESMM (57A) will receive the funds from the intermediary institution IRVTUS3N (56A), for credit to the beneficiary’s account. IRVTUS3N is US correspondent of BSCHESMM.
Narrative and note 3 (Ordering and account with institution in the SWIFT MT103 serial message)
There is no ordering institution (52A) in the message. That means the ordering customer is customer of the Sender, BNPP.
An account with institution (57A) is present in the message, i.e. the Beneficiary customer account (:59:/ES6300491800132710387658) is not held by the receiver (PNBPUS3N) of this message, but by the account with institution.
Narrative and note 4 (Details of charges in the SWIFT MT103 serial message)
Details of charges (71A) is SHA. The charges are shared between Ordering and Beneficiary customer. The Debtor pays charges to ordering bank. The Beneficiary pays charges to receiving and other intermediary banks. Note that the Ordering bank may have taken charges, but they do not appear in the MT103 Message.
This ends our analysis of the first MT103 serial message. In the next article, we will consider the second MT103 message exchanged between Wells Fargo and Bank of New York Mellon.
Hello Sir,
Could you tell me the difference between a correspondent bank and an intermediary bank in the above context?
Hi Jules, Strictly speaking, there is no difference. The intermediary institution (F56) must have an account relationship with the beneficiary bank. Otherwise the money could not flow through F56. However, in serial payments, the correspondent of the beneficiary bank would be provided in F56, while in the announcement (cover payments), it would be provided in the F54. Let me know if you have further questions.
Hi Jean,
Based on my understanding in the above example the sender ‘BNP’ will initially generate MT103 and they doesn’t possess any direct relationship with the Receiving bank ‘Santander’.
So my question is, how the sender knows the information about F56 which is actually a correspondent to receiver?
Does the sender bank already knows as in who will be the beneficiary correspondent in serial transfer because there might be more than one beneficiary correspondent for different regions.
Please guide.
That’s through published SSIs.
Each participating member back clarifies how it can be reached (via which back) for a particular currency
Thanks Pooja. The answer lies with the SSI.
Hi Gaurav, I can finally get back to you. The answer to your question lies in something called Standing Settlement Instruction (SSI). SSI of Bank A contains information about the correspondents of Bank A in the different currencies as well as the account in those currencies.
SWIFT propagates the information to counterparties over their network. The counterparties receive and store the information in payments engines. They use it to find out correspondents and route the payments. I hope this helps.
Hi Jean,
Can you please send me the most probable scenario of a mt103 in usd from sender xxx bank uk to receiver yyy bank colombia with ZZZ receivers Intermediary Bank usa>
Hi Jean,
Could you please clarify the below –
As per your note 2-
”Fields 53A and 54A (Sender’s and receiver’s correspondents) are not present. This means payment does not go through correspondents. So BNPAFRPP has an account with PNBPUS3N”.
I have gone through your article on cover payments, where we use both tag 53 and 54 in MT 103 Announcement. I understand there also when we initiate the first 202COV, the sender has an account with the receiver (i.e tag 53 in MT 103 Announcement) and the sender’s account is debited and receiver’s account is credited. therefore, the above statements sounds a little confusing and moreover here you have mentioned that this payment does not go through correspondents. When BNPAFRPP has an account with PNBPUS3N, isn’t is through corresponding banking?
Hi Stuti,
When I talk about correspondents, I refer to the fields 53 and 54 of the SWIFT message. When BNPAFRPP has an account with PNBPUS3N, the account relationship is through corresponding banking of course.
But in the SWIFT message, PNBPUS3N is the receiver and it can immediately debit the account of BNP PARIBAS and forwards it to the next party. No need to wait for the money to come through a correspondent.
And that is why F53 and F54 are not present. I hope this clarifies. Please let me know if things are not clear.
I’m interested in how the messages look like in case of rejecting/returning a MT103 with cover method. I’ve tried to find examples but to no avail. Can you bring light into the darkness?
Hi Jens,
thanks for reaching out.
The rules for rejecting/returning a MT103 announcement are the same as for rejecting/returning a serial MT103. So the related reject/return information must be provided in the field 72. As we can read in the SWIFT standards: “If the first six characters in line 1 contain the character string /REJT/ or /RETN/, then it is mandatory to follow the Payments Reject/Return Guidelines described in the Standards MT Usage Guidelines.”
There is nothing in the SWIFT MT103 telling you that it is a serial or announcement. You determine that as result of your processing. If you return a MT103 announcement (so the funds were received already), you have to return the cover too. Let me know if you have further questions.
Regards, Jean Paul
Dear Jean,
Here is a case scenario for your guidance.
A is wanting to remit $50000 to B and agrees to provide a valid MT103. However, he says that MT103 shall cease to show up once the payment is credited( Trace back of MT103 is not possible )
1. Is such type of credit possible ?
2.Is it a legitimate transaction or a fraudlent transaction?
3. If it is all legitimate then what can be the consequences on part of Sender or Receiver.
My only concern is that it should not be illegal .
Thanks
Dear Jean,
I noticed there is a sight difference between Serial MT103 and MT103 announcement, are there any differences between Serial MT202 and MT202 COV ?
I am talking about the difference in specification🙂
Dear Peter, There are many differences between MT202 and MT202COV. Check The SWIFT specifications.
I generate the MT103 message automaticaly from my application. Is it me who will add the headers to a file or the SWIFT software.
Thank you in advance
Hi Naim,
Not sure what you mean with SWIFT Software. Is it an app like SAA or SAG ? If yes, you should add the headers. Those applications do not add the headers. They expect messages with headers and contents. Good luck!
Best regards,
Jean Paul
When the company send payment instruction (MT103) to bank for processing and we receive some response from bank as a confirmation, what do we call this response from bank? does this flows from any MT format?
Hi Pavan,
The MT103 is an interbank message. Only one bank can exchange it with another bank. Companies send MT101 messages to Banks.
Banks send Payment Status Reports(There is no MT equivalent for this), Confirmation of debit (MT900) and Confirmation of credit to companies.
Regards, Jean Paul
Hello Jean,
Could you please throw some light on the usage of field 72 in MT103 ? What is the processing done at beneficiary bank’s end when an MT103 is received with field 72 ?
Thanks much.
The field 72 specifies additional information for the Receiver or other party specified. It can be structured in specific ways. Please check the SWIFT specifications. When provided, it must be transported end-to-end and made available to the receiver of the payment.
Could you please explain the usage of the code words ACC, REC, INT, INS in tag 72 ?
Also, presence of these code words in F72 should always break the STP ?
Hello Jean Paul,
Really nice website and initiative.
Good luck.
Thanks.
BR,
J.Y
So this means in case of cover message fields 53 and 54 will be present while in case of serial payments field 56 will be present. In other words cover will not contain field 56 and serial will not contain field 53 and 54 always?
Rahul, 🙂
You got it right! In case of cover message fields 53 and 54 will be present while in case of serial payments field 56 will be present.
I am getting my job done!
Best rgeards
Hi Jean & all
I’ve read through and found this a very helpful site thanks guys!
I have a question though. When is field 55a used? I have seen this field beung used in mt103 with cover, however i can see fields 53, 54 abd 55a. Does this mean the payment is debiting field 55a assuming the cover is there?
Hi Jean,
Request your suggestions regarding population of institutions in MT103 Return and MT202 Return. My query is as follows:
Let me try to illustrate:
If I get an inbound MT202 as below:
{1:F01BOFAID2XXXXX0000000000}{2:O2021200190527BOFAUS3NXXXX22221234561905271201N}{3:{108:204261475}}{4:
:20:TestMsg213
:21:TestMsg221
:32A:190527IDR12340,00
:58A:BOFAID2XXXX
-}
To return the above message, what should be the value in tag 58? Should it be BOFAID2XXXX or should it be BOFAUS3NXXX?
Similarly in case of MT103, if I get an inbound MT103 with Tag 52 (Ordering Institution), Will the return message contain the same Tag 52 or should return be treated as a fresh MT103 with no Tag 52 and just the applicable correspondent parties?
To elaborate more on the MT103 example, suppose there are 4 institutions – A, B, C, D. When A sends MT103 intended for D via B and C, The Original MT103 from A will have the following parties:
Sender – A
Receiver – B
Intermediary (Tag 56) – C
AWI (Tag 57) – D.
MT103 from B to C will read as below:
Sender – B
Receiver – C
Ordering Institution (Tag 52) – A
AWI (Tag 57) – D
MT103 from C to D will read as below:
Sender – C
Receiver – D
Ordering Institution (Tag 52) – A
Tag 72 – /INS/B
So when D returns the MT103, should the MT103 read as below?
Sender – D
Receiver – C
Intermediary (Tag 56) – B (If information is available in Tag 72)
AWI (Tag 57) – A
Tag 72 – /RETN/XXXX
or should it read like:
Sender – D
Receiver – C
Ordering Institution (Tag 52) – A
AWI (Tag 57) – D
Tag 72 – /RETN/XXXX
Hence to clarify the above doubts, I have requested examples of the both original and corresponding return messages.
Thanks and Regards,
Jagadish Vema
Hi Jagadish,
You gave me quite a lot of homework. :-). I will just give you the principles for rejects and returns: New references (MT20) are generated, but the content of the original message (MT103 or MT202) remains the same. In addition, you add the TAG 72 which contains the reason why the message was rejected/returned. In the headers, sender and receiver are interchanged. Otherwise the message cannot be routed. When the receiver, the original sender gets the message, he knows thanks to the field 72 that it is a reject/return and can process it accordingly. I hope this helps.
Hello Jean,
nice webpage and good interaction you have here. I have a specific scenario in mind; I would appreciate if you can confirm.
A German based bank is instructed by his corporate client to transfer 1 mio USD to a Japanese Bank. No RMA exist, therefore the German Bank send through his intermediary Institution Field 56 an USD Instruction, but where doe it go after the intermediary Institution is receiving the instruction? Directly to the Japanese bank, who send it back to their USD Correspondent bank for crediting their USD Nostro account?
kind regards
Christian
Hi Christian, Thank you for your comment! That is a serial payment. The German bank will send the USD payment to its correspondent (the intermediary institution) which will forward it to the correspondent of the Japanese bank in the USA (Another intermediary institution). After crediting the Japanese bank account, the correspondent of the Japanese bank will inform the Japanese bank. And that is it. For more information, you can read my article about serial and cover payments. I hope this helps. 🙂
Hi Jean,
In you example charges are set as SHA. and as it is mentioned Ordering Banks charges are paid by the Sender and all other charges are paid by the beneficiary.
I have the following question, Is OUR permitted in a chain payment and if yes how intermediaries will collect their charges?
Hi Jean,
Is it true that only grade A+++ banks have the capacity to send Swift MT103?
Or any bank can send these instruments.
No that is not correct. A bank does not need to be rated grad A+++ to send SWIFT MT103 messages.
Dear Jean,
Thanks again for your interesting insights, had a query on how the following scenario can be sent addressed via the serial payment method:
Corp ABC based in Germany wants to sent USD payment to Vendor in Australia who holds his account with Bank of China Brisabane Branch(BKCHAU2SBRI). The payment needs to routed though Bank of China Head Office in Australia (BKCHAU2AXXX).
ABC Holds account with COMMERZBANK AG FRANKFURT (COBADEFFXXX) and its correspondent bank in US is JP Morgan Chase (CHASUS33XXX).
Bank of China Head Office in Australia (BKCHAU2AXXX) holds its USD Nosto with Wellfargo WFBIUS6SXXX.
So the payment chain has to be built like this
COBADEFFXXX->CHASUS33XXX->WFBIUS6SXXX->BKCHAU2AXXX->BKCHAU2SBRI
In this case for the first MT103 -Serial payment COBADEFFXXX is sender and CHASUS33XXX is receiver and BKCHAU2SBRI is the account with Institution.
How can we include both WFBIUS6SXXX and BKCHAU2AXXX as we have only 56 Intermediary Institution in the message?
Thanks in advance.
Hi Jean,
Please explain the scenarios when do we use TAG:56..is it when indirect participant is sending the message?
Hi Jean
How many times can the field 23E repeat in an MT103 message? Please clarify.
Hi Sree, the standard does not specifiy any limit. So you can repeat it as many times as needed. In practice, two times are generally enough.
Thank you Jean.
Hello Jean
Is it any difference btw Mt103 manual downloads and mt103 regular?
Hi,
Can an MT103 be generated before funds are sent? I.e if someone was being fraudulent they could get the MT103 produced then retract the payment. This way the receiver trying to verify the MT103 will be told by the bank that it is a legitimate Mt103 but they won’t be able to trace it?
Is that possible?
Thanks,
Dave
The MT103 is an instruction that must be executed for the money to move. An MT103 can be generated and finally not executed. However, if the receiving bank gets the MT103, it means the instruction was carried out. About the tracing the message. It was very difficult to do that before SWIFT GPI. With the UETR, SWIFT messages should be easily tracked. I hope this helps.
Hi Jean,
Thank you for the helpful illustration and explanations.
Can I ask what are the pros/characteristics of sending an MT103 serial payment as opposed to an MT202COV?
Why would a sender bank prefer the MT103 serial payment over MT202COV if it is more time consuming?
Hi Jean, you did a great Job… can I ask you some questions regarding tag 56?
I saw that it has 3 options: A, C, D and for them the format is like [/1!a][/34x], what can contain? Could you show me some cases? Is usually used or it’s used just the bic?
thanks and regards
can you please clarify difference between 51a ( sender institution – BIC) and 52a ( Ordering institution-BIC)
Also i believe a 58a is mandatory only if it is a 202/202 cov . is my understanding correct ?
Thanks in anticipation
Hi Jean, Can you please clarify if both Local clearing code and SWIFT code can be used in 57A as below.
:57A://FW111222333
CITIUS33XXX
Hi Jean , so in a serial payment instruction F56 need to be there definitely but from the process flow diagram, can we say that F53 also gets populated ( after all it is the correspondent bank of the sender) ?
Looking forward to your response
Thanks !!
Dobrý den. Moj obchodý partner dostál od nás investície a jeho banka mu je nepripisala.
aj po zaslani swiftovej zprávy s kodom MT103.
Obchodný parnet tvrdí ze banka mu je nepripísala a nam sa peniaze nevratily.
Ako možeme postuppovet aby banka pripisala klientoví peniaze -investicie na nakup pozemkou.
Dakujem
Hi Jean
Can Bank A send MT 103 announcement to Bank B if they don’t have direct relationship with each other just via swift network?
Bank A has a nostro account in Bank B, but wants to transfer funds to Bank C who have no accounting and RMA with Bank A, but with Bank B.
Can we use serial MT103 message to transfer funds?
As only 3 banks are involved, in the serial MT103 message that Bank A sends to Bank B, field 56 is not needed, but field 57 is mandatory to be Bank C as below, right?
Sender – Bank A
Receiver – Bank B
Field 57 – Bank C
When is field 55a used? I have seen this field being used in MT 103 with cover. Under what circumstance is this required? Does this mean the payment is debiting field 55a assuming the cover is there?