| Field | Meaning | Required |
|---|---|---|
:20: | A unique reference assigned by the customer or the sending bank to identify this request through its whole life. It must not repeat for the same sender on the s | M |
:21R: | A reference supplied by the customer to identify the payment in its own systems, such as an invoice batch number. It is carried through to the executed payment | O |
:28D: | The statement number and sequence number that identify this request within a series of MT101 messages. They let the bank detect a missing or duplicate request i | M |
:30: | The date on which the customer asks the bank to execute the transfers in the request. The bank checks it against cut off times and business days and may move it | M |
:50a: | The customer ordering the payment, identified by account number and name and address. Option C gives account and name, option F gives structured party details, | M |
:52a: | The bank servicing the ordering customer account when it differs from the receiver of the message. It identifies the institution that holds the debtor account i | O |
:56a: | An intermediary bank in the payment chain between the ordering bank and the beneficiary bank. It is used when no direct account relationship exists and funds mu | O |
:57a: | The bank where the beneficiary holds an account, when it is not the receiver of the executed payment. It directs the executing bank to forward the funds to the | O |
:59a: | The final recipient of the funds, identified by account number and name and address. The executing bank credits this account on the value date after screening c | M |
:32B: | The currency and amount of the transfer, for example EUR 48,250.00. It is the amount the beneficiary receives before any charges agreed in the request. The amou | M |
:70: | Free text information for the beneficiary explaining what the payment is for, such as an invoice number or contract reference. It is limited to four lines of 35 | O |
:71A: | A code stating who pays the transfer charges, using OUR, BEN or SHA. OUR means the ordering customer pays all charges, BEN means the beneficiary pays, and SHA m | O |
Meridian Bank receives an MT101 from a corporate customer, reference MER101778, instructing a payment of EUR 48,250.00 on 6 November 2026 to Harbour Bank for the account of a supplier in Madrid. The debtor account is funded, the beneficiary IBAN is valid, and the bank executes the transfer on the requested value date.
Valid example from the message catalogue. Scheme rules: MT101 is a legacy customer to bank message with no single global scheme rulebook. Each bank defines its own format limits, cut off times and file handling for the message. Domestic use continues in so
Two Domestic Transactions in One MT101
What you will learn
Your objective. By the end of this lesson, you will be able to explain two domestic transactions in one mt101. A corporation may need to make two domestic payments on the same day, for example a salary payment and a supplier payment, or two supplier payments to different cities.
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 MT101 use cases, multiple debit accounts, subsidiary payments, funds repatriation and the difference between Sequence A and Sequence B. Learner uses real examples with amounts, banks and message names to show how the topic works in practice.
Key learning points
- Corporation may need to make two domestic
- Sequence B block carries its
- Two transactions may use different
- Requested execution date in Sequence
- One MT101 saves a message
Key terms
Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.
Execution date: The date on which the bank executes a payment instruction, debiting the debtor account and sending the message onward.
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.
SWIFT MT message viewer showing Two Domestic Transactions in One MT101.
Practise this lesson
Exercise
Read the MT101 with 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 two domestic transactions in one mt101?
Takeaway and next step
What to remember
The alternative, two separate messages and two separate validations, would take twice the treasury time and double the chance of a manual error.
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 50a Ordering Customer in Sequence A vs Sequence B".
Transcript and full text
Show transcript
Two domestic transactions in one MT101 is the simplest multi-transaction case, and it shows how the message works when no cross border leg is involved. A corporation sends one MT101 to its bank, and the bank executes two domestic payments from the same account, on the same execution date, to two different beneficiaries. The two payments are independent, and each has its own Sequence B, its own reference, its own amount, and its own remittance information. The bank debits the account once per transaction, or once for the total if its system supports a single debit, and it sends each payment through the domestic clearing system. Consider a concrete example. Meridian Foods Ltd holds account GB29 HBUK 4012 3456 7890 01 at HSBC in London. On 12 May 2026 it sends an MT101 with reference PAYRUN 2026 0512 and execution date 120526. Sequence B 1, indexed 1/2 in field 28D, pays 45,000 pounds to a supplier in Berlin. Sequence B 2, indexed 2/2, pays 12,000 pounds to a consultant in Manchester. Field 50a in Sequence A names Meridian Foods Ltd. Field 25 in Sequence A names the Meridian account. Each Sequence B carries its own field 21 transaction reference, its own field 32B amount, its own field 59a beneficiary, and its own field 70 remittance information. The bank reads the two Sequence B blocks and creates two separate domestic payments. The two payments may travel through different domestic systems even though they are in one MT101. The payment to the consultant in Manchester, in pounds, will normally go through Faster Payments if it is below the scheme limit, or through BACS if it is a regular bulk payment, or through CHAPS if it is high value and urgent. The payment to the supplier in Berlin, also in pounds in this example, will go through the same domestic system if the beneficiary bank is in the UK, or through the cross border route if the beneficiary account is in Germany. The MT101 does not dictate the clearing system. The bank decides the routing for each Sequence B based on the currency, the amount, the beneficiary bank, and the value date. The corporation only states the payment, and the bank routes it. The value date and the execution date are different ideas, and an SME must keep them apart. Field 30 in Sequence A is the requested execution date, the date the bank should start processing the payment. The value date is the date the beneficiary bank credits the beneficiary account, and it depends on the clearing system. A Faster Payments payment executed on 12 May will normally reach the beneficiary on the same day. A BACS payment executed on 12 May will reach the beneficiary on 14 May, because BACS works on a three day cycle. The MT101 does not carry a value date per transaction, so the corporation must know the clearing cycle of the system the bank will use, and must set the execution date early enough to meet the supplier payment deadline. The bank reports each transaction separately, even though they arrived in one message. The status report will list transaction 1, reference and amount, as executed, and transaction 2, reference and amount, as executed, with the value date and the charges for each. If one transaction fails, for example because the beneficiary account number is invalid, the bank reports that transaction as rejected and processes the other. The corporation reconciles the status report against its own payment run, transaction by transaction, and re-issues the failed payment in a new MT101 or through another channel. A treasury system that cannot reconcile at transaction level cannot use MT101 safely, because a single failed payment in a large run is easy to miss. A common edge case is a duplicate Sequence B. If the sender system generates the same field 21 reference twice, the bank may reject the second transaction as a duplicate, or it may execute it twice if its duplicate detection is weak. The sender must therefore generate a unique field 21 for each Sequence B, and the bank must check the reference against recently processed transactions. Another edge case is a transaction whose amount exceeds the debit account balance when combined with the other transactions in the run. The bank checks the total of all Sequence B amounts against the available balance, not each transaction in isolation, and it will reject the whole run or the later transactions if the total exceeds the balance. The corporation should therefore check the total before sending the message. For a business analyst, the requirement for two domestic transactions in one MT101 is straightforward to write, but it must cover the routing decision, the value date, and the reporting. The requirement should state that the system sends one MT101 with two Sequence B blocks, that each block carries its own beneficiary, amount, and remittance information, that the bank routes each payment through the appropriate domestic system, that the system records the value date per transaction from the bank status report, and that the system flags any transaction that is rejected so the treasurer can re-issue it. A system that treats the MT101 as one payment, rather than as a container for many payments, will fail the reconciliation.
Two domestic transactions in one MT101 is the simplest multi-transaction case, and it shows how the message works when no cross border leg is involved. A corporation sends one MT101 to its bank, and the bank executes two domestic payments from the same account, on the same execution date, to two different beneficiaries. The two payments are independent, and each has its own Sequence B, its own reference, its own amount, and its own remittance information. The bank debits the account once per transaction, or once for the total if its system supports a single debit, and it sends each payment through the domestic clearing system.
Consider a concrete example. Meridian Foods Ltd holds account GB29 HBUK 4012 3456 7890 01 at HSBC in London. On 12 May 2026 it sends an MT101 with reference PAYRUN 2026 0512 and execution date 120526. Sequence B 1, indexed 1/2 in field 28D, pays 45,000 pounds to a supplier in Berlin. Sequence B 2, indexed 2/2, pays 12,000 pounds to a consultant in Manchester. Field 50a in Sequence A names Meridian Foods Ltd. Field 25 in Sequence A names the Meridian account. Each Sequence B carries its own field 21 transaction reference, its own field 32B amount, its own field 59a beneficiary, and its own field 70 remittance information. The bank reads the two Sequence B blocks and creates two separate domestic payments.
The two payments may travel through different domestic systems even though they are in one MT101. The payment to the consultant in Manchester, in pounds, will normally go through Faster Payments if it is below the scheme limit, or through BACS if it is a regular bulk payment, or through CHAPS if it is high value and urgent. The payment to the supplier in Berlin, also in pounds in this example, will go through the same domestic system if the beneficiary bank is in the UK, or through the cross border route if the beneficiary account is in Germany. The MT101 does not dictate the clearing system. The bank decides the routing for each Sequence B based on the currency, the amount, the beneficiary bank, and the value date. The corporation only states the payment, and the bank routes it.
The value date and the execution date are different ideas, and an SME must keep them apart. Field 30 in Sequence A is the requested execution date, the date the bank should start processing the payment. The value date is the date the beneficiary bank credits the beneficiary account, and it depends on the clearing system. A Faster Payments payment executed on 12 May will normally reach the beneficiary on the same day. A BACS payment executed on 12 May will reach the beneficiary on 14 May, because BACS works on a three day cycle. The MT101 does not carry a value date per transaction, so the corporation must know the clearing cycle of the system the bank will use, and must set the execution date early enough to meet the supplier payment deadline.
The bank reports each transaction separately, even though they arrived in one message. The status report will list transaction 1, reference and amount, as executed, and transaction 2, reference and amount, as executed, with the value date and the charges for each. If one transaction fails, for example because the beneficiary account number is invalid, the bank reports that transaction as rejected and processes the other. The corporation reconciles the status report against its own payment run, transaction by transaction, and re-issues the failed payment in a new MT101 or through another channel. A treasury system that cannot reconcile at transaction level cannot use MT101 safely, because a single failed payment in a large run is easy to miss.
A common edge case is a duplicate Sequence B. If the sender system generates the same field 21 reference twice, the bank may reject the second transaction as a duplicate, or it may execute it twice if its duplicate detection is weak. The sender must therefore generate a unique field 21 for each Sequence B, and the bank must check the reference against recently processed transactions. Another edge case is a transaction whose amount exceeds the debit account balance when combined with the other transactions in the run. The bank checks the total of all Sequence B amounts against the available balance, not each transaction in isolation, and it will reject the whole run or the later transactions if the total exceeds the balance. The corporation should therefore check the total before sending the message.
For a business analyst, the requirement for two domestic transactions in one MT101 is straightforward to write, but it must cover the routing decision, the value date, and the reporting. The requirement should state that the system sends one MT101 with two Sequence B blocks, that each block carries its own beneficiary, amount, and remittance information, that the bank routes each payment through the appropriate domestic system, that the system records the value date per transaction from the bank status report, and that the system flags any transaction that is rejected so the treasurer can re-issue it. A system that treats the MT101 as one payment, rather than as a container for many payments, will fail the reconciliation.
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.