GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX
PAYMENTSSIGNAL

The interactive academy for the standards, messages, and rails that move money.

GET IN TOUCH
04 / SWIFT & MT10 MIN

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.

Contributor Shubham Mathure

NOT STARTED

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
  1. Official requirement

    Swift Standards MT (annual standards releases) ↗ — Swift · Category 1 — MT101 Request for Transfer

    Defines the MT message standards (including MT101, MT103, MT202/202 COV, and the MT9xx statement messages) exchanged over the Swift FIN network, maintained through annual standards releases. · Checked 2026-07-12

    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.

SEE THE PAYMENT MOVE

Corporate payment — legacy MT lifecycle — swimlane diagramThe legacy MT path from MT101 and MT103 through cancellation, investigations, returns, confirmations, and statements — with explicit no-equivalent and migration notes. The full step-by-step description follows this diagram as text.
MESSAGECLEARING OBLIGATIONSETTLEMENTPOSTING
Corporate payment — legacy MT lifecycle. A legacy teaching composite, not a recommendation to start new MT implementations. It joins corporate initiation, serial correspondent settlement, investigations, returns, and two account-reporting perspectives; bilateral services and migration dates vary. PLAY IT STEP BY STEP →
Read the steps as text
  1. 01Message
    Treasury sends a request for transferAsha Traders treasury → Bank Alfa (ordering bank) · MT101

    Asha Traders asks Bank Alfa to execute the supplier payment with an MT101. It is the legacy initiation request, not the bank-to-bank customer payment and not proof of execution.

  2. 02Processing
    Bank Alfa validates the MT101Bank Alfa (ordering bank)

    The bank checks the mandate, message fields, funds, cut-off, routing, and sanctions-screening results. A FIN ACK only confirms network acceptance; pain.002-style business status has no MT equivalent.

  3. 03Posting
    Bank Alfa debits Asha TradersBank Alfa (ordering bank)

    Once it accepts the request for execution, Bank Alfa books the customer debit under the account agreement before it releases the interbank MT103.

    • DR Asha Traders USD operating account — USD 125,000.00
  4. 04Message
    Treasury receives a debit confirmationBank Alfa (ordering bank) → Asha Traders treasury · MT900

    Where contracted, MT900 confirms one booked debit on the serviced account. It is an account-entry advice, not a beneficiary-credit confirmation and not a substitute for payment status.

  5. 05Message
    Bank Alfa sends the customer paymentBank Alfa (ordering bank) → Meridian Bank (correspondent) · MT103

    The MT103 carries the customer-payment instruction into the correspondent chain. In a serial route the instruction follows the account path used to settle the value.

  6. 06Processing
    Meridian validates and screens the MT103Meridian Bank (correspondent)

    The correspondent validates FIN fields, checks Bank Alfa's account, screens the parties and narrative data, and decides whether it can book and forward the payment.

  7. 07Settlement
    Meridian settles across its booksMeridian Bank (correspondent)

    Meridian debits Bank Alfa's USD account and credits Nordbank's USD account. The ledger movement is the settlement; the MT103 is the instruction.

    • DR Bank Alfa USD account at Meridian — USD 125,000.00
    • CR Nordbank USD account at Meridian — USD 125,000.00
  8. 08Message
    Nordbank receives a credit confirmationMeridian Bank (correspondent) → Nordbank (beneficiary bank) · MT910

    The MT910 advises Nordbank that its account at Meridian was credited. Nordbank uses it to match the incoming value against the customer-payment instruction.

  9. 09Message
    The MT103 reaches NordbankMeridian Bank (correspondent) → Nordbank (beneficiary bank) · MT103

    Meridian forwards the serial customer-payment message with the original references and party details so Nordbank can validate and apply the credit.

  10. 10Processing
    Nordbank validates and matches the paymentNordbank (beneficiary bank)

    Nordbank checks the beneficiary account, screens the payment, and matches the instruction to the credited nostro entry before paying its customer.

  11. 11Posting
    Nordbank credits the supplierNordbank (beneficiary bank)

    Nordbank books the credit to Northstar Components. A later cancellation is now a recovery request; the original credit cannot be erased by sending another message.

    • CR Northstar Components USD account — USD 125,000.00
  12. 12Message
    Treasury receives an intraday balance reportBank Alfa (ordering bank) → Asha Traders treasury · MT941

    Where contracted, MT941 reports balances without the full transaction list. It is one legacy predecessor of the broader camt.052 account report.

  13. 13Message
    Treasury receives intraday transactionsBank Alfa (ordering bank) → Asha Traders treasury · MT942

    MT942 reports account movements during the day. Treasury uses the original and account-servicer references to match the payment before the final statement arrives.

  14. 14Message
    The customer statement closes the dayBank Alfa (ordering bank) → Asha Traders treasury · MT940

    Bank Alfa sends the booked customer statement. Asha reconciles the MT940 entry to the original MT101 transaction and its own expected cash position.

  15. 15Message
    Bank Alfa reconciles its nostro statementMeridian Bank (correspondent) → Bank Alfa (ordering bank) · MT950

    Meridian's MT950 reports the entries on Bank Alfa's correspondent account. This bank-to-bank reconciliation is a different account perspective from the corporate's MT940.

MESSAGES INVOLVED

Sources for this topic2
  1. Official requirement

    Swift Standards MT (annual standards releases) ↗ — Swift · Category 1 — MT101 Request for Transfer

    Defines the MT message standards (including MT101, MT103, MT202/202 COV, and the MT9xx statement messages) exchanged over the Swift FIN network, maintained through annual standards releases. · Checked 2026-07-12

    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.

  2. Simplified educational illustration

    Payments Signal editorial teaching models — Payments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    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.