| 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
Paying from Multiple Debit Accounts
What you will learn
Your objective. By the end of this lesson, you will be able to explain paying from multiple debit accounts. A corporation may hold an operating account, a tax account, and a payroll account at the same bank, and it may need to pay from more than one of them in a single run.
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 hold an operating account
- Rule: simple to apply
- Bank checks funds separately
- Field 25 must be given
- Practical example
Key terms
Execution date: The date on which the bank executes a payment instruction, debiting the debtor account and sending the message onward.
Mandate: An authorisation given by a debtor to a creditor to collect payments from the debtor account by direct debit.
MT101: A SWIFT message a corporate customer sends to its bank to request execution of one or more payment instructions.
SWIFT MT message viewer showing Paying from Multiple Debit Accounts.
Practise this lesson
Exercise
Read the MT101 supports 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 paying from multiple debit accounts?
Takeaway and next step
What to remember
The bank executes all five payments from the three accounts, and the group treasurer reconciles each account from one MT940 statement, with each debit linked to its own transaction reference.
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 "Two Domestic Transactions in One MT101".
Transcript and full text
Show transcript
Paying from multiple debit accounts in one MT101 is the feature that makes the message powerful for a group treasury. A corporation holds accounts in several currencies, or several accounts in the same currency for different entities, and it wants to pay from each account in a single instruction. The MT101 supports this by allowing field 25, the account to be debited, to appear in Sequence B as well as in Sequence A. Field 25 in Sequence A names the default debit account for the message. Field 25 in Sequence B, when present, overrides the Sequence A account for that transaction only. The bank debits the account named in each Sequence B, and the corporation gets one message that draws on many accounts. Consider a concrete example. Atlas Holdings has three accounts at Barclays: a pounds account GB29 BARC 2012 3456 7890 01, a euros account GB29 BARC 2012 3456 7890 02, and a dollars account GB29 BARC 2012 3456 7890 03. On 12 May 2026 Atlas sends one MT101 with three Sequence B blocks. Sequence B 1 pays 45,000 euros to a supplier in Berlin, and field 25 in that Sequence B names the euros account. Sequence B 2 pays 12,000 pounds to a consultant in Manchester, and field 25 names the pounds account. Sequence B 3 pays 30,000 dollars to a supplier in New York, and field 25 names the dollars account. Field 25 in Sequence A names the pounds account as the default, but each Sequence B overrides it with its own account. The bank debits three accounts, one per transaction. The bank validates each debit account separately. It checks that the account exists, that the sender is authorised to debit it, and that the account has sufficient funds or an approved overdraft for that transaction. If the euros account has only 40,000 euros and the transaction is for 45,000 euros, the bank will reject that transaction, but it will still process the other two, unless the bilateral agreement says the whole message is rejected on any failure. The bank also checks that the currency of the debit account matches the currency of the transaction, or that a conversion is authorised. A euros transaction debited from a pounds account requires a foreign exchange conversion, and the bank will apply its rate and report the converted amount. The corporation should therefore match the debit account currency to the transaction currency wherever possible, to avoid unexpected conversion costs. The reporting for a multi-account MT101 is per account and per transaction. The bank statement for the euros account will show a debit of 45,000 euros with the field 21 reference of Sequence B 1. The statement for the pounds account will show a debit of 12,000 pounds with the reference of Sequence B 2. The statement for the dollars account will show a debit of 30,000 dollars with the reference of Sequence B 3. The treasurer reconciles each account separately, using the field 21 reference to match the statement entry to the original instruction. A treasury system that cannot reconcile at the level of the individual debit account will struggle, because the three debits appear on three different statements. A common error is to put field 25 in Sequence B when it is not needed. If all transactions are debited from the same account, field 25 should appear only in Sequence A, and the Sequence B blocks should omit it. Putting the same account in every Sequence B is harmless but adds noise, and it increases the risk of a typo in one block that causes a rejection. The opposite error is to omit field 25 in Sequence B when the transaction should be debited from a different account. The bank will then debit the Sequence A account, which may be the wrong account, and the corporation will discover the error only when it reconciles the statements. An SME who reviews an MT101 interface should check that the system makes the debit account explicit per transaction, and that it defaults to the Sequence A account only when the user has not chosen a different one. The liquidity check is also per account. The bank checks the available balance in each debit account against the transactions drawn on that account, not against the total of the message. A message with 45,000 euros from the euros account and 12,000 pounds from the pounds account needs 45,000 euros in the euros account and 12,000 pounds in the pounds account. It does not need the equivalent of 57,000 in one currency. The treasurer must therefore ensure that each account is funded before sending the message, and the treasury system should show the balance per account alongside the transactions drawn on it. A payment run that fails because one account is short by a small amount is a common operational failure, and it is avoidable with a pre-send balance check. For a business analyst, the multi-account requirement must state the override rule clearly. The requirement should say that field 25 in Sequence B, when present, overrides field 25 in Sequence A for that transaction, that the system validates each debit account and its balance before the message is sent, that the system reports the debit account per transaction in the status report, and that the reconciliation matches each statement entry to its transaction by the field 21 reference. A system that only supports a single debit account per message cannot serve a group treasury, and that limitation should be stated plainly in the gap analysis.
Paying from multiple debit accounts in one MT101 is the feature that makes the message powerful for a group treasury. A corporation holds accounts in several currencies, or several accounts in the same currency for different entities, and it wants to pay from each account in a single instruction. The MT101 supports this by allowing field 25, the account to be debited, to appear in Sequence B as well as in Sequence A. Field 25 in Sequence A names the default debit account for the message. Field 25 in Sequence B, when present, overrides the Sequence A account for that transaction only. The bank debits the account named in each Sequence B, and the corporation gets one message that draws on many accounts.
Consider a concrete example. Atlas Holdings has three accounts at Barclays: a pounds account GB29 BARC 2012 3456 7890 01, a euros account GB29 BARC 2012 3456 7890 02, and a dollars account GB29 BARC 2012 3456 7890 03. On 12 May 2026 Atlas sends one MT101 with three Sequence B blocks. Sequence B 1 pays 45,000 euros to a supplier in Berlin, and field 25 in that Sequence B names the euros account. Sequence B 2 pays 12,000 pounds to a consultant in Manchester, and field 25 names the pounds account. Sequence B 3 pays 30,000 dollars to a supplier in New York, and field 25 names the dollars account. Field 25 in Sequence A names the pounds account as the default, but each Sequence B overrides it with its own account. The bank debits three accounts, one per transaction.
The bank validates each debit account separately. It checks that the account exists, that the sender is authorised to debit it, and that the account has sufficient funds or an approved overdraft for that transaction. If the euros account has only 40,000 euros and the transaction is for 45,000 euros, the bank will reject that transaction, but it will still process the other two, unless the bilateral agreement says the whole message is rejected on any failure. The bank also checks that the currency of the debit account matches the currency of the transaction, or that a conversion is authorised. A euros transaction debited from a pounds account requires a foreign exchange conversion, and the bank will apply its rate and report the converted amount. The corporation should therefore match the debit account currency to the transaction currency wherever possible, to avoid unexpected conversion costs.
The reporting for a multi-account MT101 is per account and per transaction. The bank statement for the euros account will show a debit of 45,000 euros with the field 21 reference of Sequence B 1. The statement for the pounds account will show a debit of 12,000 pounds with the reference of Sequence B 2. The statement for the dollars account will show a debit of 30,000 dollars with the reference of Sequence B 3. The treasurer reconciles each account separately, using the field 21 reference to match the statement entry to the original instruction. A treasury system that cannot reconcile at the level of the individual debit account will struggle, because the three debits appear on three different statements.
A common error is to put field 25 in Sequence B when it is not needed. If all transactions are debited from the same account, field 25 should appear only in Sequence A, and the Sequence B blocks should omit it. Putting the same account in every Sequence B is harmless but adds noise, and it increases the risk of a typo in one block that causes a rejection. The opposite error is to omit field 25 in Sequence B when the transaction should be debited from a different account. The bank will then debit the Sequence A account, which may be the wrong account, and the corporation will discover the error only when it reconciles the statements. An SME who reviews an MT101 interface should check that the system makes the debit account explicit per transaction, and that it defaults to the Sequence A account only when the user has not chosen a different one.
The liquidity check is also per account. The bank checks the available balance in each debit account against the transactions drawn on that account, not against the total of the message. A message with 45,000 euros from the euros account and 12,000 pounds from the pounds account needs 45,000 euros in the euros account and 12,000 pounds in the pounds account. It does not need the equivalent of 57,000 in one currency. The treasurer must therefore ensure that each account is funded before sending the message, and the treasury system should show the balance per account alongside the transactions drawn on it. A payment run that fails because one account is short by a small amount is a common operational failure, and it is avoidable with a pre-send balance check.
For a business analyst, the multi-account requirement must state the override rule clearly. The requirement should say that field 25 in Sequence B, when present, overrides field 25 in Sequence A for that transaction, that the system validates each debit account and its balance before the message is sent, that the system reports the debit account per transaction in the status report, and that the reconciliation matches each statement entry to its transaction by the field 21 reference. A system that only supports a single debit account per message cannot serve a group treasury, and that limitation should be stated plainly in the gap analysis.
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.