MT101 — Request for Transfer
Requests the receiving bank to debit an account it services and move the funds onward. It is a payment initiation message, not an interbank settlement message: corporates use it to instruct their banks from a central treasury, and banks relay it to each other on a customer's behalf. One MT101 can carry many transactions against the same debit account and execution date.
DIRECTION: Sent by a corporate over SWIFT for Corporates, or by a bank acting as a relay, to the financial institution that services the account to be debited and will execute the transfers.
WHO IS INVOLVED
- Instructing party / ordering customerIssues the request — typically a corporate treasury instructing debits across its accounts.
- Forwarding (relay) institutionWhen the customer instructs through its own bank, that bank relays the MT101 unchanged to the executing bank.
- Executing (account-servicing) institutionValidates the request, debits the customer's account, and initiates the actual payments toward each beneficiary.
- BeneficiaryReceives the funds through whatever onward rail the executing bank uses.
KEY FIELDS
Curated subset of the fields practitioners meet first — the official SWIFT Standards MT documentation is the complete specification.
| FIELD | NAME | PRESENCE | WHAT IT MEANS |
|---|---|---|---|
:20: | Sender's Reference (sequence A) | MANDATORYSWIFT Standards MT | The sender's own reference for the whole request — the number quoted in any later query about it.One reference covers the full message, which may contain many transactions; individual transactions are identified by field 21 in each sequence B.⚠ Reusing references defeats duplicate detection and muddies investigation trails. |
:28D: | Message Index / Total (sequence A) | MANDATORYSWIFT Standards MT | Says which message this is in a set, such as 1 of 3, when a large request is split across several MT101s.All messages in a chained set share the sender's reference and must arrive as a complete set before execution.⚠ Broken chaining — a missing index or inconsistent totals — leaves the executing bank with a partial batch it cannot safely process. |
:30: | Requested Execution Date (sequence A) | MANDATORYSWIFT Standards MT | The date the customer wants the executing bank to start processing all the transactions in the message.It is a requested date: cut-off times, funding, and the executing bank's calendar decide the actual debit and value dates. |
:50a: | Ordering Customer | CONDITIONALSWIFT Standards MT | The account owner whose account will be debited.The standard allows it once in sequence A (covering every transaction) or in each sequence B (transaction by transaction), but it must be present in exactly one of those places — hence conditional.⚠ Supplying it in both sequences, or in neither, fails network validation. |
:21: | Transaction Reference (sequence B) | MANDATORYSWIFT Standards MT | A unique reference for each individual transaction inside the request.This is the reference the executing bank will echo in status advice and that reconciliation teams match against the resulting debits. |
:32B: | Currency / Transaction Amount (sequence B) | MANDATORYSWIFT Standards MT | How much to pay, and in which currency, for this transaction.Amounts use a comma as the decimal separator, and the currency must be one the debit account and service agreement actually support.⚠ A currency outside the account agreement is a common rejection reason at the executing bank. |
:57a: | Account With Institution (sequence B) | CONDITIONALSWIFT Standards MT | The bank that holds the beneficiary's account.Conditional per the message's usage rules; a BIC (option A) gives the executing bank the best chance of straight-through routing. Where routing is ambiguous, execution slows or fails.⚠ Free-text bank names instead of BICs push transactions into manual repair. |
:59a: | Beneficiary (sequence B) | MANDATORYSWIFT Standards MT | Who should receive this transaction, with their account.Account, name, and address quality here flows straight into the onward payment the executing bank creates — errors reappear downstream as returns. |
:71A: | Details of Charges (sequence B) | MANDATORYSWIFT Standards MT | Who pays the banks' fees for this transaction: OUR (sender pays all), SHA (shared), or BEN (beneficiary pays).The choice constrains the charging of the onward payment; some corridors restrict BEN by regulation or scheme rule. |
FIELD BY FIELD — FULL STRUCTURE
The whole MT101 laid out as a parent-child tree: every field in its nesting, with a sample value and what it means. Expand a branch to drill in. Values are fictional (SYNTHETIC / TRAINING ONLY); this is a curated practitioner view, not the full schema.
Block 1F01DEMODEFFAXXX0000000000MandatoryBasic header — identifies the sender and the session (application id, service id, the sender's logical-terminal address built on its BIC, session and sequence numbers).Block 2I101DEMODEFFXXXXNMandatoryApplication header — the message type, the counterparty address, whether it is input or output, and the priority.Block 3—User header — optional service data; most importantly field 121, the UETR.108DEMO-ONLYMessage User Reference (MUR) — a sender's reference in the user header the sender can reconcile against.
Block 4—MandatoryText — the business content, as numbered :tag: fields. The only block whose shape changes by message type.:20:DEMO-REQ-20260712MandatoryThe sender's own reference for the whole request — the number quoted in any later query about it.- Use case
- One reference covers the full message, which may contain many transactions; individual transactions are identified by field 21 in each sequence B.
- Example
:20:DEMO20260712- Watch out
- Reusing references defeats duplicate detection and muddies investigation trails.
:28D:1/1MandatorySays which message this is in a set, such as 1 of 3, when a large request is split across several MT101s.- Use case
- All messages in a chained set share the sender's reference and must arrive as a complete set before execution.
- Watch out
- Broken chaining — a missing index or inconsistent totals — leaves the executing bank with a partial batch it cannot safely process.
:50H:/DE02120300000000202051 ⏎ DEMO TRADING LTD ⏎ 9 EXAMPLE QUAY ⏎ FRANKFURT DEConditionalThe account owner whose account will be debited.- Use case
- The standard allows it once in sequence A (covering every transaction) or in each sequence B (transaction by transaction), but it must be present in exactly one of those places — hence conditional.
- Watch out
- Supplying it in both sequences, or in neither, fails network validation.
:30:260713MandatoryThe date the customer wants the executing bank to start processing all the transactions in the message.- Use case
- It is a requested date: cut-off times, funding, and the executing bank's calendar decide the actual debit and value dates.
:21:DEMO-E2E-001MandatoryA unique reference for each individual transaction inside the request.- Use case
- This is the reference the executing bank will echo in status advice and that reconciliation teams match against the resulting debits.
:32B:EUR1250,00MandatoryHow much to pay, and in which currency, for this transaction.- Use case
- Amounts use a comma as the decimal separator, and the currency must be one the debit account and service agreement actually support.
- Watch out
- A currency outside the account agreement is a common rejection reason at the executing bank.
:57A:DEMOGB2LXXXConditionalThe bank that holds the beneficiary's account.- Use case
- Conditional per the message's usage rules; a BIC (option A) gives the executing bank the best chance of straight-through routing. Where routing is ambiguous, execution slows or fails.
- Watch out
- Free-text bank names instead of BICs push transactions into manual repair.
:59:/GB33BUKB20201555555555 ⏎ EXAMPLE SUPPLIES LTD ⏎ 2 TEST ROAD ⏎ LONDON GBMandatoryWho should receive this transaction, with their account.- Use case
- Account, name, and address quality here flows straight into the onward payment the executing bank creates — errors reappear downstream as returns.
:70:DEMO INVOICE 1001Remittance Information — details passed to the beneficiary so they can reconcile the payment.:71A:SHAMandatoryWho pays the banks' fees for this transaction: OUR (sender pays all), SHA (shared), or BEN (beneficiary pays).- Use case
- The choice constrains the charging of the onward payment; some corridors restrict BEN by regulation or scheme rule.
- Example
:71A:SHA
Sources for the field structure4
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain/pacs/camt message-definition elements
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · cross-border agent chain and structured-data usage
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · FIN block structure
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: One-line plain-language descriptions of the commonly-populated elements — a practitioner view, not the authoritative ISO 20022 / MT schema, which defines many more optional elements.
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.
COMMON ERRORS
- Ordering customer supplied in both sequence A and sequence B, or in neither.Consequence: The message fails network validation and is rejected before it reaches business processing.Avoid it: Decide per message whether one debit party covers all transactions (sequence A) or varies per transaction (sequence B), and populate exactly one.
- Broken message chaining when a large request is split (inconsistent 28D index/total).Consequence: The executing bank holds an incomplete set; transactions execute late or not at all.Avoid it: Generate the index and total from the same batching routine and reconcile acknowledgements per chained message.
- Treating a sent MT101 as a completed payment.Consequence: Treasury dashboards show money as moved while the executing bank may have rejected or queued individual transactions, creating reconciliation gaps.Avoid it: Track per-transaction status from the executing bank and reconcile debits against field 21 references, not against message dispatch.
- Transaction currency not supported by the debit account or service agreement.Consequence: Rejection by the executing bank, often hours later and per transaction rather than per message.Avoid it: Validate currency and account pairs against the bank's service agreement before release.
USAGE CONTEXTS
- Corporate treasury over SWIFT for CorporatesCorporates on the SCORE model continue to exchange MT101s with their banks. Migration to the ISO 20022 pain.001 in this space is commercially driven and proceeds bank by bank rather than to a single network deadline.
- Bank-to-bank relayFor MT101s relayed between banks over the FIN network, Swift has communicated a November 2026 end of coexistence, with pain.001 as the successor. Confirm the current state with Swift and your correspondents before relying on either format.
- Initiation, not settlementAn accepted MT101 does not itself move money. The executing bank debits the account and creates onward interbank payments — historically MT103s, today typically pacs.008 — each with its own tracking, UETR, and exception handling.
Sources for this reference2
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Category 1 — MT 101
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: Field list curated for learning; national and bilateral usage rules omitted.
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.