Endereços estruturados em pagamentos SWIFT e SEPA: o prazo mudou, o trabalho não

2026-11-05

A data que desapareceu sem alarde

Durante quase todo o último ano, novembro de 2026 esteve assinalado a vermelho no calendário do setor dos pagamentos. A partir desse mês, as mensagens de pagamentos transfronteiriços na rede Swift deixariam de aceitar moradas postais escritas em texto livre, e os pagamentos SEPA na Europa seguiriam o mesmo caminho a partir de 15 de novembro. Os bancos passaram meses a refazer formulários e ficheiros em função disso.

Depois, no fim do verão, ambas as datas saíram do calendário. Em 27 de agosto de 2026, a Swift anunciou o adiamento das alterações de pagamentos da sua release de normas de 2026, incluindo a eliminação dos endereços não estruturados, e disse que consultaria o setor antes de definir um novo calendário, com uma atualização prevista até dezembro. Em 9 de setembro, o conselho de gestão de esquemas do European Payments Council fez o mesmo para os cinco rulebooks SEPA: a data final de 15 de novembro foi retirada e uma nova será definida mais tarde.

Se a sua empresa envia ou recebe pagamentos internacionais, é tentador ler isto como «não há nada a fazer». Não é bem assim.

Texto livre, estruturado, híbrido: do que trata a mudança

As mensagens de pagamento modernas, baseadas na norma ISO 20022, têm um campo separado para cada parte de um endereço: rua, número, código postal, localidade, país. Os formatos mais antigos tinham algumas linhas de texto livre, e muitos pagamentos ainda enfiam a morada inteira nessas linhas, pela ordem que ocorreu a quem a escreveu.

O setor trabalha com três formatos:

• Não estruturado: a morada inteira como texto livre. É este que está a ser eliminado.
• Totalmente estruturado: cada elemento no seu próprio campo, com localidade e país como mínimo.
• Híbrido: localidade e país nos seus próprios campos, mais até duas linhas de texto livre com até 70 caracteres cada para o resto. Existe como ponte para organizações que ainda não conseguem dividir cada morada de forma limpa.

Para os bancos ao longo do percurso, o BIC continua a ser uma forma aceite de identificar o próprio banco. A mudança diz respeito sobretudo às pessoas e empresas nas duas pontas do pagamento: a sua empresa, os seus clientes, os seus fornecedores.

Porque importa onde fica o nome da rua

Uma morada em texto livre é fácil de ler para uma pessoa e incómoda para uma máquina. «Unit 4, 12 Harbour Road, Limassol 3035, CY» e «Cyprus, Limassol, Harbour Rd 12/4» são o mesmo local, mas um controlo automático tem de adivinhar que parte é a localidade e qual é o país. A triagem de sanções e a monitorização de branqueamento de capitais em cada banco da cadeia assentam nesses dados. Quando não podem ser lidos com confiança, o pagamento é retido para uma análise manual e alguém escreve a pedir esclarecimentos.

Os campos estruturados eliminam a maior parte das suposições. Um país no seu próprio campo pode ser verificado de imediato, e uma localidade no sítio certo não é confundida com parte do nome de uma empresa. O ganho: menos pagamentos retidos por perguntas e menos devolvidos. É por isso que a mudança continua a chegar, mesmo sem data.

Porque houve adiamento

Em resumo: o setor não estava preparado. Os números de preparação citados na altura apontavam para cerca de 61% dos pagamentos ainda com endereços não estruturados em abril de 2026, e grandes bancos e sistemas de pagamento nacionais pediram mais tempo. Mover o prazo foi reconhecer quantos dados ainda precisam de ser limpos. Não foi uma mudança de rumo. A J.P. Morgan, por exemplo, descreveu a decisão como reagendada, não abandonada.

A parte que lhe cabe

Os bancos podem refazer os seus formatos de mensagem. O que não conseguem fazer facilmente é corrigir uma morada que foi mal registada desde o início. A Swift foi explícita: os dados de endereço têm de estar corretos na origem, e para uma empresa a origem são normalmente os seus próprios registos: listas de fornecedores, ficheiros de clientes, modelos de fatura, os beneficiários guardados no homebanking.

É para isso que serve o tempo extra:

• Dividir as moradas em partes. Para cada contraparte habitual, guarde separadamente rua, número, código postal, localidade e país, e não um único bloco de texto.
• Usar códigos de país coerentes. «Germany», «DE» e «Deutschland» devem tornar-se um único valor, idealmente o código ISO de duas letras.
• Perguntar no onboarding. Quando um fornecedor enviar os dados bancários, peça ao mesmo tempo a morada registada dividida em partes. A maioria responde uma vez e nunca mais pensa nisso.
• Alinhar a documentação. O nome e a morada do beneficiário no pagamento devem coincidir com a fatura e o contrato. As discrepâncias são um motivo frequente de perguntas e, por vezes, de uma transferência devolvida.
• Verificar os seus próprios dados. A morada que os seus clientes veem quando lhe pagam deve ser a sua morada registada, escrita da mesma forma em todo o lado.
• Usar os campos disponíveis. Se um formulário de pagamento ou ficheiro de carregamento tiver campos separados para localidade e código postal, preencha-os em vez de pôr tudo na primeira linha.

Nada disto é difícil. É fastidioso, e envolve finanças, compras e quem cuida do sistema de contabilidade, e é exatamente por isso que fica para depois quando não há prazo.

O que isto significa hoje para os seus pagamentos

Nada nos seus pagamentos tem de mudar de um dia para o outro. Endereços não estruturados, híbridos e estruturados continuam todos válidos segundo a norma Swift atual, e os rulebooks SEPA continuam a permitir o formato não estruturado até o EPC definir uma nova data final. A atualização da Swift sobre o calendário está prevista até ao fim deste ano. Quando quer que cheguem as novas datas, é mais fácil já ter dados limpos do que começar a limpeza nessa altura.

Entretanto, dados desarrumados têm um custo próprio. Um pagamento retido enquanto um banco no percurso pergunta quem é o beneficiário, ou devolvido porque os dados não batem certo, custa tempo e muitas vezes comissões. Os pagamentos SWIFT podem passar por bancos correspondentes, e cada um faz os seus próprios controlos. O nosso guia sobre transferências devolvidas explica o que acontece quando os dados falham, e a nossa visão geral SEPA vs SWIFT explica quando se aplica cada via.

Onde entra a Polydirection

A Polydirection oferece contas e pagamentos internacionais para empresas com casos complexos: SEPA, SWIFT, IBAN multimoeda e Mastercard, geridos através de uma única conta e analisados individualmente. Empresas de cripto, jogo, forex e dating têm um gestor dedicado, não uma carta de recusa padrão.

Se paga a fornecedores e parceiros em muitos países, isso significa que há uma pessoa a quem perguntar quando um pagamento é retido ou os dados de uma contraparte parecem pouco claros. Se está a arrumar a forma como os seus dados de pagamento estão configurados, ou quer verificar o que um pagamento de saída precisa antes de o enviar, contacte-nos.

A Polydirection oferece contas Personal e Business para negócios de cripto, jogo, forex e dating — consulte a tabela de tarifas completa na página de tarifas.