SWIFT MTs / Learning brief
SWIFT MT101
Your notes
In simple terms / 01
What this means in plain language
Explains how corporates and banks use MT101 transfer requests in practice and how those instructions can lead to customer credit transfers.
An MT101 is a request for transfer, often used when a corporate asks a financial institution to initiate one or more payments from an account. It can support centralized treasury arrangements in which instructions are sent to an executing bank directly or through another financial institution. The MT101 does not itself prove that the beneficiary was paid; the bank must validate authority, account details, funds, controls, and execution conditions. Successful processing can lead to downstream customer credit-transfer messages and account reporting.
Complete lesson / 02
Understand the full idea, step by step
A company rarely pays its suppliers one screen-tap at a time. Its treasury team prepares a list — this supplier, that amount, on this date — and hands the whole list to the bank with an instruction: please make these payments from our account. On SWIFT, one form of that request is the MT101, and it is a request, not yet a payment.
MT101 — SWIFT Message Type 101, the request for transfer
An MT101 lets an authorised party — most often a corporate treasury — ask a financial institution to initiate one or more transfers from a stated account. It can travel straight to the account-servicing bank, or through another bank in a centralised treasury arrangement. Receiving an MT101 is the start of execution, not the end: the bank still authenticates the sender, checks the mandate, validates every item, applies financial-crime controls, and chooses a route for each accepted payment.
The request at a glance
- Who sends it
- An authorised party, typically a corporate treasury function.
- What it asks
- Initiate one or more transfers from a named account.
- Field 28D
- Message index and total — where this message sits in a set (for example 1/1).
- Field 21
- Transaction reference for each individual transfer item.
- Field 32B
- Currency and amount of each item — for one item here, EUR 12,400.00.
- What it is not
- Not a completed payment and not proof any beneficiary has been credited.
SWIFT MT — ILLUSTRATIVE, NON-PRODUCTION
A synthetic MT101 with a single item. Notice :28D: the message index, :21: the item's reference, :32B: the currency and amount, :50H: the ordering customer, and :59: the beneficiary. One MT101 can list several items; each carries its own field 21 so its fate can be tracked separately.
From request to payment
- CUSTOMER
Asha Traders' treasury sends the MT101 listing the transfers to make from its account.
- VALIDATION
Bank Alfa authenticates the sender and checks the mandate: is this party authorised to move money from this account, for this type of transfer?
- VALIDATION
Bank Alfa validates each item — beneficiary details, amount, execution date — and applies financial-crime controls to every one.
- MESSAGE
For each accepted item, Bank Alfa produces the downstream payment message it needs, such as an MT103 toward the beneficiary's bank.
- NOTIFICATION
Bank Alfa reports back status that distinguishes what it received from what it actually executed, item by item.
COMMON CONFUSION
“Every payment made in an internet or mobile banking app produces an MT101 behind the scenes.”
It does not. Most everyday app payments never generate an MT101 at all — the bank initiates them through its own channels and rails. The MT101 is a specific request-for-transfer instrument, used mainly where a corporate or a centralised treasury asks a bank to initiate payments under an agreed mandate. Treat it as one particular door into a bank, not the universal source of all payments.
WHAT IF — An MT101 contains several items and some are valid while others fail — an expired mandate, missing funds, or invalid beneficiary data.
What happens: The bank must decide whether to accept the good items and reject the rest, and then report that split clearly rather than passing or failing the whole request silently.
How it is handled: Maya's team ensures the status tells treasury exactly which items executed and which did not. If the split is unclear, treasury may resubmit the entire request and accidentally duplicate the payments that already succeeded — so precise, item-level reporting is the control that prevents double payments.
The MT101 was delivered successfully. Does that mean the suppliers have been paid?
No. Successful delivery means the request reached the bank, not that any beneficiary received funds. Each item still has to pass authentication, validation, and controls, and then generate and complete its own downstream payment. Support teams follow each item's execution status and route, and never read message acceptance as payment completion.
STRICTLY SPEAKING
Strictly speaking, an MT101 works only on top of an agreed authority: who may submit requests, from which accounts, and for which transaction types are governed by a mandate between the parties, not by the message alone. The same customer-to-bank initiation is expressed in ISO 20022 as pain.001. Details of authority, routing, and multi-bank arrangements are set out in the relevant agreements and standards rather than inferred from the message.
FOR NOW, REMEMBER
- An MT101 is a request for transfer: an authorised party asking a bank to initiate one or more payments from an account.
- Receiving it starts execution — authentication, mandate check, validation, controls, routing — it does not complete a payment.
- It is not what ordinary internet-banking payments produce; it is a specific corporate and treasury instrument.
- With multiple items, clear item-level status prevents treasury from resubmitting and duplicating payments that already succeeded.
TRY IT YOURSELF
Asha Traders sends an MT101 with five items. Bank Alfa's delivery status shows the message was received. What should the treasury conclude?
The MT101 was a customer asking its bank to pay. When those payments cross borders, the banks must also move the money between themselves — often with a cover payment. Next we meet the MT202 and its cover variant.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
MT101 requests execution rather than confirming final payment.
- 02
Corporate authorization and account servicing are central to processing.
- 03
Execution may create other payment and reporting messages.
Practical use cases / 04
Where you would use this
A corporate treasury team submits payments across accounts held with multiple banks.
A bank analyst maps MT101 fields into approval and execution workflows.
A tester verifies authorization, insufficient-funds, and partial-processing scenarios.
Worked example / 05
Put the idea into a real situation
Illustrative example: a group treasury center sends an MT101 asking Bank B to pay two suppliers from the subsidiary's account. Bank B authenticates the arrangement, validates each instruction, checks balances and compliance controls, then executes accepted items through suitable payment rails. One invalid beneficiary account may be rejected while another item proceeds. Account reports and payment statuses give treasury evidence of what the bank actually processed.
Evidence & review / 07
Evidence & review
SWIFT FIN MT101 request for transfer, used under an agreed mandate by corporates and centralised treasuries; ISO 20022 pain.001 is the customer-to-bank equivalent.
What this brief simplifies: Authentication and mandate handling are described at concept level; the exact authority model lives in the bilateral agreement. Field descriptions omit optional details covered in the SWIFT Standards documentation.
Sources for this brief3
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · MT 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.
- Scheme-specific rule
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · pain.001 as the ISO 20022 customer-to-bank initiation equivalent
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal · Asha Traders treasury scenario and item-level status framing
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.