MT101 Format: Every Field, Sequence A and B

An MT101 — the SWIFT Request for Transfer — is a corporate's instruction to a bank to debit the corporate's own account and pay someone: one sequence A with what applies to every payment (the reference :20:, the message index :28D:, the execution date :30:, the debit account in :50a:), then one sequence B per payment (its reference :21:, amount :32B:, beneficiary :59a:, charges :71A:). If you are trying to work out what an MT101 is for and how it differs from MT103 and MT202, start with MT101 vs MT103 vs MT202. This post is for the day you are building or debugging one and need to know what each field holds and what your bank will refuse.

SWIFT's own MT101 specification sits behind the user handbook login, so everything below is checked against what banks publish instead: ANZ's and mBank's 2026 guides, Česká spořitelna's file description and Handelsbanken's implementation guide. Four banks turn out to be a good teacher, because they disagree in instructive places.

And it is still worth knowing. The corporate-to-bank space runs on its own clock: SWIFT says corporates can keep exchanging MTs like MT101 after the November 2025 interbank cutover, and the direction of travel is the pain.001 — the timelines post keeps the dates in one place.

The shape of the message

An MT101 is a SWIFT FIN message. Block 1 carries the sender, block 2 the message type and the receiving bank ({2:I101…}), block 3 is optional, and block 4 holds the fields, one per line, each starting with a colon-wrapped tag. ANZ's guide spells out the envelope: block 4 opens with {4: and closes with -}.

Inside block 4 there are two kinds of sequence:

• Sequence A, general information, appears exactly once, and whatever it says applies to every payment in the message.
• Sequence B, transaction details, repeats, one occurrence per payment.

The field formats use SWIFT's shorthand: 16x is up to sixteen characters, 6!n exactly six digits, 3!a15d a three-letter currency and an amount whose decimal comma is mandatory, 4*35x up to four lines of 35. A lowercase a in a tag name, as in :50a:, stands for the option letter you choose — :50H:, :57A:, :59F:.

Sequence A — what applies to every payment

:20:   Sender's Reference            mandatory   16x
:21R:  Customer Specified Reference  optional    16x
:28D:  Message Index/Total           mandatory   5n/5n
:50a:  Instructing Party (C or L)    optional
:50a:  Ordering Customer (F, G, H)   conditional
:52a:  Account Servicing Institution optional    (A or C)
:51A:  Sending Institution           optional
:30:   Requested Execution Date      mandatory   6!n
:25:   Authorisation                 optional    35x

:20: Sender's Reference names the message. Keep it unique — Česká spořitelna's guide builds it from the file date and two counters so it never repeats, even after old payment files are gone. But do not build your matching on it. ANZ's guide says plainly that it will not return the :20: content, and that the reply has to be matched on the :21: of each payment.

:21R: Customer Specified Reference is the instruction to post one debit for the whole message. Per Česká spořitelna, when it is present the ordering customer asks for a single debit entry for the sum of all the payments; without it, each payment is debited on its own. Not every bank honours it: mBank's 2026 guide marks it "not supported, ignored if present".

:28D: Message Index/Total chains a long instruction across several messages, as 1/3, 2/3, 3/3. In a chain, every message carries the same :20:, and sequence A is repeated identically in each. That is the standard. In practice, ANZ requires 1/1 and treats every message as a separate instruction, and Handelsbanken accepts the field but does not act on it. If you are writing one MT101 per payment file, 1/1 is the safe value.

:50a: Ordering Customer is the account owner and the account to debit: option G is an account plus a BIC, option H an account plus name and address, and option F an account plus structured name-and-address lines. The banks narrow this: mBank's examples use :50H:, ANZ asks for G or F, and ANZ wants a physical address in F — no PO boxes, with at least the country and town on the 3/ line.

:50a: Instructing Party, options C (a BIC) or L (a name), is for when someone other than the account owner is authorised to order the payment — a shared service centre paying for a subsidiary, say. Česká spořitelna is explicit that it is only used when the instructing customer is not also the account owner.

:52a: Account Servicing Institution is the bank that holds the account to be debited, when that is not simply the receiver of the message.

:30: Requested Execution Date is the date, as YYMMDD. mBank stores a future-dated instruction until that day and then executes it; ANZ requires a valid business date.

:51A: Sending Institution and :25: Authorisation are both in the standard and both widely ignored: mBank ignores them if present, Handelsbanken does not use them. :25: was meant to carry additional security provisions, such as a digital signature, between the customer and the bank.

Sequence B — one block per payment

:21:   Transaction Reference         mandatory   16x
:21F:  F/X Deal Reference            optional    16x
:23E:  Instruction Code              optional    4!c[/30x]
:32B:  Currency/Transaction Amount   mandatory   3!a15d
:50a:  Instructing Party (C or L)    optional
:50a:  Ordering Customer (F, G, H)   conditional
:52a:  Account Servicing Institution optional
:56a:  Intermediary                  optional    (A, C or D)
:57a:  Account With Institution      optional    (A, C or D)
:59a:  Beneficiary                   mandatory   (no letter, A or F)
:70:   Remittance Information        optional    4*35x
:77B:  Regulatory Reporting          optional    3*35x
:33B:  Currency/Original Amount      optional    3!a15d
:71A:  Details of Charges            mandatory   3!a
:25A:  Charges Account               optional    /34x
:36:   Exchange Rate                 optional    12d

:21: Transaction Reference is your reference for this one payment, and the one to match on. ANZ sends its replies (an MT199 or MT900) against it.

:32B: Currency/Transaction Amount is what the beneficiary should get, as EUR1234,56. The decimal comma is required even with no decimals (JPY12345,), and there are no thousands separators.

:33B:, :36: and :21F: handle a payment in a different currency from the account. :33B: is the original ordered amount in the account's currency, :36: the rate, and :21F: the reference of the FX deal that rate came from. ANZ also lets you send :32B: as zero with the amount in :33B: and the instruction code EQUI in :23E:, meaning "pay the equivalent of this".

:23E: Instruction Code is a four-letter code, with optional text after a slash. ANZ accepts up to four, does not act on them itself, and passes on the ones meant for the beneficiary's bank — which may or may not act on them.

:57a: Account With Institution is the beneficiary's bank, and :56a: Intermediary a bank in between. Option A is a BIC, option C a national clearing code (// plus the code — ANZ's example is an Australian BSB), option D a name and address for when you have neither. If :57a: is missing, Česká spořitelna's guide says the receiver of the message takes that role; ANZ makes it mandatory anyway.

:59a: Beneficiary is the account and the party being paid: with no letter option, an account plus name and address lines; option A, an account plus a BIC; option F, an account plus structured name-and-address lines. ANZ says not to use the no-letter option when you give an address, and not at all cross-border: use F, with at least 3/ plus country and town.

:70: Remittance Information is four lines of 35 characters of free text. Banks use it differently — mBank uses a coded layout for Polish split payments, and Handelsbanken caps it at 14 characters for some transfers within the bank. The remittance advice post covers what happens when 140 characters is not enough.

:71A: Details of Charges is who pays the fees: OUR (the ordering customer), SHA (shared) or BEN (the beneficiary). Banks restrict the choice by payment type — ANZ requires SHA for RTGS and SHA or OUR for international payments, and mBank executes cross-border payments to EEA countries as SHA only, quietly changing OUR or BEN to SHA. :25A: Charges Account names a separate account for those charges.

:77B: Regulatory Reporting carries what the authorities of the sending or receiving country require, three lines of 35.

The rules that decide whether it is valid

The formats are half of it. The other half is a set of network rules between fields, and these are where hand-built MT101s fail. Česká spořitelna's guide lists them; in plain words:

1. Ordering customer: A or B, never both, never neither. If every payment debits one account, put :50a: (F, G or H) in sequence A. If payments debit different accounts, put it in every sequence B instead.
2. Instructing party (:50a: C or L) and :52a: follow the same either-or rule, except that both may be absent.
3. An exchange rate needs its deal and its original amount. If :36: is present, :21F: and :33B: must be too, and :33B: is not allowed without :36:.
4. :33B: must be in a different currency from :32B:. USD1000, against CHF1200, is valid; USD against USD is not.
5. An intermediary needs a beneficiary bank. If :56a: is present, :57a: must be too.
6. One debit means one currency. With :21R: in sequence A, every :32B: in the instruction — across all chained messages — has to be in the same currency.

Then each bank adds its own on top. ANZ, for example, rejects a payment that looks like a duplicate of one in the last six calendar days: same funding account, beneficiary account and name, amount, currency and first line of remittance information. Česká spořitelna gives 10,000 characters as the maximum length of a message on the SWIFT network.

A small MT101, end to end

One payment from a single account, with the ordering customer in sequence A. The names, accounts and BICs are invented:

:20:2610230001
:28D:1/1
:50H:/NL91EXMP0417164300
EXAMPLE TRADING BV
KEIZERSGRACHT 1
NL/AMSTERDAM
:30:261026
:21:INV2026-0457
:32B:EUR12500,00
:57A:EXMPDEFFXXX
:59F:/DE89370400440532013000
1/SUPPLIER GMBH
2/HAUPTSTRASSE 1
3/DE/BERLIN
:70:INVOICE 2026-0457
:71A:SHA

Read it top to bottom and it is the whole idea of the format: what applies to the instruction, then what applies to each payment. Add a second payment and you repeat from :21: down, with a new reference.

What your bank does differently

Here is the part the standard does not tell you. All four banks are "MT101", and no two accept the same message.

• ANZ takes one sequence B per message — no batches — and only 1/1 in :28D:.
• mBank ignores :21R:, :51A:, :25:, :56A:, :77B:, :33B:, :25A: and :36: if you send them.
• Handelsbanken accepts :28D: and :50L: without acting on them, and does not use :51A: or :25:.
• Česká spořitelna documents the full set of network rules and the chaining logic.

So a file that one bank executes, another quietly ignores half of, and a third rejects. That is not a flaw in any of them; it is what "the standard" means in bank connectivity. The standard sets the outer limits, and each bank's implementation guide is the contract you actually build against. I would ask every bank for its MT101 guide before writing a line of mapping, and test with each one separately — the same advice that holds for pain.001, the XML message that is replacing MT101.

Related: MT101 vs MT103 vs MT202 for what each message is for, pain.001, field by field for the ISO 20022 successor, and MT940, tag by tag for the statement that tells you the payment went out.