Fedwire et ISO 20022, un an après : ce qui a changé — et ce qui casse le 16 novembre 2026
Le Fedwire Funds Service est passé à ISO 20022 en une seule journée, sans coexistence et sans repli. Un an plus tard, la migration est faite, et une seconde bascule obligatoire est déjà programmée. Voici ce que la Federal Reserve elle-même signale comme cassant en production, et ce qu'il faut corriger avant novembre.
Où en est Fedwire ISO 20022, un an après la migration ?
Le Fedwire Funds Service a adopté le format de message ISO 20022 en une seule journée : le 14 juillet 2025. Il n'y a eu aucune période de coexistence — l'ancien format FAIM 3.0.7 a cessé d'être pris en charge le vendredi 11 juillet 2025, et les messages encore émis dans ce format n'étaient plus acceptés. Un an après, la migration est achevée : Fedwire a émis 217,3 millions de virements en 2025, pour une moyenne d'environ 4 590 milliards de dollars par jour. Une seconde version obligatoire est déjà fixée au 16 novembre 2026, et elle supprime l'adresse postale entièrement non structurée pour chaque partie et chaque agent, dans chaque message, au profit d'un unique format hybride qui exige toujours un nom de ville et un pays.
Validez votre fichier maintenant
Gratuit, instantané et 100 % dans votre navigateur - aucun fichier n'est jamais envoyé.
Le big bang du 14 juillet 2025 — et la date que tout le monde continue de se tromper
La Federal Reserve n'a pas procédé par étapes. Elle a adopté ISO 20022 pour le Fedwire Funds Service en une seule journée, et elle l'a dit en ces termes. Le vendredi 11 juillet 2025 a été le dernier jour où l'ancien format était pris en charge ; une fois le service fermé à 19 h ET, les messages au format FAIM n'étaient plus acceptés, et ceux encore en transit ont été supprimés pendant le week-end de migration. Il n'y a eu ni double flux, ni couche de traduction, ni délai de grâce.
La date que l'on trouve encore dans la documentation des éditeurs — et dans les réponses de plus d'un assistant IA — est le 10 mars 2025. C'était la date initiale, et elle a été reportée. La migration a eu lieu le 14 juillet 2025. Si la page d'un fournisseur indique encore mars, c'est qu'elle n'a pas été touchée depuis plus d'un an, ce qui en dit long sur le reste de la page.
Ce qui a disparu, c'est FAIM, le Fedwire Application Interface Manual : un format propriétaire à balises numérotées, où un paiement était une suite d'accolades — {1520} pour l'IMAD, {2000} pour le montant, {6000} pour l'information au bénéficiaire. Le seul héritage qui subsiste est en lecture seule : les messages passés restent consultables pendant quinze mois, chacun dans le format dans lequel il a été créé.
Ce qui a réellement changé à l'intérieur du message
Ce qui est intéressant, ce n'est pas que le XML ait remplacé les balises. Ce sont les quatre obligations structurelles qui l'accompagnent, dont chacune casse une intégration naïve.
Chaque message voyage désormais dans une enveloppe : le Business Application Header
head.001 est obligatoire, à l'émission comme à la réception. L'en-tête est un document distinct du message métier, et le routing number qu'il porte doit être le bon — voir l'erreur T125 ci-dessous. Si votre intégration traite le paiement comme un unique document XML, elle est déjà fausse.
L'UETR est devenu obligatoire — mais Fedwire ne vérifie pas qu'il est unique
L'Unique End-to-End Transaction Reference est exigé sur les messages de valeur (pacs.008, pacs.009, pacs.004). La Federal Reserve en valide le format et déclare explicitement qu'elle n'en vérifie pas l'unicité. Un UETR dupliqué passera sans encombre, et le problème de rapprochement retombe sur vous, pas sur l'opérateur.
Le jeu de messages est plus restreint que la plupart ne le supposent
Valeur : pacs.008, pacs.009, pacs.004. Statut : pacs.002. Demande de retour : camt.056, à laquelle répond camt.029. Drawdowns : pain.013 et pain.014. Rejets techniques : admi.002. Restitution : camt.052, et uniquement camt.052 — il n'y a pas de camt.053 sur le Fedwire Funds Service. En écrire un est une erreur de catégorie, pas une variante.
Dates, heures et montants sont restreints au-delà de ce que le schéma autorise
Fedwire accepte l'UTC ou un décalage UTC, et rejette l'heure locale nue. La date de règlement interbancaire doit être une date locale simple (AAAA-MM-JJ), parce qu'elle désigne un jour ouvré Fedwire en heure de l'Est. Les montants ne portent aucun signe plus ou moins en tête : ils sont réputés positifs. Un message peut être conforme au schéma et être refusé sur l'un de ces points.
Ce que la Federal Reserve elle-même signale comme cassant
Après la mise en service, la Fed a publié une FAQ post-implémentation. C'est un document inhabituel et précieux : la liste, par l'opérateur lui-même, de ce qui échoue réellement en production. Quatre points méritent d'être retenus, car aucun n'est une erreur de schéma — le fichier est valide, et il échoue quand même.
Retours chariot à l'intérieur des éléments de texte libre
La Fed recommande explicitement de ne pas placer de CRLF dans le texte au format libre. C'est du XML légal, cela passe la validation, et cela retarde le traitement ou casse la prise en charge par l'établissement destinataire. Retirez les sauts de ligne de tout ce qu'un humain a saisi.
Éléments de texte ne contenant que des espaces
Même famille, même résultat. Un élément rempli d'espaces n'est pas un élément vide, et la Fed déconseille de l'envoyer. Nettoyez les espaces, et omettez l'élément plutôt que d'envoyer des blancs.
T125 — l'en-tête ne correspond pas à la connexion
Le routing number présent dans le From Member ID du Business Application Header doit appartenir au titulaire de la connexion FedLine Direct qui émet le message. C'est une erreur de câblage, pas une erreur de donnée, et c'est la première chose à vérifier quand tout semble correct et que rien ne passe.
Utiliser le mauvais message pour corriger un paiement
Un paiement déjà réglé se retourne avec un pacs.004 — jamais avec un nouveau pacs.008 ou pacs.009. Une demande de retour est un camt.056, jamais une investigation camt.110. Et T134 se déclenche lorsque le Charge Bearer vaut CRED sans information de frais associée : utilisez SHAR, ou déclarez zéro.
Le second big bang : lundi 16 novembre 2026
Un an de stabilité, puis une nouvelle bascule obligatoire — avec un week-end de bascule les 14 et 15 novembre et un dernier jour normal le vendredi 13. Ce n'est ni progressif, ni facultatif. Cinq points à afficher au mur.
- 1L'adresse postale entièrement non structurée disparaît. Chaque partie et chaque agent, dans chaque message, passe à un unique format hybride : nom de ville et pays toujours présents, plus au maximum deux lignes de texte libre de 70 caractères. Les trois lignes de 35 caractères, c'est terminé.
- 2Les messages d'investigation camt.110 et camt.111 sont repensés — si vous avez construit quoi que ce soit sur la version 2023, il faudra y revenir.
- 3Un pattern XSD est introduit sur les éléments de texte. Jusqu'ici, le jeu de caractères accepté relevait de la recommandation ; à partir de novembre, il est imposé par le schéma.
- 4Le calendrier de test est déjà publié : deux samedis de test en production, les 19 septembre et 31 octobre 2026, avec inscription dix jours ouvrés à l'avance. Un groupe de test est obligatoire si vous émettez en moyenne 100 messages sortants ou plus par jour par import ou téléversement.
- 5Regardez le calendrier à deux fois. La règle d'adresse structurée de SEPA mord le 15 novembre 2026 — la veille. Si vous émettez des paiements des deux côtés de l'Atlantique, c'est un seul chantier d'adresses, pas deux.
La Fed donne ouvertement sa raison : l'interopérabilité avec les évolutions que mènent Swift et CHIPS. C'est le même état cible hybride que le groupe CBPR+ a introduit en novembre 2025, qui arrive sur Fedwire un an plus tard — d'où le fait que les deux échéances tombent dans la même quinzaine. Ce n'est pas une coïncidence, et ce n'est pas une coordination que vous pouvez ignorer.
Validez un message Fedwire avant de l'envoyer
Déposez un pacs.008, un pacs.009, un pacs.004 ou un camt.056 dans le validateur et voyez ce que la Fed verrait. Tout s'exécute dans votre navigateur — le fichier ne quitte jamais votre machine, ce qui est la seule façon réaliste de tester un virement de production.
Ouvrir le validateur FedwireSources officielles
Chacun des faits ci-dessus provient des publications de la Federal Reserve elle-même : l'ISO 20022 Implementation Center, la FAQ post-implémentation, la FAQ de la version de novembre 2026 et les statistiques de volume publiées. Là où la Fed ne publie rien — les identifiants exacts de version des messages et les longueurs des champs de remise vivent dans l'Implementation Guide sur MyStandards, derrière une authentification — cet article ne dit rien plutôt que de deviner.
Questions fréquemment posées
Quand Fedwire a-t-il migré vers ISO 20022 ?
Le 14 juillet 2025, par une bascule en une seule journée. Le vendredi 11 juillet 2025 a été le dernier jour où l'ancien format FAIM 3.0.7 était pris en charge. La date du 10 mars 2025, qui circule encore largement, était le plan initial et a été reportée — ce n'est pas la date de migration.
Y a-t-il eu une période de coexistence entre FAIM et ISO 20022 ?
Non. La Federal Reserve a adopté ISO 20022 en une seule journée, sans double flux. Les messages au format FAIM envoyés après la limite n'ont pas été acceptés et ont été supprimés pendant le week-end de migration. Le seul accès à l'ancien format qui subsiste est en lecture seule : les messages passés restent consultables pendant quinze mois, chacun dans le format dans lequel il a été créé.
Quels messages ISO 20022 le Fedwire Funds Service utilise-t-il ?
Messages de valeur : pacs.008 (virement de clientèle), pacs.009 (virement d'établissement financier, cover incluse) et pacs.004 (retour de paiement). Statut : pacs.002. Demande de retour : camt.056, à laquelle répond camt.029. Drawdowns : pain.013 et pain.014. Rejet technique : admi.002. Restitution : camt.052. Chacun d'eux est encapsulé dans un Business Application Header head.001. Il n'y a pas de camt.053 sur Fedwire.
L'UETR est-il obligatoire sur Fedwire, et est-il contrôlé ?
Il est obligatoire sur les messages de valeur — pacs.008, pacs.009 et pacs.004. La Federal Reserve valide le format de l'UETR mais ne vérifie pas qu'il est unique. Un doublon sera accepté : l'unicité est donc votre responsabilité, pas celle de l'opérateur.
Que se passe-t-il le 16 novembre 2026 ?
Une seconde version obligatoire, avec un week-end de bascule les 14 et 15 novembre. L'adresse postale entièrement non structurée est supprimée au profit d'un unique format hybride pour chaque partie et chaque agent, dans chaque message ; les messages d'investigation camt.110 et camt.111 sont repensés ; et un pattern XSD est appliqué aux éléments de texte, resserrant le jeu de caractères que vous pouvez envoyer.
Les adresses structurées sont-elles déjà obligatoires sur Fedwire ?
Pas pour tout le monde, et c'est le malentendu le plus fréquent. Depuis juillet 2025, l'état cible hybride ne s'applique qu'à l'Ultimate Debtor, à l'Initiating Party, à l'Ultimate Creditor et à l'Originator. Le Debtor, le Creditor et les agents restent sous le régime intermédiaire : une adresse structurée ou jusqu'à trois lignes libres de 35 caractères, mais jamais les deux à la fois. Ce régime intermédiaire prend fin le 16 novembre 2026.
Comment Fedwire m'indique-t-il qu'un message a été rejeté ?
Par un admi.002. Il porte l'IMAD du message rejeté dans la référence associée — ou NOTAVAILABLE lorsque le message n'a pas pu être lu assez loin pour en trouver un. Une erreur technique ou de schéma et une erreur métier se distinguent par la forme de l'identifiant que porte le rejet.
Cela concerne-t-il CHIPS, FedNow et SWIFT ?
CHIPS a migré vers ISO 20022 le 8 avril 2024, et FedNow est nativement ISO 20022 depuis le départ. Sur SWIFT, la coexistence MT/ISO 20022 pour les instructions de paiement transfrontalières (CBPR+) a pris fin le 22 novembre 2025 — mais cela vaut pour les instructions de paiement : les messages de restitution MT 9xx sont dépréciés, non retirés. La version de novembre 2026 de Fedwire est explicitement alignée sur ce que font Swift et CHIPS.