6.9.2022

Journal officiel de l’Union européenne

L 231/1

RÈGLEMENT D’EXÉCUTION (UE) 2022/1463 DE LA COMMISSION

du 5 août 2022

établissant les spécifications techniques et opérationnelles du système technique pour l’échange transfrontière automatisé de justificatifs et l’application du principe «une fois pour toutes» conformément au règlement (UE) 2018/1724 du Parlement européen et du Conseil

(Texte présentant de l’intérêt pour l’EEE)

LA COMMISSION EUROPÉENNE,

vu le traité sur le fonctionnement de l’Union européenne,

vu le règlement (UE) 2018/1724 du Parlement européen et du Conseil du 2 octobre 2018 établissant un portail numérique unique pour donner accès à des informations, à des procédures et à des services d’assistance et de résolution de problèmes, et modifiant le règlement (UE) no 1024/2012 (1), et notamment son article 14, paragraphe 9,

considérant ce qui suit:

(1)

L’article 14, paragraphe 1, du règlement (UE) 2018/1724 impose à la Commission de mettre en place, en coopération avec les États membres, un système technique d’échange de justificatifs requis pour les procédures en ligne énumérées à l’annexe II dudit règlement et les procédures prévues par les directives 2005/36/CE (2), 2006/123/CE (3), 2014/24/UE (4) et 2014/25/UE (5) du Parlement européen et du Conseil.

(2)

Les spécifications techniques et opérationnelles du système technique «une fois pour toutes» (OOTS) figurant dans le présent règlement devraient fixer les principales composantes de l’architecture de l’OOTS et définir les rôles et obligations techniques et opérationnels de la Commission, des États membres, des demandeurs de justificatifs, des fournisseurs de justificatifs et des plateformes intermédiaires. En outre, ces spécifications devraient établir un système d’enregistrement permettant de surveiller les échanges et de délimiter la responsabilité concernant la maintenance, l’exploitation et la sécurité de l’OOTS.

(3)

Afin de permettre la mise en place de l’OOTS à la date fixée dans le règlement (UE) 2018/1724, il est envisagé de compléter le présent règlement par des documents techniques plus détaillés et non contraignants, élaborés de manière consensuelle par la Commission en coopération avec les États membres au sein du groupe de coordination du portail et conformément aux lignes directrices de la Commission relatives à la mise en œuvre du programme de travail 2021-2022 du règlement sur le portail numérique unique. Toutefois, lorsque cela est jugé nécessaire à la lumière de nouvelles évolutions techniques, de discussions ou de divergences d’opinions au sein du groupe de coordination du portail, notamment en ce qui concerne la finalisation des documents d’études techniques et les choix de conception majeurs, ou lorsqu’il s’avère nécessaire de rendre contraignants certains éléments des documents d’études techniques, il sera possible de compléter/modifier les spécifications techniques et opérationnelles énoncées dans le présent règlement conformément à la procédure d’examen visée à l’article 37, paragraphe 2, du règlement (UE) 2018/1724.

(4)

Afin de réduire les coûts et le temps nécessaires pour la mise en place de l’OOTS, l’architecture de l’OOTS devrait, dans la mesure du possible, s’appuyer sur des solutions réutilisables, être neutre sur le plan technologique et tenir compte des différentes solutions nationales. Par exemple, l’OOTS devrait être en mesure d’utiliser l’échelon national, central, régional et local, les portails des procédures, les services de données ou les plateformes intermédiaires existants, qui ont été créés pour une utilisation nationale. Les composantes développées par la Commission devraient faire l’objet d’une licence logicielle ouverte qui favorise la réutilisation et la collaboration.

(5)

L’une de ces solutions réutilisables développée au niveau de l’Union est le système de nœuds eIDAS prévu par le règlement d’exécution (UE) 2015/1501 de la Commission (6), qui, en permettant la communication avec d’autres nœuds du réseau eIDAS, peut traiter la demande d’authentification transfrontière d’un utilisateur et la fourniture d’une telle authentification. Les nœuds eIDAS devraient permettre aux demandeurs de justificatifs et, le cas échéant, aux fournisseurs de justificatifs d’identifier les utilisateurs qui demandent l’échange de justificatifs par l’intermédiaire de l’OOTS afin que les fournisseurs de justificatifs puissent faire correspondre les données d’identification avec leurs dossiers existants.

(6)

L’OOTS devrait s’appuyer sur les travaux déjà réalisés et exploiter les synergies avec d’autres systèmes existants d’échange de justificatifs ou d’informations entre les autorités concernées par les procédures visées à l’article 14, paragraphe 1, du règlement (UE) 2018/1724, y compris les systèmes qui ne sont pas concernés par l’article 14, paragraphe 10, dudit règlement. Par exemple, en ce qui concerne les données du registre des véhicules et des permis de conduire, l’OOTS devrait tenir compte des modèles de données déjà élaborés et, dans la mesure du possible, établir des ponts techniques pour faciliter la connexion des autorités compétentes utilisant déjà d’autres réseaux existants [RESPER (7) ou EUCARIS (8)] à l’OOTS pour la fourniture de justificatifs dans le cadre des procédures couvertes par ce dernier. Il convient d’adopter une approche similaire en ce qui concerne d’autres systèmes tels que, entre autres: le groupe d’utilisateurs de l’EMREX (EUG) (9) dans le domaine de l’éducation, l’échange électronique d’informations sur la sécurité sociale (EESSI) au titre du règlement (CE) no 987/2009 du Parlement européen et du Conseil (10) dans le domaine de la sécurité sociale, le système européen d’information sur les casiers judiciaires créé par la décision 2009/316/JAI du Conseil (11) aux fins de la coopération judiciaire et le système eCertis (12) utilisé dans les procédures de passation des marchés publics. La coopération entre ces systèmes et l’OOTS devrait être définie au cas par cas.

(7)

Aux fins de l’authentification transfrontière d’un utilisateur, l’architecture de l’OOTS devrait être alignée sur le règlement (UE) no 910/2014 du Parlement européen et du Conseil (13). Le 3 juin 2021, la Commission a adopté une recommandation relative à une boîte à outils commune de l’Union en vue d’une approche coordonnée pour un cadre européen relatif à une identité numérique (14). Ladite recommandation établit un processus structuré de coopération entre les États membres, la Commission et, le cas échéant, les opérateurs du secteur privé, afin de travailler sur les aspects techniques du cadre européen relatif à une identité numérique. Afin de garantir l’alignement nécessaire entre ce processus et l’OOTS, la Commission devrait veiller à une coordination appropriée, notamment par l’intermédiaire du groupe de contact «Synergies et interopérabilité», entre le réseau de coopération établi par la décision d’exécution (UE) 2015/296 de la Commission (15) et le groupe de coordination du portail.

(8)

Afin de garantir la sécurité des services transfrontières de fourniture électronique aux fins de l’OOTS, les États membres devraient veiller à ce que ces services respectent les exigences relatives aux services d’envoi recommandé électronique, énoncées à l’article 44 du règlement (UE) no 910/2014. À cet effet, il convient que l’OOTS utilise des points d’accès eDelivery afin de créer un réseau de nœuds pour un échange de données numériques sécurisé. En plus de permettre des services de fourniture électronique transfrontière sécurisée, eDelivery fournit des fonctionnalités de service de métadonnées susceptibles de prendre en charge les futures versions de l’OOTS avec un plus grand nombre de nœuds d’échange de données sécurisés. Dans ce cadre, les États membres devraient pouvoir choisir les fournisseurs de leur logiciel eDelivery.

(9)

Afin de garantir une souplesse dans l’application du présent règlement, les États membres devraient pouvoir décider s’ils souhaitent disposer d’un ou de plusieurs points d’accès eDelivery, dans le cadre de l’OOTS. Un État membre devrait donc être en mesure de déployer un point d’accès unique gérant tous les messages eDelivery liés au système OOTS auprès des demandeurs ou des fournisseurs de justificatifs via une plateforme intermédiaire, le cas échéant, ou, à défaut, de déployer plusieurs points d’accès à tout niveau hiérarchique ou pour des domaines, secteurs ou niveaux géographiques spécifiques de ses administrations publiques.

(10)

Conformément au droit de l’Union, y compris les directives 2005/36/CE, 2006/123/CE, 2014/24/UE, 2014/25/UE et le règlement (UE) 2018/1724, certaines procédures administratives doivent être mises à la disposition des utilisateurs en ligne. Étant donné que ces procédures et les justificatifs requis ne sont pas harmonisés en vertu du droit de l’Union, des services communs devraient être mis en place pour permettre l’échange transfrontière des justificatifs requis aux fins de ces procédures par l’intermédiaire de l’OOTS.

(11)	Lorsqu’il n’existe pas de type de justificatif convenu qui soit harmonisé dans l’ensemble de l’Union et que tous les États membres puissent fournir, un intermédiaire des justificatifs devrait aider à déterminer quels types de justificatifs peuvent être acceptés pour une procédure particulière.

(12)

L’intermédiaire des justificatifs devrait se fonder sur le contenu des règles fournies par les États membres et devrait fournir un mécanisme en ligne permettant aux États membres de créer une requête pour leurs exigences en matière d’information et leurs ensembles de types de justificatifs. L’intermédiaire des justificatifs devrait permettre aux États membres de gérer et de partager des informations sur les règles relatives aux types de justificatifs.

(13)	Lorsqu’une interopérabilité est nécessaire entre le portail des procédures, les services de données et les services communs, elle devrait être étayée par des documents techniques.

(14)

Le présent règlement devrait préciser quand les justificatifs structurés et non structurés qui sont requis aux fins des procédures visées à l’article 14, paragraphe 1, du règlement (UE) 2018/1724 sont considérés comme émis légalement dans un format électronique permettant l’échange automatique. Les justificatifs non structurés émis sous forme électronique peuvent être échangés via l’OOTS s’ils sont complétés par les éléments de métadonnées du modèle de métadonnées générique de l’OOTS contenu dans le référentiel sémantique visé à l’article 7, paragraphe 1, du présent règlement. Des justificatifs structurés peuvent être échangés via l’OOTS s’ils sont complétés par les éléments de métadonnées du modèle de métadonnées générique de l’OOTS visé à l’article 7, paragraphe 1, du présent règlement et sont conformes au modèle de données de l’OOTS pour le type de justificatif pertinent visé à l’article 7, paragraphe 2, du présent règlement ou accompagnés d’une version lisible par un humain.

(15)

Les États membres devraient être libres de déterminer quand ils convertissent des justificatifs en un format électronique permettant leur échange automatisé via l’OOTS. Toutefois, afin de renforcer l’utilité de l’OOTS pour ses utilisateurs et étant donné que l’utilisation de modèles de données et de schémas de métadonnées pour les formats non structurés et structurés est généralement fortement recommandée, la Commission devrait soutenir les États membres dans les efforts qu’ils déploient pour atteindre cet objectif.

(16)

Afin d’éviter les doubles emplois, de garantir des synergies et d’offrir un choix aux utilisateurs, le développement de modèles de données OOTS pour les types de justificatifs structurés et la normalisation des cas d’utilisation pour la fourniture d’identifiants conformément au processus structuré prévu par la recommandation (UE) 2021/946 de la Commission du 3 juin 2021 concernant une boîte à outils commune de l’Union pour une approche coordonnée en vue d’un cadre européen relatif à une identité numérique (16) devraient être effectués en étroite coopération et en harmonie les uns avec les autres en ce qui concerne les justificatifs relevant de l’article 14 du règlement (UE) 2018/1724, y compris en recensant les cas d’utilisation commune. L’alignement des modèles de données de l’OOTS et des cas d’utilisation normalisés dans le cadre de la recommandation susmentionnée de la Commission devrait permettre aux utilisateurs de recourir à d’autres moyens pour la fourniture des justificatifs relevant de l’article 14 du règlement (UE) 2018/1724, que ce soit indépendamment de l’OOTS ou en combinaison avec celui-ci. Lorsque des modifications sont apportées aux modèles de données et aux schémas de métadonnées pour les justificatifs contenus dans le référentiel sémantique, les États membres devraient disposer d’un délai de douze mois à compter de l’adoption de toute mise à jour pour appliquer une modification aux justificatifs concernés.

(17)

Afin de réduire au minimum la quantité de données échangées, dans le cas des justificatifs structurés, si un seul sous-ensemble de données est requis dans la demande de justificatifs, le fournisseur de justificatifs ou une plateforme intermédiaire, le cas échéant, pourrait permettre le filtrage automatisé des données et, lorsque c’est nécessaire pour le transfert, la transformation des données pour le compte du responsable du traitement des données, de sorte que seules les données demandées soient échangées.

(18)

Lorsque les États membres gèrent des registres et services nationaux qui jouent le même rôle que le répertoire des services de données ou que l’intermédiaire des justificatifs, ou un rôle équivalent à ceux-ci, ils ne devraient pas être tenus de faire deux fois le travail en contribuant aux services communs concernés. Toutefois, dans ce cas, ils devraient veiller à ce que leurs services nationaux soient connectés aux services communs de manière à pouvoir être utilisés par d’autres États membres. Ces États membres devraient également pouvoir copier les données pertinentes des registres ou services nationaux vers le répertoire des services de données ou l’intermédiaire des justificatifs.

(19)

Dans la déclaration de Tallinn de 2017 sur l’administration électronique (17), les États membres ont réaffirmé leur engagement à progresser dans la mise en relation de leurs services publics en ligne et à mettre en œuvre le principe «une fois pour toutes» afin de fournir des services publics numériques efficaces et sûrs qui rendront les choses plus faciles pour les citoyens et les entreprises. La déclaration de Berlin de 2020 sur la société numérique et l’administration numérique fondée sur des valeurs (18), qui s’appuie sur les principes de centrage sur l’utilisateur et de convivialité, a défini d’autres principes clés sur lesquels les services publics numériques devraient être fondés, y compris la confiance et la sécurité dans les interactions de l’administration numérique ainsi que la souveraineté et l’interopérabilité numériques. Le présent règlement devrait mettre ces engagements en œuvre en plaçant les utilisateurs au centre du système et en exigeant que les utilisateurs soient informés sur l’OOTS, ses étapes et les conséquences de son utilisation.

(20)

Il importe qu’un système approprié soit en place pour permettre aux utilisateurs de s’identifier aux fins de l’échange de justificatifs. Le seul cadre de reconnaissance mutuelle pour les moyens d’identification électronique nationaux au niveau de l’Union est défini dans le règlement (UE) no 910/2014. Les moyens d’identification électronique émis dans le cadre de schémas d’identification électronique notifiés conformément audit règlement devraient donc être utilisés par les demandeurs de justificatifs pour authentifier l’identité d’un utilisateur avant que celui-ci ne demande explicitement l’utilisation de l’OOTS. Lorsque l’identification du fournisseur de justificatifs concerné exige la fourniture d’attributs allant au-delà des attributs obligatoires de l’ensemble minimal de données figurant à l’annexe du règlement d’exécution (UE) 2015/1501, ces attributs supplémentaires devraient également être demandés à l’utilisateur par le demandeur de justificatifs et fournis au fournisseur de justificatifs ou à la plateforme intermédiaire, le cas échéant, dans le cadre de la demande de justificatifs.

(21)

Certaines des procédures visées à l’article 14, paragraphe 1, du règlement (UE) 2018/1724 requièrent que des justificatifs puissent être demandés au nom d’une personne physique ou morale. Par exemple, certaines procédures étant pertinentes pour les entreprises, les entrepreneurs devraient pouvoir demander l’échange de justificatifs en leur nom propre ou par l’intermédiaire d’un représentant. Le règlement (UE) no 910/2014 établit un cadre juridique de confiance pour les moyens d’identification électronique délivrés aux personnes morales ou aux personnes physiques représentant des personnes morales. La reconnaissance mutuelle des moyens d’identification électronique nationaux prévue par ledit règlement s’applique à ces cas de représentation. Le présent règlement devrait donc s’appuyer sur le règlement (UE) no 910/2014, ainsi que sur tout acte d’exécution adopté sur la base de celui-ci, pour l’identification des utilisateurs dans des cas de représentation. Le groupe de coordination du portail et ses sous-groupes devraient coopérer étroitement avec les structures de gouvernance établies en vertu du règlement (UE) no 910/2014 afin de contribuer à l’élaboration de solutions pour les pouvoirs de représentation et les mandats. Étant donné que certaines des procédures couvertes par l’OOTS reposent sur le cadre créé par le règlement (UE) no 910/2014, les justificatifs demandés par les représentants devraient également pouvoir être traités par l’intermédiaire de l’OOTS si et dans la mesure où ces solutions sont trouvées.

(22)

Afin de réduire le temps et les coûts nécessaires à la mise en œuvre de l’OOTS et de tirer parti de l’expérience de chacun en matière de mise en œuvre, la Commission devrait soutenir les États membres et encourager leur collaboration en ce qui concerne le développement de solutions et de composantes techniques réutilisables pouvant être exploitées pour mettre en œuvre des portails des procédures, des espaces de prévisualisation et des services de données nationaux.

(23)

Afin de garantir que les utilisateurs conservent à tout moment le contrôle de leurs données à caractère personnel tout en utilisant le système OOTS prévu par le règlement (UE) 2018/1724, l’OOTS devrait permettre aux utilisateurs d’exprimer leur décision concernant ces données dans deux cas. Tout d’abord, il convient de veiller à ce que les utilisateurs reçoivent suffisamment d’informations pour présenter une demande éclairée et expresse de traitement de leur demande de justificatifs par l’intermédiaire de l’OOTS, conformément à l’article 14, paragraphe 3, point a), et à l’article 14, paragraphe 4, du règlement (UE) 2018/1724. Il convient ensuite de veiller à ce qu’ils puissent visualiser les justificatifs à échanger dans un espace sécurisé de prévisualisation avant de décider de procéder ou non à l’échange de justificatifs conformément à l’article 14, paragraphe 3, point f), du règlement (UE) 2018/1724, sauf dans les cas visés à l’article 14, paragraphe 5, dudit règlement.

(24)

La responsabilité de la mise en place de l’OOTS est partagée par les États membres et la Commission, et le groupe de coordination du portail devrait donc jouer un rôle central dans la gouvernance du système. Compte tenu de leur technicité et afin de faciliter la mise en œuvre, dans les systèmes nationaux existants, de documents techniques, les travaux du groupe de coordination du portail devraient être soutenus et préparés par des experts réunis au sein d’un ou de plusieurs sous-groupes créés conformément à son règlement intérieur. Le fonctionnement de cette gouvernance de l’OOTS devrait être évalué dans le rapport que la Commission est tenue de présenter au Parlement européen et au Conseil au plus tard le 12 décembre 2022, conformément à l’article 36 du règlement (UE) 2018/1724.

(25)

Afin de garantir une réaction rapide aux éventuels incidents et temps d’arrêt susceptibles d’affecter le fonctionnement de l’OOTS, les États membres et la Commission devraient mettre en place un réseau de points de contact pour l’assistance technique. Afin de garantir le bon fonctionnement de l’OOTS, ces points de contact pour l’assistance technique devraient disposer des pouvoirs et des ressources humaines et financières nécessaires pour accomplir leurs tâches.

(26)

Afin de garantir le fonctionnement et la maintenance efficaces de l’OOTS, les responsabilités portant sur les différentes composantes devraient être clairement réparties. La Commission, en tant que propriétaire et exploitante des services communs, devrait être responsable de leur maintenance, de leur hébergement et de leur sécurité. Chaque État membre devrait être chargé d’assurer la maintenance et la sécurité des composantes de l’OOTS dont il est propriétaire et responsable, tels que les nœuds eIDAS, les points d’accès eDelivery ou les registres nationaux, conformément au droit de l’Union et au droit national applicables.

(27)

Afin de garantir une protection appropriée des données à caractère personnel, comme l’exige le règlement (UE) 2016/679 du Parlement européen et du Conseil (19), le présent règlement devrait préciser le rôle des États membres, en particulier celui des autorités compétentes respectives en leur qualité de demandeur ou de fournisseur de justificatifs, et des plateformes intermédiaires, le cas échéant, en ce qui concerne les données à caractère personnel contenues dans les justificatifs échangés par l’intermédiaire de l’OOTS.

(28)

Afin de garantir la protection des services communs contre les menaces susceptibles de peser sur la confidentialité, l’intégrité ou la disponibilité des systèmes d’information et de communication de la Commission, il convient que la décision (UE, Euratom) 2017/46 de la Commission (20) s’applique à ces services.

(29)	Les paragraphes 1 à 8 et le paragraphe 10 de l’article 14 du règlement (UE) 2018/1724 sont applicables à partir du 12 décembre 2023. Par conséquent, les exigences énoncées dans le présent règlement devraient également s’appliquer à compter de cette date.

(30)	Le Contrôleur européen de la protection des données a été consulté conformément à l’article 42, paragraphe 1, du règlement (UE) 2018/1725 du Parlement européen et du Conseil (21), et a rendu des observations formelles le 6 mai 2021 (22).

(31)	Les mesures prévues par le présent règlement sont conformes à l’avis du comité du portail numérique unique,

A ADOPTÉ LE PRÉSENT RÈGLEMENT:

SECTION 1

DISPOSITIONS GÉNÉRALES

Article premier

Définitions

Aux fins du présent règlement, on entend par:

1)	«système technique “une fois pour toutes”» («OOTS»): le système technique pour l’échange transfrontière automatisé de justificatifs visé à l’article 14, paragraphe 1, du règlement (UE) 2018/1724;

2)	«fournisseur de justificatifs»: une autorité compétente, telle que visée à l’article 14, paragraphe 2, du règlement (UE) 2018/1724, qui délivre légalement des justificatifs structurés ou non structurés;

3)	«demandeur de justificatifs»: une autorité compétente responsable d’une ou de plusieurs des procédures visées à l’article 14, paragraphe 1, du règlement (UE) 2018/1724;

«point d’accès eDelivery»: une composante de communication qui fait partie du service d’envoi électronique eDelivery fondé sur des spécifications et des normes techniques, y compris le protocole de messagerie AS4 et les services auxiliaires élaborés dans le cadre du mécanisme pour l’interconnexion en Europe et maintenus dans le cadre du programme pour une Europe numérique, dans la mesure où ces spécifications techniques et normes se recoupent avec la norme ISO 15000-2;

5)	«nœud eIDAS»: un nœud tel que défini à l’article 2, point 1), du règlement d’exécution (UE) 2015/1501 et conforme aux exigences techniques et opérationnelles énoncées dans ledit règlement et sur la base de celui-ci;

«plateforme intermédiaire»: une solution technique agissant en sa propre qualité ou pour le compte d’autres entités telles que les fournisseurs ou les demandeurs de justificatifs, en fonction de l’organisation administrative des États membres dans lesquels la plateforme intermédiaire opère, et par l’intermédiaire de laquelle les fournisseurs ou les demandeurs de justificatifs se connectent aux services communs visés à l’article 4, paragraphe 1, ou aux fournisseurs ou demandeurs de justificatifs d’autres États membres;

7)	«répertoire des services de données»: un registre contenant la liste des fournisseurs de justificatifs et les types de justificatifs qu’ils délivrent, ainsi que les informations pertinentes qui les accompagnent;

8)	«intermédiaire des justificatifs»: un service permettant à un demandeur de justificatifs de déterminer quel type de justificatif provenant d’un autre État membre satisfait aux exigences en matière de justificatifs aux fins d’une procédure nationale;

9)	«moyen d’identification électronique»: un élément matériel et/ou immatériel contenant des données d’identification personnelle et utilisé pour s’authentifier pour un service en ligne;

10)

«référentiel sémantique»: un ensemble de spécifications sémantiques, liées à l’intermédiaire des justificatifs et au répertoire des services de données, composé des définitions des noms, des types de données et des éléments de données associés à des types de justificatifs spécifiques, afin de garantir une compréhension mutuelle et une interprétation multilingue par les fournisseurs de justificatifs, les demandeurs de justificatifs et les utilisateurs, lors de l’échange de justificatifs par l’intermédiaire de l’OOTS;

11)

«documents techniques»: un ensemble de documents techniques détaillés et non contraignants élaborés par la Commission en coopération avec les États membres dans le cadre du groupe de coordination du portail visé à l’article 29 du règlement (UE) 2018/1724 ou de tout sous-groupe visé à l’article 19 du présent règlement, qui portent, notamment, sur une architecture de haut niveau, des protocoles d’échange, des normes et des services auxiliaires qui soutiennent la Commission, les États membres, les fournisseurs de justificatifs, les demandeurs de justificatifs, les plateformes intermédiaires et les autres entités concernées par la mise en place de l’OOTS conformément au présent règlement;

12)	«service de données»: un service technique par l’intermédiaire duquel un fournisseur de justificatifs traite les demandes de justificatifs et expédie les justificatifs;

13)	«modèle de données»: une abstraction qui organise des éléments de données, normalise leur relation entre eux et précise les entités, leurs attributs et la relation entre ces entités;

14)	«espace de prévisualisation»: une fonctionnalité qui permet à l’utilisateur de prévisualiser les justificatifs demandés visés à l’article 15, paragraphe 1, point b), ii);

15)

«justificatif structuré»: tout justificatif sous forme électronique requis pour les procédures visées à l’article 14, paragraphe 1, du règlement (UE) 2018/1724 qui est organisé selon des éléments ou des champs prédéfinis ayant une signification et un format technique spécifiques permettant un traitement par des systèmes logiciels, complété par les éléments de métadonnées du modèle de métadonnées générique de l’OOTS visé à l’article 7, paragraphe 1, du présent règlement et conforme au modèle de données OOTS pour le type de justificatif pertinent visé à l’article 7, paragraphe 2, du présent règlement, ou accompagné d’une version lisible par un humain;

16)

«justificatif non structuré»: un justificatif sous forme électronique requis pour les procédures visées à l’article 14, paragraphe 1, du règlement (UE) 2018/1724, qui n’est pas organisé selon des éléments ou des champs prédéfinis ayant une signification et un format technique spécifiques, mais est complété par les éléments de métadonnées du modèle de métadonnées générique OOTS visé à l’article 7, paragraphe 1, du présent règlement;

17)	«type de justificatifs»: une catégorie de justificatifs structurés ou non structurés ayant un objet ou un contenu commun;

18)

«incident»: une situation dans laquelle l’OOTS n’exécute pas, omet de transmettre les justificatifs ou transmet des justificatifs qui n’ont pas été demandés, ou dans laquelle les justificatifs ont été modifiés ou divulgués au cours de la transmission, ainsi que toute violation de la sécurité visée à l’article 29;

19)	«portail des procédures»: une page web ou une application mobile sur lesquelles un utilisateur peut accéder à une procédure en ligne visée à l’article 14, paragraphe 1, du règlement (UE) 2018/1724 et la mener à son terme.

Article 2

Structure de l’OOTS

Le système OOTS comporte les composantes suivantes:

a)	les portails des procédures des demandeurs de justificatifs et les services de données des fournisseurs de justificatifs;

b)	des plateformes intermédiaires, le cas échéant;

c)	les espaces de prévisualisation visés à l’article 15, paragraphe 1, point b), ii);

d)	les registres et services nationaux visés à l’article 8, le cas échéant;

e)	des nœuds eIDAS pour l’authentification de l’utilisateur et la vérification de son identité;

f)	des points d’accès eDelivery;

g)	les services communs visés à l’article 4, paragraphe 1;

h)	les éléments d’intégration et les interfaces nécessaires pour connecter les composantes visées aux points a) à g).

SECTION 2

SERVICES DE L’OOTS

Article 3

Nœuds eIDAS et points d’accès eDelivery

1. Les États membres veillent à ce que les demandeurs de justificatifs soient connectés à un nœud eIDAS pour permettre l’authentification de l’utilisateur conformément à l’article 11, soit directement, soit via une plateforme intermédiaire.

2. Les États membres veillent à ce que des points d’accès eDelivery soient installés, configurés et intégrés dans les portails des procédures des demandeurs de justificatifs, dans les services de données des fournisseurs de justificatifs et dans les plateformes intermédiaires.

3. Les États membres peuvent choisir le nombre de points d’accès eDelivery qu’ils utilisent pour l’OOTS.

Article 4

Services communs

1. La Commission, en coopération avec les États membres, met en place les services suivants de l’OOTS (les «services communs»):

a)	le répertoire des services de données visé à l’article 5;

b)	l’intermédiaire des justificatifs visé à l’article 6;

c)	le référentiel sémantique visé à l’article 7.

2. Les États membres assurent la connexion technique entre les portails des procédures des demandeurs de justificatifs, directement ou via des plateformes intermédiaires, et les services communs ainsi que l’enregistrement correct de leurs services de données dans les services communs. Lors de la mise en œuvre de ces connexions, les États membres se laissent guider par les descriptions contenues dans les documents techniques.

3. Les États membres veillent à ce que seuls les demandeurs de justificatifs soient connectés aux services communs, directement ou via des plateformes intermédiaires, et à ce que seuls les demandeurs et les fournisseurs de justificatifs puissent utiliser l’OOTS. Les États membres vérifient à intervalles réguliers le fonctionnement des connexions avec les services communs.

Article 5

Répertoire des services de données

1. Sans préjudice de l’article 8 du présent règlement, les États membres veillent à ce que tous les fournisseurs de justificatifs et les types de justificatifs qu’ils délivrent qui sont pertinents pour les procédures en ligne visées à l’article 14, paragraphe 1, du règlement (UE) 2018/1724 soient enregistrés dans le répertoire des services de données.

2. La Commission est responsable du développement et de la maintenance des interfaces permettant aux coordonnateurs nationaux visés à l’article 28 du règlement (UE) 2018/1724, aux autorités compétentes, aux plateformes intermédiaires, le cas échéant, et à la Commission, dans les limites de leurs responsabilités et des droits d’accès définis par la Commission:

a)	d’enregistrer et de radier les informations contenues dans le répertoire des services de données et d’effectuer toute autre mise à jour de ces informations;

b)	de gérer les droits d’accès des personnes autorisées à effectuer des enregistrements et à apporter des modifications aux données enregistrées.

La Commission veille à ce que les coordonnateurs nationaux, les autorités compétentes et les plateformes intermédiaires puissent choisir entre des interfaces utilisateur graphiques pour les personnes autorisées et des interfaces programmatiques pour les téléchargements automatisés.

3. Les États membres veillent à ce que chaque type de justificatifs enregistré dans le répertoire des services de données s’accompagne:

a)	du niveau de garantie des moyens d’identification électronique notifiés par les États membres conformément au règlement (UE) no 910/2014; et

le cas échéant, des attributs supplémentaires, spécifiés afin de faciliter l’identification du fournisseur de justificatifs concerné et allant au-delà des attributs obligatoires des données minimales définies conformément au règlement d’exécution (UE) 2015/1501, échangés à l’aide des moyens d’identification électronique notifiés conformément au règlement (UE) no 910/2014, nécessaires à leur échange par l’intermédiaire de l’OOTS.

4. Le répertoire des services de données établit une distinction claire entre les attributs supplémentaires visés au paragraphe 3, point b), du présent article et les attributs échangés via les moyens d’identification électronique notifiés conformément au règlement (UE) no 910/2014 visés à l’article 13, paragraphe 1, point f), du présent règlement.

5. Le niveau de garantie visé au paragraphe 3, point a), requis pour les utilisateurs transfrontières n’excède pas le niveau de garantie requis pour les utilisateurs non transfrontières.

6. Les États membres veillent à ce que les informations contenues dans le répertoire des services de données soient tenues à jour.

Article 6

Intermédiaire des justificatifs

1. L’intermédiaire des justificatifs permet aux demandeurs de justificatifs de déterminer quels types de justificatifs délivrés dans d’autres États membres correspondent aux types de justificatifs requis dans le cadre des procédures pour lesquelles ces demandeurs de justificatifs sont compétents.

2. Les États membres complètent, au moyen de l’interface visée à l’article 5, paragraphe 2, la liste des types de justificatifs figurant dans le répertoire des services de données visé à l’article 5, paragraphe 1, par les faits ou le respect des exigences procédurales qu’ils prouvent, éventuellement conjointement avec d’autres types de justificatifs, si nécessaire. Ils veillent à ce que ces informations soient exactes et tenues à jour.

3. La Commission est responsable du développement et de la maintenance des interfaces permettant aux coordonnateurs nationaux, aux autorités compétentes, aux plateformes intermédiaires, le cas échéant, et à la Commission, dans les limites de leurs responsabilités et des droits d’accès définis par la Commission:

a)	d’ajouter, de modifier et de mettre à jour les informations visées au paragraphe 2;

b)	de gérer les droits d’accès des personnes autorisées à apporter des ajouts et des modifications aux informations enregistrées.

4. La Commission facilite la mise en correspondance des types de justificatifs délivrés dans un État membre avec les faits ou le respect des exigences procédurales qui doivent être prouvés dans le cadre d’une procédure dans un autre État membre en structurant la discussion et en organisant les travaux au sein du sous-groupe compétent visé à l’article 19. Le sous-groupe définit un langage formel spécifique du domaine, en faisant référence, autant que possible, aux normes internationales pertinentes, et propose ce langage au groupe de coordination du portail conformément à l’article 18, point f).

Article 7

Référentiel sémantique et modèles de données

1. Le référentiel sémantique donne accès au modèle de métadonnées générique de l’OOTS, qui est conçu pour afficher des métadonnées qui identifient de manière unique les justificatifs et le fournisseur de justificatifs et qui comprend des champs supplémentaires conçus pour afficher les métadonnées visées à l’article 13, paragraphe 1, points a), b) et c).

2. Pour les types de justificatifs structurés convenus au sein du groupe de coordination du portail, le référentiel sémantique contient un modèle de données de l’OOTS comprenant au moins les éléments suivants:

une représentation de ce modèle de données avec:

i)	un diagramme visuel de modélisation des données; et

ii)

une description textuelle de toutes les entités du modèle de données, comprenant une définition et une liste des attributs de l’entité; et, pour chaque attribut, le type attendu (par exemple booléen, identifiant, date), une définition, la cardinalité et l’utilisation facultative d’une liste de codes;

b)	des distributions en XML sur la base de la définition du schéma XML (XSD), ou un format équivalent, complétées par d’autres formats de série largement utilisés, dans la mesure du possible;

c)	des listes de codes pour assurer le traitement automatisé des justificatifs, disponibles dans un format structuré;

d)	un mécanisme de conversion dans un format lisible par un humain, tel que XSLT ou équivalent.

3. Pour chaque type de justificatifs, le référentiel sémantique propose un contrôle des versions et un journal des modifications permettant de suivre les différentes versions.

4. Le référentiel sémantique contient une méthode d’élaboration de nouveaux modèles de données OOTS pour les types de justificatifs échangés via l’OOTS, comprenant des exemples et du matériel d’apprentissage.

5. Les calendriers de mise à jour et d’adaptation des modèles de métadonnées génériques OOTS et des modèles de données OOTS sont régulièrement examinés par les États membres et la Commission dans le cadre de l’un des sous-groupes du groupe de coordination du portail visé à l’article 19 et adoptés par le groupe de coordination du portail. Les fournisseurs de justificatifs ou les plateformes intermédiaires, le cas échéant, appliquent ces mises à jour et adaptations au plus tard 12 mois après leur publication dans le référentiel sémantique.

6. La Commission fournit aux États membres un outil informatique qui les aidera à vérifier la conformité des justificatifs avec le modèle de métadonnées générique de l’OOTS et les modèles de données de l’OOTS.

7. La Commission met le référentiel sémantique à la disposition du public sur un site web spécifique de la Commission.

Article 8

Registres et services nationaux

1. Les États membres qui disposent de registres ou de services nationaux équivalents au répertoire des services de données ou à l’intermédiaire des justificatifs peuvent choisir de ne pas enregistrer les fournisseurs de justificatifs, les types de justificatifs qu’ils délivrent et les faits ou le respect des exigences procédurales que ceux-ci prouvent, éventuellement en combinaison avec d’autres types de justificatifs, et le niveau de garantie des moyens d’identification électronique requis pour accéder à chaque type de justificatifs conformément aux articles 5 et 6. Dans ce cas, les États membres:

a)	permettent aux autres États membres de rechercher dans leurs registres nationaux les informations visées au présent paragraphe;

b)	copient les informations visées au présent paragraphe des registres ou services nationaux vers le répertoire des services de données ou l’intermédiaire des justificatifs.

2. Lors de la mise en œuvre du paragraphe 1, les États membres se laissent guider par les descriptions contenues dans les documents techniques.

SECTION 3

DEMANDEURS DE JUSTIFICATIFS

Article 9

Explication aux utilisateurs

1. Les demandeurs de justificatifs veillent à ce que leurs portails des procédures contiennent une explication de l’OOTS et de ses caractéristiques, y compris des informations indiquant que:

a)	l’utilisation de l’OOTS est facultative;

b)	les utilisateurs ont la possibilité de prévisualiser les justificatifs dans l’espace de prévisualisation visé à l’article 15, paragraphe 1, point b), ii), et de décider de les utiliser ou non pour la procédure;

c)	les utilisateurs peuvent agir en leur nom propre ou être représentés par une autre personne morale ou physique, si et dans la mesure où des solutions de représentation conformes au règlement (UE) no 910/2014 et à tout acte d’exécution adopté sur la base de celui-ci ont été trouvées.

Les informations visées au premier alinéa, point b), du présent paragraphe ne sont pas requises dans le cas des procédures visées à l’article 14, paragraphe 5, du règlement (UE) 2018/1724.

2. L’obligation de fournir des explications visée au paragraphe 1 du présent article est sans préjudice de l’obligation de fournir aux personnes concernées les informations visées aux articles 13 et 14 du règlement (UE) 2016/679.

Article 10

Choix du type de justificatifs

1. Les demandeurs de justificatifs donnent aux utilisateurs la possibilité de demander, par soumission directe, les types de justificatifs correspondant, sur la base des informations enregistrées auprès de l’intermédiaire des justificatifs, à ceux qui seraient acceptables en vertu du droit applicable dans la procédure concernée, à condition que les fournisseurs de justificatifs mettent ces types de justificatifs à disposition via l’OOTS conformément à l’article 5, paragraphe 1.

2. Si plusieurs justificatifs peuvent être demandés, le demandeur de justificatifs veille à ce que les utilisateurs puissent sélectionner tous les justificatifs, un sous-ensemble ou un type spécifique de justificatifs.

Article 11

Authentification de l’utilisateur

1. Les demandeurs de justificatifs s’appuient sur des moyens d’identification électronique délivrés dans le cadre d’un schéma d’identification électronique notifié conformément au règlement (UE) no 910/2014 pour authentifier les utilisateurs, agissant en leur nom propre ou par l’intermédiaire d’un représentant, si et dans la mesure où des solutions de représentation conformes au règlement (UE) no 910/2014 et à tout acte d’exécution adopté sur la base de celui-ci ont été trouvées.

2. Une fois que l’utilisateur a sélectionné le type de justificatifs à échanger par l’intermédiaire de l’OOTS, les demandeurs de justificatifs informent les utilisateurs:

a)	le cas échéant, des attributs supplémentaires visés à l’article 5, paragraphe 3, point b), du présent règlement qu’ils doivent fournir; et

b)	qu’ils seront redirigés vers le ou les fournisseurs de justificatifs concernés ou, le cas échéant, la ou les plateformes intermédiaires concernées, afin de prévisualiser les justificatifs sélectionnés.

3. Lorsque la prévisualisation n’est pas requise conformément à l’article 14, paragraphe 5, du règlement (UE) 2018/1724, le paragraphe 2, point b), du présent article ne s’applique pas. Dans ce cas, le ou les fournisseurs de justificatifs ou, le cas échéant, la ou les plateformes intermédiaires peuvent demander au demandeur de justificatifs de rediriger l’utilisateur afin qu’il s’identifie et s’authentifie de nouveau aux fins de la mise en correspondance de son identité et des justificatifs. L’utilisateur peut choisir de ne pas être redirigé. Dans ce cas, le demandeur de justificatifs informe l’utilisateur que le processus de mise en correspondance de l’identité et des justificatifs effectué par le fournisseur de justificatifs pourrait ne pas aboutir à une correspondance telle que visée à l’article 16 du présent règlement.

Article 12

Demande expresse

Outre les informations visées à l’article 9, le demandeur de justificatifs fournit à l’utilisateur:

a)	le(s) nom(s) du (des) fournisseur(s) de justificatifs;

b)	le(s) type(s) de justificatifs ou les champs de données à échanger.

Le présent article est sans préjudice des situations dans lesquelles l’utilisation de l’OOTS est autorisée sans nécessité de demande expresse conformément à l’article 14, paragraphe 4, du règlement (UE) 2018/1724.

Article 13

Demande de justificatifs

1. Le demandeur de justificatifs veille à ce que la demande de justificatifs soit transmise au fournisseur de justificatifs ou à la plateforme intermédiaire, le cas échéant, et contienne les informations suivantes:

a)	l’identifiant unique de la demande;

b)	le type de justificatifs demandé;

c)	la date et l’heure de la demande expresse;

d)	l’identification de la procédure pour laquelle les justificatifs sont exigés;

e)	le nom et les métadonnées qui identifient de manière unique le demandeur de justificatifs et la plateforme intermédiaire, le cas échéant;

f)	les attributs de l’utilisateur, ou de l’utilisateur et de son représentant, le cas échéant, échangés via les moyens d’identification électronique visés à l’article 11, paragraphe 1;

g)	le niveau de garantie, tel que défini dans le règlement (UE) no 910/2014, des moyens d’identification électronique utilisés par l’utilisateur;

h)	les attributs supplémentaires visés à l’article 5, paragraphe 3, point b), fournis par l’utilisateur aux fins de la demande;

i)	l’identification du fournisseur de justificatifs tel qu’il est enregistré dans le répertoire des services de données;

j)	si la demande expresse de l’utilisateur était requise conformément à l’article 14, paragraphe 4, du règlement (UE) 2018/1724;

k)	si la possibilité de prévisualiser les justificatifs est requise conformément à l’article 14, paragraphe 5, du règlement (UE) 2018/1724.

2. Le demandeur de justificatifs établit une distinction claire entre les attributs supplémentaires visés au paragraphe 1, point h), et les attributs visés au paragraphe 1, point f).

Article 14

Redirection de l’utilisateur vers le fournisseur de justificatifs

1. Sans préjudice des procédures visées à l’article 14, paragraphe 5, du règlement (UE) 2018/1724, les demandeurs de justificatifs veillent à ce que les utilisateurs, après avoir sélectionné les justificatifs à échanger au moyen de l’OOTS sur le portail des procédures conformément à l’article 10 du présent règlement et exprimé leur demande expresse conformément à l’article 12 du présent règlement, soient redirigés vers le ou les fournisseurs de justificatifs ou vers la ou les plateformes intermédiaires, le cas échéant, afin d’exercer la possibilité de prévisualiser les justificatifs.

2. Pour les procédures visées à l’article 14, paragraphe 5, du règlement (UE) 2018/1724, les utilisateurs peuvent être redirigés vers le ou les fournisseurs de justificatifs ou vers la ou les plateformes intermédiaires, le cas échéant, conformément à l’article 11, paragraphe 3, du présent règlement.

SECTION 4

FOURNISSEURS DE JUSTIFICATIFS

Article 15

Rôle dans l’échange de justificatifs

1. Les États membres veillent à ce que, aux fins de l’échange de justificatifs au moyen de l’OOTS, les fournisseurs de justificatifs ou les plateformes intermédiaires, le cas échéant, utilisent des services d’application capables:

a)	de recevoir et d’interpréter des demandes de justificatifs émanant d’un point d’accès eDelivery, qui sont considérées comme la contribution aux services de données;

sous réserve de l’identification et de l’authentification réussies conformément à l’article 16 du présent règlement:

i)	de récupérer tout justificatif correspondant à la demande;

ii)

sauf dans le cas des procédures visées à l’article 14, paragraphe 5, du règlement (UE) 2018/1724, de permettre aux utilisateurs d’indiquer lesquels de ces justificatifs ils souhaitent prévisualiser et de leur donner la possibilité de prévisualiser les justificatifs ainsi indiqués dans un espace de prévisualisation;

iii)	de permettre aux utilisateurs d’indiquer, le cas échéant, les justificatifs correspondants qui devraient être renvoyés au demandeur de justificatifs en vue de leur utilisation dans le cadre de la procédure;

de renvoyer au demandeur de justificatifs une réponse relative à ces justificatifs au moyen d’un point d’accès eDelivery, sous réserve de la décision de l’utilisateur d’utiliser les justificatifs dans le cadre de la procédure suivant la possibilité de les prévisualiser, sauf dans le cas des procédures visées à l’article 14, paragraphe 5, du règlement (UE) 2018/1724, des rapports d’erreur, y compris dans la situation visée à l’article 16, paragraphe 3, point a), du présent règlement, ou des rapports concernant des justificatifs en cours de conversion.

2. Si une réponse relative aux justificatifs est renvoyée, elle inclut les justificatifs demandés et est accompagnée:

a)	des métadonnées qui identifient de manière unique la réponse relative aux justificatifs;

b)	des métadonnées qui identifient de manière unique la demande de justificatifs;

c)	des métadonnées qui indiquent la date et l’heure auxquelles la réponse a été créée;

d)	des métadonnées qui identifient de manière unique les justificatifs et le fournisseur de justificatifs;

e)	lorsque des justificatifs structurés ne sont pas conformes au modèle de données OOTS pertinent pour le type de justificatifs concerné, une version des justificatifs lisible par un humain.

3. La réponse relative aux justificatifs peut également inclure les métadonnées qui identifient de manière unique la ou les langues des justificatifs demandés.

4. Si un rapport d’erreur est renvoyé, il contient des métadonnées qui identifient de manière unique la demande de justificatifs, la date et l’heure auxquelles il a été créé et une description de l’erreur qui s’est produite.

5. Lorsque les justificatifs ne sont pas encore disponibles pour l’échange au moyen de l’OOTS, mais sont en cours de conversion en justificatifs structurés ou non structurés au sens de l’article 1er, points 16) et 17), un rapport, tel que visé au paragraphe 1, point c), du présent article est renvoyé. Ledit rapport contient des métadonnées qui identifient de manière unique la demande de justificatifs, la date et l’heure auxquelles il a été créé ainsi qu’un message indiquant que les justificatifs concernés sont en cours de conversion en justificatifs structurés ou non structurés au sens de l’article 1er, points 16) et 17), et seront prêts plus tard pour la transmission au moyen de l’OOTS. Le fournisseur de justificatifs indique dans le rapport la date et l’heure auxquelles les justificatifs devraient être disponibles.

Article 16

Mise en correspondance de l’identité et des justificatifs

1. Les fournisseurs de justificatifs ou les plateformes intermédiaires, le cas échéant, peuvent exiger des utilisateurs qu’ils s’identifient et s’authentifient de nouveau aux fins de la mise en correspondance de leur identité et des justificatifs, y compris en fournissant des attributs supplémentaires.

2. Les fournisseurs de justificatifs ou les plateformes intermédiaires, le cas échéant, veillent à ce que les justificatifs ne soient échangés au moyen de l’OOTS que si les attributs d’identité de l’utilisateur et, le cas échéant, du représentant, échangés via des moyens d’identification électronique visés à l’article 11, paragraphe 1, et les attributs supplémentaires visés à l’article 11, paragraphe 2, point a), et fournis par l’utilisateur pour faciliter l’identification par le fournisseur de justificatifs concerné, correspondent aux attributs qu’ils détiennent.

3. Lorsque le processus de mise en correspondance de l’identité et des justificatifs n’aboutit pas à une correspondance ou donne lieu à deux résultats ou plus, l’utilisateur ou le représentant, le cas échéant, n’est pas autorisé à prévisualiser les justificatifs demandés, qui ne sont pas échangés. En l’absence d’une telle correspondance:

a)	un message d’erreur est envoyé au demandeur de justificatifs;

b)	l’utilisateur reçoit un message automatique expliquant que le justificatif ne peut être fourni.

SECTION 5

SYSTÈME D’ENREGISTREMENT DE L’OOTS

Article 17

Système d’enregistrement

1. Pour chaque demande de justificatifs transmise au moyen de l’OOTS, le demandeur de justificatifs, le ou les fournisseurs de justificatifs ou la ou les plateformes intermédiaires, le cas échéant, enregistrent les éléments suivants:

a)	la demande de justificatifs visée à l’article 13, paragraphe 1;

b)	les informations figurant dans la réponse relative aux justificatifs demandés, à l’exception des justificatifs proprement dits, ou dans le rapport d’erreur visé à l’article 15, paragraphe 1, point c), et à l’article 16, paragraphe 3, point a);

les données relatives à l’événement eDelivery se rapportant à l’un des éléments suivants:

i)	les demandes d’échange de justificatifs;

ii)	les réponses relatives aux justificatifs;

iii)	les rapports d’erreur.

2. Pour chaque justificatif échangé au moyen de l’OOTS, le fournisseur de justificatifs ou la plateforme intermédiaire, le cas échéant, enregistre la décision prise par l’utilisateur, après avoir prévisualisé le justificatif, d’approuver ou non son utilisation aux fins de la procédure ou, le cas échéant, le fait que l’utilisateur quitte l’espace de prévisualisation ou le portail des procédures sans prendre de décision spécifique.

3. La Commission et, dans les situations visées à l’article 8, paragraphe 1, point a), les États membres concernés enregistrent toutes les interactions avec les services communs visés à l’article 4, paragraphe 1.

4. Sans préjudice des périodes de conservation plus longues requises en vertu du droit national pour les enregistrements visés aux paragraphes 1, 2 et 3 aux fins de l’OOTS ou à d’autres fins, la Commission et les demandeurs de justificatifs, les fournisseurs de justificatifs ou les plateformes intermédiaires, le cas échéant, conservent ces enregistrements pendant une période de douze mois.

5. En cas de suspicion d’incidents et aux fins des audits et des contrôles aléatoires de sécurité effectués dans leurs domaines de responsabilité respectifs visés à l’article 26, les demandeurs de justificatifs, les fournisseurs de justificatifs et les plateformes intermédiaires, le cas échéant, se communiquent mutuellement, sur demande, les enregistrements pertinents visés aux paragraphes 1 et 2 du présent article au moyen du tableau de bord de l’assistance technique visé à l’article 22. À ces mêmes fins et de la même manière, les États membres et la Commission, le cas échéant, mettent à la disposition des demandeurs de justificatifs, des fournisseurs de justificatifs et des plateformes intermédiaires, le cas échéant, concernés les enregistrements pertinents visés au paragraphe 3 du présent article.

SECTION 6

GOUVERNANCE DE L’OOTS

Article 18

Groupe de coordination du portail

La Commission, en coopération avec les États membres dans le cadre du groupe de coordination du portail institué par l’article 29 du règlement (UE) 2018/1724:

a)	supervise la mise en place et le lancement de l’OOTS conformément à l’article 31, paragraphe 3, du présent règlement;

b)	fixe les priorités en matière de développement et d’amélioration futurs de l’OOTS;

c)	établit un calendrier indicatif de la mise à jour régulière, de la confirmation et de l’adaptation des documents techniques;

d)	recommande des modifications dans les documents techniques;

e)	organise des examens par les pairs afin de promouvoir les échanges d’expériences et de bonnes pratiques entre les États membres en ce qui concerne l’application du présent règlement par les États membres;

f)	approuve ou rejette les modalités de fonctionnement soumises par les sous-groupes établis conformément au règlement intérieur du groupe de coordination du portail et, si nécessaire, donne des orientations spécifiques et supervise leurs travaux.

Article 19

Sous-groupes du groupe de coordination du portail

1. Pour veiller à la coordination du développement et du fonctionnement de l’OOTS, les sous-groupes visés à l’article 18, point f), examinent et, si nécessaire, élaborent des propositions de modalités de fonctionnement à soumettre au groupe de coordination du portail dans les domaines suivants, en particulier:

a)	la normalisation des modèles de données de l’OOTS;

b)	la configuration des justificatifs;

c)	l’examen, le maintien et l’interprétation des documents techniques;

d)	la gouvernance opérationnelle, en particulier les modalités de fonctionnement et les accords de niveau de service;

e)	la sécurité de l’OOTS, y compris l’élaboration de plans de gestion des risques afin d’identifier les risques, d’évaluer leur incidence potentielle et de planifier les réponses techniques et organisationnelles appropriées en cas d’incident;

f)	les essais et le déploiement des composantes de l’OOTS, y compris l’interopérabilité entre les composantes nationales de l’OOTS visées à l’article 2, points a) à f) et point h), et les services communs visés à l’article 4, paragraphe 1.

Les modalités de fonctionnement comprennent l’élaboration et la proposition des normes nécessaires à l’interopérabilité dans les domaines respectifs des sous-groupes, en suivant, dans la mesure du possible, les normes internationales. Une fois approuvées par le groupe de coordination du portail, ces normes sont incluses dans les documents techniques.

2. Les sous-groupes adoptent leurs propositions de modalités de fonctionnement par consensus, chaque fois que c’est possible. Lorsqu’il apparaît impossible de parvenir à un consensus, le président peut décider, s’il est soutenu par la majorité simple des membres du sous-groupe présents à la réunion, qu’une proposition du sous-groupe peut être soumise au groupe de coordination du portail.

SECTION 7

ASSISTANCE TECHNIQUE

Article 20

Point de contact unique de la Commission pour l’assistance technique

1. La Commission désigne un point de contact unique pour l’assistance technique, qui est chargé de l’exploitation et de la maintenance des services communs visés à l’article 4, paragraphe 1.

2. Le point de contact unique pour l’assistance technique assure la liaison avec d’autres points de contact pertinents de la Commission et coordonne la résolution des problèmes avec les points d’accès eDelivery ou les nœuds eIDAS.

3. La Commission veille à ce que son point de contact unique pour l’assistance technique soit organisé de manière qu’il puisse accomplir ses tâches en toutes circonstances et réagir rapidement.

Article 21

Point de contact unique national pour l’assistance technique

1. Chaque État membre désigne un point de contact unique pour l’assistance technique afin d’assurer l’exploitation et la maintenance des composantes pertinentes de l’OOTS dont il est responsable en vertu de la section 9.

2. Les points de contact uniques pour l’assistance technique:

fournissent une expertise et des conseils aux fournisseurs et aux demandeurs de justificatifs pour tous les problèmes techniques rencontrés dans le cadre du fonctionnement de l’OOTS et, si nécessaire, assurent la liaison avec le point de contact technique de la Commission et avec d’autres points de contact nationaux pour l’assistance technique;

b)	enquêtent sur les temps d’arrêt éventuels des points d’accès eDelivery, sur les éventuelles atteintes à la sécurité ainsi que sur les autres incidents, et les résolvent;

c)	informent les points de contact pour l’assistance technique de toute activité susceptible d’entraîner une atteinte effective ou présumée à la sécurité des systèmes électroniques.

3. Lorsqu’il est informé par un fournisseur de justificatifs de doutes quant à la légalité d’une ou de plusieurs demandes de justificatifs, le point de contact unique pour l’assistance technique:

a)	examine les demandes de justificatifs ou des échantillons de demandes de justificatifs transmises par le même demandeur de justificatifs dans le passé;

b)	utilise le tableau de bord de l’assistance technique visé à l’article 22 pour demander au point de contact unique pour l’assistance technique désigné par l’État membre du demandeur de justificatifs de transmettre les enregistrements des échanges sélectionnés visés à l’article 17;

c)	porte la question à l’attention du coordonnateur national si le problème persiste.

4. Les États membres veillent à ce que leur point de contact unique pour l’assistance technique respectif soit organisé de manière qu’il puisse accomplir ses tâches en toutes circonstances et réagir rapidement.

Article 22

Tableau de bord de l’assistance technique

1. La Commission met en place un tableau de bord pour faciliter la communication entre tous les points de contact pour l’assistance technique.

2. Les États membres et la Commission enregistrent dans le tableau de bord les coordonnées des points de contact pour l’assistance technique et les tiennent à jour.

3. Au moyen du tableau de bord, les points de contact:

a)	signalent tout incident considéré comme substantiel;

b)	signalent toute mesure temporaire ou permanente prise à la suite d’incidents;

c)	demandent aux points de contact pour l’assistance technique pertinents les enregistrements des échanges sélectionnés dans les cas visés à l’article 17, paragraphe 5, et, en cas de doute quant à la légalité de la demande de justificatifs conformément à l’article 21, paragraphe 3;

d)	demandent toute autre assistance nécessaire en cas d’incident.

4. Les coordonnateurs nationaux et le président du groupe de coordination du portail ont accès au tableau de bord.

5. La Commission et les coordonnateurs nationaux utilisent le tableau de bord pour fournir les informations visées à l’article 27 et à l’article 28, paragraphe 2.

SECTION 8

COOPÉRATION AVEC D’AUTRES STRUCTURES DE GOUVERNANCE

Article 23

Portée de la coopération

La Commission, conjointement avec le groupe de coordination du portail et ses sous-groupes, coopère avec les structures de gouvernance pertinentes établies par le droit de l’Union ou des accords internationaux dans des domaines pertinents pour l’OOTS afin de créer des synergies et de réutiliser, dans la mesure du possible, les solutions élaborées dans ces autres structures.

SECTION 9

RESPONSABILITÉ EN MATIÈRE DE MAINTENANCE ET D’EXPLOITATION DES COMPOSANTES DE L’OOTS

Article 24

Responsabilités de la Commission

La Commission est propriétaire des services communs et du tableau de bord de l’assistance technique et est responsable de leur développement, de leur disponibilité, de leur contrôle, de leur mise à jour, de leur maintenance et de leur hébergement.

Article 25

Responsabilités des États membres

Chaque État membre est réputé propriétaire et responsable de la mise en place, le cas échéant, ainsi que du développement, de la disponibilité, du contrôle, de la mise à jour, de la maintenance et de l’hébergement des composantes nationales respectives de l’OOTS visées à l’article 2, points a) à f) et point h).

Article 26

Modifications et mises à jour

1. La Commission informe les États membres des modifications et mises à jour apportées aux services communs.

2. Les États membres informent la Commission des modifications et mises à jour apportées aux composantes dont ils sont responsables et qui sont susceptibles d’avoir des répercussions sur le fonctionnement de l’OOTS.

3. Les informations sur les mises à jour critiques sont fournies sans retard injustifié. Dans le cas d’autres mises à jour non critiques susceptibles d’avoir une incidence sur les composantes de l’OOTS appartenant à d’autres États membres ou sur les services communs, le délai de réalisation des mises à jour est fixé par le groupe de coordination du portail sur la base d’une proposition du sous-groupe concerné.

Article 27

Disponibilité de l’OOTS

1. L’OOTS fonctionne 24 heures sur 24 et 7 jours sur 7, avec un taux de disponibilité des points d’accès eDelivery, des espaces de prévisualisation et des services communs d’au moins 98 %, sauf en cas de maintenance programmée conformément au paragraphe 2 du présent article. Les objectifs de niveau de service des autres éléments de l’OOTS sont précisés dans les accords de niveau de service visés à l’article 19, paragraphe 1, point d).

2. Les États membres et la Commission notifient les activités de maintenance programmées relatives aux composantes pertinentes de l’OOTS comme suit:

a)	5 jours ouvrables à l’avance en cas d’opérations de maintenance pouvant entraîner jusqu’à 4 heures d’indisponibilité;

b)	10 jours ouvrables à l’avance en cas d’opérations de maintenance pouvant entraîner jusqu’à 12 heures d’indisponibilité;

c)	30 jours ouvrables à l’avance en cas d’opérations de maintenance de l’infrastructure en salle informatique pouvant entraîner jusqu’à 6 jours d’indisponibilité par an.

Dans la mesure du possible, les opérations de maintenance sont programmées en dehors des heures de travail.

3. Lorsqu’un État membre a fixé des créneaux hebdomadaires de maintenance, il notifie à la Commission le jour et les heures prévus pour ces créneaux. Sans préjudice des obligations visées au paragraphe 2, points a), b) et c), si le système est indisponible à ces créneaux planifiés, l’État membre n’est pas tenu de le notifier à la Commission à chaque fois.

4. En cas de défaillance technique inattendue des composantes de l’OOTS d’un État membre, l’État membre concerné informe sans délai les autres États membres et la Commission de leur indisponibilité et, s’il est connu, du moment auquel les composantes devraient fonctionner de nouveau.

5. En cas de défaillance inattendue des services communs, la Commission informe sans délai les États membres de l’indisponibilité d’un ou de plusieurs services communs et, s’il est connu, du moment estimé de reprise des services concernés.

6. Les notifications visées au présent article sont effectuées au moyen du tableau de bord de l’assistance technique visé à l’article 22.

SECTION 10

SÉCURITÉ

Article 28

Sécurité des services communs et des composantes nationales

1. La Commission assure la sécurité des services communs visés à l’article 4, paragraphe 1, ainsi que des éléments d’intégration et des interfaces visés à l’article 2, point h), dont elle est responsable.

2. Les États membres assurent la sécurité des composantes nationales de l’OOTS ainsi que des éléments d’intégration et des interfaces visés à l’article 2, point h), dont ils sont responsables.

3. Aux fins visées aux paragraphes 1 et 2, les États membres et la Commission prennent, au moins, chacun pour la composante dont il est responsable, les mesures nécessaires pour:

a)	empêcher toute personne qui n’y est pas autorisée d’avoir accès aux composantes dont ils sont responsables;

b)	empêcher l’encodage de données et toute consultation, modification ou suppression de données par des personnes qui n’y sont pas autorisées;

c)	détecter toute activité visée aux points a) et b); et

d)	veiller à ce que les événements liés à la sécurité soient enregistrés conformément aux normes de sécurité internationales reconnues en matière de technologies de l’information.

4. Les États membres veillent, en particulier, à ce que:

les connexions qu’ils opèrent vers et depuis les points d’accès eDelivery et toutes les communications internes entre les différentes autorités nationales satisfassent au moins au même niveau d’exigences de sécurité que le service d’envoi électronique eDelivery afin de protéger la sécurité et la confidentialité de l’échange et l’intégrité des justificatifs échangés au moyen de l’OOTS;

b)	l’origine de la demande de justificatifs transmise par le point d’accès du demandeur de justificatifs et de la réponse relative aux justificatifs échangée ou du message d’erreur transmis par le point d’accès du fournisseur de justificatifs ne soit pas répudiée.

5. Conformément au paragraphe 4, lors de tout échange de justificatifs donné, l’État membre du fournisseur de justificatifs est responsable de la qualité, de la confidentialité, de l’intégrité et de la disponibilité des justificatifs demandés jusqu’à ce qu’ils parviennent au point d’accès eDelivery du demandeur de justificatifs ou à une plateforme intermédiaire, le cas échéant. Lors d’un échange de justificatifs donné, l’État membre du demandeur de justificatifs est responsable de la confidentialité et de l’intégrité des justificatifs demandés dès qu’ils parviennent à son point d’accès eDelivery.

6. Les États membres et la Commission assurent la confidentialité, l’intégrité et la disponibilité des enregistrements visés à l’article 17, paragraphes 1, 2) et 3), au moyen de mesures de sécurité appropriées et proportionnées, chacun pour les enregistrements qu’il a effectués.

Article 29

Contrôle des systèmes électroniques

1. Les États membres et la Commission procèdent à des contrôles réguliers des composantes de l’OOTS dont ils sont responsables.

2. Les points de contact uniques pour l’assistance technique visés aux articles 20 et 21 utilisent le tableau de bord de l’assistance technique visé à l’article 22 pour s’informer mutuellement des problèmes constatés lors des contrôles et susceptibles d’entraîner une atteinte effective ou présumée à la sécurité de l’OOTS.

Article 30

Système de gestion de l’administration

La Commission met en place un système de gestion administrative pour gérer les règles d’authentification et d’autorisation permettant la validation des données d’identification afin de permettre l’accès aux services communs et au tableau de bord de l’assistance technique.

SECTION 11

DISPOSITIONS FINALES

Article 31

Essais de l’OOTS

1. Les États membres et la Commission adoptent, dans le cadre du groupe de coordination du portail, un calendrier d’essais et un ensemble d’indicateurs en fonction desquels les résultats peuvent être mesurés et considérés comme positifs.

2. La Commission fournit des services d’essai que les États membres peuvent utiliser pour tester la conformité des solutions techniques à partir des indicateurs visés au paragraphe 1.

3. Les États membres et la Commission testent le fonctionnement de chacune des composantes de l’OOTS et vérifient si elles peuvent fonctionner correctement conformément aux indicateurs visés au paragraphe 1. Seules les composantes de l’OOTS pour lesquelles les essais donnent des résultats positifs sont mises à la disposition des utilisateurs.

Article 32

Aide de la Commission

La Commission met à disposition une équipe d’experts dans le cadre de son point de contact pour l’assistance technique pour aider les points de contact nationaux pour l’assistance technique et les coordonnateurs nationaux dans tous les aspects liés au fonctionnement de l’OOTS d’un point de vue technique, en particulier:

a)	la fourniture de lignes directrices;

b)	l’organisation d’ateliers et de démonstrations;

c)	les réponses à donner à des questions individuelles.

Article 33

Traitement des données à caractère personnel

En ce qui concerne le traitement des données à caractère personnel figurant dans les justificatifs et faisant l’objet d’un échange effectué dans les composantes du système OOTS dont elles sont propriétaires en vertu de l’article 25 du présent règlement, les autorités compétentes respectives des États membres, en leur qualité de demandeur ou de fournisseur de justificatifs, agissent en tant que responsables du traitement au sens de l’article 4, point 7, du règlement (UE) 2016/679 et comme précisé aux articles 34 et 35 du présent règlement.

Article 34

Responsabilités du demandeur de justificatifs en qualité de responsable du traitement des données

1. Pour chaque échange de justificatifs effectué au moyen de l’OOTS, le demandeur de justificatifs concerné ou la plateforme intermédiaire concernée, le cas échéant, est l’unique responsable du caractère complet et légal de la demande de justificatifs. Le demandeur de justificatifs veille, en particulier, à ce que les justificatifs soient requis pour la procédure particulière pour laquelle ils sont demandés par un utilisateur.

2. Une fois que les justificatifs échangés au moyen de l’OOTS sont mis à la disposition du demandeur de justificatifs ou de la plateforme intermédiaire, le cas échéant, soit à la suite du choix de l’utilisateur de procéder à l’échange de justificatifs conformément à l’article 14, paragraphe 3, point f), du règlement (UE) 2018/1724, soit dans le cas des procédures visées à l’article 14, paragraphe 5, du règlement (UE) 2018/1724, le demandeur de justificatifs ou la plateforme intermédiaire, le cas échéant, assure le même niveau de protection des données à caractère personnel, conformément au règlement (UE) 2016/679, que dans une situation où l’utilisateur soumet ou télécharge des justificatifs sans recourir à l’OOTS.

Article 35

Responsabilités du fournisseur de justificatifs en qualité de responsable du traitement des données

1. Sans préjudice des obligations qui lui incombent en vertu du règlement (UE) 2016/679, pour chaque échange de justificatifs effectué au moyen de l’OOTS, le fournisseur de justificatifs concerné ou la plateforme intermédiaire concernée, le cas échéant, est l’unique responsable pour vérifier:

a)	si les justificatifs demandés qu’il ou elle détient peuvent être mis en correspondance avec l’utilisateur conformément à l’article 16;

b)	si l’utilisateur a le droit d’utiliser les justificatifs demandés.

2. Lorsqu’une plateforme intermédiaire fournit l’espace de prévisualisation conformément à l’article 15, paragraphe 1, point b), ii), du présent règlement, elle est considérée comme un sous-traitant agissant pour le compte du fournisseur de justificatifs conformément à l’article 4, point 8, du règlement (UE) 2016/679.

Article 36

Entrée en vigueur

Le présent règlement entre en vigueur le vingtième jour suivant celui de sa publication au Journal officiel de l’Union européenne.

Il est applicable à partir du 12 décembre 2023.

Le présent règlement est obligatoire dans tous ses éléments et directement applicable dans tout État membre.

Fait à Bruxelles, le 5 août 2022.

Par la Commission

La présidente

Ursula VON DER LEYEN

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

(2) Directive 2005/36/CE du Parlement européen et du Conseil du 7 septembre 2005 relative à la reconnaissance des qualifications professionnelles (JO L 255 du 30.9.2005, p. 22).

(3) Directive 2006/123/CE du Parlement européen et du Conseil du 12 décembre 2006 relative aux services dans le marché intérieur (JO L 376 du 27.12.2006, p. 36).

(4) Directive 2014/24/UE du Parlement européen et du Conseil du 26 février 2014 sur la passation des marchés publics et abrogeant la directive 2004/18/CE (JO L 94 du 28.3.2014, p. 65).

(5) Directive 2014/25/UE du Parlement européen et du Conseil du 26 février 2014 relative à la passation de marchés par des entités opérant dans les secteurs de l’eau, de l’énergie, des transports et des services postaux et abrogeant la directive 2004/17/CE (JO L 94 du 28.3.2014, p. 243).

(6) Règlement d’exécution (UE) 2015/1501 de la Commission du 8 septembre 2015 sur le cadre d’interopérabilité visé à l’article 12, paragraphe 8, du règlement (UE) no 910/2014 du Parlement européen et du Conseil sur l’identification électronique et les services de confiance pour les transactions électroniques au sein du marché intérieur (JO L 235 du 9.9.2015, p. 1).

(7) Réseau des permis de conduire mis en œuvre sur la base de l’article 15 de la directive 2006/126/CE du Parlement européen et du Conseil du 20 décembre 2006 relative au permis de conduire (JO L 403 du 30.12.2006, p. 18).

(8) Traité relatif à un système d’information européen concernant les véhicules et les permis de conduire (EUCARIS), adopté à Luxembourg le 29 juin 2000.

(9) Le groupe d’utilisateurs de l’EMREX (EUG) est un réseau international indépendant qui rassemble divers acteurs intéressés par l’amélioration de la portabilité des données des étudiants; https://emrex.eu/

(10) Règlement (CE) no 987/2009 du Parlement européen et du Conseil du 16 septembre 2009 fixant les modalités d’application du règlement (CE) no 883/2004 portant sur la coordination des systèmes de sécurité sociale (JO L 284 du 30.10.2009, p. 1).

(11) Décision 2009/316/JAI du Conseil du 6 avril 2009 relative à la création du système européen d’information sur les casiers judiciaires (ECRIS), en application de l’article 11 de la décision-cadre 2009/315/JAI (JO L 93 du 7.4.2009, p. 33).

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

(13) Règlement (UE) no 910/2014 du Parlement européen et du Conseil du 23 juillet 2014 sur l’identification électronique et les services de confiance pour les transactions électroniques au sein du marché intérieur et abrogeant la directive 1999/93/CE (JO L 257 du 28.8.2014, p. 73).

(14) Une identité électronique européenne fiable et sécurisée — Recommandation | Façonner l’avenir numérique de l’Europe (europa.eu).

(15) Décision d’exécution (UE) 2015/296 de la Commission du 24 février 2015 établissant les modalités de coopération entre les États membres en matière d’identification électronique conformément à l’article 12, paragraphe 7, du règlement (UE) no 910/2014 du Parlement européen et du Conseil sur l’identification électronique et les services de confiance pour les transactions électroniques au sein du marché intérieur (JO L 53 du 25.2.2015, p. 14).

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

(17) Signée le 6 octobre 2017, https://digital-strategy.ec.europa.eu/en/news/ministerial-declaration-egovernment-tallinn-declaration

(18) Signée le 8 décembre 2020, https://digital-strategy.ec.europa.eu/en/news/berlin-declaration-digital-society-and-value-based-digital-government

(19) Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (règlement général sur la protection des données) (JO L 119 du 4.5.2016, p. 1).

(20) Décision (UE, Euratom) 2017/46 de la Commission du 10 janvier 2017 sur la sécurité des systèmes d’information et de communication au sein de la Commission européenne (JO L 6 du 11.1.2017, p. 40).

(21) Règlement (UE) 2018/1725 du Parlement européen et du Conseil du 23 octobre 2018 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel par les institutions, organes et organismes de l’Union et à la libre circulation de ces données, et abrogeant le règlement (CE) no 45/2001 et la décision no 1247/2002/CE (JO L 295 du 21.11.2018, p. 39).

(22) https://edps.europa.eu/data-protection/our-work/publications/comments/specifications-technical-system-cross-border_fr

6.9.2022

Journal officiel de l’Union européenne

L 231/24

RÈGLEMENT (UE) 2022/1465 DE LA COMMISSION

du 5 septembre 2022

modifiant l’annexe I du règlement (CE) no 1334/2008 du Parlement européen et du Conseil en ce qui concerne certaines substances aromatisantes

(Texte présentant de l’intérêt pour l’EEE)

LA COMMISSION EUROPÉENNE,

vu le traité sur le fonctionnement de l’Union européenne,

vu le règlement (CE) no 1334/2008 du Parlement européen et du Conseil du 16 décembre 2008 relatif aux arômes et à certains ingrédients alimentaires possédant des propriétés aromatisantes qui sont destinés à être utilisés dans et sur les denrées alimentaires et modifiant le règlement (CEE) no 1601/91 du Conseil, les règlements (CE) no 2232/96 et (CE) no 110/2008 et la directive 2000/13/CE (1), et notamment son article 11, paragraphe 3,

vu le règlement (CE) no 1331/2008 du Parlement européen et du Conseil du 16 décembre 2008 établissant une procédure d’autorisation uniforme pour les additifs, enzymes et arômes alimentaires (2), et notamment son article 7, paragraphe 5,

considérant ce qui suit:

(1)	L’annexe I du règlement (CE) no 1334/2008 établit une liste de l’Union des arômes et matériaux de base dont l’utilisation dans et sur les denrées alimentaires est autorisée, et énonce leurs conditions d’utilisation.

(2)	Par son règlement d’exécution (UE) no 872/2012 (3), la Commission a adopté la liste des substances aromatisantes et incorporé cette liste à l’annexe I, partie A, du règlement (CE) no 1334/2008.

(3)	Cette liste peut être mise à jour conformément à la procédure uniforme visée à l’article 3, paragraphe 1, du règlement (CE) no 1331/2008, soit à l’initiative de la Commission, soit à la demande d’un État membre ou d’une partie intéressée.

(4)

La liste de l’Union des arômes et matériaux de base figurant à l’annexe I du règlement (CE) no 1334/2008 contient, entre autres, un certain nombre de substances aromatisantes pour lesquelles, au moment de l’adoption de la liste dans le règlement d’exécution (UE) no 872/2012, l’Autorité européenne de sécurité des aliments (ci-après l’«Autorité») n’avait pas été en mesure d’exclure un problème de sécurité pour la santé du consommateur sur la base des données disponibles et avait donc estimé que des données complémentaires étaient nécessaires pour mener à bien son évaluation. Ces substances ont été inscrites sur la liste de l’Union des substances aromatisantes, mais à la condition que des données relatives à la sécurité répondant aux préoccupations exprimées par l’Autorité soient soumises avant l’expiration des délais spécifiques fixés à l’annexe I, partie A, du règlement (CE) no 1334/2008. Parmi les substances figurant sur la liste de l’Union des arômes et matériaux de base signalées au moyen d’une note de bas de page dans l’attente de la finalisation de leur évaluation par l’Autorité, se trouvaient les cinq substances suivantes relevant de l’évaluation du groupe d’arômes 208 (FGE.208): le p-mentha-1,8-dién-7-ol (no FL 02.060), le myrténol (no FL 02.091), le myrténal (no FL 05.106), l’acétate de p-mentha-1,8-dién-7-yle (no FL 09.278) et l’acétate de myrtényle (no FL 09.302). L’Autorité a sollicité des données scientifiques complémentaires, qui ont été communiquées ultérieurement par les demandeurs.

(5)

Dans son avis scientifique du 24 juin 2015 (4), l’Autorité a évalué les données fournies et a conclu que la substance représentative du groupe, à savoir le p-mentha-1,8-dién-7-al (no FL 05.117) était génotoxique in vivo et que, par conséquent, son utilisation en tant que substance aromatisante posait un problème de sécurité.

(6)	À la suite de cet avis, la Commission a retiré cette substance de la liste de l’Union des arômes à la faveur du règlement (UE) 2015/1760 (5).

(7)	Étant donné que le p-mentha-1,8-dién-7-al (no FL 05.117) est représentatif de quatre autres substances relevant de l’évaluation du groupe d’arômes 208 (FGE.208), la Commission a en outre retiré ces quatre substances de la liste de l’Union au moyen du règlement (UE) 2016/637 de la Commission (6).

(8)

En ce qui concerne le p-mentha-1,8-dién-7-ol (no FL 02.060), le myrténol (no FL 02.091), le myrténal (no FL 05.106), l’acétate de p-mentha-1,8-dién-7-yle (no FL 09.278) et l’acétate de myrtényle (no FL 09.302), les demandeurs pour ces substances ont indiqué avoir lancé des séries spécifiques d’études de toxicité répondant aux préoccupations exprimées à leur sujet dans l’avis de l’Autorité du 24 juin 2015. Les demandeurs se sont engagés à soumettre les nouvelles données sollicitées avant le 30 avril 2016.

(9)

Dans l’attente de l’évaluation de ces substances par l’Autorité, de leur évaluation finale exhaustive dans le cadre de la procédure en groupe de travail de l’Autorité et de l’achèvement de la procédure réglementaire subséquente, la Commission a adopté le règlement (UE) 2016/1244 (7) limitant les utilisations de ces substances aromatisantes, tout en maintenant leur statut de substances en cours d’évaluation.

(10)	Les demandeurs ont présenté des études scientifiques et d’autres données pertinentes pour l’évaluation pour le 30 avril 2016.

(11)

Dans ses avis du 22 mars 2017 (8) et du 11 décembre 2018 (9), l’Autorité a évalué les données communiquées ainsi que d’autres données complémentaires, écarté les préoccupations relatives à la génotoxicité pour ces cinq substances et décidé qu’elles pouvaient être évaluées selon la procédure d’évaluation des substances aromatisantes existantes visée dans le règlement (CE) no 1565/2000 de la Commission (10). À cette fin, l’Autorité a affecté ces cinq substances à l’évaluation du groupe d’arômes 73 (FGE.73). Dans ses avis du 19 septembre 2017 (11) et du 10 décembre 2020 (12), elle a mis à jour les évaluations de ce groupe de substances et a conclu que lesdites substances ne posaient pas de problème de sécurité. Elle a également formulé des recommandations visant à modifier le nom et les spécifications de certaines de ces substances.

(12)

Aux fins du règlement (CE) no 1334/2008, l’Autorité a été amenée à examiner les 20 substances suivantes relevant de l’évaluation du groupe d’aromes 203 (FGE.203 rev.1): déca-2,4-dién-1-ol (no FL 02.139), hepta-2,4-dién-1-ol (no FL 02.153), hexa-2,4-dién-1-ol (no FL 02.162), nona-2,4-dién-1-ol (no FL 02.188), hexa-2(trans),4(trans)-diénal (no FL 05.057), tridéca-2(trans),4(cis),7(cis)-triénal (no FL 05.064), nona-2,4-diénal (no FL 05.071), 2,4-décadiénal (no FL 05.081), hepta-2,4-diénal (no FL 05.084), penta-2,4-diénal (no FL 05.101), undéca-2,4-diénal (no FL 05.108), dodéca-2,4-diénal (no FL 05.125), octa-2(trans),4(trans)-diénal (no FL 05.127), déca-2(trans),4(trans)-diénal (no FL 05.140), déca-2,4,7-triénal (no FL 05.141), nona-2,4,6-triénal (no FL 05.173), 2,4-octadiénal (no FL 05.186), trans,trans-2,4-nonadiénal (no FL 05.194), trans-2,trans-4-undécadiénal (no FL 05.196) et acétate d’hexa-2,4-diényle (no FL 09.573). L’Autorité a sollicité des données scientifiques complémentaires, qui ont été communiquées ultérieurement par les demandeurs.

(13)	Les substances hexa-2(trans),4(trans)-diénal (no FL 05.057) et déca-2(trans),4(trans)-diénal (no FL 05.140) ont été utilisées comme substances représentatives du groupe et des données de toxicité ont été transmises pour ces substances.

(14)

Dans son avis scientifique du 26 mars 2014 (13), l’Autorité a évalué les données communiquées et a conclu qu’elle n’était pas en mesure d’écarter certaines préoccupations en matière de sécurité pour les deux substances représentatives du groupe. Par conséquent, l’Autorité n’a pas pu mener à terme l’évaluation des substances relevant de l’évaluation du groupe d’arômes 203.

(15)	Les demandeurs pour ces substances ont indiqué avoir lancé diverses études de toxicité spécifiques aux substances de ce groupe, répondant aux préoccupations exprimées par l’Autorité dans son avis du 26 mars 2014.

(16)	L’Autorité a demandé des données supplémentaires sur l’identité et la caractérisation, ainsi que des données relatives à la production annuelle et à l’apport alimentaire, afin de permettre une évaluation correcte de l’exposition et d’évaluer de manière exhaustive l’innocuité de ces substances.

(17)

Les demandeurs se sont engagés à soumettre les nouvelles données sollicitées pour le 30 septembre 2016. Dans l’attente de la communication des données complémentaires, de l’évaluation de la génotoxicité de ces substances par l’Autorité, de leur évaluation finale exhaustive dans le cadre de la procédure en groupe de travail de l’Autorité et de l’achèvement de la procédure réglementaire subséquente, la Commission a adopté le règlement (UE) 2017/378 (14) limitant les utilisations de ces substances aromatisantes, tout en maintenant leur statut de substances en cours d’évaluation.

(18)	Les demandeurs ont présenté des études et données scientifiques pertinentes pour l’évaluation pour le 30 septembre 2016.

(19)

Dans son avis du 5 juin 2018 (15), l’Autorité a évalué les données communiquées, écarté les préoccupations relatives à la génotoxicité pour ces substances et décidé qu’elles pouvaient être évaluées selon la procédure d’évaluation des substances aromatisantes existantes visée dans le règlement (CE) no 1565/2000. À cette fin, l’Autorité a affecté seize de ces substances à l’évaluation du groupe d’arômes 70 (FGE.70) et quatre d’entre elles à l’évaluation du groupe d’arômes 05 (FGE.05). Dans ses avis du 5 juin 2019 (16) et du 26 juin 2019 (17), elle a mis à jour les évaluations des substances respectivement dans le cadre de l’évaluation du groupe d’arômes 70, révision 1 (FGE.70 Rev1) et du groupe d’arômes 05, révision 3 (FGE.05 Rev3). En ce qui concerne les seize substances relevant de l’évaluation du groupe d’arômes 70 Rev.1, l’Autorité a conclu qu’elles ne posaient pas de problème de sécurité et a formulé des recommandations visant à modifier le nom et les spécifications de certaines de ces substances. En ce qui concerne les quatre substances relevant de l’évaluation du groupe d’arômes 05 Rev.3, l’Autorité a également conclu qu’elles ne posaient pas de problème de sécurité et a formulé des recommandations visant à modifier le nom et les spécifications de certaines de ces substances.

(20)	Il y a donc lieu de modifier l’annexe I, partie A, du règlement (CE) no 1334/2008 en conséquence.

(21)	Les mesures prévues par le présent règlement sont conformes à l’avis du comité permanent des végétaux, des animaux, des denrées alimentaires et des aliments pour animaux,

A ADOPTÉ LE PRÉSENT RÈGLEMENT:

Article premier

L’annexe I, partie A, du règlement (CE) no 1334/2008 est modifiée conformément à l’annexe du présent règlement.

Article 2

Le présent règlement entre en vigueur le vingtième jour suivant celui de sa publication au Journal officiel de l’Union européenne.

Le présent règlement est obligatoire dans tous ses éléments et directement applicable dans tout État membre.

Fait à Bruxelles, le 5 septembre 2022.

Par la Commission

La présidente

Ursula VON DER LEYEN

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

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

(3) Règlement d’exécution (UE) no 872/2012 de la Commission du 1er octobre 2012 portant adoption de la liste de substances aromatisantes prévue par le règlement (CE) no 2232/96 du Parlement européen et du Conseil, introduction de ladite liste dans l’annexe I du règlement (CE) no 1334/2008 du Parlement européen et du Conseil et abrogation du règlement (CE) no 1565/2000 de la Commission et de la décision 1999/217/CE de la Commission (JO L 267 du 2.10.2012, p. 1).

(4) Avis scientifique sur l’évaluation du groupe d’arômes 208, révision 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», EFSA Journal, 2015, 13(7):4173, 28 p., doi:10.2903/j.efsa.2015.4173. Disponible en ligne à l’adresse suivante: www.efsa.europa.eu/efsajournal

(5) Règlement (UE) 2015/1760 de la Commission du 1er octobre 2015 modifiant l’annexe I du règlement (CE) no 1334/2008 du Parlement européen et du Conseil en ce qui concerne le retrait de la substance aromatisante p-mentha-1,8-dién-7-al de la liste de l’Union (JO L 257 du 2.10.2015, p. 27).

(6) Règlement (UE) 2016/637 de la Commission du 22 avril 2016 modifiant l’annexe I du règlement (CE) no 1334/2008 du Parlement européen et du Conseil en ce qui concerne la suppression de certaines substances aromatisantes de la liste de l’Union (JO L 108 du 23.4.2016, p. 24).

(7) Règlement (UE) 2016/1244 de la Commission du 28 juillet 2016 modifiant l’annexe I du règlement (CE) no 1334/2008 du Parlement européen et du Conseil en ce qui concerne certaines substances aromatisantes appartenant à un groupe à structure alpha, bêta insaturée (JO L 204 du 29.7.2016, p. 7).

(8) Avis scientifique sur l’évaluation du groupe d’arômes 208, révision 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», EFSA Journal, 2017, 15(5):4766, https://doi.org/10.2903/j.efsa.2017.4766

(9) Avis scientifique sur l’évaluation du groupe d’arômes 208, révision 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», EFSA Journal, 2019, 17(1):5569, https://doi.org/10.2903/j.efsa.2019.5569

(10) Règlement (CE) no 1565/2000 de la Commission du 18 juillet 2000 énonçant les mesures nécessaires à l’adoption d’un programme d’évaluation, en application du règlement (CE) no 2232/96 du Parlement européen et du Conseil (JO L 180 du 19.7.2000, p. 8).

(11) Avis scientifique sur l’évaluation du groupe d’arômes 73, révision 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», EFSA Journal, 2017, 15(11):5010, doi: 10.2903/j.efsa.2017.5010. Disponible en ligne à l’adresse suivante: www.efsa.europa.eu/efsajournal

(12) Avis scientifique sur l’évaluation du groupe d’arômes 73, révision 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», EFSA Journal, 2020, 18(1):5970, doi: 10.2903/j.efsa.2020.5970. Disponible en ligne à l’adresse suivante: www.efsa.europa.eu/efsajournal

(13) Avis scientifique sur l’évaluation du groupe d’arômes 203, révision 1 (FGE.203Rev1): Groupe CEF de l’EFSA (groupe scientifique de l’EFSA sur les matériaux en contact avec les aliments, les enzymes, les arômes et les auxiliaires technologiques), 2014. Avis scientifique sur l’évaluation du groupe d’arômes 203, révision 1 (FGE.203 Rev1): «α,β-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», EFSA Journal, 2014, 12(4):3626, 31 p., doi:10.2903/j.efsa.2014.3626. Disponible en ligne à l’adresse suivante: www.efsa.europa.eu/efsajournal

(14) Règlement (UE) 2017/378 de la Commission du 3 mars 2017 modifiant l’annexe I du règlement (CE) no 1334/2008 du Parlement européen et du Conseil en ce qui concerne certaines substances aromatisantes (JO L 58 du 4.3.2017, p. 14).

(15) Avis scientifique sur l’évaluation du groupe d’arômes 203, révision 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», EFSA Journal, 2018, 16(7):5322.

(16) Avis scientifique sur l’évaluation du groupe d’arômes 70, révision 1 (FGE.70Rev1): «consideration of aliphatic, linear, α,β-unsaturated, di- and trienals and related alcohols, acids and esters evaluated by JECFA (61st-68th-69th meeting)», EFSA Journal, 2019, 17(7):5749.

(17) Avis scientifique sur l’évaluation du groupe d’arômes 5, révision 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 et 15», EFSA Journal, 2019, 17(8):5761.

ANNEXE

À l’annexe I du règlement (CE) no 1334/2008, le tableau 1 figurant dans la partie A, section 2, est modifié comme suit:

l’inscription relative à la substance no FL 02.060 est remplacée par le texte suivant:

«02.060

p-Mentha-1,8-dién-7-ol

536-59-4

974

2024

EFSA»;

l’inscription relative à la substance no FL 02.091 est remplacée par le texte suivant:

«02.091

Myrténol

515-00-4

981

10285

EFSA»;

l’inscription relative à la substance no FL 02.139 est remplacée par le texte suivant:

«02.139

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

18409-21-7

1189

11748

EFSA»;

l’inscription relative à la substance no FL 02.153 est remplacée par le texte suivant:

«02.153

Hepta-2,4-dien-1-ol

33467-79-7

1784

EFSA»;

l’inscription relative à la substance no FL 02.162 est remplacée par le texte suivant:

«02.162

Hexa-2,4-dien-1-ol

111-28-4

1174

EFSA»;

l’inscription relative à la substance no FL 02.188 est remplacée par le texte suivant:

«02.188

Nona-2,4-dien-1-ol

62488-56-6

1183

11802

Au moins 92 %; composant secondaire: 3-4 % de 2-nonén-1-ol

EFSA»;

l’inscription relative à la substance no FL 05.057 est remplacée par le texte suivant:

«05.057

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

142-83-6

1175

640

EFSA»;

l’inscription relative à la substance no FL 05.064 est remplacée par le texte suivant:

«05.064

Tridéca-2(trans),4(cis),7(cis)-trienal

13552-96-0

1198

685

Au moins 71 %; composants secondaires: 14 % de 4-cis-7-cis-tridécadiénol, 6 % de 3-cis-7-cis-tridécadiénol, 5 % de 2-trans-7-cis-tridécadiénal et 3 % de 2-trans-4-trans-7-cis-tridécatriénal

EFSA»;

l’inscription relative à la substance no FL 05.071 est remplacée par le texte suivant:

«05.071

Nona-2,4-dienal

6750-03-4

1185

732

Au moins 89 %; composants secondaires: 5-6 % de 2,4-nonadién-1-ol et 1-2 % de 2-nonén-1-ol

EFSA»;

l’inscription relative à la substance no FL 05.081 est remplacée par le texte suivant:

«05.081

2,4-Decadienal

2363-88-4

3135

2120

Au moins 89 %; composants secondaires: mélange des (cis, cis)-2,4-décadiénal, (cis, trans)-2,4-décadiénal et (trans, cis)-2,4-décadiénal (somme de tous les isomères: 95 %), acétone et isopropanol

EFSA»;

l’inscription relative à la substance no FL 05.084 est remplacée par le texte suivant:

«05.084

Hepta-(2E,4E)-dienal

4313-03-5

1179

729

Au moins 92 %; composants secondaires: 2-4 % de (E,Z)-2,4-heptadiénal et 2-4 % d’acide 2,4-heptadiénoïque

EFSA»;

l’inscription relative à la substance no FL 05.101 est remplacée par le texte suivant:

«05.101

Penta-2,4-dienal

764-40-9

1173

11695

EFSA»;

l’inscription relative à la substance no FL 05.106 est remplacée par le texte suivant:

«05.106

Myrténal

564-94-3

980

10379

EFSA»;

l’inscription relative à la substance no FL 05.108 est remplacée par le texte suivant:

«05.108

Undeca-2,4-dienal

13162-46-4

1195

10385

EFSA»;

l’inscription relative à la substance no FL 05.125 est remplacée par le texte suivant:

«05.125

Dodeca-(2E,4E)-dienal

21662-16-8

1196

11758

Au moins 85 %; composant secondaire: 11-12 % d’isomère 2-trans-4-cis

EFSA»;

l’inscription relative à la substance no FL 05.127 est remplacée par le texte suivant:

«05.127

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

30361-28-5

1181

11805

EFSA»;

l’inscription relative à la substance no FL 05.140 est remplacée par le texte suivant:

«05.140

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

25152-84-5

1190

2120

Au moins 90 % de l’isomère (E,E); 95 % (somme des isomères)

EFSA»;

l’inscription relative à la substance no FL 05.141 est remplacée par le texte suivant:

«05.141

Deca-2,4,7-trienal

51325-37-2

1786

EFSA»;

l’inscription relative à la substance no FL 05.173 est remplacée par le texte suivant:

«05.173

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

57018-53-8

1785

EFSA»;

l’inscription relative à la substance no FL 05.186 est remplacée par le texte suivant:

«05.186

2,4-Octadienal

5577-44-6

11805

Au moins 85 % de E,E avec 10 % de E,Z

EFSA»;

l’inscription relative à la substance no FL 05.194 est remplacée par le texte suivant:

«05.194

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

5910-87-2

732

Au moins 89 %; composants secondaires: au moins 5 % de 2,4-nonadién-1-ol et 2-nonén-1-ol et autres isomères du 2,4-nonadiénal

EFSA»;

l’inscription relative à la substance no FL 05.196 est remplacée par le texte suivant:

«05.196

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

EFSA»;

l’inscription relative à la substance no FL 09.278 est remplacée par le texte suivant:

«09.278

Acétate de p-mentha-1,8-diène-7-yle

15111-96-3

975

10742

EFSA»;

l’inscription relative à la substance no FL 09.302 est remplacée par le texte suivant:

«09.302

Acétate de myrtényle

35670-93-0

982

10887

EFSA»;

l’inscription relative à la substance no FL 09.573 est remplacée par le texte suivant:

«09.573

Acétate d’hexa-2,4-diényle

1516-17-2

1780

10675

EFSA».

6.9.2022

Journal officiel de l’Union européenne

L 231/36

RÈGLEMENT D’EXÉCUTION (UE) 2022/1467 DE LA COMMISSION

du 5 septembre 2022

modifiant le règlement d’exécution (UE) 2015/2378 en ce qui concerne les formulaires types et les formats informatisés à utiliser en relation avec la directive 2011/16/UE du Conseil et la liste des données statistiques à fournir par les États membres aux fins de l’évaluation de ladite directive

LA COMMISSION EUROPÉENNE,

vu le traité sur le fonctionnement de l’Union européenne,

vu la directive 2011/16/UE du Conseil du 15 février 2011 relative à la coopération administrative dans le domaine fiscal et abrogeant la directive 77/779/CEE (1), et notamment son article 20, paragraphe 4,

considérant ce qui suit:

(1)

La directive 2011/16/UE a été modifiée par la directive (UE) 2021/514 (2) afin d’améliorer les dispositions relatives à toutes les formes d’échange d’informations et de coopération administrative en prévoyant un échange automatique et obligatoire des informations déclarées par les opérateurs de plateformes.

(2)	Il convient dès lors d’adapter le règlement d’exécution (UE) 2015/2378 de la Commission (3) à ces modifications. L’échange automatique d’informations au titre de l’article 8 bis quater, paragraphe 2, de la directive 2011/16/UE devrait être effectué au moyen d’un format informatique standard.

(3)	Conformément à la directive 2011/16/UE, il est également nécessaire d’arrêter les modalités pratiques de l’enregistrement et de l’identification de certains opérateurs de plateformes déclarants en application de l’article 8 bis quater, paragraphe 4.

(4)

En application de l’article 8 bis quater, paragraphe 6, de la directive 2011/16/UE, il convient d’établir un registre central afin de consigner les informations à fournir conformément à l’article 8 bis quater, paragraphe 5, et à communiquer conformément à l’annexe V, section IV, points F 2) et F 4). Ce registre central devrait être mis à la disposition des autorités compétentes des États membres. Il convient d’utiliser un formulaire type pour la communication et l’enregistrement de ces informations.

(5)

L’article 23, paragraphe 4, de la directive 2011/16/UE prévoit une liste de données statistiques à fournir par les États membres aux fins de l’évaluation de ladite directive. Pour des raisons de cohérence et de sécurité juridique, il convient d’aligner la date d’application du présent règlement sur celle prévue à l’article 2, paragraphe 1, deuxième alinéa, de la directive (UE) 2021/514.

(6)	Le Contrôleur européen de la protection des données a été consulté sur les mesures prévues au présent règlement conformément à l’article 42, paragraphe 1, du règlement (UE) 2018/1725 du Parlement européen et du Conseil (4).

(7)	Les mesures prévues au présent règlement sont conformes à l’avis du comité de la coopération administrative en matière fiscale,

A ADOPTÉ LE PRÉSENT RÈGLEMENT:

Article premier

Le règlement d’exécution (UE) 2015/2378 est modifié comme suit:

1)	à l’article 2, le paragraphe 3 suivant est ajouté: «3. Le format informatique à utiliser pour l’échange automatique et obligatoire d’informations au titre de l’article 8 bis quater, paragraphe 2, de la directive 2011/16/UE est conforme au format figurant à l’annexe XIV du présent règlement.»;

2)	à l’article 2 quinquies, paragraphe 1, l’alinéa suivant est ajouté: «La liste des données statistiques requises pour l’échange automatique et obligatoire d’informations au titre de l’article 8 bis quater, de la directive 2011/16/UE figure à l’annexe XV du présent règlement.»;

l’article 2 septies suivant est ajouté:

«Article 2 septies

Formulaires types pour la communication d’informations sur les opérateurs de plateforme exclus et les opérateurs de plateformes étrangers au registre central, format du numéro d’identification individuel des opérateurs de plateforme étrangers et période de conservation des informations supprimées du registre central

1. Le formulaire à utiliser pour la communication d’informations sur les opérateurs de plateformes exclus et les opérateurs de plateformes étrangers au registre central conformément à l’article 8 bis quater, paragraphe 6, de la directive 2011/16/UE est conforme à l’annexe XVI du présent règlement.

2. Les éléments clés à enregistrer dans le registre central, conformément à l’article 8 bis quater, paragraphe 6, de la directive 2011/16/UE, sont les informations énumérées à l’annexe V, section IV, points F 2) et F 4), de ladite directive et à l’annexe XVI du présent règlement. L’établissement du registre central et le traitement des données à caractère personnel effectué dans le registre central par la Commission pour le compte des autorités compétentes des États membres sont conformes au règlement (UE) 2016/679 du Parlement européen et du Conseil (*1) et au règlement (UE) 2018/1725 du Parlement européen et du Conseil (*2). Les autorités compétentes des États membres sont considérées comme des responsables du traitement et la Commission est considérée comme un sous-traitant conformément au règlement (UE) 2016/679.

3. Le format du numéro d’identification individuel des opérateurs de plateformes étrangers au sens de l’article 8 bis quater, paragraphe 4, de la directive 2011/16/UE est défini à l’annexe XVI du présent règlement.

4. La période de conservation des informations supprimées du registre central, conformément à l’annexe V, section IV, point F 5), sous d), et à l’article 8 bis quater, paragraphe 5, de la directive 2011/16/UE, est fixée à l’annexe XVI du présent règlement.»;

(*1) Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (règlement général sur la protection des données) (JO L 119 du 4.5.2016, p. 1)."

(*2) Règlement (UE) 2018/1725 du Parlement européen et du Conseil du 23 octobre 2018 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel par les institutions, organes et organismes de l’Union et à la libre circulation de ces données, et abrogeant le règlement (CE) no 45/2001 et la décision no 1247/2002/CE (JO L 295 du 21.11.2018, p. 39)."

4)	les annexes I, IX et X sont remplacées par le texte figurant à l’annexe I du présent règlement;

5)	l’annexe V est modifiée conformément à l’annexe II du présent règlement;

6)	les annexes XIV, XV et XVI, telles qu’elles figurent à l’annexe III du présent règlement, sont ajoutées.

Article 2

Le présent règlement entre en vigueur le vingtième jour suivant celui de sa publication au Journal officiel de l’Union européenne.

Il est applicable à partir du 1er janvier 2023.

Le présent règlement est obligatoire dans tous ses éléments et directement applicable dans tout État membre.

Fait à Bruxelles, le 5 septembre 2022.

Par la Commission

La présidente

Ursula VON DER LEYEN

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

(2) Directive (UE) 2021/514 du Conseil du 22 mars 2021 modifiant la directive 2011/16/UE relative à la coopération administrative dans le domaine fiscal (JO L 104 du 25.3.2021, p. 1).

(3) Règlement d’exécution (UE) 2015/2378 de la Commission du 15 décembre 2015 établissant les modalités d’application de certaines dispositions de la directive 2011/16/UE du Conseil relative à la coopération administrative dans le domaine fiscal et abrogeant le règlement d’exécution (UE) no 1156/2012 (JO L 332 du 18.12.2015, p. 1).

(4) Règlement (UE) 2018/1725 du Parlement européen et du Conseil du 23 octobre 2018 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel par les institutions, organes et organismes de l’Union et à la libre circulation de ces données, et abrogeant le règlement (CE) no 45/2001 et la décision no 1247/2002/CE (JO L 295 du 21.11.2018, p. 39).

ANNEXE I

Les annexes I, IX et X sont remplacées par le texte suivant:

«ANNEXE I

Formulaire visé à l'article 1er, paragraphe 2

Le formulaire à utiliser pour les demandes d'informations et d'enquêtes administratives introduites en vertu de l'article 5 et de l'article 5 bis de la directive 2011/16/UE, ainsi que pour les réponses correspondantes, les accusés de réception, les demandes de renseignements à caractère général et les déclarations d'incapacité ou de refus au titre de l'article 7 de ladite directive comporte les champs suivants (1):

—	base juridique,

—	numéro de référence,

—

date,

—	identité des autorités requérantes et requises,

—	identité de la personne faisant l'objet d'un contrôle ou d'une enquête,

—

description générale du cas et, le cas échéant, renseignements spécifiques qui pourraient permettre d'évaluer la pertinence vraisemblable des informations demandées à l'administration et l'application du droit national des États membres en ce qui concerne les taxes et impôts visés à l'article 2 de la directive 2011/16/UE,

—	finalité fiscale des informations demandées,

—	période faisant l'objet de l'enquête,

—	nom et adresse de toute personne dont il y a lieu de penser qu'elle est en possession des informations demandées,

—	respect des obligations juridiques définies à l'article 16, paragraphe 1, de la directive 2011/16/UE,

—	respect des obligations juridiques définies à l'article 17, paragraphe 1, de la directive 2011/16/UE,

—	demande motivée portant sur une enquête administrative et motifs du refus de mener l'enquête administrative demandée,

—	accusé de réception de la demande d'informations,

—	demande d'autres renseignements de caractère général,

—	motifs des déclarations d'incapacité ou de refus concernant la communication d'informations,

—	motifs du non-respect du délai de réponse imparti et date pour laquelle l'autorité requise estime pouvoir répondre,

—	description détaillée du groupe.

«ANNEXE IX

Liste visée à l'article 2 quinquies

Les données statistiques requises pour les formes de coopération administrative autres que l'échange automatique et obligatoire d'informations visées à l'article 23, paragraphe 4, de la directive 2011/16/UE, couvrent les informations suivantes:

—	identification de l'État membre,

—

année,

—

partie A: statistiques par État membre en ce qui concerne l’échange d’informations

—

sur l'échange d'informations sur demande (articles 5, 6 et 7 de la directive 2011/16/UE),

—	nombre de demandes envoyées,

—	nombre de réponses reçues,

—	nombre de réponses complètes reçues dans le délai légal,

—	nombre de réponses pour lesquelles l'ensemble des informations ou une partie d'entre elles ont été reçues dans un délai de deux mois,

—	nombre de demandes reçues,

—	nombre de réponses envoyées,

—	nombre de refus fondés sur l'article 17 de la directive 2011/16/UE,

—

sur l'échange d'informations sur demande concernant le groupe (articles 5 bis de la directive 2011/16/UE),

—	nombre de demandes envoyées concernant le groupe,

—	nombre de réponses reçues concernant le groupe,

—	nombre de réponses complètes reçues concernant le groupe dans le délai légal,

—	nombre de réponses concernant le groupe pour lesquelles l'ensemble des informations ou une partie d'entre elles ont été reçues dans un délai de deux mois,

—	nombre de demandes reçues concernant le groupe,

—	nombre de réponses envoyées concernant le groupe,

—	nombre de refus concernant le groupe fondés sur l'article 17 de la directive 2011/16/UE,

—

sur l'échange spontané d'informations (articles 9 et 10 de la directive 2011/16/UE),

—	nombre d'échanges spontanés envoyés,

—	nombre d'échanges spontanés reçus,

—

partie B: statistiques relatives à d'autres formes de coopération administrative

—

sur la présence dans les bureaux administratifs et sur la participation aux enquêtes administratives (article 11 de la directive 2011/16/UE),

—	nombre de présences entrantes dans les bureaux administratifs et de participations aux enquêtes administratives,

—	nombre de présences sortantes dans les bureaux administratifs et de participations aux enquêtes administratives,

—

sur les contrôles simultanés (article 12 de la directive 2011/16/UE),

—	nombre de contrôles simultanés menés à l'initiative de l'État membre,

—	nombre de contrôles simultanés auxquels l'État membre a participé,

—

sur les demandes de notification (article 13 de la directive 2011/16/UE),

—	nombre de demandes de notification envoyées,

—	nombre de demandes de notification reçues,

—

sur le retour d'informations (article 14 de la directive 2011/16/UE),

—	nombre de demandes de retours d'informations envoyées,

—	nombre de retours d'informations reçus,

—	nombre de demandes de retours d'informations reçues,

—	nombre de retours d'informations envoyés,

—

partie C: statistiques relatives à l'estimation des recettes supplémentaires ou à l'augmentation de la taxe établie suite à la coopération administrative. Les informations figurant dans cette partie sont facultatives

—	résultant de l'échange d'informations sur demande,

—	résultant de l'échange spontané d'informations,

—	résultant des contrôles simultanés,

—	chiffre global et nombre de cas.

«ANNEXE X

Liste visée à l'article 2 quinquies

Les données statistiques requises pour l'échange automatique et obligatoire d'informations visées à l'article 23, paragraphe 4, de la directive 2011/16/UE, concernant les catégories de revenu et de capital visées à l'article 8, paragraphe 1, de ladite directive couvrent les informations suivantes:

—	pour toutes les catégories de revenu et de capital visées à l'article 8, paragraphe 1, de la directive 2011/16/UE: des statistiques relatives au message et au contribuable,

—	dans le cas de revenus d'emploi et de tantièmes et jetons de présence: statistiques sur le message et le bénéficiaire, le message et le payeur, le bénéficiaire et la relation, le payeur et la relation, le bénéficiaire et le revenu,

—	dans le cas de pensions: statistiques sur le message et le bénéficiaire, le message et le payeur, le bénéficiaire, le payeur, le régime, le revenu,

—	dans le cas de produits d'assurance sur la vie: statistiques sur le message et la police, la police générale, l'événement,

—	dans le cas de propriété et de revenus de biens immobiliers: statistiques sur le message et les parties, parties en général, nombre et valeur des propriétés, nombre et valeur des transactions, nombre et valeurs des emprunts, quantité et valeur des revenus issus de droits,

—	dans le cas de revenus générés par les redevances: statistiques sur le message et le bénéficiaire, le message et le payeur, le bénéficiaire et le revenu,

—	dans le cas de message sur le statut: des statistiques relatives aux messages sur le statut, erreurs concernant ces messages,

—	dans le cas de messages ne contenant aucune donnée: statistiques relatives aux messages ne contenant aucune donnée.

(1) Cependant, seuls les champs effectivement complétés dans un cas précis doivent apparaître sur le formulaire utilisé pour ce cas.

ANNEXE II

Le titre du point b) de l'annexe V est remplacé par le texte suivant:

«b)	en ce qui concerne le corps destiné à communiquer des informations sur des revenus d'emploi, tantièmes et jetons de présence ou des redevances:»

ANNEXE III

Les annexes XIV, XV et XVI suivantes sont ajoutées:

«ANNEXE XIV

Format informatique visé à l'article 2, paragraphe 3

Le format informatique à utiliser pour l'échange automatique et obligatoire d'informations en vertu de l'article 8 bis quater, paragraphe 2, de la directive 2011/16/UE est conforme à la structure arborescente ci-après et contient les éléments et attributs suivants (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>

»;

«ANNEXE XV

Liste visée à l'article 2 quinquies

Les données statistiques requises pour l'échange obligatoire d'informations visées à l'article 8 bis quater, paragraphe 2, de la directive 2011/16/UE, conformément à l'article 23, paragraphe 4, de ladite directive couvrent les informations suivantes:

—	par message, statistiques sur le nombre total de rapports reçus des opérateurs de plateformes déclarants pour l’échange automatique et obligatoire d’informations,

—	par message, statistiques sur le nombre total de rapports reçus de chaque autre État membre,

—

par vendeur à déclarer, statistiques sur le type de vendeur à déclarer, le numéro d’identification du contribuable ou son équivalent fonctionnel, l'État membre de résidence du vendeur à déclarer et le motif de l’échange, l'État membre de résidence du vendeur à déclarer et/ou l'État membre dans lequel le bien immobilier est situé,

—	par opérateur de plateforme déclarant, statistiques sur le type d’activité concerné et la contrepartie et le type correspondant au lot.

»;

«ANNEXE XVI

Formulaire visé à l'article 2 septies, paragraphe 1

Le formulaire à utiliser pour la communication d’informations sur les opérateurs de plateformes exclus conformément à l’article 8 bis quater, paragraphe 6, de la directive 2011/16/UE et pour la communication d’informations sur les opérateurs de plateformes étrangers conformément à l’annexe V, section IV, points F 2) et F 4), de la directive 2011/16/UE contient les champs suivants:

(a)	nom de l’opérateur de plateforme exclu

(b)	adresse postale de l’opérateur de plateforme exclu

(c)	adresse électronique, y compris les sites internet de l’opérateur de plateforme exclu

(d)	tout NIF délivré à l’opérateur de plateforme exclu, s’il est disponible

(e)	l'État membre dans lequel la démonstration visée à l’annexe V, section I, point A 3), de la directive 2011/16/UE a été faite et

(f)	exercice fiscal à partir duquel le statut d’opérateur de plateforme exclu a été accordé.

Format du numéro d’identification individuel pour les opérateurs de plateformes étrangers

Le numéro d’identification individuel est composé de 12 chiffres, selon le format CPAAAAXXXXXX, où: CP est le code pays ISO de l'État membre qui délivre le numéro d'identification individuel, AAAA est l'année pendant laquelle l'opérateur de plateforme étranger s'enregistre auprès de l'État membre d'enregistrement unique, et XXXXXX est une chaîne unique de caractères composée de lettres et/ou de chiffres.

Période de conservation de certaines informations supprimées ou radiées du registre central

Lorsque l’enregistrement d’un opérateur de plateforme déclarant au sens de l’annexe V, section I, point A 4), sous b), de la directive 2011/16/UE, telle que modifiée par la directive (UE) 2021/514, est révoqué conformément à l’annexe V, section IV, point F 7), de la directive 2011/16/UE, l’État membre d’enregistrement unique supprime l’opérateur de plateforme déclarant du registre central. Le registre central conserve les informations supprimées visées à l’annexe V, section IV, points F 2) et F 4), de la directive 2011/16/UE pendant une durée maximale de 12 mois à compter de la date de la suppression.

Les informations enregistrées dans le registre central des opérateurs de plateforme exclus seront supprimées lorsqu’un opérateur de plateforme exclu au sens de l’annexe V, section I, point A 3), de la directive 2011/16/UE, telle que modifiée par la directive (UE) 2021/514, ne démontre pas d'avance et sur une base annuelle que l’ensemble du modèle commercial de ladite plateforme est tel qu’il ne compte aucun vendeur à déclarer, et ce à la satisfaction de l’autorité compétente de l’État membre auquel, conformément aux règles énoncées à l’annexe V, section III, points A 1) à A 3), de la directive 2011/16/UE, l’opérateur de plateforme aurait dû communiquer des informations. Le registre central conserve les informations supprimées visées à l’annexe XVI, points a) à f), du présent règlement pendant une durée maximale de 12 mois à compter de la date de suppression des informations enregistrées.

(1) Cependant, seuls les éléments et attributs effectivement applicables dans un cas donné en vertu des règles de diligence raisonnable et de déclaration énoncées dans la section II et la section III de l'annexe V de la directive 2011/16/UE du Conseil, telle que modifiée par la directive (UE) 2021/514 du Conseil, doivent figurer dans le format informatique utilisé pour ce cas.

		ISSN 1977-0693
Journal officiel de l’Union européenne		L 231

Édition de langue française	Législation	65e année 6 septembre 2022

Sommaire		II Actes non législatifs	page
		RÈGLEMENTS
	*	Règlement d’exécution (UE) 2022/1463 de la Commission du 5 août 2022 établissant les spécifications techniques et opérationnelles du système technique pour l’échange transfrontière automatisé de justificatifs et l’application du principe une fois pour toutes conformément au règlement (UE) 2018/1724 du Parlement européen et du Conseil ( 1 )	1
	*	Règlement d’exécution (UE) 2022/1464 de la Commission du 2 septembre 2022 modifiant le règlement (CE) no 1210/2003 du Conseil concernant certaines restrictions spécifiques applicables aux relations économiques et financières avec l’Iraq	22
	*	Règlement (UE) 2022/1465 de la Commission du 5 septembre 2022 modifiant l’annexe I du règlement (CE) no 1334/2008 du Parlement européen et du Conseil en ce qui concerne certaines substances aromatisantes ( 1 )	24
	*	Règlement (UE) 2022/1466 de la Commission du 5 septembre 2022 modifiant l’annexe I du règlement (CE) no 1334/2008 du Parlement européen et du Conseil en ce qui concerne la suppression de certaines substances aromatisantes de la liste de l’Union ( 1 )	32
	*	Règlement d’exécution (UE) 2022/1467 de la Commission du 5 septembre 2022 modifiant le règlement d’exécution (UE) 2015/2378 en ce qui concerne les formulaires types et les formats informatisés à utiliser en relation avec la directive 2011/16/UE du Conseil et la liste des données statistiques à fournir par les États membres aux fins de l’évaluation de ladite directive	36
	*	Règlement d’exécution (UE) 2022/1468 de la Commission du 5 septembre 2022 modifiant le règlement d’exécution (UE) no 540/2011 en ce qui concerne les conditions d’approbation de la substance active penflufène et abrogeant le règlement d’exécution (UE) 2018/185 ( 1 )	101
	*	Règlement d’exécution (UE) 2022/1469 de la Commission du 5 septembre 2022 concernant l’autorisation du sulfate de L-lysine produit par Escherichia coli CGMCC 7.398 en tant qu’additif dans l’alimentation de toutes les espèces animales ( 1 )	105
	*	Règlement d’exécution (UE) 2022/1470 de la Commission du 5 septembre 2022 concernant l’autorisation de l’endo-1,4-β-xylanase produite par Trichoderma longibrachiatum CBS 139997 et de l’α-galactosidase produite par Aspergillus tubingensis ATCC SD 6740 en tant qu’additif pour l’alimentation des poulets d’engraissement, des poulettes destinées à la ponte, des espèces aviaires mineures destinées à l’engraissement ou élevées pour la ponte, et des oiseaux d’ornement (titulaire de l’autorisation: Industrial Técnica Pecuaria S.A.) ( 1 )	109
	*	Règlement d’exécution (UE) 2022/1471 de la Commission du 5 septembre 2022 concernant l’autorisation du carbonate de lanthane octahydraté en tant qu’additif dans l’alimentation des chats (titulaire de l’autorisation: Porus GmbH) ( 1 )	113
	*	Règlement d’exécution (UE) 2022/1472 de la Commission du 5 septembre 2022 concernant l’autorisation du sulfate-lysinate de manganèse en tant qu’additif destiné à l’alimentation de toutes les espèces animales ( 1 )	116

«07.030	1-(4-méthoxyphényl)pent-1-én-3-one	104-27-8	826	164		2	EFSA
07.046	vanillylidèneacétone	1080-12-2	732	691		2	EFSA
07.049	1-(4-méthoxyphényl)-4-méthylpent-1-én-3-one	103-13-9	829	719		2	EFSA
07.206	4-(2,3,6-triméthylphényl)but-3-én-2-one	56681-06-2				2	EFSA
07.258	6-méthyl-3-heptén-2-one	2009-74-7				1	EFSA
10.034	5,6-dihydro-3,6-diméthylbenzofuran-2(4H)-one	80417-97-6	1163			2	EFSA
10.036	5,6,7,7a-tétrahydro-3,6-diméthylbenzofuran-2(4H)-one	13341-72-5	1162			2	EFSA
10.042	3,4-diméthyl-5-pentylidènefuran-2(5H)-one	774-64-1		11873	Au moins 93 %; composant secondaire: 1-2 % de gamma-lactone de l’acide 3,4-diméthyl-5-cétobutanoïque	2	EFSA
10.043	2,7-diméthylocta-5(trans),7-diéno-1,4-lactone	78548-56-8				2	EFSA
10.046	hex-2-éno-1,4-lactone	2407-43-4				2	EFSA
10.054	non-2-éno-1,4-lactone	21963-26-8				2	EFSA
10.060	2-décéno-1,4-lactone	2518-53-8				2	EFSA
10.170	5-pentyl-3H-furan-2-one	51352-68-2	1989		Mélange d’isomères 3H- et 5H- (2:1)	2	EFSA
13.004	2-furoate d’allyle	4208-49-5	21	360		2	EFSA
13.034	3-(2-furyl)acrylaldéhyde	623-30-3	1497			1	EFSA
13.043	furfurylidène-2-butanal	770-27-4	1501	11885		1	EFSA
13.044	4-(2-furyl)but-3-én-2-one	623-15-4	1511	11838		1	EFSA
13.046	3-(2-furyl)-2-méthylprop-2-énal	874-66-8	1498	11878		1	EFSA
13.066	3-acétyl-2,5-diméthylfurane	10599-70-9	1506	10921		4	EFSA
13.103	2-butylfurane	4466-24-4	1490	10927		3	EFSA
13.137	3-(2-furyl)-2-phénylprop-2-énal	65545-81-5	1502	11928		1	EFSA
13.150	3-(5-méthyl-2-furyl)prop-2-énal	5555-90-8	1499			1	EFSA»