| Field | Meaning | Required |
|---|---|---|
:20: | A unique reference assigned by the sending bank to identify this payment through its whole life. It must not repeat for the same sender within the same business | M |
:23B: | A four character code that tells the receiving bank how to handle the transfer. CRED means a normal credit transfer, SPAY means a SWIFT payment, SSTD means a st | M |
:32A: | The value date on which funds become available to the beneficiary, the three letter ISO currency code and the amount to be paid. For USD 25,000 on 5 November 20 | M |
:33B: | The currency and amount in which the ordering customer instructed the payment, when that differs from the settlement currency in field 32A. It preserves the ori | O |
:50a: | The customer who ordered the payment, identified by account number and name and address. Option K gives account, name and address in free text. Option F gives s | M |
:52a: | The financial institution that ordered the transfer when it is not the sender of the message. It is normally the bank holding the ordering customer account in a | O |
:53a: | The account held by the sender with the receiver, or the correspondent bank through which settlement will occur. It tells the receiving bank where to debit the | O |
:54a: | The account held by the receiver with another bank, used when the receiver does not hold the sender account directly. It identifies the next bank in the settlem | O |
:57a: | The bank where the beneficiary holds an account, when it is not the receiver of the MT103. It directs the receiving bank to forward the payment to the correct a | O |
:59a: | The final recipient of the funds, identified by account number and name and address. Option A gives the account and BIC, option F gives structured name and addr | M |
:70: | Free text information for the beneficiary explaining what the payment is for, such as an invoice number, contract reference or salary month. It is limited to fo | O |
:71A: | A three letter code stating who pays the transfer charges. OUR means the ordering customer pays all charges, BEN means the beneficiary pays all charges, and SHA | M |
Meridian Bank London sends an MT103, reference MER1035521, for USD 25,000 value 5 November 2024 to Harbour Bank Singapore to pay Bright Logistics for invoice INV-1187. This is a pre-migration example, from before coexistence ended on 22 November 2025. Field :71A: is SHA, the beneficiary account is given in :59a:, and the payment settles on the value date.
Valid example from the message catalogue. Scheme rules: MT103 is a SWIFT MT (FIN) message, not a base ISO 20022 message: there is no single global scheme rulebook, and each bank and market practice sets its own format limits and cut-off times on top of the
Worked Example: the full USD 367,574.90 payment from BNP Paribas Paris (BNPAFRPP) to Banco Santander Madrid (BSCHESMM) via Wells Fargo (PNBPUS3N, USD 20 charge) and Bank of New York Mellon (IRVTUS3N, USD 22 charge), reference 103REF405775, charges SHA, beneficiary account ES6300491800132710387658, final settled USD 367,532.90, with every optional field explained as it appears and disappears across the three MT103s
What you will learn
Your objective. By the end of this lesson, you will be able to explain worked example: the full USD 367,574.90 payment from bnp paribas paris (bnpafrpp) to banco santander madrid (bschesmm) via wells fargo (pnbpus3n, USD 20 charge) and bank of new york mellon (irvtus3n, USD 22 charge), reference 103ref405775, charges sha, beneficiary account es6300491800132710387658, final settled USD 367,532.90, with every optional field explained as it appears and disappears across the three mt103s. This worked example is set before the CBPR+ migration, so the payment travels as MT103s.
Why it matters. This matters because the message is the payment instruction. A wrong field, a missing element or a misunderstood format is a failed payment, a return, or a compliance breach.
Chapter objective: Learner explains the optional MT103 fields 52a, 57a, 53B, 70 and 71G, and shows how each one changes routing, charges and remittance information. Learner uses real examples with amounts, banks and message names to show how the topic works in practice.
Key learning points
- Worked example
- Field 70
- Field 57A reads BSCHESMM
- Field 57A still reads BSCHESMM
- Field 57a
- Lesson of the chain
Key terms
Value date: The date on which funds become available to the beneficiary and on which interest starts to accrue. It is the date used for settlement and for nostro posting.
Nostro: An account that a bank holds with another bank, usually in a foreign currency, to settle payments in that currency.
MT103: A SWIFT message that carries a single customer credit transfer instruction from one bank to another. It names the ordering customer, the beneficiary, the amount, the currency and the value date.
SWIFT MT message viewer showing Worked Example: the full USD 367,574.90 payment from BNP Paribas Paris (BNPAFRPP) to Banco Santander Madrid (BSCHESMM) via Wells Fargo (PNBPUS3N, USD 20 charge) and Bank of New York Mellon (IRVTUS3N, USD 22 charge), reference 103REF405775, charges SHA, beneficiary account ES6300491800132710387658, final settled USD 367,532.90, with every optional field explained as it appears and disappears across the three MT103s.
Practise this lesson
Exercise
Read the MT103 messages message described in this lesson and identify its key parts.
Use the message structure, fields and example in this lesson.
- What to do. List the main blocks of the message, name the field that carries the amount, and name the field that identifies the payment.
Correct result. The message is made of blocks, each carrying a part of the payment instruction. The amount field and the identification field are the two a receiving bank checks first, because without them it cannot process or reconcile the payment.
Why. A message is only useful if you can read it. The blocks tell the receiving bank what to do, and the amount and identification fields are what it checks first.
Check your understanding
Practice question
Which of the following best describes worked example: the full USD 367,574.90 payment from bnp paribas paris (bnpafrpp) to banco santander madrid (bschesmm) via wells fargo (pnbpus3n, USD 20 charge) and bank of new york mellon (irvtus3n, USD 22 charge), reference 103ref405775, charges sha, beneficiary account es6300491800132710387658, final settled USD 367,532.90, with every optional field explained as it appears and disappears across the three mt103s?
Takeaway and next step
What to remember
The lesson of the chain is that field 52a appears once the sender stops being the ordering institution, field 57a disappears once the receiver becomes the beneficiary bank, field 53B changes at every hop to name the funding account, and field 71F records each deduction in turn.
Open the message type from this lesson and inspect its fields, then find the field that carries the amount.
Open the ISO 20022 Message Explorer →
Builds on "Field 70 Remittance Information and Field 71G Receiver's Charges".
Transcript and full text
Show transcript
This worked example is set before the CBPR+ migration, so the payment travels as MT103s. The payment begins with a customer of BNP Paribas in Paris who instructs a transfer of 367,574.90 dollars to a beneficiary whose account is ES6300491800132710387658 with Banco Santander in Madrid. The charge option is SHA, which means shared charges, so each bank in the chain may deduct its own fee from the amount it forwards. The transaction reference is 103REF405775, and it stays the same on all three MT103 messages so every bank can link the legs. Field 70 carries the invoice reference, and the value date is 5 November 2024, so Santander must make the funds available on that date subject to its cut off time. The first MT103 is sent by BNP Paribas, BIC BNPAFRPP, to Wells Fargo, BIC PNBPUS3N, in New York. Field 32A reads 241105USD367574,90 for the full amount, field 50a names the BNP Paribas customer, and field 59A names the beneficiary with account ES6300491800132710387658. Field 52a is absent, because BNP Paribas is both the sender and the ordering institution. Field 57A reads BSCHESMM, because Santander holds the beneficiary account and Wells Fargo must forward the payment there. Field 53B names the BNP Paribas dollar account held with Wells Fargo, so Wells Fargo knows which nostro account to debit. The second MT103 is sent by Wells Fargo, BIC PNBPUS3N, to Bank of New York Mellon, BIC IRVTUS3N, in New York. Wells Fargo deducts its charge of 20 dollars, so field 32A now reads 241105USD367554,90, and field 71F reads USD20,00 to show that deduction. Field 52A now appears with BNPAFRPP, because Wells Fargo is the sender but BNP Paribas ordered the payment. Field 57A still reads BSCHESMM, because Santander still holds the beneficiary account. Field 53B now names the Wells Fargo account held with Bank of New York Mellon, so that bank knows which account to debit for the onward leg. The third MT103 is sent by Bank of New York Mellon, BIC IRVTUS3N, to Banco Santander, BIC BSCHESMM, in Madrid. Bank of New York Mellon deducts its charge of 22 dollars, so field 32A now reads 241105USD367532,90, and field 71F reads USD22,00 to show that deduction. Field 52A still reads BNPAFRPP, because BNP Paribas remains the ordering institution. Field 57a is now absent, because the receiver is Santander itself, the bank that holds the beneficiary account, so there is no need to name it again. Field 70 still carries the invoice reference, and field 71A still reads SHA. The final settled amount is 367,532.90 dollars, which is the original 367,574.90 dollars less the 20 dollar charge from Wells Fargo and the 22 dollar charge from Bank of New York Mellon. Santander credits account ES6300491800132710387658 with 367,532.90 dollars on 5 November 2026, and the beneficiary can reconcile the shortfall by adding the two field 71F amounts. The lesson of the chain is that field 52a appears once the sender stops being the ordering institution, field 57a disappears once the receiver becomes the beneficiary bank, field 53B changes at every hop to name the funding account, and field 71F records each deduction in turn. Worked example with real numbers: take the USD 367,574. The first MT103 now carries field 56A with the London bank, and field 57A with Wells Fargo, and the London bank forwards to Wells Fargo, which forwards to Bank of New York Mellon, which forwards to Madrid, so the chain has four legs instead of three, and each leg deducts a charge: London USD 10, Wells Fargo USD 20, Bank of New York Mellon USD 22, so the beneficiary receives USD 367,522.90, USD 10 less than before. The worked example shows that adding an intermediary costs money and time, and the treasurer must decide whether the extra hop is worth it, or whether to wait for Wells Fargo to become available. Failure and recovery: the four-leg chain fails when the London bank is named in 56A but the 57A still names Bank of New York Mellon, skipping Wells Fargo, so the London bank sends the payment directly to Bank of New York Mellon, which does not expect it, and holds it. The recovery is a status request to Bank of New York Mellon, a correction of the 57A to name Wells Fargo, and a resend, but the payment is already a day late, and the charges have already been deducted by London. A chain with a new intermediary must be tested end to end before it is used live, with the fields checked on each leg, because a chain that is tested only on the first leg will fail on the second, and the failure will be discovered by the beneficiary, not by the bank. For a business analyst, product owner or subject matter expert, the worked example requirement must include a variant with an extra intermediary, showing the fields, the charges and the time on each leg, and must state the test that proves the chain works before it is used. The ISO 20022 pacs.008 must carry the same four-leg chain, and the migration test must check the intermediary agent fields on each leg, because a chain that is correct in MT but truncated in MX will send the payment to the wrong bank. A worked example that does not vary the chain is a worked example that does not test the chain.
This worked example is set before the CBPR+ migration, so the payment travels as MT103s. The payment begins with a customer of BNP Paribas in Paris who instructs a transfer of 367,574.90 dollars to a beneficiary whose account is ES6300491800132710387658 with Banco Santander in Madrid. The charge option is SHA, which means shared charges, so each bank in the chain may deduct its own fee from the amount it forwards. The transaction reference is 103REF405775, and it stays the same on all three MT103 messages so every bank can link the legs. Field 70 carries the invoice reference, and the value date is 5 November 2024, so Santander must make the funds available on that date subject to its cut off time.
The first MT103 is sent by BNP Paribas, BIC BNPAFRPP, to Wells Fargo, BIC PNBPUS3N, in New York. Field 32A reads 241105USD367574,90 for the full amount, field 50a names the BNP Paribas customer, and field 59A names the beneficiary with account ES6300491800132710387658. Field 52a is absent, because BNP Paribas is both the sender and the ordering institution. Field 57A reads BSCHESMM, because Santander holds the beneficiary account and Wells Fargo must forward the payment there. Field 53B names the BNP Paribas dollar account held with Wells Fargo, so Wells Fargo knows which nostro account to debit.
The second MT103 is sent by Wells Fargo, BIC PNBPUS3N, to Bank of New York Mellon, BIC IRVTUS3N, in New York. Wells Fargo deducts its charge of 20 dollars, so field 32A now reads 241105USD367554,90, and field 71F reads USD20,00 to show that deduction. Field 52A now appears with BNPAFRPP, because Wells Fargo is the sender but BNP Paribas ordered the payment. Field 57A still reads BSCHESMM, because Santander still holds the beneficiary account. Field 53B now names the Wells Fargo account held with Bank of New York Mellon, so that bank knows which account to debit for the onward leg.
The third MT103 is sent by Bank of New York Mellon, BIC IRVTUS3N, to Banco Santander, BIC BSCHESMM, in Madrid. Bank of New York Mellon deducts its charge of 22 dollars, so field 32A now reads 241105USD367532,90, and field 71F reads USD22,00 to show that deduction. Field 52A still reads BNPAFRPP, because BNP Paribas remains the ordering institution. Field 57a is now absent, because the receiver is Santander itself, the bank that holds the beneficiary account, so there is no need to name it again. Field 70 still carries the invoice reference, and field 71A still reads SHA.
The final settled amount is 367,532.90 dollars, which is the original 367,574.90 dollars less the 20 dollar charge from Wells Fargo and the 22 dollar charge from Bank of New York Mellon. Santander credits account ES6300491800132710387658 with 367,532.90 dollars on 5 November 2026, and the beneficiary can reconcile the shortfall by adding the two field 71F amounts. The lesson of the chain is that field 52a appears once the sender stops being the ordering institution, field 57a disappears once the receiver becomes the beneficiary bank, field 53B changes at every hop to name the funding account, and field 71F records each deduction in turn.
Worked example with real numbers: take the USD 367,574. The first MT103 now carries field 56A with the London bank, and field 57A with Wells Fargo, and the London bank forwards to Wells Fargo, which forwards to Bank of New York Mellon, which forwards to Madrid, so the chain has four legs instead of three, and each leg deducts a charge: London USD 10, Wells Fargo USD 20, Bank of New York Mellon USD 22, so the beneficiary receives USD 367,522.90, USD 10 less than before. The worked example shows that adding an intermediary costs money and time, and the treasurer must decide whether the extra hop is worth it, or whether to wait for Wells Fargo to become available.
Failure and recovery: the four-leg chain fails when the London bank is named in 56A but the 57A still names Bank of New York Mellon, skipping Wells Fargo, so the London bank sends the payment directly to Bank of New York Mellon, which does not expect it, and holds it. The recovery is a status request to Bank of New York Mellon, a correction of the 57A to name Wells Fargo, and a resend, but the payment is already a day late, and the charges have already been deducted by London. A chain with a new intermediary must be tested end to end before it is used live, with the fields checked on each leg, because a chain that is tested only on the first leg will fail on the second, and the failure will be discovered by the beneficiary, not by the bank.
For a business analyst, product owner or subject matter expert, the worked example requirement must include a variant with an extra intermediary, showing the fields, the charges and the time on each leg, and must state the test that proves the chain works before it is used. The ISO 20022 pacs.008 must carry the same four-leg chain, and the migration test must check the intermediary agent fields on each leg, because a chain that is correct in MT but truncated in MX will send the payment to the wrong bank. A worked example that does not vary the chain is a worked example that does not test the chain.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.