¿En qué se diferencian MT101 y pain.001?

El pago es el mismo y el envoltorio no. El MT101 es un mensaje de texto SWIFT con campos etiquetados en posiciones fijas; el pain.001 es un mensaje XML de ISO 20022 con un elemento con nombre para cada valor. El pain.001 declara cuántos apuntes lleva y cuánto suman, y se rechaza a sí mismo cuando eso no coincide con su contenido; el MT101 declara qué mensaje es de cuántos, y nada sobre totales. Los bancos aceptan uno, el otro o los dos, y la elección es del canal, no de tu lado.

¿Qué significan los campos de un MT101?

:20: es la referencia del emisor para todo el mensaje y :28D: es su sitio en la serie. :50H: es el cliente ordenante, dado como la cuenta de la que sale el dinero y el nombre que figura en ella. :30: es la fecha de ejecución solicitada. Después, por cada pago: :21: su propia referencia, :32B: la divisa y el importe, :57A: el banco del beneficiario, :59: el beneficiario y su cuenta, :70: para qué es, :71A: quién paga los gastos.

¿Qué quiere decir :71A: SHA en un MT101?

Que cada parte paga a su banco: el ordenante paga lo que le cobre el suyo y el beneficiario asume lo que le descuente el suyo. OUR carga todos los gastos al ordenante y BEN los saca del importe que recibe el beneficiario. Los ficheros ISO 20022 usan otro vocabulario para la misma elección — SLEV en una transferencia SEPA significa que cada parte paga a su banco, que es lo que dice SHA aquí.

¿Puede un MT101 llevar varios pagos?

Sí. La secuencia B se repite, una vez por apunte, y cada repetición lleva su referencia, su importe, su beneficiario y su opción de gastos. Lo que no lleva es un total, así que cuántos apuntes hay y cuánto suman es algo que tiene que sostener tu propio lado. Esa es la mitad que construimos desde la remesa en lugar de leerla del mensaje.

SWIFT · la petición

El MT101 pide la misma transferencia. Solo que dice menos de ella.

El MT101 es la petición de transferencia: el mensaje que un cliente manda a su banco para mover dinero, en la ortografía de etiquetas y posiciones que SWIFT usa desde mucho antes del XML. El mismo pago cabe en los dos, campo por campo. Lo que no cruza es la cabecera que el pain.001 le pone encima, y por eso los dos ficheros se comprueban en sitios distintos.

La cuenta que leen todas estas páginas

EUR

Lo publica: SWIFT
Qué lleva dentro: Una petición: la cuenta ordenante, el beneficiario, el importe y el día.
Cuenta: ES21 0049 0001 5323 4567 8901

Saldo final · 14 ago 2026EUR 2.990.901,67

La definición

Qué es exactamente un MT101

El Request for Transfer de SWIFT, y el fichero que muchos bancos siguen pidiendo a los clientes que ya tienen relación SWIFT con ellos.

El MT101 es el Request for Transfer de SWIFT. La secuencia A declara lo que comparte todo el mensaje: :20: la referencia del emisor, :28D: qué mensaje es de cuántos, :50H: el cliente ordenante con la cuenta de la que sale el dinero, :30: el día en que se pide la ejecución. La secuencia B se repite una vez por pago: :21: su propia referencia, :32B: la divisa y el importe, :57A: el banco del beneficiario, :59: el beneficiario con su cuenta, :70: el concepto, :71A: quién paga los gastos. Los importes llevan coma decimal y la divisa va delante de la cifra, dentro del mismo campo.

Quién lo envía: Lo mandas tú, y muchas veces a través de un banco que no es el que tiene la cuenta. El MT101 existe para que una relación pueda dar órdenes sobre otra, y por eso :50H: nombra la cuenta ordenante de forma explícita en lugar de dejarla al canal.
Cuándo llega: Al liberar la remesa, igual que sale un pain.001. Un banco que acepta los dos toma el MT101 donde ya hay relación SWIFT, y el pain.001 en todo lo demás.
Qué aspecto tiene: Texto plano, una etiqueta por línea y dos secuencias: un bloque general y un bloque de apunte que se repite. Una etiqueta puede llevar varios subcampos en posiciones fijas, y la letra que sigue al número es la opción — :50H: es el ordenante dado como cuenta más nombre, y :50F: es la misma parte dada de otra manera.

Cómo se llaman sus partes

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

El fichero

El mismo pago, en etiquetas

La orden de la página del pain.001, escrita como la quiere un banco que sigue pidiendo MT101. La cuenta, el beneficiario, el importe y el día son los mismos bytes; la diferencia está en la cabecera.

MT101Secuencia A, y después un bloque de apunte

: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.001La misma orden, en el mensaje ISO 20022

<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>

Dónde está cada dato dentro del fichero

Qué identifica al fichero: :20:
Qué mensaje es este, de cuántos: :28D:
De qué cuenta sale, y a nombre de quién: :50H:
El día en que se pide que se ejecute: :30:
La referencia que lo une a un pago: :21:
Cuánto, y en qué divisa: :32B:
Qué banco lo envía y cuál lo recibe: :57A:
A quién se paga, y en qué cuenta: :59:
Para qué dice el pago que es: :70:
Quién paga los gastos bancarios: :71A:

Qué falta

Lo que el MT101 no dice, y quién tiene que decirlo

Los dos ficheros llevan el pago. Solo uno de ellos lleva una afirmación sobre sí mismo.

Del MT101 sacamos la cuenta ordenante de :50H:, la fecha de ejecución solicitada de :30: y, por cada apunte, la referencia de :21:, la divisa y el importe de :32B:, el banco del beneficiario de :57A:, el beneficiario y su cuenta de :59:, el concepto de :70: y la opción de gastos de :71A:. Todo lo que un pain.001 declara en un elemento con nombre está aquí en una posición conocida dentro de una etiqueta numerada, y la lectura es exacta en los dos casos.

Lo que falta es el cuadre. :28D: cuenta mensajes, no dinero: dice que este es uno de uno, y no dice nada de lo que suman los apuntes que lleva debajo. Un pain.001 se rechaza a sí mismo cuando su importe de control está mal. Un MT101 no tiene con qué rechazarse, así que una remesa que perdió un pago entre el libro y el fichero sale con exactamente el mismo aspecto que una que no lo perdió. Construimos los dos ficheros desde la remesa liberada y cuadramos los dos contra ella, así que la comprobación existe con la ortografía que pida tu banco.

Por eso estas dos páginas son en realidad una sola. Elegir entre MT101 y pain.001 es una conversación con tu banco sobre su canal, no una decisión sobre con cuánto cuidado se cuentan tus pagos.

Después

Los dos extremos de la misma orden

El pain.001 es este mensaje en ISO 20022, y los dos salen de una sola remesa. SEPA es el reglamento que cumple una transferencia en euros lleve el fichero que lleve. El MT940 es donde aparece el cargo una vez que el banco lo ha ejecutado.

Formatos para leer al lado

Qué lo lee aquí

El mismo día escrito en cuatro formatos, uno junto a otro, está en Biblioteca de formatos

Preguntas sobre MT101

Lo que de verdad se busca sobre este mensaje

01¿En qué se diferencian MT101 y pain.001?: El pago es el mismo y el envoltorio no. El MT101 es un mensaje de texto SWIFT con campos etiquetados en posiciones fijas; el pain.001 es un mensaje XML de ISO 20022 con un elemento con nombre para cada valor. El pain.001 declara cuántos apuntes lleva y cuánto suman, y se rechaza a sí mismo cuando eso no coincide con su contenido; el MT101 declara qué mensaje es de cuántos, y nada sobre totales. Los bancos aceptan uno, el otro o los dos, y la elección es del canal, no de tu lado.
02¿Qué significan los campos de un MT101?: :20: es la referencia del emisor para todo el mensaje y :28D: es su sitio en la serie. :50H: es el cliente ordenante, dado como la cuenta de la que sale el dinero y el nombre que figura en ella. :30: es la fecha de ejecución solicitada. Después, por cada pago: :21: su propia referencia, :32B: la divisa y el importe, :57A: el banco del beneficiario, :59: el beneficiario y su cuenta, :70: para qué es, :71A: quién paga los gastos.
03¿Qué quiere decir :71A: SHA en un MT101?: Que cada parte paga a su banco: el ordenante paga lo que le cobre el suyo y el beneficiario asume lo que le descuente el suyo. OUR carga todos los gastos al ordenante y BEN los saca del importe que recibe el beneficiario. Los ficheros ISO 20022 usan otro vocabulario para la misma elección — SLEV en una transferencia SEPA significa que cada parte paga a su banco, que es lo que dice SHA aquí.
04¿Puede un MT101 llevar varios pagos?: Sí. La secuencia B se repite, una vez por apunte, y cada repetición lleva su referencia, su importe, su beneficiario y su opción de gastos. Lo que no lleva es un total, así que cuántos apuntes hay y cuánto suman es algo que tiene que sostener tu propio lado. Esa es la mitad que construimos desde la remesa en lugar de leerla del mensaje.

Mándanos un MT101 de los que acepta tu banco.

Una relación, una remesa. Te devolvemos los mismos pagos cuadrados contra el libro del que salieron, y la misma orden en la ortografía que prefiera tu banco.

Solicitar una demo Volver a la biblioteca de formatos

El canal no cambia: esto va del fichero, no de cómo viaja.