| 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 a Subsidiary Account and Paying on Behalf of Subsidiaries
What you will learn
Your objective. By the end of this lesson, you will be able to explain paying from a subsidiary account and paying on behalf of subsidiaries. Paying from a subsidiary account means the money leaves an account owned by the subsidiary, even though the parent treasury team sends the instruction.
Why it matters. The bank must hold a mandate for either pattern before it will act.
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
- Paying from a subsidiary account
- Paying on behalf of a subsidiary
- Supplier can then match
- Bank that debits
- Treasurer who confuses the two patterns
- EUR 50,000 from London to Munich
Key terms
Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.
Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.
Mandate: An authorisation given by a debtor to a creditor to collect payments from the debtor account by direct debit.
SWIFT MT message viewer showing Paying from a Subsidiary Account and Paying on Behalf of Subsidiaries.
Practise this lesson
Exercise
Find the field field 70 in the message described in this lesson and explain what it controls.
Use the field description and the example in this lesson.
- What to do. Write down what field 70 carries, what happens if it is wrong, and which system reads it.
Correct result. field 70 carries the value the lesson describes. If it is wrong, the payment is rejected, returned, or misrouted, and the exception must be investigated before the payment can proceed.
Why. Fields are the contract between systems. A wrong field is not a typo, it is a failed payment.
Check your understanding
Practice question
Which of the following best describes paying from a subsidiary account and paying on behalf of subsidiaries?
Takeaway and next step
What to remember
Each payment is reported under the correct entity, and the group accountant can post each one without a manual correction.
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 "Paying from Multiple Debit Accounts".
Transcript and full text
Show transcript
Paying from a subsidiary account and paying on behalf of subsidiaries are two different patterns, and an SME must keep them apart. In the first pattern, the subsidiary itself is the ordering customer, and the payment is debited from the subsidiary own account. In the second pattern, the parent pays on behalf of the subsidiary, and the payment is debited from the parent account, but the ordering customer named in the transaction is the subsidiary. The MT101 supports both, through the combination of field 50a and field 25 in Sequence B. The difference matters for the reporting, the tax treatment, and the intercompany accounting. In the subsidiary account pattern, the subsidiary sends the MT101, or the parent sends it with the subsidiary named as the ordering customer. Sequence A field 50a names the parent or the group treasury, and field 25 in Sequence A names the parent account as the default. Sequence B for the subsidiary payment carries field 50a naming the subsidiary, for example Atlas GmbH, Munich, and field 25 naming the subsidiary account, for example DE89 3704 0044 0532 0130 00 at a German bank. The bank debits the subsidiary account, and the beneficiary sees the subsidiary as the ordering customer. The bank checks that the sender is authorised to instruct a payment from the subsidiary account, which normally requires a mandate from the subsidiary to the parent or to the group treasury. In the payment on behalf pattern, often called POBO, the parent debits its own account but names the subsidiary as the ordering customer. Sequence B carries field 50a naming the subsidiary, Atlas GmbH, and field 25 naming the parent account, GB29 BARC 2012 3456 7890 01. The bank debits the parent account, but the beneficiary and the reporting show the subsidiary as the ordering customer. The parent then records an intercompany receivable from the subsidiary for the amount paid. The subsidiary records an intercompany payable to the parent. The bank does not need to know about the intercompany accounting, but it does need to know that the parent is authorised to pay on behalf of the subsidiary, and that authorisation is normally given in the account mandate or in a separate POBO agreement. The mandate is the legal basis, and it must be in place before the first payment. A mandate is a document, signed by the subsidiary, authorising the parent or the group treasury to instruct payments from the subsidiary account, or to pay on its behalf from the parent account. The bank holds the mandate on file, and it checks each MT101 against it. If the mandate is missing or has expired, the bank will reject the transaction. A treasurer who sets up a new subsidiary must therefore arrange the mandate at the same time as opening the account, and must renew it when the authorised signatories change. A payment that is rejected because the mandate is missing is a common failure in the first month after a new subsidiary is created. The reporting differs between the two patterns. In the subsidiary account pattern, the debit appears on the subsidiary bank statement, and the subsidiary reconciles it against its own accounts payable. In the POBO pattern, the debit appears on the parent bank statement, and the parent reconciles it against its intercompany ledger. The beneficiary receives the same information in both cases, the subsidiary name as the ordering customer, so the supplier can match the payment to the correct invoice. The difference is visible only in the bank statements and the intercompany accounting, not in the payment message the beneficiary receives. Consider a full example. Atlas Holdings has a parent in London and two subsidiaries, Atlas GmbH in Munich and Atlas SAS in Paris. On 12 May 2026 the group treasury sends one MT101 to Barclays with three Sequence B blocks. Sequence B 1 pays 60,000 euros to a supplier in Frankfurt for Atlas GmbH, debited from the Atlas GmbH account in Frankfurt, with field 50a naming Atlas GmbH. Sequence B 2 pays 25,000 euros to a supplier in Lyon for Atlas SAS, debited from the parent account in London, with field 50a naming Atlas SAS, which is the POBO pattern. Sequence B 3 pays 12,000 pounds to a consultant in Manchester for the parent, debited from the parent account, with field 50a naming Atlas Holdings Ltd. One message, three patterns, three different debit accounts and ordering customers, and the bank handles each correctly because the field 50a and field 25 in each Sequence B state the position explicitly. For a business analyst, the subsidiary requirement must cover the mandate, the ordering customer, and the intercompany accounting. The requirement should state that the system carries field 50a and field 25 per Sequence B, that it checks the mandate before the message is sent, that it records whether each transaction is a subsidiary account payment or a POBO payment, and that it posts the intercompany entries for POBO transactions automatically. A system that cannot distinguish the two patterns will post the accounting incorrectly, and the error will only be found at month end when the intercompany balances do not reconcile.
Paying from a subsidiary account and paying on behalf of subsidiaries are two different patterns, and an SME must keep them apart. In the first pattern, the subsidiary itself is the ordering customer, and the payment is debited from the subsidiary own account. In the second pattern, the parent pays on behalf of the subsidiary, and the payment is debited from the parent account, but the ordering customer named in the transaction is the subsidiary. The MT101 supports both, through the combination of field 50a and field 25 in Sequence B. The difference matters for the reporting, the tax treatment, and the intercompany accounting.
In the subsidiary account pattern, the subsidiary sends the MT101, or the parent sends it with the subsidiary named as the ordering customer. Sequence A field 50a names the parent or the group treasury, and field 25 in Sequence A names the parent account as the default. Sequence B for the subsidiary payment carries field 50a naming the subsidiary, for example Atlas GmbH, Munich, and field 25 naming the subsidiary account, for example DE89 3704 0044 0532 0130 00 at a German bank. The bank debits the subsidiary account, and the beneficiary sees the subsidiary as the ordering customer. The bank checks that the sender is authorised to instruct a payment from the subsidiary account, which normally requires a mandate from the subsidiary to the parent or to the group treasury.
In the payment on behalf pattern, often called POBO, the parent debits its own account but names the subsidiary as the ordering customer. Sequence B carries field 50a naming the subsidiary, Atlas GmbH, and field 25 naming the parent account, GB29 BARC 2012 3456 7890 01. The bank debits the parent account, but the beneficiary and the reporting show the subsidiary as the ordering customer. The parent then records an intercompany receivable from the subsidiary for the amount paid. The subsidiary records an intercompany payable to the parent. The bank does not need to know about the intercompany accounting, but it does need to know that the parent is authorised to pay on behalf of the subsidiary, and that authorisation is normally given in the account mandate or in a separate POBO agreement.
The mandate is the legal basis, and it must be in place before the first payment. A mandate is a document, signed by the subsidiary, authorising the parent or the group treasury to instruct payments from the subsidiary account, or to pay on its behalf from the parent account. The bank holds the mandate on file, and it checks each MT101 against it. If the mandate is missing or has expired, the bank will reject the transaction. A treasurer who sets up a new subsidiary must therefore arrange the mandate at the same time as opening the account, and must renew it when the authorised signatories change. A payment that is rejected because the mandate is missing is a common failure in the first month after a new subsidiary is created.
The reporting differs between the two patterns. In the subsidiary account pattern, the debit appears on the subsidiary bank statement, and the subsidiary reconciles it against its own accounts payable. In the POBO pattern, the debit appears on the parent bank statement, and the parent reconciles it against its intercompany ledger. The beneficiary receives the same information in both cases, the subsidiary name as the ordering customer, so the supplier can match the payment to the correct invoice. The difference is visible only in the bank statements and the intercompany accounting, not in the payment message the beneficiary receives.
Consider a full example. Atlas Holdings has a parent in London and two subsidiaries, Atlas GmbH in Munich and Atlas SAS in Paris. On 12 May 2026 the group treasury sends one MT101 to Barclays with three Sequence B blocks. Sequence B 1 pays 60,000 euros to a supplier in Frankfurt for Atlas GmbH, debited from the Atlas GmbH account in Frankfurt, with field 50a naming Atlas GmbH. Sequence B 2 pays 25,000 euros to a supplier in Lyon for Atlas SAS, debited from the parent account in London, with field 50a naming Atlas SAS, which is the POBO pattern. Sequence B 3 pays 12,000 pounds to a consultant in Manchester for the parent, debited from the parent account, with field 50a naming Atlas Holdings Ltd. One message, three patterns, three different debit accounts and ordering customers, and the bank handles each correctly because the field 50a and field 25 in each Sequence B state the position explicitly.
For a business analyst, the subsidiary requirement must cover the mandate, the ordering customer, and the intercompany accounting. The requirement should state that the system carries field 50a and field 25 per Sequence B, that it checks the mandate before the message is sent, that it records whether each transaction is a subsidiary account payment or a POBO payment, and that it posts the intercompany entries for POBO transactions automatically. A system that cannot distinguish the two patterns will post the accounting incorrectly, and the error will only be found at month end when the intercompany balances do not reconcile.
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.