What is the difference between MT101 and pain.001?

The payment is the same and the packaging is not. MT101 is a SWIFT text message with tagged fields at fixed positions; pain.001 is an ISO 20022 XML message with a named element for every value. pain.001 states a transaction count and a control sum for the whole file and refuses itself when they disagree with its contents; MT101 states which message it is out of how many, and nothing about totals. Banks take one, the other, or both, and the choice belongs to the channel rather than to your side.

What do the fields of an MT101 mean?

:20: is the sender’s reference for the whole message and :28D: is its place in the series. :50H: is the ordering customer, given as the account the money leaves and the name on it. :30: is the requested execution date. Then, per payment: :21: its own reference, :32B: the currency and amount, :57A: the beneficiary’s bank, :59: the beneficiary and its account, :70: what it is for, :71A: who pays the charges.

What does :71A: SHA mean on an MT101?

Each side pays its own bank: the payer pays what its bank charges, the beneficiary absorbs what its own bank deducts. OUR puts every charge on the payer, and BEN takes them out of the amount the beneficiary receives. The ISO 20022 files use a different vocabulary for the same choice — SLEV on a SEPA credit transfer means each side pays its own bank, which is what SHA says here.

Can one MT101 carry several payments?

Yes. Sequence B repeats, once per transaction, and each repeat carries its own reference, amount, beneficiary and charge option. What it does not carry is a total, so how many transactions the file holds and what they come to is something your own side has to hold. That is the half we build from the run rather than read back out of the message.

SWIFT · the request

MT101 asks for the same transfer. It just says less about it.

MT101 is the request for transfer: the message a customer sends its bank to move money, in the tag-and-position spelling SWIFT has used since long before XML. The same payment fits in both, field for field. What does not carry across is the header a pain.001 puts on top of it, which is why the two files get checked in different places.

The account every page here reads

EUR

Published by: SWIFT
What it carries: One request: the ordering account, the beneficiary, the amount and the day.
Account: ES21 0049 0001 5323 4567 8901

Closing balance · Aug 14, 2026EUR 2,990,901.67

The definition

What an MT101 actually is

The SWIFT Request for Transfer, and the file plenty of banks still ask for from customers who already have a SWIFT relationship with them.

MT101 is the SWIFT Request for Transfer. Sequence A states what the whole message shares: :20: the sender’s reference, :28D: which message this is out of how many, :50H: the ordering customer with the account the money leaves, :30: the day execution is requested. Sequence B repeats once per payment: :21: its own reference, :32B: the currency and the amount, :57A: the beneficiary’s bank, :59: the beneficiary with its account, :70: what the payment is for, :71A: who pays the charges. Amounts use a comma for the decimal, and the currency sits in front of the figure inside the same field.

Who sends it: You do, and often through a bank that is not the one holding the account. MT101 exists so that one relationship can instruct another, which is why :50H: names the ordering account explicitly instead of leaving it to the channel.
When it arrives: When the run is released, exactly as a pain.001 goes. A bank that takes both takes MT101 where a SWIFT relationship already exists, and pain.001 everywhere else.
What it looks like: Plain text, one tag to a line, two sequences: a general block and a transaction block that repeats. A tag can carry several subfields at fixed positions, and the letter after the number is the option — :50H: is the ordering customer given as an account plus a name, and :50F: is the same party given another way.

What its parts are called

MT101 :21:
MT101 :32B:
MT101 :28D:
MT101 :71A:
MT101 vs pain.001

The file

The same payment, in tags

The instruction from the pain.001 page, written the way a bank that still asks for MT101 wants it. The account, the beneficiary, the amount and the day are the same bytes; the header is the difference.

MT101Sequence A, then one transaction block

:20:MSG26081700041
:28D:1/1
:50H:/ES2100490001532345678901
SOCIEDAD MATRIZ SA
:30:260817
:21:PO-2026-8841
:32B:EUR28450,00
:57A:CAIXESBBXXX
:59:/ES6621000418401234567891
NORTE SUMINISTROS SL
:70:SUMINISTRO AGOSTO
:71A:SHA

pain.001The same instruction, in the ISO 20022 message

<CstmrCdtTrfInitn>
  <GrpHdr>
    <MsgId>MSG26081700041</MsgId>
    <CreDtTm>2026-08-14T00:00:00</CreDtTm>
    <NbOfTxs>1</NbOfTxs>
    <CtrlSum>28450.00</CtrlSum>
    <InitgPty><Nm>SOCIEDAD MATRIZ SA</Nm></InitgPty>
  </GrpHdr>
  <PmtInf>
    <PmtInfId>MSG26081700041-01</PmtInfId>
    <PmtMtd>TRF</PmtMtd>
    <PmtTpInf><SvcLvl><Cd>SEPA</Cd></SvcLvl></PmtTpInf>
    <ReqdExctnDt><Dt>2026-08-17</Dt></ReqdExctnDt>
    <Dbtr><Nm>SOCIEDAD MATRIZ SA</Nm></Dbtr>
    <DbtrAcct><Id><IBAN>ES2100490001532345678901</IBAN></Id></DbtrAcct>
    <DbtrAgt><FinInstnId><BICFI>BSCHESMMXXX</BICFI></FinInstnId></DbtrAgt>
    <ChrgBr>SLEV</ChrgBr>
    <CdtTrfTxInf>
      <PmtId><EndToEndId>PO-2026-8841</EndToEndId></PmtId>
      <Amt><InstdAmt Ccy="EUR">28450.00</InstdAmt></Amt>
      <CdtrAgt><FinInstnId><BICFI>CAIXESBBXXX</BICFI></FinInstnId></CdtrAgt>
      <Cdtr><Nm>NORTE SUMINISTROS SL</Nm></Cdtr>
      <CdtrAcct><Id><IBAN>ES6621000418401234567891</IBAN></Id></CdtrAcct>
      <RmtInf><Ustrd>SUMINISTRO AGOSTO</Ustrd></RmtInf>
    </CdtTrfTxInf>
  </PmtInf>
</CstmrCdtTrfInitn>

Where each fact lives in this file

What identifies the file itself: :20:
Which message this is, out of how many: :28D:
Which account it leaves, and in whose name: :50H:
The day execution is asked for: :30:
The reference that ties it to a payment: :21:
How much, and in which currency: :32B:
Which bank sends it, and which one receives it: :57A:
Who is being paid, and into which account: :59:
What the payment says it is for: :70:
Who pays the bank charges: :71A:

What is missing

What MT101 does not say, and who has to say it

Both files carry the payment. Only one of them carries a statement about itself.

Out of MT101 we take the ordering account from :50H:, the requested execution date from :30:, and then, per transaction, the reference on :21:, the currency and amount on :32B:, the beneficiary’s bank on :57A:, the beneficiary and its account on :59:, the remittance information on :70: and the charge option on :71A:. Everything a pain.001 states in a named element sits here at a known position inside a numbered tag, and the reading is exact either way.

What is missing is the footing. :28D: counts messages, not money: it says this is one message out of one, and says nothing about what the transactions under it come to. A pain.001 refuses itself when its control sum is wrong. An MT101 has nothing to refuse itself with, so a run that lost a payment between the ledger and the file leaves looking exactly like a run that did not. We build both files from the released run and foot both against it, so the check exists in whichever spelling your bank asks for.

That is why these two pages are really one page. Choosing between MT101 and pain.001 is a conversation with your bank about its channel, not a decision about how carefully your payments get counted.

Both ends of the same instruction

pain.001 is this message in ISO 20022, and the two come out of one run. SEPA is the rulebook a euro transfer satisfies whichever file carries it. MT940 is where the debit turns up once the bank has executed it.

Formats to read beside it

What reads it here

The same day written in four formats, side by side, is on Format library

Asked about MT101

The questions a payments team actually types

01What is the difference between MT101 and pain.001?: The payment is the same and the packaging is not. MT101 is a SWIFT text message with tagged fields at fixed positions; pain.001 is an ISO 20022 XML message with a named element for every value. pain.001 states a transaction count and a control sum for the whole file and refuses itself when they disagree with its contents; MT101 states which message it is out of how many, and nothing about totals. Banks take one, the other, or both, and the choice belongs to the channel rather than to your side.
02What do the fields of an MT101 mean?: :20: is the sender’s reference for the whole message and :28D: is its place in the series. :50H: is the ordering customer, given as the account the money leaves and the name on it. :30: is the requested execution date. Then, per payment: :21: its own reference, :32B: the currency and amount, :57A: the beneficiary’s bank, :59: the beneficiary and its account, :70: what it is for, :71A: who pays the charges.
03What does :71A: SHA mean on an MT101?: Each side pays its own bank: the payer pays what its bank charges, the beneficiary absorbs what its own bank deducts. OUR puts every charge on the payer, and BEN takes them out of the amount the beneficiary receives. The ISO 20022 files use a different vocabulary for the same choice — SLEV on a SEPA credit transfer means each side pays its own bank, which is what SHA says here.
04Can one MT101 carry several payments?: Yes. Sequence B repeats, once per transaction, and each repeat carries its own reference, amount, beneficiary and charge option. What it does not carry is a total, so how many transactions the file holds and what they come to is something your own side has to hold. That is the half we build from the run rather than read back out of the message.

Send us an MT101 your bank takes.

One relationship, one run. You get back the same payments footed against the ledger they came from, and the same instruction in whichever spelling your bank prefers.

Request a demo Back to the format library

The channel does not change: this is about the file, not about how it travels.