Migración a ISO 20022 en España: qué está cambiando (y qué se acaba de aplazar)
La migración a ISO 20022 es el mayor cambio de la mensajería de pagos en una generación y, para los equipos financieros españoles, la situación acaba de volverse más confusa. El plazo, para dejar de aceptar direcciones no estructuradas en los mensajes de pago, fijado inicialmente para noviembre de 2026, ha sido aplazado tanto por Swift como por el European Payments Council (EPC), organismo que fija el calendario SEPA.
Para las empresas españolas, los pagos SEPA (nacionales y dentro de la zona euro) y los pagos internacionales por Swift siguen calendarios distintos. Tratarlos como si tuvieran un único plazo es el error más habitual que vemos cometer a los equipos financieros.
¿Qué es la migración a ISO 20022?
La migración a ISO 20022 es, para el sector bancario mundial, el paso del antiguo estándar de mensajería de pagos MT a ISO 20022, un formato estructurado y basado en XML que transporta datos de pago mucho más ricos, entre ellos direcciones desglosadas en campos independientes, en lugar de texto libre.
Los bancos de todo el mundo llevan tiempo sustituyendo MT por ISO 20022, tanto para las instrucciones de pago como para los informes de cuentas. El cambio práctico se nota primero en cómo se formatean las direcciones del beneficiario y del destinatario: una única línea de texto libre ya no es suficiente, las direcciones deben desglosarse en elementos estructurados (número de edificio, calle, ciudad, país) o, como mínimo, seguir un formato híbrido en el que la ciudad y el país figuren en sus propios campos.
Por qué está ocurriendo esto
Las direcciones estructuradas mejoran la calidad de los datos. Permiten a los bancos filtrar los pagos por motivos de sanciones y delincuencia financiera con mayor fiabilidad, gestionarlos con menos intervenciones manuales y reducir el tiempo de investigación cuando algo falla. Es un movimiento impulsado por todo el sector, liderado por los bancos y los esquemas de pago y no por un único regulador, lo que explica en parte por qué el calendario varía tanto según la red y el sistema de pago.
El calendario de Swift y del EPC/SEPA para la migración a ISO 20022
Qué está confirmado y qué se ha aplazado
La migración principal de mensajería de MT a ISO 20022 de Swift para los pagos internacionales (CBPR+) se completó en noviembre de 2025. En esa fase todavía se toleraban las direcciones no estructuradas. El siguiente hito, un requisito obligatorio de direcciones postales totalmente estructuradas o híbridas, estaba previsto para noviembre de 2026.
Esta es la actualización más importante para quien siga este tema: el requisito de dirección estructurada que debía entrar en vigor en noviembre de 2026 se ha aplazado oficialmente y todavía no se ha confirmado una nueva fecha.
El 27 de agosto de 2026, Swift anunció que ampliaba el plazo tras las peticiones del sector para disponer de más tiempo y confirmará un nuevo calendario, como muy tarde, en diciembre de 2026.
El European Payments Council (EPC), que fija el calendario equivalente para las transferencias y adeudos SEPA, siguió el mismo patrón poco después. Su Payment Scheme Management Board también aplazó ese plazo el 9 de septiembre de 2026, con una nueva fecha prevista para su reunión de octubre de 2026.
El requisito, fijado originalmente para el 15 de noviembre de 2026, para alinearse con la fecha de Swift, se aplica a los cinco reglamentos de esquemas SEPA (SEPA Credit Transfer, SEPA Instant Credit Transfer, SEPA Direct Debit Core y B2B, y One-Leg Out Instant Credit Transfer).
Conviene precisar un punto importante: lo que se ha aplazado es el requisito de dirección, no la ISO 20022 en sí.
La migración de mensajería ISO 20022 subyacente (el paso de los mensajes MT a los mensajes MX basados en XML, pacs.008, pain.001, etc.) ya está en marcha y no va a detenerse. Lo que se ha retrasado es concretamente la norma que habría rechazado los mensajes que todavía llevaran únicamente una <AdrLine> en texto libre en lugar de campos estructurados como <TwnNm> (nombre de la ciudad) y <Ctry> (país). Así que, para una empresa española, tanto los pagos SEPA como los pagos internacionales por Swift están en la misma situación: la dirección está confirmada, la fecha no.
SEPA y Swift: dos calendarios distintos para las empresas españolas
Sistema de pago | Ámbito | Estado de ISO 20022 |
|---|---|---|
SEPA (transferencias y adeudos domiciliados) | Pagos nacionales en España y pagos dentro de la zona euro | El requisito de dirección estructurada, fijado originalmente para el 15 de noviembre de 2026, fue aplazado por el Payment Scheme Management Board del EPC el 9 de septiembre de 2026. Nueva fecha prevista en la reunión de octubre de 2026. |
Swift transfronterizo (CBPR+) | Pagos internacionales enviados o recibidos fuera de la zona SEPA | El requisito de dirección estructurada, fijado originalmente para noviembre de 2026, es el que Swift aplazó el 27 de agosto de 2026.
Se espera una fecha revisada antes de diciembre de 2026.
Es el flujo que más de cerca deberían seguir las empresas españolas con actividad internacional fuera de la zona euro. |
Si tus pagos son principalmente transferencias SEPA, nacionales o dentro de la zona euro, la presión se ha reducido considerablemente por ahora. Si envías o recibes pagos internacionales con regularidad fuera de la zona SEPA a través de Swift, esto sigue muy vigente, solo que ya no está fijado a una fecha concreta de noviembre de 2026.
Qué revisar por tu parte
Sea cual sea tu combinación de pagos, puedes anticiparte a los cambios con algunas comprobaciones:
Revisa el formato de tus archivos. Confirma que tu ERP o tu sistema contable generan los archivos de pago que tu banco aceptará, una vez las direcciones estructuradas o híbridas sean obligatorias.
Revisa los datos de tus beneficiarios. Cada ficha de beneficiario debe tener la ciudad y el país como campos independientes, no combinados en una sola línea de dirección.
Pregunta directamente a tu banco. Los plazos varían según el banco y el sistema de pago; algunos bancos pueden mantener sus propios calendarios internos anteriores, independientemente del calendario general del sector.
Sigue haciendo pruebas. Cuando tu banco ofrezca una opción de validación, envía ya un pago de muestra con una dirección estructurada.
Qué significa esto si pagas a través de Agicap
La respuesta depende de cómo lleguen tus pagos a Agicap, y conviene precisar la diferencia entre dos cosas distintas: dar formato al mensaje de pago (tarea de Agicap) y depurar los datos de direcciones que hay detrás (tarea del cliente, sea cual sea la vía por la que circule el pago).
- •
Si creas tus pagos directamente en Agicap, Agicap genera por ti el mensaje ISO 20022 con el formato correcto y va desplegando el formato de dirección estructurada banco por banco, por delante de la fecha límite de cada entidad, así que la mayor parte de ese trabajo técnico ocurre en segundo plano. Lo que Agicap no puede hacer es inventar datos que no existen: si la ciudad y el país de un beneficiario nunca se registraron como campos independientes, Agicap no tiene ninguna fuente de la que extraer datos estructurados.
Por eso lo único que conviene revisar es que la ciudad y el país figuren como campos independientes en tus datos de beneficiarios, y no unidos en una sola línea de dirección, antes incluso de que se genere el formato.- •
Si tus pagos se crean fuera de Agicap, en tu ERP o en tu software de contabilidad y luego se transfieren a través de Agicap, la misma lógica se aplica un paso antes: ese sistema tiene que exportar un archivo conforme a ISO 20022 con las direcciones ya estructuradas o híbridas. Agicap transmite el pago a tu banco, pero no puede analizar ni reestructurar a posteriori unos datos de dirección que llegan ya volcados en texto libre.
En cualquier caso, el aplazamiento no elimina la tarea de fondo: depurar los datos de dirección en origen es un proyecto de datos maestros.
Cómo una gestión de pagos bien organizada da sus frutos: Luminous Hotel Management
Este caso no tiene que ver específicamente con el cumplimiento de la dirección estructurada de ISO 20022, pero ilustra la disciplina subyacente que esta migración premia: saber exactamente cómo están tus conexiones bancarias y tus datos de pago, entidad por entidad, banco por banco. La complejidad multibanco suele estar donde cambios de formato como este generan más fricción, y merece la pena ver cómo es esa disciplina en la práctica.
Luminous Hotel Management, que gestiona 17 entidades y 67 cuentas bancarias, antes conciliaba sus cuentas manualmente en todas ellas. Tras centralizar la conectividad bancaria y automatizar la conciliación con Agicap, el tiempo dedicado a la conciliación bancaria se redujo a un 90 %, hasta menos de dos horas a la semana, y la empresa evitó contratar a una persona a tiempo completo dedicada a esta tarea.
“Antes de Agicap, no teníamos una visión clara de la tesorería neta generada o consumido cada mes”, explica Neha Jadav, CEO y cofundadora.
En resumen
El plazo de noviembre de 2026 que quizá hayas leído en otras fuentes de información, se ha movido pero la dirección del cambio no. Los datos de pago estructurados siguen siendo hacia dónde se dirige el sector, tanto en SEPA como en Swift. Las empresas que sigan depurando los datos de sus beneficiarios y probando sus formatos de archivo desde ahora no se verán con la soga al cuello cuando se confirme la próxima fecha.
Si tus pagos pasan por varios bancos y sistemas, merece la pena comprobar desde ya si tu configuración puede asumir un requisito de dirección estructurada antes de que sea obligatorio.
Descubre cómo gestiona Agicap la conectividad multibanco y la gestión de flujos de pagos para ver dónde pueden estar tus puntos débiles.
Preguntas frecuentes sobre la migración a ISO 20022
¿El requisito de dirección estructurada de ISO 20022 se limita a los pagos transfronterizos por Swift, o también alcanza a SEPA?
También alcanza a SEPA, con su propio calendario alineado. El European Payments Council (EPC) gestiona un requisito de dirección estructurada independiente en los cinco reglamentos de esquemas SEPA (SEPA Credit Transfer, SEPA Instant Credit Transfer, SEPA Direct Debit Core y B2B, y One-Leg Out Instant Credit Transfer), fijado originalmente para el 15 de noviembre de 2026 para alinearse con la fecha de Swift.
Tras el aplazamiento de Swift del 27 de agosto de 2026, el Payment Scheme Management Board del EPC decidió retrasar también su propio plazo de SEPA el 9 de septiembre de 2026, con una nueva fecha prevista para su reunión de octubre de 2026.
¿Una dirección híbrida de ISO 20022 necesita algo más que el campo de país?
Sí. Una dirección híbrida requiere tanto la ciudad como el país como campos independientes y estructurados; un código de país por sí solo no cumple el mínimo exigido, ni siquiera con el formato híbrido, más permisivo.
Mi banco ya me ha avisado de cambios en las direcciones estructuradas, ¿el aplazamiento de Swift anula eso?
No necesariamente. Los bancos pueden aplicar partes del requisito de dirección estructurada antes del calendario general de Swift/CBPR+, o de forma independiente a él. Confirma la fecha y el alcance exactos que te haya indicado tu banco, en lugar de dar por hecho que el reciente aplazamiento se aplica automáticamente a tu relación bancaria.
¿Afecta el aplazamiento a las transferencias y adeudos SEPA en España?
Sí. El requisito de dirección estructurada de las transferencias y adeudos SEPA (SEPA Credit Transfer, SEPA Instant Credit Transfer, SEPA Direct Debit Core y B2B, y One-Leg Out Instant Credit Transfer) estaba alineado con la fecha de Swift del 15 de noviembre de 2026 y se ha aplazado junto con ella. El Payment Scheme Management Board del European Payments Council decidió aplazarlo el 9 de septiembre de 2026, con una nueva fecha prevista en su reunión de octubre de 2026.
¿Se ha aplazado la migración a ISO 20022 en sí, o solo el requisito de dirección?
Solo el requisito de dirección. La migración de mensajería subyacente (el paso de los mensajes MT a los mensajes MX basados en XML, pacs.008, pain.001 y similares) ya está en marcha y no se ha visto afectada por el aplazamiento. Lo que se ha retrasado es específicamente la norma que exigiría direcciones estructuradas o híbridas en lugar de una <AdrLine> en texto libre.
ente la norma que exigiría direcciones estructuradas o híbridas en lugar de una <AdrLine> en texto libre.
