MT101 Request for Transfer

When MT101 is used

A request for transfer is a payment order, not a payment. The Sender does not move any money: it asks the Receiver, which holds the ordering customer’s account, to debit that account and send the money on. The Receiver then executes each transaction itself, usually by booking an internal transfer or by sending an MT103 (or a domestic payment) to the beneficiary’s bank.

There are two common set-ups. In the relay model, a corporate sends its payment file to its main bank (the forwarding or sending bank), which turns each instruction into an MT101 and sends it over Swift to the bank abroad that holds the corporate’s account there. In the direct model, the corporate is itself connected to Swift and sends the MT101 straight to the account servicing bank. Either way, the debit happens at the Receiver, or at the account servicing institution named in field 52a when that is another bank.

The message has two sequences. Sequence A carries what applies to every transaction: the Sender’s reference, the chain index in 28D, the requested execution date and, when there is a single debit account, the ordering customer. Sequence B repeats once per payment, with its own reference, amount, beneficiary and charges code. A field that can appear in both sequences must appear in one or the other, never in both.

Field 50a appears twice in each sequence with different letter options. Options C and L name the instructing party: a party allowed to give orders on someone else’s account, such as a group treasury centre paying from a subsidiary’s account. Options F, G and H name the ordering customer, the account owner whose account is debited. The instructing party is only used when it is not the account owner.

Since 22 November 2025 the network treats the two set-ups differently. Between banks, an MT101 with more than one transaction is rejected by FIN, and a single-transaction MT101 is converted to pain.001 by Swift’s contingency processing; MT101s exchanged with corporates through SCORE (Swift for Corporates) continue as before for now. A bank relaying a corporate’s multi-payment file therefore splits it into single-transaction messages or moves to pain.001.

Using the MT101 requires registration in a Message User Group and bilateral agreements: between the account servicing bank and the account owner, between the sending bank and the account owner, and often between the two banks. Those agreements settle cut-off times, amount limits, charges, how rejects are reported and whether cancellations are accepted. Swift recommends reporting a rejected request with an MT195 (or another message that follows the payment reject guidelines) and handling cancellations with an MT192 answered by an MT196.

MT101 format: sequences and fields

Rules worth knowing

• C1 (D54): if field 36 is present in a transaction, field 21F must be present in the same transaction.
• C2 (D60): in each transaction, if 33B is present and the 32B amount is not zero, field 36 is mandatory; if 33B is present with a zero 32B, or 33B is absent, field 36 is not allowed.
• C3 (D61): the ordering customer (50a option F, G or H) must be in sequence A or in every occurrence of sequence B, never in both and never in neither. One debit account: sequence A. Several debit accounts: each sequence B.
• C4 (D62): the instructing party (50a option C or L) may be in sequence A or in one or more occurrences of sequence B, but not in both.
• C5 (D68): if 33B is present, its currency must differ from the currency in 32B of the same transaction.
• C6 (D64): field 52a may be in sequence A or in one or more occurrences of sequence B, but not in both. C7 (D65): if 56a is present, 57a must be present.
• C8 (D98): if 21R is present in sequence A, all 32B currencies in the message (and in all chained messages) must be the same.
• C9 (E54): if the 32B amount is zero and 23E contains EQUI, 33B is mandatory and 21F optional; if the amount is zero without EQUI, or 23E is absent, 33B and 21F are not allowed.
• 23E: a code may not repeat within one transaction except OTHR (E46), certain pairs cannot be combined, for example CHQB with URGP, RTGS or NETS, NETS with RTGS, or EQUI with any of the cash management codes (D67), and repeated codes follow a set order: instructions for the Receiver first (CMSW, CMTO, CMZB, INTC, REPA, CORT, URGP), then routing codes (NETS, RTGS), then instructions for a later party (CHQB, PHON), then OTHR.
• Chained messages (28D greater than 1/1) carry the same field 20 and an identical sequence A.

MT101 example

Northwind Trading LLC banks with ZagTrader Test Bank in Dubai (ZAGTAEADXXX) and holds a GBP account with BANKGB2LXXX in London. Through its Dubai bank it asks the London bank to pay GBP 48,250.00 from that account on 22 October 2026 to a UK supplier that banks with ZAGTGB2LXXX. Because this is a bank-to-bank relay, the message carries a single transaction: since November 2025 an interbank MT101 with several transactions is rejected by the network.

{1:F01ZAGTAEADAXXX0000000000}{2:I101BANKGB2LXXXXN}{3:{121:ad81391d-eca8-41ca-ae93-ffb5d9b7f7bb}}{4:
:20:ZT101261020A01
:28D:1/1
:50H:/GB42BANK40051587654321
NORTHWIND TRADING LLC
OFFICE 1204 BUSINESS BAY TOWER
DUBAI AE
:30:261022
:21:NW-PAY-000781
:32B:GBP48250,00
:57A:ZAGTGB2LXXX
:59:/GB38ZAGT40051512345678
ACME COMPONENTS LTD
1 HIGH STREET
LONDON
:70:/INV/2026-0457
:71A:SHA
-}

Line by line

The BICs, names, references, IBANs and UETR are made up; the IBANs carry valid check digits.

BANKGB2LXXX executes the transaction itself, typically by sending an MT103 or a domestic payment to the beneficiary’s bank, and debits Northwind’s account on the execution date. A corporate connected through SCORE could send the same request with several sequence B occurrences, for example one per supplier.

Common errors and rejects

1. Interbank MT101 with several transactions rejected

   Since 22 November 2025 the network rejects an MT101 between banks that carries more than one sequence B. Send one transaction per message, or relay the customer’s instructions as pain.001.

2. Ordering customer in both sequences or in neither (D61)

   The 50a ordering customer (option F, G or H) must be in sequence A or in every occurrence of sequence B. A frequent cause is a file generator that writes the debit account once in sequence A and again per transaction. Pick one place: sequence A for a single debit account, sequence B for several.

3. Instruction code problems in 23E (D66, D67, E46)

   Text after the code is only allowed with CMTO, PHON, OTHR and REPA; a code other than OTHR may not repeat; and some pairs cannot be combined, for example CHQB with URGP. Check the code list your bank supports too: many banks act only on a few codes (such as URGP or RTGS) and ignore the rest.

4. Zero amount or 33B/36/21F mismatch (E54, D60, D54)

   A zero amount in 32B is only valid for an EQUI transfer (with 33B) or a cash management sweep. When 33B is present with a non-zero amount, field 36 must be present, and with field 36 the FX deal reference 21F is required (NONREF if there is none).

5. Request refused by the account servicing bank

   An MT101 that passes network validation can still be rejected by the Receiver: no bilateral agreement for this Sender, an unknown debit account, insufficient funds, an amount over the agreed limit, or a missed cut-off. The Receiver usually reports it with an MT195 or MT199 quoting fields 20 and 21. Check the agreement and the debit account before resending.

6. Wrong beneficiary account or bank

   Not a network reject, but a common reason for returns: an IBAN with bad check digits or a 57a that does not hold the account. Validate IBANs and BICs before sending.

   How to fix it

MT101 in ISO 20022

The ISO 20022 equivalent is pain.001 (Customer Credit Transfer Initiation). The J.P. Morgan ISO 20022 mapping guide pairs "MT101 (relay)" with pain.001: in the relay scenario a forwarding bank passes the customer’s pain.001 on to the debtor’s bank, and pain.002 reports its status. Party mapping is direct: 50a becomes Debtor, 52a Debtor Agent, 56a Intermediary Agent, 57a Creditor Agent and 59a Creditor.

For interbank use the November 2025 end of coexistence applies. Swift’s CBPR+ roadmap (as reproduced in Citi’s September 2025 client webinar) and BNY’s October 2024 notice say that from 22 November 2025 an interbank MT101 with multiple transactions is rejected by FIN, while a single-transaction interbank MT101 goes through contingency conversion to pain.001. MT101s exchanged in SCORE between corporates and banks remain as they are for the time being.

Moving to pain.001 brings structured addresses, an ultimate debtor and creditor, purpose codes and a group header with a control sum, none of which the MT101 can carry. A pain.001 relayed between banks also gets a proper status report in pain.002 instead of a free-format reject.

Related messages

• MT103Single Customer Credit Transfer
• MT195Queries
• MT192Request for Cancellation
• MT196Answers
• MT199Free Format Message
• MT940Customer Statement Message
• MT942Interim Transaction Report
• pain.001Customer Credit Transfer Initiation
• pacs.008FI to FI Customer Credit Transfer

MT101 questions

What is an MT101 used for?

A company uses it to tell a bank that holds one of its accounts to make payments from that account. It is how a group treasury pays from accounts it holds with banks in other countries without logging into each bank’s own system.

What is the difference between MT101 and MT103?

The MT101 is a request: it asks the bank that holds the account to debit it and pay. The MT103 is the payment itself, sent from bank to bank to move the money. The bank that receives an MT101 usually executes it by sending an MT103.

What is an MT101 relay?

The corporate sends its instructions to its own bank, and that bank forwards them as an MT101 to the bank abroad that holds the corporate’s account. The forwarding bank is responsible for delivering the message, not for the payment, which the account servicing bank executes.

Where does the ordering customer go in an MT101, sequence A or B?

In sequence A when every payment is debited from the same account, in each occurrence of sequence B when the payments come from different accounts. It must never be in both (network rule C3).

What does 23E URGP mean in an MT101?

URGP marks a time-sensitive payment that the Receiver should execute in an expeditious manner. RTGS asks for settlement through a real-time gross settlement system if one is available. What each bank does with these codes is set in its agreement with the customer.

Can banks still send an MT101 after November 2025?

Only in part. Since 22 November 2025 an interbank MT101 with more than one transaction is rejected by the network, and a single-transaction one is converted to pain.001 by Swift’s contingency processing. MT101s between corporates and banks in SCORE continue for now.