ISO 20022 · la orden
El pain.001 pide. Lo primero que mira el banco es que cuadre.
El pain.001 es el fichero que manda tu tesorería cuando quiere que se mueva el dinero: una cabecera de mensaje, un bloque de pago por cuenta ordenante y un apunte por beneficiario. Todo lo que va debajo de esa cabecera tiene que sumar exactamente el importe de control que declara, y un fichero que no cuadra se rechaza entero, antes de que nadie mire los pagos que lleva dentro.
La cuenta que leen todas estas páginas
EUR- Lo publica
- ISO 20022
- Qué lleva dentro
- Una orden: quién paga, a quién, cuánto y para qué 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 pain.001
El mensaje ISO 20022 con el que un cliente pide a su banco que ejecute transferencias — el sentido contrario del extracto que las informa a la mañana siguiente.
El pain.001 es el mensaje ISO 20022 CustomerCreditTransferInitiation. GrpHdr identifica el fichero y declara cuántos apuntes lleva y cuánto suman. Un bloque PmtInf reúne lo que comparten los pagos que van debajo: la cuenta ordenante, el banco que la lleva, la fecha de ejecución solicitada y quién paga los gastos. Dentro, un CdtTrfTxInf por pago nombra al beneficiario, su cuenta, el importe y la referencia que el ordenante quiere recuperar. Los importes llevan punto decimal y la divisa va como atributo del propio importe, no en un campo aparte.
- Quién lo envía
- Lo mandas tú. Un pain.001 va de tu lado al banco, que es justo el sentido contrario de todas las páginas de extracto de esta biblioteca. Sale por el canal que ese banco ya tenga montado — EBICS, host to host, SWIFT, su propia API — y el canal es una decisión distinta del mensaje que viaja dentro.
- Cuándo llega
- Cuando están las aprobaciones. El fichero se construye al liberar la remesa, y su fecha de ejecución solicitada dice qué día pides tú, no qué día lo contabiliza el banco. Eso lo decide él, y vuelve en el extracto.
- Qué aspecto tiene
- XML anidado, y cada valor va en un elemento con nombre en lugar de en una posición. No hay que contar caracteres ni leer por desplazamiento, y por eso un validador puede rechazar un fichero por un solo elemento mal puesto antes de que lo abra nadie.
Cómo se llaman sus partes
- pain.001 CtrlSum
- pain.001 NbOfTxs
- pain.001 EndToEndId
- pain.001 ChrgBr SLEV
- pain.001 vs MT101
El fichero
Un pago, tal y como sale
La orden que esta biblioteca manda el mismo día en que cierra su extracto: una transferencia desde la cuenta que describen todas las demás páginas, para ejecutar el siguiente día hábil.
<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
- <GrpHdr><MsgId>
- Lo que el fichero dice que suma
- <GrpHdr><NbOfTxs> · <GrpHdr><CtrlSum>
- De qué cuenta sale, y a nombre de quién
- <Dbtr><Nm> · <DbtrAcct><Id><IBAN>
- A quién se paga, y en qué cuenta
- <Cdtr><Nm> · <CdtrAcct><Id><IBAN>
- Qué banco lo envía y cuál lo recibe
- <DbtrAgt><FinInstnId><BICFI> · <CdtrAgt><FinInstnId><BICFI>
- Cuánto, y en qué divisa
- <Amt><InstdAmt Ccy="EUR">
- El día en que se pide que se ejecute
- <PmtInf><ReqdExctnDt><Dt>
- La referencia que lo une a un pago
- <PmtId><EndToEndId>
- Quién paga los gastos bancarios
- <PmtInf><ChrgBr>
- Para qué dice el pago que es
- <RmtInf><Ustrd>
Qué se comprueba
Qué mira el banco antes de leer los pagos
Un pain.001 se acepta entero o se rechaza entero. Lo que decide eso son un puñado de elementos que tienen que estar de acuerdo entre sí.
La cabecera declara un número de apuntes y un total, y las dos cosas son afirmaciones sobre lo que hay debajo. NbOfTxs tiene que ser cuántos bloques CdtTrfTxInf lleva el fichero de verdad, y CtrlSum tiene que ser lo que suman sus InstdAmt, al céntimo. Los dos se construyen a partir de los pagos de la remesa en lugar de llevarse al lado, así que un fichero no puede salir con una cabecera que contradiga su propio contenido. Todo el importe viaja en unidades mínimas exactas: no se redondea nada ni al entrar ni al salir.
El resto ya es el criterio del banco. Un pain.001 que valida todavía puede rechazarse por una cuenta de beneficiario que ese banco no acepta, por una divisa que la cuenta ordenante no tiene o por una fecha que no es hábil allí donde va el dinero. Esa respuesta vuelve en un pain.002 y aterriza sobre la misma orden en lugar de en el correo de alguien: la referencia que pusiste en EndToEndId es la que vuelve, y el cargo aparece otra vez en el extracto de la mañana siguiente con ella.
Ese es el trato con un fichero de órdenes. Se rechaza por aritmética antes de que nadie lo juzgue por nada más, así que la aritmética es la parte que hay que construir, no la que hay que repasar.
Después
De dónde sale este fichero y adónde va
El MT101 es la misma orden en la ortografía antigua, y aquí las dos salen de una sola remesa. SEPA no es otro fichero: es el conjunto de reglas que este tiene que cumplir para que un banco del área lo ejecute. El CAMT.053 es donde aparece el cargo a la mañana siguiente.
Formatos para leer al lado
El mismo día escrito en cuatro formatos, uno junto a otro, está en Biblioteca de formatos
Preguntas sobre pain.001
Lo que de verdad se busca sobre este fichero
- 01¿Qué es el CtrlSum de un pain.001?
- El total de todos los InstdAmt del fichero, declarado una vez en la cabecera de grupo. Es una afirmación sobre los apuntes que van debajo, así que se comprueba antes que nada: un importe de control que se separa un céntimo de los pagos que cubre hace que se rechace el fichero entero, y no sale ninguno de ellos. NbOfTxs es la misma afirmación sobre el número de apuntes. Los dos se construyen desde la remesa en lugar de guardarse al lado.
- 02¿En qué se diferencian pain.001 y pain.002?
- Uno pide y el otro contesta. El pain.001 es la orden de transferencia que manda tu lado; el pain.002 es el informe de estado que devuelve el banco, con un estado por apunte y un código de motivo allí donde algo se ha rechazado. Los dos se atan por las referencias del fichero que enviaste — la identificación del mensaje y la referencia extremo a extremo — y por eso vale la pena poner valores de verdad en esos dos campos.
- 03¿Dónde va la referencia extremo a extremo en un pain.001?
- Dentro de PmtId, en cada apunte, como EndToEndId. El banco la pasa sin tocarla: vuelve en el informe de estado, aparece en el apunte del cargo en el extracto y, donde el banco del beneficiario lo soporta, le llega también a él. Es el único campo del fichero que ata de verdad una orden con el apunte que la liquida, así que conviene ponerle algo que tu propio libro reconozca.
- 04¿Qué significa ChrgBr SLEV?
- Que los gastos siguen el nivel de servicio del pago. En una transferencia SEPA eso quiere decir que cada parte paga a su banco, y es el único valor que admite el esquema. Los demás códigos viven fuera de SEPA: DEBT carga todos los gastos al ordenante, CRED al beneficiario y SHAR los reparte.
- 05¿Qué versión de pain.001 hay que mandar?
- La que publique cada banco en su guía, y en un grupo rara vez coinciden. El mensaje tiene varias versiones en circulación, y los bancos no se ponen de acuerdo en qué elementos exigen, cuáles ignoran y cuánto texto aceptan en cada uno. Fijamos un perfil de formato a la versión que cada banco acepta de verdad, así que un grupo que manda tres versiones no tiene que unificar sus bancos antes de poder pagarles.
Mándanos un fichero de los que acepta tu banco.
Una cuenta, una remesa. Te devolvemos el mismo fichero construido desde tu propio libro, cuadrado con los pagos que lo generaron y con las referencias que ya usan tus sistemas.
Para esto no hay que abrir ningún canal: con el fichero basta.