Dossier

Context

In een uitbreiding van het SDG-verhaal voorziet Europa een oplossing voor informatieuitwisseling betreffende kortetermijnverhuur van accommodaties (Short Term Accommodation Rental services). Deze STR’s zijn plaatsen (units) die worden verhuurd en aangeboden aan het brede publiek om te verblijven, en dit gedurende korte tijd. Hotels, campings, … vallen buiten de scope. De STR’s worden typisch aangeboden op gespecialiseerde platformen (zoals bvb airbnb). Europa wil dat lidstaten voor de informatieuitwisseling gebruik maken van een zgn Single Digital Entry Point (SDEP). Men voorziet één SDEP per land. Dit SDEP is verantwoordelijk voor het vormen van een abstractielaag tussen STR-platformen enerzijds en verantwoordelijke overheden (CA’s, Competent Authorities) anderzijds. In België bestaan er al registers voor het Vlaams gewest, Waals gewest, Brussel, en de Duitstalige gemeenschap. In Vlaanderen neemt Toerisme Vlaanderen een duorol op: zij zijn tegenlijk de bevoegde autoriteit èn zij beheren tevens het register dat registratienummers toekent voor STR’s op het Vlaamse grondgebied.

*** Update 30/4/24: De STR-verordening (Verordening (EU) 2024/1028 van het Europees Parlement en de Raad van 11 april 2024 betreffende het verzamelen en delen van gegevens met betrekking tot diensten voor kortetermijnverhuur van accommodatie en tot wijziging van Verordening (EU) 2018/1724) is intussen gepubliceerd. De tekst is hier terug te vinden in alle EU-talen. De verordening treedt in werking op 19 mei 2024 (20 dagen na publicatie). Vanaf dan is er 2 jaar de tijd voor implementatie, dus:

HL integratie architectuur

Onder begeleiding van PwC zal een proof of concept ontwikkeld worden voor het SDEP (Zie https://github.com/SEMICeu/STR-AP/tree/main/prototype ). Deze code kan desgewenst hergebruikt worden door de verschillende lidstaten. De werking en de features van het SDEP en mede het integrale systeem worden momenteel nog besproken, maar voorlopig zijn dit de vaststellingen:

• De host (eigenaar/verhuurder van een STR) registreert zijn STR bij het officiële register van een lidstaat (of regio van een lidstaat). Voor Vlaanderen is dit bvb in handen van Toerisme Vlaanderen. Na registratie ontvangt de host een uniek registratienummer voor dat specifieke STR.

• De host kan zijn STR op verschillende platformen (bvb airbnb) te huur aanbieden (we spreken dan van een “listing” van de STR). Tijdens die procedure biedt het STR-platform tevens de kans om een registratienummer in te vullen voor het STR, indien de host hierover beschikt. Dat laatste is niet altijd het geval: voor accomodaties die zich bevinden buiten een gebied waarbinnen de STR-wetgeving van toepassing is zijn vrijgesteld van de verplichting om een registratienummer te hebben, net als hotels (ook al bevinden zich deze binnen een toepassend gebied). Het is de rol van de CA’s om op frequente basis deze gebieden up to date te houden.

• Tijdens het maken van een listing op een platform zal het platform controleren of de STR zich in een gebied bevindt dat onderhevig is aan de STR-wetgeving. Het platform kan al deze gebieden voor een land opvragen bij het SDEP van dat land.

• Wanneer tijdens de listing géén registratienummer wordt meegegeven zal het STR-platform een listing doorgeven aan het SDEP, dat op zijn beurt verantwoordelijk is voor het doorsturen van deze data naar de verantwoordelijke CA. De CA kan dan de nodige controles uitvoeren. Opmerking: het is nog onduidelijk of de listing ook zal doorgegeven worden als de STR wél een registratienummer heeft.

• Eens om de zoveel tijd (bvb maandelijks) geeft het platform alle activiteitsdata door binnen een bepaald gebied aan het SDEP. Dat laatste geeft deze activiteitsdata verder door aan een collector in de regio. Voor Vlaanderen is Toerisme Vlaanderen niet alleen verantwoordelijk voor het beheer van het register, maar ook voor het invullen van deze collector rol.

• STR-platformen maken deze alle bovenstaande calls via een API van het SDEP. De beveiliging hiervan gebeurt via OAUTH2 (en dus moeten de STR-platformen die het recht hebben om dit soort calls te maken gekend zijn bij het SDEP.

De afspraken op Europees niveau behandelen het contract en de interfacing van het SDEP richting de platformen, daar dit voor alle Europese lidstaten hetzelfde concept is. Hoe het SDEP achter de schermen communiceert met de verschillende CA’s in een lidstaat moet elke lidstaat voor zichzelf bekijken.

De epics en user stories voor het SDEP zijn te vinden op https://github.com/SEMICeu/STR-AP/blob/main/prototype/3.%20Testing/Endpoints.md.

Transmissie van data naar Eurostat

Initieel leek de collectie van data bij Eurostat (of andere Europese statistieken) ook deel uit te maken van het plaatje. De laatste informatie vertelt dat dit een zaak is van de CA’s per EU-lidstaat, en dat dit geen deel zou uitmaken van het SDEP-verhaal. Dit is nog niet uitgeklaard.

Informatiemodel

Het algemene informatiemodel rond dit project is terug te vinden op https://semiceu.github.io/STR-AP/.

API contract

Op dit moment is de consensus van de API interface van het SDEP een REST API (JSON-formaat) zal zijn, met autorisatie via OAuth.

Er zijn momenteel 4 SDEP-endpoints gedefinieerd, bedoeld voor gebruik door de STR-platformen:

Het SDEP voorziet ook een endpoint voor healthchecks: GET /ping

De PoC-code van het SDEP door PwC bevat nog andere endpoints, maar die zijn te gebruiken door de CA’s, en maken daarom niet strikt deel uit van het Europese contract.

Onboarding STR-platformen

Er zal een proces moeten ingericht worden om platformen te onboarden op het SDEP. Pas na deze onboarding zal het platform calls kunnen maken en data kunnen doorgeven. Te bekijken hoe dit proces er zal uitzien.