ISO 20022: Swift amplía el plazo, pero el reto sigue estando en los datos

Swift acaba de dar más tiempo a la industria.

Hasta ahora, uno de los hitos más importantes de ISO 20022 para 2026 estaba previsto para noviembre: las direcciones postales completamente no estructuradas dejarían de utilizarse en los mensajes de pagos transfronterizos, obligando a identificar de manera estructurada determinados elementos de la dirección, como ciudad y país.

En la práctica hay tres formas de enviar una dirección: estructurada, con cada dato en su propio campo; híbrida, con al menos la ciudad y el país en campos propios y el resto en líneas de texto; y no estructurada, todo en líneas de texto libre. Esta última es la que se retira.

El 27 de agosto, Swift anunció que extenderá el calendario. La preparación de la industria continúa siendo desigual y, para el requisito de direcciones estructuradas, consultará con bancos, bancos centrales, infraestructuras de pagos, grupos de mercado y corporativos antes de definir el nuevo timing.

Para las tesorerías corporativas, el aplazamiento elimina una fecha inmediata. Pero no elimina el problema.

Porque detrás de una dirección aparentemente sencilla existe una pregunta mucho más importante:

Imaginemos un caso sencillo. Hace algunos años, un proveedor fue dado de alta en el ERP con su nombre, cuenta bancaria y una dirección escrita en un solo campo: 1200 Industrial Boulevard, Dallas, Texas, USA. Para cualquier persona, la información es perfectamente comprensible y, durante años, los pagos pudieron procesarse sin dificultad.

Hasta que las reglas cambian.

Es fácil interpretar la transición hacia direcciones estructuradas como otro cambio técnico: modificar un layout, incorporar nuevos campos o pedirle a IT que adapte una interfaz.

Creo que esa lectura se queda corta.

En los proyectos de Cash Management y conectividad bancaria aparece constantemente una realidad: podemos modernizar canales, formatos e interfaces, pero la tecnología solo puede trabajar con la calidad de la información que recibe.

ISO 20022, sin empezar por el XML

Cuando hablamos de ISO 20022 aparecen rápidamente términos como XML, pain.001, pacs.008 o camt.053. Para quien no trabaja diariamente con mensajería financiera, el tema puede parecer mucho más complejo de lo que realmente es.

• pain.001: la instrucción de pago que la empresa envía a su banco.
• pacs.008: el mensaje con el que los bancos se transfieren el pago entre sí.
• camt.053: el estado de cuenta que el banco devuelve a la empresa.

La idea de fondo es más sencilla: ISO 20022 establece un lenguaje común para que empresas, bancos e infraestructuras financieras intercambien información con mayor estructura y significado.

Volvamos a nuestra dirección. Para una persona, 1200 Industrial Boulevard, Dallas, Texas 75201, USA es suficiente. Nuestro cerebro identifica casi automáticamente la calle, la ciudad, el estado y el país.

Para una máquina resulta mucho más útil recibir esos componentes como datos diferenciados:

Para nosotros, la información prácticamente no cambió. Para un sistema, sí. Cada elemento puede ser identificado, validado, utilizado en controles, comparado con otras fuentes y transmitido entre sistemas sin que cada participante tenga que interpretar nuevamente una cadena de texto.

El pago empieza mucho antes de llegar al banco

Cuando pensamos en ISO 20022 solemos mirar hacia Swift, el banco, el archivo o la conectividad. Pero para una empresa, el pago comenzó mucho antes.

Proveedor → Master Data → ERP → TMS → Host-to-Host / API → Banco → Swift → Banco beneficiario

Compras puede participar en el alta del proveedor. Cuentas por Pagar complementa la información. Master Data mantiene el registro. IT administra el ERP y las interfaces. Finalmente, Tesorería utiliza esos datos para generar la instrucción.

Cuando el banco recibe el pago, está viendo el resultado de todo ese proceso.

Una empresa puede generar correctamente un pain.001, migrar de un archivo plano a XML, implementar host-to-host e incluso conectarse mediante APIs con sus bancos. Técnicamente, todo puede funcionar perfectamente. Pero si el ERP continúa alimentando esa arquitectura con información incompleta o inconsistente, el problema permanece.

Si esos datos nunca fueron capturados correctamente en el ERP, alguien tendrá que reconstruirlos después. Podrá hacerlo Tesorería, IT, un TMS o incluso una herramienta de inteligencia artificial, pero eso no sustituye una buena captura y gobierno desde el origen.

Y aquí aparece una pregunta que suele ser más importante que el propio formato del mensaje:

¿Quién es responsable de que esos datos sean correctos?

Un pago puede pertenecer operacionalmente a Tesorería, pero la información que lo alimenta atraviesa Compras, Cuentas por Pagar, Master Data, Compliance e IT. Por eso, conforme un proyecto de conectividad avanza, la conversación deja de ser únicamente tecnológica y se convierte también en una conversación de gobierno de datos: cuál es la fuente de verdad, quién puede modificar la información, quién valida los cambios y cómo se mantiene su calidad entre sistemas.

Por eso ISO 20022 no empieza realmente en Swift.

Empieza en nuestros propios sistemas.

Del Straight-Through Processing al dato de extremo a extremo

Durante años, una de las grandes aspiraciones del Cash Management ha sido incrementar el Straight-Through Processing (STP): lograr que una transacción recorra el proceso de punta a punta con la menor intervención manual posible.

ISO 20022 obliga a extender esa misma lógica al dato. Si llevamos el concepto un poco más lejos, podríamos pensar también en una especie de Straight-Through Data: que la información nazca correctamente y conserve su significado durante todo el recorrido.

Un ERP puede almacenar perfectamente Country = US y City = Dallas. Pero una interfaz legacy puede tomar ambos campos, concatenarlos con el resto de la dirección y entregar al siguiente sistema una única cadena de texto.

La empresa tenía el dato estructurado. Lo perdió durante el camino.

La diferencia también es importante cuando aparece una incidencia. Si un pago tiene información incompleta, corregir manualmente la instrucción puede resolver la operación del día. Pero si el problema está en el maestro de proveedores, la misma excepción puede volver a aparecer.

Corregir una instrucción repara un pago; corregir el dato en su origen mejora el proceso.

De ISO 20022 a la IA: los datos son la base de la tesorería del futuro

La importancia de estos datos irá mucho más allá del calendario de implementación.

Las tesorerías están avanzando hacia mayores niveles de automatización. Estamos empezando a imaginar agentes capaces de monitorear posiciones de caja, identificar anomalías, analizar pagos, recomendar movimientos de liquidez y eventualmente ejecutar determinadas acciones bajo políticas y autorizaciones definidas.

Pero incluso el agente más sofisticado necesitará saber quién es el beneficiario, dónde está ubicado, cuál es su cuenta, si sus datos fueron modificados recientemente y si una operación es consistente con su comportamiento histórico.

Ahí existe una conexión importante entre ISO 20022, APIs y tesorería agéntica. ISO 20022 aporta estructura y semántica; las APIs permiten mover esa información entre sistemas; y la inteligencia artificial puede utilizarla para interpretar, recomendar y eventualmente actuar.

Las tres capas comparten el mismo fundamento: datos de calidad.

La tesorería agéntica no empieza con un modelo de IA. Empieza con datos estructurados, confiables y disponibles para que las máquinas puedan entenderlos.

¿Qué debería hacer una tesorería corporativa ahora?

El aplazamiento da más tiempo, pero precisamente por eso puede ser una buena oportunidad para preparar el dato antes de que vuelva a existir presión por una fecha límite. No se trata de convertir al tesorero en experto en XML; se trata de comenzar las conversaciones correctas.

1. Identificar los flujos afectados. Revisar los pagos internacionales y confirmar con los bancos qué cambios aplican a cada canal y formato, así como el nuevo calendario conforme sea definido.
2. Revisar el maestro de beneficiarios. No solo comprobar que existe una dirección, sino validar que los elementos necesarios estén disponibles como datos identificables.
3. Seguir el recorrido del dato. Entender cómo viaja desde el alta del proveedor hasta el banco: ERP, TMS, middleware, archivos, host-to-host o APIs.
4. Definir ownership. Saber quién crea la información, quién puede modificarla, quién valida los cambios y quién corrige los registros históricos.
5. Probar los datos, no solo el formato. Que el banco acepte un mensaje ISO 20022 no significa necesariamente que haya recibido correctamente la información que la empresa quería transmitir.

Un proyecto ISO 20022 no debería considerarse exitoso únicamente porque un archivo pasa una validación técnica. El verdadero objetivo es que la información correcta pueda viajar de extremo a extremo sin depender de interpretaciones, reparaciones o intervenciones manuales.

Una dirección parece un detalle. No lo es.

La dirección del beneficiario puede parecer secundaria frente al monto, la moneda o la cuenta bancaria. Pero precisamente por eso resulta tan útil para entender el cambio: obliga a una empresa a mirar más allá del mensaje que envía al banco y revisar la calidad de la información que lo alimenta.

Este análisis refleja el anuncio de Swift del 27 de agosto de 2026. Al publicarlo, el nuevo calendario para las direcciones estructuradas aún no estaba definido: confírmalo con tus bancos y en el sitio de Swift.

Swift está dando más tiempo a la industria, pero la dirección del viaje no cambia. Los pagos internacionales continúan avanzando hacia información más rica y estructurada, capaz de soportar mejores controles, mayor automatización y procesos cada vez más digitales.

Para las tesorerías, aprovechar ese tiempo significa mirar antes al ERP, al maestro de beneficiarios y al gobierno de la información que esperar a que llegue una nueva fecha límite.

La pregunta, por tanto, no debería ser únicamente:

¿Está preparado nuestro banco para ISO 20022?

Sino también:

Para seguir leyendo: La tesorería agéntica ya es técnicamente posible · La liquidez no se administra cuenta por cuenta.

Fuentes y lectura adicional

• Swift, 27 de agosto de 2026. Swift accepts community request to extend structured address migration for ISO 20022 payment messages.
• Swift. ISO 20022: The removal of unstructured address.
• Swift. About ISO 20022.

CTP Journey · Finanzas, pagos e IA para decidir mejor.