Ao abrigo do DORA, as entidades financeiras comunicam o seu Registo de Informações (RoI) uma vez por ano à sua autoridade competente, utilizando os 15 modelos previstos no Regulamento de Execução (UE) n.º 2024/2956. A validação desses modelos tem-se revelado mais difícil do que o seu preenchimento. No "dry run" de 2024 realizado pelas Autoridades Europeias de Supervisão (ESAs), apenas 6,5 % dos registos passaram em todas as verificações de qualidade dos dados. Para o ciclo de 2026, a CSSF do Luxemburgo afirmou que as verificações seriam aplicadas a mais campos de dados e que um registo aceite no ano passado poderia ser rejeitado este ano. A boa notícia: os erros de validação do RoI ao abrigo da DORA raramente são misteriosos. Quase todos se devem a um número reduzido de causas, e cada causa tem um responsável natural na sua organização.

Tipos de erros de validação do Registo de Informação DORA

Resolva o erro antes de alterar qualquer coisa. O grupo indica-lhe se o problema está no ficheiro ou nos seus dados.

• Erros de empacotamento e erros técnicos. O ficheiro ZIP, a estrutura de pastas, os nomes dos ficheiros ou os indicadores de arquivo não correspondem às especificações, pelo que o ficheiro não pode ser processado. O código 808, "Faltam indicadores de arquivo ou o caso está errado", é típico: todos os 15 modelos têm de ser apresentados, mesmo os que estão vazios. Na lista de problemas comuns das ESA, estes erros levam à rejeição.

• Erros de campo e de dados. Falta um valor obrigatório, ou um identificador ou formato é inválido. A regra v8826_m, por exemplo, verifica se um identificador de entidade jurídica (LEI) tem 20 caracteres e termina com dois dígitos. Estas constatações, por si só, não rejeitam o ficheiro, mas a sua autoridade pode, ainda assim, solicitar-lhe que as corrija e que o reenvie.

• Erros de relação e consistência. Um registo remete para algo que não existe noutro modelo. O código 807, "Restrição de chave estrangeira violada", é o caso clássico: o próprio exemplo das ESAs é uma referência a um contrato no modelo B_07.01 que não existe no B_02.01. O ficheiro é rejeitado.

• Conclusões sobre a qualidade dos dados. Um registo pode passar em todas as verificações técnicas e, mesmo assim, suscitar dúvidas. Em abril de 2026, a Autoridade Bancária Europeia (EBA) realizou verificações adicionais da qualidade dos dados em todos os registos. Os exemplos do Banco Central da Irlanda incluem um código fictício para a empresa-mãe de última instância de um prestador e a menção "não aplicável" como nome de um prestador.

Seja qual for o grupo, anote o código de erro, o modelo (por exemplo, B_02.01), a linha, a coluna (por exemplo, c0010) e o valor que apresentou falha. O nosso RoI Validator gratuito apresenta a linha, a coluna e o valor da célula para cada resultado. O feedback da sua autoridade competente é enviado através do seu próprio portal e processo; por isso, guarde essa mensagem como referência para qualquer novo envio.

Todos os erros de validação do DORA levam à rejeição?

Não. A gravidade de uma constatação depende da regra, das regras de validação em vigor para esse ciclo e da forma como a autoridade competente a trata. Em termos gerais, aplicam-se três níveis:

• Erros de bloqueio. As verificações de pacotes, estruturas e chaves, tais como 103, 714, 720, 805, 807 e 808, rejeitam o envio. Deve corrigir os dados e enviar um novo pacote.

• Conclusões sem bloqueio. Regras como a v8886_m (valor obrigatório em falta), a v8826_m (formato LEI) e as verificações VR_ em relação à GLEIF não rejeitam o ficheiro por si só. A necessidade de reenviar o ficheiro depende da sua autoridade: a CSSF do Luxemburgo, por exemplo, espera que as entidades financeiras corrijam estes avisos e reenviem o ficheiro.

• Feedback sobre a qualidade dos dados. Este feedback surge após a validação técnica, frequentemente por parte da sua autoridade, e pode levar a um pedido para corrigir e reenviar um registo que já tinha sido aceite.

Uma regra também pode mudar de nível de um ciclo para o seguinte. Verifique o tipo de mensagem nas orientações atuais da sua autoridade antes de decidir se uma constatação requer uma nova apresentação.

Erros comuns no Registo de Informação DORA: causas, responsáveis e soluções

Os códigos abaixo provêm da lista de problemas comuns das ESAs e das orientações das autoridades nacionais. O seu validador ou autoridade poderá formulá-los de forma diferente.

Os identificadores requerem uma atenção especial. O regulamento de execução exige um LEI válido e ativo ou um Identificador Único Europeu (EUID), ou ambos, quando disponíveis, para cada prestador de serviços de TIC de terceiros que seja uma pessoa coletiva. Os prestadores estabelecidos fora da UE só podem ser identificados através do LEI.

Checklist para a validação do Registo de Informação DORA

Consulte esta lista antes de cada envio, e não apenas após uma rejeição:

• A entidade declarante, o nível de reporte (individual ou consolidado) e a data de referência estão corretos.

• Todas as entidades financeiras possuem um LEI válido e todos os prestadores de serviços de TIC externos possuem um LEI ou EUID válido.

• Os campos obrigatórios relativos a fornecedores, contratos, serviços de TIC e funções empresariais estão preenchidos.

• Todas as referências entre modelos estão corretas e todas as chaves estão preenchidas e são únicas.

• Os valores provisórios e genéricos foram substituídos ou explicados.

• O pacote segue o pacote técnico atual e a convenção de nomenclatura, incluindo todos os 15 modelos.

• Já validou a exportação final, analisou todos os avisos e atribuiu um responsável a todos os itens ainda pendentes.

• Conheça o prazo de apresentação, o portal e o procedimento de reenvio da sua entidade.

Para verificar a exportação final, carregue-a no nosso RoI Validator gratuito. Esta ferramenta realiza 294 verificações em todos os 15 relatórios no formato oficial xBRL-CSV, não requer registo e elimina os ficheiros após o processamento.

Valide o seu registo gratuitamente

Mantenha o registo atualizado após a submissão

A maioria dos erros de validação surge meses antes de alguém executar uma validação. Um contrato é renovado, mas o registo não. Um fornecedor altera a sua entidade jurídica. Um novo serviço de TIC entra em funcionamento sem uma função empresarial associada. Se o registo só receber atenção no primeiro trimestre, cada ciclo começa com a mesma limpeza.

O que evita isso é a atribuição de responsabilidades. Atribua a cada tipo de registo um responsável designado: o departamento de compras para os fornecedores e os seus identificadores, o departamento jurídico para os contratos, o departamento de TI para os serviços de TIC e o departamento de negócios para as funções que esses serviços suportam. São eles que atualizam o registo quando algo muda, e não quando começa o período de relatórios. Uma validação trimestral de uma exportação de teste permite então identificar os problemas enquanto as pessoas que conhecem a resposta ainda se lembram dela.

Isso trata o registo como dados operacionais, em vez de um ficheiro a reparar uma vez por ano, que é precisamente para isso que uma solução de Registo de Informação foi concebida.

Como isto se apresenta no Formalize. Fornecedores, contratos, serviços de TIC e funções empresariais são registos interligados num único sistema. Antes de exportar, um painel de verificação de dados mostra os dados obrigatórios em falta e as ligações interrompidas, e é possível clicar para aceder ao local onde cada problema se encontra. A exportação gera os 15 relatórios num único pacote, pronto para o RoI Validator.

Este artigo tem caráter meramente informativo e não constitui aconselhamento jurídico.