SWIFT MT103 serial payment analysis 3/3

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.

SWIFT MT103 Serial Payment 3 between Receiver correspondent and Account with Institution
SWIFT MT103 Serial Payment 3 between Receiver correspondent and Account with Institution

 

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.

WP Data Tables

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

18 COMMENTS

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

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

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

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

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

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

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

LEAVE A REPLY

Please enter your comment!
Please enter your name here

MOST POPULAR