Endereços estruturados SEPA: o prazo de 15 de novembro de 2026 explicado
A partir de 15 de novembro de 2026, um endereço postal num pagamento SEPA terá de ser estruturado ou híbrido, caso contrário o seu banco rejeitará o ficheiro. O que muda, porque é que o gatilho é a data de execução contida no ficheiro, e como verificar um pain.001 ou um pain.008 já hoje.
O que muda para os endereços SEPA a 15 de novembro de 2026?
A partir de 15 de novembro de 2026, se uma transferência a crédito SEPA (pain.001) ou um débito direto (pain.008) contiver um endereço postal para o devedor ou o credor, esse endereço terá de ser estruturado ou híbrido — deixa de poder ser um endereço em texto livre composto apenas por elementos AdrLine. Um endereço estruturado fornece cada componente na sua própria etiqueta (localidade, país, rua, número de porta, código postal) sem nenhum AdrLine; um endereço híbrido conserva no máximo dois AdrLine de 70 caracteres, mas tem ainda de acrescentar o nome da localidade (TwnNm) e o país (Ctry). O país por si só não basta: o nome da localidade é o critério discriminante. Se o endereço não for estruturado, o banco tem de rejeitar a instrução. O gatilho é a data de execução ou de cobrança contida no ficheiro, e não a data de hoje — um ficheiro produzido agora para uma execução em novembro já não está conforme.
Valide o seu ficheiro agora
Grátis, instantâneo e 100% no seu navegador - nenhum ficheiro é enviado.
O que muda realmente a 15 de novembro de 2026
Os rulebooks do Conselho Europeu de Pagamentos que regem a transferência SEPA, o débito direto SEPA e o OCT Inst fazem os endereços postais passar do texto livre para dados estruturados. Esta alteração é descrita no EPC153-22 (« Provision of Addresses under the EPC Payment Schemes », versão 2.1) e entra em vigor a 15 de novembro de 2026 — uma data que o EPC alinhou com a Swift Standards MX Release de novembro de 2026, prevista para o segundo fim de semana completo do mês.
Até agora, podia descrever o endereço de uma parte como uma ou duas linhas de texto livre — o elemento AdrLine — e o banco aceitava-o. A partir da data-limite, um endereço fornecido para o devedor ou o credor terá de ser legível por máquina: totalmente estruturado ou híbrido. Se não for nem uma coisa nem outra, o prestador de serviços de pagamento tem de rejeitar a instrução. Nada o obriga a fornecer um endereço; a regra só se aplica quando um endereço está presente.
Não se trata de um simples retoque cosmético. O EPC observa que apenas os campos estruturados Cidade e País são necessários para o filtro regulamentar (regulatory screening) e que os endereços estruturados reduzem os erros de processamento, de filtragem e de reconciliação — aumentando o processamento ponta a ponta. A SEPA alinha as suas próprias mensagens com a direção que o resto do mundo dos pagamentos já está a seguir.
Estruturado, híbrido ou não estruturado
O rulebook reconhece três formas de endereço postal. Saber qual delas o seu ficheiro utiliza é tudo o que está em jogo: duas passam após a data-limite, uma não.
Estruturado — passa
Cada componente ocupa o seu próprio elemento: StrtNm (rua), BldgNb (número de porta), PstCd (código postal), TwnNm (localidade), Ctry (país). Nenhum AdrLine. TwnNm e Ctry são obrigatórios.
Híbrido — passa
Conserva até dois AdrLine de no máximo 70 caracteres para a parte da rua, mas tem também de acrescentar TwnNm e Ctry como elementos próprios. É a via de migração pragmática para os sistemas que não conseguem decompor totalmente um endereço.
Não estruturado — rejeitado
Apenas elementos AdrLine (eventualmente com Ctry), sem TwnNm. É o clássico endereço em texto livre. A partir de 15 de novembro de 2026 deixa de ser aceite e o banco tem de rejeitar o ficheiro.
TwnNm é o critério discriminante
Acrescentar apenas Ctry não torna um endereço estruturado. A presença de um verdadeiro nome de localidade em TwnNm é o que indica ao banco que o endereço é legível por máquina. Sem ele, o endereço conta como não estruturado.
Não estruturado: rejeitado a partir de 15 de novembro de 2026
<PstlAdr> <Ctry>BE</Ctry> <AdrLine>Rue de la Loi 1</AdrLine> <AdrLine>1000 Bruxelles</AdrLine> </PstlAdr>
Híbrido: aceite (TwnNm + Ctry + no máximo 2 AdrLine)
<PstlAdr> <TwnNm>Bruxelles</TwnNm> <Ctry>BE</Ctry> <AdrLine>Rue de la Loi 1</AdrLine> </PstlAdr>
Estruturado: aceite, e recomendado pelo EPC
<PstlAdr> <StrtNm>Rue de la Loi</StrtNm> <BldgNb>1</BldgNb> <PstCd>1000</PstCd> <TwnNm>Bruxelles</TwnNm> <Ctry>BE</Ctry> </PstlAdr>
O primeiro exemplo é o que mais engana: o país está presente e a localidade aparece no texto, mas está enterrada dentro de um AdrLine. Sem qualquer elemento TwnNm, o banco lê um endereço não estruturado e rejeita a instrução.
O gatilho é a data no ficheiro — e o âmbito é estreito
A parte mais mal compreendida desta regra é o calendário. A data-limite não é avaliada em relação à data de hoje; é avaliada em relação à data de execução solicitada (ReqdExctnDt) de uma transferência, ou à data de cobrança solicitada (ReqdColltnDt) de um débito direto, contida no ficheiro. Um lote que constrói hoje cuja data de execução caia a 15 de novembro de 2026 ou depois já não está conforme hoje — as ordens permanentes e os débitos diretos enviados vários dias ou semanas antecipadamente entram no âmbito muito antes de o calendário chegar a novembro.
O perímetro é mais restrito do que se imagina. O requisito incide sobre o endereço do pagador e do beneficiário — o devedor (Dbtr) e o credor (Cdtr) num pain.001 ou num pain.008. O EPC153-22 trata apenas dessas partes: nada diz sobre as partes últimas (UltmtDbtr, UltmtCdtr), a parte iniciadora (InitgPty) nem os agentes; bloquear o endereço em texto livre de uma parte última vai, portanto, além do que o guia exige.
Atenção a uma última fonte de confusão: 15 de novembro de 2026 é a data SEPA, determinada pelos rulebooks EPC dos pain.001 e pain.008. Não é a migração SWIFT CBPR+, que rege as mensagens interbancárias pacs que os bancos trocam entre si num circuito diferente e cuja coexistência MT/ISO 20022 já terminou em novembro de 2025. Se só enviar ficheiros SEPA através do seu banco, é a data SEPA que o diz respeito.
Como tornar o seu ficheiro SEPA conforme
Colocar um pain.001 ou um pain.008 em conformidade é mecânico assim que a regra é compreendida. Estes quatro passos fazem passar um endereço de não estruturado a conforme, e pode confirmar o resultado localmente antes do envio.
- 1
Localizar cada endereço postal Dbtr e Cdtr
Olhe dentro do elemento PstlAdr de cada bloco de devedor e de credor. Ignore as partes últimas, a parte iniciadora e os agentes — estão fora do âmbito desta regra.
- 2
Acrescentar TwnNm e Ctry como elementos próprios
O nome da localidade em TwnNm e o código de país ISO em Ctry formam o par obrigatório. Acrescentar Ctry sem TwnNm deixa o endereço não estruturado.
- 3
Escolher estruturado ou híbrido para o resto
Ou decompõe a rua em StrtNm, BldgNb e PstCd sem nenhum AdrLine (totalmente estruturado), ou conserva no máximo dois AdrLine de 70 caracteres ao lado de TwnNm e Ctry (híbrido). Nunca exceda dois AdrLine nem 70 caracteres.
- 4
Validar em relação à data de execução, não ao dia atual
Verifique o ficheiro com o ReqdExctnDt ou o ReqdColltnDt que ele realmente contém. Se essa data for 15 de novembro de 2026 ou posterior, um endereço não estruturado é um erro bloqueante; antes disso, um simples aviso. A ValidateFin aplica exatamente esta lógica no seu navegador.
- 5
Verifique com o seu banco as instruções com data futura
Se o seu software submete instruções com data futura — em particular as ordens permanentes — pergunte ao seu banco como tratará aquelas já enviadas com uma data de execução igual ou posterior a 15 de novembro de 2026. Os débitos diretos comuns costumam ser submetidos apenas algumas semanas antes do vencimento: para esses, ainda há tempo.
Verifique o formato dos seus endereços antes do prazo
Não espere por um lote rejeitado para descobrir um endereço não estruturado. A ValidateFin lê a data de execução contida no seu pain.001 ou pain.008, verifica cada endereço de devedor e de credor face ao EPC153-22, e indica-lhe se passará a 15 de novembro de 2026 — tudo localmente, sem que nada saia da sua máquina.
Abrir o validador SEPAFonte oficial
A regra provém do guia do European Payments Council «Provision of Addresses under the EPC Payment Schemes» (EPC153-22 v2.1): secção 6.3 para a data de 15 de novembro de 2026, e secção 7.4 para a regra da data de execução. Cite-a se precisar de convencer alguém internamente.
EPC153-22 v2.1 — Provision of Addresses under the EPC Payment Schemes (PDF)Perguntas frequentes
O que acontece exatamente a 15 de novembro de 2026?
A partir dessa data, se uma transferência a crédito SEPA (pain.001) ou um débito direto (pain.008) contiver um endereço postal para o devedor ou o credor, o endereço tem de ser estruturado ou híbrido. Um endereço puramente em texto livre (apenas AdrLine, sem TwnNm) é rejeitado pelo banco. Se não for fornecido nenhum endereço, nada muda.
Qual é a diferença entre um endereço estruturado e um endereço híbrido?
Um endereço estruturado coloca cada componente no seu próprio elemento (StrtNm, BldgNb, PstCd, TwnNm, Ctry) sem nenhum AdrLine. Um endereço híbrido conserva até dois AdrLine de no máximo 70 caracteres para a parte da rua, mas tem ainda de acrescentar TwnNm e Ctry. Ambos são aceites após a data-limite.
É obrigatório fornecer um endereço postal?
Não. A regra não o obriga a acrescentar um endereço. Diz apenas que, se fornecer um para o devedor ou o credor, este tem de ser estruturado ou híbrido. Um endereço simplesmente ausente não gera qualquer erro.
Porque é que acrescentar o país não resolve o problema?
Porque o nome da localidade (TwnNm) é o critério discriminante, não o país. Um endereço em texto livre apenas com AdrLine e Ctry continua não estruturado. Tem de acrescentar um verdadeiro TwnNm — e Ctry — para que o endereço conte como estruturado ou híbrido.
O prazo depende da data de hoje ou da data de pagamento?
Da data de pagamento contida no ficheiro. O gatilho é a data de execução solicitada (ReqdExctnDt) para as transferências ou a data de cobrança solicitada (ReqdColltnDt) para os débitos diretos. Um ficheiro construído hoje para uma execução em novembro já não está conforme, o que é importante para as ordens permanentes e os débitos diretos pré-enviados.
Que partes são afetadas?
O endereço do pagador e do beneficiário, ou seja, o devedor (Dbtr) e o credor (Cdtr). O EPC153-22 cobre apenas essas partes e permanece omisso sobre as partes últimas (UltmtDbtr, UltmtCdtr), a parte iniciadora (InitgPty) e os agentes: tratar o endereço em texto livre de uma parte última como um erro bloqueante vai além do guia.
É o mesmo que a migração SWIFT ISO 20022?
Não. 15 de novembro de 2026 é a data SEPA, proveniente dos rulebooks EPC dos pain.001 e pain.008. SWIFT CBPR+ é um circuito diferente — as mensagens interbancárias pacs que os bancos trocam entre si — e o seu período de coexistência MT/ISO 20022 já terminou em novembro de 2025. Para os ficheiros SEPA enviados através do seu banco, é a data SEPA que se aplica.
Como posso verificar o meu ficheiro já?
Cole o seu pain.001 ou pain.008 no validador SEPA da ValidateFin. Ele lê a data de execução ou de cobrança do ficheiro, inspeciona cada endereço de devedor e de credor face ao EPC153-22, e assinala um erro bloqueante se a data for 15 de novembro de 2026 ou posterior, ou um aviso se for anterior — tudo no seu navegador, sem qualquer envio.
E as ordens permanentes já submetidas com data de novembro de 2026?
É o único caso a tratar desde já. Uma instrução com data futura — uma ordem permanente em particular — já depositada no seu banco com uma data de execução igual ou posterior a 15 de novembro de 2026 leva o seu endereço segundo a nova regra. Verifique com o seu banco como tratará as instruções já submetidas. Os débitos diretos comuns são geralmente enviados apenas algumas semanas antes do vencimento, pelo que entram no âmbito mais perto da data-limite.