6.9.2022

Jornal Oficial da União Europeia

L 231/1

REGULAMENTO DE EXECUÇÃO (UE) 2022/1463 DA COMISSÃO

de 5 de agosto de 2022

que estabelece especificações técnicas e operacionais do sistema técnico para o intercâmbio automatizado transfronteiriço de elementos de prova e a aplicação do princípio da declaração única, em conformidade com o Regulamento (UE) 2018/1724 do Parlamento Europeu e do Conselho

(Texto relevante para efeitos do EEE)

A COMISSÃO EUROPEIA,

Tendo em conta o Tratado sobre o Funcionamento da União Europeia,

Tendo em conta o Regulamento (UE) 2018/1724 do Parlamento Europeu e do Conselho, de 2 de outubro de 2018, relativo à criação de uma plataforma digital única para a prestação de acesso a informações, a procedimentos e a serviços de assistência e de resolução de problemas, e que altera o Regulamento (UE) n.o 1024/2012 (1), nomeadamente o artigo 14.o, n.o 9,

Considerando o seguinte:

(1)

O artigo 14.o, n.o 1, do Regulamento (UE) 2018/1724 exige que a Comissão, em cooperação com os Estados-Membros, estabeleça um sistema técnico para o intercâmbio de elementos de prova, tal como exigido para os procedimentos em linha enumerados no anexo II do mesmo regulamento e para os procedimentos previstos nas Diretivas 2005/36/CE (2), 2006/123/CE (3), 2014/24/UE (4) e 2014/25/UE (5) do Parlamento Europeu e do Conselho.

(2)

As especificações técnicas e operacionais do Sistema técnico de declaração única (ou STDU, sistema técnico de declaração única) constantes do presente regulamento devem estabelecer os principais componentes da arquitetura do STDU, definir as funções e obrigações técnicas e operacionais da Comissão, dos Estados-Membros, dos requerentes de elementos de prova, dos emitentes de elementos de prova e das plataformas de mediação. Além disso, estas especificações devem estabelecer um sistema de registo para monitorizar os intercâmbios e definir a responsabilidade pela manutenção, funcionamento e segurança do STDU.

(3)

A fim de permitir a criação do STDU até à data prevista no Regulamento (UE) 2018/1724, prevê-se complementar o presente regulamento com documentos de conceção técnica mais pormenorizados e não vinculativos, elaborados de forma consensual pela Comissão, em cooperação com os Estados-Membros, no âmbito do grupo de coordenação da plataforma e em conformidade com as orientações da Comissão para a aplicação do programa de trabalho 2021-2022 do Regulamento Plataforma Digital Única. No entanto, se tal for considerado necessário à luz de novos desenvolvimentos técnicos ou de debates ou divergências de opinião no âmbito do grupo de coordenação da plataforma, nomeadamente sobre a finalização dos documentos de projeto técnico e as principais opções de conceção, ou quando for necessário tornar obrigatórios determinados elementos dos documentos de conceção técnica, será possível complementar/alterar as especificações técnicas e operacionais estabelecidas no presente regulamento em conformidade com o procedimento de exame a que se refere o artigo 37.o, n.o 2, do Regulamento (UE) 2018/1724.

(4)

A fim de reduzir os custos e o tempo necessário para o estabelecimento do STDU, a arquitetura deste deve, na medida do possível, basear-se em soluções reutilizáveis, ser tecnologicamente neutra e ter em conta diferentes soluções nacionais. Por exemplo, o STDU deve poder utilizar os portais de procedimentos, serviços de dados ou plataformas de mediação existentes a nível nacional, incluindo a nível central, regional e local, que tenham sido criados para utilização nacional. Os componentes desenvolvidos pela Comissão devem ser divulgados ao abrigo de uma licença de software aberto que promova a reutilização e a colaboração.

(5)

Uma dessas soluções reutilizáveis desenvolvida a nível da União é o sistema de nós eIDAS estabelecido no Regulamento de Execução (UE) 2015/1501 da Comissão (6), que, ao permitir a comunicação com outros nós da rede eIDAS, pode tratar o pedido e a disponibilização de autenticação transfronteiriça de um utilizador. Os nós eIDAS devem permitir que os requerentes de elementos de prova e, se for caso disso, os emitentes de elementos de prova identifiquem os utilizadores que solicitam o intercâmbio de elementos de prova através do STDU, para que os emitentes de elementos de prova possam comparar os dados de identificação com os seus registos existentes.

(6)

O STDU deve continuar o trabalho já realizado e explorar sinergias com outros sistemas existentes para o intercâmbio de elementos de prova ou de informações entre as autoridades relevantes para os procedimentos a que se refere o artigo 14.o, n.o 1, do Regulamento (UE) 2018/1724, incluindo sistemas não abrangidos pelo artigo 14.o, n.o 10, do mesmo regulamento. Por exemplo, no que diz respeito aos dados do registo de veículos e cartas de condução, o STDU deve ter em conta os modelos de dados já desenvolvidos e, sempre que possível, estabelecer pontes técnicas para facilitar a ligação ao STDU das autoridades competentes que já utilizam outras redes existentes (RESPER (7) ou EUCARIS (8)) para a apresentação de elementos de prova nos procedimentos abrangidos pelo STDU. Deve adotar-se uma abordagem semelhante em relação a outros sistemas, tais como, mas não apenas: o Emrex User Group (EUG) (9) no domínio do ensino, o Intercâmbio Eletrónico de Informações de Segurança Social (EESSI) nos termos do Regulamento (CE) n.o 987/2009 do Parlamento Europeu e do Conselho (10) para a segurança social, o Sistema Europeu de Informação sobre Registos Criminais estabelecido pela Decisão 2009/316/JAI (11) para fins de cooperação judiciária e o eCertis (12), utilizado em procedimentos de contratação pública. A cooperação entre estes sistemas e o STDU deve ser definida caso a caso.

(7)

Para efeitos da autenticação transfronteiriça de um utilizador, a arquitetura do STDU deve ser harmonizada com o Regulamento (UE) n.o 910/2014 do Parlamento Europeu e do Conselho (13). Em 3 de junho de 2021, a Comissão adotou uma recomendação relativa a um conjunto de instrumentos comuns da União para uma abordagem coordenada com vista a um Quadro Europeu para a Identidade Digital (14). Esta recomendação estabelece um processo estruturado de cooperação entre os Estados-Membros, a Comissão e, se for caso disso, os operadores do setor privado, para trabalhar nos aspetos técnicos do Quadro Europeu para a Identidade Digital. A fim de assegurar o necessário alinhamento entre esse processo e o STDU, a Comissão deve assegurar uma coordenação adequada, em especial através do grupo de contacto «Sinergias e Interoperabilidade», entre a rede de cooperação criada pela Decisão de Execução (UE) 2015/296 da Comissão (15) e o grupo de coordenação da plataforma.

(8)

A fim de garantir a segurança dos serviços transfronteiriços de envio eletrónico para efeitos do STDU, os Estados-Membros devem assegurar que esses serviços cumprem os requisitos aplicáveis aos serviços de envio registado eletrónico, estabelecidos no artigo 44.o do Regulamento (UE) n.o 910/2014. Para este efeito, é conveniente que o STDU utilize pontos de acesso à plataforma eDelivery para criar uma rede de nós para o intercâmbio seguro de dados digitais. Para além de permitir um envio transfronteiriço seguro, o eDelivery oferece funcionalidades de serviço de metadados que podem apoiar futuras versões do STDU com um maior número de nós de intercâmbio seguro de dados. Nesse quadro, os Estados-Membros deverão poder escolher os fornecedores do seu software eDelivery.

(9)

A fim de assegurar a flexibilidade na aplicação do presente regulamento, os Estados-Membros deverão poder optar por ter um ou vários pontos de acesso à plataforma eDelivery como parte do STDU. Um Estado-Membro deve portanto poder implantar um ponto de acesso único capaz de gerir todas as mensagens na plataforma eDelivery relacionadas com o STDU aos requerentes ou emitentes de elementos de prova através de uma plataforma de mediação, consoante o caso, ou, em alternativa, implantar vários pontos de acesso a qualquer nível hierárquico ou para domínios ou setores ou níveis geográficos específicos das suas administrações públicas.

(10)

De acordo com o direito da União, incluindo as Diretivas 2005/36/CE, 2006/123/CE, 2014/24/UE e 2014/25/UE e o Regulamento (UE) 2018/1724, determinados procedimentos administrativos devem ser disponibilizados aos utilizadores em linha. Uma vez que esses procedimentos e os elementos de prova exigidos não estão harmonizados no direito da União, deverão ser criados serviços comuns para permitir o intercâmbio transfronteiriço de elementos de prova necessários para esses procedimentos através do STDU.

(11)

Caso não haja acordo quanto a um tipo de elementos de prova harmonizado em toda a União e que todos os Estados-Membros possam fornecer, um serviço de mediação de elementos de prova deverá ajudar a determinar quais os tipos de elementos de prova que podem ser aceites para um determinado procedimento.

(12)

O serviço de mediação de elementos de prova deve basear-se no conteúdo das regras fornecidas pelos Estados-Membros e deve proporcionar um mecanismo em linha para os Estados-Membros consultarem os seus requisitos de informação e conjuntos de tipos de elementos de prova. O serviço de mediação de elementos de prova deve permitir aos Estados-Membros gerir e partilhar informações sobre as regras relativas aos tipos de elementos de prova.

(13)	Nos casos em que seja necessária interoperabilidade entre o portal de procedimentos e os serviços de dados e os serviços comuns, essa interoperabilidade deve ser apoiada por documentos de conceção técnica.

(14)

O presente regulamento deve especificar quando os elementos de prova estruturados e não estruturados exigidos para os procedimentos enumerados no artigo 14.o, n.o 1, do Regulamento (UE) 2018/1724 são considerados legalmente emitidos em formato eletrónico que permite o intercâmbio automático. Os elementos de prova não estruturados emitidos num formato eletrónico podem ser intercambiados através do STDU se forem complementados pelos elementos de metadados do modelo de metadados genérico STDU contido no repositório semântico a que se refere o artigo 7.o, n.o 1, do presente regulamento. Os elementos de prova estruturados podem ser intercambiados através do STDU se forem complementados pelos elementos de metadados do modelo de metadados genérico do STDU a que se refere o artigo 7.o, n.o 1, do presente regulamento e estiverem em conformidade com o modelo de dados do STDU para o tipo de prova relevante, tal como referido no artigo 7.o, n.o 2, do presente regulamento, ou acompanhados de uma versão legível pelo ser humano.

(15)

Os Estados-Membros devem ser livres de determinar quando convertem elementos de prova num formato eletrónico que permita o seu intercâmbio automatizado através do STDU. No entanto, a fim de aumentar a utilidade do STDU para os seus utilizadores e uma vez que a utilização de modelos de dados e de esquemas de metadados tanto para formatos não estruturados como estruturados é, de um modo geral, altamente recomendada, a Comissão deve apoiar os Estados-Membros nos seus esforços para alcançar este objetivo.

(16)

A fim de evitar duplicações, assegurar sinergias e proporcionar escolhas aos utilizadores, o desenvolvimento de modelos de dados do STDU para tipos de elementos estruturados e a normalização dos casos de utilização para o fornecimento de credenciais em conformidade com o processo estruturado previsto na Recomendação (UE) 2021/946 da Comissão, de 3 de junho de 2021, relativa a um conjunto de instrumentos comuns da União para uma abordagem coordenada com vista a um Quadro Europeu para a Identidade Digital (16), devem ser realizados em estreita cooperação e alinhamento entre si no que diz respeito aos elementos de prova abrangidos pelo artigo 14.o do Regulamento (UE) 2018/1724, nomeadamente através da identificação de casos de utilização comum. O alinhamento dos modelos de dados do STDU e dos casos de utilização normalizados ao abrigo da referida recomendação da Comissão deve permitir que os utilizadores se baseiem em meios alternativos para a apresentação dos elementos de prova abrangidos pelo artigo 14.o do Regulamento (UE) 2018/1724, independentemente ou em combinação com o STDU. Sempre que sejam introduzidas alterações nos modelos de dados e esquemas de metadados para elementos de prova, contidos no repositório semântico, os Estados-Membros devem dispor de um prazo de 12 meses a contar da adoção de qualquer atualização para aplicar quaisquer alterações aos elementos de prova em causa.

(17)

Para minimizar a quantidade de dados intercambiados, no caso de elementos estruturados, se apenas for solicitado um subconjunto de dados no pedido de elementos de prova, o emitente de elementos de prova ou uma plataforma de mediação, consoante o caso, poderá permitir a filtragem automatizada dos dados e, se necessário para a transferência, a transformação dos dados em nome do responsável pelo tratamento dos dados, de modo que apenas os dados solicitados sejam intercambiados.

(18)

Nos casos em que os Estados-Membros gerem registos e serviços nacionais que desempenham um papel idêntico ou equivalente ao do registo de serviços de dados ou do serviço de mediação de elementos de prova, não devem ser obrigados a uma duplicação do seu trabalho através de contributos para os serviços comuns pertinentes. No entanto, nesse caso, devem assegurar que os seus serviços nacionais estão ligados aos serviços comuns de modo a que possam ser utilizados por outros Estados-Membros. Em alternativa, esses Estados-Membros devem poder copiar os dados pertinentes dos registos ou serviços nacionais para o registo de serviços de dados ou serviço de mediação de elementos de prova.

(19)

Na Declaração de Taline de 2017 sobre a administração pública em linha (17), os Estados-Membros reafirmaram o seu compromisso de avançar na ligação dos seus serviços públicos em linha e de aplicar o princípio da declaração única, a fim de prestar serviços públicos digitais eficientes e seguros que facilitem a vida dos cidadãos e das empresas. A Declaração de Berlim de 2020 sobre a Sociedade Digital e a Administração Digital Baseada em Valores (18), assente nos princípios da centralidade dos utilizadores e da facilidade de utilização, e estabeleceu outros princípios fundamentais em que se devem basear os serviços públicos digitais, incluindo a confiança e a segurança nas interações da administração pública digital e a soberania e interoperabilidade digitais. O presente regulamento deve implementar esses compromissos, colocando os utilizadores no centro do sistema e exigindo que os utilizadores sejam informados sobre o STDU, as suas etapas e as consequências da utilização do sistema.

(20)

É importante que haja um sistema adequado que permita aos utilizadores identificarem-se para efeitos de intercâmbio de elementos de prova. O único quadro de reconhecimento mútuo de meios nacionais de identificação eletrónica a nível da União é estabelecido no Regulamento (UE) n.o 910/2014. Os meios de identificação eletrónica emitidos ao abrigo de sistemas de identificação eletrónica notificados em conformidade com esse regulamento devem, por conseguinte, ser utilizados pelos requerentes de elementos de prova para autenticar a identidade de um utilizador antes de este solicitar expressamente a utilização do STDU. Sempre que a identificação do emitente de elementos de prova relevante exija o fornecimento de atributos para além dos atributos obrigatórios do conjunto mínimo de dados enumerados no anexo do Regulamento de Execução (UE) 2015/1501, esses atributos adicionais devem também ser solicitados ao utilizador pelo requerente de elementos de prova e fornecidos ao emitente de elementos de prova ou à plataforma de mediação, consoante o caso, como parte do pedido de elementos de prova.

(21)

Alguns dos procedimentos enumerados no artigo 14.o, n.o 1, do Regulamento (UE) 2018/1724 exigem que os elementos de prova possam ser solicitados em nome de uma pessoa singular ou coletiva. Por exemplo, certos procedimentos são relevantes para as empresas e os empresários devem, por conseguinte, poder solicitar o intercâmbio de elementos de prova por conta própria ou através de um representante. O Regulamento (UE) n.o 910/2014 estabelece um quadro jurídico fiável para os meios de identificação eletrónica emitidos para pessoas coletivas ou pessoas singulares que representem pessoas coletivas. O reconhecimento mútuo dos meios nacionais de identificação eletrónica nos termos desse regulamento aplica-se a estes casos de representação. O presente regulamento deverá, por conseguinte, basear-se no Regulamento (UE) n.o 910/2014 e em quaisquer atos de execução adotados com base no mesmo, para a identificação dos utilizadores em caso de representação. O grupo de coordenação da plataforma e os seus subgrupos devem cooperar estreitamente com as estruturas de governação criadas ao abrigo do Regulamento (UE) n.o 910/2014, a fim de ajudar a desenvolver soluções para os poderes de representação e os mandatos. Uma vez que alguns dos procedimentos abrangidos pelo STDU assentam no quadro criado pelo Regulamento (UE) n.o 910/2014, os elementos de prova solicitados pelos representantes devem também poder ser processados através do STDU quando e na medida em que essas soluções tenham sido encontradas.

(22)

A fim de reduzir o tempo e os custos de implementação do STDU e de partilhar os benefícios da experiência de aplicação, a Comissão deve apoiar os Estados-Membros e promover a colaboração entre estes no desenvolvimento de soluções técnicas e componentes reutilizáveis que possam ser utilizados para implementar portais de procedimentos nacionais, funções de pré-visualização e serviços de dados.

(23)

A fim de garantir que os utilizadores mantêm constantemente o controlo sobre os seus dados pessoais quando utilizam o STDU, tal como previsto no Regulamento (UE) 2018/1724, estes devem permitir que os utilizadores expressem a sua decisão em relação a esses dados em dois casos. Primeiro, deve garantir-se que os utilizadores recebem informações suficientes que lhes permitam apresentar um pedido informado e expresso de tratamento do seu pedido de elementos de prova através do STDU, em conformidade com o artigo 14.o, n.o 3, alínea a), e com o artigo 14.o, n.o 4, do Regulamento (UE) 2018/1724. Deve depois garantir-se que podem visualizar os elementos de prova do intercâmbio numa função segura de pré-visualização antes de decidirem se devem ou não proceder ao intercâmbio de elementos de prova em conformidade com o artigo 14.o, n.o 3, alínea f), do Regulamento (UE) 2018/1724, exceto nos casos referidos no artigo 14.o, n.o 5, do mesmo regulamento.

(24)

A responsabilidade pela criação do STDU é partilhada entre os Estados-Membros e a Comissão, pelo que o grupo de coordenação da plataforma deve desempenhar um papel central na governação do sistema. Tendo em conta a natureza técnica do seu trabalho e a fim de facilitar a aplicação, nos sistemas nacionais existentes, dos documentos de conceção técnica, o trabalho do grupo de coordenação da plataforma deve ser apoiado e preparado por peritos reunidos num ou vários subgrupos criados em conformidade com o seu regulamento interno. O funcionamento desta governação do STDU deve ser avaliado no relatório que a Comissão está obrigada a apresentar ao Parlamento Europeu e ao Conselho até 12 de dezembro de 2022, nos termos do artigo 36.o do Regulamento (UE) 2018/1724.

(25)

A fim de assegurar uma reação rápida a eventuais incidentes e interrupções do serviço que possam afetar o funcionamento do STDU, os Estados-Membros e a Comissão devem criar uma rede de pontos de contacto para apoio técnico. A fim de assegurar o bom funcionamento do STDU, esses pontos de contacto para apoio técnico deverão dispor de poderes e de recursos humanos e financeiros suficientes para poderem desempenhar as suas funções.

(26)

A fim de assegurar o funcionamento e a manutenção eficientes do STDU, as responsabilidades pelos seus diferentes componentes devem ser claramente repartidas. A Comissão, enquanto proprietária e operadora dos serviços comuns, deve ser responsável pela sua manutenção, alojamento e segurança. Cada Estado-Membro deve ser responsável por assegurar a manutenção e a segurança dos componentes do STDU de que são proprietários e pelos quais são responsáveis, como os nós eIDAS, os pontos de acesso à plataforma eDelivery ou os registos nacionais, em conformidade com o direito aplicável nacional e da União.

(27)

A fim de assegurar uma proteção adequada dos dados pessoais, tal como exigido pelo Regulamento (UE) 2016/679 do Parlamento Europeu e do Conselho (19), o presente regulamento deve especificar o papel dos Estados-Membros, em especial o papel das respetivas autoridades competentes na sua qualidade de requerente de elementos prova ou de emitente de elementos de prova, e das plataformas de mediação, consoante o caso, em relação aos dados pessoais contidos nos elementos de prova trocados através do STDU.

(28)	A fim de assegurar a proteção dos serviços comuns contra potenciais ameaças que prejudiquem a confidencialidade, a integridade ou a disponibilidade dos sistemas de comunicação e informação da Comissão, a Decisão (UE, Euratom) 2017/46 da Comissão (20) deve aplicar-se a esses serviços.

(29)	O artigo 14.o, n.os 1 a 8 e n.o 10, do Regulamento (UE) 2018/1724 são aplicáveis a partir de 12 de dezembro de 2023. Por conseguinte, os requisitos estabelecidos no presente regulamento devem ser igualmente aplicáveis a partir dessa data.

(30)	A Autoridade Europeia para a Proteção de Dados foi consultada em conformidade com o disposto no artigo 42.o, n.o 1, do Regulamento (UE) 2018/1725 do Parlamento Europeu e do Conselho (21) e apresentou observações formais em 6 de maio de 2021 (22).

(31)	As medidas previstas no presente regulamento estão em conformidade com o parecer do Comité da Plataforma Digital Única,

ADOTOU O PRESENTE REGULAMENTO:

SECÇÃO 1

DISPOSIÇÕES GERAIS

Artigo 1.o

Definições

Para efeitos do presente regulamento, entende-se por:

1)	«Sistema técnico de declaração única» («STDU»), o sistema técnico para o intercâmbio automatizado transfronteiriço de elementos de prova a que se refere o artigo 14.o, n.o 1, do Regulamento (UE) 2018/1724;

2)	«Emitente de elementos de prova», uma autoridade competente na aceção do artigo 14.o, n.o 2, do Regulamento (UE) 2018/1724, que emite legalmente elementos estruturados ou não estruturados;

3)	«Requerente de elementos de prova», uma autoridade competente responsável por um ou mais dos procedimentos referidos no artigo 14.o, n.o 1, do Regulamento (UE) 2018/1724;

«Ponto de acesso à plataforma eDelivery», um componente de comunicação que faz parte do serviço de envio eletrónico eDelivery, com base em especificações e normas técnicas, incluindo o protocolo de mensagens AS4 e os respetivos serviços auxiliares desenvolvidos no âmbito do programa do Mecanismo Interligar a Europa e prosseguidos no âmbito do Programa Europa Digital, na medida em que essas especificações e normas técnicas se sobreponham à norma ISO 15000-2;

5)	«Nó eIDAS», um nó tal como definido no artigo 2.o, ponto 1), do Regulamento de Execução (UE) 2015/1501 e que cumpre os requisitos técnicos e operacionais estabelecidos nesse regulamento e com base nesse regulamento;

«Plataforma de mediação», uma solução técnica que atua por si própria ou por conta de outras entidades, tais como emitentes ou requerentes de elementos de prova, em função da organização administrativa dos Estados-Membros em que a plataforma de mediação opera, e através da qual os emitentes ou requerentes de elementos de prova se ligam aos serviços comuns a que se refere o artigo 4.o, n.o 1, ou a emitentes ou requerentes de elementos de prova de outros Estados-Membros;

7)	«Registo de serviços de dados», um registo que contém a lista de emitentes de elementos de prova e os tipos de elementos de prova que emitem, juntamente com as informações de acompanhamento pertinentes;

8)	«Serviço de mediação de elementos de prova», um serviço que permite a um requerente de elementos de prova determinar o tipo de elementos de prova proveniente de outro Estado-Membro que satisfaz o requisito de elemento de prova para efeitos de um procedimento nacional;

9)	«Meio de identificação eletrónica»: uma unidade material e/ou imaterial que contenha os dados de identificação pessoal e que seja utilizada para autenticação de um serviço em linha;

10)

«Repositório semântico», um conjunto de especificações semânticas, associado ao serviço de mediação de elementos de prova e ao registo de serviços de dados, composto por definições de nomes, tipos de dados e elementos de dados associados a tipos específicos de elementos de prova, a fim de assegurar a compreensão mútua e a interpretação multilingue para os emitentes de elementos de prova, os requerentes de elementos de prova e os utilizadores, aquando do intercâmbio de elementos de prova através do STDU;

11)

«Documentos de conceção técnica», um conjunto de documentos técnicos pormenorizados e não vinculativos, elaborados pela Comissão em cooperação com os Estados-Membros no âmbito do grupo de coordenação da plataforma mencionado no artigo 29.o do Regulamento (UE) 2018/1724, ou quaisquer subgrupos mencionados no artigo 19.o do presente regulamento, incluindo, entre outros, uma arquitetura de alto nível, protocolos de intercâmbio, normas e serviços auxiliares que apoiam a Comissão, os Estados-Membros, os emitentes de elementos de prova, os requerentes de elementos de prova, as plataformas de mediação e outras entidades envolvidas na criação do STDU em conformidade com o presente regulamento;

12)	«Serviço de dados», um serviço técnico através do qual um emitente de elementos de prova trata os pedidos de elementos de prova e envia elementos de prova;

13)	«Modelo de dados», uma abstração que organiza elementos de dados, normaliza a forma como se relacionam entre si e especifica as entidades, os seus atributos e a relação entre essas entidades;

14)	«Função de pré-visualização», uma funcionalidade que permite ao utilizador pré-visualizar os elementos de prova solicitados, tal como referido no artigo 15.o, n.o 1, alínea b), subalínea ii);

15)

«Elementos estruturados», qualquer elemento de prova em formato eletrónico exigido para os procedimentos enumerados no artigo 14.o, n.o 1, do Regulamento (UE) 2018/1724, organizado em elementos ou campos predefinidos que tenham um significado específico e um formato técnico que permita o tratamento por sistemas informáticos, complementado pelos elementos de metadados do modelo de metadados genéricos do STDU referido no artigo 7.o, n.o 1, do presente regulamento e em conformidade com o modelo de dados do STDU para o tipo de elemento de prova relevante, tal como referido no artigo 7.o, n.o 2, do presente regulamento, ou acompanhado de uma versão legível pelo ser humano;

16)

«Elementos não estruturados», elementos de prova em formato eletrónico exigidos para os procedimentos enumerados no artigo 14.o, n.o 1, do Regulamento (UE) 2018/1724, que não estão organizados em elementos ou campos predefinidos com significado e formato técnico específicos, mas que são complementadas pelos elementos de metadados do modelo de metadados genéricos do STDU referido no artigo 7.o, n.o 1, do presente regulamento;

17)	«Tipo de elemento de prova», uma categoria de elementos estruturados ou não estruturados com uma finalidade ou conteúdo comuns;

18)

«Incidente», uma situação em que o STDU não está a funcionar, não transmite os elementos de prova ou transmite elementos de prova que não foram solicitados, ou em que os elementos de prova foram alterados ou divulgados durante a transmissão, bem como qualquer violação de segurança mencionada no artigo 29.o;

19)	«Portal de procedimentos», uma página Web ou uma aplicação móvel em que um utilizador pode aceder e dar conclusão a um procedimento em linha como o mencionado no artigo 14.o, n.o 1, do Regulamento (UE) 2018/1724.

Artigo 2.o

Estrutura do STDU

O STDU consiste no seguinte:

a)	Os portais de procedimentos dos requerentes de elementos de prova e os serviços de dados dos emitentes de elementos de prova;

b)	Plataformas de mediação, se for caso disso;

c)	As funções de pré-visualização referidas no artigo 15.o, n.o 1, alínea b), subalínea ii);

d)	Os registos nacionais e os serviços referidos no artigo 8.o, se for caso disso;

e)	Nós eIDAS para autenticação do utilizador e correspondência da identidade;

f)	Pontos de acesso à plataforma eDelivery;

g)	Os serviços comuns referidos no artigo 4.o, n.o 1;

h)	As interfaces e os elementos de integração necessários para ligar os componentes referidos nas alíneas a) a g).

SECÇÃO 2

SERVIÇOS DO STDU

Artigo 3.o

Nós eIDAS e pontos de acesso à plataforma eDelivery

1. Os Estados-Membros devem assegurar que os requerentes de elementos de prova estão ligados a um nó eIDAS para permitir a autenticação do utilizador nos termos do artigo 11.o, quer diretamente quer através de uma plataforma de mediação.

2. Os Estados-Membros devem assegurar que os pontos de acesso à plataforma eDelivery são instalados, configurados e integrados nos portais de procedimentos dos requerentes de elementos de prova, nos serviços de dados dos emitentes de elementos de prova e nas plataformas de mediação.

3. Os Estados-Membros podem escolher o número de pontos de acesso à plataforma eDelivery que utilizam para o STDU.

Artigo 4.o

Serviços comuns

1. A Comissão, em cooperação com os Estados-Membros, estabelece os seguintes serviços do STDU («serviços comuns»):

a)	O registo de serviços de dados mencionado no artigo 5.o;

b)	O serviço de mediação de elementos de prova mencionado no artigo 6.o;

c)	O repositório semântico mencionado no artigo 7.o.

2. Os Estados-Membros asseguram a ligação técnica entre os portais de procedimentos dos requerentes de elementos de prova, diretamente ou através de plataformas de mediação, com os serviços comuns e o registo adequado dos seus serviços de dados nos serviços comuns. Ao implementar estas ligações, os Estados-Membros devem guiar-se pelas descrições contidas nos documentos de conceção técnica.

3. Os Estados-Membros garantem que apenas os requerentes de elementos de prova estão ligados, diretamente ou através de plataformas de mediação, aos serviços comuns e que apenas os requerentes de elementos de prova e os emitentes de elementos de prova podem utilizar o STDU. Os Estados-Membros verificam periodicamente o funcionamento das ligações aos serviços comuns.

Artigo 5.o

Registo de serviços de dados

1. Sem prejuízo do disposto no artigo 8.o do presente regulamento, os Estados-Membros devem assegurar que todos os emitentes de elementos de prova e todos os tipos de elementos de prova por eles emitidos que sejam relevantes para os procedimentos em linha a que se refere o artigo 14.o, n.o 1, do Regulamento (UE) 2018/1724 são registados no registo de serviços de dados.

2. A Comissão é responsável pelo desenvolvimento e manutenção de interfaces que permitam aos coordenadores nacionais mencionados no artigo 28.o do Regulamento (UE) 2018/1724, às autoridades competentes, às plataformas de mediação se for caso disso, e à Comissão, no âmbito das suas responsabilidades e dos limites dos direitos de acesso definidos pela Comissão:

a)	Registar, cancelar o registo e efetuar quaisquer outras atualizações de informações contidas no registo de serviços de dados;

b)	Gerir os direitos de acesso das pessoas autorizadas a efetuar registos e alterações aos dados registados.

A Comissão deve assegurar que os coordenadores nacionais, as autoridades competentes e as plataformas de mediação podem escolher entre interfaces gráficas de utilizador para pessoas autorizadas e interfaces de programas para carregamentos automatizados.

3. Os Estados-Membros asseguram que cada tipo de elementos de prova registado no registo de serviços de dados é acompanhado:

a)	Do nível de garantia dos meios de identificação eletrónica notificados pelos Estados-Membros em conformidade com o Regulamento (UE) n.o 910/2014; e

Se aplicável, de atributos adicionais, especificados a fim de facilitar a identificação do emitente de elementos de prova relevante e que vão além dos atributos obrigatórios do conjunto mínimo de dados estabelecido em conformidade com o Regulamento de Execução (UE) 2015/1501, intercambiados através dos meios de identificação eletrónica notificados em conformidade com o Regulamento (UE) n.o 910/2014, necessários para o seu intercâmbio através do STDU.

4. O registo de serviços de dados estabelece uma distinção clara entre os atributos adicionais referidos no n.o 3, alínea b), do presente artigo e os atributos intercambiados utilizando os meios de identificação eletrónica notificados em conformidade com o Regulamento (UE) n.o 910/2014 a que se refere o artigo 13.o, n.o 1, alínea f), do presente regulamento.

5. O nível de garantia referido no n.o 3, alínea a), exigido aos utilizadores transfronteiriços não deve exceder o nível de garantia exigido aos utilizadores não transfronteiriços.

6. Os Estados-Membros asseguram que as informações constantes do registo de serviços de dados se mantêm atualizadas.

Artigo 6.o

Serviço de mediação de elementos de prova

1. O serviço de mediação de elementos de prova deve permitir que os requerentes de elementos de prova determinem quais os tipos de elementos de prova emitidos noutros Estados-Membros que correspondem aos tipos de elementos de prova exigidos no contexto dos procedimentos para os quais esse requerente de elementos de prova é competente.

2. Os Estados-Membros complementam, através da interface a que se refere o artigo 5.o, n.o 2, a lista de tipos de elementos de prova no registo de serviços de dados a que se refere o artigo 5.o, n.o 1, com os factos ou o cumprimento dos requisitos processuais que provam, eventualmente em conjunto com outros tipos de elementos de prova, se necessário. Os Estados-Membros asseguram que essas informações são exatas e atualizadas.

3. A Comissão é responsável pelo desenvolvimento e manutenção de interfaces que permitam aos coordenadores nacionais, às autoridades competentes, às plataformas de mediação se for caso disso, e à Comissão, no âmbito das suas responsabilidades e dos limites dos direitos de acesso definidos pela Comissão:

a)	Acrescentar, alterar e atualizar as informações referidas no n.o 2;

b)	Gerir os direitos de acesso das pessoas autorizadas a acrescentar e alterar as informações registadas.

4. A Comissão facilita o levantamento dos tipos de elementos de prova emitidos num Estado-Membro relativamente aos factos ou ao cumprimento dos requisitos processuais que têm de ser provados num procedimento noutro Estado-Membro, ao estruturar a discussão e organizar os trabalhos no subgrupo pertinente referido no artigo 19.o. O subgrupo deve estabelecer uma linguagem formal específica do domínio, sempre que possível referenciando as normas internacionais pertinentes, e propor essa linguagem ao grupo de coordenação da plataforma, em conformidade com o artigo 18.o, alínea f).

Artigo 7.o

Repositório semântico e modelos de dados

1. O repositório semântico deve facultar o acesso ao modelo de metadados genéricos do STDU, concebido para visualizar metadados que identifiquem de forma inequívoca os elementos de prova e o emitente de elementos de prova e que inclua campos adicionais concebidos para visualizar os metadados mencionados no artigo 13.o, n.o 1, alíneas a), b) e c).

2. Para os tipos de elementos estruturados acordados no grupo de coordenação da plataforma, o repositório semântico deve conter um modelo de dados do STDU constituído, pelo menos, pelos seguintes componentes:

Uma representação desse modelo de dados com:

i)	um diagrama visual do modelo de dados, e

ii)	uma descrição textual de todas as entidades do modelo de dados, que consiste numa definição e na lista dos atributos da entidade; e, para cada atributo, o tipo previsto (por exemplo, booliano, identificador, data), uma definição, a cardinalidade e a utilização facultativa de uma lista de códigos;

b)	Distribuições em formato XML baseadas na definição de regras de validação de dados em XML (XSD), ou num formato equivalente, complementadas por outros formatos de serialização amplamente utilizados, sempre que possível;

c)	Listas de códigos para assegurar o tratamento automatizado dos elementos de prova, disponíveis num formato estruturado;

d)	Um mecanismo de conversão num formato legível pelo ser humano, por exemplo.XSLT ou equivalente.

3. Para cada tipo de elementos de prova, o repositório semântico deve oferecer um controlo de versão e um registo de alterações para permitir acompanhar as diferentes versões.

4. O repositório semântico deve conter uma metodologia para o desenvolvimento de novos modelos de dados do STDU para os tipos de elementos de prova trocados através do STDU, que consiste em exemplos e materiais didáticos.

5. Os calendários para as atualizações e adaptações dos modelos de metadados genéricos do STDU e dos modelos de dados do STDU devem ser debatidos regularmente pelos Estados-Membros e pela Comissão no âmbito de um dos subgrupos do grupo de coordenação da plataforma a que se refere o artigo 19.o, e adotados pelo grupo de coordenação da plataforma. Os emitentes de elementos de prova ou as plataformas de mediação, consoante o caso, devem aplicar essas atualizações e adaptações o mais tardar 12 meses após a sua publicação no repositório semântico.

6. A Comissão deve fornecer aos Estados-Membros uma ferramenta informática que os ajudará a verificar a conformidade dos elementos de prova com o modelo de metadados genéricos do STDU e com os modelos de dados do STDU.

7. A Comissão deve disponibilizar ao público o repositório semântico num sítio Web específico da Comissão.

Artigo 8.o

Registos e serviços nacionais

1. Os Estados-Membros que disponham de registos ou serviços nacionais equivalentes ao registo de serviços de dados ou ao serviço de mediação de elementos de prova podem optar por não registar os emitentes de elementos de prova, os tipos de elementos de prova que emitem e os factos ou o cumprimento dos requisitos processuais que provam, eventualmente em conjunto com outros tipos de elementos de prova, e o nível de garantia dos meios de identificação eletrónica exigidos para aceder a cada tipo de elementos de prova, tal como previsto nos artigos 5.o e 6.°. Nesse caso, devem tomar uma das seguintes medidas:

a)	Autorizar outros Estados-Membros a pesquisar nos seus registos nacionais as informações referidas no presente número;

b)	Copiar as informações referidas no presente número dos registos ou serviços nacionais para o registo de serviços de dados ou o serviço de mediação de elementos de prova.

2. Ao implementar o n.o 1, os Estados-Membros devem guiar-se pelas descrições contidas nos documentos de conceção técnica.

SECÇÃO 3

REQUERENTES DE ELEMENTOS DE PROVA

Artigo 9.o

Explicação aos utilizadores

1. Os requerentes de elementos de prova devem assegurar que os seus portais de procedimento contêm uma explicação do STDU e das suas características, incluindo a informação de que:

a)	A utilização do STDU é voluntária;

b)	Os utilizadores têm a opção de pré-visualizar os elementos de prova na função de pré-visualização referida no artigo 15.o, n.o 1, alínea b), subalínea ii), e decidir se devem ou não utilizá-los para o procedimento;

Os utilizadores podem agir por conta própria ou ser representados por outra pessoa singular ou coletiva, quando e na medida em que tenham sido encontradas soluções de representação em conformidade com o Regulamento (UE) n.o 910/2014 e de quaisquer atos de execução adotados com base nesse regulamento.

As informações referidas na alínea b) do primeiro parágrafo do presente número não são exigidas no caso dos procedimentos referidos no artigo 14.o, n.o 5, do Regulamento (UE) 2018/1724.

2. A obrigação de fornecer explicações a que se refere o n.o 1 do presente artigo é sem prejuízo da obrigação de fornecer aos titulares dos dados as informações referidas nos artigos 13.o e 14.° do Regulamento (UE) 2016/679.

Artigo 10.o

Seleção do tipo de elementos de prova

1. Os requerentes de elementos de prova devem dar aos utilizadores a possibilidade de solicitar por submissão direta os tipos de elementos de prova que correspondem, com base nas informações registadas no serviço de mediação de elementos de prova, a tipos que sejam aceitáveis nos termos da legislação aplicável no procedimento pertinente, desde que os emitentes de elementos de prova disponibilizem esses tipos de elementos de prova através do STDU, em conformidade com o artigo 5.o, n.o 1.

2. Se puderem ser solicitados vários elementos de prova, o requerente de elementos de prova deve assegurar que os utilizadores podem selecionar todos, um subconjunto ou um tipo específico de elementos de prova.

Artigo 11.o

Autenticação do utilizador

1. Os requerentes de elementos de prova devem basear-se em meios de identificação eletrónica emitidos no âmbito de um sistema de identificação eletrónica que tenha sido notificado em conformidade com o Regulamento (UE) n.o 910/2014 para autenticar os utilizadores, a atuar por conta própria ou através de um representante, quando e na medida em que se tenham encontrado soluções de representação em conformidade com o Regulamento (UE) n.o 910/2014 e quaisquer atos de execução adotados com base nesse regulamento.

2. Logo que o utilizador tenha selecionado o tipo de elementos de prova para o intercâmbio através do STDU, os requerentes de elementos de prova devem informar os utilizadores:

a)	De quaisquer atributos adicionais a que se refere o artigo 5.o, n.o 3, alínea b), do presente regulamento que devam fornecer, se aplicáveis; e

b)	De que serão reencaminhados para o emitente ou os emitentes de elementos de prova, ou, consoante o caso, a plataforma ou as plataformas de mediação, para pré-visualizar os elementos de prova selecionados.

3. Caso não seja exigida pré-visualização em conformidade com o artigo 14.o, n.o 5, do Regulamento (UE) 2018/1724, não se aplica o n.o 2, alínea b), do presente artigo. Nesse caso, o emitente ou os emitentes de elementos de prova, ou, consoante o caso, a plataforma ou as plataformas de mediação podem solicitar ao requerente de elementos de prova que reencaminhe o utilizador para que se identifique ou autentique novamente para efeitos de correspondência da identidade e dos elementos de prova. O utilizador pode optar por não ser reencaminhado. Nesse caso, o requerente de elementos de prova deve informar o utilizador de que o processo de correspondência da identidade e dos elementos de prova realizado pelo emitente de elementos de prova pode não resultar numa correspondência, tal como referido no artigo 16.o do presente regulamento.

Artigo 12.o

Pedido expresso

Para além das informações referidas no artigo 9.o, o requerente de elementos de prova deve fornecer ao utilizador o seguinte:

a)	Os nomes dos emitentes de elementos de prova;

b)	Os tipos de elementos de prova ou campos de dados do intercâmbio.

O presente artigo não prejudica as situações nas quais o uso do STDU é permitido sem um pedido expresso nos termos do artigo 14.o, n.o 4, do Regulamento (UE) 2018/1724.

Artigo 13.o

Pedido de elementos de prova

1. O requerente de elementos de prova deve assegurar que o pedido de elementos de prova é transmitido ao emitente de elementos de prova ou à plataforma de mediação, consoante o caso, e que contém as seguintes informações:

a)	O identificador único do pedido;

b)	O tipo de elementos de prova solicitado;

c)	Data e hora em que o pedido expresso foi apresentado;

d)	Identificação do procedimento para o qual são exigidos elementos de prova;

e)	Nome e metadados que identificam de forma inequívoca o requerente de elementos de prova e a plataforma de mediação, consoante o caso;

f)	Os atributos do utilizador, ou do utilizador e do representante, se for caso disso, trocados através dos meios de identificação eletrónica referidos no artigo 11.o, n.o 1;

g)	O nível de garantia, tal como definido no Regulamento (UE) n.o 910/2014, dos meios de identificação eletrónica utilizados pelo utilizador;

h)	Os atributos adicionais, referidos no artigo 5.o, n.o 3, alínea b), fornecidos pelo utilizador para efeitos do pedido;

i)	A identificação do emitente de elementos de prova, tal como registado no registo de serviços de dados;

j)	Se o pedido expresso do utilizador é obrigatório em conformidade com o artigo 14.o, n.o 4, do Regulamento (UE) 2018/1724;

k)	Se a possibilidade de pré-visualizar os elementos de prova é obrigatória em conformidade com o artigo 14.o, n.o 5, do Regulamento (UE) 2018/1724.

2. O requerente de elementos de prova deve fazer uma distinção clara entre os atributos adicionais referidos no n.o 1, alínea h), e os atributos referidos no n.o 1, alínea f).

Artigo 14.o

Reencaminhamento do utilizador para o emitente de elementos de prova

1. Sem prejuízo dos procedimentos a que se refere o artigo 14.o, n.o 5, do Regulamento (UE) 2018/1724, os requerentes de elementos de prova devem assegurar que os utilizadores, depois de selecionarem os elementos de prova a trocar através do STDU no portal de procedimentos em conformidade com o artigo 10.o do presente regulamento e apresentarem o seu pedido expresso em conformidade com o artigo 12.o do presente regulamento, são reencaminhados para o emitente ou emitentes de elementos de prova, ou a plataforma ou plataformas de mediação, consoante o caso, para exercerem a opção de pré-visualizar os elementos de prova.

2. Quanto aos procedimentos mencionados no artigo 14.o, n.o 5, do Regulamento (UE) 2018/1724, os utilizadores podem ser reencaminhados para o emitente ou emitentes de elementos de prova ou a plataforma ou plataformas de mediação, consoante o caso, em conformidade com o artigo 11.o, n.o 3, do presente regulamento.

SECÇÃO 4

EMITENTE DE ELEMENTOS DE PROVA

Artigo 15.o

Papel no intercâmbio de elementos de prova

1. Os Estados-Membros devem assegurar que, para efeitos do intercâmbio de elementos de prova através do STDU, os emitentes de elementos de prova ou as plataformas de mediação, consoante o caso, utilizam serviços de aplicações capazes de:

a)	Receber e interpretar pedidos de elementos de prova apresentados por um ponto de acesso à plataforma eDelivery, que devem ser considerados como os dados de entrada para os serviços de dados;

Sob reserva de uma identificação e autenticação bem sucedidas, em conformidade com o artigo 16.o do presente regulamento:

i)	extrair quaisquer elementos de prova que correspondam ao pedido,

ii)

exceto no caso dos procedimentos referidos no artigo 14.o, n.o 5, do Regulamento (UE) 2018/1724, permitir aos utilizadores especificar quais desses elementos de prova pretendem pré-visualizar e dar-lhes a possibilidade de pré-visualizar os elementos assim especificados numa função de pré-visualização,

iii)	permitir que os utilizadores indiquem, se for caso disso, quais dos elementos de prova correspondentes devem ser devolvidos ao requerente para utilização no procedimento;

Devolver as respostas relativas aos elementos de prova ao requerente de elementos de prova através de um ponto de acesso à plataforma eDelivery, sob reserva da decisão do utilizador de utilizar os elementos de prova no procedimento após a possibilidade de os pré-visualizar, exceto no caso dos procedimentos referidos no artigo 14.o, n.o 5, do Regulamento (UE) 2018/1724, de relatórios de erro, incluindo na situação referida no artigo 16.o, n.o 3, alínea a), do presente regulamento, ou relatórios sobre elementos de prova em fase de conversão.

2. Se for devolvida uma resposta relativa aos elementos de prova, esta deve incluir os elementos de prova solicitados e ser acompanhada de:

a)	Metadados que identificam de forma inequívoca a resposta relativa aos elementos de prova;

b)	Metadados que identificam de forma inequívoca o pedido de elementos de prova;

c)	Metadados que indicam a data e a hora em que a resposta foi gerada;

d)	Metadados que identificam de forma inequívoca os elementos de prova e o emitente de elementos de prova;

e)	Se os elementos estruturados não estiverem em conformidade com o modelo de dados do STDU pertinente para o tipo de elementos de prova em causa, uma versão legível pelo ser humano dos elementos de prova.

3. A resposta relativa aos elementos de prova pode também incluir metadados que identifiquem de forma inequívoca a língua ou as línguas dos elementos de prova solicitados.

4. Se o sistema apresentar um relatório de erro, este deve incluir metadados que identifiquem de forma inequívoca o pedido de elementos de prova, a data e hora em que foi gerado e uma descrição do erro ocorrido.

5. Se os elementos de prova ainda não estiverem disponíveis para intercâmbio através do STDU, mas em fase de conversão em elementos estruturados ou não estruturados, tal como definidos no artigo 1.o, pontos 16) e 17), o sistema deve apresentar um relatório como o mencionado no n.o 1, alínea c), do presente artigo. Esse relatório deve incluir metadados que identifiquem de forma inequívoca o pedido de elementos de prova, a data e hora em que foram gerados e uma mensagem segundo a qual os elementos de prova em causa estão a ser convertidos em elementos estruturados ou não estruturados, tal como definidos no artigo 1.o, pontos 16) e 17), e estarão prontos para a transmissão através do STDU no futuro. O emitente de elementos de prova deve incluir no relatório a data e a hora preliminares em que os elementos de prova estarão disponíveis.

Artigo 16.o

Correspondência da identidade e dos elementos de prova

1. Os emitentes de elementos de prova ou as plataformas de mediação, consoante o caso, podem exigir que os utilizadores se identifiquem ou autentiquem novamente para efeitos de correspondência entre identidade e elementos de prova, nomeadamente fornecendo atributos adicionais.

2. Os emitentes de elementos de prova, ou as plataformas de mediação, consoante o caso, devem assegurar que os elementos de prova só são trocados através do STDU se os atributos de identidade do utilizador e do representante, consoante o caso, num intercâmbio através dos meios de identificação eletrónica a que se refere o artigo 11.o, n.o 1, e os atributos adicionais a que se refere o artigo 11.o, n.o 2, alínea a), e fornecidos pelo utilizador para facilitar a identificação pelo emitente de elementos de prova pertinente, correspondem aos atributos que por eles detidos.

3. Se o processo de correspondência da identidade e dos elementos de prova não resultar numa correspondência ou se a correspondência da identidade gerar dois ou mais resultados, o utilizador ou o representante, consoante o caso, não deve ser autorizado a pré-visualizar os elementos de prova solicitados e os elementos de prova não devem ser intercambiados. Na ausência de tal correspondência:

a)	Deve ser enviada uma mensagem de erro ao requerente de elementos de prova;

b)	O utilizador deve receber uma mensagem automática a explicar que os elementos de prova não podem ser fornecidos.

SECÇÃO 5

SISTEMA DE REGISTO DO STDU

Artigo 17.o

Sistema de registo

1. Para cada pedido de elementos de prova transmitido através do STDU, o requerente de elementos prova, os emitentes de elementos de prova ou as plataformas de mediação, consoante o caso, devem registar os seguintes elementos:

a)	O pedido de elementos de prova mencionado no artigo 13.o, n.o 1;

b)	As informações incluídas na resposta relativa aos elementos de prova, com exceção dos próprios elementos de prova, ou no relatório de erro mencionado no artigo 15.o, n.o 1, alínea c), e no artigo 16.o, n.o 3, alínea a);

Os dados do evento eDelivery dizem respeito a qualquer um dos seguintes elementos:

i)	intercâmbio de pedidos de elementos de prova,

ii)	respostas relativas aos elementos de prova,

iii)	relatórios de erro.

2. Para cada elemento de prova trocado através do STDU, o emitente de elementos de prova ou a plataforma de mediação, consoante o caso, deve registar a decisão do utilizador — após pré-visualizar os elementos de prova — de aprovar ou não a utilização do elemento de prova para o procedimento ou, se for caso disso, o facto de o utilizador sair da função de pré-visualização ou do portal de procedimentos sem tomar uma decisão específica.

3. A Comissão e, nas situações referidas no artigo 8.o, n.o 1, alínea a), os Estados-Membros em causa devem registar todas as interações com os serviços comuns mencionados no artigo 4.o, n.o 1.

4. Sem prejuízo de períodos de conservação mais longos exigidos pela legislação nacional para os registos referidos nos n.os 1, 2 e 3 para efeitos do STDU ou para outros fins, a Comissão e os requerentes de elementos de prova, os emitentes de elementos de prova ou as plataformas de mediação, consoante o caso, devem conservar esses registos durante um período de 12 meses.

5. Em caso de suspeita de incidentes e para efeitos de auditorias e controlos aleatórios de segurança realizados nos respetivos domínios de responsabilidade referidos no artigo 26.o, os requerentes de elementos de prova, os emitentes de elementos de prova e as plataformas de mediação, consoante o caso, devem disponibilizar-se mutuamente, mediante pedido, os registos pertinentes referidos nos n.os 1 e 2 do presente artigo através do painel de controlo de assistência técnica referido no artigo 22.o. Para os mesmos efeitos e da mesma forma, os Estados-Membros e a Comissão, se for caso disso, disponibilizam os registos pertinentes referidos no n.o 3 do presente artigo aos requerentes de elementos de prova, aos emitentes de elementos de prova e às plataformas de mediação pertinentes, consoante o caso.

SECÇÃO 6

GOVERNAÇÃO DO STDU

Artigo 18.o

Grupo de coordenação da plataforma

A Comissão, em cooperação com os Estados-Membros no âmbito do grupo de coordenação da plataforma criado pelo artigo 29.o do Regulamento (UE) 2018/1724, deve:

a)	Supervisionar a criação e o lançamento do STDU, em conformidade com o artigo 31.o, n.o 3, do presente regulamento;

b)	Definir prioridades para mais evoluções e melhorias no STDU;

c)	Estabelecer um calendário indicativo para as atualizações regulares dos documentos de conceção técnica, bem como para a sua manutenção e adaptação;

d)	Recomendar alterações aos documentos de conceção técnica;

e)	Organizar avaliações pelos pares para promover o intercâmbio de experiências e boas práticas entre os Estados-Membros sobre a aplicação do presente regulamento pelos Estados-Membros;

f)	Aprovar ou rejeitar as modalidades operacionais apresentadas por qualquer dos subgrupos estabelecidos em conformidade com o regulamento interno do grupo de coordenação da plataforma e, se necessário, dar orientações específicas e supervisionar o seu trabalho.

Artigo 19.o

Subgrupos do grupo de coordenação da plataforma

1. A fim de assegurar desenvolvimento e funcionamento coordenados dos STDU, os subgrupos a que se refere o artigo 18.o, alínea f), devem debater e, se necessário, elaborar propostas das modalidades operacionais a apresentar ao grupo de coordenação da plataforma nos seguintes domínios, em especial:

a)	Normalização dos modelos de dados do STDU;

b)	Levantamento dos elementos de prova;

c)	Revisão, manutenção e interpretação dos documentos de conceção técnica;

d)	Governação operacional, em especial disposições operacionais e acordos de nível de serviço;

e)	Segurança do STDU, incluindo a elaboração de planos de gestão dos riscos para identificar riscos, avaliar o seu potencial impacto e planear respostas técnicas e organizativas adequadas em caso de incidentes;

f)	Ensaio e implantação dos componentes do STDU, incluindo a interoperabilidade entre os componentes nacionais do STDU referidos no artigo 2.o, alíneas a) a f) e h), e os serviços comuns mencionados no artigo 4.o, n.o 1.

As modalidades operacionais incluem a elaboração e a proposta de normas necessárias à interoperabilidade nos domínios respetivos dos subgrupos, segundo normas internacionais, sempre que possível. Uma vez aprovadas pelo grupo de coordenação da plataforma, estas normas devem ser incluídas nos documentos de conceção técnica.

2. Sempre que possível, os subgrupos adotam as suas propostas de modalidades operacionais por consenso. Se um consenso parecer improvável, o presidente pode decidir, com o apoio de uma maioria simples dos membros do subgrupo presente na reunião, que uma proposta do subgrupo pode ser apresentada ao grupo de coordenação da plataforma.

SECÇÃO 7

APOIO TÉCNICO

Artigo 20.o

Ponto único de contacto para apoio técnico da Comissão

1. A Comissão designa um ponto único de contacto para apoio técnico que assegure o funcionamento e a manutenção dos serviços comuns a que se refere o artigo 4.o, n.o 1.

2. O ponto único de contacto para apoio técnico deve estabelecer a ligação com outros pontos de contacto pertinentes da Comissão e coordenar a resolução de problemas com os pontos de acesso à plataforma eDelivery ou os nós eIDAS.

3. A Comissão assegura que o seu ponto único de contacto para apoio técnico é organizado de forma a poder desempenhar as suas funções em todas as circunstâncias e reagir a curto prazo.

Artigo 21.a

Ponto único de contacto para apoio técnico nacional

1. Cada Estado-Membro designa um ponto único de contacto para apoio técnico, a fim de assegurar o funcionamento e a manutenção dos componentes relevantes do STDU pelos quais são responsáveis nos termos da secção 9.

2. Os pontos únicos de contacto para apoio técnico devem:

Dar conhecimentos especializados e aconselhamento aos emitentes de elementos de prova e aos requerentes de elementos de prova relativamente a todos os problemas técnicos encontrados no funcionamento do STDU e, se necessário, estabelecer a ligação com o ponto de contacto para apoio técnico da Comissão e com outros pontos de contacto para apoio técnico nacionais;

b)	Investigar e resolver eventuais interrupções do serviço dos pontos de acesso à plataforma eDelivery, eventuais violações da segurança e outros incidentes;

c)	Informar os pontos de contacto para apoio técnico de quaisquer atividades que possam resultar numa violação ou suspeita de violação da segurança dos sistemas eletrónicos.

3. Quando informado por um emitente de elementos de prova sobre dúvidas quanto à legalidade de um ou vários pedidos de elementos de prova, o ponto único de contacto para apoio técnico deve:

a)	Analisar pedidos de elementos de prova ou amostras de pedidos de elementos de prova transmitidos pelo mesmo requerente de elementos de prova no passado;

b)	Utilizar o painel de controlo de assistência técnica referido no artigo 22.o para solicitar ao ponto único de contacto para apoio técnico designado pelo Estado-Membro do requerente de elementos de prova que transmita registos dos intercâmbios selecionados mencionados no artigo 17.o;

c)	Chamar a atenção do coordenador nacional para a questão se o problema persistir.

4. Os Estados-Membros devem assegurar que o respetivo ponto único de contacto para apoio técnico é organizado de forma a permitir que desempenhe as suas funções em todas as circunstâncias e seja capaz de reagir a curto prazo.

Artigo 22.o

Painel de controlo de assistência técnica

1. A Comissão cria um painel de controlo para facilitar a comunicação entre todos os pontos de contacto para apoio técnico.

2. Os Estados-Membros e a Comissão devem registar no painel de controlo os dados de contacto dos pontos de contacto para apoio técnico e mantê-los atualizados.

3. Os pontos de contacto devem, através do painel de controlo:

a)	Comunicar qualquer incidente considerado substancial;

b)	Comunicar quaisquer medidas temporárias ou permanentes tomadas na sequência de incidentes;

c)	Solicitar aos pontos de contacto para apoio técnico pertinentes os registos dos intercâmbios selecionados nos casos referidos no artigo 17.o, n.o 5, e se houver dúvidas quanto à legalidade do pedido de elementos de prova a que se refere o artigo 21.o, n.o 3;

d)	Solicitar qualquer outra assistência necessária em caso de incidentes.

4. Os coordenadores nacionais e o presidente do grupo de coordenação da plataforma têm acesso ao painel de controlo.

5. A Comissão e os coordenadores nacionais utilizam o painel de controlo para prestar as informações referidas no artigo 27.o e no artigo 28.o, n.o 2.

Secção 8

Cooperação com outras estruturas de governação

Artigo 23.o

Âmbito de cooperação

A Comissão, juntamente com o grupo de coordenação da plataforma e os seus subgrupos, deve cooperar com as estruturas de governação pertinentes estabelecidas pelo direito da União ou por acordos internacionais em domínios relevantes para o STDU, a fim de alcançar sinergias e reutilizar, na medida do possível, as soluções desenvolvidas nessas outras instâncias.

Secção 9

Responsabilidade pela manutenção e pelo funcionamento de componentes do STDU

Artigo 24.o

Responsabilidades da Comissão

A Comissão é proprietária dos serviços comuns e do painel de controlo de assistência técnica e é responsável pelo seu desenvolvimento, disponibilidade, supervisão, atualização, manutenção e alojamento.

Artigo 25.o

Responsabilidades dos Estados-Membros

No que diz respeito aos respetivos componentes nacionais do STDU mencionados no artigo 2.o, alíneas a) a f) e h), cada Estado-Membro é considerado proprietário e responsável pelo estabelecimento, se for caso disso, e pelo desenvolvimento, disponibilidade, supervisão, atualização, manutenção e alojamento.

Artigo 26.o

Alterações e atualizações

1. A Comissão informa os Estados-Membros das alterações e atualizações dos serviços comuns.

2. Os Estados-Membros devem informar a Comissão sobre alterações e atualizações aos componentes da sua responsabilidade que possam ter repercussões no funcionamento do STDU.

3. As informações sobre atualizações críticas devem ser prestadas sem demoras injustificadas. No caso de outras atualizações que não sejam de importância crítica e suscetíveis de afetar componentes do STDU que sejam propriedade de outros Estados-Membros ou dos serviços comuns, o tempo de espera deve ser decidido pelo grupo de coordenação da plataforma com base numa proposta do subgrupo relevante.

Artigo 27.o

Disponibilidade do STDU

1. O horário de funcionamento do STDU deve ser 24 horas por dia/7 dias por semana, com uma taxa de disponibilidade dos pontos de acesso à plataforma eDelivery, das funções de pré-visualização e dos serviços comuns de pelo menos 98 %, excluindo as operações de manutenção programadas em conformidade com o n.o 2 do presente artigo. Os objetivos do nível de serviço dos restantes componentes do STDU devem ser especificados nos acordos de nível de serviço a que se refere o artigo 19.o, n.o 1, alínea d).

2. Os Estados-Membros e a Comissão devem notificar as atividades de manutenção programadas relacionadas com os componentes relevantes do STDU com a seguinte antecedência:

a)	Cinco dias úteis, no que respeita às operações de manutenção que possam provocar um período de indisponibilidade até quatro horas;

b)	Dez dias úteis, no que respeita às operações de manutenção que possam provocar um período de indisponibilidade até 12 horas;

c)	Trinta dias úteis no que respeita à manutenção das infraestruturas da sala de computadores que possam provocar um período de indisponibilidade de até seis dias por ano.

Tanto quanto possível, as operações de manutenção devem ser planeadas para ocorrer fora do horário de trabalho.

3. Se um Estado-Membro tiver definido um horário semanal fixo para as operações de manutenção, deve comunicar à Comissão as horas e os dias da semana previstos para esse efeito. Sem prejuízo das obrigações estabelecidas no n.o 2, alíneas a), b) e c), se os sistemas dos Estados-Membros ficarem indisponíveis durante esse horário fixo, os Estados-Membros ficam isentos da obrigação de notificar a Comissão de cada vez que tal suceda.

4. Em caso de falha técnica inesperada dos componentes do STDU dos Estados-Membros, o Estado-Membro em causa informa sem demora os outros Estados-Membros e a Comissão da sua indisponibilidade e, se houver informações a esse respeito, da retoma prevista do funcionamento dos componentes.

5. Em caso de falha inesperada dos serviços comuns, a Comissão informa sem demora os Estados-Membros da indisponibilidade de um ou mais serviços comuns e, se houver informações a esse respeito, da retoma prevista do serviço.

6. As notificações mencionadas no presente artigo são efetuadas através do painel de controlo de assistência técnica referido no artigo 22.o.

SECÇÃO 10

SEGURANÇA

Artigo 28.o

Segurança dos serviços comuns e dos componentes nacionais

1. A Comissão assegura a segurança dos serviços comuns a que se refere o artigo 4.o, n.o 1, e das interfaces e dos elementos de integração referidos no artigo 2.o, alínea h), pelos quais é responsável.

2. Os Estados-Membros asseguram a segurança dos componentes nacionais do STDU e das interfaces e dos elementos de integração referidos no artigo 2.o, alínea h), pelos quais são responsáveis.

3. Para os efeitos referidos nos n.os 1 e 2, os Estados-Membros e a Comissão tomam, pelo menos, e em relação a componentes pelos quais são responsáveis, as medidas necessárias para:

a)	Impedir o acesso de pessoas não autorizadas a componentes pelos quais são responsáveis;

b)	Impedir a entrada de dados, bem como qualquer consulta, alteração ou supressão de dados por pessoas não autorizadas;

c)	Detetar qualquer das atividades a que se referem as alíneas a) e b); e

d)	Assegurar o registo dos eventos de segurança em conformidade com as normas de segurança internacionais reconhecidas para as tecnologias da informação.

4. Os Estados-Membros devem garantir, em especial:

Que as ligações que operam à entrada e saída dos pontos de acesso à plataforma eDelivery e todas as comunicações internas entre as diferentes autoridades nacionais cumprem, pelo menos, o mesmo nível de requisitos de segurança que o serviço de envio eletrónico à plataforma eDelivery, a fim de proteger a segurança e a confidencialidade do intercâmbio e a integridade dos elementos de prova trocados através do STDU;

b)	O não repúdio da origem do pedido de elementos de prova transmitido a partir do ponto de acesso do requerente de elementos de prova, bem como da resposta aos elementos de prova intercambiados ou da mensagem de erro transmitida a partir do ponto de acesso do emitente de elementos de prova.

5. Em conformidade com o n.o 4, o Estado-Membro do emitente de elementos de prova em qualquer intercâmbio de elementos de prova é responsável pela qualidade, confidencialidade, integridade e disponibilidade dos elementos de prova solicitados até que estes cheguem ao ponto de acesso à plataforma eDelivery do requerente de elementos de prova ou a uma plataforma de mediação, consoante o caso. O Estado-Membro do requerente de elementos de prova num determinado intercâmbio de elementos de prova é responsável pela confidencialidade e integridade dos elementos de prova solicitados a partir do momento em que chegam ao seu ponto de acesso à plataforma eDelivery.

6. Os Estados-Membros e a Comissão asseguram a confidencialidade, a integridade e a disponibilidade dos registos referidos no artigo 17.o, n.os 1, 2, e 3, através de medidas de segurança adequadas e proporcionadas, cada um para os registos por si registados.

Artigo 29.o

Supervisão dos sistemas eletrónicos

1. Os Estados-Membros e a Comissão procedem a controlos regulares dos elementos do STDU pelos quais são responsáveis.

2. Os pontos únicos de contacto para apoio técnico referidos nos artigos 20.o e 21.° utilizam o painel de controlo de assistência técnica referido no artigo 22.o para se informarem mutuamente dos problemas detetados durante os controlos que possam resultar numa violação ou suspeita de violação da segurança do STDU.

Artigo 30.o

Sistema de gestão da administração

A Comissão deve criar um sistema de gestão da administração para gerir as regras de autenticação e autorização para a validação dos dados de identificação, a fim de permitir o acesso aos serviços comuns e ao painel de controlo de assistência técnica.

SECÇÃO 11

DISPOSIÇÕES FINAIS

Artigo 31.o

Testes do STDU

1. Os Estados-Membros e a Comissão devem, no âmbito do grupo de coordenação da plataforma, adotar um calendário de testes e um conjunto de indicadores segundo os quais os resultados dos testes podem ser medidos e considerados positivos.

2. A Comissão presta serviços de ensaio que os Estados-Membros podem utilizar para testar a conformidade das soluções técnicas com os indicadores referidos no n.o 1.

3. Os Estados-Membros e a Comissão devem testar o funcionamento de cada um dos componentes do STDU e verificar se podem funcionar corretamente de acordo com os indicadores referidos no n.o 1. Só devem ser disponibilizados aos utilizadores os componentes do STDU cujos testes produzem resultados positivos.

Artigo 32.o

Assistência da Comissão

A Comissão deve disponibilizar uma equipa de peritos como parte do ponto de contacto de apoio técnico da Comissão para assistir os pontos de contacto de apoio técnico nacionais e os coordenadores nacionais em todos os aspetos relacionados com o funcionamento dos STDU do ponto de vista técnico, em especial:

a)	Fornecer orientações;

b)	Organizar seminários e demonstrações;

c)	Responder a perguntas isoladas.

Artigo 33.o

Tratamento de dados pessoais

No que diz respeito ao tratamento de dados pessoais presentes nos elementos de prova sujeitos a intercâmbio através do STDU e que ocorram nos componentes do STDU de que sejam proprietários nos termos do artigo 25.o do presente regulamento, as respetivas autoridades competentes dos Estados-Membros, na sua qualidade de requerente de elementos de prova ou emitente de elementos de prova, atuam como responsáveis pelo tratamento, na aceção do artigo 4.o, ponto 7, do Regulamento (UE) 2016/679 e conforme especificado nos artigos 34.o e 35.° do presente regulamento.

Artigo 34.o

Responsabilidades do requerente de elementos de prova enquanto responsável pelo tratamento dos dados

1. Para cada intercâmbio de elementos de prova através do STDU, o requerente de elementos de prova ou a plataforma de mediação, consoante o caso, é o único responsável pela exaustividade e legalidade do pedido de elementos de prova. O requerente de elementos de prova deve assegurar, em especial, que os elementos de prova são necessários para o procedimento específico para o qual são solicitados por um utilizador.

2. Logo que os elementos de prova intercambiados através do STDU fiquem à disposição do requerente de elementos de prova ou da plataforma de mediação, consoante o caso, na sequência da escolha do utilizador de proceder ao intercâmbio de elementos de prova em conformidade com o artigo 14.o, n.o 3, alínea f), do Regulamento (UE) 2018/1724, ou no caso dos procedimentos referidos no artigo 14.o, n.o 5, do Regulamento (UE) 2018/1724, o requerente de elementos de prova ou a plataforma de mediação, consoante o caso, deve assegurar o mesmo nível de proteção dos dados pessoais em conformidade com o Regulamento (UE) 2016/679 que numa situação em que o utilizador apresenta ou carrega os elementos de prova sem recorrer ao STDU.

Artigo 35.o

Responsabilidades do emitente de elementos de prova enquanto responsável pelo tratamento dos dados

1. Sem prejuízo das suas obrigações estabelecidas no Regulamento (UE) 2016/679, para cada intercâmbio de elementos de prova através do STDU, o emitente de elementos de prova ou a plataforma de mediação pertinente, consoante o caso, é o único responsável por verificar:

a)	Que os elementos de prova solicitados correspondem ao utilizador, em conformidade com o artigo 16.o;

b)	Que o utilizador tem o direito de utilizar os elementos de prova solicitados.

2. Quando uma plataforma de mediação fornece a função de pré-visualização nos termos do artigo 15.o, n.o 1, alínea b), subalínea ii), do presente regulamento, deve ser considerada um subcontratante que atua em nome do emitente de elementos de prova, em conformidade com o artigo 4.o, n.o 8, do Regulamento (UE) 2016/679.

Artigo 36.o

Entrada em vigor

O presente regulamento entra em vigor no vigésimo dia seguinte ao da sua publicação no Jornal Oficial da União Europeia.

O presente regulamento é aplicável a partir de 12 de dezembro de 2023.

O presente regulamento é obrigatório em todos os seus elementos e diretamente aplicável em todos os Estados-Membros.

Feito em Bruxelas, em 5 de agosto de 2022.

Pela Comissão

A Presidente

Ursula VON DER LEYEN

(1) JO L 295 de 21.11.2018, p. 1.

(2) Diretiva 2005/36/CE do Parlamento Europeu e do Conselho, de 7 de setembro de 2005, relativa ao reconhecimento das qualificações profissionais (JO L 255 de 30.9.2005, p. 22).

(3) Diretiva 2006/123/CE do Parlamento Europeu e do Conselho, de 12 de dezembro de 2006, relativa aos serviços no mercado interno (JO L 376 de 27.12.2006, p. 36).

(4) Diretiva 2014/24/UE do Parlamento Europeu e do Conselho, de 26 de fevereiro de 2014, relativa aos contratos públicos e que revoga a Diretiva 2004/18/CE (JO L 94 de 28.3.2014, p. 65).

(5) Diretiva 2014/25/UE do Parlamento Europeu e do Conselho, de 26 de fevereiro de 2014, relativa aos contratos públicos celebrados pelas entidades que operam nos setores da água, da energia, dos transportes e dos serviços postais e que revoga a Diretiva 2004/17/CE (JO L 94 de 28.3.2014, p. 243).

(6) Regulamento de Execução (UE) 2015/1501 da Comissão, de 8 de setembro de 2015, que estabelece o quadro de interoperabilidade, nos termos do artigo 12.o, n.o 8, do Regulamento (UE) n.o 910/2014 do Parlamento Europeu e do Conselho relativo à identificação eletrónica e aos serviços de confiança para as transações eletrónicas no mercado interno (JO L 235 de 9.9.2015, p. 1).

(7) Rede de cartas de condução criada com base no artigo 15.o da Diretiva 2006/126/CE do Parlamento Europeu e do Conselho, de 20 de dezembro de 2006, relativa à carta de condução (JO L 403 de 30.12.2006, p. 18).

(8) Tratado relativo a um Sistema Europeu de Informação sobre Veículos e Cartas de Condução (EUCARIS), adotado no Luxemburgo em 29 de junho de 2000.

(9) O Emrex User Group (GUE) é uma rede internacional independente que reúne vários intervenientes interessados em melhorar a portabilidade dos dados dos estudantes; https://emrex.eu/

(10) Regulamento (CE) n.o 987/2009 do Parlamento Europeu e do Conselho, de 16 de setembro de 2009, que estabelece as modalidades de aplicação do Regulamento (CE) n.o 883/2004 relativo à coordenação dos sistemas de segurança social (JO L 284 de 30.10.2009, p. 1).

(11) Decisão 2009/316/JAI do Conselho, de 6 de abril de 2009, relativa à criação do Sistema Europeu de Informação sobre os Registos Criminais (ECRIS) em aplicação do artigo 11.o da Decisão-Quadro 2009/315/JAI (JO L 93 de 7.4.2009, p. 33).

(12) https://ec.europa.eu/tools/ecertis/#/homePage

(13) Regulamento (UE) n.o 910/2014 do Parlamento Europeu e do Conselho, de 23 de julho de 2014, relativo à identificação eletrónica e aos serviços de confiança para as transações eletrónicas no mercado interno e que revoga a Diretiva 1999/93/CE (JO L 257 de 28.8.2014, p. 73).

(14) A trusted and secure European e-ID - Recommendation | Shaping Europe’s digital future (europa.eu) (não traduzido para português).

(15) Decisão de Execução (UE) 2015/296 da Comissão, de 24 de fevereiro de 2015, que estabelece as disposições processuais de cooperação entre Estados-Membros em matéria de identificação eletrónica nos termos do artigo 12.o, n.o 7, do Regulamento (UE) n.o 910/2014 do Parlamento Europeu e do Conselho relativo à identificação eletrónica e aos serviços de confiança para as transações eletrónicas no mercado interno (JO L 53 de 25.2.2015, p. 14).

(16) JO L 210 de 14.6.2021, p. 51.

(17) Assinada em 6 de outubro de 2017; https://digital-strategy.ec.europa.eu/en/news/ministerial-declaration-egovernment-tallinn-declaration

(18) Assinada em 8 de dezembro de 2020; https://digital-strategy.ec.europa.eu/en/news/berlin-declaration-digital-society-and-value-based-digital-government

(19) Regulamento (UE) 2016/679 do Parlamento Europeu e do Conselho, de 27 de abril de 2016, relativo à proteção das pessoas singulares no que diz respeito ao tratamento de dados pessoais e à livre circulação desses dados e que revoga a Diretiva 95/46/CE (Regulamento Geral sobre a Proteção de Dados) (JO L 119 de 4.5.2016, p. 1).

(20) Decisão (UE, Euratom) 2017/46 da Comissão, de 10 de janeiro de 2017, relativa à segurança dos sistemas de comunicação e de informação na Comissão Europeia (JO L 6 de 11.1.2017, p. 40).

(21) Regulamento (UE) 2018/1725 do Parlamento Europeu e do Conselho, de 23 de outubro de 2018, relativo à proteção das pessoas singulares no que diz respeito ao tratamento de dados pessoais pelas instituições e pelos órgãos e organismos da União e à livre circulação desses dados, e que revoga o Regulamento (CE) n.o 45/2001 e a Decisão n.o 1247/2002/CE (JO L 295 de 21.11.2018, p. 39).

(22) https://edps.europa.eu/data-protection/our-work/publications/formal-comments/draft-commission-implementing-regulation-4_en

6.9.2022

Jornal Oficial da União Europeia

L 231/24

REGULAMENTO (UE) 2022/1465 DA COMISSÃO

de 5 de setembro de 2022

que altera o anexo I do Regulamento (CE) n.o 1334/2008 do Parlamento Europeu e do Conselho no que diz respeito a determinadas substâncias aromatizantes

(Texto relevante para efeitos do EEE)

A COMISSÃO EUROPEIA,

Tendo em conta o Tratado sobre o Funcionamento da União Europeia,

Tendo em conta o Regulamento (CE) n.o 1334/2008 do Parlamento Europeu e do Conselho, de 16 de dezembro de 2008, relativo aos aromas e a determinados ingredientes alimentares com propriedades aromatizantes utilizados nos e sobre os géneros alimentícios e que altera o Regulamento (CEE) n.o 1601/91 do Conselho, os Regulamentos (CE) n.o 2232/96 e (CE) n.o 110/2008 e a Diretiva 2000/13/CE (1), nomeadamente o artigo 11.o, n.o 3,

Tendo em conta o Regulamento (CE) n.o 1331/2008 do Parlamento Europeu e do Conselho, de 16 de dezembro de 2008, que estabelece um procedimento de autorização comum aplicável a aditivos alimentares, enzimas alimentares e aromas alimentares (2), nomeadamente o artigo 7.o, n.o 5,

Considerando o seguinte:

(1)	O anexo I do Regulamento (CE) n.o 1334/2008 estabelece uma lista da União de aromas e materiais de base autorizados para utilização nos e sobre os géneros alimentícios e as respetivas condições de utilização.

(2)	O Regulamento de Execução (UE) n.o 872/2012 da Comissão (3) adotou uma lista de substâncias aromatizantes e incluiu essa lista na parte A do anexo I do Regulamento (CE) n.o 1334/2008.

(3)	Essa lista pode ser atualizada em conformidade com o procedimento comum referido no artigo 3.o, n.o 1, do Regulamento (CE) n.o 1331/2008, quer por iniciativa da Comissão quer na sequência de um pedido apresentado por um Estado-Membro ou por uma parte interessada.

(4)

A lista da União de aromas e materiais de base estabelecida no anexo I do Regulamento (CE) n.o 1334/2008 contém, entre outras, um certo número de substâncias aromatizantes relativamente às quais, quando da adoção da lista pelo Regulamento de Execução (UE) n.o 872/2012, não tinha sido possível à Autoridade Europeia para a Segurança dos Alimentos («Autoridade») excluir um risco de segurança para a saúde do consumidor com base nos dados disponíveis e, por conseguinte, esta tinha considerado que eram necessários dados adicionais para concluir a sua avaliação. Essas substâncias foram incluídas na lista da União de substâncias aromatizantes, mas na condição de serem apresentados dados de segurança para dar resposta às preocupações expressas pela Autoridade antes do termo dos prazos específicos estabelecidos no anexo I, parte A, do Regulamento (CE) n.o 1334/2008. Entre as substâncias incluídas na lista da União de aromas e materiais de base, mas identificadas por uma nota de rodapé exigindo que a Autoridade conclua a sua avaliação, constavam as seguintes cinco substâncias da avaliação do grupo de aromas 208 (FGE.208): p-menta-1,8-dien-7-ol (n.o FL 02.060), mirtenol (n.o FL 02.091), mirtenal (n.o FL 05.106), acetato de p-menta-1,8-dien-7-ilo (n.o FL 09.278) e acetato de mirtenilo (n.o FL 09.302). A Autoridade solicitou dados científicos adicionais que foram posteriormente apresentados pelos requerentes.

(5)

No seu parecer científico de 24 de junho de 2015 (4), a Autoridade avaliou os dados apresentados e concluiu que a substância representativa do grupo, p-menta-1,8-dien-7-al (n.o FL 05.117), era genotóxica in vivo e que, por conseguinte, a sua utilização como substância aromatizante suscitava uma preocupação de segurança.

(6)	Na sequência deste parecer, a Comissão retirou esta substância da lista da União de aromas através do Regulamento (UE) 2015/1760 (5).

(7)	Uma vez que o p-menta-1,8-dien-7-al (n.o FL 05.117) é representativo de quatro outras substâncias pertencentes à avaliação do grupo de aromas 208 (FGE.208), a Comissão retirou também essas quatro substâncias da lista da União através do Regulamento (UE) 2016/637 da Comissão (6).

(8)

No que diz respeito ao p-menta-1,8-dien-7-ol (n.o FL 02.060), ao mirtenol (n.o FL 02.091), ao mirtenal (n.o FL 05.106), ao acetato de p-menta-1,8-dien-7-ilo (n.o FL 09.278) e ao acetato de mirtenilo (n.o FL 09.302), os requerentes destas substâncias assinalaram que tinham lançado conjuntos individuais de estudos de toxicidade específicos sobre as mesmas, dando resposta às preocupações expressas pela Autoridade no seu parecer de 24 de junho de 2015. Os requerentes comprometeram-se a apresentar os novos dados solicitados antes de 30 de abril de 2016.

(9)

Na pendência da avaliação dessas substâncias pela Autoridade, bem como da sua eventual avaliação completa no âmbito do procedimento de painel da Autoridade e da conclusão do processo regulamentar ulterior, a Comissão adotou o Regulamento (UE) 2016/1244 (7), que limita as utilizações destas substâncias aromatizantes, mantendo simultaneamente o seu estatuto de substâncias em avaliação.

(10)	Os requerentes apresentaram estudos científicos e outros dados pertinentes para a avaliação até 30 de abril de 2016.

(11)

Nos seus pareceres de 22 de março de 2017 (8) e de 11 de dezembro de 2018 (9), a Autoridade avaliou os dados apresentados e outros dados adicionais, excluiu a preocupação quanto à genotoxicidade dessas cinco substâncias e decidiu que podiam ser avaliadas no âmbito do procedimento de avaliação das substâncias aromatizantes existentes referido no Regulamento (CE) n.o 1565/2000 da Comissão (10). Para o efeito, a Autoridade atribuiu essas cinco substâncias à avaliação do grupo de aromas 73 (FGE.73). Nos seus pareceres de 19 de setembro de 2017 (11) e de 10 de dezembro de 2020 (12), a Autoridade atualizou as avaliações deste grupo de substâncias e concluiu que essas substâncias não suscitam preocupações de segurança. Apresentou igualmente recomendações para alterar o nome e as especificações de algumas dessas substâncias.

(12)

Ao abrigo do Regulamento (CE) n.o 1334/2008, a Autoridade tinha de concluir a avaliação das 20 substâncias seguintes incluídas na avaliação do grupo de aromas 203 (FGE.203 rev.1): deca-2,4-dien-1-ol (n.o FL 02.139); hepta-2,4-dien-1-ol (n.o FL 02.153); hexa-2,4-dien-1-ol (n.o FL 02.162); nona-2,4-dien-1-ol (n.o FL 02.188); hexa-2(trans),4(trans)-dienal (n.o FL 05.057); trideca-2(trans),4(cis),7(cis)-trienal (n.o FL 05.064); nona-2,4-dienal (n.o FL 05.071); 2,4-decadienal (n.o FL 05.081); hepta-2,4-dienal (n.o FL 05.084); penta-2,4-dienal (n.o FL 05.101); undeca-2,4-dienal (n.o FL 05.108); dodeca-2,4-dienal (n.o FL 05.125); octa-2(trans),4(trans)-dienal (n.o FL 05.127); deca-2(trans),4(trans)-dienal (n.o FL 05.140); deca-2,4,7-trienal (n.o FL 05.141); nona-2,4,6-trienal (n.o FL 05.173); 2,4-octadienal (n.o FL 05.186); trans-2,trans-4-nonadienal (n.o FL 05.194); trans-2,trans-4-undecadienal (n.o FL 05.196) e acetato de hexa-2,4-dienilo (n.o FL 09.573). A Autoridade solicitou dados científicos adicionais que foram posteriormente apresentados pelos requerentes.

(13)	As substâncias hexa-2(trans),4(trans)-dienal (n.o FL 05.057) e deca-2(trans),4(trans)-dienal (n.o FL 05.140) foram usadas como substâncias representativas para o grupo, tendo-se apresentado os respetivos dados de toxicidade.

(14)

No seu parecer científico de 26 de março de 2014 (13), a Autoridade avaliou os dados apresentados e concluiu que não podia excluir preocupações de segurança para ambas as substâncias representativas do grupo. Por conseguinte, a Autoridade não pôde concluir a avaliação das substâncias pertencentes ao grupo FGE 203.

(15)	Os requerentes destas substâncias assinalaram que tinham lançado uma série de estudos de toxicidade específicos sobre as substâncias deste grupo, respondendo às preocupações manifestadas pela Autoridade no seu parecer de 26 de março de 2014.

(16)	A Autoridade solicitou mais dados sobre a identidade e a caracterização, bem como dados relativos à quantidade anual produzida e à ingestão, a fim de permitir uma avaliação da exposição adequada, com o intuito de efetuar uma avaliação completa da segurança destas substâncias.

(17)

Os requerentes comprometeram-se a apresentar os novos dados solicitados até 30 de setembro de 2016. Na pendência da apresentação dos dados adicionais, da avaliação da genotoxicidade dessas substâncias pela Autoridade, bem como da sua eventual avaliação completa no âmbito do procedimento de painel da Autoridade e da conclusão do processo regulamentar ulterior, a Comissão adotou o Regulamento (UE) 2017/378 (14), que limita as utilizações destas substâncias aromatizantes, mantendo simultaneamente o seu estatuto de substâncias em avaliação.

(18)	Os requerentes apresentaram estudos científicos e dados pertinentes para esta avaliação até 30 de setembro de 2016.

(19)

No seu parecer de 5 de junho de 2018 (15), a Autoridade avaliou os dados apresentados, excluiu a preocupação quanto à genotoxicidade dessas substâncias e decidiu que podiam ser avaliadas no âmbito do procedimento de avaliação das substâncias aromatizantes existentes referido no Regulamento (CE) n.o 1565/2000 da Comissão. Para o efeito, a Autoridade atribuiu 16 dessas substâncias à avaliação do grupo de aromas 70 (FGE.70) e quatro delas à avaliação do grupo de aromas 05 (FGE.05). Nos seus pareceres adotados em 5 de junho de 2019 (16) e 26 de junho de 2019 (17), a Autoridade atualizou as avaliações das substâncias incluídas na avaliação do grupo de aromas 70, revisão 1 (FGE.70 Rev1) e na avaliação do grupo de aromas 05, revisão 3 (FGE.05 Rev3), respetivamente. No que diz respeito às 16 substâncias do FGE.70 Rev.1, a Autoridade concluiu que não suscitam preocupações de segurança e formulou recomendações para alterar o nome e as especificações de algumas dessas substâncias. No que diz respeito às quatro substâncias do FGE.05 Rev.3, a Autoridade concluiu igualmente que não suscitam preocupações de segurança e formulou recomendações para alterar o nome e as especificações de algumas dessas quatro substâncias.

(20)	O anexo I, parte A, do Regulamento (CE) n.o 1334/2008 deve, portanto, ser alterado em conformidade.

(21)	As medidas previstas no presente regulamento estão em conformidade com o parecer do Comité Permanente dos Vegetais, Animais e Alimentos para Consumo Humano e Animal,

ADOTOU O PRESENTE REGULAMENTO:

Artigo 1.o

O anexo I, parte A, do Regulamento (CE) n.o 1334/2008 é alterado em conformidade com o anexo do presente regulamento.

Artigo 2.o

O presente regulamento entra em vigor no vigésimo dia seguinte ao da sua publicação no Jornal Oficial da União Europeia.

O presente regulamento é obrigatório em todos os seus elementos e diretamente aplicável em todos os Estados-Membros.

Feito em Bruxelas, em 5 de setembro de 2022.

Pela Comissão

A Presidente

Ursula VON DER LEYEN

(1) JO L 354 de 31.12.2008, p. 34.

(2) JO L 354 de 31.12.2008, p. 1.

(3) Regulamento de Execução (UE) n.o 872/2012 da Comissão, de 1 de outubro de 2012, que adota a lista das substâncias aromatizantes prevista no Regulamento (CE) n.o 2232/96 do Parlamento Europeu e do Conselho, inclui essa lista no anexo I do Regulamento (CE) n.o 1334/2008 do Parlamento Europeu e do Conselho e revoga o Regulamento (CE) n.o 1565/2000 e a Decisão 1999/217/CE (JO L 267 de 2.10.2012, p. 1).

(4) Scientific Opinion on Flavouring Group Evaluation 208 Revision 1 (FGE.208Rev1): Consideration of genotoxicity data on representatives for 10 alicyclic aldehydes with the α,β-unsaturation in ring/side-chain and precursors from chemical subgroup 2.2 of FGE.19 (não traduzido para português). EFSA Journal 2015;13(7):4173, 28 pp. doi:10.2903/j.efsa.2015.4173 Disponível em linha: www.efsa.europa.eu/efsajournal

(5) Regulamento (UE) 2015/1760 da Comissão, de 1 de outubro de 2015, que altera o anexo I do Regulamento (CE) n.o 1334/2008 do Parlamento Europeu e do Conselho no que diz respeito à retirada da lista da União da substância aromatizante p-menta-1,8-dien-7-al (JO L 257 de 2.10.2015, p. 27).

(6) Regulamento (UE) 2016/637 da Comissão, de 22 de abril de 2016, que altera o anexo I do Regulamento (CE) n.o 1334/2008 do Parlamento Europeu e do Conselho no que diz respeito à retirada de determinadas substâncias aromatizantes da lista da União (JO L 108 de 23.4.2016, p. 24).

(7) Regulamento (UE) 2016/1244 da Comissão, de 28 de julho de 2016, que altera o anexo I do Regulamento (CE) n.o 1334/2008 do Parlamento Europeu e do Conselho no que diz respeito a determinadas substâncias aromatizantes de um grupo relacionado com uma estrutura insaturada nas posições alfa e beta (JO L 204 de 29.7.2016, p. 7).

(8) Scientific Opinion on Flavouring Group Evaluation 208 Revision 2 (FGE.208Rev2): Consideration of genotoxicity data on alicyclic aldehydes with α,β-unsaturation in ring/side-chain and precursors from chemical subgroup 2.2 of FGE.19 (não traduzido para português). EFSA Journal 2017;15(5):4766. https://doi.org/10.2903/j.efsa.2020.5941.

(9) Scientific Opinion on Flavouring Group Evaluation 208 Revision 3 (FGE.208Rev3): Consideration of genotoxicity data on alicyclic aldehydes with α,β-unsaturation in ring/side-chain and precursors from chemical subgroup 2.2 of FGE.19 (não traduzido para português). EFSA Journal 2019;17(1):5569. https://doi.org/10.2903/j.efsa.2020.5941.

(10) Regulamento (CE) n.o 1565/2000 da Comissão, de 18 de julho de 2000, que estabelece as medidas necessárias para a adoção de um programa de avaliação em aplicação do Regulamento (CE) n.o 2232/96 do Parlamento Europeu e do Conselho (JO L 180 de 19.7.2000, p. 8).

(11) Scientific Opinion on Flavouring Group Evaluation 73 Revision 4 (FGE.73Rev4): Consideration of alicyclic alcohols, aldehydes, acids and related esters evaluated by JECFA (59th and 63rd meeting) structurally related to primary saturated or unsaturated alicyclic alcohols, aldehydes, acids and esters evaluated by EFSA in FGE.12Rev5 (não traduzido para português). EFSA Journal 2017;15(11):5010 doi: 10.2903/j.efsa.2017.5010. Disponível em linha: www.efsa.europa.eu/efsajournal

(12) Scientific Opinion on Flavouring Group Evaluation 73 Revision 5 (FGE.73Rev5): Consideration of alicyclic alcohols, aldehydes, acids and related esters evaluated by JECFA (59th, 63rd and 86th meeting) and structurally related to substances evaluated in FGE.12Rev5 (não traduzido para português). EFSA Journal 2020;18(1):5970. doi: 10.2903/j.efsa.2020.5970. Disponível em linha: www.efsa.europa.eu/efsajournal

(13) Scientific Opinion on Flavouring Group Evaluation 203 Rev 1 (FGE.203 Rev1): Painel CEF da EFSA (Painel dos Materiais em Contacto com Géneros Alimentícios e das Enzimas, Aromatizantes e Auxiliares Tecnológicos), 2014. Scientific Opinion on Flavouring Group Evaluation 203 Revision 1 (FGE.203Rev1): α,β-unsaturated aliphatic aldehydes and precursors from chemical subgroup 1.1.4 of FGE.19 with two or more conjugated double-bonds and with or without additional non-conjugated double-bonds (não traduzido para português). EFSA Journal 2014;12(4):3626, 31 pp. doi:10.2903/j.efsa.2014.3626 Disponível em linha: www.efsa.europa.eu/efsajournal

(14) Regulamento (UE) 2017/378 da Comissão, de 3 de março de 2017, que altera o anexo I do Regulamento (CE) n.o 1334/2008 do Parlamento Europeu e do Conselho no que diz respeito a determinadas substâncias aromatizantes (JO L 58 de 4.3.2017, p. 14).

(15) Scientific Opinion on Flavouring Group Evaluation 203 Revision 2 (FGE.203Rev2): α,β-unsaturated aliphatic aldehydes and precursors from chemical subgroup 1.1.4 of FGE.19 with two or more conjugated double-bonds and with or without additional non-conjugated double-bonds (não traduzido para português). EFSA Journal 2018;16(7):5322.

(16) Scientific Opinion on Flavouring Group Evaluation 70, Revision 1 (FGE.70Rev1): Consideration of aliphatic, linear, α,β-unsaturated, di- and trienals and related alcohols, acids and esters evaluated by JECFA (61st-68th-69th meeting) (não traduzido para português). EFSA Journal 2019;17(7):5749.

(17) Scientific Opinion on Flavouring Group Evaluation 5, Revision 3 (FGE.05Rev3): Branched- and straight-chain unsaturated aldehydes, dienals, unsaturated and saturated carboxylic acids and related esters with saturated and unsaturated aliphatic alcohols and a phenylacetic acid related ester from chemical groups 1, 2, 3, 5 and 15 (não traduzido para português). EFSA Journal 2019;17(8):5761.

ANEXO

O anexo I, parte A, secção 2, quadro 1, do Regulamento (CE) n.o 1334/2008 é alterado do seguinte modo:

A entrada relativa ao n.o FL 02.060 passa a ter a seguinte redação:

«02.060

p-Menta-1,8-dien-7-ol

536-59-4

974

2024

EFSA»

A entrada relativa ao n.o FL 02.091 passa a ter a seguinte redação:

«02.091

Mirtenol

515-00-4

981

10285

EFSA»

A entrada relativa ao n.o FL 02.139 passa a ter a seguinte redação:

«02.139

Deca-(2E,4E)-dien-1-ol

18409-21-7

1189

11748

EFSA»

A entrada relativa ao n.o FL 02.153 passa a ter a seguinte redação:

«02.153

Hepta-2,4-dien-1-ol

33467-79-7

1784

EFSA»

A entrada relativa ao n.o FL 02.162 passa a ter a seguinte redação:

«02.162

Hexa-2,4-dien-1-ol

111-28-4

1174

EFSA»

A entrada relativa ao n.o FL 02.188 passa a ter a seguinte redação:

«02.188

Nona-2,4-dien-1-ol

62488-56-6

1183

11802

No mínimo 92 %; componente secundário: 3-4 % de 2-Nonen-1-ol.

EFSA»

A entrada relativa ao n.o FL 05.057 passa a ter a seguinte redação:

«05.057

Hexa-2(trans),4(trans)-dienal

142-83-6

1175

640

EFSA»

A entrada relativa ao n.o FL 05.064 passa a ter a seguinte redação:

«05.064

Trideca-2(trans),4(cis),7(cis)-trienal

13552-96-0

1198

685

No mínimo 71 %; componentes secundários: 14 % de 4-cis-7-cis-Tridecadienol; 6 % de 3-cis-7-cis-Tridecadienol; 5 % de 2-trans-7-cis-Tridecadienal; 3 % de 2-trans-4-trans-7-cis-Tridecatrienal.

EFSA»

A entrada relativa ao n.o FL 05.071 passa a ter a seguinte redação:

«05.071

Nona-2,4-dienal

6750-03-4

1185

732

No mínimo 89 %; componentes secundários: 5-6 % de 2,4-Nonadien-1-ol e 1-2 % de 2-Nonen-1-ol.

EFSA»

A entrada relativa ao n.o FL 05.081 passa a ter a seguinte redação:

«05.081

2,4-Decadienal

2363-88-4

3135

2120

No mínimo 89 %; componentes secundários: mistura de (cis, cis)-, (cis, trans)- e (trans, cis)-2,4-Decadienais (soma de todos os isómeros 95 %); acetona e isopropanol

EFSA»

A entrada relativa ao n.o FL 05.084 passa a ter a seguinte redação:

«05.084

Hepta-(2E,4E)-dienal

4313-03-5

1179

729

No mínimo 92 %; componentes secundários: 2-4 % de (E,Z)-2,4-Heptadienal e 2-4 % de ácido 2,4-Heptadienoico.

EFSA»

A entrada relativa ao n.o FL 05.101 passa a ter a seguinte redação:

«05.101

Penta-2,4-dienal

764-40-9

1173

11695

EFSA»

A entrada relativa ao n.o FL 05.106 passa a ter a seguinte redação:

«05.106

Mirtenal

564-94-3

980

10379

EFSA»

A entrada relativa ao n.o FL 05.108 passa a ter a seguinte redação:

«05.108

Undeca-2,4-dienal

13162-46-4

1195

10385

EFSA»

A entrada relativa ao n.o FL 05.125 passa a ter a seguinte redação:

«05.125

Dodeca-(2E,4E)-dienal

21662-16-8

1196

11758

No mínimo 85 %; componente secundário: 11-12 % de isómero 2-trans-4-cis.

EFSA»

A entrada relativa ao n.o FL 05.127 passa a ter a seguinte redação:

«05.127

Octa-2(trans),4(trans)-dienal

30361-28-5

1181

11805

EFSA»

A entrada relativa ao n.o FL 05.140 passa a ter a seguinte redação:

«05.140

Deca-2(trans),4(trans)-dienal

25152-84-5

1190

2120

Pelo menos 90 %, no mínimo, do isómero (E, E); 95 % (soma dos isómeros)

EFSA»

A entrada relativa ao n.o FL 05.141 passa a ter a seguinte redação:

«05.141

Deca-2,4,7-trienal

51325-37-2

1786

EFSA»

A entrada relativa ao n.o FL 05.173 passa a ter a seguinte redação:

«05.173

Nona-(2E,4E,6E)-trienal

57018-53-8

1785

EFSA»

A entrada relativa ao n.o FL 05.186 passa a ter a seguinte redação:

«05.186

2,4-Octadienal

5577-44-6

11805

Pelo menos 85 % de isómero E, E com 10 % de isómero E, Z

EFSA»

A entrada relativa ao n.o FL 05.194 passa a ter a seguinte redação:

«05.194

(2E, 4E)-Nona-2,4-dienal

5910-87-2

732

No mínimo 89 %; componentes secundários: pelo menos 5 % de 2,4-Nonadien-1-ol e 2-Nonen-1-ol e outros isómeros do 2,4-Nonadienal.

EFSA»

A entrada relativa ao n.o FL 05.196 passa a ter a seguinte redação:

«05.196

(2E, 4E)-Undeca-2,4-dienal

EFSA»

A entrada relativa ao n.o FL 09.278 passa a ter a seguinte redação:

«09.278

Acetato de p-menta-1,8-dien-7-ilo

15111-96-3

975

10742

EFSA»

A entrada relativa ao n.o FL 09.302 passa a ter a seguinte redação:

«09.302

Acetato de mirtenilo

35670-93-0

982

10887

EFSA»

A entrada relativa ao n.o FL 09.573 passa a ter a seguinte redação:

«09.573

Acetato de hexa-2,4-dienilo

1516-17-2

1780

10675

EFSA»

6.9.2022

Jornal Oficial da União Europeia

L 231/36

REGULAMENTO DE EXECUÇÃO (UE) 2022/1467 DA COMISSÃO

de 5 de setembro de 2022

que altera o Regulamento de Execução (UE) 2015/2378 no respeitante aos formulários normalizados e aos formatos eletrónicos a utilizar em relação à Diretiva 2011/16/UE do Conselho e à lista de dados estatísticos a fornecer pelos Estados-Membros para efeitos de avaliação dessa diretiva

A COMISSÃO EUROPEIA,

Tendo em conta o Tratado sobre o Funcionamento da União Europeia,

Tendo em conta a Diretiva 2011/16/UE do Conselho, de 15 de fevereiro de 2011, relativa à cooperação administrativa no domínio da fiscalidade e que revoga a Diretiva 77/799/CEE (1), nomeadamente o artigo 20.o, n.o 4,

Considerando o seguinte:

(1)	A Diretiva (UE) 2021/514 do Conselho (2) alterou a Diretiva 2011/16/UE, a fim de melhorar as disposições relacionadas com todas as formas de troca de informações e de cooperação administrativa, prevendo a troca automática obrigatória de informações comunicadas pelos operadores de plataformas.

(2)	Por conseguinte, é necessário adaptar o Regulamento de Execução (UE) 2015/2378 da Comissão (3) a essas alterações. A troca automática de informações nos termos do artigo 8.o-AC, n.o 2, da Diretiva 2011/16/UE deve ser efetuada por meio de um formato eletrónico normalizado.

(3)	Em conformidade com a Diretiva 2011/16/UE, é igualmente necessário estabelecer as modalidades práticas para o registo e identificação de determinados operadores de plataformas reportantes nos termos do artigo 8.o-AC, n.o 4.

(4)

Nos termos do artigo 8.o-AC, n.o 6, da Diretiva 2011/16/UE, é necessário criar um registo central no qual são inscritas as informações que têm de ser notificadas em conformidade com o artigo 8.o-AC, n.o 5, e comunicadas em conformidade com o anexo V, secção IV, ponto F, n.os 2 e 4. Este registo central deve ser disponibilizado às autoridades competentes dos Estados-Membros. Deve ser utilizado um formulário normalizado para a comunicação e a inscrição dessas informações no registo.

(5)

O artigo 23.o, n.o 4, da Diretiva 2011/16/UE prevê que os Estados-Membros disponibilizem uma lista de dados estatísticos para efeitos da sua avaliação. Por razões de coerência e de segurança jurídica, a data de aplicação do presente regulamento deve coincidir com a data de aplicação prevista no artigo 2.o, n.o 1, segundo parágrafo, da Diretiva (UE) 2021/514.

(6)	Em conformidade com o artigo 42.o, n.o 1, do Regulamento (UE) 2018/1725 do Parlamento Europeu e do Conselho (4), a Autoridade Europeia para a Proteção de Dados foi consultada sobre as medidas previstas no regulamento.

(7)	As medidas previstas no presente regulamento estão em conformidade com o parecer do Comité de Cooperação Administrativa em Matéria Fiscal,

ADOTOU O PRESENTE REGULAMENTO:

Artigo 1.o

O Regulamento de Execução (UE) 2015/2378 é alterado do seguinte modo:

1)	Ao artigo 2.o é aditado o seguinte número: «3. O formato eletrónico a utilizar para a troca automática de informações obrigatória prevista no artigo 8.o-AC, n.o 2, da Diretiva 2011/16/UE deve estar em conformidade com o anexo XIV do presente regulamento.»;

2)	Ao artigo 2.o-D, n.o 1, é aditado o seguinte parágrafo: «A lista dos dados estatísticos necessários para a troca automática de informações obrigatória, nos termos do artigo 8.o-AC da Diretiva 2011/16/UE, está estabelecida no anexo XV do presente regulamento.»;

É aditado o seguinte artigo 2.o-F:

«Artigo 2.o-F

Formulários normalizados para a comunicação de informações ao registo central sobre operadores de plataformas excluídos e operadores de plataformas estrangeiros, formato do número de identificação individual dos operadores de plataforma estrangeiros e período de conservação das informações eliminadas do registo central

1. O formulário a utilizar para a comunicação de informações ao registo central sobre operadores de plataformas excluídos nos termos do artigo 8.o-AC, n.o 6, da Diretiva 2011/16/UE deve estar em conformidade com o anexo XVI do presente regulamento.

2. Nos termos do artigo 8.o-AC, n.o 6, da Diretiva 2011/16/UE, os principais elementos a inscrever no registo central são as informações enumeradas no anexo V, secção IV, ponto F, n.os 2 e 4, da referida diretiva e no anexo XVI do presente regulamento. A criação do registo central e o tratamento de dados pessoais efetuado no âmbito do registo central pela Comissão em nome das autoridades competentes dos Estados-Membros devem respeitar o disposto no Regulamento (UE) 2016/679 do Parlamento Europeu e do Conselho (*1) e no Regulamento (UE) 2018/1725 do Parlamento Europeu e do Conselho (*2). As autoridades competentes dos Estado-Membro são consideradas responsáveis pelo tratamento de dados, e a Comissão é considerada subcontratante em conformidade com o Regulamento (UE) 2016/679.

3. O formato do número de identificação individual dos operadores de plataformas estrangeiros na aceção do artigo 8.o-AC, n.o 4, da Diretiva 2011/16/UE é estabelecido no anexo XVI do presente regulamento.

4. O período de conservação das informações eliminadas do registo central nos termos do anexo V, secção IV, ponto F, n.o 5, alínea d), e do artigo 8.o-AC, n.o 5, da Diretiva 2011/16/UE é fixado no anexo XVI do presente regulamento.

(*1) Regulamento (UE) 2016/679 do Parlamento Europeu e do Conselho, de 27 de abril de 2016, relativo à proteção das pessoas singulares no que diz respeito ao tratamento de dados pessoais e à livre circulação desses dados e que revoga a Diretiva 95/46/CE (Regulamento Geral sobre a Proteção de Dados) (JO L 119 de 4.5.2016, p. 1)."

(*2) Regulamento (UE) 2018/1725 do Parlamento Europeu e do Conselho, de 23 de outubro de 2018, relativo à proteção das pessoas singulares no que diz respeito ao tratamento de dados pessoais pelas instituições e pelos órgãos e organismos da União e à livre circulação desses dados, e que revoga o Regulamento (CE) n.° 45/2001 e a Decisão n.° 1247/2002/CE (JO L 295 de 21.11.2018, p. 39)»;"

4)	Os anexos I, IX e X são substituídos pelo texto constante do anexo I do presente regulamento;

5)	O anexo V é alterado no anexo II do presente regulamento;

6)	São aditados os anexos XIV, XV e XVI cujo texto figura no anexo III do presente regulamento.

Artigo 2.o

O presente regulamento entra em vigor no vigésimo dia seguinte ao da sua publicação no Jornal Oficial da União Europeia.

O presente regulamento é aplicável a partir de 1 de janeiro de 2023.

O presente regulamento é obrigatório em todos os seus elementos e diretamente aplicável em todos os Estados-Membros.

Feito em Bruxelas, em 5 de setembro de 2022.

Pela Comissão

A Presidente

Ursula VON DER LEYEN

(1) JO L 64 de 11.3.2011, p. 1.

(2) Diretiva (UE) 2021/514 do Conselho, de 22 de março de 2021, que altera a Diretiva 2011/16/UE relativa à cooperação administrativa no domínio da fiscalidade (JO L 104 de 25.3.2021, p. 1).

(3) Regulamento de Execução (UE) 2015/2378 da Comissão, de 15 de dezembro de 2015, que fixa as normas de execução de certas disposições da Diretiva 2011/16/UE do Conselho relativa à cooperação administrativa no domínio da fiscalidade e que revoga o Regulamento de Execução (UE) n.o 1156/2012 (JO L 332 de 18.12.2015, p. 1).

(4) Regulamento (UE) 2018/1725 do Parlamento Europeu e do Conselho, de 23 de outubro de 2018, relativo à proteção das pessoas singulares no que diz respeito ao tratamento de dados pessoais pelas instituições e pelos órgãos e organismos da União e à livre circulação desses dados, e que revoga o Regulamento (CE) n.° 45/2001 e a Decisão n.° 1247/2002/CE (JO L 295 de 21.11.2018, p. 39).

ANEXO I

Os anexos I, IX e X são substituídos pelos seguintes:

«Anexo I

Formulário referido no artigo 1.o, n.o 2

O formulário a utilizar para os pedidos de informações e de inquéritos administrativos nos termos dos artigos 5.o e 5.o-A da Diretiva 2011/16/UE, bem como para as respetivas respostas, avisos de receção, pedidos de informações complementares de caráter geral e declarações de incapacidade ou de recusa nos termos do artigo 7.o da referida diretiva, deve conter os seguintes campos (1):

—	Base jurídica,

—	Número de referência,

—

Data,

—	Identidade das autoridades requerente e requerida,

—	Identidade da pessoa objeto de inspeção ou investigação,

—

Descrição geral do caso e, se for caso disso, informações antecedentes específicas suscetíveis de permitir a avaliação da relevância previsível das informações requeridas para a administração e execução da legislação interna dos Estados-Membros respeitante aos impostos a que se refere o artigo 2.o da Diretiva 2011/16/UE,

—	Fim fiscal a que se destina o pedido de informações,

—	Período sob investigação,

—	Nome e endereço de qualquer pessoa que se suponha estar na posse das informações solicitadas,

—	Cumprimento do requisito legal estabelecido no artigo 16.o, n.o 1, da Diretiva 2011/16/UE,

—	Cumprimento do requisito legal estabelecido no artigo 17.o, n.o 1, da Diretiva 2011/16/UE,

—	Pedido fundamentado de inquérito administrativo e razões da recusa de realização do inquérito administrativo pedido,

—	Aviso de receção do pedido de informações,

—	Pedido de informações complementares de caráter geral,

—	Razões da incapacidade ou recusa de prestar informações,

—	Razões da incapacidade para responder no prazo relevante e data em que a autoridade requerida considera estar em condições de responder,

—	Uma descrição pormenorizada do grupo.

«Anexo IX

Lista referida no artigo 2.o-D

Os dados estatísticos necessários para todas as formas de cooperação administrativa, além da troca automática de informações obrigatória, nos termos do artigo 23.o, n.o 4, da Diretiva 2011/16/UE abrangem as seguintes informações:

—	Identificação do Estado-Membro,

—

Ano,

—

Parte A: Estatísticas por Estado-Membro em matéria de troca de informações

—

sobre troca de informações a pedido (artigos 5.o, 6.o e 7.o da Diretiva 2011/16/UE)

—	Número de pedidos enviados,

—	Número de respostas recebidas,

—	Número de respostas completas recebidas no prazo legal,

—	Número de respostas com informações (parciais ou totais) recebidas no prazo de dois meses,

—	Número de pedidos recebidos,

—	Número de respostas enviadas,

—	Número de recusas com fundamento no artigo 17.o da Diretiva 2011/16/UE,

—

sobre troca de informações a pedido de grupos (artigo 5.o-A da Diretiva 2011/16/UE)

—	Número de pedidos de grupos enviados,

—	Número de respostas de grupos recebidas,

—	Número de respostas de grupos completas recebidas no prazo legal,

—	Número de respostas de grupos com informações (parciais ou totais) recebidas no prazo de dois meses,

—	Número de pedidos de grupos recebidos,

—	Número de respostas de grupos enviadas,

—	Número de recusas de grupos com fundamento no artigo 17.o da Diretiva 2011/16/UE,

—

sobre troca espontânea de informações (artigos 9.o e 10.o da Diretiva 2011/16/UE)

—	Número de trocas espontâneas enviadas,

—	Número de trocas espontâneas recebidas,

—

Parte B: Estatísticas sobre outras formas de cooperação administrativa

—

sobre a presença nos serviços administrativos e a participação em inquéritos administrativos (artigo 11.o da Diretiva 2011/16/UE)

—	Número de presenças recebidas nos serviços administrativos e participação em inquéritos administrativos no Estado-Membro,

—	Número de presenças efetuadas nos serviços administrativos e participação em inquéritos administrativos no exterior,

—

sobre controlos simultâneos (artigo 12.o da Diretiva 2011/16/UE)

—	Número de controlos simultâneos que o Estado-Membro tenha iniciado,

—	Número de controlos simultâneos em que o Estado-Membro tenha participado,

—

sobre pedidos de notificação (artigo 13.o da Diretiva 2011/16/UE)

—	Número de pedidos de notificação enviados,

—	Número de pedidos de notificação recebidos,

—

sobre retorno de informação (artigo 14.o da Diretiva 2011/16/UE)

—	Número de pedidos de retornos de informação enviados,

—	Número de retornos de informação recebidos,

—	Número de pedidos de retornos de informação recebidos,

—	Número de retornos de informação enviados,

—

Parte C: Estatísticas sobre as estimativas de receitas adicionais ou aumento do imposto liquidado devido à cooperação administrativa. As informações no âmbito desta parte são facultativas.

—	Devido à troca de informações a pedido,

—	Devido à troca espontânea de informações,

—	Em resultado do controlo simultâneo,

—	Número global e número de casos.

«Anexo X

Lista referida no artigo 2.o-D

Os dados estatísticos necessários para a troca automática de informações obrigatória prevista no artigo 23.o, n.o 4, da Diretiva 2011/16/UE sobre as categorias de rendimento e de património referidas no artigo 8.o, n.o 1, da diretiva abrangem as seguintes informações:

—	Para todas as categorias de rendimento e de património referidas no artigo 8.o, n.o 1, da Diretiva 2011/16/UE: estatísticas sobre a mensagem e o contribuinte,

—	No caso de rendimentos do trabalho e de honorários de administradores: estatísticas sobre a mensagem e o beneficiário, a mensagem e o pagador, o beneficiário e o vínculo, o pagador e o vínculo, o beneficiário e os rendimentos,

—	No caso de pensões: estatísticas sobre a mensagem e o beneficiário, a mensagem e o pagador, o beneficiário, o pagador, o regime, o rendimento,

—	No caso de produtos de seguro de vida: estatísticas sobre a mensagem e a apólice, conjunto das apólices, o evento,

—	No caso de propriedade e rendimentos de bens imóveis: estatísticas sobre a mensagem e as partes, conjunto das partes, quantidade e valor dos bens, quantidade e valor das transações, quantidade e valor no caso de empréstimos, quantidade e valor dos rendimentos associados aos direitos,

—	No caso de rendimentos de royalties: estatísticas sobre a mensagem e o beneficiário, a mensagem e o pagador, o beneficiário e o rendimento,

—	No caso de mensagens relativas ao estatuto: estatísticas sobre mensagens relativas ao estatuto, erros nestas mensagens,

—	No caso de mensagens não contendo nenhum dado: estatísticas sobre as mensagens que não contêm nenhum dado.

(1) Contudo, apenas os campos efetivamente preenchidos num caso concreto devem constar do respetivo formulário.

ANEXO II

A alínea b) do anexo V passa a ter a seguinte redação:

«b)	No que respeita ao texto para comunicar informações sobre rendimentos do trabalho, os honorários de administradores e royalties:»

ANEXO III

São aditados os seguintes anexos XIV, XV e XVI:

«Anexo XIV

Formato eletrónico referido no artigo 2.o, n.o 3

O formato eletrónico para a troca automática de informações obrigatória prevista no artigo 8.o-AC, n.o 2, da Diretiva 2011/16/UE é conforme à estrutura em árvore que se segue e contém os seguintes elementos e atributos (1):

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:dpi="urn:oecd:ties:dpi:v1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:stf="urn:oecd:ties:dpistf:v1" xmlns:iso="urn:oecd:ties:isodpitypes:v1" targetNamespace="urn:oecd:ties:dpi:v1" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">

<xsd:import namespace="urn:oecd:ties:isodpitypes:v1" schemaLocation="isodpitypes_v1.0.xsd"/>

<xsd:import namespace="urn:oecd:ties:dpistf:v1" schemaLocation="oecddpitypes_v1.0.xsd"/>

<xsd:simpleType name="MessageType_EnumType">

<xsd:annotation>

<xsd:documentation xml:lang="en">Message type defines the type of reporting.</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="DPI">

<xsd:annotation>

<xsd:documentation>This type defines the messages to be exchanged under the OECD Model Rules and [EU Specific] [EU DIR2021/514].</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="DPIMessageTypeIndic_EnumType">

<xsd:annotation>

<xsd:documentation xml:lang="en">The MessageTypeIndic defines the type of message sent.</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="DPI401">

<xsd:annotation>

<xsd:documentation>The message contains new (including additional) information.</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DPI402">

<xsd:annotation>

<xsd:documentation>The message contains corrections for previously sent information.</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DPI403">

<xsd:annotation>

<xsd:documentation>The message advises that there is no data to report.</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="INType_EnumType">

<xsd:annotation>

<xsd:documentation xml:lang="en">The INType defines the type of identification number being sent.</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="LEI">

<xsd:annotation>

<xsd:documentation>Legal Entity Identifier</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="EIN">

<xsd:annotation>

<xsd:documentation>Entity Identification Number</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="IIN">

<xsd:annotation>

<xsd:documentation>Individual Identification Number</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="BRN">

<xsd:annotation>

<xsd:documentation>Business Registration Number</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="Other">

<xsd:annotation>

<xsd:documentation>Other</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="DPIPropertyType_EnumType">

<xsd:annotation>

<xsd:documentation xml:lang="en">Main business activities

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="DPI901">

<xsd:annotation>

<xsd:documentation>Office</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DPI902">

<xsd:annotation>

<xsd:documentation>Hotel room</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DPI903">

<xsd:annotation>

<xsd:documentation>Bed and Breakfast room</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DPI904">

<xsd:annotation>

<xsd:documentation>House</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DPI905">

<xsd:annotation>

<xsd:documentation>Apartment</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DPI906">

<xsd:annotation>

<xsd:documentation>Mobile Home</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DPI907">

<xsd:annotation>

<xsd:documentation>Campground</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DPI908">

<xsd:annotation>

<xsd:documentation>Boat</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DPI909">

<xsd:annotation>

<xsd:documentation>Parking Space</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="DPI910">

<xsd:annotation>

<xsd:documentation>Other</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="Nexus_EnumType">

<xsd:annotation>

<xsd:documentation xml:lang="en">The reason for which the information will be filled to the competent authority of the EU Member State.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="RPONEX1">

<xsd:annotation>

<xsd:documentation>The Reporting Platform Operator is resident for tax purposes in the EU Member State.</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="RPONEX2">

<xsd:annotation>

<xsd:documentation>The Reporting Platform Operator does not have a residence for tax purposes but it is incorporated under the laws of the EU Member State.</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="RPONEX3">

<xsd:annotation>

<xsd:documentation>The Reporting Platform Operator does not have a residence for tax purposes but it has its place of management (including effective management) in the EU Member State.</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="RPONEX4">

<xsd:annotation>

<xsd:documentation>The Reporting Platform Operator does not have a residence for tax purposes but it has a permanent establishment in the EU Member State and it is not a Qualified Non-Union Platform Operator.</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="RPONEX5">

<xsd:annotation>

<xsd:documentation>The Reporting Platform Operator is neither resident for tax purposes, nor incorporated or managed in the EU Member State, nor has a permanent establishment in the EU Member State but it facilitates the carrying out of a Relevant Activity by Reportable Sellers or a Relevant Activity involving the rental of immovable property located in the EU Member State and it is not a Qualified Non-Union Platform Operator.</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType name="NamePerson_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">The user must spread the data about the name of a party over up to six elements. The container element for this will be 'NameFix'. </xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="PrecedingTitle" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation xml:lang="en">His Excellency,Estate of the Late ...</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Title" type="stf:StringMin1Max200_Type" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation xml:lang="en">Greeting title. Example: Mr, Dr, Ms, Herr, etc. Can have multiple titles.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="FirstName">

<xsd:annotation>

<xsd:documentation xml:lang="en">FirstName of the person</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="stf:StringMin1Max200_Type">

<xsd:attribute name="xnlNameType" type="stf:StringMin1Max200_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">Defines the name type of FirstName. Example: Given Name, Forename, First Name, Father's Name, etc. In some countries, FirstName could be a Family Name or a Surname. Use this attribute to define the type for this name.

</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="MiddleName" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation xml:lang="en">Middle name (essential part of the name for many nationalities). Example: Sakthi in "Nivetha Sakthi Shantha". Can have multiple middle names.</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="stf:StringMin1Max200_Type">

<xsd:attribute name="xnlNameType" type="stf:StringMin1Max200_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">Defines the name type of Middle Name. Example: First name, middle name, maiden name, father's name, given name, etc.

</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="NamePrefix" minOccurs="0">

<xsd:annotation>

<xsd:documentation xml:lang="en">de, van, van de, von, etc. Example: Derick de Clarke</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="stf:StringMin1Max200_Type">

<xsd:attribute name="xnlNameType" type="stf:StringMin1Max200_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">Defines the type of name associated with the NamePrefix. For example the type of name is LastName and this prefix is the prefix for this last name.

</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="LastName">

<xsd:annotation>

<xsd:documentation xml:lang="en">Represents the position of the name in a name string. Can be Given Name, Forename, Christian Name, Surname, Family Name, etc. Use the attribute "NameType" to define what type this name is.

In case of a company, this field can be used for the company name.</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="stf:StringMin1Max200_Type">

<xsd:attribute name="xnlNameType" type="stf:StringMin1Max200_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">Defines the name type of LastName. Example: Father's name, Family name, Surname, Mother's Name, etc. In some countries, LastName could be the given name or first name.

</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<xsd:element name="GenerationIdentifier" type="stf:StringMin1Max200_Type" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation xml:lang="en">Jnr, Thr Third, III</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Suffix" type="stf:StringMin1Max200_Type" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation xml:lang="en">Could be compressed initials - PhD, VC, QC</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="GeneralSuffix" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation xml:lang="en">Deceased, Retired ...</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="nameType" type="stf:OECDNameType_EnumType" use="optional">

<xsd:annotation>

<xsd:documentation xml:lang="en">It is possible for STF documents to contain several names for the same party. This attribute is a qualifier to indicate the type of a particular name.</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

</xsd:complexType>

<xsd:complexType name="PersonParty_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">This container brings together all data about a person as a party. Name and address are required components and each can be present more than once to enable as complete a description as possible. Whenever possible one or more identifiers (TIN etc) should be added as well as a residence country code. Additional data that describes and identifies the party can be given. The code for the legal type according to the OECD codelist must be added. The structures of all of the subelements are defined elsewhere in this schema.</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="ResCountryCode" type="iso:CountryCode_Type" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>This repeatable data element describes the residence country code(s) of the individual Seller and must be present in all data records. This should correspond to the jurisdiction of residence identified on the basis of the due diligence requirements of the OECD Model Rules or [EU Specific] [EU DIR2021/514]. Specifically, under the OECD Model Rules, the residence country code of an individual Seller should correspond to the jurisdiction of the Seller’s primary residence.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="TIN" type="dpi:TIN_Type" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>This repeatable data element provides the tax identification number (TIN) used by the tax administration of the jurisdiction of residence of the individual Seller. In case the individual Seller does not have a TIN, the jurisdiction of residence does not issue a TIN or require the collection of the TIN issued to such Seller, or the TIN is not known to the sending Competent Authority, the Unknown attribute (see below) must be set to “true” and the value “NOTIN” should be entered [OECD Specific]. Furthermore, in case more than one TIN are provided, any provided element cannot be flagged as “unknown”.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="VAT" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation xml:lang="en">This data element must be provided when a VAT Identification number is available.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Name" type="dpi:NamePerson_Type" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>This element should contain the name of the person.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Address" type="dpi:Address_Type" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>This data element should contain the address of the person, including the country code of the address as well as the type of the address, indicating the legal character of that address.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Nationality" type="iso:CountryCode_Type" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>The nationality element is not to be provided as part of the DPI schema.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="BirthInfo">

<xsd:annotation>

<xsd:documentation>This data element contains the birth information of an Individual Seller. It is always required to be provided unless such Seller is documented pursuant to a Government Verification Service and is composed of the date and the place of birth.</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element name="BirthDate" type="xsd:date">

<xsd:annotation>

<xsd:documentation>This element provides the date of birth, complying with the following format: YYYY-MM-DD.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="BirthPlace" type="dpi:BirthPlace_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>This element provides information about the place of birth. This element must be filled in at least with the city and the country of birth (either the current jurisdiction identified by 2-characters country code or a former jurisdiction identified by a name).</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="AddressFix_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">Structure of the address for a party broken down into its logical parts, recommended for easy matching. The 'City' element is the only required subelement. All of the subelements are simple text - data type 'string'.

</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="Street" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The street.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="BuildingIdentifier" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The identifier of the building on the street, typically a number.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="SuiteIdentifier" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The identifier of an office or similar part of a building.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="FloorIdentifier" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The identifier of a floor within a building.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="DistrictName" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The name of the district of the address.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="POB" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The post office box.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="PostCode" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The post code of the address, which must be provided if available.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="City" type="stf:StringMin1Max200_Type">

<xsd:annotation>

<xsd:documentation>The city of the address.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="CountrySubentity" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>A geographic area of the country larger than district or city, for example a county, a department, a Land, a canton, etc.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="Address_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">The user has the option to enter the data about the address of a party either as one long field or to spread the data over up to eight elements or even to use both formats. If the user chooses the option to enter the data required in separate elements, the container element for this will be 'AddressFix'. If the user chooses the option to enter the data required in a less structured way in 'AddressFree' all available address details shall be presented as one string of bytes, blank or "/" (slash) or carriage return- line feed used as a delimiter between parts of the address. PLEASE NOTE that the address country code is outside both of these elements. The use of the fixed form is recommended as a rule to allow easy matching. However, the use of the free form is recommended if the sending state cannot reliably identify and distinguish the different parts of the address. The user may want to use both formats e.g. if besides separating the logical parts of the address he also wants to indicate a suitable breakdown into print-lines by delimiters in the free text form. In this case 'AddressFix' has to precede 'AddressFree'.

</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="CountryCode">

<xsd:annotation>

<xsd:documentation>This data element provides the country code associated with the entity’s (or person’s) address.</xsd:documentation>

</xsd:annotation>

<xsd:simpleType>

<xsd:restriction base="iso:CountryCode_Type">

<xsd:minLength value="1"/>

<xsd:maxLength value="2"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:choice>

<xsd:element name="AddressFree" type="stf:StringMin1Max4000_Type">

<xsd:annotation>

<xsd:documentation>This data element allows input of address information in free text. It should only be used in exceptional circumstances when it is impossible to provide the address in the fixed format.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:sequence>

<xsd:element name="AddressFix" type="dpi:AddressFix_Type"/>

<xsd:element name="AddressFree" type="stf:StringMin1Max4000_Type" minOccurs="0">

<xsd:annotation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:choice>

</xsd:sequence>

<xsd:attribute name="legalAddressType" type="stf:OECDLegalAddressType_EnumType" use="optional">

<xsd:annotation>

<xsd:documentation>This is a datatype for an attribute to an address. It serves to indicate the legal character of that address (residential, business etc.).

The possible values are:

—	OECD301= residentialOrBusiness

—	OECD302= residential

—	OECD303= business

—	OECD304= registeredOffice

—	OECD305= unspecified

The address of the Reportable Platform Operator must represent the “Registered Office Address” (OECD304).</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

</xsd:complexType>

<xsd:complexType name="BirthPlace_Type">

<xsd:annotation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="City" type="stf:StringMin1Max200_Type">

<xsd:annotation>

<xsd:documentation>The city of birth.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="CitySubentity" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The city subentity of birth.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="CountryInfo">

<xsd:complexType>

<xsd:choice>

<xsd:element name="CountryCode" type="iso:CountryCode_Type">

<xsd:annotation>

<xsd:documentation>The current jurisdiction of birth.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="FormerCountryName" type="stf:StringMin1Max200_Type">

<xsd:annotation>

<xsd:documentation>The former jurisdiction of birth. The Former Country Name element should be used in case the person was born in a country that has since ceased to exist.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:choice>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="MonAmnt_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">This data type is to be used whenever monetary amounts are to be communicated. Such amounts shall be given in full units, i.e. without decimals. The code for the currency in which the value is expressed has to be taken from the ISO codelist 4217 and added in attribute currCode.

</xsd:documentation>

</xsd:annotation>

<xsd:simpleContent>

<xsd:extension base="xsd:integer">

<xsd:attribute name="currCode" type="iso:currCode_Type" use="required"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

<xsd:complexType name="NameOrganisation_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">Name of organisation</xsd:documentation>

</xsd:annotation>

<xsd:simpleContent>

<xsd:extension base="stf:StringMin1Max200_Type"/>

</xsd:simpleContent>

</xsd:complexType>

<xsd:complexType name="NameReportableSeller_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">Name of Seller</xsd:documentation>

</xsd:annotation>

<xsd:simpleContent>

<xsd:extension base="stf:StringMin1Max200_Type"/>

</xsd:simpleContent>

</xsd:complexType>

<xsd:complexType name="TIN_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">This is the identification number/identification code for the party in question. As the identifier may be not strictly numeric, it is just defined as a string of characters. Attribute 'issuedBy' is required to designate the issuer of the identifier. </xsd:documentation>

</xsd:annotation>

<xsd:simpleContent>

<xsd:extension base="stf:StringMin0Max200_Type">

<xsd:attribute name="issuedBy" type="iso:CountryCode_Type" use="optional">

<xsd:annotation>

<xsd:documentation xml:lang="en">Country code of issuing country, indicating country of Residence (to taxes and other).

It should always be provided, unless the TIN element is flagged as “unknown”.</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

<xsd:attribute name="unknown" type="xsd:boolean" use="optional">

<xsd:annotation>

<xsd:documentation xml:lang="en">This attribute must be provided if the TIN is not available or inexistent. Any value provided for a TIN flagged as unknown will be discarded.</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

<xsd:complexType name="MessageSpec_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">Information in the message header identifies the Tax Administration that is sending the message. It specifies when the message was created, what period (normally a year) the report is for, and the nature of the report (original, corrected, supplemental, etc).</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="SendingEntityIN" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>Although not used for exchanges between Competent Authorities under the DPI MCAA and [EU DIR2021/514], for domestic reporting, this data element can be used in case the schema is mandated for domestic reporting by Reporting Platform Operators to their tax administration. In such instances, it identifies the Reporting Platform Operator sending the message through a domestically-defined identification number.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="TransmittingCountry" type="iso:CountryCode_Type">

<xsd:annotation>

<xsd:documentation>This data element identifies the jurisdiction of the Competent Authority transmitting the DPI message.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="ReceivingCountry" type="iso:CountryCode_Type">

<xsd:annotation>

<xsd:documentation>This data element identifies the jurisdiction of the Competent Authority receiving the DPI message.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="MessageType" type="dpi:MessageType_EnumType">

<xsd:annotation>

<xsd:documentation>This data element specifies the type of message being sent. The only allowable entry for messages exchanged under the OECD Model Rules and [EU Specific] [EU DIR2021/514] in this field is “DPI”.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Warning" type="stf:StringMin1Max4000_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation xml:lang="en">Free text expressing the restrictions for use of the information this message contains and the legal framework under which it is given.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Contact" type="stf:StringMin1Max4000_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation xml:lang="en">All necessary contact information about persons responsible for and involved in the processing of the data transmitted in this message, both legally and technically. Free text as this is not intended for automatic processing.

In international exchanges, this data element contains the contact details of the sending competent authority.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="MessageRefId" type="stf:StringMin1Max170_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">Sender's unique identifier for this message.

The Message RefID must start with the country code of the sending jurisdiction, then the year of the reportable period, then the receiving country code before a unique identifier.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="MessageTypeIndic" type="dpi:DPIMessageTypeIndic_EnumType">

<xsd:annotation>

<xsd:documentation>This data element specifies the type of information that is sent, i.e. whether it is new information or whether the message seeks to correct or delete previously sent information.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="ReportingPeriod" type="xsd:date">

<xsd:annotation>

<xsd:documentation xml:lang="en">The reporting year for which information is transmitted in documents of the current message. This is in yyyy-MM-DD format, on the basis of the calendar year in which the relevant Reportable Period under the OECD Model Rules or [EU Specific] [EU DIR2021/514] ended.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Timestamp" type="xsd:dateTime">

<xsd:annotation>

<xsd:documentation>This data element identifies the date and time when the message was compiled. It is anticipated that this element will be automatically populated by the host system. The format for use is yyyy-MM-DD’T’hh:mm:ss.nnn. Fractions of seconds may be used (in such a case the milli-seconds will be provided on 3 digits, see “.nnn” in the format above). </xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="OrganisationIN_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">This is the identification number/identification code for the Entity in question. As the identifier may be not strictly numeric, it is just defined as a string of characters. Attribute 'issuedBy' is required to designate the issuer of the identifier. Attribute 'INType' defines the type of identification number. </xsd:documentation>

</xsd:annotation>

<xsd:simpleContent>

<xsd:extension base="stf:StringMin1Max200_Type">

<xsd:attribute name="issuedBy" type="iso:CountryCode_Type" use="optional">

<xsd:annotation>

<xsd:documentation xml:lang="en">Country code of issuing country, indicating country of Residence (to taxes and other)</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

<xsd:attribute name="INType" type="dpi:INType_EnumType" use="required">

<xsd:annotation>

<xsd:documentation xml:lang="en">This attribute defines the type of identification number being sent among the following:

—	[EU Specific]: IIN for the reporting of an individual identification number;

—	LEI for the reporting of a legal entity identifier;

—	EIN for the reporting of an entity identification number;

—	BRN for the reporting of a business registration number; or

—

Other.

</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

<xsd:complexType name="OrganisationParty_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">

This container brings together all data about an organisation as a party. Name and address are required components and each can be present more than once to enable as complete a description as possible. Whenever possible one or more identifiers (TIN etc) should be added as well as a residence country code. Additional data that describes and identifies the party can be given . The code for the legal type according to the OECD codelist must be added. The structures of all of the subelements are defined elsewhere in this schema.</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="ResCountryCode" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>This repeatable data element describes the residence country code(s) of the entity.

In case of an Entity Seller this should always be present and should correspond to the jurisdiction of residence identified on the basis of the due diligence requirements of the OECD Model Rules or [EU Specific] [EU DIR2021/514]. Specifically, under the OECD Model Rules, the residence country code of an Entity Seller should correspond to the jurisdiction in which its registered office is located.

In case of a Reporting Platform Operator, the residence country code should correspond to the jurisdiction where the Reporting Platform Operator is resident for tax purposes or, where it does not have a residence for tax purposes, either the jurisdiction it is incorporated under or the jurisdiction that it has its place of management (including effective management) in, [EU Specific] or the Member State where it has a permanent establishment in.

[EU Specific]: Reporting Platform Operator: This element is optional.</xsd:documentation>

</xsd:annotation>

<xsd:simpleType>

<xsd:restriction base="iso:CountryCode_Type"/>

</xsd:simpleType>

</xsd:element>

<xsd:element name="TIN" type="dpi:TIN_Type" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>This repeatable data element provides the tax identification number (TIN) used by the tax administration of the jurisdiction of residence of the entity. In case the entity does not have a TIN, or the TIN is not known to the sending Competent Authority, the value “NOTIN” should be entered [OECD Specific] and the Unknown attribute (see below) must be set to “true”. Furthermore, in case more than one TIN are provided, any provided element cannot be flagged as “unknown”.

[EU Specific]: This element must be present for both Reporting Platform Operator and Entity Seller.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="IN" type="dpi:OrganisationIN_Type" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation xml:lang="en">This data element can be provided (and repeated) if there are other INs available, such as a company registration number or an Entity Identification Number (EIN).

[EU Specific]:

—	Reporting Platform Operator: Where relevant, the individual identification number (IIN) shall be provided

—	Entity Seller: The business registration number (BRN) must be provided</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="VAT" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation xml:lang="en">This data element can be provided when a VAT Identification number is available.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Name" type="dpi:NameOrganisation_Type" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>This element should contain the legal name of the entity, including the domestic designation for the legal form, as indicated in its articles of incorporation or any similar document.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="PlatformBusinessName" type="stf:StringMin1Max200_Type" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>The repeatable Platform Business Name element identifies the business name(s) of the other Reporting Platform(s) in respect of which the Reporting Platform Operator is reporting.

This element must not be used for the Entity Sellers.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Address" type="dpi:Address_Type" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>This data element should contain the address of the entity, including the country code of the address as well as the type of the address, indicating the legal character of that address.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Nexus" type="dpi:Nexus_EnumType" minOccurs="0">

<xsd:annotation>

<xsd:documentation>[EU Specific] This data element provides the reason for which the information will be reported to the competent authority of the EU Member State.

This data element must not be used for Entity Seller.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="AssumedReporting" type="xsd:boolean" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The Assumed Reporting element identifies whether the Reporting Platform Operator is not reporting information on Reportable Sellers, because another Reporting Platform Operator has assumed the reporting.

When “AssumedReporting” is set to “true”, it means that another Reporting Platform Operator reported for the Reporting Platform Operator. Otherwise, this element must be set to “false”.

This element is mandatory for Reporting Platform Operator and must not be provided for an Entity Seller.

By way of an example, Platform Z is operated by two Platform Operators: Platform Operator 1 (resident in jurisdiction 1) and Platform Operator 2 (resident in jurisdiction 2). In satisfying the reporting requirements, Platform Operator 1 has obtained assurances from Platform Operator 2 that it will fulfil the reporting obligations with respect to all of the Reportable Sellers of Platform Operator 1 in jurisdiction 2.

Platform Operator 1 will therefore provide its identification information and set the AssumedReporting element to “true” to notify its jurisdiction residence (jurisdiction 1) that it has relied on another Platform Operator to fulfil the reporting requirements. Platform Operator 1 will also use the AssumingPlatformOperator element (discussed further below) to report to its jurisdiction (jurisdiction 1) identification information on Platform Operator 2, assuming the reporting obligation in the name of Platform Operator 1. Platform Operator 1 will not provide ReportableSeller element.

At the same time, Platform Operator 2 will use the AssumedPlatformOperator element (discussed further below) to report to its jurisdiction of residence (jurisdiction 2) identification information on Platform Operator 1, for which it has assumed reporting obligations, and complete the Platform Operator element for itself.

[EU Specific] This element is optional for the purposes of [EU DIR2021/514].

</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="CorrectablePlatformOperator_Type">

<xsd:annotation>

<xsd:documentation>This correctable extends the information about the Reporting Platform Operator by considering the DocSpec element used to identify the particular report within the DPI message being transmitted.</xsd:documentation>

</xsd:annotation>

<xsd:complexContent>

<xsd:extension base="dpi:OrganisationParty_Type">

<xsd:sequence>

<xsd:element name="DocSpec" type="stf:DocSpec_Type">

<xsd:annotation>

<xsd:documentation>DocSpec identifies the particular report within the DPI message being transmitted. It permits the identification of reports requiring correction.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="CorrectableReportableSeller_Type">

<xsd:annotation>

<xsd:documentation>This correctable extends the information about the Reportable Seller by considering the DocSpec element used to identify the particular report within the DPI message being transmitted.</xsd:documentation>

</xsd:annotation>

<xsd:complexContent>

<xsd:extension base="dpi:ReportableSeller_Type">

<xsd:sequence>

<xsd:element name="DocSpec" type="stf:DocSpec_Type">

<xsd:annotation>

<xsd:documentation>DocSpec identifies the particular report within the DPI message being transmitted. It permits the identification of reports requiring correction.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="CorrectableAdditionalInfo_Type">

<xsd:sequence>

<xsd:element name="DocSpec" type="stf:DocSpec_Type"/>

<xsd:element name="OtherInfo" type="stf:StringMin1Max4000WithLang_Type" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>Please include any further brief information or explanation you consider necessary or that would facilitate the understanding of the compulsory information provided in the country-by-country report. </xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="ResCountryCode" type="iso:CountryCode_Type" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="AccountHolder_Type">

<xsd:sequence>

<xsd:choice>

<xsd:element name="Individual" type="dpi:NameReportableSeller_Type"/>

<xsd:sequence>

<xsd:element name="Organisation" type="dpi:OrganisationParty_Type"/>

<xsd:element name="AcctHolderType"/>

</xsd:sequence>

</xsd:choice>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="FinancialIdentifier_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">The Financial Identifier is an optional (mandatory) element that reflects the Financial Account Identifier which, under the OECD Model Rules or [EU Specific] [EU DIR2021/514], is the unique identifying number or reference available to the Reporting Platform Operator of the bank account or other payment account to which the Consideration is paid or credited. Under subparagraphs B(2)(c) and B(3)(c) of Section III of the OECD Model Rules or [EU Specific] subparagraphs B(2)(b) and B(3)(b) of Section III of [EU DIR2021/514], the Financial Identifier must be reported and exchanged provided that it is available to the Reporting Platform Operator and that the jurisdiction of the Reportable Seller’s residence has indicated that it wishes to receive such Financial Identifiers for taxpayer matching purposes.</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="Identifier" type="dpi:Identifier_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">Entity Identification Number, which contains the Financial Account Identifier pertaining to the Reportable Seller should be reflected. Financial Account Identifiers can include the IBAN number, sort code and account number and any other payment account identifier that the Reporting Platform Operator used for transferring the Consideration in respect to a Reportable Seller.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="AccountHolderName" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The Account Holder Name field is an optional (mandatory) element which, reflecting subparagraphs B(2)(d) and B(3)(d) of Section III of the OECD Model Rules or [EU Specific] subparagraphs B(2)(c) and B(3)(c) of Section III of [EU DIR2021/514], contains the name of the holder of the financial account to which the Consideration is paid or credited, where different from the name of the Reportable Seller and to the extent available to the Reporting Platform Operator.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="OtherInfo" type="stf:StringMin1Max400_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>Reflecting subparagraphs B(2)(d) and B(3)(d) of Section III of the OECD Model Rules or [EU Specific] subparagraphs B(2)(c) and B(3)(c) of Section III of [EU DIR2021/514], the OtherInfo field contains any other identifying information available to the Reporting Platform Operator with respect to that account holder.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="Identifier_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">The Identifier field is a required element which contains the Financial Account Identifier pertaining to the Reportable Seller should be reflected. Financial Account Identifiers can include the IBAN number, sort code and account number and any other payment account identifier that the Reporting Platform Operator used for transferring the Consideration in respect to a Reportable Seller.</xsd:documentation>

</xsd:annotation>

<xsd:simpleContent>

<xsd:extension base="stf:StringMin1Max200_Type">

<xsd:attribute name="AccountNumberType" type="stf:StringMin1Max200_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">This attribute describes the type of account number being sent.</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

<xsd:complexType name="OtherActivities_Type">

<xsd:sequence>

<xsd:element name="Consideration" type="dpi:ConsiderationType">

<xsd:annotation>

<xsd:documentation>The Consideration element contains information on the Consideration received by a Reportable Seller in relation to the Relevant Activities provided. It is further split into four elements, representing the quarters during which the Consideration was paid or credited to a Reportable Seller. In this respect, Consideration is considered to be paid or credited to a Reportable Seller when it is paid or credited to an account specified by the Reportable Seller (as stated in paragraph 32 of the Commentary to Section I of the OECD Model Rules).</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="NumberOfActivities" type="dpi:NumberOfActivities_Type">

<xsd:annotation>

<xsd:documentation>The Number of Activities element specified the number of Relevant Activities that a Reportable Seller has provided. It is further split into four elements. These elements represent the four quarters in respect of which reporting of the number of Relevant Activities in respect of which Consideration was paid or credited to the Reportable Seller is required. As such, that the numbers of activities are reported on the basis of the date of payment or credit of the Consideration.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Fees" type="dpi:FeesType">

<xsd:annotation>

<xsd:documentation>The Fees element is further split into four elements, representing the quarters in respect of which reporting takes place. </xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Taxes" type="dpi:TaxesType">

<xsd:annotation>

<xsd:documentation>The Taxes element is further split into four elements, representing the quarters in respect of which reporting takes place. </xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="NumberOfActivities_Type">

<xsd:annotation>

<xsd:documentation>The Number of Services element is further split into four elements, representing the quarters in respect of which reporting takes place. </xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="NumbQ1" type="xsd:integer"/>

<xsd:element name="NumbQ2" type="xsd:integer"/>

<xsd:element name="NumbQ3" type="xsd:integer"/>

<xsd:element name="NumbQ4" type="xsd:integer"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="TaxesType">

<xsd:annotation>

<xsd:documentation>The Taxes element is further split into four elements, representing the quarters in respect of which reporting takes place.

Each quarter element is further comprised of the MonAmnt_Type, used to communicate taxes withheld in respect of Sellers. Such amounts shall be given in full units, i.e. without decimals. The code for the currency, in which the value is expressed has to be taken from the ISO code list 4217 and added in attribute currCode.</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="TaxQ1" type="dpi:MonAmnt_Type"/>

<xsd:element name="TaxQ2" type="dpi:MonAmnt_Type"/>

<xsd:element name="TaxQ3" type="dpi:MonAmnt_Type"/>

<xsd:element name="TaxQ4" type="dpi:MonAmnt_Type"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="FeesType">

<xsd:sequence>

<xsd:annotation>

<xsd:documentation>The Fees element is further split into four elements, representing the quarters in respect of which reporting takes place.

Each quarter element is further comprised of the MonAmnt_Type, used to communicate the fees withheld in respect of Sellers. Such amounts shall be given in full units, i.e. without decimals. The code for the currency, in which the value is expressed has to be taken from the ISO code list 4217 and added in attribute currCode.</xsd:documentation>

</xsd:annotation>

<xsd:element name="FeesQ1" type="dpi:MonAmnt_Type"/>

<xsd:element name="FeesQ2" type="dpi:MonAmnt_Type"/>

<xsd:element name="FeesQ3" type="dpi:MonAmnt_Type"/>

<xsd:element name="FeesQ4" type="dpi:MonAmnt_Type"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="ConsiderationType">

<xsd:sequence>

<xsd:annotation>

<xsd:documentation>The Consideration element is further split into four elements, representing the quarters in respect of which reporting takes place.

Each quarter element is further comprised of the MonAmnt_Type, used to communicate the monetary amounts earned by Sellers. Such amounts shall be given in full units, i.e. without decimals. The code for the currency, in which the value is expressed has to be taken from the ISO code list 4217 and added in attribute currCode.</xsd:documentation>

</xsd:annotation>

<xsd:element name="ConsQ1" type="dpi:MonAmnt_Type"/>

<xsd:element name="ConsQ2" type="dpi:MonAmnt_Type"/>

<xsd:element name="ConsQ3" type="dpi:MonAmnt_Type"/>

<xsd:element name="ConsQ4" type="dpi:MonAmnt_Type"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="PropertyListingType">

<xsd:sequence>

<xsd:element name="Address" type="dpi:Address_Type">

<xsd:annotation>

<xsd:documentation>The Address element is further comprised of the elements as described above under the Address Type.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="LandRegistrationNumber" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The Land Registration Number element contains the land registration number, which under subparagraph B(3)(f) of Section III of the OECD Model Rules or [EU Specific] subparagraph B(3)(e) of Section III of [EU DIR2021/514], is reportable if available to the Reporting Platform Operator. For these purposes, the land registration number includes functional equivalents, such as a cadastral number.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Consideration" type="dpi:ConsiderationType">

<xsd:annotation>

For Relevant Activities involving the rental of immovable property, the Consideration information must be provided separately with respect to each Property Listing.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="NumberOfActivities" type="dpi:NumberOfActivities_Type">

<xsd:annotation>

For Relevant Activities involving the rental of immovable property, the number of activities must be provided separately with respect to each Property Listing.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Fees" type="dpi:FeesType">

<xsd:annotation>

<xsd:documentation>The Fees element specified the fees and commissions that a Reporting Platform Operator has withheld in respect of a Reportable Seller. It is split into four elements, representing the quarters in respect of which the reporting of fees or commissions withheld or charged by the Reporting Platform Operator is required under subparagraphs B(2)(g) and B(3)(h) of Section III of the OECD Model Rules or [EU Specific] subparagraphs B(2)(f) and B(3)(g) of Section III of [EU DIR2021/514]. </xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Taxes" type="dpi:TaxesType">

<xsd:annotation>

<xsd:documentation>The Taxes element specifies the taxes that a Reporting Platform Operator has withheld in respect of a Reportable Seller. It is further split into four elements, representing the quarters in respect of which reporting of taxes withheld by the Reporting Platform Operator is required under subparagraphs B(2)(g) and B(3)(h) of Section III of the OECD Model Rules or [EU Specific] subparagraphs B(2)(f) and B(3)(g) of Section III of [EU DIR2021/514].</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="PropertyType" type="dpi:DPIPropertyType_EnumType" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The Property Type element specifies the type of property rented. DPI901 to DPI910.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="OtherPropertyType" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>This element describes the type of property in case “DPI910” is selected as Property Type. This element cannot be used in case another Property Type is selected.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="RentedDays" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The Rented Days element contains the number of days that the Property Listing was rented during the Reportable Period.

4 numbers max. Set the type as simple</xsd:documentation>

</xsd:annotation>

<xsd:simpleType>

<xsd:restriction base="xsd:integer">

<xsd:totalDigits value="4"/>

<xsd:minInclusive value="1"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="GVSType">

<xsd:annotation>

<xsd:documentation>The GVS element reflects the Government Verification Service (GVS) due diligence procedures and is composed of the Name GVS, Jurisdiction GVS, Reference GVS and Other TIN GVS elements, which contain the information items subject to reporting (and exchange) in respect of a Reportable Seller that has been identified on the basis of a Government Verification Service, as well as the Financial Identifier element.

[EU Specific] At the time of publication, the collection and exchange of GVS information is not a legal requirement under [EU DIR2021/514].</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="NameGVS" type="stf:StringMin1Max200_Type">

<xsd:annotation>

<xsd:documentation>The Name GVS element contains the legal name of the Reportable Seller.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="JurisdictionGVS">

<xsd:annotation>

<xsd:documentation>The Jurisdiction GVS element identifies the jurisdiction whose Government Verification Service was relied upon by the Reporting Platform Operator in respect of the Reportable Seller.

It uses the 2-character alphabetic country code and country name list based on the ISO 3166-1 Alpha 2 standard.</xsd:documentation>

</xsd:annotation>

<xsd:simpleType>

<xsd:restriction base="iso:CountryCode_Type"/>

</xsd:simpleType>

</xsd:element>

<xsd:element name="ReferenceGVS" type="stf:StringMin1Max200_Type">

<xsd:annotation>

<xsd:documentation>The Reference GVS element contains the unique reference number or code provided by the jurisdiction whose GVS was used, allowing that jurisdiction to match the Reportable Seller to a taxpayer within its database.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="OtherTINGVS" type="stf:StringMin1Max200_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>Reflecting subparagraph B(2)(b) and B(3)(b) of Section III of the OECD Model Rules, the Other TIN GVS element contains any TIN available to the Reporting Platform Operator, including the jurisdiction of issuance.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="FinancialIdentifier" type="dpi:FinancialIdentifier_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The Financial Identifier is an optional (mandatory) element that reflects the Financial Account Identifier which is the unique identifying number or reference available to the Reporting Platform Operator of the bank account or other payment account to which the Consideration is paid or credited.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="ReportableSeller_Type">

<xsd:sequence>

<xsd:element name="Identity">

<xsd:annotation>

<xsd:documentation>The Identity element is further comprised of the EntitySeller and IndividualSeller elements.</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:choice>

<xsd:element name="EntitySeller">

<xsd:annotation>

<xsd:documentation>The Entity Seller element is further comprised of the Standard and GVS elements.</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:choice>

<xsd:element name="Standard">

<xsd:annotation>

<xsd:documentation>The Standard element reflects the standard due diligence procedures and is further comprised of the EntSellerID (that follows the OrganisationParty Type) and FinancialIdentifier elements. Platform Operators by default would use the standard due diligence procedures, but can also rely on the GVS procedure where it has been made available by the Reportable Jurisdiction .

The Standard element should be completed in case the Reporting Platform Operator has relied on the standard due diligence procedures of the OECD Model Rules or [EU Specific] [EU DIR2021/514] to identify and document the Entity Seller.</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element name="EntSellerID" type="dpi:OrganisationParty_Type">

<xsd:annotation>

<xsd:documentation>The EntSellerID element identifies the Entity Seller and follows the OrganisationParty_Type.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="FinancialIdentifier" type="dpi:FinancialIdentifier_Type" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>The Financial Identifier is an optional (mandatory) element that reflects the Financial Account Identifier which, under the OECD Model Rules or [EU Specific] [EU DIR2021/514], is the unique identifying number or reference available to the Reporting Platform Operator of the bank account or other payment account to which the Consideration is paid or credited. Under subparagraphs B(2)(c) and B(3)(c) of Section III of the OECD Model Rules or [EU Specific] subparagraphs B(2)(b) and B(3)(b) of Section III of [EU DIR2021/514], the Financial Identifier must be reported and exchanged provided that it is available to the Reporting Platform Operator and that the jurisdiction of the Reportable Seller’s residence has indicated that it wishes to receive such Financial Identifiers for taxpayer matching purposes.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="PermanentEstablishments" type="dpi:PermanentEstablishments_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>[EU Specific] This data element provides information on any permanent establishment through which Relevant Activities are carried out by the Entity Seller in the Union, indicating each respective EU Member State where such a permanent establishment is located.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="GVS" type="dpi:GVSType">

<xsd:annotation>

<xsd:documentation>The GVS element should be completed in case the Reporting Platform Operator has relied on an approved Government Verification Service in order to identify and document the Entity Seller.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:choice>

</xsd:complexType>

</xsd:element>

<xsd:element name="IndividualSeller">

<xsd:complexType>

<xsd:choice>

<xsd:element name="Standard">

<xsd:annotation>

<xsd:documentation>The Standard element reflects the standard due diligence procedures and is further comprised of the IndSellerID element (which follows the PersonParty Type) and the Financial Identifier element. Platform Operators by default would use the standard due diligence procedures, but can also rely on the GVS procedure where it has been made available by the Reportable Jurisdiction .

The PersonParty_Type, as enumerated in Section III of the OECD Model Rules or [EU Specific] [EU DIR2021/514], defines the information to be included in relation to an individual where the standard due diligence procedures are followed.</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element name="IndSellerID" type="dpi:PersonParty_Type">

<xsd:annotation>

<xsd:documentation>The IndSellerID element identifies the individual Seller and follows the PersonParty_Type</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="FinancialIdentifier" type="dpi:FinancialIdentifier_Type" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>The Financial Identifier is an optional (mandatory) and repeatable element that reflects the Financial Account Identifier which, under the OECD Model Rules or [EU Specific] [EU DIR2021/514], is the unique identifying number or reference available to the Reporting Platform Operator of the bank account or other payment account to which the Consideration is paid or credited. Under subparagraphs B(2)(c) and B(3)(c) of Section III of the OECD Model Rules or [EU Specific] subparagraphs B(2)(b) and B(3)(b) of Section III of [EU DIR2021/514], the Financial Identifier must be reported and exchanged provided that it is available to the Reporting Platform Operator and that the jurisdiction of the Reportable Seller’s residence has indicated that it wishes to receive such Financial Identifiers for taxpayer matching purposes.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="GVS" type="dpi:GVSType">

<xsd:annotation>

</xsd:annotation>

</xsd:element>

</xsd:choice>

</xsd:complexType>

</xsd:element>

</xsd:choice>

</xsd:complexType>

</xsd:element>

<xsd:element name="RelevantActivities">

<xsd:annotation>

<xsd:documentation>The Relevant Activities element includes information on the Relevant Activities provided by Reportable Sellers and the Consideration derived therefrom. The element is comprised of the Immovable Property, Personal Services, sale of Goods and Transportation Rental elements, reflecting the nature of the activities provided by the Reportable Seller. Under the OECD Model Rules and [EU DIR2021/514], information in respect of the Immovable Property and Personal Services elements must be provided. Under the OECD Extended Scope and [EU DIR2021/514], information in respect of the sale of Goods and Transportation Rental elements must also be provided.</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element name="ImmovableProperty" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The Immovable Property element contains information on Relevant Activities provided by a Reportable Seller in relation to the rental of immovable property. It comprises the repeatable Property Listing element.</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element name="PropertyListing" type="dpi:PropertyListingType" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>The Property Listing element is comprised of the Address, Land Registration Number, Consideration, Number of Activities, Fees, Taxes, Property Type and Rented days elements.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="PersonalServices" type="dpi:OtherActivities_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The Personal Services element contains information on Relevant Activities involving time- or task-based work performed by one or more individuals, acting either independently or on behalf of an Entity, and which is carried out at the request of a user, either online or physically offline after having been facilitated via Platform.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="SaleOfGoods" type="dpi:OtherActivities_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The sale of Goods element specifies the Relevant Activities provided by a Reportable Seller with respect to sale of goods.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="TransportationRental" type="dpi:OtherActivities_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>The Transportation Rental element specifies the Relevant Activities provided by a Reportable Seller with respect to the rental of any mode of transport.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="PermanentEstablishments_Type">

<xsd:sequence>

<xsd:annotation>

<xsd:documentation>The repeatable Permanent Establishment element identifies an EU Member State where a permanent establishment through which Relevant Activities are carried out by the Entity Seller in the Union is located.</xsd:documentation>

</xsd:annotation>

<xsd:element name="PermanentEstablishment" type="iso:MSCountryCode_Type" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="OtherPlatformOperators_Type">

<xsd:choice>

<xsd:sequence>

<xsd:element name="AssumingPlatformOperator" type="dpi:CorrectableOtherRPO_Type">

<xsd:annotation>

<xsd:documentation>This element provides information about the Platform Operator assuming the reporting in the name of the Reporting Platform Operator, as identified in the Platform Operator element.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

<xsd:sequence>

<xsd:element name="AssumedPlatformOperator" type="dpi:CorrectableOtherRPO_Type" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>This repeatable element provides information about each Platform Operator for which the Reporting Platform Operator, as identified in the Platform Operator element, assumes the reporting.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:choice>

</xsd:complexType>

<xsd:complexType name="OtherRPO_Type">

<xsd:sequence>

<xsd:annotation>

<xsd:documentation>This element provides information about the assuming or assumed Platform Operator.</xsd:documentation>

</xsd:annotation>

<xsd:element name="ResCountryCode" type="iso:CountryCode_Type" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>This repeatable data element describes the residence country code(s) of the Platform Operator assuming the reporting or the residence country code(s) of each Platform Operator for which the Reporting Platform Operator assumes the reporting. As with the residence country code(s) of the Reporting Platform Operator, the residence country code of this Platform Operator should correspond to the jurisdiction where the Platform Operator is resident for tax purposes or, where it does not have a residence for tax purposes, either the jurisdiction it is incorporated under or the jurisdiction that it has its place of management (including effective management) in, [EU Specific] or the Member State where it has a permanent establishment in.

[EU Specific] This element is optional for the purposes of [EU DIR2021/514].

</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="TIN" type="dpi:TIN_Type" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>This data element provides the tax identification number (TIN) used by the tax administration of the jurisdiction of residence of the entity. In case the entity does not have a TIN, or the TIN is not known to the sending Competent Authority, the Unknown attribute (see below) must be set to “true”. Furthermore, in case more than one TIN are provided, any provided element cannot be flagged as “unknown”.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Name" type="dpi:NameOrganisation_Type">

<xsd:annotation>

</xsd:annotation>

</xsd:element>

<xsd:element name="Address" type="dpi:Address_Type">

<xsd:annotation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="CorrectableOtherRPO_Type">

<xsd:complexContent>

<xsd:extension base="dpi:OtherRPO_Type">

<xsd:sequence>

<xsd:element name="DocSpec" type="stf:DocSpec_Type">

<xsd:annotation>

<xsd:documentation>DocSpec identifies the particular report within the DPI message being transmitted. It permits the identification of reports requiring correction (for further guidance see the Corrections section below).</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="DPIBody_Type">

<xsd:sequence>

<xsd:annotation>

<xsd:documentation>The DPI Body element contains the information on the Reporting Platform Operator, as well as on the Relevant Services performed by Reportable Sellers that give rise to the exchange.</xsd:documentation>

</xsd:annotation>

<xsd:element name="PlatformOperator" type="dpi:CorrectablePlatformOperator_Type">

<xsd:annotation>

<xsd:documentation>The Platform Operator element identifies the Reporting Platform Operator and follows the Organisation Party type (see OrganisationParty_Type).</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="OtherPlatformOperators" type="dpi:OtherPlatformOperators_Type" minOccurs="0">

<xsd:annotation>

<xsd:documentation>This other Platform Operators element identifies either:

—	The Platform Operator assuming the reporting in the name of the Reporting Platform Operator, as identified in the Platform Operator element;

—	Each Platform Operator for which the Reporting Platform Operator, as identified in the Platform Operator element, assumes the reporting.

[OECD Specific] This element must be provided, if available.

[EU Specific] This element is optional for the purposes of [EU DIR2021/514].

</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="ReportableSeller" type="dpi:CorrectableReportableSeller_Type" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation>This element contains the identification information on each Reportable Seller, as well as information on the Relevant Services provided by such Reportable Seller and the Consideration derived therefrom.

In case of Nil Reporting, i.e. when MessageTypeIndic is set to “DPI403”, no Reportable Seller must be provided.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:element name="DPI_OECD">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="MessageSpec" type="dpi:MessageSpec_Type">

<xsd:annotation>

<xsd:documentation>The information in the message header identifies the tax administration that is sending the DPI message. It specifies when the message was created, what reporting period the report is for, and the nature of the report (original, supplemental, etc.).</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="DPIBody" type="dpi:DPIBody_Type" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="version" type="stf:StringMin1Max10_Type">

<xsd:annotation>

<xsd:documentation xml:lang="en">The DPI Version.</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

</xsd:complexType>

</xsd:element>

</xsd:schema>

»;

«Anexo XV

Lista referida no artigo 2.o-D

Os dados estatísticos necessários para a troca de informações obrigatória prevista no artigo 8.o-AC, n.o 2, da Diretiva 2011/16/UE, nos termos do artigo 23.o, n.o 4, da referida diretiva devem abranger as seguintes informações:

—	Para cada mensagem, estatísticas sobre o número total de comunicações recebidas dos operadores de plataformas reportantes para a troca automática de informações obrigatória,

—	Para cada mensagem, estatísticas sobre o número total de comunicações recebidas de cada Estado-Membro,

—

Para cada vendedor sujeito a comunicação, estatísticas sobre o tipo de vendedor sujeito a comunicação, número de identificação do contribuinte ou equivalente funcional, Estado-Membro de residência do vendedor sujeito a comunicação e motivo da troca de informações; Estado-Membro de residência do vendedor sujeito a comunicação e/ou Estado-Membro em que se situa o bem imóvel,

—	Para cada operador de plataforma reportante, estatísticas sobre o tipo de atividade relevante e a tomada em consideração, bem como o tipo de propriedade anunciada.

»;

«Anexo XVI

Modelo referido no artigo 2.o-F, n.o 1

O formulário a utilizar para a comunicação de informações sobre operadores de plataformas excluídos nos termos do artigo 8.o-AC, n.o 6, da Diretiva 2011/16/UE e para a comunicação de informações sobre operadores de plataformas estrangeiros nos termos do anexo V, secção IV, ponto F, n.os 2 e 4, da Diretiva 2011/16/UE deve incluir os seguintes campos:

(a)	Nome do operador de plataforma excluído;

(b)	Endereço postal do operador de plataforma excluído;

(c)	Endereço eletrónico, incluindo sítios Web do operador de plataforma excluído;

(d)	Qualquer NIF emitido ao operador de plataforma excluído, se disponíveis;

(e)	Estado-Membro onde foi efetuada a demonstração realizada em conformidade com o anexo V, secção I, ponto A, n.o 3, da Diretiva 2011/16/UE; e

(f)	Exercício fiscal a partir do qual foi concedido o estatuto de operador de plataforma excluído.

Formato do número de identificação individual dos operadores de plataforma estrangeiros

O número de identificação individual respeita o seguinte formato de 12 dígitos, CCAAAAXXXXXX, em que: CC representa o código ISO do país do Estado-Membro que emite o número de identificação individual; AAAA representa o ano em que o operador de plataforma estrangeiro se regista no Estado-Membro de registo único; e XXXXXX representa uma sequência única de carateres composta por letras e/ou números.

Período de conservação de determinadas informações eliminadas ou excluídas do registo central

Se o registo de um operador de plataforma reportante, na aceção do anexo V, secção I, ponto A, n.o 4, alínea b), da Diretiva 2011/16/UE, com a redação que lhe foi dada pela Diretiva (UE) 2021/514, for revogado em conformidade com o anexo V, secção IV, ponto F, n.o 7, da Diretiva 2011/16/UE, o Estado-Membro de registo único deve eliminar o operador de plataforma reportante do registo central. O registo central não pode conservar as informações eliminadas a que se refere o anexo V, secção IV, ponto F, n.os 2 e 4, da Diretiva 2011/16/UE por um período superior a 12 meses a contar da data de eliminação.

As informações inscritas no registo central dos operadores de plataforma excluídos serão excluídas se um operador de plataforma excluído na aceção do anexo V, secção I, ponto A, n.o 3, da Diretiva 2011/16/UE, com a redação que lhe foi dada pela Diretiva (UE) 2021/514, não demonstrar, previamente e numa base anual, a contento da autoridade competente do Estado-Membro ao qual o operador de plataforma teria de comunicar, em conformidade com as regras estabelecidas no anexo V, secção III, ponto A, n.os 1 a 3, da Diretiva 2011/16/UE, que a totalidade do modelo de negócio da plataforma não possui vendedores sujeitos a comunicação. O registo central não pode conservar as informações excluídas referidas no anexo XVI alíneas a) a f), do presente regulamento por um período superior a 12 meses a contar da data de exclusão das informações inscritas no registo.

(1) Contudo, apenas os elementos e atributos efetivamente aplicáveis a um determinado caso após a execução das regras em matéria diligência devida e comunicação previstas no anexo V, secções II e III, da Diretiva 2011/16/UE do Conselho, com a redação que lhe foi dada pela Diretiva (UE) 2021/514 do Conselho, devem constar do formato eletrónico utilizado nesse caso.

		ISSN 1977-0774
Jornal Oficial da União Europeia		L 231

Edição em língua portuguesa	Legislação	65.° ano 6 de setembro de 2022

Índice		II Atos não legislativos	Página
		REGULAMENTOS
	*	Regulamento de Execução (UE) 2022/1463 da Comissão, de 5 de agosto de 2022, que estabelece especificações técnicas e operacionais do sistema técnico para o intercâmbio automatizado transfronteiriço de elementos de prova e a aplicação do princípio da declaração única, em conformidade com o Regulamento (UE) 2018/1724 do Parlamento Europeu e do Conselho ( 1 )	1
	*	Regulamento de Execução (UE) 2022/1464 da Comissão, de 2 de setembro de 2022, que altera o Regulamento (CE) n.o 1210/2003 do Conselho relativo a determinadas restrições específicas aplicáveis às relações económicas e financeiras com o Iraque	22
	*	Regulamento (UE) 2022/1465 da Comissão, de 5 de setembro de 2022, que altera o anexo I do Regulamento (CE) n.o 1334/2008 do Parlamento Europeu e do Conselho no que diz respeito a determinadas substâncias aromatizantes ( 1 )	24
	*	Regulamento (UE) 2022/1466 da Comissão, de 5 de setembro de 2022, que altera o anexo I do Regulamento (CE) n.o 1334/2008 do Parlamento Europeu e do Conselho no que diz respeito à supressão de determinadas substâncias aromatizantes da lista da União ( 1 )	32
	*	Regulamento de Execução (UE) 2022/1467 da Comissão, de 5 de setembro de 2022, que altera o Regulamento de Execução (UE) 2015/2378 no respeitante aos formulários normalizados e aos formatos eletrónicos a utilizar em relação à Diretiva 2011/16/UE do Conselho e à lista de dados estatísticos a fornecer pelos Estados-Membros para efeitos de avaliação dessa diretiva	36
	*	Regulamento de Execução (UE) 2022/1468 da Comissão, de 5 de setembro de 2022, que altera o Regulamento de Execução (UE) n.o 540/2011 no que se refere às condições de aprovação da substância ativa penflufene e que revoga o Regulamento de Execução (UE) 2018/185 ( 1 )	101
	*	Regulamento de Execução (UE) 2022/1469 da Comissão, de 5 de setembro de 2022, relativo à autorização do sulfato de L-lisina produzido por Escherichia coli CGMCC 7.398 como aditivo em alimentos para todas as espécies animais ( 1 )	105
	*	Regulamento de Execução (UE) 2022/1470 da Comissão, de 5 de setembro de 2022, relativo à autorização de endo-1,4-β-xilanase produzida por Trichoderma longibrachiatum CBS 139997 e α-galactosidase produzida por Aspergillus tubingensis ATCC SD 6740 como aditivo em alimentos para frangos de engorda, frangas para postura, espécies menores de aves de capoeira de engorda e para postura e aves ornamentais (detentor da autorização: Industrial Técnica Pecuaria S.A.) ( 1 )	109
	*	Regulamento de Execução (UE) 2022/1471 da Comissão, de 5 de setembro de 2022, relativo à autorização de carbonato de lantânio octa-hidratado como aditivo em alimentos para gatos (detentor da autorização: Porus GmbH) ( 1 )	113
	*	Regulamento de Execução (UE) 2022/1472 da Comissão, de 5 de setembro de 2022, relativo à autorização de sulfato lisinato de manganês como aditivo em alimentos para animais de todas as espécies ( 1 )	116

«07.030	1-(4-Metoxifenil)pent-1-en-3-ona	104-27-8	826	164		2	AESA
07.046	Vanililideno-acetona	1080-12-2	732	691		2	AESA
07.049	1-(4-Metoxifenil)-4-metilpent-1-en-3-ona	103-13-9	829	719		2	AESA
07.206	4-(2,3,6-Trimetilfenil)but-3-en-2-ona	56681-06-2				2	AESA
07.258	6-Metil-3-hepten-2-ona	2009-74-7				1	AESA
10.034	5,6-Di-hidro-3,6-dimetilbenzofuran-2(4H)-ona	80417-97-6	1163			2	AESA
10.036	5,6,7,7a-Tetra-hidro-3,6-dimetilbenzofuran-2(4H)-ona	13341-72-5	1162			2	AESA
10.042	3,4-Dimetil-5-pentilidenofuran-2(5H)-ona	774-64-1		11873	No mínimo 93 %; componente secundário: 1-2 % de gama-lactona do ácido 3,4-dimetil-5-cetobutanoico	2	AESA
10.043	2,7-Dimetilocta-5(trans),7-dieno-1,4-lactona	78548-56-8				2	AESA
10.046	Hex-2-eno-1,4-lactona	2407-43-4				2	AESA
10.054	Non-2-eno-1,4-lactona	21963-26-8				2	AESA
10.060	2-Deceno-1,4-lactona	2518-53-8				2	AESA
10.170	5-Pentil-3H-furan-2-ona	51352-68-2	1989		Mistura dos isómeros 3H- e 5H- (2:1)	2	AESA
13.004	2-Furoato de alilo	4208-49-5	21	360		2	AESA
13.034	3-(2-Furil)acrilaldeído	623-30-3	1497			1	AESA
13.043	Furfurilideno-2-butanal	770-27-4	1501	11885		1	AESA
13.044	4-(2-Furil)but-3-en-2-ona	623-15-4	1511	11838		1	AESA
13.046	3-(2-Furil)-2-metilprop-2-enal	874-66-8	1498	11878		1	AESA
13.066	3-Acetil-2,5-dimetilfurano	10599-70-9	1506	10921		4	AESA
13.103	2-Butilfurano	4466-24-4	1490	10927		3	AESA
13.137	3-(2-Furil)-2-fenilprop-2-enal	65545-81-5	1502	11928		1	AESA
13.150	3-(5-Metil-2-furil)prop-2-enal	5555-90-8	1499			1	AESA»