ISO 20022: qué cambió en las transferencias internacionales y qué datos exigen ahora

Un pago al exterior puede quedar detenido por una dirección incompleta, un nombre abreviado o un propósito escrito como «pago». El formato ISO 20022 facilita detectar esas inconsistencias.

En Soulbit Academy explicamos qué cambió en los mensajes de pago transfronterizo y qué información debe preparar una PYME antes de ordenar o recibir una transferencia.

ISO 20022 en las transferencias internacionales: qué cambió y con qué fechas

ISO 20022 es el estándar de mensajería usado en las instrucciones de pago transfronterizo entre entidades financieras de Swift. El 22 de noviembre de 2025 terminó la coexistencia con MT para esas instrucciones. Swift informó que el 97 % ya se enviaba en ISO 20022, según su comunicado oficial.

El formato ISO 20022 es ahora la norma para esos mensajes. Algunas instrucciones MT aún pueden entrar en un servicio de conversión de contingencia, con recargos desde el 1 de enero de 2026, según las preguntas frecuentes de Swift.

La diferencia práctica es la estructura. Un mensaje MT agrupaba datos del ordenante y del beneficiario en líneas de texto libre. Un mensaje ISO 20022 separa cada dato en su propio campo: nombre, calle, número, ciudad, país, identificador, propósito, referencia. Un sistema puede validar, filtrar y conciliar un campo; un bloque de texto, mucho peor.

Para una empresa, la consecuencia no es técnica sino documental. Los datos que antes se escribían «como cupieran» ahora deben existir completos y separados en su ficha de proveedor o de cliente. El banco los toma del formulario que usted llena.

Qué datos exige ISO 20022 a quien ordena una transferencia internacional

Un banco puede pedir datos del ordenante, beneficiario, entidades y propósito. El formulario exacto varía por entidad. La Tabla 1 resume datos útiles y errores habituales.

Dato	Qué debe entregar la empresa	Error frecuente
Nombre del beneficiario	Razón social tal como figura en su cuenta bancaria, sin abreviaturas inventadas	Usar el nombre comercial en lugar de la razón social
Dirección del beneficiario	Calle, número, ciudad, código postal y país en campos separados; como mínimo ciudad y país	Una sola línea de texto libre o solo el país
Cuenta y banco del beneficiario	IBAN o número de cuenta y BIC del banco receptor	Un dígito mal copiado o un BIC de otra sucursal
Ordenante	Razón social, NIT y dirección de la propia empresa, con el mismo formato	Dirección antigua o sin ciudad separada
Propósito del pago	Concepto concreto: factura, contrato o servicio, con su referencia	Escribir solo «pago» o «varios»
Referencia de factura	Número de factura o de orden en el campo de referencia	Omitirlo y obligar al beneficiario a conciliar a mano
Identificador de entidad (LEI u otro)	Solo si el banco o la contraparte lo piden	Entregar un identificador vencido o de otra entidad

Dos matices importan. El primero: que ISO 20022 admita un campo no significa que su banco lo exija en todos los casos. El LEI, por ejemplo, es un identificador de entidad jurídica que el estándar contempla; no hay una norma general que lo imponga a cada PYME.

El segundo: la lista tiene origen público. El Comité de Pagos e Infraestructuras de Mercado (CPMI) del BIS publicó requisitos armonizados de datos ISO 20022 para pagos transfronterizos, con una versión actualizada el 26 de febrero de 2026. Son una guía no regulatoria, orientada a que los bancos converjan hacia 2027; puede consultarla en el informe del BIS.

¿Por qué el propósito del pago importa tanto?

El propósito ayuda al banco a entender la operación. Un concepto concreto, coherente con una factura o contrato, puede evitar preguntas. Uno genérico puede motivar una solicitud de soporte.

En Colombia, además, el pago al exterior es una operación de cambio con su propia documentación. Lo que escriba en el propósito debe ser coherente con ese soporte; el detalle está en nuestra guía del régimen cambiario para empresas en Colombia y en la del documento soporte para pagos a proveedores del exterior.

Dirección estructurada o híbrida desde el 14 de noviembre de 2026

Swift prevé que, desde el 14 de noviembre de 2026, las direcciones postales incluidas en mensajes de pago CBPR+ deberán ser estructuradas o híbridas. La fecha aún no ha llegado; confirme el formato con su banco en la guía de Swift.

Una dirección estructurada separa calle, número, código postal, ciudad y país. La híbrida combina campos estructurados, al menos ciudad y país, con texto libre limitado. Swift dejará de aceptar direcciones totalmente libres en los mensajes afectados.

Swift indica que los mensajes afectados que no cumplan serán rechazados en la red, sin conversión de contingencia. Conviene revisar las direcciones de proveedores y clientes antes del plazo.

Antes del 14 de noviembre de 2026, una empresa debe revisar sus datos de pago en este orden:

• Revisar la ficha de cada proveedor frecuente y separar la dirección en campos.
• Comprobar que ciudad y país estén siempre presentes y escritos igual que en los documentos del proveedor.
• Actualizar la propia dirección del ordenante en el banco, porque también viaja en el mensaje.
• Pedir al proveedor nuevo, desde el primer contacto, una dirección completa y un nombre exacto.

Por qué se rechaza o se retiene una transferencia internacional

Una transferencia internacional se rechaza o se retiene cuando un campo falta, no coincide o activa una revisión de cumplimiento. Rechazo y retención son cosas distintas: el primero devuelve la instrucción; la segunda deja los fondos en revisión mientras alguien pide aclaraciones. La Tabla 2 los separa por causa.

Causa	Cómo se manifiesta	Qué corrige el ordenante
Dirección no estructurada o incompleta	El banco devuelve la instrucción o solicita rehacerla antes de enviarla	Entregar calle, ciudad y país en campos separados
Nombre distinto al de la cuenta	El banco receptor no puede aplicar el pago o pregunta por el titular	Usar la razón social exacta del beneficiario
Cuenta o BIC erróneos	Devolución con descuento de comisiones intermedias	Confirmar los datos con el beneficiario por un canal verificado
Propósito vago	Solicitud de factura o contrato antes de liberar los fondos	Indicar concepto y referencia desde el inicio
Coincidencia con listas de sanciones	Revisión manual y petición de información de las partes	Aportar documentos que aclaren la identidad y la relación comercial

Nada de lo anterior es nuevo en sí mismo. Lo nuevo es que el formato estructurado deja más campos que validar con reglas automáticas, y un error que antes pasaba como texto libre ahora produce una excepción. Si una operación entra en revisión por coincidencia con listas, la lógica es la que describe nuestra guía de listas de sanciones y screening en pagos internacionales.

¿Cuánto tarda en resolverse una retención?

El plazo depende del banco, de los corresponsales y de la rapidez con que el ordenante responda; no hay un tiempo general verificable. Lo que sí es controlable es la respuesta: cuanto antes entregue el soporte que le piden, antes se libera. Por eso conviene tener factura, contrato y datos del beneficiario en una carpeta antes de ordenar el pago.

Para dimensionar el costo de este tipo de fricción, y de las comisiones y márgenes que ya conlleva una transferencia, puede revisar el análisis de cuánto cuesta una transferencia Swift en 2026. No repetimos aquí esas cifras.

Caso ilustrativo: una PYME colombiana paga a un proveedor en Alemania

Una dirección en una sola línea, un nombre comercial y un propósito genérico bastan para que una transferencia se retenga o se devuelva. La empresa del caso es ficticia: una distribuidora colombiana de 40 empleados que paga a un proveedor alemán. Todos los datos son supuestos, no son resultados de un cliente ni tarifas de Soulbit. Sirve para mostrar el orden de las decisiones, no un caso real.

La distribuidora ordena su primera transferencia tras el cambio de formato. En la ficha del proveedor, la dirección figura en una línea: «Industriestr. 12 Hamburgo». El propósito dice «pago». El nombre es el comercial, no la razón social de la cuenta.

El banco devuelve la solicitud con tres observaciones. Falta el país en un campo propio, el nombre no coincide con el titular de la cuenta y el propósito no permite vincular el pago a una factura. La empresa corrige los tres puntos, vuelve a ordenar y, como supuesto del caso, pierde un día hábil.

La lección no es el día perdido. Es que los tres errores eran de datos, no de dinero, y se evitaban con una verificación previa de cinco minutos. La ficha corregida sería:

• Razón social completa del proveedor, copiada de su factura.
• Calle y número, código postal, ciudad y país en campos separados.
• IBAN y BIC confirmados por un canal distinto al correo de la factura.
• Propósito: «Factura 2026-118, suministro de repuestos» y la referencia en su campo.

Si la misma distribuidora recibiera pagos de clientes en el exterior, la lógica se invierte: debe entregar a su cliente sus propios datos completos, con la razón social y la dirección que figuran en su registro, para que el banco de este los coloque en los campos correctos.

Checklist antes de ordenar o recibir una transferencia internacional

Antes de ordenar una transferencia internacional, la empresa debe verificar seis grupos de datos y conservar el soporte. Este checklist sirve para ordenar y para recibir, porque el banco del otro lado aplica las mismas reglas.

1. Razón social exacta del beneficiario, tal como figura en su cuenta bancaria.
2. Dirección en campos separados, con ciudad y país siempre presentes.
3. Cuenta (IBAN o número) y BIC del banco, confirmados por un canal verificado.
4. Propósito concreto y referencia de factura, coherentes con el contrato.
5. Identificadores adicionales (NIT propio, LEI si el banco lo pide) vigentes y de la entidad correcta.
6. Soporte cambiario y documental del país del ordenante, guardado y a mano.

Después de enviar el pago, conserve la confirmación y el número de referencia para cualquier consulta al banco.

Qué entrega Soulbit V1 y qué no en relación con ISO 20022

Soulbit no emite transferencias Swift ni controla las reglas de ISO 20022. Es una plataforma custodial: mantiene saldos en stablecoins (USDC y USDT) y en fiat (USD, EUR y GBP), con custodia institucional con MPC, verificación KYB y soporte humano. Su único rail bancario local es Colombia.

Lo que sí ofrece V1 es otra ruta para mover valor: pagos en stablecoin, conversión eOTC bajo cotización, payment links y QR de cobro. Esa ruta tiene sus propios requisitos de verificación y de datos, distintos de los de Swift. La comparación entre ambas está en Swift frente a stablecoins en pagos internacionales.

Lo que Soulbit no hace es igual de relevante. No ofrece cuentas bancarias ni depósitos y no tiene licencia bancaria. No resuelve la declaración de cambio ni el soporte documental de su empresa. No elimina las obligaciones de verificación de identidad y de origen de fondos. Y no existe en este artículo ninguna promesa de precio inferior: cada empresa debe comparar cotizaciones reales.