MT103 SWIFT message with optional fields 52a and 57a – Part 2

The MT103 SWIFT message with optional fields 52a (Ordering institution) and 57a (Account with institution) was introduced in the previous article. We saw that many intermediaries are involved in the processing of that message. But the message was still on the way and has not reached his final destination yet. In this article, we will see what happens next and and how the beneficiary gets the funds.

The picture below shows the main actors and highlights some of the fields transported in the message.

 

Image of MT103 SWIFT Message received by the account with institution

Second MT103 SWIFT Message received by the account with institution

 

The table below contains information that is highlighted in the examples provided in the SWIFT Message Reference Guide. An additional column (comments) provides further explanation on the fields to ease their understanding.

The following page provides further explanation on the Field formatting rules and Character sets used in SWIFT MT Messages. Read it to better understand the meaning of 16x, 4!c, 4*(1!n/33x), [/1!a][/34x] and so on.

Narratives and notes on this MT103 SWIFT Message

The following narrative and notes allow to get a deeper understanding of the message content. Read them carefully and if there is any question, post a comment.

Narrative and note 1 (Main purpose of this MT103 SWIFT message)

The Receiver (PNBPUS3N) of the previous MT103 SWIFT Message is now the sender. It forwards the message to the Account with Institution (OCBCSGSG) which is now the receiver. Sender (PNBPUS3N) is asking Receiver (OCBCSGSG) to credit beneficiary account (:59F:/840735-592) with the funds credited on OCBCSGSG’s account.

Narrative and note 2 (Account relationships)

  • The transaction currency is USD. So PNBPUS3N is saying to OCBCSGSG: “I have credited your USD account with me. The funds are for the customer (:59F:/840735-592) that you should credit.”
  • PNBPUS3N therefore provides correspondent account services to both BNPAFRPP and OCBCSGSG. BNPAFRPP and OCBCSGSG have nostro accounts in USD currency with PNBPUS3N.

Narrative and note 3 (Sender’s reference F20 and Unique End-to-end Transaction Reference)

A new sender’s reference is generated by the sender (PNBPUS3N). As the name indicates, it is a reference assigned by the Sender to unambiguously identify the message. But the End-to-end Transaction Reference has another purpose: it is used to identify the message end-to-end and once it is generated, next parties are not allowed to modify it. It is transported end to end.

Narrative and note 4 (Field 57 is not present in this SWIFT MT103 message)

The Beneficiary customer account (:59F:/840735-592) is serviced by the Account with institution (OCBCSGSG). It was field 57 in the first message, but it is now Receiver of this message. The field 57 does not need to appear anymore

Narrative and note 5 (Charges 71F and Instructed amount 33B in this SWIFT MT103 message)

The Sender of this message (PNBPUS3N) has deducted USD25 (Tag 71F) from the initial settlement amount (USD2350,). The field 33B is added to the message to convey that information. Interbank settled amount (USD2325,-) = Instructed amount – 25 USD.

Narrative and note 6 (Fields 70 and 72 in this SWIFT MT103 message)

The field 70 (remittance information) is forwarded unchanged.

The field  72 (:72:/INS/BNPAFRPP) was added to this message. It is there to inform the receiver (OCBCSGSG) about the party that instructed the sender (PNBPUS3N) to execute the transaction. Without field 72, OCBCSGSG would not know it since that information is not provided somewhere else in the message.

In addition, the Receiver (OCBCSGSG) knows that the instructor (:72:/INS/BNPAFRPP) is an intermediary since it is different from Ordering institution (BANQUE DELUBAC ET CIE).

 

Other articles have been written about SWIFT MT103 Message: the basic MT103 SWIFT message with mandatory fields and the MT103 SWIFT Message with optional fields 53B, 70 and 71G. Read them if necessary to get additional information and a better understanding of the MT103 SWIFT Message.

, , ,

8 Responses to MT103 SWIFT message with optional fields 52a and 57a – Part 2

  1. Oana November 8, 2018 at 11:20 am #

    Hello Jean Paul! First of all, I would like to thank you for the wonderful documentation that you provide regarding payments. You really saved me. I have searched through many resources, but I find yours very well written, clear, and to-the-point. You do a great work and help so many people.

    I would like to note possibly two typos in this article (if my understanding is correct):
    – In note 3: fields 121 should not be modified by next parties, right?
    – In the table, field “71A” should be “OUR” ?
    Actually, I did not understand very well how these charges are represented in the MT103 message. Shouldn’t there always (or most times) be both Sender and Receiver charges, irrespective of field “71A” (SHA/OUR/BEN)? How would the charges be represented in each of these cases and how is this represented when there are more than 2 banks in the process (like in this example)? Do you have another article on this topic?

    Thank you very much again for the documentation.

    • Jean Paul November 8, 2018 at 12:56 pm #

      Hi Oana,
      Yes you are right :-). The field 121 should not be modified by next parties since it is used to identify the message unambigously. I have updated it. Thanks for reading with attention.

      The field 71A is populated by the Bank that generates and sends the MT103. Next banks in the chain cannot change it.
      However, if they take charges, they must add the repetitive field 71F – Sender’s Charges to the message that is forwarded to the next party in the chain.
      The sender populates the field 71G – Receiver’s Charges usually when 71A is OUR and he knows how much it costs. If not, the receiving bank charges the sending bank (generally through MT191) since it is not allowed to deduct the charges from the received amount is this case.
      The equation is always the following: F32A = F33B + F71G – (F71F + F71F+ …). In case multiple banks take charges.
      I hope it clarifies a bit.
      I have not written an article specifically on that. I will try to write one in the future.

  2. Oana November 8, 2018 at 2:26 pm #

    Thank you very much, Jean Paul! It is very kind of you to help me with the understanding of these concepts. Very much appreciated. πŸ™‚ I think I understood now. Please allow to verify my understanding.

    F32A is the actual amount transferred between banks.

    Case 1: When 71A=SHA: F32A is the same as the amount specified by the ordering customer. The beneficiary receives this amount (unless he has to pay charges to his bank?)

    Case 2: When 71A=OUR: F32A is the same as the amount specified by the ordering customer, but the beneficiary receives less (F32A – F71G)

    Case 3: When 71A=SHA and 71F exists: F32A is not the same as the amount specified by the ordering customer, but (initial amount (F33B) – 71F).
    So, if I understand correctly, in this example, the ordering customers “pays” $25 just because his bank doesn’t have a direct relationship with the bank of the beneficiary, but goes through a correspondent?

    These are only the cases in the examples you provided… but I understand that all scenarios respect the equation you mentioned.
    However, what I find strange is that there is no specific field which says how much money the beneficiary receives. In Case 2, it is the amount in F33B, in case 3 it is the amount in F32A (minus possible charges on the beneficiary bank’s side, as 71A=SHA). What is the rule based on which the beneficiary bank knows how much to credit the beneficiary’s account?

    Thank you very much for your support and the wonderful documentation that you write!

    • Jean Paul November 8, 2018 at 3:14 pm #

      Yes you got it. Cases 1, 2 and 3 are correct. The equation works for all scenarios. πŸ™‚ I use it often.
      The SWIFT standard has not foreseen a specific field where you find the exact amount that the beneficiary receives.
      In X-Border payments, you have many intermediaries and each of them may take charges for the service provided.
      It is therefore difficult for the bank that is sending a payment to say exactly how much the beneficiairy will receive.

      To your question – So, if I understand correctly, in this example, the ordering customers β€œpays” $25 just because his bank doesn’t have a direct relationship with the bank of the beneficiary, but goes through a correspondent?
      PNBPUS3N takes 25USD for the service provided. Ultimately, it is the beneficiary who pays it since that amount is deducted from the settlement amount that PNBPUS3N initially received. 71A=SHA means charges are shared between Ordering and beneficiary customers. The ordering customer pays charges to his bank and the beneficiary pays the charges to all the intermediary banks and the beneficiay bank. I now saw and fixed the issue with OUR in the comments. It is now SHA in the comments column too. Thanks.

  3. Oana November 8, 2018 at 3:47 pm #

    Dear Jean Paul, thank you so much. You explain so well. Everything is clear for me. And, congratulations for this site! I am sure it helps many people. πŸ™‚

    • Jean Paul November 8, 2018 at 6:12 pm #

      Thank you for your appreciation. I am happy everything is clear now. πŸ™‚

  4. San February 11, 2019 at 10:32 am #

    Dear Jean Paul,

    Thanks a lot for your detailed explanation.
    In the above example, I assume that for Wells Fargo it is a third party payment. So how the reconciliation will happen for the incoming MT message (Message generated by BNP) and outgoing MT message(Message generated by Wells Fargo) at Wells Fargo side ?

    • Jean Paul February 11, 2019 at 1:57 pm #

      Dear San,
      Thank you for your careful reading and your question! You are correct. For Wells Fargo it is a third party payment. The funds move through Wells Fargo because it is the correspondent of the account with institution, the beneficiary bank. For the reconciliation, Wells Fargo can use the Unique End-to-end Transaction Reference that is transported end-to-end. You are right that we have two payments here from Wells Fargo Perspective: an incoming payment from BNP and an outgoing payment to OCBCSGSG. In the payment engine, it is usually pretty easy to follow that. You can see the received incoming payment, how the outgoing payment is generated and sent to the receiver and the related accounting. And that eases the manual reconciliation for end users. References are excellent for automated reconciliations.

Leave a Reply