MT101: the request for transfer
The MT101 lets a customer ask a bank to move money from its own account — a request for transfer, not the interbank payment itself.
L0 Explain simply
An everyday analogy: an MT101 is a signed letter you send to your bank saying "please pay these bills from my account". You are not moving the money yourself — you are asking the bank that actually holds your account to do it. Now imagine a large company that banks in ten countries and wants to send all such letters from one mailroom: it writes each letter to the right bank, and its own connection or a forwarding bank delivers them. The bank receiving the letter checks the signature and its standing instructions, then makes the actual payments by whatever means suit each one. The letter starts the process; it is not itself a payment, and it can still be declined.
L1 Core concepts
The MT101, request for transfer, is an instruction to move funds out of the sender's own account held at another institution. It is the MT world's payment-initiation message: typically a corporate treasury (or a bank acting on its behalf) asks an account servicing bank to debit the corporate's account and pay one or more beneficiaries. The receiving bank executes each request through whatever rail fits — an MT103 for a cross-border leg, a domestic transfer for a local one. One MT101 can carry several transactions against the same debit account and requested execution date. It remains a request rather than a completed payment: execution depends on the mandate in place, available funds, and the receiving bank's own checks.
L2 Practitioner view
Making MT101 work is mostly a matter of agreements set up long before the first message. The account servicing bank needs a signed mandate authorising the instructing party; the institutions involved need RMA authorisations; and everyone needs agreed formats, cut-offs, and a way to report rejects back, because the standard leaves more of that to bilateral agreement than newcomers expect. Common failure points are an instructing party the receiving bank does not recognise, a requested execution date that misses the local cut-off, and routing or charge details the receiving bank cannot honour. Many corporates now initiate payments with ISO 20022 pain.001 over host-to-host channels instead, so operations teams often support both, with MT101 persisting in established multi-bank cash management setups.
L3 Technical details
An MT101 is organised as two sequences in block 4. Sequence A, appearing once, carries message-level data: :20: sender's reference, :28D: message index and total so a large batch can span several messages, the instructing party and ordering customer in :50a:, optionally the account servicing institution in :52a:, and :30: the requested execution date. Sequence B repeats once per transaction: :21: transaction reference, :32B: currency and amount, routing fields such as :56a: and :57a:, :59a: beneficiary, :70: remittance information, and :71A: the charge option. The full field specifications, presence rules, and network-validated rules are in the SWIFT Standards MT Category 1 documentation on swift.com, which requires a SWIFT user account to access.
Sources & standards1
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Category 1 — MT101 Request for Transfer
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
Sources for this topic2
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Category 1 — MT101 Request for Transfer
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The mailroom analogy compresses the instructing-party arrangements; real setups are governed by bilateral agreements and mandates that vary widely between banks and are not reproduced here.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
Deepest material on this page: L3 — Technical details. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.