Fedwire e ISO 20022, un anno dopo: cosa è cambiato — e cosa si rompe il 16 novembre 2026
Il Fedwire Funds Service è passato a ISO 20022 in un solo giorno, senza coesistenza e senza ripiego. Un anno dopo la migrazione è conclusa, e un secondo passaggio obbligatorio è già in calendario. Ecco cosa la stessa Federal Reserve dichiara che si rompe in produzione, e cosa correggere prima di novembre.
A che punto è Fedwire ISO 20022, un anno dopo la migrazione?
Il Fedwire Funds Service ha adottato il formato di messaggio ISO 20022 in un solo giorno: il 14 luglio 2025. Non c'è stato alcun periodo di coesistenza — il vecchio formato FAIM 3.0.7 ha smesso di essere supportato venerdì 11 luglio 2025, e i messaggi ancora inviati in quel formato non sono stati accettati. Un anno dopo, la migrazione è completa: nel 2025 Fedwire ha originato 217,3 milioni di bonifici, per una media di circa 4.590 miliardi di dollari al giorno. Un secondo rilascio obbligatorio è già fissato per il 16 novembre 2026 ed elimina l'indirizzo postale completamente non strutturato per ogni parte e ogni agente, in ogni messaggio, a favore di un unico formato ibrido che richiede sempre una località e un paese.
Valida il tuo file subito
Gratis, istantaneo e 100% nel browser - nessun file viene mai caricato.
Il big bang del 14 luglio 2025 — e la data che tutti continuano a sbagliare
La Federal Reserve non ha proceduto per fasi. Ha adottato ISO 20022 per il Fedwire Funds Service in un solo giorno, e lo ha detto con queste parole. Venerdì 11 luglio 2025 è stato l'ultimo giorno in cui il vecchio formato è stato supportato; una volta chiuso il servizio alle 19:00 ET, i messaggi in formato FAIM non sono più stati accettati, e quelli ancora in transito sono stati cancellati durante il fine settimana della migrazione. Nessuna esecuzione in parallelo, nessun livello di traduzione, nessun periodo di tolleranza.
La data che si trova ancora nella documentazione dei fornitori — e nelle risposte di più di un assistente IA — è il 10 marzo 2025. Era la data iniziale, ed è stata rinviata. La migrazione è avvenuta il 14 luglio 2025. Se la pagina di un fornitore riporta ancora marzo, non viene aggiornata da oltre un anno: il che dice qualcosa sul resto della pagina.
Ciò che è scomparso è FAIM, il Fedwire Application Interface Manual: un formato proprietario, basato su tag, in cui un pagamento era una sequenza di parentesi graffe numerate — {1520} per l'IMAD, {2000} per l'importo, {6000} per le informazioni al beneficiario. Del vecchio formato resta soltanto la sola lettura: i messaggi passati restano consultabili per quindici mesi, ciascuno nel formato in cui è stato creato.
Cosa è cambiato davvero all'interno del messaggio
La parte interessante non è che l'XML abbia sostituito i tag. Sono i quattro obblighi strutturali arrivati con esso, ognuno dei quali rompe un'integrazione ingenua.
Ogni messaggio viaggia ora in una busta: il Business Application Header
head.001 è obbligatorio, sia in invio sia in ricezione. L'header è un documento distinto dal messaggio di business, e il routing number che riporta deve essere quello giusto — si veda l'errore T125 più avanti. Se la vostra integrazione tratta il pagamento come un unico documento XML, è già sbagliata.
L'UETR è diventato obbligatorio — ma Fedwire non verifica che sia univoco
L'Unique End-to-End Transaction Reference è obbligatorio sui messaggi di valore (pacs.008, pacs.009, pacs.004). La Federal Reserve ne valida il formato e dichiara esplicitamente di non verificarne l'univocità. Un UETR duplicato passerà senza ostacoli, e il problema di riconciliazione ricade su di voi, non sull'operatore.
L'insieme dei messaggi è più ristretto di quanto molti immaginino
Valore: pacs.008, pacs.009, pacs.004. Stato: pacs.002. Richiesta di restituzione: camt.056, a cui risponde camt.029. Drawdown: pain.013 e pain.014. Rifiuti tecnici: admi.002. Rendicontazione: camt.052, e solo camt.052 — sul Fedwire Funds Service non esiste alcun camt.053. Scriverne uno è un errore di categoria, non una variante.
Date, orari e importi sono più vincolati di quanto lo schema consenta
Fedwire accetta UTC o uno scostamento UTC, e rifiuta l'ora locale semplice. La data di regolamento interbancario deve essere una data locale nuda (AAAA-MM-GG), perché indica una giornata lavorativa Fedwire nell'ora dell'Est. Gli importi non portano alcun segno più o meno: sono presunti positivi. Un messaggio può essere valido rispetto allo schema e comunque essere rifiutato su uno di questi punti.
Cosa la stessa Federal Reserve dichiara che si rompe
Dopo l'avvio, la Fed ha pubblicato delle FAQ post-implementazione. È un documento insolito e prezioso: l'elenco, redatto dall'operatore stesso, di ciò che va davvero storto in produzione. Quattro punti meritano di essere memorizzati, perché nessuno di essi è un errore di schema — il file è valido, e fallisce comunque.
Ritorni a capo all'interno degli elementi di testo libero
La Fed sconsiglia esplicitamente di inserire CRLF nel testo in formato libero. È XML legale, supera la validazione, e ritarda l'elaborazione o rompe la gestione dell'istituto ricevente. Eliminate le interruzioni di riga da tutto ciò che è stato digitato da una persona.
Elementi di testo che contengono soltanto spazi
Stessa famiglia, stesso esito. Un elemento riempito di spazi non è un elemento vuoto, e la Fed sconsiglia di inviarlo. Ripulite, e omettete l'elemento invece di inviare spazi bianchi.
T125 — l'header non corrisponde alla connessione
Il routing number nel From Member ID del Business Application Header deve appartenere al titolare della connessione FedLine Direct che invia il messaggio. È un errore di cablaggio, non di dati, ed è la prima cosa da controllare quando tutto sembra corretto e non passa nulla.
Usare il messaggio sbagliato per correggere un pagamento
Un pagamento già regolato viene restituito con un pacs.004 — mai con un nuovo pacs.008 o pacs.009. La richiesta di restituzione è un camt.056, mai un'indagine camt.110. E T134 scatta quando il Charge Bearer è impostato su CRED senza alcuna informazione sulle spese: usate SHAR, oppure dichiarate zero.
Il secondo big bang: lunedì 16 novembre 2026
Un anno di stabilità, e poi un altro passaggio obbligatorio — con un fine settimana di migrazione il 14-15 novembre e l'ultima giornata normale venerdì 13. Non è graduale, e non è facoltativo. Cinque cose da tenere sotto gli occhi.
- 1L'indirizzo postale completamente non strutturato scompare. Ogni parte e ogni agente, in ogni messaggio, passa a un unico formato ibrido: località e paese sempre presenti, più al massimo due righe di testo libero di 70 caratteri. Le tre righe da 35 caratteri spariscono.
- 2I messaggi di indagine camt.110 e camt.111 sono ridisegnati — se avete costruito qualcosa sulla versione del 2023, va rivisto.
- 3Viene introdotto un pattern XSD sugli elementi di testo. Finora l'insieme di caratteri accettato era una raccomandazione; da novembre è imposto dallo schema.
- 4Il calendario dei test è già pubblicato: due sabati di test in produzione, il 19 settembre e il 31 ottobre 2026, con iscrizione dieci giorni lavorativi prima. Un gruppo di test è obbligatorio se inviate in media 100 o più messaggi in uscita al giorno tramite import o upload.
- 5Guardate il calendario due volte. La regola SEPA sugli indirizzi strutturati entra in vigore il 15 novembre 2026 — il giorno prima. Se inviate pagamenti su entrambe le sponde dell'Atlantico, questo è un solo progetto sugli indirizzi, non due.
La Fed espone apertamente la sua ragione: l'interoperabilità con i cambiamenti che Swift e CHIPS stanno introducendo. È lo stesso stato finale ibrido introdotto dal gruppo CBPR+ nel novembre 2025, che arriva su Fedwire un anno dopo — ed è per questo che le due scadenze cadono nella stessa quindicina. Non è una coincidenza, e non è un coordinamento che si possa ignorare.
Validate un messaggio Fedwire prima di inviarlo
Trascinate un pacs.008, pacs.009, pacs.004 o camt.056 nel validatore e vedete ciò che vedrebbe la Fed. Funziona interamente nel vostro browser — il file non lascia mai la vostra macchina, l'unico modo realistico per testare un bonifico di produzione.
Apri il validatore FedwireFonti ufficiali
Tutti i fatti riportati provengono dalle pubblicazioni della stessa Federal Reserve: l'ISO 20022 Implementation Center, le FAQ post-implementazione, le FAQ del rilascio di novembre 2026 e le statistiche di volume pubblicate. Dove la Fed non pubblica qualcosa — gli identificatori esatti delle versioni dei messaggi e le lunghezze dei campi di remittance vivono nella Implementation Guide su MyStandards, dietro un login — questo articolo non dice nulla invece di tirare a indovinare.
Domande frequenti
Quando è migrato Fedwire a ISO 20022?
Il 14 luglio 2025, con un passaggio in un solo giorno. Venerdì 11 luglio 2025 è stato l'ultimo giorno in cui il vecchio formato FAIM 3.0.7 è stato supportato. La data del 10 marzo 2025, che circola ancora largamente, era il piano iniziale ed è stata rinviata — non è la data della migrazione.
C'è stato un periodo di coesistenza tra FAIM e ISO 20022?
No. La Federal Reserve ha adottato ISO 20022 in un solo giorno, senza esecuzione in parallelo. I messaggi in formato FAIM inviati dopo il cutoff non sono stati accettati e sono stati cancellati durante il fine settimana della migrazione. L'unico accesso rimasto al vecchio formato è in sola lettura: i messaggi passati restano consultabili per quindici mesi, ciascuno nel formato in cui è stato creato.
Quali messaggi ISO 20022 utilizza il Fedwire Funds Service?
Messaggi di valore: pacs.008 (bonifico della clientela), pacs.009 (trasferimento tra istituzioni finanziarie, cover incluso) e pacs.004 (restituzione del pagamento). Stato: pacs.002. Richiesta di restituzione: camt.056, a cui risponde camt.029. Drawdown: pain.013 e pain.014. Rifiuto tecnico: admi.002. Rendicontazione: camt.052. Ognuno di essi è avvolto in un Business Application Header head.001. Su Fedwire non esiste camt.053.
L'UETR è obbligatorio su Fedwire, e viene verificato?
È obbligatorio sui messaggi di valore — pacs.008, pacs.009 e pacs.004. La Federal Reserve valida il formato dell'UETR ma non verifica che sia univoco. Un duplicato viene accettato, quindi l'univocità è una vostra responsabilità, non dell'operatore.
Cosa succede il 16 novembre 2026?
Un secondo rilascio obbligatorio, con un fine settimana di migrazione il 14-15 novembre. L'indirizzo postale completamente non strutturato viene eliminato a favore di un unico formato ibrido per ogni parte e ogni agente, in ogni messaggio; i messaggi di indagine camt.110 e camt.111 sono ridisegnati; e un pattern XSD viene applicato agli elementi di testo, restringendo l'insieme di caratteri che potete inviare.
Gli indirizzi strutturati sono già obbligatori su Fedwire?
Non per tutti, ed è il malinteso più diffuso. Da luglio 2025 lo stato finale ibrido si applica soltanto all'Ultimate Debtor, all'Initiating Party, all'Ultimate Creditor e all'Originator. Il Debtor, il Creditor e gli agenti restano nel regime transitorio: un indirizzo strutturato oppure fino a tre righe libere da 35 caratteri, ma mai entrambi insieme. Quel regime transitorio termina il 16 novembre 2026.
Come mi comunica Fedwire che un messaggio è stato rifiutato?
Con un admi.002. Riporta l'IMAD del messaggio rifiutato nel riferimento correlato — oppure NOTAVAILABLE quando il messaggio non ha potuto essere letto abbastanza a fondo da trovarlo. Un errore tecnico o di schema e un errore di business si distinguono dalla forma dell'identificatore che il rifiuto riporta.
Questo riguarda CHIPS, FedNow e SWIFT?
CHIPS è migrato a ISO 20022 l'8 aprile 2024, e FedNow è nativo ISO 20022 fin dall'inizio. Su SWIFT, la coesistenza MT/ISO 20022 per le istruzioni di pagamento transfrontaliere (CBPR+) è terminata il 22 novembre 2025 — ma questo riguarda le istruzioni di pagamento: i messaggi di rendicontazione MT 9xx sono deprecati, non ritirati. Il rilascio Fedwire di novembre 2026 è esplicitamente allineato a ciò che stanno facendo Swift e CHIPS.