Fedwire e ISO 20022, um ano depois: o que mudou — e o que se parte a 16 de novembro de 2026
O Fedwire Funds Service passou para ISO 20022 num único dia, sem coexistência e sem recuo. Um ano depois, a migração está concluída e uma segunda transição obrigatória já está marcada. Eis o que a própria Federal Reserve declara que falha em produção, e o que corrigir antes de novembro.
Em que ponto está o Fedwire ISO 20022, um ano após a migração?
O Fedwire Funds Service adotou o formato de mensagem ISO 20022 num único dia: 14 de julho de 2025. Não houve período de coexistência — o antigo formato FAIM 3.0.7 deixou de ser suportado na sexta-feira 11 de julho de 2025, e as mensagens ainda enviadas nesse formato não foram aceites. Um ano depois, a migração está concluída: o Fedwire originou 217,3 milhões de transferências em 2025, com uma média de cerca de 4,59 biliões de dólares por dia. Uma segunda entrega obrigatória já está fixada para 16 de novembro de 2026 e elimina o endereço postal totalmente não estruturado para cada parte e cada agente, em cada mensagem, a favor de um único formato híbrido que exige sempre uma localidade e um país.
Valide o seu ficheiro agora
Grátis, instantâneo e 100% no seu navegador - nenhum ficheiro é enviado.
O big bang de 14 de julho de 2025 — e a data que toda a gente continua a errar
A Federal Reserve não fez isto por fases. Adotou o ISO 20022 para o Fedwire Funds Service num único dia, e disse-o com essas palavras. Sexta-feira, 11 de julho de 2025, foi o último dia em que o formato antigo esteve suportado; assim que o serviço encerrou às 19h00 ET, as mensagens em formato FAIM deixaram de ser aceites, e as que ainda estavam em curso foram apagadas durante o fim de semana da migração. Não houve execução em paralelo, nem camada de tradução, nem período de tolerância.
A data que ainda se encontra na documentação dos fornecedores — e nas respostas de mais do que um assistente de IA — é 10 de março de 2025. Era a data original, e foi adiada. A migração aconteceu a 14 de julho de 2025. Se a página de um fornecedor continua a dizer março, não é tocada há mais de um ano, o que diz alguma coisa sobre o resto da página.
O que desapareceu foi o FAIM, o Fedwire Application Interface Manual: um formato proprietário, baseado em etiquetas, em que um pagamento era uma série de chavetas numeradas — {1520} para o IMAD, {2000} para o montante, {6000} para a informação ao beneficiário. Do formato antigo resta apenas leitura: as mensagens passadas continuam consultáveis durante quinze meses, cada uma no formato em que foi criada.
O que mudou realmente dentro da mensagem
O interessante não é o XML ter substituído as etiquetas. São as quatro obrigações estruturais que vieram com ele, cada uma das quais parte uma integração ingénua.
Cada mensagem viaja agora dentro de um envelope: o Business Application Header
O head.001 é obrigatório, tanto no envio como na receção. O cabeçalho é um documento distinto da mensagem de negócio, e o routing number que transporta tem de ser o correto — ver o erro T125 mais abaixo. Se a sua integração trata o pagamento como um único documento XML, já está errada.
O UETR passou a ser obrigatório — mas o Fedwire não verifica se é único
O Unique End-to-End Transaction Reference é obrigatório nas mensagens de valor (pacs.008, pacs.009, pacs.004). A Federal Reserve valida o seu formato e afirma claramente que não verifica a unicidade. Um UETR duplicado passa sem obstáculo, e o problema de reconciliação recai sobre si, não sobre o operador.
O conjunto de mensagens é mais estreito do que a maioria supõe
Valor: pacs.008, pacs.009, pacs.004. Estado: pacs.002. Pedido de devolução: camt.056, respondido por camt.029. Drawdowns: pain.013 e pain.014. Rejeições técnicas: admi.002. Reporte: camt.052, e apenas camt.052 — não existe camt.053 no Fedwire Funds Service. Escrever um é um erro de categoria, não uma variante.
Datas, horas e montantes estão mais restringidos do que o esquema permite
O Fedwire aceita UTC ou um desvio UTC, e rejeita a hora local simples. A data de liquidação interbancária tem de ser uma data local pura (AAAA-MM-DD), porque significa um dia útil Fedwire na hora do Leste. Os montantes não levam sinal de mais nem de menos: presumem-se positivos. Uma mensagem pode ser válida face ao esquema e ainda assim ser recusada por qualquer um destes pontos.
O que a própria Federal Reserve declara que falha
Depois do arranque, a Fed publicou umas FAQ pós-implementação. É um documento invulgar e valioso: a lista, feita pelo próprio operador, do que realmente corre mal em produção. Vale a pena memorizar quatro pontos, porque nenhum deles é um erro de esquema — o ficheiro é válido, e falha à mesma.
Mudanças de linha dentro dos elementos de texto livre
A Fed desaconselha explicitamente colocar CRLF no texto de formato livre. É XML legal, passa a validação, e atrasa o processamento ou parte o tratamento da instituição recetora. Retire as quebras de linha de tudo o que tenha sido escrito por uma pessoa.
Elementos de texto que só contêm espaços
Mesma família, mesmo resultado. Um elemento preenchido com espaços não é um elemento vazio, e a Fed desaconselha enviá-lo. Recorte, e omita o elemento em vez de enviar espaços em branco.
T125 — o cabeçalho não corresponde à ligação
O routing number no From Member ID do Business Application Header tem de pertencer ao titular da ligação FedLine Direct que envia a mensagem. É um erro de cablagem, não de dados, e é a primeira coisa a verificar quando tudo parece correto e nada passa.
Usar a mensagem errada para corrigir um pagamento
Um pagamento já liquidado é devolvido com um pacs.004 — nunca com um novo pacs.008 ou pacs.009. O pedido de devolução é um camt.056, nunca uma investigação camt.110. E o T134 dispara quando o Charge Bearer está definido como CRED sem informação de encargos associada: use SHAR, ou declare zero.
O segundo big bang: segunda-feira, 16 de novembro de 2026
Um ano de estabilidade, e depois outra transição obrigatória — com um fim de semana de migração a 14 e 15 de novembro e o último dia normal na sexta-feira 13. Não é gradual, e não é opcional. Cinco coisas para ter à vista.
- 1O endereço postal totalmente não estruturado desaparece. Cada parte e cada agente, em cada mensagem, passa a um único formato híbrido: localidade e país sempre presentes, mais no máximo duas linhas de texto livre de 70 caracteres. As três linhas de 35 caracteres desaparecem.
- 2As mensagens de investigação camt.110 e camt.111 são redesenhadas — se construiu alguma coisa sobre a versão de 2023, é preciso revê-la.
- 3É introduzido um padrão XSD nos elementos de texto. Até agora o conjunto de caracteres aceite era uma recomendação; a partir de novembro é imposto pelo esquema.
- 4O calendário de testes já está publicado: dois sábados de teste em produção, 19 de setembro e 31 de outubro de 2026, com inscrição dez dias úteis antes. Um grupo de teste é obrigatório se enviar em média 100 ou mais mensagens de saída por dia via importação ou upload.
- 5Olhe para o calendário duas vezes. A regra de endereço estruturado da SEPA entra em vigor a 15 de novembro de 2026 — no dia anterior. Se envia pagamentos dos dois lados do Atlântico, isto é um único projeto de endereços, não dois.
A Fed dá a sua razão abertamente: a interoperabilidade com as mudanças que a Swift e a CHIPS estão a fazer. É o mesmo estado final híbrido que o grupo CBPR+ introduziu em novembro de 2025, a chegar ao Fedwire um ano depois — e é por isso que os dois prazos caem na mesma quinzena. Não é coincidência, e não é uma coordenação que se possa ignorar.
Valide uma mensagem Fedwire antes de a enviar
Largue um pacs.008, pacs.009, pacs.004 ou camt.056 no validador e veja o que a Fed veria. Corre inteiramente no seu navegador — o ficheiro nunca sai da sua máquina, que é a única forma realista de alguém testar uma transferência de produção.
Abrir o validador FedwireFontes oficiais
Todos os factos acima vêm das publicações da própria Federal Reserve: o ISO 20022 Implementation Center, as FAQ pós-implementação, as FAQ da entrega de novembro de 2026 e as estatísticas de volume publicadas. Onde a Fed não publica algo — os identificadores exatos de versão das mensagens e os comprimentos dos campos de remessa vivem no Implementation Guide no MyStandards, atrás de um login — este artigo nada diz em vez de adivinhar.
Perguntas frequentes
Quando é que o Fedwire migrou para ISO 20022?
A 14 de julho de 2025, numa transição de um só dia. Sexta-feira, 11 de julho de 2025, foi o último dia em que o antigo formato FAIM 3.0.7 esteve suportado. A data de 10 de março de 2025, que ainda circula muito, era o plano original e foi adiada — não é a data da migração.
Houve um período de coexistência entre o FAIM e o ISO 20022?
Não. A Federal Reserve adotou o ISO 20022 num único dia, sem execução em paralelo. As mensagens em formato FAIM enviadas depois do corte não foram aceites e foram apagadas durante o fim de semana da migração. O único acesso ao formato antigo que resta é de leitura: as mensagens passadas continuam consultáveis durante quinze meses, cada uma no formato em que foi criada.
Que mensagens ISO 20022 usa o Fedwire Funds Service?
Mensagens de valor: pacs.008 (transferência de cliente), pacs.009 (transferência entre instituições financeiras, incluindo cobertura) e pacs.004 (devolução de pagamento). Estado: pacs.002. Pedido de devolução: camt.056, respondido por camt.029. Drawdowns: pain.013 e pain.014. Rejeição técnica: admi.002. Reporte: camt.052. Todas elas vão envolvidas num Business Application Header head.001. Não existe camt.053 no Fedwire.
O UETR é obrigatório no Fedwire, e é verificado?
É obrigatório nas mensagens de valor — pacs.008, pacs.009 e pacs.004. A Federal Reserve valida o formato do UETR mas não verifica se é único. Um duplicado será aceite, portanto a unicidade é responsabilidade sua, não do operador.
O que acontece a 16 de novembro de 2026?
Uma segunda entrega obrigatória, com um fim de semana de migração a 14 e 15 de novembro. O endereço postal totalmente não estruturado é removido a favor de um único formato híbrido para cada parte e cada agente, em cada mensagem; as mensagens de investigação camt.110 e camt.111 são redesenhadas; e é aplicado um padrão XSD aos elementos de texto, apertando o conjunto de caracteres que pode enviar.
Os endereços estruturados já são obrigatórios no Fedwire?
Não para todos, e este é o mal-entendido mais comum. Desde julho de 2025 o estado final híbrido aplica-se apenas ao Ultimate Debtor, ao Initiating Party, ao Ultimate Creditor e ao Originator. O Debtor, o Creditor e os agentes continuam no regime transitório: um endereço estruturado ou até três linhas livres de 35 caracteres, mas nunca ambos ao mesmo tempo. Esse regime transitório termina a 16 de novembro de 2026.
Como é que o Fedwire me diz que uma mensagem foi rejeitada?
Com um admi.002. Transporta o IMAD da mensagem rejeitada na referência relacionada — ou NOTAVAILABLE quando a mensagem não pôde ser lida o suficiente para o encontrar. Um erro técnico ou de esquema e um erro de negócio distinguem-se pela forma do identificador que a rejeição transporta.
Isto afeta a CHIPS, o FedNow e o SWIFT?
A CHIPS migrou para ISO 20022 a 8 de abril de 2024, e o FedNow é nativo ISO 20022 desde o início. No SWIFT, a coexistência MT/ISO 20022 para as instruções de pagamento transfronteiriças (CBPR+) terminou a 22 de novembro de 2025 — mas isso aplica-se às instruções de pagamento: as mensagens de reporte MT 9xx estão descontinuadas, não retiradas. A entrega de novembro de 2026 do Fedwire está explicitamente alinhada com o que a Swift e a CHIPS estão a fazer.