| 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
MT101 Structure: Sequence A and Sequence B
What you will learn
Your objective. By the end of this lesson, you will be able to explain mt101 structure: sequence a and sequence b. Sequence A is the general information sequence.
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
- Sequence: general information sequence
- Information applies to the message
- Bank processes each Sequence B
- Index helps
- Flexibility: covered in later sections
- Bank may reject that transaction and process
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 MT101 Structure: Sequence A and Sequence B.
Practise this lesson
Exercise
Read the MT101 may 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 mt101 structure: sequence a and sequence b?
Takeaway and next step
What to remember
The bank then sends a status report, often an MT199 or an account statement MT940, to confirm what was executed.
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 "What MT101 Is and When Corporations Use It".
Transcript and full text
Show transcript
An MT101 has two sequences. Sequence A is the general information sequence, and it appears once. It identifies the sender, the message reference, the requested execution date, and the ordering customer for the message as a whole. Sequence B is the transaction details sequence, and it repeats once for each payment in the message. A message with 40 supplier payments has one Sequence A and 40 Sequence B blocks. The two sequences are separated by the field tags, and the bank reads Sequence A first to understand the run, then processes each Sequence B as a separate payment. Sequence A contains field 20, the sender transaction reference, format 16x, which is the reference the sender gives the whole message. It contains field 28D, the message index and total, format 5n/5n, written as a fraction such as 1/3, 2/3, 3/3, which tells the bank how many transactions to expect. It contains field 50a, the ordering customer, which names the party instructing the bank for the whole message. It contains field 30, the requested execution date, format 6!n, written as YYMMDD, for example 120526 for 12 May 2026. It contains field 25, the account number to be debited, format 35x, which is the default debit account for the message. Sequence A may also contain field 52a, the ordering institution, field 26T, the transaction type code, field 77B, the regulatory reporting information, and field 71A, the details of charges. Sequence B contains the fields for one payment. Field 21 is the transaction reference, format 16x, unique within the message. Field 32B is the transaction amount, format 3!a15d, carrying the currency code and the amount, for example EUR45000,00. Field 50a is the ordering customer for this transaction, which may differ from Sequence A. Field 52a is the ordering institution. Field 56a is the intermediary institution. Field 57a is the account with institution. Field 59a is the beneficiary customer, with the name and account. Field 70 is the remittance information, format 4x35, up to four lines of 35 characters. Field 71A is the details of charges for this transaction. Field 77B is the regulatory reporting. Field 33B is the currency and amount originally instructed, used when the payment is converted. Field 36 is the exchange rate, format 12d, used when the bank converts the currency. Field 28D is the control that holds the message together. It is written as a fraction, such as 1/3, 2/3, and 3/3, where the first number is the index of the current transaction and the second number is the total. A bank that receives a message with 28D as 1/3 expects two more Sequence B blocks to follow. If a block is missing, the bank will query the sender, because it cannot safely execute an incomplete payment run. The index also helps the bank to reconcile its processing and to report each transaction back to the customer by its own reference. A mismatch in 28D is one of the most common reasons a bank rejects an MT101, and it is usually caused by a truncation in the sender system. The two sequences use different fields for the same idea in some cases, and that flexibility is deliberate. Field 50a in Sequence A names the ordering customer for the whole message, while field 50a in Sequence B can name a different ordering customer for that single transaction. Field 25 in Sequence A names the account to be debited for the message, while field 25 in Sequence B can name a different debit account for that transaction. This flexibility allows a corporation to pay from several accounts in one message, and to pay on behalf of subsidiaries, which are covered in later sections of this chapter. The bank validates each Sequence B against the account named in it, not only against the Sequence A account. Every field in an MT101 has a format and a network validated rule. Field 20 must be 16x and must not start or end with a slash, and must not contain two consecutive slashes. Field 32B must carry a valid ISO currency code and an amount with a comma as the decimal separator. Field 59a must carry a valid account number or IBAN and a name. Field 30 must be a valid date. The SWIFT network validates these rules before the message reaches the bank, and a message that breaks a rule is rejected with a network acknowledgement. The bank then applies its own business validation, checking that the sender is authorised, that the debit account exists and has sufficient funds or an approved overdraft, and that each beneficiary account is well formed. The message ends after the last Sequence B, and the bank validates the whole MT101 before it executes any transaction. If one transaction fails validation, the bank may reject that transaction and process the rest, or it may reject the whole message, depending on its agreement with the customer. The bank then sends a status report, often an MT199 or an account statement MT940, to confirm what was executed. A treasurer should always reconcile the status report against the original instruction, transaction by transaction, because a single rejected transaction in a 40 payment run is easy to miss and expensive to discover late. For an SME, the practical point is that Sequence A is the header of the run and Sequence B is the payment. When a business analyst writes a requirement for an MT101 interface, the requirement must state the Sequence A fields the system populates automatically, the Sequence B fields the user enters per payment, the validation rules the system enforces before the message leaves the corporate treasury system, and the reconciliation the system performs against the bank status report. A system that cannot produce a correct 28D, or that cannot carry a different 50a and 25 in Sequence B, cannot support the multi-account and subsidiary use cases that make MT101 worth using.
An MT101 has two sequences. Sequence A is the general information sequence, and it appears once. It identifies the sender, the message reference, the requested execution date, and the ordering customer for the message as a whole. Sequence B is the transaction details sequence, and it repeats once for each payment in the message. A message with 40 supplier payments has one Sequence A and 40 Sequence B blocks. The two sequences are separated by the field tags, and the bank reads Sequence A first to understand the run, then processes each Sequence B as a separate payment.
Sequence A contains field 20, the sender transaction reference, format 16x, which is the reference the sender gives the whole message. It contains field 28D, the message index and total, format 5n/5n, written as a fraction such as 1/3, 2/3, 3/3, which tells the bank how many transactions to expect. It contains field 50a, the ordering customer, which names the party instructing the bank for the whole message. It contains field 30, the requested execution date, format 6!n, written as YYMMDD, for example 120526 for 12 May 2026. It contains field 25, the account number to be debited, format 35x, which is the default debit account for the message. Sequence A may also contain field 52a, the ordering institution, field 26T, the transaction type code, field 77B, the regulatory reporting information, and field 71A, the details of charges.
Sequence B contains the fields for one payment. Field 21 is the transaction reference, format 16x, unique within the message. Field 32B is the transaction amount, format 3!a15d, carrying the currency code and the amount, for example EUR45000,00. Field 50a is the ordering customer for this transaction, which may differ from Sequence A. Field 52a is the ordering institution. Field 56a is the intermediary institution. Field 57a is the account with institution. Field 59a is the beneficiary customer, with the name and account. Field 70 is the remittance information, format 4x35, up to four lines of 35 characters. Field 71A is the details of charges for this transaction. Field 77B is the regulatory reporting. Field 33B is the currency and amount originally instructed, used when the payment is converted. Field 36 is the exchange rate, format 12d, used when the bank converts the currency.
Field 28D is the control that holds the message together. It is written as a fraction, such as 1/3, 2/3, and 3/3, where the first number is the index of the current transaction and the second number is the total. A bank that receives a message with 28D as 1/3 expects two more Sequence B blocks to follow. If a block is missing, the bank will query the sender, because it cannot safely execute an incomplete payment run. The index also helps the bank to reconcile its processing and to report each transaction back to the customer by its own reference. A mismatch in 28D is one of the most common reasons a bank rejects an MT101, and it is usually caused by a truncation in the sender system.
The two sequences use different fields for the same idea in some cases, and that flexibility is deliberate. Field 50a in Sequence A names the ordering customer for the whole message, while field 50a in Sequence B can name a different ordering customer for that single transaction. Field 25 in Sequence A names the account to be debited for the message, while field 25 in Sequence B can name a different debit account for that transaction. This flexibility allows a corporation to pay from several accounts in one message, and to pay on behalf of subsidiaries, which are covered in later sections of this chapter. The bank validates each Sequence B against the account named in it, not only against the Sequence A account.
Every field in an MT101 has a format and a network validated rule. Field 20 must be 16x and must not start or end with a slash, and must not contain two consecutive slashes. Field 32B must carry a valid ISO currency code and an amount with a comma as the decimal separator. Field 59a must carry a valid account number or IBAN and a name. Field 30 must be a valid date. The SWIFT network validates these rules before the message reaches the bank, and a message that breaks a rule is rejected with a network acknowledgement. The bank then applies its own business validation, checking that the sender is authorised, that the debit account exists and has sufficient funds or an approved overdraft, and that each beneficiary account is well formed.
The message ends after the last Sequence B, and the bank validates the whole MT101 before it executes any transaction. If one transaction fails validation, the bank may reject that transaction and process the rest, or it may reject the whole message, depending on its agreement with the customer. The bank then sends a status report, often an MT199 or an account statement MT940, to confirm what was executed. A treasurer should always reconcile the status report against the original instruction, transaction by transaction, because a single rejected transaction in a 40 payment run is easy to miss and expensive to discover late.
For an SME, the practical point is that Sequence A is the header of the run and Sequence B is the payment. When a business analyst writes a requirement for an MT101 interface, the requirement must state the Sequence A fields the system populates automatically, the Sequence B fields the user enters per payment, the validation rules the system enforces before the message leaves the corporate treasury system, and the reconciliation the system performs against the bank status report. A system that cannot produce a correct 28D, or that cannot carry a different 50a and 25 in Sequence B, cannot support the multi-account and subsidiary use cases that make MT101 worth using.
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.