MT103 Serial Payment between Debtor Bank and its correspondent

SWIFT MT103 serial payment analysis 1/3

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:

  1. SWIFT MT103 202 Cover payment analysis – part 1
  2. SWIFT MT103 202 Cover payment analysis – part 2
  3. SWIFT MT103 202 Cover payment analysis – part 3
  4. 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.

MT103 Serial Payment between Debtor Bank and its correspondent
MT103 Serial Payment Message 1 between Debtor Bank and its correspondent

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.

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.

48 thoughts on “SWIFT MT103 serial payment analysis 1/3”

  1. Hello Sir,

    Could you tell me the difference between a correspondent bank and an intermediary bank in the above context?

    1. 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.

    2. 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.

      1. That’s through published SSIs.
        Each participating member back clarifies how it can be reached (via which back) for a particular currency

      2. 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.

  2. 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?

    1. 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.

  3. 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?

    1. 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

  4. 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

  5. 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 ?

  6. 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

    1. 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

  7. 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?

    1. 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

  8. 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.

    1. 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.

  9. 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?

    1. 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

  10. Mohammed Mouzouri

    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?

  11. 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

    1. 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.

  12. 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

    1. 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. 🙂

  13. 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?

  14. 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.

  15. Hi Jean,

    Please explain the scenarios when do we use TAG:56..is it when indirect participant is sending the message?

    1. 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.

  16. 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

    1. 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.

  17. 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?

  18. 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

  19. 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

  20. Hi Jean, Can you please clarify if both Local clearing code and SWIFT code can be used in 57A as below.

    :57A://FW111222333
    CITIUS33XXX

  21. 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 !!

  22. 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

  23. Are you seeking financial solution to start up, continue your projects, contracts and give it a firm and excellent end, come to Us to sort and settle that your financial struggle of years that has lay hold on your growth in life, I guarantee our clients 100% efficacy of delivery to build an everlasting trust in business and retain all our clients till the end of the world, I have a genuine and trusted provider that can deliver to an intending clients BG/SBLC MT103/202 GPI CASH TRANSFER/ MT103 MANUAL DOWNLOAD/MT103/202 SINGLE CASH TRANSFER and Our delivery is prompt and Satisfying.
    Emil: alexw8267@gmail.com
    WhatsApp ‪+1 (213) 260‑2409‬

Leave a Comment

Your email address will not be published. Required fields are marked *