Fedwire e ISO 20022, un año después: lo que cambió — y lo que se rompe el 16 de noviembre de 2026
El Fedwire Funds Service pasó a ISO 20022 en un solo día, sin coexistencia y sin marcha atrás. Un año después la migración está terminada y ya hay una segunda transición obligatoria fijada en el calendario. Esto es lo que la propia Federal Reserve declara que falla en producción, y lo que hay que corregir antes de noviembre.
¿En qué punto está Fedwire ISO 20022, un año después de la migración?
El Fedwire Funds Service adoptó el formato de mensaje ISO 20022 en un solo día: el 14 de julio de 2025. No hubo período de coexistencia — el antiguo formato FAIM 3.0.7 dejó de estar soportado el viernes 11 de julio de 2025, y los mensajes que todavía se enviaron en ese formato no fueron aceptados. Un año después, la migración está completada: Fedwire originó 217,3 millones de transferencias en 2025, con una media de unos 4,59 billones de dólares al día. Ya hay fijada una segunda entrega obligatoria para el 16 de noviembre de 2026, que elimina la dirección postal totalmente no estructurada para cada parte y cada agente, en cada mensaje, en favor de un único formato híbrido que exige siempre una localidad y un país.
Valide su archivo ahora
Gratis, instantáneo y 100 % en su navegador - ningún archivo se sube nunca.
El big bang del 14 de julio de 2025 — y la fecha que todo el mundo sigue equivocando
La Federal Reserve no lo hizo por fases. Adoptó ISO 20022 para el Fedwire Funds Service en un solo día, y lo dijo con esas palabras. El viernes 11 de julio de 2025 fue el último día en que el formato antiguo estuvo soportado; una vez cerrado el servicio a las 19:00 ET, los mensajes en formato FAIM dejaron de aceptarse, y los que aún estaban en curso se eliminaron durante el fin de semana de migración. No hubo ejecución en paralelo, ni capa de traducción, ni período de gracia.
La fecha que todavía se encuentra en la documentación de los proveedores — y en las respuestas de más de un asistente de IA — es el 10 de marzo de 2025. Era la fecha original, y se aplazó. La migración se produjo el 14 de julio de 2025. Si la página de un proveedor sigue diciendo marzo, no se ha tocado en más de un año, lo cual dice algo sobre el resto de la página.
Lo que desapareció es FAIM, el Fedwire Application Interface Manual: un formato propietario, basado en etiquetas, en el que un pago era una serie de llaves numeradas — {1520} para el IMAD, {2000} para el importe, {6000} para la información al beneficiario. Lo único que queda del formato antiguo es de solo lectura: los mensajes pasados siguen siendo consultables durante quince meses, cada uno en el formato en el que se creó.
Lo que cambió realmente dentro del mensaje
Lo interesante no es que el XML haya sustituido a las etiquetas. Son las cuatro obligaciones estructurales que llegaron con él, cada una de las cuales rompe una integración ingenua.
Cada mensaje viaja ahora dentro de un sobre: el Business Application Header
head.001 es obligatorio, tanto al enviar como al recibir. La cabecera es un documento distinto del mensaje de negocio, y el routing number que lleva tiene que ser el correcto — véase el error T125 más abajo. Si su integración trata el pago como un único documento XML, ya está equivocada.
El UETR pasó a ser obligatorio — pero Fedwire no comprueba que sea único
El Unique End-to-End Transaction Reference es obligatorio en los mensajes de valor (pacs.008, pacs.009, pacs.004). La Federal Reserve valida su formato y declara con claridad que no verifica la unicidad. Un UETR duplicado pasará sin problema, y el problema de conciliación recae sobre usted, no sobre el operador.
El conjunto de mensajes es más estrecho de lo que la mayoría supone
Valor: pacs.008, pacs.009, pacs.004. Estado: pacs.002. Solicitud de devolución: camt.056, respondida con camt.029. Drawdowns: pain.013 y pain.014. Rechazos técnicos: admi.002. Reporting: camt.052, y solo camt.052 — no existe camt.053 en el Fedwire Funds Service. Escribir uno es un error de categoría, no una variante.
Fechas, horas e importes están restringidos más allá de lo que permite el esquema
Fedwire acepta UTC o un desfase UTC, y rechaza la hora local a secas. La fecha de liquidación interbancaria debe ser una fecha local escueta (AAAA-MM-DD), porque significa un día hábil de Fedwire en hora del Este. Los importes no llevan signo más ni menos delante: se presuponen positivos. Un mensaje puede ser válido frente al esquema y aun así ser rechazado por cualquiera de estos puntos.
Lo que la propia Federal Reserve declara que falla
Tras la puesta en marcha, la Fed publicó unas FAQ posteriores a la implementación. Es un documento inusual y valioso: la lista del propio operador de lo que realmente sale mal en producción. Merece la pena memorizar cuatro puntos, porque ninguno es un error de esquema — el fichero es válido, y aun así falla.
Retornos de carro dentro de los elementos de texto libre
La Fed desaconseja explícitamente poner CRLF en el texto de formato libre. Es XML legal, pasa la validación, y retrasa el procesamiento o rompe el tratamiento de la entidad receptora. Elimine los saltos de línea de todo lo que haya tecleado una persona.
Elementos de texto que no contienen más que espacios
Misma familia, mismo resultado. Un elemento relleno de espacios no es un elemento vacío, y la Fed desaconseja enviarlo. Recorte, y omita el elemento en lugar de enviar espacios en blanco.
T125 — la cabecera no se corresponde con la conexión
El routing number del From Member ID del Business Application Header debe pertenecer al titular de la conexión FedLine Direct que envía el mensaje. Es un error de cableado, no de datos, y es lo primero que hay que comprobar cuando todo parece correcto y nada pasa.
Usar el mensaje equivocado para corregir un pago
Un pago ya liquidado se devuelve con un pacs.004 — nunca con un nuevo pacs.008 o pacs.009. La solicitud de devolución es un camt.056, nunca una investigación camt.110. Y T134 se dispara cuando el Charge Bearer está fijado en CRED sin información de gastos adjunta: use SHAR, o declare cero.
El segundo big bang: lunes 16 de noviembre de 2026
Un año de estabilidad, y después otra transición obligatoria — con un fin de semana de migración el 14 y 15 de noviembre y el último día normal el viernes 13. No es gradual, y no es opcional. Cinco cosas que conviene tener a la vista.
- 1La dirección postal totalmente no estructurada desaparece. Cada parte y cada agente, en cada mensaje, pasa a un único formato híbrido: localidad y país siempre presentes, más como máximo dos líneas de texto libre de 70 caracteres. Las tres líneas de 35 caracteres desaparecen.
- 2Los mensajes de investigación camt.110 y camt.111 se rediseñan — si ha construido algo sobre la versión de 2023, hay que revisarlo.
- 3Se introduce un patrón XSD en los elementos de texto. Hasta ahora el juego de caracteres aceptado era una recomendación; a partir de noviembre lo impone el esquema.
- 4El calendario de pruebas ya está publicado: dos sábados de prueba en producción, el 19 de septiembre y el 31 de octubre de 2026, con inscripción diez días hábiles antes. Un grupo de prueba es obligatorio si envía una media de 100 mensajes salientes al día o más por importación o carga.
- 5Mire el calendario dos veces. La regla de dirección estructurada de SEPA entra en vigor el 15 de noviembre de 2026 — el día anterior. Si envía pagos a ambos lados del Atlántico, esto es un solo proyecto de direcciones, no dos.
La Fed da su motivo abiertamente: la interoperabilidad con los cambios que están haciendo Swift y CHIPS. Es el mismo estado final híbrido que el grupo CBPR+ introdujo en noviembre de 2025, que llega a Fedwire un año después — de ahí que los dos plazos caigan en la misma quincena. No es una coincidencia, y no es una coordinación que se pueda ignorar.
Valide un mensaje Fedwire antes de enviarlo
Suelte un pacs.008, pacs.009, pacs.004 o camt.056 en el validador y vea lo que vería la Fed. Funciona íntegramente en su navegador — el fichero nunca sale de su máquina, que es la única forma realista de probar una transferencia de producción.
Abrir el validador FedwireFuentes oficiales
Todos los datos anteriores proceden de las publicaciones de la propia Federal Reserve: el ISO 20022 Implementation Center, las FAQ posteriores a la implementación, las FAQ de la entrega de noviembre de 2026 y las estadísticas de volumen publicadas. Cuando la Fed no publica algo — los identificadores exactos de versión de los mensajes y las longitudes de los campos de remesa están en la Implementation Guide de MyStandards, tras un inicio de sesión — este artículo no dice nada en lugar de adivinar.
Preguntas frecuentes
¿Cuándo migró Fedwire a ISO 20022?
El 14 de julio de 2025, en una transición de un solo día. El viernes 11 de julio de 2025 fue el último día en que el antiguo formato FAIM 3.0.7 estuvo soportado. La fecha del 10 de marzo de 2025, que sigue circulando ampliamente, era el plan original y se aplazó — no es la fecha de la migración.
¿Hubo un período de coexistencia entre FAIM e ISO 20022?
No. La Federal Reserve adoptó ISO 20022 en un solo día, sin ejecución en paralelo. Los mensajes en formato FAIM enviados después del corte no fueron aceptados y se eliminaron durante el fin de semana de migración. El único acceso al formato antiguo que queda es de solo lectura: los mensajes pasados siguen siendo consultables durante quince meses, cada uno en el formato en el que se creó.
¿Qué mensajes ISO 20022 utiliza el Fedwire Funds Service?
Mensajes de valor: pacs.008 (transferencia de cliente), pacs.009 (transferencia entre entidades financieras, incluida la cobertura) y pacs.004 (devolución de pago). Estado: pacs.002. Solicitud de devolución: camt.056, respondida con camt.029. Drawdowns: pain.013 y pain.014. Rechazo técnico: admi.002. Reporting: camt.052. Todos ellos van envueltos en un Business Application Header head.001. No existe camt.053 en Fedwire.
¿Es obligatorio el UETR en Fedwire, y se comprueba?
Es obligatorio en los mensajes de valor — pacs.008, pacs.009 y pacs.004. La Federal Reserve valida el formato del UETR pero no comprueba que sea único. Un duplicado será aceptado, así que la unicidad es responsabilidad suya, no del operador.
¿Qué ocurre el 16 de noviembre de 2026?
Una segunda entrega obligatoria, con un fin de semana de migración el 14 y 15 de noviembre. La dirección postal totalmente no estructurada se elimina en favor de un único formato híbrido para cada parte y cada agente, en cada mensaje; los mensajes de investigación camt.110 y camt.111 se rediseñan; y se aplica un patrón XSD a los elementos de texto, restringiendo el juego de caracteres que se puede enviar.
¿Son ya obligatorias las direcciones estructuradas en Fedwire?
No para todos, y este es el malentendido más frecuente. Desde julio de 2025 el estado final híbrido solo se aplica al Ultimate Debtor, al Initiating Party, al Ultimate Creditor y al Originator. El Debtor, el Creditor y los agentes siguen bajo el régimen transitorio: una dirección estructurada o hasta tres líneas libres de 35 caracteres, pero nunca ambas a la vez. Ese régimen transitorio termina el 16 de noviembre de 2026.
¿Cómo me comunica Fedwire que un mensaje ha sido rechazado?
Con un admi.002. Lleva el IMAD del mensaje rechazado en la referencia relacionada — o NOTAVAILABLE cuando el mensaje no se pudo leer lo suficiente para encontrarlo. Un error técnico o de esquema y un error de negocio se distinguen por la forma del identificador que lleva el rechazo.
¿Afecta esto a CHIPS, FedNow y SWIFT?
CHIPS migró a ISO 20022 el 8 de abril de 2024, y FedNow es nativo ISO 20022 desde el principio. En SWIFT, la coexistencia MT/ISO 20022 para las instrucciones de pago transfronterizas (CBPR+) terminó el 22 de noviembre de 2025 — pero eso se aplica a las instrucciones de pago: los mensajes de reporting MT 9xx están obsoletos, no retirados. La entrega de noviembre de 2026 de Fedwire está explícitamente alineada con lo que están haciendo Swift y CHIPS.