6.9.2022

Den Europæiske Unions Tidende

L 231/1

KOMMISSIONENS GENNEMFØRELSESFORORDNING (EU) 2022/1463

af 5. august 2022

om fastsættelse af tekniske og operationelle specifikationer for det tekniske system til grænseoverskridende elektronisk udveksling af dokumentation og anvendelse af engangsprincippet i overensstemmelse med Europa-Parlamentets og Rådets forordning (EU) 2018/1724

(EØS-relevant tekst)

EUROPA-KOMMISSIONEN HAR —

under henvisning til traktaten om Den Europæiske Unions funktionsmåde,

under henvisning til Europa-Parlamentets og Rådets forordning (EU) 2018/1724 af 2. oktober 2018 om oprettelse af en fælles digital portal, der giver adgang til oplysninger, procedurer og bistands- og problemløsningstjenester, og om ændring af forordning (EU) nr. 1024/2012 (1), særlig artikel 14, stk. 9, og

ud fra følgende betragtninger:

(1)

I artikel 14, stk. 1, i forordning (EU) 2018/1724 pålægges Kommissionen i samarbejde med medlemsstaterne at etablere et teknisk system til elektronisk udveksling af oplysninger, som der kræves ved de online procedurer, der er opført i bilag II til nævnte forordning, og de procedurer, der er fastsat i Europa-Parlamentets og Rådets direktiv 2005/36/EF (2), 2006/123/EF (3), 2014/24/EU (4) og 2014/25/EU (5).

(2)

De tekniske og operationelle specifikationer for det tekniske engangssystem (OOTS), der er indeholdt i denne forordning, bør fastlægge de vigtigste komponenter i OOTS' arkitektur, definere de tekniske og operationelle roller og forpligtelser, som Kommissionen, medlemsstaterne, dokumentationsansøgerne, dokumentationsudbyderne og formidlingsplatformene har. Ved disse specifikationer bør der desuden oprettes et logsystem med henblik på at overvåge udvekslingerne og afgrænse ansvaret for vedligeholdelse, drift og sikkerhed af OOTS.

(3)

For at gøre det muligt at oprette OOTS inden den dato, der er fastsat i forordning (EU) 2018/1724, påtænkes det at supplere denne forordning med mere detaljerede, ikkebindende dokumenter vedrørende teknisk udformning, der udarbejdes ved konsensus af Kommissionen i samarbejde med medlemsstaterne i portalkoordinationsgruppen og i overensstemmelse med Kommissionens retningslinjer for gennemførelsen af arbejdsprogrammet for 2021-2022 for forordningen om den fælles digitale portal. Hvis det anses for nødvendigt i lyset af nye tekniske udviklinger eller drøftelser eller meningsforskelle i portalkoordinationsgruppen, navnlig om færdiggørelsen af dokumenterne vedrørende teknisk udformning og større valg angående udformning, eller når der opstår behov for at gøre visse elementer i dokumenterne om teknisk udformning bindende, vil det dog være muligt at supplere/ændre de tekniske og operationelle specifikationer, der er fastsat i denne forordning, i overensstemmelse med undersøgelsesproceduren i artikel 37, stk. 2, i forordning (EU) 2018/1724.

(4)

For at reducere omkostningerne og den tid, der er nødvendig for at oprette OOTS, bør OOTS' arkitektur så vidt muligt være baseret på genanvendelige løsninger, være teknologineutral og tage højde for forskellige nationale løsninger. OOTS bør f.eks. kunne anvende de eksisterende nationale, herunder centrale, regionale og lokale, procedureportaler, datatjenester eller formidlingsplatforme, der er oprettet til national brug. De komponenter, som Kommissionen har udviklet, bør frigives i henhold til en åben softwarelicens, der fremmer genbrug og samarbejde.

(5)

En af disse genanvendelige løsninger, der er udviklet på EU-plan, er systemet med eIDAS-knudepunkter som fastsat i Kommissionens gennemførelsesforordning (EU) 2015/1501 (6), som ved at muliggøre kommunikation med andre knudepunkter i eIDAS-netværket kan behandle anmodningen om og leveringen af grænseoverskridende autentifikation af en bruger. eIDAS-knudepunkterne bør gøre det muligt for dokumentationsansøgere og, hvor det er relevant, dokumentationsudbydere at identificere brugere, der anmoder om udveksling af dokumentation via OOTS, således at dokumentationsudbyderne kan matche identifikationsdataene med deres eksisterende registreringer.

(6)

OOTS bør bygge på det arbejde, der allerede er udført, og udnytte synergier med andre eksisterende systemer til udveksling af dokumentation eller oplysninger mellem myndigheder, der er relevante for de procedurer, der er omhandlet i artikel 14, stk. 1, i forordning (EU) 2018/1724, herunder systemer, der ikke er omfattet af artikel 14, stk. 10, i nævnte forordning. For så vidt angår data fra køretøjs- og kørekortregistre bør OOTS f.eks. tage hensyn til allerede udviklede datamodeller og, hvor det er muligt, etablere tekniske broer for at lette forbindelsen mellem kompetente myndigheder, der allerede anvender andre eksisterende netværk (RESPER (7) eller Eucaris (8)) til OOTS med henblik på tilvejebringelse af dokumentation i de procedurer, der er omfattet af OOTS. En lignende tilgang bør anvendes i forbindelse med andre systemer såsom, men ikke begrænset til: EMREX User Group (EUG) (9) på uddannelsesområdet, Electronic Exchange of Social Security Information (EESSI) i henhold til Europa-Parlamentets og Rådets forordning (EF) nr. 987/2009 (10) på socialsikringsområdet, det europæiske informationssystem vedrørende strafferegistre, der blev oprettet ved Rådets afgørelse 2009/316/RIA (11) med henblik på retligt samarbejde, og eCertis (12), der anvendes i offentlige udbudsprocedurer. Samarbejdet mellem disse systemer og OOTS bør fastlægges fra sag til sag.

(7)

Med henblik på grænseoverskridende autentifikation af en bruger bør OOTS' arkitektur bringes i overensstemmelse med Europa-Parlamentets og Rådets forordning (EU) nr. 910/2014 (13). Den 3. juni 2021 vedtog Kommissionen en henstilling om en fælles EU-værktøjskasse med henblik på en koordineret tilgang til en europæisk ramme for digital identitet (14). Denne henstilling fastlægger en struktureret proces for samarbejde mellem medlemsstaterne, Kommissionen og, hvor det er relevant, operatører i den private sektor med henblik på at arbejde med de tekniske aspekter af rammen for den europæiske digitale identitet. For at sikre den nødvendige tilpasning mellem denne proces og OOTS bør Kommissionen sikre passende koordinering, navnlig gennem kontaktgruppen for synergier og interoperabilitet, mellem det samarbejdsnetværk, der er oprettet ved Kommissionens gennemførelsesafgørelse (EU) 2015/296 (15), og portalkoordinationsgruppen.

(8)

For at garantere sikkerheden af de grænseoverskridende elektroniske leveringstjenester med henblik på OOTS bør medlemsstaterne sikre, at sådanne tjenester opfylder kravene til elektroniske registrerede leveringstjenester, der er fastsat i artikel 44 i forordning (EU) nr. 910/2014. Med henblik herpå er det hensigtsmæssigt, at OOTS anvender eDelivery-adgangspunkter til at oprette et netværk af knudepunkter for sikker digital dataudveksling. Ud over at muliggøre sikker levering på tværs af grænserne leverer eDelivery også metadatatjenestefunktioner, der kan understøtte fremtidige versioner af OOTS med et større antal sikre dataudvekslingsknudepunkter. Inden for disse rammer bør medlemsstaterne kunne vælge udbyderne af deres eDelivery-software.

(9)

For at sikre fleksibilitet i anvendelsen af denne forordning bør medlemsstaterne kunne beslutte at have enten et eller flere eDelivery-adgangspunkter som en del af OOTS. En medlemsstat bør derfor kunne anvende et enkelt adgangspunkt, der forvalter alle OOTS-relaterede eDelivery-meddelelser til dokumentationsansøgerne eller dokumentationsudbyderne via en formidlingsplatform, hvor det er relevant, eller alternativt anvende flere adgangspunkter på et hierarkisk niveau eller for specifikke områder eller sektorer eller geografiske niveauer i dens offentlige forvaltninger.

(10)

I henhold til EU-retten, herunder direktiv 2005/36/EF, 2006/123/EF, 2014/24/EU, 2014/25/EU og forordning (EU) 2018/1724, skal visse administrative procedurer gøres tilgængelige for brugerne online. Da disse procedurer og den krævede dokumentation ikke er harmoniseret i henhold til EU-retten, bør der oprettes fælles tjenester for at muliggøre grænseoverskridende udveksling af dokumentation, der kræves i forbindelse med disse procedurer via OOTS.

(11)	Hvis der ikke findes en aftalt type dokumentation, der er harmoniseret i hele Unionen, og som alle medlemsstater kan fremlægge, bør en dokumentationsmæglertjeneste bidrage til at afgøre, hvilke dokumentationstyper der kan accepteres i forbindelse med en bestemt procedure.

(12)

Dokumentationsmæglertjenesten bør være baseret på regelindhold, der stilles til rådighed af medlemsstaterne, og bør udgøre en onlinemekanisme, således at medlemsstaterne kan foretage søgninger i deres oplysningskrav og typer af dokumentation. Dokumentationsmæglertjenesten bør give medlemsstaterne mulighed for at forvalte og udveksle oplysninger om regler vedrørende typer af bevismateriale.

(13)	I tilfælde, hvor der er behov for interoperabilitet mellem procedureportalen og datatjenesterne og de fælles tjenester, bør dette understøttes af dokumenter vedrørende teknisk udformning.

(14)

Denne forordning bør præcisere, hvornår struktureret og ustruktureret dokumentation, der er nødvendig for de procedurer, der er anført i artikel 14, stk. 1, i forordning (EU) 2018/1724, anses for lovligt udstedt i elektronisk format, der muliggør automatisk udveksling. Ustruktureret dokumentation, der er udstedt i et elektronisk format, kan udveksles via OOTS, hvis den suppleres af metadataelementerne i den generiske OOTS-metadatamodel, der er indeholdt i det semantiske register, der er omhandlet i denne forordnings artikel 7, stk. 1. Struktureret dokumentation kan udveksles via OOTS, hvis de suppleres med metadataelementerne i den generiske OOTS-metadatamodel, der er omhandlet i denne forordnings artikel 7, stk. 1, og enten er i overensstemmelse med OOTS-datamodellen for den relevante dokumentationstype som omhandlet i denne forordnings artikel 7, stk. 2, eller ledsages af en menneskeligt læsbar version.

(15)

Medlemsstaterne bør frit kunne afgøre, hvornår de konverterer dokumentation til et elektronisk format, der muliggør automatisk udveksling via OOTS. For at gøre OOTS mere brugbart for brugerne, og eftersom brugen af datamodeller og metadataskemaer til både ustrukturerede og strukturerede formater generelt anbefales kraftigt, bør Kommissionen støtte medlemsstaterne i deres bestræbelser på at nå dette mål.

(16)

For at undgå overlapning, sikre synergier og give brugerne valgmuligheder bør udviklingen af OOTS-datamodeller for strukturerede dokumentationstyper og standardiseringen af brugssager med henblik på levering af brugeroplysninger i overensstemmelse med den strukturerede proces, der er fastsat i Kommissionens henstilling (EU) 2021/946 (16), ske i tæt samarbejde og tilpasning med hinanden for så vidt angår dokumentation, der er omfattet af artikel 14 i forordning (EU) 2018/1724, herunder ved at bestemme tilfælde af fælles anvendelse. Tilpasningen af OOTS-datamodellerne og de standardiserede anvendelsestilfælde i henhold til ovennævnte henstilling fra Kommissionen bør gøre det muligt for brugerne at anvende alternative dokumentationsmidler, der er omfattet af artikel 14 i forordning (EU) 2018/1724, enten uafhængigt af eller i kombination med OOTS. Når der foretages ændringer af datamodellerne og metadataskemaerne for dokumentation i det semantiske register, bør medlemsstaterne have en frist på 12 måneder fra vedtagelsen af enhver ajourføring til at anvende eventuelle ændringer af den pågældende dokumentation.

(17)

For at minimere mængden af udvekslede data i tilfælde af struktureret dokumentation, hvis der i dokumentationsansøgningen kun anmodes om en del af dataene, kan dokumentationsudbyderen eller, hvor det er relevant, en formidlingsplatform muliggøre automatisk filtrering af dataene og, hvis det er nødvendigt for overførslen, omdannelse af datene på vegne af den dataansvarlige, således at kun de ønskede data udveksles.

(18)

Hvis medlemsstaterne forvalter nationale registre og tjenester, der spiller samme eller en tilsvarende rolle som datatjenesteregistret eller dokumentationsmæglertjenesten, bør de ikke være forpligtet til at duplikere deres arbejde ved at bidrage til de relevante fælles tjenester. I så fald bør de imidlertid sikre, at deres nationale tjenester er forbundet med de fælles tjenester på en sådan måde, at de kan anvendes af andre medlemsstater. Alternativt bør disse medlemsstater kunne kopiere de relevante data fra de nationale registre eller tjenester til datatjenesten eller dokumentationsmæglertjenesten.

(19)

I Tallinnerklæringen om digital forvaltning fra 2017 (17) bekræftede medlemsstaterne deres tilsagn om at gøre fremskridt med hensyn til at forbinde deres offentlige e-tjenester og gennemføre engangsprincippet med henblik på at levere effektive og sikre digitale offentlige tjenester, der vil gøre livet lettere for borgere og virksomheder. Berlinerklæringen fra 2020 om det digitale samfund og værdibaseret digital forvaltning (18), der bygger på principperne om brugerfokus og brugervenlighed, fastsatte yderligere nøgleprincipper, som digitale offentlige tjenester bør baseres på, herunder tillid og sikkerhed i digitale forvaltningsinteraktioner og digital suverænitet og interoperabilitet. Nærværende forordning bør gennemføre disse forpligtelser ved at sætte brugerne i centrum for systemet og kræve, at brugerne informeres om OOTS, dets trin og konsekvenserne af at anvende systemet.

(20)

Det er vigtigt, at der findes et passende system, der gør det muligt for brugerne at identificere sig med henblik på udveksling af dokumentation. Den eneste ramme for gensidig anerkendelse af nationale elektroniske identifikationsmidler på EU-plan er fastsat i forordning (EU) nr. 910/2014. Elektroniske identifikationsmidler, der er udstedt i henhold til elektroniske identifikationsordninger, der er anmeldt i overensstemmelse med nævnte forordning, bør derfor anvendes af dokumentationsansøgere til at autentificere en brugers identitet, inden brugeren udtrykkeligt anmoder om anvendelse af OOTS. Hvis identifikationen af den relevante dokumentationsudbyder kræver tilvejebringelse af attributter ud over de obligatoriske attributter for det minimumsdatasæt, der er opført i bilaget til gennemførelsesforordning (EU) 2015/1501, bør dokumentationsansøgeren også anmode brugeren om sådanne yderligere attributter, og de bør, hvor det er relevant, forelægges for dokumentationsudbyderen eller formidlingsplatformen som en del af dokumentationsansøgningen.

(21)

Nogle af de procedurer, der er anført i artikel 14, stk. 1, i forordning (EU) 2018/1724, kræver, at der kan anmodes om dokumentation på vegne af en juridisk eller fysisk person. For eksempel er visse procedurer relevante for virksomheder, og iværksættere bør derfor kunne anmode om udveksling af dokumentation enten på egne vegne eller gennem en repræsentant. Ved forordning (EU) nr. 910/2014 fastlægges en pålidelig retlig ramme for elektroniske identifikationsmidler, der udstedes til juridiske personer eller til fysiske personer, der repræsenterer juridiske personer. Den gensidige anerkendelse af nationale elektroniske identifikationsmidler i henhold til nævnte forordning finder anvendelse på disse tilfælde af repræsentation. Nærværende forordning bør derfor baseres på forordning (EU) nr. 910/2014 og eventuelle gennemførelsesretsakter, der vedtages på grundlag heraf, med henblik på identifikation af brugere i tilfælde af repræsentation. Portalkoordinationsgruppen og dens undergrupper bør arbejde tæt sammen med de forvaltningsstrukturer, der er oprettet i henhold til forordning (EU) nr. 910/2014, for at hjælpe med at udvikle løsninger vedrørende repræsentation og mandater. I betragtning af, at nogle af de procedurer, der er omfattet af OOTS, er afhængige af den ramme, der er indført ved forordning (EU) nr. 910/2014, bør den dokumentation, som repræsentanterne anmoder om, også kunne behandles via OOTS, når og i det omfang disse løsninger er blevet fundet.

(22)

For at reducere den tid og de omkostninger, der er forbundet med at gennemføre OOTS, og for at drage fordel af hinandens erfaringer med gennemførelsen bør Kommissionen støtte medlemsstaterne og fremme samarbejdet mellem dem om udvikling af genanvendelige tekniske løsninger og komponenter, der kan anvendes til at gennemføre nationale procedureportaler, forhåndsvisninger og datatjenester.

(23)

For at sikre, at brugerne til enhver tid bevarer kontrollen over deres personoplysninger, når de anvender OOTS som fastsat i forordning (EU) 2018/1724, bør OOTS give brugerne mulighed for at give udtryk for deres beslutning vedrørende disse oplysninger i to tilfælde. For det første bør det sikres, at brugerne modtager tilstrækkelige oplysninger til, at de kan fremsætte en oplyst og udtrykkelig anmodning om at behandle deres dokumentationsanmodning via OOTS i overensstemmelse med artikel 14, stk. 3, litra a), og artikel 14, stk. 4, i forordning (EU) 2018/1724. Den bør derefter sikre, at de kan se den dokumentation, der skal udveksles, i en sikker forhåndsvisning, inden de beslutter, om de vil fortsætte med udvekslingen af dokumentation i overensstemmelse med artikel 14, stk. 3, litra f), i forordning (EU) 2018/1724, undtagen i de tilfælde der er omhandlet i artikel 14, stk. 5, i nævnte forordning.

(24)

Ansvaret for oprettelsen af OOTS deles mellem medlemsstaterne og Kommissionen, og portalkoordinationsgruppen bør derfor spille en central rolle i forvaltningen af systemet. I betragtning af den tekniske karakter af dens arbejde og for at lette gennemførelsen i de eksisterende nationale systemer af dokumenter vedrørende teknisk udformning bør arbejdet i portalkoordinationsgruppen støttes og forberedes af eksperter, der samles i en eller flere undergrupper, der er nedsat i overensstemmelse med dens forretningsorden. Funktionen af denne OOTS-forvaltning bør vurderes i den rapport, som Kommissionen skal forelægge Europa-Parlamentet og Rådet senest den 12. december 2022 i henhold til artikel 36 i forordning (EU) 2018/1724.

(25)

For at sikre en hurtig reaktion på eventuelle hændelser og nedgangstider, der kan påvirke OOTS' funktion, bør medlemsstaterne og Kommissionen oprette et netværk af kontaktpunkter for teknisk støtte. For at sikre, at OOTS fungerer korrekt, bør disse kontaktpunkter for teknisk støtte have beføjelser og tilstrækkelige menneskelige og finansielle ressourcer til, at de kan udføre deres opgaver.

(26)

For at sikre, at OOTS fungerer og vedligeholdes effektivt, bør ansvaret for de forskellige komponenter fordeles klart. Kommissionen bør som ejer og operatør af de fælles tjenester være ansvarlig for vedligeholdelse, hosting og sikkerhed. Hver medlemsstat bør være ansvarlig for at sikre vedligeholdelsen og sikkerheden af de komponenter i OOTS, som de ejer, og som de er ansvarlige for, såsom eIDAS-knudepunkter, eDelivery-adgangspunkter eller nationale registre, i overensstemmelse med den relevante EU-ret og nationale ret.

(27)

For at sikre passende beskyttelse af personoplysninger som krævet i Europa-Parlamentets og Rådets forordning (EU) 2016/679 (19) bør denne forordning præcisere medlemsstaternes rolle, navnlig de respektive kompetente myndigheders rolle i deres egenskab af dokumentationsansøgere eller dokumentationsudbydere, og, hvor det er relevant, formidlerplatformene i forbindelse med de personoplysninger, der er indeholdt i den dokumentation, der udveksles via OOTS.

(28)	For at sikre, at de fælles tjenester beskyttes mod potentielle trusler, der skader fortroligheden, integriteten eller tilgængeligheden af Kommissionens kommunikations- og informationssystemer, bør Kommissionens afgørelse (EU, Euratom) 2017/46 (20) finde anvendelse på disse tjenester.

(29)	Artikel 14, stk. 1-8 og 10, i forordning (EU) 2018/1724 anvendes fra den 12. december 2023. Derfor bør kravene i nærværende forordning også gælde fra denne dato.

(30)	Den Europæiske Tilsynsførende for Databeskyttelse blev hørt i overensstemmelse med artikel 42, stk. 1, i Europa-Parlamentets og Rådets forordning (EU) 2018/1725 (21) og afgav formelle bemærkninger den 6. maj 2021 (22).

(31)	Foranstaltningerne i denne forordning er i overensstemmelse med udtalelsen fra udvalget for den fælles digitale portal —

VEDTAGET DENNE FORORDNING:

AFDELING 1

ALMINDELIGE BESTEMMELSER

Artikel 1

Definitioner

I denne forordning forstås ved:

1)	»teknisk engangssystem« (»OOTS«): det tekniske system til grænseoverskridende elektronisk udveksling af dokumentation, jf. artikel 14, stk. 1, i forordning (EU) 2018/1724

2)	»dokumentationsudbyder«: en kompetent myndighed som omhandlet i artikel 14, stk. 2, i forordning (EU) 2018/1724, der lovligt udsteder struktureret eller ustruktureret dokumentation

3)	»dokumentationsansøger«: en kompetent myndighed, der er ansvarlig for en eller flere af de procedurer, der er omhandlet i artikel 14, stk. 1, i forordning (EU) 2018/1724

»eDelivery-adgangspunkt«: en kommunikationskomponent, der er en del af den elektroniske leveringstjeneste eDelivery baseret på tekniske specifikationer og standarder, herunder den meddelelsesoverførende protokol AS4 og accessoriske tjenester, der er udviklet under programmet for Connecting Europe-faciliteten og fortsat under programmet for et digitalt Europa, i det omfang disse tekniske specifikationer og standarder overlapper med ISO 15000-2-standarden

5)	»eIDAS-knudepunkt«: et knudepunkt som defineret i artikel 2, nr. 1), i gennemførelsesforordning (EU) 2015/1501, som opfylder de tekniske og driftsmæssige krav, der er fastsat i og på grundlag af nævnte forordning

»formidlingsplatform«: en teknisk løsning, der handler i egen egenskab eller på vegne af andre enheder såsom dokumentationsudbydere eller dokumentationsansøgere, afhængigt af den administrative organisation i de medlemsstater, hvor formidlingsplatformen opererer, og hvorigennem dokumentationsudbydere eller dokumentationsansøgere tilslutter sig de fælles tjenester, der er omhandlet i artikel 4, stk. 1, eller til dokumentationsudbydere eller dokumentationsansøgere fra andre medlemsstater

7)	»datatjenesteregister«: et register, der indeholder listen over dokumentationsudbydere og de dokumentationstyper, de udsteder, sammen med de relevante ledsagende oplysninger

8)	»dokumentationsmæglingstjeneste«: en tjeneste, der gør det muligt for dokumentationsansøger at afgøre, hvilken type dokumentation fra en anden medlemsstat der opfylder dokumentationskravet i forbindelse med en national procedure

9)	»elektronisk identifikationsmiddel«: en materiel og/eller immateriel enhed, der indeholder personidentifikationsdata, og som bruges til autentifikation i forbindelse med en onlinetjeneste

10)

»semantisk register«: en samling af semantiske specifikationer, der er knyttet til dokumentationsmæglingstjenesten og datatjenesteregistret, og som består af definitioner af navne, datatyper og dataelementer i forbindelse med specifikke dokumentationstyper for at sikre gensidig forståelse og fortolkning på tværs af sprog for dokumentationsudbydere, dokumentationsansøgere og brugere, når de udveksler dokumentation via OOTS

11)

»dokumenter vedrørende teknisk udformning«: et sæt detaljerede og ikkebindende tekniske dokumenter, der er udarbejdet af Kommissionen i samarbejde med medlemsstaterne inden for rammerne af portalkoordinationsgruppen, jf. artikel 29 i forordning (EU) 2018/1724, eller hvilken som helst undergruppe, der er omhandlet i nærværende forordnings artikel 19, og som omfatter, men ikke er begrænset til, en arkitektur på højt niveau, udvekslingsprotokoller, standarder og accessoriske tjenester, der støtter Kommissionen, medlemsstaterne, dokumentationsudbyderne, dokumentationsansøgerne, formidlingsplatformene og andre enheder, der er berørt af OOTS i overensstemmelse med nærværende forordning

12)	»datatjeneste«: en teknisk tjeneste, hvorigennem en dokumentationsudbyder behandler dokumentationsansøgninger og sender dokumentation

13)	»datamodel«: en abstraktion, der organiserer dataelementer, standardiserer deres forhold til hinanden og specificerer enhederne, deres attributter og forholdet mellem sådanne enheder

14)	»forhåndsvisningsområde«: en funktion, der sætter brugeren i stand til på forhånd at se den dokumentation, der anmodes om, jf. artikel 15, stk. 1, litra b), nr. ii)

15)

»struktureret dokumentation«: enhver form for dokumentation i elektronisk format, der kræves til de procedurer, der er anført i artikel 14, stk. 1, i forordning (EU) 2018/1724, og som er organiseret i foruddefinerede elementer eller felter med en specifik betydning og et specifikt teknisk format, der muliggør behandling i softwaresystemer, suppleret med metadataelementerne i den generiske OOTS-metadatamodel, der er omhandlet i nærværende forordnings artikel 7, stk. 1, og enten i overensstemmelse med OOTS-datamodellen for den relevante dokumentationstype som omhandlet i nærværende forordnings artikel 7, stk. 2, eller ledsaget af en humanlæsbar version

16)

»ustruktureret dokumentation«: dokumentation i elektronisk format, der kræves til de procedurer, der er anført i artikel 14, stk. 1, i forordning (EU) 2018/1724, og som ikke er organiseret i foruddefinerede elementer eller felter med en specifik betydning og et specifikt teknisk format, men som suppleres af metadataelementerne i den generiske OOTS-metadatamodel, der er omhandlet i artikel 7, stk. 1, i nærværende forordning

17)	»dokumentationstype«: en kategori af struktureret eller ustruktureret dokumentation med et fælles formål eller indhold

18)	»hændelse«: en situation, hvor OOTS ikke præsterer, undlader at overføre dokumentation eller overfører dokumentation, der ikke er blevet anmodet om, eller hvor dokumentationen er blevet ændret eller er offentliggjort under fremsendelsen, samt ethvert brud på sikkerheden, jf. artikel 29

19)	»procedureportal«: en webside eller en mobilapplikation, hvor en bruger kan få adgang til og gennemføre en onlineprocedure som omhandlet i artikel 14, stk. 1, i forordning (EU) 2018/1724.

Artikel 2

OOTS' struktur

OOTS skal bestå af følgende:

a)	dokumentationsansøgernes procedureportaler og dokumentationsudbydernes datatjenester

b)	formidlingsplatforme, hvis det er relevant

c)	de forhåndsvisningsområder, der er omhandlet i artikel 15, stk. 1, litra b), nr. ii)

d)	de nationale registre og tjenester, der er omhandlet i artikel 8, hvis det er relevant

e)	eIDAS-knudepunkter til brugerautentifikation og identitetsmatchning

f)	eDelivery-adgangspunkter

g)	de fælles tjenester, der er omhandlet i artikel 4, stk. 1

h)	de integrationselementer og -grænseflader, der er nødvendige for at forbinde de komponenter, der er omhandlet i litra a)-g).

AFDELING 2

OOTS' TJENESTER

Artikel 3

eIDAS-knudepunkter og eDelivery-adgangspunkter

1. Medlemsstaterne sikrer, at dokumentationsansøgerne er forbundet med et eIDAS-knudepunkt for at muliggøre brugerautentifikation i henhold til artikel 11, enten direkte eller via en formidlingsplatform.

2. Medlemsstaterne sikrer, at eDelivery-adgangspunkter installeres, konfigureres og integreres i dokumentationsansøgernes procedureportaler, i dokumentationsudbydernes datatjenester og på formidlingsplatformene.

3. Medlemsstaterne kan vælge antallet af eDelivery-adgangspunkter, de anvender til OOTS.

Artikel 4

Fælles tjenester

1. Kommissionen opretter i samarbejde med medlemsstaterne følgende tjenester under OOTS (»fælles tjenester«):

a)	det datatjenesteregister, der er omhandlet i artikel 5

b)	dokumentationsmæglertjenesten, der er omhandlet i artikel 6

c)	det semantiske register, der er omhandlet i artikel 7.

2. Medlemsstaterne sikrer den tekniske forbindelse mellem dokumentationsansøgernes procedureportaler, direkte eller via formidlingsplatforme, med de fælles tjenester og korrekt registrering af deres datatjenester i de fælles tjenester. Ved gennemførelsen af disse forbindelser tager medlemsstaterne udgangspunkt i beskrivelserne i dokumenterne vedrørende teknisk udformning.

3. Medlemsstaterne sikrer, at kun dokumentationskrav er forbundet, direkte eller via formidlingsplatforme, til de fælles tjenester, og at kun dokumentationsansøgere og dokumentationsudbydere kan anvende OOTS. Medlemsstaterne kontrollerer med regelmæssige mellemrum, at forbindelserne til de fælles tjenester fungerer.

Artikel 5

Datatjenesteregister

1. Uden at det berører denne forordnings artikel 8, sikrer medlemsstaterne, at alle de dokumentationsudbydere og de dokumentationstyper, som de udsteder, og som er relevante for de onlineprocedurer, der er omhandlet i artikel 14, stk. 1, i forordning (EU) 2018/1724, registreres i datatjenesteregistret.

2. Kommissionen er ansvarlig for udvikling og vedligeholdelse af grænseflader, der gør det muligt for de nationale koordinatorer, der er omhandlet i artikel 28 i forordning (EU) 2018/1724, de kompetente myndigheder, formidlingsplatformene, hvor det er relevant, og Kommissionen, inden for rammerne af hver deres ansvarsområder og inden for rammerne af de adgangsrettigheder, der er fastlagt af Kommissionen, at:

a)	registrere, afregistrere og foretage enhver anden ajourføring af oplysningerne i datatjenesteregistret

b)	forvalte adgangsrettighederne for personer, der er bemyndiget til at foretage registreringer og ændringer af de registrerede data.

Kommissionen sikrer, at nationale koordinatorer, kompetente myndigheder og formidlingsplatforme kan vælge mellem grafiske brugergrænseflader for autoriserede personer og programmatiske grænseflader til automatiske uploads.

3. Medlemsstaterne sikrer, at hver type dokumentation, der registreres i datatjenesteregistret, ledsages af:

a)	sikkerhedsniveauet for de elektroniske identifikationsmidler, som medlemsstaterne har anmeldt i overensstemmelse med forordning (EU) nr. 910/2014 samt

hvor det er relevant, yderligere attributter, der er specificeret med henblik på at lette identifikationen af den relevante dokumentationsudbyder, og som går ud over de obligatoriske attributter for det minimumsdatasæt, der er fastsat i overensstemmelse med gennemførelsesforordning (EU) 2015/1501, og som udveksles ved hjælp af de elektroniske identifikationsmidler, der er anmeldt i overensstemmelse med forordning (EU) nr. 910/2014, og som er nødvendige for udvekslingen via OOTS.

4. Datatjenesteregistret sondrer klart mellem de yderligere attributter, der er omhandlet i nærværende artikels stk. 3, litra b), og de attributter, der udveksles ved hjælp af de elektroniske identifikationsmidler, der er anmeldt i overensstemmelse med forordning (EU) nr. 910/2014, jf. artikel 13, stk. 1, litra f), i nærværende forordning.

5. Det sikkerhedsniveau, der er omhandlet i stk. 3, litra a), og som kræves til grænseoverskridende brugere, må ikke overstige det sikkerhedsniveau, der kræves for ikkegrænseoverskridende brugere.

6. Medlemsstaterne sikrer, at oplysningerne i datatjenesteregistret holdes ajour.

Artikel 6

Dokumentationsmæglertjenesten

1. Dokumentationsmæglertjenesten skal gøre det muligt for dokumentationsansøgere at afgøre, hvilke dokumentationstyper der er udstedt i andre medlemsstater, der svarer til de dokumentationstyper, der kræves i forbindelse med procedurer, som dokumentationsansøgeren har kompetence til.

2. Medlemsstaterne supplerer via den grænseflade, der er omhandlet i artikel 5, stk. 2, listen over dokumentationstyper i datatjenesteregistret, jf. artikel 5, stk. 1, i forhold til de faktiske forhold eller overholdelsen af proceduremæssige krav, som de dokumenterer, eventuelt sammen med andre dokumentationstyper, hvis det er nødvendigt. Medlemsstaterne sikrer, at disse oplysninger er nøjagtige og ajourførte.

3. Kommissionen er ansvarlig for udvikling og vedligeholdelse af grænseflader, der gør det muligt for nationale koordinatorer, kompetente myndigheder, formidlingsplatforme, hvor det er relevant, og Kommissionen, hver inden for rammerne af deres ansvarsområder og de adgangsrettigheder, der er fastlagt af Kommissionen, at:

a)	tilføje, ændre og ajourføre de oplysninger, der er omhandlet i stk. 2

b)	forvalte adgangsrettighederne for personer, der er bemyndiget til at tilføje og ændre de registrerede oplysninger.

4. Kommissionen letter kortlægningen mellem de dokumentationstyper, der udstedes i én medlemsstat, og de faktiske forhold eller overholdelsen af proceduremæssige krav, der skal dokumenteres i en procedure i en anden medlemsstat, ved at strukturere drøftelserne og tilrettelægge arbejdet i den relevante undergruppe, der er omhandlet i artikel 19. Undergruppen fastsætter et formelt domænespecifikt sprog, der så vidt muligt henviser til relevante internationale standarder, og foreslår portalkoordinationsgruppen dette sprog i overensstemmelse med artikel 18, litra f).

Artikel 7

Semantisk register og datamodeller

1. Det semantiske register skal give adgang til den generiske OOTS-metadatamodel, som er udformet til at vise metadata, der entydigt identificerer dokumentationen og dokumentationsudbyderen, og som omfatter yderligere felter, der er beregnet til at vise de metadata, der er omhandlet i artikel 13, stk. 1, litra a), b) og c).

2. For de typer af struktureret dokumentation, der er aftalt i portalkoordinationsgruppen, skal det semantiske register indeholde en OOTS-datamodel, der som minimum består af de følgende komponenter:

en gengivelse af denne datamodel med:

i)	et visuelt datamodeldiagram samt

ii)	en tekstbeskrivelse af alle datamodellens enheder bestående af en definition og listen over enhedens attributter og for hver attribut den forventede type (f.eks. boolesk, identifikator, dato), en definition, kardinaliteten og den valgfri brug af en kodeliste

b)	fordelinger i XML baseret på XML Schema Definiton (XSD) eller et tilsvarende format suppleret med andre almindeligt anvendte serialiseringsformater, hvor det er muligt

c)	kodelister for at sikre automatisk behandling af dokumentation, som er tilgængeligt i et struktureret format

d)	en mekanisme til konvertering til et humanlæsbart format, f.eks..XSLT eller tilsvarende.

3. For hver type dokumentation skal det semantiske register tilbyde versionskontrol og en ændringslog for at holde øje med forskellige versioner.

4. Det semantiske register skal indeholde en metode til udvikling af nye OOTS-datamodeller til dokumentationstyper, der udveksles via OOTS, bestående af eksempler og undervisningsmateriale.

5. Tidsplaner for ajourføringer og tilpasninger af de generiske OOTS-metadatamodeller og OOTS-datamodellerne drøftes regelmæssigt af medlemsstaterne og Kommissionen inden for rammerne af en af undergrupperne i portalkoordinationsgruppen, jf. artikel 19, og vedtages af portalkoordinationsgruppen. Dokumentationsudbyderne eller formidlingsplatformene, hvor det er relevant, anvender disse ajourføringer og tilpasninger senest 12 måneder efter deres offentliggørelse i det semantiske register.

6. Kommissionen stiller et IT-værktøj til rådighed for medlemsstaterne, som kan hjælpe dem med at kontrollere, at dokumentationen er i overensstemmelse med den generiske OOTS-metadatamodel og OOTS-datamodellerne.

7. Kommissionen gør det semantiske register offentligt tilgængeligt på Kommissionens særlige websted.

Artikel 8

Nationale registre og tjenester

1. Medlemsstater, der har nationale registre eller tjenester, der svarer til datatjenesteregistret eller dokumentationsmæglertjenesten, kan vælge ikke at registrere dokumentationsudbydere, de dokumentationstyper, som de udsteder, og de faktiske forhold eller overholdelse af proceduremæssige krav, som de dokumenterer, eventuelt sammen med andre dokumentationstyper, og graden af sikkerhed for de elektroniske identifikationsmidler, der kræves for at få adgang til hver enkelt dokumentationstype, jf. artikel 5 og 6. I så fald skal de i stedet gøre et af følgende:

a)	give andre medlemsstater mulighed for at søge i deres nationale registre efter de oplysninger, der er omhandlet i dette stykke

b)	kopiere de oplysninger, der er omhandlet i dette stykke, fra de nationale registre eller tjenester til datatjenesteregistret eller dokumentationsmæglertjenesten.

2. Ved gennemførelsen af stk. 1 tager medlemsstaterne udgangspunkt i beskrivelserne i dokumenterne vedrørende teknisk udformning.

AFDELING 3

DOKUMENTATIONSANSØGERE

Artikel 9

Forklaring til brugerne

1. Dokumentationsansøgerne skal sikre, at deres procedureportaler indeholder en forklaring af OOTS og dets funktioner, herunder oplysninger om, at:

a)	brugen af OOTS er frivillig

b)	brugerne har mulighed for at se dokumentationen i forhåndsvisninger, jf. artikel 15, stk. 1, litra b), nr. ii), og beslutte, om de vil anvende den til proceduren eller ej

c)	brugerne kan handle på egne vegne eller lade sig repræsentere af en anden juridisk eller fysisk person, når og i det omfang der er fundet løsninger til repræsentation i overensstemmelse med forordning (EU) nr. 910/2014 og eventuelle gennemførelsesretsakter, der er vedtaget på grundlag heraf.

De oplysninger, der er omhandlet i dette stykkes første afsnit, litra b), kræves ikke i forbindelse med de procedurer, der er omhandlet i artikel 14, stk. 5, i forordning (EU) 2018/1724.

2. Forpligtelsen til at give forklaringer som omhandlet i denne artikels stk. 1 berører ikke forpligtelsen til at give de registrerede personer de oplysninger, der er omhandlet i artikel 13 og 14 i forordning (EU) 2016/679.

Artikel 10

Valg af dokumentationstype

1. Dokumentationsansøgerne skal give brugerne mulighed for at anmode om de dokumentationstyper, der på grundlag af de oplysninger, der er registreret i dokumentationsmæglertjenesten, svarer til typer, som ville være acceptable i henhold til gældende ret i den relevante procedure ved direkte indsendelse, forudsat at dokumentationsudbyderne gør disse dokumentationstyper tilgængelige via OOTS i overensstemmelse med artikel 5, stk. 1.

2. Hvis der kan anmodes om flere dele af en dokumentation, skal dokumentationsansøgeren sikre, at brugerne kan vælge alt, en undergruppe af eller en specifik type af dokumentationen.

Artikel 11

Autentificering af brugere

1. Dokumentationsansøgerne skal gøre brug af de elektroniske identifikationsmidler, der er udstedt i henhold til en elektronisk identifikationsordning, som er anmeldt i overensstemmelse med forordning (EU) nr. 910/2014, med henblik på at autentificere brugerne, som handler enten på egne vegne eller gennem en repræsentant, når og i det omfang der er fundet løsninger til repræsentation i overensstemmelse med forordning (EU) nr. 910/2014 og eventuelle gennemførelsesretsakter, der er vedtaget på grundlag heraf.

2. Når brugeren har valgt den dokumentationstype, der skal udveksles via OOTS, skal dokumentationsansøgere informere brugerne:

a)	om eventuelle yderligere attributter, hvor det er relevant, som omhandlet i artikel 5, stk. 3, litra b), i denne forordning, som de skal tilvejebringe, samt

b)	om at de vil blive omdirigeret til den relevante dokumentationsudbyder, dokumentationsudbydere eller, hvor det er relevant, formidlingsplatformen eller -platformene for at få forhåndsvist den valgte dokumentation.

3. Hvis forhåndsvisning ikke er påkrævet i henhold til artikel 14, stk. 5, i forordning (EU) 2018/1724, finder nærværende artikels stk. 2, litra b), ikke anvendelse. I så fald kan dokumentationsudbyderen, dokumentationsudbyderne eller, hvor det er relevant, formidlingsplatformen eller -platformene anmode dokumentationsansøgeren om at omdirigere brugeren til at genidentificere og genautentificere sig med henblik på at matche identitet og dokumentation. Brugeren kan vælge ikke at blive omdirigeret. I så fald underretter dokumentationsansøgeren brugeren om, at processen med matchning af identitet og dokumentation, som udføres af dokumentationsudbyderen, muligvis ikke fører til et match som omhandlet i artikel 16 i denne forordning.

Artikel 12

Udtrykkelig ansøgning

Dokumentationsansøgeren skal ud over de oplysninger, der er omhandlet i artikel 9, give brugeren følgende:

a)	navn(e) på dokumentationsudbyderen (-erne)

b)	de(n) dokumentationstype(r) eller datafelter, der skal udveksles.

Denne artikel berører ikke de situationer, hvor brugen af OOTS er tilladt uden en udtrykkelig anmodning i overensstemmelse med artikel 14, stk. 4, i forordning (EU) 2018/1724.

Artikel 13

Dokumentationsansøgning

1. Dokumentationsansøgeren sikrer, at dokumentationsansøgningen fremsendes til dokumentationsudbyderen eller formidlingsplatformen, hvor det er relevant, og at den indeholder følgende oplysninger:

a)	anmodningens entydige indikator

b)	den dokumentationstype, der ansøges om

c)	dato og klokkeslæt for den udtrykkelige ansøgning

d)	identifikation af den procedure, som der kræves dokumentation til

e)	navn og metadata, der entydigt identificerer dokumentationsansøgeren og formidlingsplatformen, hvor det er relevant

f)	brugerens attributter eller brugerens og, hvor det er relevant, repræsentantens attributter, der er blevet udvekslet ved hjælp af de elektroniske identifikationsmidler, der er omhandlet i artikel 11, stk. 1

g)	sikkerhedsniveauet som defineret i forordning (EU) nr. 910/2014 for de elektroniske identifikationsmidler, der anvendes af brugeren

h)	de yderligere attributter, der er omhandlet i artikel 5, stk. 3, litra b), som brugeren stiller til rådighed med henblik på anmodningen

i)	identifikationen af den dokumentationsudbyder, der er registreret i datatjenesteregistret

j)	hvorvidt brugerens udtrykkelige anmodning var påkrævet i henhold til artikel 14, stk. 4, i forordning (EU) 2018/1724

k)	hvorvidt muligheden for at få en forhåndsvisning af dokumentationen er påkrævet i henhold til artikel 14, stk. 5, i forordning (EU) 2018/1724.

2. Dokumentationsansøgeren skal foretage en klar sondring mellem de yderligere attributter, der er omhandlet i stk. 1, litra h), og de attributter, der er omhandlet i stk. 1, litra f).

Artikel 14

Omdirigering af brugeren til dokumentationsudbyderen

1. Uden at det berører de procedurer, der er omhandlet i artikel 14, stk. 5, i forordning (EU) 2018/1724, sikrer dokumentationsansøgerne, at brugerne efter at have valgt den dokumentation, der skal udveksles via OOTS, i procedureportalen i overensstemmelse med artikel 10 i nærværende forordning og udtrykkeligt have anmodet herom i overensstemmelse med artikel 12 i nærværende forordning, omdirigeres til dokumentationsudbyderen, dokumentationsudbyderne eller, hvor det er relevant, formidlingsplatformen eller -platformene for at udnytte muligheden for at få en forhåndsvisning af dokumentationen.

2. For så vidt angår de procedurer, der er omhandlet i artikel 14, stk. 5, i forordning (EU) 2018/1724, kan brugerne omdirigeres til dokumentationsudbyderen, dokumentationsudbyderne eller, hvor det er relevant, formidlingsplatformen eller -platformene i overensstemmelse med artikel 11, stk. 3, i nærværende forordning.

AFDELING 4

DOKUMENTATIONSUDBYDERE

Artikel 15

Rolle i udvekslingen af dokumentation

1. Medlemsstaterne sikrer, at dokumentationsudbyderne eller, hvor det er relevant, formidlingsplatformene med henblik på udvekslingen af dokumentation via OOTS anvender applikationstjenester, der er i stand til det følgende:

a)	at modtage og fortolke dokumentationsansøgninger fra et eDelivery-adgangspunkt, der betragtes som input til datatjenesterne

med forbehold af vellykket identifikation og autentifikation i overensstemmelse med artikel 16 i denne forordning:

i)	at indhente de dele af dokumentationen, der passer til anmodningen

ii)

med undtagelse af de procedurer, der er omhandlet i artikel 14, stk. 5, i forordning (EU) 2018/1724, at give brugerne mulighed for at angive, hvilke af disse dele af dokumentationen de ønsker at få forhåndsvist, og give dem mulighed for at få forhåndsvist de således angivne dele i et forhåndsvisningsområde

iii)	at give brugerne mulighed for at angive, hvilken dokumentation der i givet fald skal returneres til dokumentationsansøgeren til anvendelse i proceduren

at returnere dokumentationsresultater til dokumentationsansøgeren via et eDelivery-adgangspunkt, med forbehold af brugerens beslutning om at anvende dokumentationen i proceduren efter muligheden for forhåndsvisning af den, undtagen i tilfælde af de procedurer, der er omhandlet i artikel 14, stk. 5, i forordning (EU) 2018/1724, fejlrapporter, herunder i den situation, der er omhandlet i artikel 16, stk. 3, litra a), i nærværende forordning, eller rapporter vedrørende dokumentation, der er ved at blive konverteret.

2. Hvis et dokumentationsresultat returneres, skal det indeholde den ønskede dokumentation og være ledsaget af:

a)	metadata, der entydigt identificerer dokumentationsresultatet

b)	metadata, der entydigt identificerer dokumentationsansøgningen

c)	metadata, der angiver den dato og det tidspunkt, hvor resultatet blev genereret

d)	metadata, der entydigt identificerer dokumentationen og dokumentationsudbyderen

e)	hvis struktureret dokumentation ikke er i overensstemmelse med den OOTS-datamodel, der er relevant for den pågældende dokumentationstype, en menneskeligt læsbar version af dokumentationen.

3. Dokumentationsresultatet kan også omfatte de metadata, der entydigt identificerer det eller de sprog, som den ønskede dokumentation er affattet på.

4. Hvis en fejlrapport returneres, skal den indeholde metadata, der entydigt identificerer dokumentationsansøgningen, datoen og tidspunktet, hvor den blev genereret, og en beskrivelse af den fejl, der opstod.

5. Hvis der endnu ikke foreligger dokumentation til udveksling via OOTS, men den er ved at blive konverteret til struktureret eller ustruktureret dokumentation som defineret i artikel 1, nr. 16) og 17), returneres en rapport som omhandlet i denne artikels stk. 1, litra c). Denne rapport skal indeholde metadata, der entydigt identificerer dokumentationsansøgningen, datoen og tidspunktet, hvor den blev genereret og en meddelelse om, at den pågældende dokumentation er ved at blive konverteret til struktureret eller ustruktureret dokumentation som defineret i artikel 1, nr. 16) og 17), og vil være klar til fremsendelse via OOTS i fremtiden. Dokumentationsudbyderen medtager i rapporten den foreløbige dato og det foreløbige tidspunkt for, hvornår dokumentationen vil være tilgængelig.

Artikel 16

Matchning af identitet og dokumentation

1. Dokumentationsudbyderne eller, hvor det er relevant, formidlingsplatformene kan kræve, at brugerne genidentificerer og genautentificerer sig med henblik på at matche identitet og dokumentation, herunder ved at tilvejebringe yderligere attributter.

2. Dokumentationsudbyderne eller, hvor det er relevant, formidlingsplatformene sikrer, at dokumentation kun udveksles via OOTS, hvis brugerens og, hvis det er relevant, repræsentantens identitetsattributter, der udveksles ved hjælp af de elektroniske identifikationsmidler, der er omhandlet i artikel 11, stk. 1, og yderligere attributter som omhandlet i artikel 11, stk. 2, litra a), og leveres af brugeren for at gøre identifikationen lettere for den relevante dokumentationsudbyder, matcher dokumentationsudbydernes eller formidlingsplatformenes egne attributter.

3. Hvis processen med matchning af identitet og dokumentation ikke fører til et match, eller identitetsmatchningen genererer to eller flere resultater, må brugeren eller, hvor det er relevant, repræsentanten ikke få en forhåndsvisning af den ønskede dokumentation, og dokumentationen må ikke udveksles. I mangel af et sådant match:

a)	skal der sendes en fejlmeddelelse til dokumentationsansøgeren

b)	skal brugeren modtage en automatiseret meddelelse, hvori det forklares, at dokumentationen ikke kan fremsendes.

AFDELING 5

OOTS' LOGSYSTEM

Artikel 17

Logsystem

1. For hver dokumentationsansøgning, der fremsendes via OOTS, skal den eller de dokumentationsansøgere eller, hvor det er relevant, formidlingsplatforme registrere følgende elementer:

a)	dokumentationsansøgningen, der er omhandlet i artikel 13, stk. 1

b)	oplysningerne i dokumentationsresultatet, med undtagelse af selve dokumentationen, eller fejlrapporten, jf. artikel 15, stk. 1, litra c), og artikel 16, stk. 3, litra a)

eDelivery-hændelsesdataene vedrørende en eller flere af følgende:

i)	ansøgninger om udveksling af dokumentation

ii)	dokumentationsresultater

iii)	fejlrapporter.

2. For hver dokumentation, der udveksles via OOTS, registrerer dokumentationsudbyderen eller, hvor det er relevant, formidlingsplatformen brugerens beslutning efter at have set forhåndsvisningen af dokumentationen for at godkende eller ikke at godkende anvendelsen af dokumentationen til proceduren eller, hvor det er relevant, at brugeren forlader forhåndsvisningen eller procedureportalen uden at træffe en specifik afgørelse.

3. Kommissionen og, i de situationer, der er omhandlet i artikel 8, stk. 1, litra a), de relevante medlemsstater registrerer alle interaktioner med de fælles tjenester, der er omhandlet i artikel 4, stk. 1.

4. Uden at det berører længere opbevaringsperioder, der kræves i henhold til national ret for de logfiler, der er omhandlet i stk. 1, 2 og 3, med henblik på OOTS eller til andre formål, opbevarer Kommissionen og dokumentationsansøgerne, dokumentationsudbyderne eller formidlingsplatformene, hvor det er relevant, disse logfiler i en periode på 12 måneder.

5. I tilfælde af mistanke om hændelser og med henblik på revisioner og tilfældige sikkerhedskontroller, der foretages inden for deres respektive ansvarsområder, jf. artikel 26, stiller dokumentationsansøgerne, dokumentationsudbyderne og, hvor det er relevant, formidlingsplatformene efter anmodning de relevante logfiler, der er omhandlet i nærværende artikels stk. 1 og 2, til rådighed for hinanden via det dashboard for teknisk støtte, der er omhandlet i artikel 22. Med henblik herpå og på samme måde stiller medlemsstaterne og Kommissionen, hvor det er relevant, de relevante logfiler, der er omhandlet i denne artikels stk. 3, til rådighed for de relevante dokumentationsansøgere, dokumentationsudbydere og, hvor det er relevant, formidlingsplatforme.

AFDELING 6

FORVALTNINGEN AF OOTS

Artikel 18

Portalkoordinationsgruppen

Kommissionen skal i samarbejde med medlemsstaterne inden for rammerne af portalkoordinationsgruppen, der er nedsat ved artikel 29 i forordning (EU) 2018/1724:

a)	føre tilsyn med oprettelsen og lanceringen af OOTS i overensstemmelse med artikel 31, stk. 3, i denne forordning

b)	fastsætte prioriteter for videre udvikling og forbedring af OOTS

c)	fastlægge en vejledende tidsplan for regelmæssig ajourføring og vedligeholdelse og tilpasning af dokumenterne vedrørende teknisk udformning

d)	anbefale ændringer i dokumenterne vedrørende teknisk udformning

e)	tilrettelægge peerevalueringer for at fremme udveksling af erfaringer og god praksis mellem medlemsstaterne vedrørende medlemsstaternes anvendelse af denne forordning

f)	godkende eller afvise operationelle retningslinjer forelagt af en af de undergrupper, der er oprettet i overensstemmelse med portalkoordinationsgruppens forretningsorden, og om nødvendigt give specifik vejledning og føre tilsyn med deres arbejde.

Artikel 19

Undergrupper i portalkoordinationsgruppen

1. For at sikre en koordineret udvikling og drift af OOTS drøfter de undergrupper, der er omhandlet i artikel 18, litra f), og udarbejder om nødvendigt forslag til de operationelle bestemmelser, der skal forelægges portalkoordinationsgruppen på følgende områder, navnlig:

a)	standardisering af OOTS-datamodellerne

b)	kortlægning af dokumentation

c)	gennemgang, vedligeholdelse og fortolkning af dokumenterne vedrørende teknisk udformning

d)	operationel styring, navnlig operationelle ordninger og serviceleveranceaftaler

e)	OOTS' sikkerhed, herunder udarbejdelse af risikostyringsplaner med henblik på at identificere risici, vurdere deres potentielle indvirkning og planlægge passende tekniske og organisatoriske reaktioner i tilfælde af hændelser

f)	afprøvning og ibrugtagning af OOTS-komponenterne, herunder interoperabilitet mellem de nationale komponenter i OOTS, der er omhandlet i artikel 2, litra a)-f) og h), og de fælles tjenester, der er omhandlet i artikel 4, stk. 1.

De operationelle bestemmelser skal omfatte udarbejdelse og forslag til standarder, der er nødvendige for interoperabilitet på de respektive områder af undergrupperne, i overensstemmelse med internationale standarder, når det er muligt. Når disse standarder er godkendt af portalkoordinationsgruppen, skal de indgå i dokumenterne vedrørende teknisk udformning.

2. Undergrupperne vedtager deres forslag til operationelle bestemmelser ved konsensus, når det er muligt. Hvis det viser sig, at der ikke kan opnås konsensus, kan formanden, hvis det støttes af et simpelt flertal af de medlemmer af undergruppen, der er til stede på mødet, beslutte, at et forslag fra undergruppen kan forelægges portalkoordinationsgruppen.

AFDELING 7

TEKNISK STØTTE

Artikel 20

Kommissionens centrale kontaktpunkt for teknisk støtte

1. Kommissionen udpeger et centralt kontaktpunkt for teknisk støtte til at sikre driften og vedligeholdelsen af de fælles tjenester, der er omhandlet i artikel 4, stk. 1.

2. Det centrale kontaktpunkt for teknisk støtte samarbejder med andre relevante kontaktpunkter i Kommissionen og koordinerer løsningen af problemer med eDelivery-adgangspunkter eller eIDAS-knudepunkter.

3. Kommissionen sikrer, at dens centrale kontaktpunkt for teknisk støtte er organiseret på en måde, der gør det muligt for den at udføre sine opgaver under alle omstændigheder og reagere med kort varsel.

Artikel 21

Det nationale centrale kontaktpunkt for teknisk støtte

1. Hver medlemsstat udpeger et centralt kontaktpunkt for teknisk støtte til at sikre driften og vedligeholdelsen af de relevante komponenter i OOTS, som de er ansvarlige for i henhold til afdeling 9.

2. Det nationale centrale kontaktpunkt for teknisk støtte skal:

a)	yde ekspertise og rådgivning til dokumentationsudbydere og dokumentationsansøgere i forbindelse med alle tekniske problemer vedrørende driften af OOTS og om nødvendigt samarbejde med Kommissionens tekniske kontaktpunkt og med andre nationale kontaktpunkter for teknisk støtte

b)	undersøge og løse eventuelle nedetider i eDelivery-adgangspunkterne, eventuelle brud på sikkerheden og andre hændelser

c)	underrette kontaktpunkterne for teknisk støtte om alle aktiviteter, der kan føre til et brud eller mistanke om brud på de elektroniske systemers sikkerhed.

3. Når det centrale kontaktpunkt for teknisk støtte underrettes af en dokumentationsudbyder om tvivl angående lovligheden af en eller flere dokumentationsansøgninger, skal det centrale kontaktpunkt for teknisk støtte:

a)	gennemgå dokumentationsansøgninger eller stikprøver af dokumentationsansøgninger, der tidligere er fremsendt fra den samme dokumentationsansøger

b)	anvende det dashboard for teknisk støtte, der er omhandlet i artikel 22, til at anmode det centrale kontaktpunkt for teknisk støtte, der er udpeget af dokumentationsansøgeren medlemsstat, til at fremsende logfiler over udvalgte udvekslinger, jf. artikel 17

c)	gøre den nationale koordinator opmærksom på problemet, hvis problemet varer ved.

4. Medlemsstaterne sikrer, at deres centrale kontaktpunkt for teknisk støtte er organiseret på en måde, der gør det muligt for den at udføre sine opgaver under alle omstændigheder og reagere med kort varsel.

Artikel 22

Dashboard for teknisk støtte

1. Kommissionen opretter et dashboard for at lette kommunikationen mellem alle kontaktpunkter for teknisk støtte.

2. Medlemsstaterne og Kommissionen registrerer kontaktoplysningerne for kontaktpunkterne for teknisk støtte i dashboardet og ajourfører dem.

3. Kontaktpunkterne skal via dashboardet:

a)	indberette enhver hændelse, der anses for at være væsentlig

b)	indberette eventuelle midlertidige eller permanente foranstaltninger, der er truffet som følge af hændelser

c)	anmode de relevante kontaktpunkter for teknisk støtte om logfiler over udvalgte udvekslinger i de tilfælde, der er omhandlet i artikel 17, stk. 5, og i tvivlstilfælde om lovligheden af den dokumentationsansøgning, der er omhandlet i artikel 21, stk. 3

d)	anmode om anden bistand, der er nødvendig i tilfælde af hændelser.

4. De nationale koordinatorer og formanden for portalkoordinationsgruppen har adgang til dashboardet.

5. Kommissionen og de nationale koordinatorer anvender dashboardet til at give de oplysninger, der er omhandlet i artikel 27 og artikel 28, stk. 2.

AFDELING 8

SAMARBEJDE MED ANDRE FORVALTNINGSSTRUKTURER

Artikel 23

Omfanget af samarbejdet

Kommissionen samarbejder med portalkoordinationsgruppen og dens undergrupper med relevante forvaltningsstrukturer, der er oprettet i henhold til EU-retten eller internationale aftaler på områder, der er relevante for OOTS, med henblik på at opnå synergier og så vidt muligt genbruge de løsninger, der er udviklet i disse andre fora.

AFDELING 9

ANSVAR FOR VEDLIGEHOLDELSE OG DRIFT AF KOMPONENTER I OOTS

Artikel 24

Kommissionens ansvar

Kommissionen ejer de fælles tjenester og dashboardet for teknisk støtte og er ansvarlig for deres udvikling, tilgængelighed, overvågning, opdatering, vedligeholdelse og hosting.

Artikel 25

Medlemsstaternes ansvar

For så vidt angår de respektive nationale komponenter i OOTS, der er omhandlet i artikel 2, litra a)-f) og h), betragtes hver medlemsstat som ejer og ansvarlig for oprettelsen, hvor det er relevant, og for udviklingen, tilgængeligheden, overvågningen, opdateringen, vedligeholdelsen og hosting.

Artikel 26

Ændringer og opdateringer

1. Kommissionen underretter medlemsstaterne om ændringer og opdateringer af de fælles tjenester.

2. Medlemsstaterne underretter Kommissionen om ændringer og opdateringer af de komponenter, som de har ansvar for, og som kan have indvirkning på OOTS' funktion.

3. Oplysninger om kritiske opdateringer skal gives uden unødig forsinkelse. I tilfælde af andre ikkekritiske opdateringer, der sandsynligvis vil påvirke nogle OOTS-komponenter, der ejes af andre medlemsstater, eller de fælles tjenester, fastsætter portalkoordinationsgruppen fristen på grundlag af et forslag fra den relevante undergruppe.

Artikel 27

OOTS' tilgængelighed

1. OOTS' driftstidsramme skal være 24 timer om dagen 7 dage om ugen med en tilgængelighedsgrad for eDelivery-adgangspunkterne, forhåndsvisningerne og de fælles tjenester på mindst 98 %, eksklusive vedligeholdelse planlagt i overensstemmelse med denne artikels stk. 2. Målene for serviceniveauet for de resterende OOTS-komponenter skal angives i de serviceleveranceaftaler, der er omhandlet i artikel 19, stk. 1, litra d).

2. Medlemsstaterne og Kommissionen giver meddelelse om de planlagte vedligeholdelsesaktiviteter i forbindelse med de relevante OOTS-komponenter som følger:

a)	5 arbejdsdage i forvejen for vedligeholdelsesopgaver, der kan gøre systemet utilgængeligt i op til 4 timer

b)	10 arbejdsdage i forvejen for vedligeholdelsesopgaver, der kan gøre systemet utilgængeligt i op til 12 timer

c)	30 arbejdsdage i forvejen for vedligeholdelse af infrastrukturen i datarum, der kan gøre systemet utilgængeligt i op til 6 dage pr. år.

Vedligeholdelsesarbejdet planlægges så vidt muligt uden for arbejdstiden.

3. Hvis medlemsstaterne har afsat et fast ugentligt vedligeholdelsestidspunkt, underretter de Kommissionen om klokkeslæt og dag. Uden at det berører forpligtelserne i stk. 2, litra a), b) og c), er medlemsstaterne, hvis medlemsstaternes systemer bliver utilgængelige under et sådant fast tidspunkt, fritaget for forpligtelsen til at underrette Kommissionen hver gang.

4. I tilfælde af uventede tekniske fejl i medlemsstaternes OOTS-komponenter underretter den relevante medlemsstat straks de øvrige medlemsstater og Kommissionen om, at komponenterne ikke er tilgængelige, og, hvis den er kendt, om den forventede genoptagelse af komponenternes funktion.

5. I tilfælde af uventet svigt i de fælles tjenester underretter Kommissionen straks medlemsstaterne om, at der ikke er adgang til en eller flere fælles tjenester, og, hvis den er kendt, om den planlagte genoptagelse af tjenesten.

6. De meddelelser, der er omhandlet i denne artikel, foretages via det dashboard for teknisk støtte, der er omhandlet i artikel 22.

AFDELING 10

SIKKERHED

Artikel 28

De fælles tjenesters og de nationale komponenters sikkerhed

1. Kommissionen varetager sikkerheden for de fælles tjenester, der er omhandlet i artikel 4, stk. 1, og de integrationselementer og -grænseflader, der er omhandlet i artikel 2, litra h), som den er ansvarlig for.

2. Medlemsstaterne varetager sikkerheden for de nationale komponenter i OOTS og de integrationselementer og -grænseflader, der er omhandlet i artikel 2, litra h), som de er ansvarlige for.

3. Med henblik på stk. 1 og 2 træffer medlemsstaterne og Kommissionen som minimum og for hver af de komponenter, som de er ansvarlige for, de nødvendige foranstaltninger for at:

a)	forhindre uautoriserede personer i at få adgang til de komponenter, som de er ansvarlige for

b)	forhindre, at oplysninger indskrives, konsulteres, ændres eller slettes af uautoriserede personer

c)	afsløre ethvert tilfælde af de aktiviteter, der er omhandlet i litra a) og b), samt

d)	sikre registrering af sikkerhedshændelser i overensstemmelse med anerkendte internationale sikkerhedsstandarder for informationsteknologi.

4. Medlemsstaterne sikrer navnlig:

at de forbindelser, de opererer ind i og ud af eDelivery-adgangspunkter, og al intern kommunikation mellem forskellige nationale myndigheder når mindst samme sikkerhedsniveau som den elektroniske leveringstjeneste eDelivery for at beskytte sikkerheden og fortroligheden i forbindelse med udvekslingen og integriteten af den dokumentation, der udveksles via OOTS

b)	uafviseligheden af oprindelsen af den dokumentationsansøgning, der er fremsendt fra dokumentationsansøgerens adgangspunkt, og af det dokumentationsresultat, der udveksles, eller den fejlmeddelelse, der er fremsendt fra dokumentationsudbyderens adgangspunkt.

5. I overensstemmelse med stk. 4 er den medlemsstat, hvor dokumentationsudbyderen er etableret i forbindelse med en given udveksling af dokumentation, ansvarlig for kvaliteten, fortroligheden, integriteten og tilgængeligheden af den ønskede dokumentation, indtil den når frem til dokumentationsansøgerens eller, hvor det er relevant, en formidlingsplatforms eDelivery-adgangspunkt. Den medlemsstat, hvor dokumentationsansøgeren er etableret, er i hvilken som helst udveksling af dokumentation ansvarlig for fortroligheden og integriteten af det bevismateriale, der anmodes om, fra det øjeblik, hvor den når frem til sit eDelivery Access Point.

6. Medlemsstaterne og Kommissionen sikrer fortroligheden, integriteten og tilgængeligheden af de logfiler, der er omhandlet i artikel 17, stk. 1, 2 og 3, ved hjælp af passende og forholdsmæssige sikkerhedsforanstaltninger, hver for de logfiler, de har registreret.

Artikel 29

Overvågning af de elektroniske systemer

1. Medlemsstaterne og Kommissionen foretager regelmæssig kontrol af de OOTS-komponenter, som de er ansvarlige for.

2. De centrale kontaktpunkter for teknisk bistand, der er omhandlet i artikel 20 og 21, anvender det dashboard for teknisk bistand, der er omhandlet i artikel 22, til at underrette hinanden om problemer, der opdages under kontrollerne, og som kan føre til et brud eller mistanke om brud på OOTS' sikkerhed.

Artikel 30

System til forvaltning af administration

Kommissionen opretter et administrationssystem til forvaltning af autentificerings- og godkendelsesreglerne for validering af identifikationsdataene med henblik på at give adgang til de fælles tjenester og dashboardet for teknisk støtte.

AFDELING 11

AFSLUTTENDE BESTEMMELSER

Artikel 31

Test af OOTS

1. Medlemsstaterne og Kommissionen vedtager inden for rammerne af portalkoordinationsgruppen en testplan og et sæt indikatorer, i henhold til hvilke testresultaterne kan måles og betragtes som positive.

2. Kommissionen stiller prøvningstjenester til rådighed, som medlemsstaterne kan anvende til at teste de tekniske løsningers overensstemmelse med de indikatorer, der er omhandlet i stk. 1.

3. Medlemsstaterne og Kommissionen tester funktionen af de enkelte OOTS-komponenter og kontrollerer, at de kan fungere korrekt i henhold til de indikatorer, der er omhandlet i stk. 1. Kun de komponenter i OOTS, for hvilke testene giver positive resultater, stilles til rådighed for brugerne.

Artikel 32

Støtte fra Kommissionen

Kommissionen stiller et hold eksperter til rådighed som en del af Kommissionens kontaktpunkt for teknisk støtte for at bistå nationale kontaktpunkter for teknisk støtte og nationale koordinatorer i alle aspekter af OOTS' funktion set ud fra et teknisk synspunkt, navnlig:

a)	udarbejdelse af retningslinjer

b)	tilrettelæggelse af workshops og demonstrationer

c)	besvarelse af individuelle spørgsmål.

Artikel 33

Behandling af personoplysninger

I forbindelse med behandlingen af personoplysninger i det bevismateriale, der er genstand for udveksling via OOTS, og som forekommer i de OOTS-komponenter, som de ejer i henhold til denne forordnings artikel 25, fungerer medlemsstaternes respektive kompetente myndigheder i deres egenskab af dokumentationsansøgere eller dokumentationsudbydere som dataansvarlige som defineret i artikel 4, nr. 7), i forordning (EU) 2016/679 og som yderligere specificeret i nærværende forordnings artikel 34 og 35.

Artikel 34

Dokumentationsansøgerens ansvar som dataansvarlig

1. For hver udveksling af dokumentation via OOTS er den relevante dokumentationsansøger eller, hvor det er relevant, formidlingsplatform eneansvarlig for, at dokumentationsansøgningen er fuldstændig og lovlig. Dokumentationsansøgeren skal navnlig sikre, at dokumentationen er nødvendig for den særlige procedure, til hvilken brugeren anmoder om den.

2. Når den dokumentation, der er udvekslet via OOTS, bliver tilgængelig for dokumentationsansøgeren eller, hvor det er relevant, formidlingsplatformen enten efter brugerens valg om at fortsætte med udvekslingen af dokumentation i overensstemmelse med artikel 14, stk. 3, litra f), i forordning (EU) 2018/1724, eller i tilfælde af de procedurer, der er omhandlet i artikel 14, stk. 5, i forordning (EU) 2018/1724, sikrer dokumentationsansøgeren eller, hvor det er relevant, formidlingsplatformen det samme niveau for beskyttelse af personoplysninger i overensstemmelse med forordning (EU) 2016/679 som i en situation, hvor brugeren indgiver eller uploader dokumentationen uden at gøre brug af OOTS.

Artikel 35

Dokumentationsudbyderens ansvar som dataansvarlig

1. Med forbehold af deres forpligtelser i henhold til forordning (EU) 2016/679 er den relevante dokumentationsudbyder eller, hvor det er relevant, formidlingsplatform for hver udveksling af dokumentation via OOTS eneansvarlig for at verificere:

a)	at den ønskede dokumentation, den er i besiddelse af, kan matches med brugeren i overensstemmelse med artikel 16

b)	at brugeren har ret til at anvende den ønskede dokumentation.

2. Når en formidlingsplatform stiller forhåndsvisning til rådighed i overensstemmelse med artikel 15, stk. 1, litra b), nr. ii), i denne forordning, betragtes den som en databehandler, der handler på vegne af dokumentationsudbyderen i henhold til artikel 4, stk. 8, i forordning (EU) 2016/679.

Artikel 36

Ikrafttræden

Denne forordning træder i kraft på tyvendedagen efter offentliggørelsen i Den Europæiske Unions Tidende.

Den anvendes fra den 12. december 2023.

Denne forordning er bindende i alle enkeltheder og gælder umiddelbart i hver medlemsstat.

Udfærdiget i Bruxelles, den 5. august 2022.

På Kommissionens vegne

Ursula VON DER LEYEN

Formand

(1) EUT L 295 af 21.11.2018, s. 1.

(2) Europa-Parlamentets og Rådets direktiv 2005/36/EF af 7. september 2005 om anerkendelse af erhvervsmæssige kvalifikationer (EUT L 255 af 30.9.2005, s. 22).

(3) Europa-Parlamentets og Rådets direktiv 2006/123/EF af 12. december 2006 om tjenesteydelser i det indre marked (EUT L 376 af 27.12.2006, s. 36).

(4) Europa-Parlamentets og Rådets direktiv 2014/24/EU af 26. februar 2014 om offentlige udbud og om ophævelse af direktiv 2004/18/EF (EUT L 94 af 28.3.2014, s. 65).

(5) Europa-Parlamentets og Rådets direktiv 2014/25/EU af 26. februar 2014 om fremgangsmåderne ved indgåelse af kontrakter inden for vand- og energiforsyning, transport samt posttjenester og om ophævelse af direktiv 2004/17/EF (EUT L 94 af 28.3.2014, s. 243).

(6) Kommissionens gennemførelsesforordning (EU) 2015/1501 af 8. september 2015 om interoperabilitetsrammen i henhold til artikel 12, stk. 8, i Europa-Parlamentets og Rådets forordning (EU) nr. 910/2014 om elektronisk identifikation og tillidstjenester til brug for elektroniske transaktioner på det indre marked (EUT L 235 af 9.9.2015, s. 1).

(7) Kørekortnetværk oprettet på grundlag af artikel 15 i Europa-Parlamentets og Rådets direktiv 2006/126/EF af 20. december 2006 om kørekort (EUT L 403 af 30.12.2006, s. 18).

(8) Traktat om et europæisk informationssystem vedrørende køretøjer og kørekort (Eucaris), vedtaget i Luxembourg den 29. juni 2000.

(9) Emrex User Group (EUG) er et uafhængigt, internationalt netværk, der samler forskellige aktører, der er interesserede i at forbedre dataportabiliteten for studerende, https://emrex.eu/.

(10) Europa-Parlamentets og Rådets forordning (EF) nr. 987/2009 af 16. september 2009 om de nærmere regler til gennemførelse af forordning (EF) nr. 883/2004 om koordinering af de sociale sikringsordninger (EUT L 284 af 30.10.2009, s. 1).

(11) Rådets afgørelse 2009/316/RIA af 6. april 2009 om indførelse af det europæiske informationssystem vedrørende strafferegistre (ECRIS) i henhold til artikel 11 i rammeafgørelse 2009/315/RIA (EUT L 93 af 7.4.2009, s. 33).

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

(13) Europa-Parlamentets og Rådets forordning (EU) nr. 910/2014 af 23. juli 2014 om elektronisk identifikation og tillidstjenester til brug for elektroniske transaktioner på det indre marked og om ophævelse af direktiv 1999/93/EF (EUT L 257 af 28.8.2014, s. 73).

(14) A trusted and secure European e-ID - Recommendation | Shaping Europe’s digital future (europa.eu).

(15) Kommissionens gennemførelsesafgørelse (EU) 2015/296 af 24. februar 2015 om fastlæggelse af de proceduremæssige ordninger for samarbejde mellem medlemsstaterne om elektronisk identifikation i henhold til artikel 12, stk. 7, i Europa-Parlamentets og Rådets forordning (EU) nr. 910/2014 om elektronisk identifikation og tillidstjenester til brug for elektroniske transaktioner på det indre marked (EUT L 53 af 25.2.2015, s. 14).

(16) Kommissionens henstilling (EU) 2021/946 af 3. juni 2021 om en fælles EU-værktøjskasse for en koordineret tilgang til en ramme for en europæisk digital identitet (EUT L 210 af 14.6.2021, s 51).

(17) Undertegnet den 6. oktober 2017, https://digital-strategy.ec.europa.eu/en/news/ministerial-declaration-egovernment-tallinn-declaration.

(18) Undertegnet den 8. december 2020, https://digital-strategy.ec.europa.eu/da/news/berlin-declaration-digital-society-and-value-based-digital-government

(19) Europa-Parlamentets og Rådets forordning (EU) 2016/679 af 27. april 2016 om beskyttelse af fysiske personer i forbindelse med behandling af personoplysninger og om fri udveksling af sådanne oplysninger og om ophævelse af direktiv 95/46/EF (generel forordning om databeskyttelse) (EUT L 119 af 4.5.2016, s. 1).

(20) Kommissionens afgørelse (EU, Euratom) 2017/46 af 10. januar 2017 om kommunikations- og informationssystemernes sikkerhed i Europa-Kommissionen (EUT L 6 af 11.1.2017, s. 40).

(21) Europa-Parlamentets og Rådets forordning (EU) 2018/1725 af 23. oktober 2018 om beskyttelse af fysiske personer i forbindelse med behandling af personoplysninger i Unionens institutioner, organer, kontorer og agenturer og om fri udveksling af sådanne oplysninger og om ophævelse af forordning (EF) nr. 45/2001 og afgørelse nr. 1247/2002/EF (EUT L 295 af 21.11.2018, s. 39).

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

6.9.2022

Den Europæiske Unions Tidende

L 231/24

KOMMISSIONENS FORORDNING (EU) 2022/1465

af 5. september 2022

om ændring af bilag I til Europa-Parlamentets og Rådets forordning (EF) nr. 1334/2008 for så vidt angår visse aromastoffer

(EØS-relevant tekst)

EUROPA-KOMMISSIONEN HAR —

under henvisning til traktaten om Den Europæiske Unions funktionsmåde,

under henvisning til Europa-Parlamentets og Rådets forordning (EF) nr. 1334/2008 af 16. december 2008 om aromaer og visse fødevareingredienser med aromagivende egenskaber til anvendelse i og på fødevarer og om ændring af Rådets forordning (EØF) nr. 1601/91, forordning (EF) nr. 2232/96 og (EF) nr. 110/2008 og direktiv 2000/13/EF (1), særlig artikel 11, stk. 3,

under henvisning til Europa-Parlamentets og Rådets forordning (EF) nr. 1331/2008 af 16. december 2008 om en fælles godkendelsesprocedure for fødevaretilsætningsstoffer, fødevareenzymer og fødevarearomaer (2), særlig artikel 7, stk. 5, og

ud fra følgende betragtninger:

(1)	Bilag I til forordning (EF) nr. 1334/2008 indeholder en EU-liste over aromaer og udgangsmaterialer, der er godkendt til anvendelse i og på fødevarer, og disses anvendelsesbetingelser.

(2)	Der blev ved Kommissionens gennemførelsesforordning (EU) nr. 872/2012 (3) vedtaget en liste over aromastoffer, og listen blev indsat i del A i bilag I til forordning (EF) nr. 1334/2008.

(3)	Listen kan opdateres i overensstemmelse med den fælles procedure, jf. artikel 3, stk. 1, i forordning (EF) nr. 1331/2008, enten på Kommissionens initiativ eller som følge af en ansøgning, der er indgivet af en medlemsstat eller en interesseret part.

(4)

EU-listen over aromaer og udgangsmaterialer i bilag I til forordning (EF) nr. 1334/2008 indeholder bl.a. en række aromastoffer, for hvilke Den Europæiske Fødevaresikkerhedsautoritet (»autoriteten«) på tidspunktet for vedtagelsen af listen ved gennemførelsesforordning (EU) nr. 872/2012 ikke havde kunnet udelukke en sikkerhedsrisiko for forbrugernes sundhed på grundlag af de foreliggende data og derfor havde vurderet, at der var behov for supplerende data for at kunne afslutte evalueringen af stofferne. Disse stoffer blev optaget på EU-listen over aromastoffer, men på den betingelse, at der skulle fremlægges sikkerhedsdata til imødegåelse af de betænkeligheder, autoriteten havde givet udtryk for, inden udløbet af de specifikke frister, der er fastsat i del A i bilag I til forordning (EF) nr. 1334/2008. Blandt de stoffer, der er opført på EU-listen over aromaer og udgangsmaterialer, men hvortil der er knyttet en fodnote med krav om, at autoriteten afslutter vurderingen, var der følgende fem stoffer i Flavouring Group Evaluation 208 (FGE.208), nemlig p-mentha-1,8-dien-7-ol (FL-nr. 02.060), myrtenol (FL-nr. 02.091), myrtenal (FL-nr. 05.106), p-mentha-1,8-dien-7-ylacetat (FL-nr. 09.278) og myrtenylacetat (FL-nr. 09.302). Autoriteten anmodede om yderligere videnskabelige data, som efterfølgende blev fremlagt af ansøgerne.

(5)

I sin videnskabelige udtalelse af 24. juni 2015 (4) evaluerede autoriteten de fremlagte data og konkluderede, at det repræsentative stof for gruppen, p-mentha-1,8-dien-7-al (FL-nr. 05.117), var genotoksisk in vivo, og at anvendelse heraf som aromastof derfor gav anledning til sikkerhedsmæssige betænkeligheder.

(6)	Efter denne udtalelse trak Kommissionen stoffet tilbage fra EU-listen over aromaer ved Kommissionens forordning (EU) 2015/1760 (5).

(7)	Da p-mentha-1,8-dien-7-al (FL-nr. 05.117) er repræsentativt for fire andre stoffer, der indgår i Flavouring Group Evaluation 208 (FGE.208), trak Kommissionen disse fire stoffer tilbage fra EU-listen ved Kommissionens forordning (EU) 2016/637 (6).

(8)

For så vidt angår p-mentha-1,8-dien-7-ol (FL-nr. 02.060), myrtenol (FL-nr. 02.091), myrtenal (FL-nr. 05.106), p-mentha-1,8-dien-7-ylacetat (FL-nr. 09.278) og myrtenylacetat (FL-nr. 09.302) oplyste ansøgerne om disse stoffer, at de havde iværksat specifikke individuelle sæt toksicitetsundersøgelser af dem og adresserede de betænkeligheder, som autoriteten gav udtryk for i sin udtalelse af 24. juni 2015. Ansøgerne forpligtede sig til at fremlægge de ønskede nye oplysninger inden den 30. april 2016.

(9)

I afventning af autoritetens evaluering af disse stoffer, deres fuldstændige endelige evaluering i henhold til autoritetens panelprocedure og afslutningen af den efterfølgende reguleringsproces vedtog Kommissionen forordning (EU) 2016/1244 (7), der begrænser anvendelserne af disse aromastoffer, samtidig med at deres status som stoffer under evaluering blev opretholdt.

(10)	Ansøgerne fremlagde videnskabelige undersøgelser og andre data af relevans for evalueringen senest den 30. april 2016.

(11)

I sine udtalelser af 22. marts 2017 (8) og 11. december 2018 (9) evaluerede autoriteten de fremlagte data og supplerende data, udelukkede betænkelighederne med hensyn til genotoksicitet for disse fem stoffer og besluttede, at de kunne evalueres efter den procedure for evaluering af eksisterende aromastoffer, der er omhandlet i Kommissionens forordning (EF) nr. 1565/2000 (10). Med henblik herpå anbragte autoriteten disse fem stoffer i Flavouring Group Evaluation 73 (FGE.73). I sine udtalelser af 19. september 2017 (11) og 10. december 2020 (12) ajourførte Kommissionen evalueringerne af denne gruppe af stoffer og konkluderede, at disse stoffer ikke giver anledning til sikkerhedsmæssige betænkeligheder. Den anbefalede også at ændre navnet på og specifikationerne for nogle af disse stoffer.

(12)

I henhold til forordning (EF) nr. 1334/2008 skulle autoriteten afslutte vurderingen af følgende 20 stoffer i Flavouring Group Evaluation 203 (FGE.203 rev. 1): deca-2,4-dien-1-ol (FL-nr. 02.139), hepta-2,4-dien-1-ol (FL-nr. 02.153), hexa-2,4-dien-1-ol (FL-nr. 02.162), nona-2,4-dien-1-ol (FL-nr. 02.188), hexa-2(trans),4(trans)-dienal (FL-nr. 05.057), trideca-2(trans),4(cis),7(cis)-trienal (FL-nr. 05.064), nona-2,4-dienal (FL-nr. 05.071), 2,4-decadienal (FL-nr. 05.081), hepta-2,4-dienal (FL-nr. 05.084), penta-2,4-dienal (FL-nr. 05.101), undeca-2,4-dienal (FL-nr. 05.108), dodeca-2,4-dienal (FL-nr. 05.125), octa-2(trans),4(trans)-dienal (FL-nr. 05.127), deca-2(trans),4(trans)-dienal (FL-nr. 05.140), deca-2,4,7-trienal (FL-nr. 05.141), nona-2,4,6-trienal (FL-nr. 05.173), 2,4-octadienal (FL-nr. 05.186), tr-2,tr-4-nonadienal (FL-nr. 05.194), tr-2,tr-4-undecadienal (FL-nr. 05.196) og hexa-2,4-dienylacetat (FL-nr. 09.573). Autoriteten har anmode om yderligere videnskabelige data, som efterfølgende blev fremlagt af ansøgerne.

(13)	Stofferne hexa-2-trans,4-trans-dienal (FL-nr. 05.057) og deca-2-trans,4-trans-dienal (FL-nr. 05.140) blev anvendt som repræsentative stoffer for denne gruppe af stoffer, og der blev fremlagt toksicitetsdata om dem.

(14)	I sin videnskabelige udtalelse af 26. marts 2014 (13) evaluerede autoriteten de fremlagte data og konkluderede, at det ikke kunne udelukke sikkerhedsmæssige betænkeligheder for begge repræsentative stoffer i gruppen. Autoriteten kunne derfor ikke afslutte vurderingen af stofferne i FGE-gruppe 203.

(15)	Ansøgerne om disse stoffer anførte, at de havde iværksat en række specifikke toksicitetsundersøgelser af stofferne i denne gruppe som svar på de betænkeligheder, autoriteten gav udtryk for i sin udtalelse af 26. marts 2014.

(16)	Autoriteten anmodede om yderligere data om identitet og karakterisering samt data om produktions- og indtagsmængde for at muliggøre en korrekt eksponeringsvurdering med henblik på en fuldstændig vurdering af disse stoffers sikkerhed.

(17)

Ansøgerne forpligtede sig til at fremlægge de ønskede nye oplysninger senest den 30. september 2016. I afventning af fremlæggelsen af de supplerende data, autoritetens evaluering af disse stoffers genotoksicitet, deres fuldstændige endelige evaluering i henhold til autoritetens panelprocedure og afslutningen af den efterfølgende reguleringsproces vedtog Kommissionen forordning (EU) 2017/378 (14), der begrænser anvendelserne af disse aromastoffer, samtidig med at deres status som stoffer under evaluering blev opretholdt.

(18)	Ansøgerne fremlagde videnskabelige undersøgelser og data af relevans for evalueringen senest den 30. september 2016.

(19)

I sin udtalelse af 5. juni 2018 (15) evaluerede autoriteten de fremlagte data, udelukkede betænkelighederne med hensyn til genotoksicitet for disse stoffer og besluttede, at de kunne evalueres efter den procedure for evaluering af eksisterende aromastoffer, der er omhandlet i forordning (EF) nr. 1565/2000. Med henblik herpå anbragte autoriteten 16 af disse stoffer i Flavouring Group Evaluation 70 (FGE.70) og fire af dem i Flavouring Group Evaluation 05 (FGE.05). I sine udtalelser af 5. juni 2019 (16) og 26. juni 2019 (17) ajourførte den evalueringerne af stofferne i henholdsvis Flavouring Group Evaluation 70, Revision 1 (FGE.70 Rev1) og Flavouring Group Evaluation 05, Revision 3 (FGE.05 Rev3). For så vidt angår de 16 stoffer i FGE 70 Rev.1 konkluderede autoriteten, at de ikke giver anledning til sikkerhedsmæssige betænkeligheder, og den fremsatte anbefalinger om at ændre navn og specifikationer for nogle af disse stoffer. For så vidt angår de fire stoffer i FGE.05 Rev.3 konkluderede autoriteten, at de ikke giver anledning til sikkerhedsmæssige betænkeligheder, og den fremsatte anbefalinger om at ændre navn og specifikationer for nogle af disse fire stoffer.

(20)	Del A i bilag I til forordning (EF) nr. 1334/2008 bør derfor ændres.

(21)	Foranstaltningerne i denne forordning er i overensstemmelse med udtalelse fra Den Stående Komité for Planter, Dyr, Fødevarer og Foder —

VEDTAGET DENNE FORORDNING:

Artikel 1

Del A i bilag I til forordning (EF) nr. 1334/2008 ændres som angivet i bilaget til nærværende forordning.

Artikel 2

Denne forordning træder i kraft på tyvendedagen efter offentliggørelsen i Den Europæiske Unions Tidende.

Denne forordning er bindende i alle enkeltheder og gælder umiddelbart i hver medlemsstat.

Udfærdiget i Bruxelles, den 5. september 2022.

På Kommissionens vegne

Ursula VON DER LEYEN

Formand

(1) EUT L 354 af 31.12.2008, s. 34.

(2) EUT L 354 af 31.12.2008, s. 1.

(3) Kommissionens gennemførelsesforordning (EU) nr. 872/2012 af 1. oktober 2012 om vedtagelse af listen over aromastoffer, jf. Europa-Parlamentets og Rådets forordning (EF) nr. 2232/96, om indsættelse af listen i bilag I til Europa-Parlamentets og Rådets forordning (EF) nr. 1334/2008 og om ophævelse af Kommissionens forordning (EF) nr. 1565/2000 og Kommissionens afgørelse 1999/217/EF (EUT L 267 af 2.10.2012, s. 1).

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

(5) Kommissionens forordning (EU) 2015/1760 af 1. oktober 2015 om ændring af bilag I til Europa-Parlamentets og Rådets forordning (EF) nr. 1334/2008 for så vidt angår fjernelse af aromastoffet p-mentha-1,8-dien-7-al fra EU-listen (EUT L 257 af 2.10.2015, s. 27).

(6) Kommissionens forordning (EU) 2016/637 af 22. april 2016 om ændring af bilag I til Europa-Parlamentets og Rådets forordning (EF) nr. 1334/2008 for så vidt angår fjernelse af visse aromastoffer fra EU-listen (EUT L 108 af 23.4.2016, s. 24).

(7) Kommissionens forordning (EU) 2016/1244 af 28. juli 2016 om ændring af bilag I til Europa-Parlamentets og Rådets forordning (EF) nr. 1334/2008 for så vidt angår visse aromastoffer fra en gruppe med en alfa-beta-umættet struktur (EUT L 204 af 29.7.2016, s. 7).

(8) Scientific Opinion on Flavouring Group Evaluation 208 Revision 2 (FGE.208Rev2): Consideration of genotoxicity data on alicyclic aldehydes with a,b-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) Scientific Opinion on Flavouring Group Evaluation 208 Revision 3 (FGE.208Rev3): consideration of genotoxicity data on alicyclic aldehydes with alpha,beta-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) Kommissionens forordning (EF) nr. 1565/2000 af 18. juli 2000 om fastlæggelse af de nødvendige foranstaltninger til vedtagelse af et evalueringsprogram i henhold til Europa-Parlamentets og Rådets forordning (EF) nr. 2232/96 (EFT L 180 af 19.7.2000, s. 8).

(11) Scientific Opinion on Flavouring Group Evaluation 73, Revision 4 (FGE.73Rev4): consideration of alicyclic alcohols, aldehydes, acids and related esters evaluated by JECFA (59th and 63rd meeting) structurally related to primary saturated or unsaturated alicyclic alcohols, aldehydes, acids and esters evaluated by EFSA in FGE.12Rev5. EFSA Journal 2017;15(11):5010. doi: 10.2903/j.efsa.2017.5010. Findes på: www.efsa.europa.eu/efsajournal.

(12) Scientific Opinion on Flavouring Group Evaluation 73, Revision 5 (FGE.73Rev5): consideration of alicyclic alcohols, aldehydes, acids and related esters evaluated by JECFA (59th, 63rd and 86th meeting) and structurally related to substances evaluated in FGE.12Rev5, EFSA Journal 2020;18(1):5970. doi: 10.2903/j.efsa.2020.5970. Foreligger online: www.efsa.europa.eu/efsajournal.

(13) Scientific Opinion on Flavouring Group Evaluation 203 Rev 1 (FGE.203 Rev1): EFSA's CEF-panel (EFSA's Ekspertpanel for Materialer, der Kommer i Berøring med Fødevarer, Enzymer, Smagsstoffer og Hjælpestoffer, der Anvendes i Fødevarer), 2014. Scientific Opinion on Flavouring Group Evaluation 203 Revision 1 (FGE.203Rev1): α,β-unsaturated aliphatic aldehydes and precursors from chemical subgroup 1.1.4 of FGE.19 with two or more conjugated double-bonds and with or without additional non-conjugated double-bonds. EFSA Journal 2014;12(4):3626, 31 s. doi:10.2903/j.efsa.2014.3626. Foreligger online: www.efsa.europa.eu/efsajournal.

(14) Kommissionens forordning (EU) 2017/378 af 3. marts 2017 om ændring af bilag I til Europa-Parlamentets og Rådets forordning (EF) nr. 1334/2008 for så vidt angår visse aromastoffer (EUT L 58 af 4.3.2017, s. 14).

(15) Scientific Opinion on Flavouring Group Evaluation 203, Revision 2 (FGE.203Rev2): alpha,beta-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) Scientific Opinion on Flavouring Group Evaluation 70, Revision 1 (FGE.70Rev1): consideration of aliphatic, linear, α,β-unsaturated, di- and trienals and related alcohols, acids and esters evaluated by JECFA (61st-68th-69th meeting). EFSA Journal 2019;17(7):5749.

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

BILAG

I del A, afsnit 2, tabel 1, i bilag I til forordning (EF) nr. 1334/2008 foretages følgende ændringer:

Rækken vedrørende FL-nr. 02.060 affattes således:

»02.060

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

536-59-4

974

2024

EFSA«

Rækken vedrørende FL-nr. 02.091 affattes således:

»02.091

myrtenol

515-00-4

981

10285

EFSA«

Rækken vedrørende FL-nr. 02.139 affattes således:

»02.139

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

18409-21-7

1189

11748

EFSA«

Rækken vedrørende FL-nr. 02.153 affattes således:

»02.153

hepta-2,4-dien-1-ol

33467-79-7

1784

EFSA«

Rækken vedrørende FL-nr. 02.162 affattes således:

»02.162

hexa-2,4-dien-1-ol

111-28-4

1174

EFSA«

Rækken vedrørende FL-nr. 02.188 affattes således:

»02.188

nona-2,4-dien-1-ol

62488-56-6

1183

11802

Mindst 92 %; sekundær bestanddel: 3-4 % 2-nonen-1-ol

EFSA«

Rækken vedrørende FL-nr. 05.057 affattes således:

»05.057

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

142-83-6

1175

640

EFSA«

Rækken vedrørende FL-nr. 05.064 affattes således:

»05.064

trideca-2-trans,4-cis,7-cis-trienal

13552-96-0

1198

685

Mindst 71 %; sekundære bestanddele: 14 % 4-cis-7-cis-tridecadienol, 6 % 3-cis-7-cis- tridecadienol, 5 % 2-trans-7-cis-tridecadienal og 3 % 2-trans-4-trans-7-cis-tridecatrienal

EFSA«

Rækken vedrørende FL-nr. 05.071 affattes således:

»05.071

nona-2,4-dienal

6750-03-4

1185

732

Mindst 89 %; sekundære bestanddele: 5-6 % 2,4-nonadien-1-ol og 1-2 % 2-nonen-1-ol

EFSA«

Rækken vedrørende FL-nr. 05.081 affattes således:

»05.081

2,4-decadienal

2363-88-4

3135

2120

Mindst 89 %; sekundære bestanddele: blanding af (cis, cis)-, (cis, trans)- og (trans, cis)-2,4-decadienal (summen af alle isomerer: 95 %), acetone og isopropanol

EFSA«

Rækken vedrørende FL-nr. 05.084 affattes således:

»05.084

hepta-(2E,4E)-dienal

4313-03-5

1179

729

Mindst 92 %; sekundære bestanddele: 2-4 % (E,Z)-2,4-heptadienal og 2-4 % 2,4-heptadiensyre

EFSA«

Rækken vedrørende FL-nr. 05.101 affattes således:

»05.101

penta-2,4-dienal

764-40-9

1173

11695

EFSA«

Rækken vedrørende FL-nr. 05.106 affattes således:

»05.106

myrtenal

564-94-3

980

10379

EFSA«

Rækken vedrørende FL-nr. 05.108 affattes således:

»05.108

undeca-2,4-dienal

13162-46-4

1195

10385

EFSA«

Rækken vedrørende FL-nr. 05.125 affattes således:

»05.125

dodeca-(2E,4E)-dienal

21662-16-8

1196

11758

Mindst 85 %; sekundær bestanddel: 11-12 % 2-trans-4-cis-isomer

EFSA«

Rækken vedrørende FL-nr. 05.127 affattes således:

»05.127

octa-2-trans,4-trans-dienal

30361-28-5

1181

11805

EFSA«

Rækken vedrørende FL-nr. 05.140 affattes således:

»05.140

deca-2-trans,4-trans-dienal

25152-84-5

1190

2120

Mindst 90 % af (E, E)-isomeren, 95 % (summen af isomerer)

EFSA«

Rækken vedrørende FL-nr. 05.141 affattes således:

»05.141

deca-2,4,7-trienal

51325-37-2

1786

EFSA«

Rækken vedrørende FL-nr. 05.173 affattes således:

»05.173

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

57018-53-8

1785

EFSA«

Rækken vedrørende FL-nr. 05.186 affattes således:

»05.186

2,4-octadienal

5577-44-6

11805

Mindst 85 % E,E med 10 % E, Z

EFSA«

Rækken vedrørende FL-nr. 05.194 affattes således:

»05.194

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

5910-87-2

732

Mindst 89 %; sekundære bestanddele: mindst 5 % 2,4-nonadien-1-ol og 2-nonen-1-ol og andre isomerer af 2,4-nonadienal

EFSA«

Rækken vedrørende FL-nr. 05.196 affattes således:

»05.196

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

EFSA«

Rækken vedrørende FL-nr. 09.278 affattes således:

»09.278

p-mentha-1,8-dien-7-ylacetat

15111-96-3

975

10742

EFSA«

Rækken vedrørende FL-nr. 09.302 affattes således:

»09.302

myrtenylacetat

35670-93-0

982

10887

EFSA«

Rækken vedrørende FL-nr. 09.573 affattes således:

»09.573

hexa-2,4-dienylacetat

1516-17-2

1780

10675

EFSA«

6.9.2022

Den Europæiske Unions Tidende

L 231/36

KOMMISSIONENS GENNEMFØRELSESFORORDNING (EU) 2022/1467

af 5. september 2022

om ændring af gennemførelsesforordning (EU) 2015/2378 for så vidt angår de standardformularer og elektroniske formater, der anvendes i forbindelse med Rådets direktiv 2011/16/EU, og listen over statistiske oplysninger, som medlemsstaterne skal fremsende med henblik på evaluering af nævnte direktiv

EUROPA-KOMMISSIONEN HAR —

under henvisning til traktaten om Den Europæiske Unions funktionsmåde,

under henvisning til Rådets direktiv 2011/16/EU af 15. februar 2011 om administrativt samarbejde på beskatningsområdet og om ophævelse af direktiv 77/779/EØF (1), særlig artikel 20, stk. 4,

ud fra følgende betragtninger:

(1)	Direktiv 2011/16/EU blev ændret ved direktiv (EU) 2021/514 (2) for at forbedre de bestemmelser, der vedrører alle former for udveksling af oplysninger og administrativt samarbejde, ved at indføre obligatorisk automatisk udveksling af oplysninger, der indberettes af platformsoperatør.

(2)	Kommissionens gennemførelsesforordning (EU) 2015/2378 (3) bør derfor tilpasses disse ændringer. Den automatiske udveksling af oplysninger i henhold til artikel 8ac, stk. 2, i direktiv 2011/16/EU bør ske ved hjælp af et elektronisk standardformat.

(3)	I overensstemmelse med direktiv 2011/16/EU er det også nødvendigt at fastlægge de praktiske bestemmelser for registrering og identifikation af visse Indberettende Platformsoperatør i henhold til artikel 8ac, stk. 4.

(4)

I henhold til artikel 8ac, stk. 6, i direktiv 2011/16/EU bør der oprettes et centralt register til registrering af de oplysninger, hvorom der skal underrettes i overensstemmelse med artikel 8ac, stk. 5, og som skal meddeles i overensstemmelse med bilag V, afdeling IV, afsnit F, punkt 2 og 4. Dette centrale register bør være tilgængeligt for de kompetente myndigheder i medlemsstaterne. Der bør anvendes en standardformular til meddelelse og registrering af sådanne oplysninger.

(5)

I henhold til artikel 23, stk. 4, i direktiv 2011/16/EU skal medlemsstaterne fremsende en liste over statistiske oplysninger med henblik på evaluering af direktivet. Af hensyn til sammenhængen og retssikkerheden bør datoen, fra hvilken nærværende forordning finder anvendelse, være den samme som den anvendelsesdato, der er fastsat i artikel 2, stk. 1, andet afsnit, i direktiv (EU) 2021/514.

(6)	Den Europæiske Tilsynsførende for Databeskyttelse er blevet hørt om foranstaltningerne i forordningen i overensstemmelse med artikel 42, stk. 1, i Europa-Parlamentets og Rådets forordning (EU) 2018/1725 (4).

(7)	Foranstaltningerne i denne forordning er i overensstemmelse med udtalelse fra Udvalget for Administrativt Samarbejde på Beskatningsområdet —

VEDTAGET DENNE FORORDNING:

Artikel 1

I gennemførelsesforordning (EU) 2015/2378 foretages følgende ændringer:

1)	I artikel 2 tilføjes følgende stk. 3: »3. Det elektroniske format, der anvendes i forbindelse med den obligatoriske automatiske udveksling af oplysninger i henhold til artikel 8ac, stk. 2, i direktiv 2011/16/EU, skal indeholde de felter, der er omhandlet i bilag XIV til nærværende forordning.«

2)	I artikel 2d, stk. 1, tilføjes følgende: »Listen over de statistiske oplysninger, der kræves i forbindelse med obligatorisk automatisk udveksling af oplysninger i henhold til artikel 8ac i direktiv 2011/16/EU, er fastsat i bilag XV til nærværende forordning.«

Som artikel 2f indsættes:

»Artikel 2f

Standardformularer til meddelelse af oplysninger om Undtagne Platformsoperatører og Udenlandske Platformsoperatører til det centrale register, formatet for det individuelle identifikationsnummer for Udenlandske Platformsoperatører og opbevaringsperioden for oplysninger, der slettes fra det centrale register

1. Den formular, der anvendes til meddelelse af oplysninger om Undtagne Platformsoperatører og Udenlandske Platformsoperatører til det centrale register i henhold til artikel 8ac, stk. 6, i direktiv 2011/16/EU, skal være i overensstemmelse med bilag XVI til nærværende forordning.

2. De centrale elementer, der registreres i det centrale register, jf. artikel 8ac, stk. 6, i direktiv 2011/16/EU, er de oplysninger, der er anført i afdeling IV, afsnit F, punkt 2 og 4, i bilag V til nævnte direktiv og bilag XVI til nærværende forordning. Oprettelsen af det centrale register og Kommissionens behandling af personoplysninger i det centrale register på vegne af medlemsstaternes kompetente myndigheder finder sted i overensstemmelse med Europa-Parlamentets og Rådets forordning (EU) 2016/679 (*1) og (EU) 2018/1725 (*2). De kompetente myndigheder i medlemsstaterne betragtes som dataansvarlige, og Kommissionen betragtes som databehandler, jf. forordning (EU) 2016/679.

3. Formatet for det individuelle identifikationsnummer for Udenlandske Platformsoperatører, jf. artikel 8ac, stk. 4, i direktiv 2011/16/EU, er fastsat i bilag XVI til nærværende forordning.

4. Opbevaringsperioden for oplysninger, der slettes fra det centrale register, jf. bilag V, afdeling IV, afsnit F, punkt 5, litra d), og artikel 8ac, stk. 5, i direktiv 2011/16/EU, er fastsat i bilag XVI til nærværende forordning.

(*1) Europa-Parlamentets og Rådets forordning (EU) 2016/679 af 27. april 2016 om beskyttelse af fysiske personer i forbindelse med behandling af personoplysninger og om fri udveksling af sådanne oplysninger og om ophævelse af direktiv 95/46/EF (generel forordning om databeskyttelse) (EUT L 119 af 4.5.2016, s. 1)."

(*2) Europa-Parlamentets og Rådets forordning (EU) 2018/1725 af 23. oktober 2018 om beskyttelse af fysiske personer i forbindelse med behandling af personoplysninger i Unionens institutioner, organer, kontorer og agenturer og om fri udveksling af sådanne oplysninger og om ophævelse af forordning (EF) nr. 45/2001 og afgørelse nr. 1247/2002/EF (EUT L 295 af 21.11.2018, s. 39).«"

4)	Bilag I, IX og X affattes som angivet i bilag I til nærværende forordning.

5)	Bilag V ændres som angivet i bilag II til nærværende forordning.

6)	Bilag XIV, XV og XVI, som fastsat i bilag III til denne forordning, tilføjes.

Artikel 2

Denne forordning træder i kraft på tyvendedagen efter offentliggørelsen i Den Europæiske Unions Tidende.

Den anvendes fra den 1. januar 2023.

Denne forordning er bindende i alle enkeltheder og gælder umiddelbart i hver medlemsstat.

Udfærdiget i Bruxelles, den 5. september 2022.

På Kommissionens vegne

Ursula VON DER LEYEN

Formand

(1) EUT L 64 af 11.3.2011, s. 1.

(2) Rådets direktiv (EU) 2021/514 af 22. marts 2021 om ændring af direktiv 2011/16/EU om administrativt samarbejde på beskatningsområdet (EUT L 104 af 25.3.2021, s. 1).

(3) Kommissionens gennemførelsesforordning (EU) 2015/2378 af 15. december 2015 om gennemførelsesbestemmelser til visse bestemmelser i Rådets direktiv 2011/16/EU om administrativt samarbejde på beskatningsområdet og om ophævelse af gennemførelsesforordning (EU) nr. 1156/2012 (EUT L 332 af 18.12.2015, s. 1).

(4) Europa-Parlamentets og Rådets forordning (EU) 2018/1725 af 23. oktober 2018 om beskyttelse af fysiske personer i forbindelse med behandling af personoplysninger i Unionens institutioner, organer, kontorer og agenturer og om fri udveksling af sådanne oplysninger og om ophævelse af forordning (EF) nr. 45/2001 og afgørelse nr. 1247/2002/EF (EUT L 295 af 21.11.2018, s. 39).

BILAG I

Bilag I, IX og X affattes således:

"BILAG I

Formular, der er omhandlet i artikel 1, stk. 2

Den formular, der anvendes i forbindelse med anmodninger om oplysninger og administrative undersøgelser i henhold til artikel 5 og 5a i direktiv 2011/16/EU og de relevante svar, bekræftelser, anmodninger om supplerende baggrundsmateriale, afvisninger og afslag i henhold til artikel 7 i direktiv 2011/16/EU, skal indeholde følgende felter (1):

—	retsgrundlag

—	referencenummer

—

dato

—	identiteten på den bistandssøgende og den bistandssøgte myndighed

—	identiteten på den person, hvis forhold undersøges eller efterforskes

—

generel beskrivelse af sagen og foreliggende specifikt baggrundsmateriale, der må formodes at gøre det muligt at vurdere, om de søgte oplysninger kan forudses at være relevante for administrationen og håndhævelsen af medlemsstaternes nationale love vedrørende de i artikel 2 i direktiv 2011/16/EU omhandlede skatter

—	det skattemæssige formål med at søge oplysningerne

—	den undersøgte periode

—	navn og adresse på enhver person, der menes at være i besiddelse af de søgte oplysninger

—	opfyldelse af de lovkrav, der er fastsat i artikel 16, stk. 1, i direktiv 2011/16/EU

—	opfyldelse af de lovkrav, der er fastsat i artikel 17, stk. 1, i direktiv 2011/16/EU

—	begrundet anmodning om en administrativ undersøgelse og begrundelser for afslag om at indlede den anmodede administrative undersøgelse

—	bekræftelse på anmodningen om oplysninger

—	anmodninger om supplerende baggrundsmateriale

—	begrundelser for afvisninger og afslag på udlevering af oplysninger

—	begrundelser for manglende svar inden for den relevante tidsfrist og den dato, inden hvilken den bistandssøgte myndighed forventer at ville kunne svare

—	en detaljeret beskrivelse af gruppen.

"BILAG IX

Liste, der er omhandlet i artikel 2d

De statistiske oplysninger, der kræves i forbindelse med andre former for administrativt samarbejde end obligatorisk automatisk udveksling af oplysninger, jf. artikel 23, stk. 4, i direktiv 2011/16/EU, skal omfatte følgende oplysninger:

—	identifikation af medlemsstaten

—

år

—

del A: medlemsstatsopdelt statistik over udveksling af oplysninger

—

om udveksling af oplysninger efter anmodning (artikel 5, 6 og 7 i direktiv 2011/16/EU)

—	antal sendte anmodninger

—	antal modtagne svar

—	antal fuldstændige svar modtaget inden for den lovbestemte frist

—	antal svar, hvor (en del af eller alle) oplysningerne blev modtaget inden for to måneder

—	antal modtagne anmodninger

—	antal sendte svar

—	antal afslag på grundlag af artikel 17 i direktiv 2011/16/EU

—

om udveksling af oplysninger om gruppeanmodninger (artikel 5a i direktiv 2011/16/EU)

—	antal sendte gruppeanmodninger

—	antal modtagne gruppesvar

—	antal fuldstændige gruppesvar modtaget inden for den lovbestemte frist

—	antal gruppesvar, hvor (en del af eller alle) oplysningerne blev modtaget inden for to måneder

—	antal modtagne gruppeanmodninger

—	antal sendte gruppesvar

—	antal gruppeafslag på grundlag af artikel 17 i direktiv 2011/16/EU

—

om spontan udveksling af oplysninger (artikel 9 og 10 i direktiv 2011/16/EU)

—	antal sendte spontane udvekslinger

—	antal modtagne spontane udvekslinger

—

del B: statistik over andre former for administrativt samarbejde

—

om tilstedeværelse i administrative kontorer og deltagelse i administrative undersøgelser (artikel 11 i direktiv 2011/16/EU)

—	antal indgående tilstedeværelser i administrative kontorer og deltagelse i administrative undersøgelser

—	antal udgående tilstedeværelser i administrative kontorer og deltagelse i administrative undersøgelser

—

om samtidig kontrol (artikel 12 i direktiv 2011/16/EU)

—	antal samtidige kontroller, som medlemsstaten har igangsat

—	antal samtidige kontroller, hvori medlemsstaten har deltaget

—

om anmodning om meddelelse (artikel 13 i direktiv 2011/16/EU)

—	antal sendte anmodninger om meddelelse

—	antal modtagne anmodninger om meddelelse

—

om feedback (artikel 14 i direktiv 2011/16/EU)

—	antal sendte anmodninger om feedback

—	antal modtagne feedback-meldinger

—	antal modtagne anmodninger om feedback

—	antal sendte feedback-meldinger

—

del C: statistik over skønnet indkomststigning eller stigning i skatteansættelse som følge af administrativt samarbejde. Oplysningerne i denne del er valgfrie

—	fra udveksling af oplysninger efter anmodning

—	fra spontan udveksling af oplysninger

—	som følge af samtidig kontrol

—	i alt og antal tilfælde.

"BILAG X

Liste, der er omhandlet i artikel 2d

De statistiske oplysninger, der kræves i forbindelse med obligatorisk automatisk udveksling af oplysninger, jf. artikel 23, stk. 4, i direktiv 2011/16/EU, for så vidt angår de kategorier af indkomst og kapital, der er omhandlet i nævnte direktivs artikel 8, stk. 1, skal omfatte følgende oplysninger:

—	for alle kategorier af indkomst og kapital, der er omhandlet i artikel 8, stk. 1, i direktiv 2011/16/EU: statistik over meddelelser og skattepligtige

—	i tilfælde af arbejdsindtægt samt tantiemer og bestyrelseshonorarer: statistik over meddelelser og modtagere, meddelelser og betalere, modtagere og relation, betalere og relation, modtagere og indkomst

—	i tilfælde af pensioner: statistik over meddelelser og modtagere, meddelelser og betalere, modtagere, betalere, ordninger, indkomst

—	i tilfælde af livsforsikringsprodukter: statistik over meddelelser og policer, policer generelt, hændelser

—	i tilfælde af ejendomsret til og indtægt fra fast ejendom: statistik over meddelelser og parter, parter generelt, ejendom — antal og værdi, transaktion — antal og værdi, lån — antal og værdi, indtægter fra rettigheder — antal og værdi

—	i tilfælde af indtægter fra royalties: statistik over meddelelser og modtagere, meddelelser og betalere, modtagere og indkomst

—	i tilfælde af statusmeddelelser: statistik over statusmeddelelser, fejl i statusmeddelelser

—	i tilfælde af nuldatameddelelser: statistik om nuldatameddelelser.

(1) Bemærk, at det kun er de felter, der rent faktisk udfyldes i forbindelse med en given sag, der behøver at fremgå af formularen.

BILAG II

I punkt (b) i bilag V affattes overskriften således:

"(b)	Hvad angår teksten til meddelelse af oplysninger om lønindkomst, bestyrelseshonorarer eller royalties:"

BILAG III

Som bilag XIV, XV og XVI indsættes:

"BILAG XIV

Elektronisk format, jf. artikel 2, stk. 3

De elektroniske formater, der anvendes i forbindelse med obligatorisk automatisk udveksling af oplysninger i henhold til artikel 8ac, stk. 2, i direktiv 2011/16/EU, skal overholde følgende træstruktur og indeholde følgende elementer og attributter (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>

"BILAG XV

Liste, der er omhandlet i artikel 2d

De statistiske oplysninger, der, jf. artikel 23, stk. 4, i direktiv 2011/16/EU, kræves i forbindelse med obligatorisk udveksling af oplysninger i overensstemmelse med nævnte direktivs artikel 8ac, stk. 2, skal omfatte følgende oplysninger:

—	pr. meddelelse, statistik over det samlede antal indberetninger, der modtages fra de Indberettende Platformsoperatører med henblik på obligatorisk automatisk udveksling af oplysninger

—	pr. meddelelse, statistik over det samlede antal indberetninger modtaget fra hver enkelt medlemsstat

—

pr. Sælger, hvorom der skal indberettes, statistik over den type Sælger, hvorom der skal indberettes, skatteregistreringsnummer eller tilsvarende, bopælsmedlemsstat for den Sælger, hvorom der skal indberettes, og begrundelse for udvekslingen bopælsmedlemsstat for den Sælger, hvorom der skal indberettes, og/eller den medlemsstat, hvor den faste ejendom er beliggende

—	pr. Indberettende Platformsoperatør, statistikker over relevant aktivitetstype og modydelse og type ejendom.

"BILAG XVI

Formular, der er omhandlet i artikel 2f, stk. 1

Den formular, der skal anvendes til meddelelse af oplysninger om Undtagne Platformsoperatører i henhold til artikel 8ac, stk. 6, i direktiv 2011/16/EU og til meddelelse af oplysninger om Udenlandske Platformsoperatører i henhold til afdeling IV, afsnit F, punkt 2 og 4, i bilag V til direktiv 2011/16/EU, skal indeholde følgende felter:

(a)	navn på den Undtagne Platformsoperatør

(b)	postadresse for den Undtagne Platformsoperatør

(c)	elektronisk adresse, herunder websteder, for den Undtagne Platformsoperatør

(d)	eventuelle skatteregistreringsnumre udstedt til den Undtagne Platformsoperatør, hvis et sådant findes

(e)	medlemsstat, over for hvem godtgørelsen, jf. afdeling I, afsnit A, punkt 3, i bilag V til direktiv 2011/16/EU, er blevet forelagt samt

(f)	det regnskabsår, fra hvilket status som Undtaget Platformsoperatør blev tildelt.

Format for det individuelle identifikationsnummer for Udenlandske Platformsoperatører

Det individuelle identifikationsnummer består af følgende 12-cifrede format, CCYYYYXXXXXX, hvor: CC er ISO-landekoden for den medlemsstat, der har udstedt det individuelle identifikationsnummer, YYYY er det år, hvor den Udenlandske Platformsoperatør registreres i den medlemsstat, hvor den enkelte registrering finder sted, og XXXXXX er en unik række tegn, der består af bogstaver og/eller tal.

Opbevaringsperiode for visse oplysninger, der er slettet eller fjernet fra det centrale register

Hvis registreringen af en Indberettende Platformsoperatør, jf. afdeling I, afsnit A, punkt 4, litra b), i bilag V til direktiv 2011/16/EU, som ændret ved direktiv (EU) 2021/514, tilbagekaldes i overensstemmelse med afdeling IV, afsnit F, punkt 7, i bilag V til direktiv 2011/16/EU, sletter den medlemsstat, hvor den enkelte registrering finder sted, den Indberettende Platformsoperatør fra det centrale register. Det centrale register opbevarer de slettede oplysninger, jf. afdeling IV, afsnit F, punkt 2 og 4, i bilag V til direktiv 2011/16/EU, i højst 12 måneder fra datoen for sletningen.

Oplysninger, der er registreret i det centrale register over Undtagne Platformsoperatører, vil blive fjernet, hvis en Undtaget Platformsoperatør, jf. afdeling I, afsnit A, punkt 3, i bilag V til direktiv 2011/16/EU, som ændret ved direktiv (EU) 2021/514, ikke på forhånd og årligt tilfredsstillende har godtgjort over for den kompetente myndighed i den medlemsstat, til hvem Platformsoperatøren i henhold til de regler, der er fastsat i afdeling III, afsnit A, punkt 1-3, i bilag V til direktiv 2011/16/EU, ellers ville skulle indberette, at hele Platformens forretningsmodel er af en sådan art, at den ikke har Sælgere, hvorom der skal indberettes. Det centrale register opbevarer de fjernede oplysninger, der er omhandlet i litra a)-f) i bilag XVI til nærværende forordning, i højst 12 måneder fra datoen for fjernelsen af de registrerede oplysninger.

(1) Bemærk, at det kun er de elementer og attributter, der rent faktisk finder anvendelse i forbindelse med en given sag i forbindelse med de regler om passende omhu og indberetning i afdeling II og III i bilag V til Rådets direktiv 2011/16/EU, som ændret ved Rådets direktiv (EU) 2021/514, der behøver at fremgå at det elektroniske format.

		ISSN 1977-0634
Den Europæiske Unions Tidende		L 231

Dansk udgave	Retsforskrifter	65. årgang 6. september 2022

Indhold		II Ikke-lovgivningsmæssige retsakter	Side
		FORORDNINGER
	*	Kommissionens gennemførelsesforordning (EU) 2022/1463 af 5. august 2022 om fastsættelse af tekniske og operationelle specifikationer for det tekniske system til grænseoverskridende elektronisk udveksling af dokumentation og anvendelse af engangsprincippet i overensstemmelse med Europa-Parlamentets og Rådets forordning (EU) 2018/1724 ( 1 )	1
	*	Kommissionens gennemførelsesforordning (EU) 2022/1464 af 2. september 2022 om ændring af Rådets forordning (EF) nr. 1210/2003 om visse specifikke restriktioner i de økonomiske og finansielle forbindelser med Irak	22
	*	Kommissionens forordning (EU) 2022/1465 af 5. september 2022 om ændring af bilag I til Europa-Parlamentets og Rådets forordning (EF) nr. 1334/2008 for så vidt angår visse aromastoffer ( 1 )	24
	*	Kommissionens forordning (EU) 2022/1466 af 5. september 2022 om ændring af bilag I til Europa-Parlamentets og Rådets forordning (EF) nr. 1334/2008 for så vidt angår fjernelse af visse aromastoffer fra EU-listen ( 1 )	32
	*	Kommissionens gennemførelsesforordning (EU) 2022/1467 af 5. september 2022 om ændring af gennemførelsesforordning (EU) 2015/2378 for så vidt angår de standardformularer og elektroniske formater, der anvendes i forbindelse med Rådets direktiv 2011/16/EU, og listen over statistiske oplysninger, som medlemsstaterne skal fremsende med henblik på evaluering af nævnte direktiv	36
	*	Kommissionens gennemførelsesforordning (EU) 2022/1468 af 5. september 2022 om ændring af gennemførelsesforordning (EU) nr. 540/2011 for så vidt angår betingelserne for godkendelse af aktivstoffet penflufen og om ophævelse af gennemførelsesforordning (EU) 2018/185 ( 1 )	101
	*	Kommissionens gennemførelsesforordning (EU) 2022/1469 af 5. september 2022 om godkendelse af L-lysinsulfat produceret af Escherichia coli CGMCC 7.398 som tilsætningsstof til foder til alle dyrearter ( 1 )	105
	*	Kommissionens gennemførelsesforordning (EU) 2022/1470 af 5. september 2022 om godkendelse af endo-1,4-beta-xylanase produceret af Trichoderma longibrachiatum CBS 139997 og alpha-galactosidase produceret af Aspergillus tubingensis ATCC SD 6740 som tilsætningsstof til foder til slagtekyllinger, hønniker, mindre udbredte fjerkræarter bestemt til slagtning og opdrættet til æglægning samt prydfugle (indehaver af godkendelsen er Industrial Técnica Pecuaria S.A.) ( 1 )	109
	*	Kommissionens gennemførelsesforordning (EU) 2022/1471 af 5. september 2022 om godkendelse af lanthancarbonatoctahydrat som tilsætningsstof til foder til katte (indehaver af godkendelsen er Porus GmbH) ( 1 )	113
	*	Kommissionens gennemførelsesforordning (EU) 2022/1472 af 5. september 2022 om godkendelse af manganlysinatsulfat som tilsætningsstof til foder til alle dyrearter ( 1 )	116

»07.030	1-(4-methoxyphenyl)pent-1-en-3-on	104-27-8	826	164		2	EFSA
07.046	vanillylidenacetone	1080-12-2	732	691		2	EFSA
07.049	1-(4-methoxyphenyl)-4-methylpent-1-en-3-on	103-13-9	829	719		2	EFSA
07.206	4-(2,3,6-trimethylphenyl)but-3-en-2-on	56681-06-2				2	EFSA
07.258	6-methyl-3-hepten-2-on	2009-74-7				1	EFSA
10.034	5,6-dihydro-3,6-dimethylbenzofuran-2 (4H)-on	80417-97-6	1163			2	EFSA
10.036	5,6,7,7a-tetrahydro-3,6-dimethylbenzofuran-2(4H)-on	13341-72-5	1162			2	EFSA
10.042	3,4-dimethyl-5-pentylidenfuran-2(5H)-on	774-64-1		11873	Mindst 93 %; sekundær bestanddel: 1-2 % 3,4-dimethyl-5-ketobutansyregamma-lacton	2	EFSA
10.043	2,7-dimethylocta-5(trans),7-dien-1,4-lacton	78548-56-8				2	EFSA
10.046	hex-2-en-1,4-lacton	2407-43-4				2	EFSA
10.054	non-2-en-1,4-lacton	21963-26-8				2	EFSA
10.060	2-decen-1,4-lacton	2518-53-8				2	EFSA
10.170	5-pentyl-3H-pyran-2-on	51352-68-2	1989		Blanding af 3H- og 5H-isomerer (2:1)	2	EFSA
13.004	allyl-2-furoat	4208-49-5	21	360		2	EFSA
13.034	3-(2-furyl)acrylaldehyd	623-30-3	1497			1	EFSA
13.043	furfuryliden-2-butanal	770-27-4	1501	11885		1	EFSA
13.044	4-(2-furyl)but-3-en-2-on	623-15-4	1511	11838		1	EFSA
13.046	3-(2-furyl)-2-methylprop-2-enal	874-66-8	1498	11878		1	EFSA
13.066	3-acetyl-2,5-dimethylfuran	10599-70-9	1506	10921		4	EFSA
13.103	2-butylfuran	4466-24-4	1490	10927		3	EFSA
13.137	3-(2-furyl)-2-phenylprop-2-enal	65545-81-5	1502	11928		1	EFSA
13.150	3-(5-methyl-2-furyl)prop-2-enal	5555-90-8	1499			1	EFSA«


	(1) EØS-relevant tekst.