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.
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.
Explanation Format Comments Sender PNBPUS3N 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 OCBCSGSG 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:b03c6901-bbed-4aa9-afdh-a5bc26d19257 This reference is provided in the user block (Block 3) and transported ened-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:PNBPREF/378378 It is mandatory and of format 16x. Note that / belongs to the allowed charaters. Bank operation code :23B:CRED It is mandatory and of format 4!c. Value date/currency/interbank settled amount :32A:180816USD2325, It is mandatory and of format
6!n3!a15d (Date)(Currency)(Amount) Currency/Instructed amount :33B:USD2350, Normally optional in the standard. It is provided here because the sender has taken fees. See field 71F below.
Format 3!a15d (Currency)(Amount) Ordering customer :50F:/01234567890
1/COMPANY NAME SAS
2/RUE DENIS PAPIN, 28
3/FR/CRETEIL 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 :52D:BANQUE DELUBAC ET CIE
16 PL SALEON TERRAS
07160 LE CHEYLARD Ordering institution is optional and can be provided in two options A (usual) and D (less common). Option D, is chosen here:
[/1!a][/34x] (Party Identifier)
4*35x (Name and Address) Beneficiary customer :59F:/840735-592
1/RTP Company
2/3 Tuas South Street 3
3/SG/Singapore 638045 Beneficiary customer information is mandatory and can be provided in three different formats: No letter option, Option A and Option F. Option F is chosen in this case with format:
[/34x] (Account)
4*(1!n/33x) (Number/Name and Address) Remittance information :70:SUMMER 2018 DELIVERY
/INV/6535682524 Remittance information is optional and provided in format 4*35x if available. Up to 4 lines of up to 35 X characters each. 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:USD25, Charges USD25 deducted by the Sender (PNBPUS3N) from the initial settlement amount. Sender to receiver information :72:/INS/BNPAFRPP This is an optional field. It takes the format 6*35x.
INS is a code indicating that BNPAFRPP is the Instructing institution. End of message text/trailer
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.
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.
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.
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!
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.
Hello Jean Paul, Thank you for detailed explanation. really helpful.
I would like to ask about 71A : BEN so like what I understand is
if in message 71A :OUR is present then sender populates 71G tag
if 71A :SHA is present then 71F tag is populated
what about 71A: BEN ? for BEN how the charges is calculated and in which tag we provide the BEN charges details?
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. 🙂
Thank you for your appreciation. I am happy everything is clear now. 🙂
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 ?
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.
Hi Jean,
As always Thank you much for precisely explaining this topic.
However I have question just curious can Serial Payment transfer happen through 3 Financial institution?
Absolutely. Please read the articles about MT103 serial payment.
Can you please also explain a scenario when 56A is also involved in MT103 serial message ?
Hi Ankita, please read the article about Serial and Cover payments.
Hi Jean
Could an account number be quoted in field 57 of the mt191?
Hi Jean Paul, I have had a problem with receiving funds sent though on MT103 transmissions. The receiving bank (Australia) has returned the funds 5 times, each time with a notation that the Beneficiary Swift code needs to appear on 57A. The process has been, sending USD to an AUD account Sending bank (Malaysia USD account) – to sending bank’s USD Intermediary Bank – to receiving bank USD swift number – to receiving bank Intermediary Swift – to Beneficiary Swift. The Beneficiary swift has appeared in line F72 and Line 52A in the portions of the transmissions that I can see. The beneficiary bank keeps returning the funds with a notation that the Beneficiary bank swift needs to appear in line 57A. This has been going on for 6 weeks, and the funds have been sent and returned on 5 separate occasions, and I still don’t have the funds. I can’t understand why there would be errors over and over again? Neither the sending bank or the receiving gives me full information and it has been very worrying and stressful. The beneficiary bank keeps sending me undated messages saying that funds destined for my bank account have been returned due to an incorrect Swift code. They obviously know where they are destined. The beneficiary bank has been taken over by another bank and the swift code had changed with the takeover….