Regeling van de Staatssecretaris van Infrastructuur en Waterstaat, van 3 juni 2025, nr. IENW/BSK-2025/130201, houdende regels met betrekking tot de centrale database taxivervoer (Regeling centrale database taxivervoer) [KetenID WGK026754]

De Staatssecretaris van Infrastructuur en Waterstaat,

Gelet op artikel 83b, derde lid, van het Besluit personenvervoer 2000;

BESLUIT:

§ 1. Begripsbepalingen

Artikel 1

In deze regeling wordt verstaan onder:

Besluit:

Besluit personenvervoer 2000;

centrale applicatie:

applicatie die taxivervoergegevens ontvangt van een of meerdere registratiemiddelen en deze aanlevert aan de CDT via de CDT meldingen API;

CDT:

centrale database taxivervoer;

CDT Meldingen API:

voorziening voor het uitwisselen van taxivervoergegevens tussen een centrale applicatie en de CDT;

gebeurtenis:

voorval dat plaatsvindt binnen het registratiemiddel, zijnde een melding, fout of storing;

ICT-oplossing:

het geheel aan digitale technieken en processen voor het registreren van taxivervoergegevens en het aanleveren van deze gegevens aan de CDT;

pauze:

een periode van tenminste 15 achtereenvolgende minuten waarin de bestuurder geen werkzaamheden verricht en vrijelijk over zijn tijd kan beschikken;

taxivervoergegevens:

gegevens als bedoeld in artikel 83b, tweede lid, van het Besluit;

twee factor authenticatie:

methode waarbij de identiteit van een persoon wordt vastgesteld op basis van twee verschillende factoren.

§ 2. Registratie en aanlevering van taxivervoergegevens

Artikel 2 (Registreren en aanleveren van taxivervoergegevens)

• 1. De centrale applicatie waarvan de vervoerder gebruik maakt, wordt aangesloten op de CDT als het registratiemiddel en de centrale applicatie voldoen aan de in deze regeling opgenomen voorwaarden.

• 2. Via de CDT Meldingen API meldt de vervoerder van welke ICT-oplossing gebruik wordt gemaakt.

• 3. De bestuurder maakt gebruik van het registratiemiddel, dat ter beschikking is gesteld door de vervoerder, om taxivervoergegevens te registreren.

• 4. De taxivervoergegevens worden door het registratiemiddel geregistreerd en via de centrale applicatie realtime aangeleverd aan de CDT Meldingen API, tenzij sprake is van omstandigheden ten gevolge waarvan deze gegevens niet realtime kunnen worden geregistreerd of aangeleverd.

• 5. De omstandigheden waaronder taxivervoergegevens niet realtime kunnen worden aangeleverd, bedoeld in het vijfde lid, zijn beperkt tot:

  • a. het niet beschikbaar zijn van de CDT Meldingen API als gevolg van technische problemen of onderhoud;

  • b. een verstoring van de gegevensoverdracht tussen centrale applicatie en CDT Meldingen API.

• 6. De niet tijdig aangeleverde taxivervoergegevens, bedoeld in het vierde lid, worden onverwijld aangeleverd aan de CDT Meldingen API zodra de omstandigheden, bedoeld in het vijfde lid, zich niet meer voordoen.

• 7. Het registreren en aanleveren van taxivervoergegevens vindt plaats aan de hand van de beschrijving, bedoeld in de bijlage.

Artikel 3 (Zorgplichten vervoerder)

• 1. De vervoerder stelt aan de bestuurder een deugdelijk registratiemiddel ter beschikking.

• 2. De vervoerder draagt er zorg voor dat de bestuurder een registratie bijhoudt van de gegevens als genoemd in artikel 83b, tweede lid, van het Besluit.

• 3. Indien het registratiemiddel ondeugdelijk, defect of verloren gegaan is, zorgt de vervoerder binnen drie werkdagen voor herstel of een vervangend registratiemiddel.

• 4. De vervoerder draagt er zorg voor dat de gegevens, als bedoeld in artikel 7, zesde lid, onverwijld en waarheidsgetrouw worden aangeleverd aan de CDT Meldingen API.

• 5. De vervoerder draagt er zorg voor dat de aanlevering aan de CDT Meldingen API zonder foutmeldingen en waarschuwingsberichten verloopt.

• 6. Als foutmeldingen of waarschuwingsberichten worden ontvangen, verhelpt de vervoerder onverwijld de oorzaken ervan.

Artikel 4 (Validatie van de bestuurder)

• 1. De vervoerder valideert de gegevens van de bestuurder bij de CDT Meldingen API voordat de bestuurder voor de eerste keer met het registratiemiddel taxivervoer verricht voor de vervoerder.

• 2. Validatie vindt plaats door het aanleveren van het chauffeursnummer en de rijbewijsgegevens van de bestuurder zoals omschreven in de bijlage.

• 3. De bestuurder is gevalideerd als:

  • a. de rijbewijsgegevens van een geldig rijbewijs zijn;

  • b. het chauffeursnummer van een geldige bevoegdheid taxivervoer is; en

  • c. het chauffeursnummer en het rijbewijs van dezelfde persoon zijn.

• 4. Een niet-gevalideerde bestuurder mag geen taxivervoer voor een vervoerder verrichten, tenzij de CDT Meldingen API niet beschikbaar is ten tijde van de validatiepoging.

• 5. Als sprake is van een situatie als bedoeld in het vierde lid, valideert de vervoerder de gegevens als bedoeld in het tweede lid, onverwijld, zodra de CDT Meldingen API weer beschikbaar is.

• 6. Als de bestuurder niet in het bezit is van een Nederlands rijbewijs, maar van een niet-Nederlands rijbewijs, valideert de vervoerder het chauffeursnummer van de bestuurder.

• 7. De bestuurder met een niet-Nederlands rijbewijs is gevalideerd als het chauffeursnummer van een geldige bevoegdheid taxivervoer is.

Artikel 5 (Validatie van de auto waarmee taxivervoer wordt verricht)

• 1. De vervoerder valideert een auto waarmee taxivervoer wordt verricht voordat deze voor de eerste keer voor de vervoerder met het registratiesysteem van de CDT wordt gebruikt en legt dit vast.

• 2. Validatie vindt plaats door het elektronisch valideren van het kentekenbewijs.

• 3. In een niet door de vervoerder gevalideerde auto waarmee taxivervoer wordt verricht, wordt door een bestuurder geen taxivervoer verricht.

Artikel 6 (Aanmelden van de bestuurder)

• 1. Bij aanvang van de werkzaamheden aan boord van een auto waarmee taxivervoer wordt verricht meldt de bestuurder zich aan op het registratiemiddel.

• 2. De bestuurder die in het bezit is van een Nederlands rijbewijs meldt zich aan door zijn Nederlands rijbewijs elektronisch te authentiseren op het registratiemiddel.

• 3. Als het Nederlands rijbewijs defect is, meldt de bestuurder zich gedurende een periode van maximaal tien aaneengesloten dagen aan door middel van twee factor authenticatie.

• 4. De bestuurder die niet in het bezit is van een Nederlands rijbewijs en wel in het bezit is van een niet-Nederlands rijbewijs meldt zich aan door middel van twee factor authenticatie.

• 5. Zonder aanmelden is het een bestuurder niet toegestaan om taxivervoer te verrichten.

Artikel 7 (Gebruik van het registratiemiddel door de bestuurder)

• 1. Indien de bestuurder, voorafgaand aan de melding, bedoeld in artikel 6, eerste lid, andere werkzaamheden heeft verricht na zijn laatste afmelding als bedoeld in het zevende lid van dit artikel, registreert hij de begin- en eindtijden van de andere werkzaamheden bij de melding als bedoeld in artikel 6, eerste lid.

• 2. De bestuurder meldt een rit aan op het registratiemiddel op het moment dat het vervoeren van personen aanvangt.

• 3. De bestuurder meldt een rit af op het registratiemiddel op het moment dat het vervoeren van personen is beëindigd.

• 4. Ingeval het registratiemiddel niet gekoppeld is aan de taxameter, bedoeld in artikel 78 van het Besluit personenvervoer 2000, voert de bestuurder handmatig de door de taxameter aangegeven totaalprijs in. Als voor het vervoer geen taxameter verplicht is en de volledige ritprijs direct na de rit wordt voldaan voert de bestuurder de door de reiziger verschuldigde vergoeding in.

• 5. Gedurende de periode dat er geen registratiemiddel beschikbaar is, als genoemd in artikel 3, derde lid, registreert de bestuurder zijn taxivervoersgegevens op een andere inzichtelijke en controleerbare wijze.

• 6. De bestuurder levert de registratie, genoemd in het vijfde lid, uiterlijk de derde werkdag als bedoeld in artikel 3, derde lid, aan bij de vervoerder.

• 7. Bij beëindiging van de werkzaamheden aan boord van een auto waarmee taxivervoer wordt verricht meldt de bestuurder zich af op het registratiemiddel.

• 8. De bestuurder meldt op het moment dat deze plaats vinden op het registratiemiddel het begin en einde van pauzes die hij tijdens zijn werkzaamheden aan boord van een auto waarmee taxivervoer wordt verricht geniet.

§ 3. Techniek

Artikel 8 (Registratiemiddel)

• 1. Het registratiemiddel bevat of heeft de volgende eigenschappen:

  • a. een bewegingsdetectie van het registratiemiddel;

  • b. een locatiebepaling met een nauwkeurigheid van ten minste 25 meter;

  • c. de functionaliteit om de laatst bekende locatie vast te houden;

  • d. de functionaliteit om op basis van de locatiebepaling een afgelegde afstand te bepalen met een maximale afwijking van 15%;

  • e. een tijdsbepaling met een nauwkeurigheid van ten minste 1 seconde en synchronisatie met een geijkte externe tijdfunctie;

  • f. voorzieningen om de bestuurder te authentiseren als genoemd in artikel 6;

  • g. de functionaliteit om unieke identificatiecodes van diensten, ritten, pauzes en gebeurtenissen te genereren;

  • h. de functionaliteit om diensten, verrichtingen en andere werkzaamheden als genoemd in artikel 83b, tweede lid, onderdeel l van het Besluit, aan en af te melden via de centrale applicatie;

  • i. voorzieningen die taxivervoergegevens realtime doorsturen naar de centrale applicatie;

  • j. voorzieningen die ervoor zorgen dat er geen taxivervoergegevens verloren kunnen gaan;

  • k. de functionaliteit voor de bestuurder om alleen auto's te kunnen opgeven die de vervoerder voor hem heeft toegestaan;

  • l. de functionaliteit voor de bestuurder om zich aan te kunnen melden voor vervoerders die hem dat toestaan.

• 2. Het is niet toegestaan het registratiemiddel op een wijze te gebruiken die maakt dat taxivervoergegevens kunnen worden gewijzigd of verwijderd voordat deze zijn aangeleverd in de CDT.

Artikel 9 (Centrale applicatie)

• 1. Het aanleveren van taxivervoergegevens vanaf het registratiemiddel aan de CDT vindt plaats via een centrale applicatie.

• 2. De centrale applicatie bevat of heeft de volgende eigenschappen:

  • a. een functionaliteit om alle ontvangen gegevens direct en ongewijzigd door te sturen naar de CDT Meldingen API;

  • b. een functionaliteit die ervoor zorgt dat berichten in chronologische volgorde van registratie tijdens de werkzaamheden aan boord van de auto waarmee taxivervoer wordt verricht worden aangeboden aan de CDT Meldingen API;

  • c. een functionaliteit die maakt dat een volgend bericht aan de CDT Meldingen API pas wordt aangeboden als het voorgaande bericht succesvol is verwerkt.

Artikel 10 (Informatiebeveiliging)

• 1. De vervoerder maakt gebruik van een ICT-oplossing en een organisatie die zijn gecertificeerd voor ISO 27001. De certificatie wordt verricht door een certificerende instelling die is geaccrediteerd door de Raad voor Accreditatie of een andere accreditatie instelling die is erkend in een lidstaat van de Europese Unie.

• 2. De certificering, bedoeld in het eerste lid, heeft als werkingsgebied alle functionaliteit die gegevens levert aan de CDT Meldingen API. De functionaliteit omvat ten minste alle registratiemiddelen en de centrale applicatie.

§ 4. Overgangs- en slotbepalingen

Artikel 11 (Inwerkingtreding)

Deze regeling treedt in werking met ingang van 1 juli 2025.

Artikel 12 (Citeertitel)

Deze regeling wordt aangehaald als: Regeling centrale database taxivervoer.

Deze regeling zal met de toelichting in de Staatscourant worden geplaatst.

De Staatssecretaris van Infrastructuur en Waterstaat – Openbaar Vervoer en Milieu, C.A. Jansen

BIJLAGE TECHNISCHE BESCHRIJVING VAN DE BERICHTENUITWISSELING VOOR HET AANLEVEREN VAN TAXIVERVOERGEGEVENS AAN DE CDT MELDINGEN API (KOPPELVLAKSPECIFICATIE CDT)

(bijlage als bedoeld in artikel 2, zevende lid, van de Regeling centrale database taxivervoer)

1	INLEIDING
1.1	Context
1.2	Doel
2	PROCESSEN
2.1	Aanmelden dienst (relateren chauffeur, ondernemer en voertuig)
2.2	Aanmelden rit en aanmelden pauze
2.3	Afmelden rit en afmelden pauze
2.4	Afmelden dienst
2.5	Aanmelden ICT-dienstverlener
2.6	Afmelden ICT-dienstverlener
2.7	Valideren van chauffeur
2.8	Opvragen van openstaande diensten en verrichtingen
2.9	Melden van gebeurtenissen van het registratiemiddel chauffeur
2.10	Opvragen chauffeursnummer
3	BERICHTEN
3.1	Statusovergangen
3.2	Generieke berichtgegevens in headers
3.3	Functionele berichtgegevens
3.3.1	Chauffeur
3.3.2	Rijbewijs
3.3.3	Authenticatie
3.3.4	Ondernemer
3.3.5	Voertuig
3.3.6	Andere werkzaamheden
3.3.7	Locatie
3.4	Aanmelden dienst (relateren chauffeur, ondernemer en voertuig)
3.5	Afmelden dienst
3.6	Aanmelden rit
3.7	Afmelden rit
3.8	Aanmelden pauze
3.9	Afmelden pauze
3.10	Aanmelden ICT-dienstverlener
3.11	Afmelden ICT-dienstverlener
3.12	Valideren chauffeur
3.13	Opvragen van openstaande diensten en verrichtingen
3.14	Melden van gebeurtenissen van het registratiemiddel chauffeur
3.15	Opvragen chauffeursnummer
3.16	Foutmeldingscodes
3.16.1	Foutmeldingen wegens headers
3.16.2	Foutmeldingen wegens fouten in het bericht zelf
3.16.3	Foutmeldingen wegens verwerken inhoud
4	TECHNISCHE EISEN
4.1	Conventies
4.1.1	JSON conventies
4.1.2	Encoding
4.1.3	Hoofdlettergevoeligheid
4.1.4	Datum/tijd
4.1.5	Berichtenverkeer
4.1.6	Endpoints
4.2	Actualiteit van data
4.3	Beschikbaarheid en performance
4.3.1	Beschikbaarheid
4.3.2	Performance
5	LOGGING EN MONITORING VERBINDING
5.1	Logging
5.2	Connectie-monitoring
6	FOUTAFHANDELING
6.1	Algemeen
6.2	Error in aanroep dienstgerelateerde endpoints
6.3	Error in aanroep /verbinding
6.4	Duplicaat detectie
7	AUTHENTICATIE EN INFORMATIEBEVEILIGING
7.1	Authenticatie
7.1.1	PKI Certificaten
7.1.2	Authenticatie rijbewijs
7.1.3	Authenticatie kentekenbewijs
7.2	Informatiebeveiliging
7.2.1	Transport Layer Security (TLS)
7.2.2	API-keys
7.3	Headers

1 INLEIDING

Deze koppelvlakspecificatie geeft een beschrijving van de volgende functies van de CDT-Meldingen-API:

• 1.) Het aanleveren van diensten, ritten en pauzes door de ondernemer;

• 2.) Het valideren van chauffeursgegevens;

• 3.) Het opvragen van openstaande diensten en verrichtingen binnen de CDT;

• 4.) Het aan- en afmelden van ICT-dienstverleners door ondernemers;

• 5.) Het melden van gebeurtenissen van het registratiemiddel chauffeur gerelateerd aan een dienst.

• 6.) Het opvragen van het chauffeursnummer van een taxichauffeur op basis van het nummer van zijn Nederlandse rijbewijs.

1.1 Context

De chauffeur maakt gebruik van een Registratiemiddel Chauffeur om realtime relevante informatie over de uitvoering van taxivervoer te registreren voor de ondernemer in de centrale applicatie, die de gegevens realtime levert aan de CDT. Voor de uitwisseling van berichten met de ILT is de CDT-Meldingen-API (op basis van REST) ontwikkeld die aangeroepen dient te worden door de Centrale Applicatie.

1.2 Doel

Dit document is een bijlage bij de Regeling CDT. Het doel van dit document is om aan partijen die gebruik willen maken van de CDT Meldingen API inzicht te verschaffen in de functies en werking van de CDT-Meldingen-API.

2 PROCESSEN

In deze koppelvlakspecificatie wordt de term ‘dienst’ gebruikt zoals dat in het dagelijks spraakgebruik wordt gedaan. De betekenis van dienst in dit document is daardoor niet de definitie van Dienst in art 1.7 eerste lid onder c van de Arbeidstijdenwet. Met ‘dienst’ wordt in deze koppelvlakspecificatie ‘de werkzaamheden als taxichauffeur aan boord van de auto waarmee taxivervoer wordt verricht’ bedoeld.

De volgende processen zijn in scope voor de aanlevering bij de CDT:

• 1. Aanmelden dienst (relateren chauffeur, ondernemer en voertuig);

• 2. Melden andere werkzaamheden van de chauffeur voorafgaand aan de dienst;

• 3. Aanmelden rit of pauze;

• 4. Afmelden rit of pauze;

• 5. Afmelden dienst;

• 6. Aanmelden ICT-dienstverlener door ondernemer;

• 7. Afmelden ICT-dienstverlener door ondernemer;

• 8. Valideren van chauffeur;

• 9. Opvragen van openstaande diensten en verrichtingen;

• 10. Doorgeven van gebeurtenissen van het registratiemiddel chauffeur;

• 11. Opvragen van chauffeursnummer.

2.1 Aanmelden dienst (relateren chauffeur, ondernemer en voertuig)

Preconditie

De ondernemer heeft ervoor gezorgd dat:

• 1. De ICT-dienstverlener is aangemeld bij de CDT Meldingen API;

• 2. Het voertuig is gevalideerd;

• 3. De chauffeur is gevalideerd;

• 4. De chauffeur toegang heeft tot het 'registratiemiddel chauffeur'.

Proces

De chauffeur:

• 1. Authenticeert zich met een toegestane authenticatiemethode;

• 2. Voegt eventueel begin- en eindtijden in van andere werkzaamheden die voorafgaand aan de dienst zijn uitgevoerd;

• 3. Meldt de dienst, met daarop de ondernemer en het voertuig, via het registratiemiddel chauffeur aan bij de centrale applicatie, die vervolgens de dienst onmiddellijk aanmeldt bij de CDT-Meldingen-API.

Postconditie

De aanmelding van de dienst is geregistreerd voor de chauffeur, het voertuig en de ondernemer in de centrale applicatie en in de CDT. De optionele aanmelding van de andere werkzaamheden is geregistreerd voor de chauffeur.

2.2 Aanmelden rit en aanmelden pauze

Preconditie

• De dienst waarbinnen de rit of pauze plaatsvindt, is aangemeld en geregistreerd in de centrale applicatie en de CDT;

• Bij aanmelden pauze: er zijn geen niet-afgemelde ritten of pauzes binnen deze dienst;

• Bij aanmelden rit: er zijn geen niet-afgemelde pauzes binnen deze dienst;

Proces

• De chauffeur meldt via het registratiemiddel chauffeur de rit of pauze aan bij de centrale applicatie, die vervolgens de rit of pauze onmiddellijk aanmeldt bij de CDT-Meldingen API.

• Bij het aanmelden van een rit is de locatie verplicht. Indien er geen actuele locatie beschikbaar is wordt de laatst bekende locatie doorgegeven.

Postconditie

De aanmelding van de rit of pauze is geregistreerd binnen de dienst van de chauffeur in de centrale applicatie en de CDT.

2.3 Afmelden rit en afmelden pauze

Preconditie

De rit of pauze is geregistreerd in de centrale applicatie en de CDT.

Proces

• De chauffeur meldt via het registratiemiddel chauffeur de rit of pauze af bij de centrale applicatie, die vervolgens de rit of pauze onmiddellijk afmeldt bij de CDT-Meldingen-API.

Postconditie

De afmelding van de rit of pauze is geregistreerd binnen de dienst voor de chauffeur en de ondernemer in de centrale applicatie en de CDT.

2.4 Afmelden dienst

Preconditie

De dienst is geregistreerd en alle ritten en pauzes binnen de dienst zijn afgemeld in de centrale applicatie en de CDT.

Proces

De chauffeur meldt via het registratiemiddel chauffeur de dienst af bij de centrale applicatie, die vervolgens de dienst onmiddellijk afmeldt bij de CDT-Meldingen-API.

Postconditie

De afmelding van de dienst is geregistreerd in de centrale applicatie en de CDT.

2.5 Aanmelden ICT-dienstverlener

Preconditie

De ondernemer neemt een ICT-oplossing af bij de ICT-dienstverlener en heeft de ICT-dienstverlener niet aangemeld bij de CDT Meldingen API.

Proces

De centrale applicatie stuurt de aanmelding van de ondernemer voor de ICT-dienstverlener naar de CDT Meldingen API.

Postconditie

De ICT-dienstverlener is door de ondernemer aangemeld bij de CDT Meldingen API.

2.6 Afmelden ICT-dienstverlener

Preconditie

De ondernemer is gestopt met het afnemen van de ICT-oplossing van de ICT-dienstverlener en;

De ICT-dienstverlener is door de ondernemer aangemeld bij de CDT Meldingen API.

Proces

De centrale applicatie stuurt de afmelding van de ondernemer voor de ICT-dienstverlener naar de CDT Meldingen API.

Postconditie

De ICT-dienstverlener is door de ondernemer afgemeld bij de CDT Meldingen API.

2.7 Valideren van chauffeur

Preconditie

Ondernemer beschikt niet over de informatie of een chauffeur bevoegd is.

Proces

Ondernemer valideert via de Centrale applicatie de chauffeursgegevens bij de CDT.

NB: alleen bij validatiecode 0 worden de chauffeursgegevens als gevalideerd beschouwd.

Postconditie

Ondernemer beschikt over de informatie of de opgegeven chauffeursgegevens van een bevoegde chauffeur zijn.

2.8 Opvragen van openstaande diensten en verrichtingen

Preconditie

Centrale applicatie beschikt niet over de informatie welke diensten en verrichtingen langer dan een opgegeven duur open staan in de CDT.

Proces

Centrale applicatie vraagt diensten en verrichtingen op die langer dan een gespecificeerde tijdsduur (minimaal 24 uur) openstaan bij de CDT.

Postconditie

Centrale applicatie beschikt over de informatie met betrekking tot welke diensten en verrichtingen langer dan de gespecificeerde tijdsduur open staan in de CDT.

2.9 Melden van gebeurtenissen van het registratiemiddel chauffeur

Gebeurtenissen van het registratiemiddel chauffeur zijn meldingen (M). Een nadere toelichting hierop is te vinden in paragraaf 3.14 van dit document.

Preconditie

De dienst waaraan de gebeurtenis is gerelateerd, is aangemeld en geregistreerd in de centrale applicatie en de CDT.

Proces

Het registratiemiddel chauffeur meldt de gebeurtenis bij de centrale applicatie, die vervolgens de gebeurtenis onmiddellijk meldt bij de CDT-Meldingen-API.

Postconditie

De gebeurtenis is geregistreerd in de centrale applicatie en de CDT.

2.10 Opvragen chauffeursnummer

Het chauffeursnummer staat niet vermeld op de beschikking bij chauffeurskaarten die zijn uitgegeven voor 2025. Om het chauffeursnummer te achterhalen kan op basis van de gegevens van een Nederlands rijbewijs het chauffeursnummer opgevraagd worden bij de CDT Meldingen API.

Preconditie

Chauffeur en ondernemer beschikken niet over het chauffeursnummer en chauffeur heeft een geldig Nederlands rijbewijs en zijn BSN is geregistreerd bij Kiwa.

Proces

Ondernemer vraagt op basis van het Nederlandse rijbewijs van de chauffeur het chauffeursnummer op bij de CDT.

Postconditie

Indien de chauffeur beschikt over een geldige taxibevoegdheid, levert de CDT het chauffeursnummer terug aan de ondernemer.

NB: voor chauffeurs die geen Nederlands rijbewijs hebben of die bij KIWA niet met een BSN geregistreerd zijn is het niet mogelijk het chauffeursnummer op basis van rijbewijsgegevens op te vragen. Deze chauffeurs ontvangen het chauffeursnummer per brief van KIWA, en dienen het chauffeursnummer door te geven aan de ondernemer.

3 BERICHTEN

Berichten bestaan uit generieke berichtgegevens (metagegevens) en de inhoud van het bericht zelf. ILT heeft ervoor gekozen om de metagegevens als headers in het bericht op te nemen.

3.1 Statusovergangen

De logische samenhang tussen de berichten en de status van een dienst en verrichting is in onderstaande figuur weergegeven. De berichten ‘opvragen openstaande diensten’ en ‘valideren chauffeurs’ komen niet voor in onderstaand figuur omdat ze geen invloed hebben op de status van diensten en verrichtingen.

Regels:

• Diensten mogen alleen worden aangemeld door een aangemelde ICT-dienstverlener;

• Het aanmelden van een verrichting (rit of pauze) vereist een aangemelde dienst;

• Het aanmelden van een gebeurtenis vereist een aangemelde dienst;

• Om een dienst te kunnen afmelden moeten alle verrichtingen binnen die dienst afgemeld zijn;

• Gebeurtenissen kunnen worden gemeld tijdens een dienst, ongeacht of er een verrichting plaats vindt;

• De volgende regels gelden bij overlappende verrichtingen:

  • Overlappende ritten zijn toegestaan;

  • Tijdens een rit kan geen pauze worden aangemeld;

  • Tijdens een pauze kan geen rit worden aangemeld.

• Een pauze kan alleen gemeld worden met een aanmeldtijdstip dat ligt na de laatst afgemelde verrichting.

3.2 Generieke berichtgegevens in headers

De velden in de onderstaande tabel staan de bericht header.

Veldnaam	Type/lengte	Voorbeeld	Toelichting
Dienstverlener	UUID	a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11	Door ILT uitgegeven sleutel die de aanleverende ICT-dienstverlener uniek identificeert bij de CDT-Meldingen-API.
ext_key	UUID	a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11	Unieke sleutel voor toegang tot de API-gateway
Bericht-Id	UUID	a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11	Identificatie van een bericht. NB: dit dient gegenereerd te worden bij het verzenden van het bericht.
Verzendtijdstip	date-time in UTC conform IETF RFC3339	2023-03-31T14:55:44Z of 2023-03-31T14:55:44.444Z	Verzendtijdstip van bericht van ICT-dienstverlener naar ILT. NB: dit tijdstip dient bij iedere verzendpoging geactualiseerd te worden.
Softwareversie-Registratiemiddel	String(20)[1]	v12.23.124	Softwareversie van het registratiemiddel.
Softwareversie-Centrale-Applicatie	String(20)	v2.2.9	Softwareversie van de Centrale applicatie

1 Softwareversie-Registratiemiddel mag een empty string zijn als het bericht niet afkomstig is van een ‘registratiemiddel chauffeur’.

3.3 Functionele berichtgegevens

De velden in de onderstaande tabel kunnen op een bericht voorkomen (in de message body), per bericht is beschreven welke van deze velden voorkomen. Daarnaast staan in paragrafen 3.3.1 tot en met 3.3.7 objecten die in berichten kunnen voorkomen.

Veldnaam	Type/lengte	Voorbeelden	Toelichting
id	UUID	a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11	Identificatie van een dienst, verrichting of gebeurtenis NB: dit dient gegenereerd te worden bij het ontstaan van de dienst, verrichting of gebeurtenis.
aanmeldtijdstip	date-time in UTC conform IETF RFC3339	2023-03-31T14:55:44Z of 2023-03-31T14:55:44.444Z	Het tijdstip waarop de dienst of verrichting is gestart. NB: dit is het tijdstip op het registratiemiddel.
afmeldtijdstip	date-time in UTC conform IETF RFC3339	2023-03-31T14:55:44Z of 2023-03-31T14:55:44.444Z	Het tijdstip waarop de dienst of verrichting is beëindigd. NB: dit is het tijdstip op het registratiemiddel.
ritprijs	Integer(6)	10170	Totale eindprijs van de afgelegde rit in eurocenten. Dit is exclusief fooi.
afstand	Numeric (4,1)	12,1	Afgelegde afstand van rit
registratietijdstip	date-time in UTC conform IETF RFC3339	2023-03-31T14:55:44Z of 2023-03-31T14:55:44.444Z	Het tijdstip waarop registratie plaatsvindt op het registratiemiddel.
gebeurtenistijdstip	date-time in UTC conform IETF RFC3339	2023-03-31T14:55:44Z of 2023-03-31T14:55:44.444Z	Tijdstip dat de gebeurtenis plaatsvindt op het registratiemiddel.
gebeurteniscode	String(4)	M106	code uit tabel in paragraaf 3.14

Regels:

• Bij het bericht is aangegeven welke velden verplicht zijn;

• Bericht wordt afgewezen als velden niet het juiste formaat of opmaak hebben;

• Bericht wordt afgewezen als verplichte velden ontbreken;

• Bericht wordt afgewezen als andere dan toegestane velden aanwezig zijn;

• Bericht wordt afgewezen als toegestane velden vaker dan gespecificeerd voorkomen.

Naast de velden in bovenstaande tabel kunnen ook objecten worden verstuurd. Deze staan in de volgende paragrafen beschreven.

3.3.1 Chauffeur

onderdelen	type	RegEx	voorbeeld	Toelichting
chauffeursnummer	String(8)	^T\d{7}$	T0012345	Chauffeursnummer zoals uitgegeven door KIWA
gevalideerd	boolean		true	indicatie of rijbewijs bij CDT Meldingen API gevalideerd is. Deze mag alleen op true worden gezet als op aanroep van POST https://[host]/v2/chauffeurs/valideren validatiecode 0 is teruggegeven voor de combinatie chauffeur/ondernemer.
rijbewijs	object			zie paragraaf 3.3.2

Voorbeeld:

"chauffeur": {
	"chauffeursnummer": "T0012345", "gevalideerd": true, "rijbewijs": {
		"land": "NL", "nummer": "123456789"
	}
}

3.3.2 Rijbewijs

onderdelen	type	RegEx	voorbeeld	Toelichting
land	string2	^[A-Z]{2]$	NL	Landcode volgens ISO3166-1 alpha-2
rijbewijsnummer	string(16)	^[0-9a-zA-Z]{1,16}$	1234567890	Een Nederlands rijbewijsnummer bestaat uit 10 cijfers, andere landen kunnen afwijken. Streepjes, spaties en punten worden weggelaten.

Voorbeeld:

"rijbewijs": {
	"Land": "NL", "rijbewijsnummer": "123456789"
}

3.3.3 Authenticatie

onderdelen	type	RegEx	voorbeeld	Toelichting
middel	string{4}	RBNL|BIO| 2FA|geen	RBNL	RBNL = Nederlands rijbewijs BIO = Biometrie 2FA = 2-factor authenticatie geen = chauffeur is niet geauthenticeerd (NB: alleen te gebruiken bij aanmelden dienst door vervoerder bij aanlevering achteraf).
kenmerk	string(32)	–	1234565677 vingerafdruk gezichtsherkenning wachtwoord-SMS wachtwoord-koppelcode pincode-SMS pincode-koppelcode geen	Bij RBNL → rijbewijsnummer Bij BIO → vingerafdruk, gezichtsherkenning Bij 2FA → wachtwoord-SMS, wachtwoord-koppelcode, pincode-SMS, pincode-koppelcode Bij geen → geen.

Voorbeelden:

"authenticatie": {
	"middel": "RBNL",
	"kenmerk": "2090710264"
}

"authenticatie": {
	"middel": "BIO",
	"kenmerk": "gezichtsherkenning"
}

"authenticatie": {
	"middel": "2FA",
	"kenmerk": "wachtwoord-SMS"
}

"authenticatie": {
	"middel": "geen",
	"kenmerk": "geen"
}

3.3.4 Ondernemer

onderdelen	type	RegEx	voorbeeld	Toelichting
kiwaNummer	string(7)	^P\d{4,6}$	P123456	nummer van KIWA taxivergunning
kvkNummer	string(8)	^\d{8}$	12345678	Kamer van Koophandel nummer

Voorbeeld:

"ondernemer": {
	"kvkNummer": "12345678",
	"kiwaNummer": "P1234"
}

3.3.5 Voertuig

onderdelen	type	RegEx	voorbeeld	Toelichting
kenteken	string(6)	^[0-9A-Z]{6}$	P390HV	kenteken van het voertuig
validatiemethode	string(1)	K|N	K	‘K’: kentekenkaart gelezen ‘N’: niet gevalideerd
validatiedatum	string(10)	^\d{4}-\d{2}-\d{2}$	2024-03-04	datum waarop validatie is uitgevoerd, format YYYY-MM-DD. Als validatie-methode = ‘N’ dan de huidige datum gebruiken.

Voorbeeld:

"voertuig": {
	"kenteken": "P390HV",
	"validatiemethode": "N",
	"validatiedatum": "2024-03-04"
}

3.3.6 Andere werkzaamheden

onderdelen	type	voorbeeld	Toelichting
begintijdstip	date-time in UTC conform IETF RFC3339	2023-03-31T14:55:44Z of 2023-03-31T14:55:44.444Z	datum en tijdstip waarop andere werkzaamheden zijn gestart
eindetijdstip	date-time in UTC conform IETF RFC3339	2023-03-31T14:55:44Z of 2023-03-31T14:55:44.444Z	datum en tijdstip waarop andere werkzaamheden zijn geëindigd

Voorbeeld:

"andereWerkzaamheden": [
	{
		"begintijdstip": "2023-03-31T14:44:55.000Z",
		"eindetijdstip": "2023-03-31T15:44:55.000Z"
	},
	{
		"begintijdstip": "2023-03-31T18:44:55.000Z",
		"eindetijdstip": "2023-03-31T19:44:55.000Z"
	}
]

3.3.7 Locatie

onderdelen	type	RegEx	voorbeeld	Toelichting
breedtegraad	string	^[-+]?(90(\\.0{4,6})?|([1-8]?\\d(\\.\\d{4,6})?))$	5.100056	geografische breedtegraad met 4 tot 6 cijfers achter de punt
lengtegraad	string	^[-+]?(180(\\.0{4,6})?|((1[0-7]|[1-9])?\\d(\\.\\d{4,6})?))$	52.086491	geografische lengtegraad met 4 tot 6 cijfers achter de punt

Voorbeeld:

"locatie": {
	"breedtegraad": "5.10005",
	"lengtegraad": "52.08649"
}

3.4 Aanmelden dienst (relateren chauffeur, ondernemer en voertuig)

Use cases:

• Aanmelden dienst bij aanvang van de werkzaamheden aan boord van de auto waarmee taxivervoer wordt verricht, eventueel met voorafgaande andere werkzaamheden.

Endpoint: POST https://[host]/v2/diensten

Bij aanmelden dienst bevat het bericht naast alle generieke berichtgegevens de volgende functionele berichtgegevens:

Veldnaam	Verplicht
id (van de dienst)	ja
chauffeur	ja
authenticatie	ja
ondernemer	ja
voertuig	ja
aanmeldtijdstip	ja
registratietijdstip	ja
andereWerkzaamheden	nee

Response sunny day: ‘201 CREATED’

Velden in de response body:

data
	id

Meldingen in de onderstaande tabel zijn mogelijk bij een '201 CREATED' resultaatcode.

Statuscode	Meldingcode	Meldingtekst	Opmerking
201	DF00	Er zijn [#] diensten actief voor de chauffeur bij de ICT-dienstverlener.	Er is voor de opgegeven chauffeur nog een niet-afgesloten dienst bij ILT geregistreerd bij deze ICT-dienstverlener. NB: deze melding wordt niet getoond als de dienst voor de chauffeur open staat bij een andere ICT-dienstverlener.
201	DF06	‘voertuig.kenteken’ is in gebruik op een andere dienst bij de ICT-dienstverlener.	Er is voor het opgegeven voertuig nog een niet-afgesloten dienst bij ILT geregistreerd bij de ICT-dienstverlener. NB: deze melding wordt alleen teruggegeven als de dienst met het voertuig afkomstig is van de aanleverende ICT-dienstverlener.
201	DF07	‘chauffeur’ is niet gevalideerd terwijl deze als gevalideerd is gemarkeerd.	Een chauffeur mag alleen als gevalideerd worden gemeld als een geslaagde validatie is uitgevoerd.
201	DF08	‘ICT-dienstverlener’ is niet aangemeld voor ondernemer	Een ondernemer moet aanmelden welke ICT-dienstverlener voor hem levert.

Bij een afwijzing zijn de meldingen te vinden in paragraaf 3.16.

Response bij openstaande diensten: ‘201 CREATED’

gegevens van openstaande dienst(en) bij de inzendende ICT-dienstverlener staan in de message body.

Velden in de response body:

data
	id (van de aangemelde dienst)
meldingen (optioneel, één of meer)[
	code
	tekst
	details (optioneel, zal voorkomen bij DF00)
		openstaandeDiensten (één of meer) [
			id
			aanmeldtijdstip
			openstaandeVerrichtingen (optioneel, één of meer)[
				id
				aanmeldtijdstip
			]
		]
]

3.5 Afmelden dienst

Use cases:

• Afmelden dienst bij einde van de werkzaamheden aan boord van de auto waarmee taxivervoer wordt verricht.

Endpoint: POST https://[host]/v2/diensten/{dienst.id}/afmelden

Bij afmelden dienst bevat het bericht naast de generieke berichtgegevens in de header de volgende functionele berichtgegevens in de message body:

Veldnaam	Verplicht
afmeldtijdstip	ja
registratietijdstip	ja

Response sunny day: ‘200 OK’

Velden in de response body:

data
	id

Indien foutcode DF05 (zie paragraaf 3.15) wordt teruggegeven is de response: ‘400’.

data
	foutmelding: bericht afgekeurd
	aantal: [alle foutmeldingen]
	fouten (kunnen er meer zijn)[
			code
			tekst
			details (optioneel)
				openstaandeVerrichtingen (één of meer)[
					id
					aanmeldtijdstip
				]
		]

Bij overige afwijzing zijn de meldingen te vinden in paragraaf 3.16.

3.6 Aanmelden rit

Use cases:

• Aanmelden rit als (eerste) passagier instapt.

Endpoint: POST https://[host]/v2/diensten/{dienst.id}/ritten

Bij aanmelden rit bevat het bericht naast alle generieke berichtgegevens de volgende functionele berichtgegevens:

Veldnaam	Verplicht
id (van de rit)	ja
aanmeldtijdstip	ja
registratietijdstip	ja
locatie	ja

Response sunny day: ‘201 CREATED’

Velden in de response body:

data
	id

Bij een afwijzing zijn de meldingen te vinden in paragraaf 3.16.

3.7 Afmelden rit

Use cases:

• Afmelden rit als (laatste) passagier uitstapt.

Endpoint: POST https://[host]/v2/diensten/{dienst.id}/ritten/{rit.id}/afmelden

Bij afmelden rit bevat het bericht naast alle generieke berichtgegevens de volgende functionele berichtgegevens:

Veld	Verplicht
afmeldtijdstip	ja
registratietijdstip	ja
afstand	ja
ritprijs	ja

NB. Bij contractvervoer en groepsvervoer is de prijs niet verplicht. In dat geval mag ritprijs 0 (nul) zijn.

Response sunny day: ‘200 OK’

Velden in de response body:

data
	id

Bij een afwijzing zijn de meldingen te vinden in paragraaf 3.16.

3.8 Aanmelden pauze

Use cases:

• Aanmelden pauze bij aanvang pauze;

Endpoint: POST https://[host]/v2/diensten/{dienst.id}/pauzes

Bij aanmelden pauze bevat het bericht naast alle generieke berichtgegevens de volgende functionele berichtgegevens:

Veldnaam	Verplicht
id (van de pauze)	ja
aanmeldtijdstip	ja
registratietijdstip	ja

Response sunny day: '201 CREATED'

Velden in de response body:

data
	id

Bij een afwijzing zijn de meldingen te vinden in paragraaf 3.16.

3.9 Afmelden pauze

Use cases:

• Afmelden pauze bij einde pauze;

Endpoint: POST https://[host]/v2/diensten/{dienst.id}/pauzes/{pauze.id}/afmelden

Bij afmelden pauze bevat het bericht naast alle generieke berichtgegevens de volgende functionele berichtgegevens:

Veld	Verplicht
afmeldtijdstip	ja
registratietijdstip	ja

Response sunny day: ‘200 OK’

Velden in de response body:

data
	id

Bij een afwijzing zijn de meldingen te vinden in paragraaf 3.16.

3.10 Aanmelden ICT-dienstverlener

Use case:

• ondernemer meldt zich aan voor gebruik van ICT-oplossing van ICT-dienstverlener.

Endpoint: POST https://[host]/v2/ondernemers/aanmelden

In de message body worden de gegeven van de meldende ondernemer doorgegeven.

Veld	Verplicht
ondernemer	ja

Response sunny day: ‘200 OK’

Velden in de response body:

data
	validaties:[
		validatiecode
		validatieomschrijving
	]

Validatiecode	Verificatie-omschrijving
0	‘ondernemer.kiwaNummer’ is van vergunde taxiondernemer; ‘ondernemer.kvkNummer’ is van een bestaande onderneming
1	‘ondernemer.kiwaNummer’ is onbekend
2	‘ondernemer.kiwaNummer’ is niet van een vergunde taxiondernemer
3	‘ondernemer.kvkNummer’ is onbekend
4	‘ondernemer.kvkNummer’ is van niet-actieve onderneming

Bij een afwijzing zijn de meldingen te vinden in paragraaf 3.16.

3.11 Afmelden ICT-dienstverlener

Use case:

• ondernemer stopt met gebruik maken van ICT-oplossing van ICT-dienstverlener.

Endpoint: POST https://[host]/v2/ondernemers/{ondernemer.kiwaNummer}/afmelden

Response sunny day: ‘200 OK’

Er is geen message body aanwezig.

Als de ondernemer onbekend is bij de ICT-dienstverlener wordt als response ‘404 – not found’ gegeven.

Bij een afwijzing zijn de meldingen te vinden te vinden in paragraaf 3.16.

3.12 Valideren chauffeur

Use cases:

• Controleren of van een chauffeur het Nederlands rijbewijsnummer en chauffeursnummer geldig zijn en van dezelfde persoon zijn.

• Controleren of chauffeursnummer van een chauffeur met een buitenlands rijbewijs bestaat en geldig is.

Endpoint: POST https://[host]/v2/chauffeurs/valideren

In de message body wordt de te valideren chauffeur opgegeven met zijn chauffeursnummer en Nederlandse rijbewijs, en de ondernemer die de validatie uitvoert.

Veld	Verplicht
chauffeur	ja
ondernemer	ja

NB: het chauffeursobject heeft het onderdeel ‘gevalideerd’. De waarde hiervan moet false zijn bij deze opvraging.

Response sunny day: ‘200 OK’

Velden in de response body:

data
	validaties:[
		validatiecode
		validatieomschrijving
	]

Validatiecode	omschrijving bij Nederland rijbewijs	omschrijving bij buitenlands rijbewijs
0	‘chauffeur.chauffeursnummer’ is van bevoegde chauffeur; ‘chauffeur.rijbewijs.rijbewijsnummer’ is van een geldig rijbewijs en beiden zijn van dezelfde chauffeur	‘chauffeur.chauffeursnummer’ is van een bevoegde chauffeur
1	‘chauffeur.chauffeursnummer’ is van een andere chauffeur dan ‘chauffeur.rijbewijs.rijbewijsnummer’	niet van toepassing
2	‘chauffeur.chauffeursnummer’ onbekend	‘chauffeur.chauffeursnummer’ onbekend
3	‘chauffeur.rijbewijs.rijbewijsnummer’ onbekend	niet van toepassing
4	‘chauffeur.chauffeursnummer’ is van onbevoegde chauffeur	‘chauffeur.chauffeursnummer’ is van onbevoegde chauffeur
5	rijbewijs is ongeldig	niet van toepassing

Als op deze validatie de validatiecode 0 is geretourneerd mag bij aanmelden dienst voor deze chauffeur met chauffeur.chauffeursnummer en chauffeur.rijbewijs.nummer chauffeur.gevalideerd op true worden gezet. Alle voorgaande gebruikte combinaties van chauffeur.chauffeursnummer met chauffeur.rijbewijs.nummer gelden vanaf dat moment niet meer als gevalideerd.

Bij een afwijzing zijn de meldingen te vinden in paragraaf 3.16.

3.13 Opvragen van openstaande diensten en verrichtingen

Use case:

• Opvragen openstaande diensten en verrichtingen.

Endpoint:

GET https://[host]/v2/diensten/openstaand?ouderdan=24

Deze aanvraag heeft geen message body.

Geeft alle niet-afgemelde diensten met eventueel niet-afgemelde verrichtingen met een aanmeldtijdstip langer dan x uur geleden voor ICT-dienstverlener Y, waarbij x een defaultwaarde heeft van 24, dus als ouderdan wordt weggelaten wordt 24 gebruikt. Een lagere waarde dan 24 wordt genegeerd, in plaats daarvan wordt 24 gebruikt.

Headers: Softwareversie-Registratiemiddel mag leeg (empty string) zijn indien de opvraging afkomstig is van centrale applicatie.

Response sunny day: ‘200 OK’

Velden in de response body:

data
	openstaandeDiensten (kunnen er meer zijn) [
		id [
		aanmeldtijdstip
		openstaandeVerrichtingen (optioneel, kunnen er meer zijn) [
			id,
			aanmeldtijdstip
		]
	]

Als er geen openstaande diensten zijn dan krijgt de aanroep een ‘204 No Content’ response zonder message body.

3.14 Melden van gebeurtenissen van het registratiemiddel chauffeur

Use case:

• Een gebeurtenis op het registratiemiddel chauffeur melden bij de ILT.

Endpoint: (alle gebeurtenissen worden als dienstgebonden beschouwd)

POST https://[host]/v2/diensten/{dienstId}/gebeurtenissen

Velden:

Veld	Verplicht
id (van de gebeurtenis)	Ja
gebeurtenistijdstip	Ja
registratietijdstip	Ja
gebeurteniscode	Ja
authenticatie	Nee[1]
locatie	Nee[1]

1 zie tabel hieronder wanneer dit veld verplicht is.

De codes voor Meldingen zijn verplicht.

Gebeurteniscode	Omschrijving	Veld verplicht
Meldingen
M100[1]	Authenticatiepoging voor en tijdens dienst niet succesvol.	authenticatie
M101	Uitval van registratiemiddel chauffeur tijdens dienst. NB: deze melding zal pas kunnen worden gegenereerd als het registratiemiddel na uitval opnieuw wordt opgestart.
M102	Geen positiebepaling langer dan 3 minuten.	locatie (laatst bekende locatie)
M103	Positiebepaling succesvol na gebeurtenis M102.	locatie
M104	Tijd op registratiemiddel langer dan 10 minuten niet gesynchroniseerd.
M105	Tijd op registratiemiddel gesynchroniseerd na melding synchronisatieprobleem.
M106	Geen beweging gedetecteerd langer dan 1 minuut tijdens verrichting ‘rit’ terwijl positiebepaling beweging suggereert.
M107	beweging gedetecteerd terwijl positiebepaling beweging suggereert na melding M106.
M108[2]	Geen gegevensverbinding langer dan 1 minuut met registratiemiddel chauffeur.
M109[2]	Gegevensverbinding hersteld met registratiemiddel chauffeur na onderbreking.
M110[2]	Dienst afgemeld door ondernemer
M111[2]	Verrichting afgemeld door ondernemer
M112	Per ongeluk gestarte dienst/verrichting afgesloten. NB: de functionaliteit om een per ongeluk gestarte dienst of verrichting af te sluiten is optioneel. Bij het toepassen van deze functionaliteit is het verzenden van deze gebeurteniscode verplicht.
M113	Ritprijs is handmatig opgevoerd. NB: deze melding is niet nodig bij contract- of groepsvervoer, waarbij de waarde van ‘ritprijs’ 0 mag zijn.

1 Melding doorgeven na de eerstvolgende geslaagde aanmelding dienst op het registratiemiddel chauffeur

2 Melding is normaliter afkomstig van de Centrale Applicatie.

NB: bij M101 en M104 dient het gebeurtenistijdstip het tijdstip te zijn waarop de fout voor het eerst is geconstateerd en het registratietijdstip het tijdstip waarop de fout is gemeld vanuit het detecterende apparaat.

Response sunny day: ‘201 OK’

Velden in de response body:

data
	id

Bij een afwijzing zijn de meldingen te vinden in paragraaf 3.16.

3.15 Opvragen chauffeursnummer

Use case:

• Opvragen van een chauffeursnummer op basis van een Nederlands rijbewijsnummer.

Endpoint:

POST https://[host]/v2/chauffeursnummer/opvragen

Indien voor het opgegeven Nederlandse rijbewijs het chauffeursnummer kan worden gevonden wordt dit teruggegeven. Indien een niet-Nederlands rijbewijs wordt opgegeven zal geen chauffeursnummer worden gevonden.

Headers: Softwareversie-Registratiemiddel mag leeg (empty string) zijn indien de opvraging afkomstig is van centrale applicatie.

Velden:

Veld	Verplicht
rijbewijs	Ja

Response als gevonden: ‘200 OK’

Velden in de response body:

data
	chauffeursnummer

Bij een afwijzing of geen gevonden resultaat zijn de meldingen te vinden in paragraaf 3.16.

3.16 Foutmeldingscodes

De CDT Meldingen API kent de onderstaande foutmeldingscodes. Bij iedere errorcode is de http-status code weergegeven en op welke aanroepen deze kan komen.

Codering error codes:

Code prefix	Soort fout
Hxxx	technische fout in (een van de) header(s).
HFxx	functionele fout in (een van de) header(s).
Gxxx	generieke (technische) fout.
DFxx	functionele fout in dienstbericht.
VFxx	functionele fout in verrichtingbericht.
BFxx	functionele fout in gebeurtenisbericht.
OFxx	functionele fout in opvraging

Fouten worden teruggegeven in de response body in het onderstaande format:

data
	foutmelding
	aantal
	fouten [
		code
		tekst
		details (optioneel)
		openstaandeVerrichtingen (één of meer)[
			id
			aanmeldtijdstip
		]
	]

3.16.1 Foutmeldingen wegens headers

De onderstaande meldingen kunnen op alle aanroepen worden teruggegeven:

Status	Melding	Meldingtekst	Toelichting
400	H000	Ontbrekende header <headernaam>.	Dienstverlener, Bericht-Id, Softwareversie-Registratiemiddel, Softwareversie-Centrale-Applicatie of Verzendtijdstip ontbreekt.
400	H001	Waarde van ‘Bericht-Id’ voldoet niet aan de opmaak.	Moet UUID zijn
400	H002	Waarde van ‘Verzendtijdstip’ voldoet niet aan de opmaak.	IETF RFC3339 ‘date-time’ specificatie.
400	H003	Waarde van ‘Verzendtijdstip’ is in de toekomst.	Een bericht kan niet in de toekomst zijn verzonden.
400	H004	Waarde van ‘Softwareversie-Registratiemiddel’ voldoet niet aan de opmaak.	^[0-9A-Za-z.-]{2,20}$, mag in specifieke gevallen empty string zijn.
400	H005	Waarde van ‘Softwareversie-Centrale-Applicatie’ voldoet niet aan de opmaak.	^[0-9A-Za-z.-]{2,20}$
400	H006	Waarde van ‘Dienstverlener’ voldoet niet aan de opmaak.	Moet UUID zijn
400	HF00	Onbekende Dienstverlener.	Dienstverlenercode is niet actief of onbekend.
400	HF10	Bericht-Id is niet uniek.	De Bericht-Id op de header moet uniek zijn

NB: Door de manier waarop de validaties worden uitgevoerd komen de header-foutmeldingen alleen voor op berichten die geen andere foutmeldingen geven.

Gegevens meldingen:

Code	Aanroep
A	Aanmelden dienst
B	Afmelden dienst
C	Aanmelden rit
D	Afmelden rit
E	Aanmelden pauze
F	Afmelden pauze
G	Aanmelden ICT-dienstverlener
H	Valideren chauffeur
I	Melden gebeurtenissen
J	Opvragen chauffeursnummer

NB: ‘Opvragen openstaande diensten’ en ‘afmelden ICT-dienstverlener’ zijn niet opgenomen in de tabellen omdat deze beide geen message body bevatten waarop de foutcodes betrekking hebben.

3.16.2 Foutmeldingen wegens fouten in het bericht zelf

Status	Code	Tekst	Toelichting	A	B	C	D	E	F	G	H	I	J
400	G000	Ongeldige JSON.	Geldt voor het hele bericht: ongeldige JSON formattering.	X	X	X	X	X	X	X	X	X	X
400	G001	Dubbel veld.	Gegevens moeten éénduidig zijn, het is niet toegestaan hetzelfde gegeven meer dan één keer in een bericht op te nemen.	X	X	X	X	X	X	X	X	X	X
400	G010	‘aanmeldtijdstip’ ontbreekt.	verplicht veld	X		X		X
400	G011	Waarde van ‘aanmeldtijdstip’ voldoet niet aan de opmaak.	De datum/tijd is in UTC, ISO-format yyyy-MM-ddThh:mm:ss.sssZ	X		X		X
400	G012	Waarde van ‘aanmeldtijdstip’ is in de toekomst.	De datum/tijd mag niet in de toekomst zijn.	X		X		X
400	G020	‘registratietijdstip’ ontbreekt.	verplicht veld	X	X	X	X	X	X			X
400	G021	Waarde van ‘registratietijdstip’ voldoet niet aan de opmaak.	De datum/tijd is in UTC, ISO-format yyyy-MM-ddThh:mm:ss.sssZ	X	X	X	X	X	X			X
400	G022	Waarde van ‘registratietijdstip’ is in de toekomst.	De datum/tijd mag niet in de toekomst zijn.	X	X	X	X	X	X			X
400	G030	‘afmeldtijdstip’ ontbreekt.	Verplicht veld		X		X		X
400	G031	Waarde van ‘afmeldtijdstip’ voldoet niet aan de opmaak.	De datum/tijd is in UTC, ISO-format yyyy-MM-ddThh:mm:ss.sssZ		X		X		X
400	G032	Waarde van ‘afmeldtijdstip’ is in de toekomst.	De datum/tijd mag niet in de toekomst zijn.		X		X		X
400	G040	‘id’ ontbreekt.	verplicht veld	X		X		X				X
400	G041	Waarde van ‘id’ voldoet niet aan de opmaak.	UUID	X		X		X				X
400	G050	Waarde van padparameter ‘dienst’ voldoet niet aan de opmaak.	UUID		X	X	X	X	X			X
400	G060	‘chauffeur’ ontbreekt.	Verplicht	X							X
400	G061	‘chauffeur.chauffeursnummer’ ontbreekt.	Verplicht veld	X							X
400	G062	Waarde van ‘chauffeur.chauffeursnummer’ voldoet niet aan de opmaak.	Format ^T\d{7}$, bijv. T0012345.	X							X
400	G063	‘chauffeur.gevalideerd’ ontbreekt.	Verplicht veld	X
400	G064	Waarde van ‘chauffeur.gevalideerd’ voldoet niet aan de opmaak.	Boolean, true of false	X
400	G070	‘chauffeur.rijbewijs’ ontbreekt.	verplicht	X							X		X
400	G071	‘chauffeur.rijbewijs.rijbewijsnummer’ ontbreekt.	Verplicht veld	X							X		X
400	G072	Waarde van ‘chauffeur.rijbewijs.rijbewijsnummer’ voldoet niet aan de opmaak.	Veld is maximaal 16 alfanumeriek.	X							X		X
400	G073	‘chauffeur.rijbewijs.land’ ontbreekt.	Verplicht veld	X							X		X
400	G074	Waarde van ‘chauffeur.rijbewijs.land’ voldoet niet aan de opmaak.	landcode conform ISO3166-1 alpha-2	X							X		X
400	G080	‘authenticatie’ ontbreekt.	verplicht bij I als gebeurteniscode = M100	X								X
400	G081	‘authenticatie.middel’ ontbreekt.	verplicht bij I als gebeurteniscode = M100	X								X
400	G082	Waarde van 'authenticatie.middel' voldoet niet aan de opmaak.	Zie paragraaf 3.3 voor toegestane waarden	X								X
400	G083	‘authenticatie.kenmerk’ ontbreekt.	verplicht bij I als gebeurteniscode = M100	X								X
400	G084	Waarde van ‘authenticatie.kenmerk’ voldoet niet aan de opmaak.	Veld is maximaal 32 alfanumeriek.	X								X
400	G090	‘ondernemer’ ontbreekt.	Verplicht	X						X	X
400	G091	‘ondernemer.kiwaNummer’ ontbreekt.	Verplicht	X						X	X
400	G092	Waarde van ‘ondernemer.kiwaNummer’ voldoet niet aan de opmaak.	Eerste positie is altijd een 'P', overige 6 posities zijn cijfers, wanneer de cijferreeks korter is dan 6 posities dient deze uitgevuld te zijn met voorloop- nullen (0).	X						X	X
400	G093	‘ondernemer.kvkNummer’ ontbreekt.	verplicht veld.	X						X	X
400	G094	Waarde van ‘ondernemer.kvkNummer’ voldoet niet aan de opmaak.	Wanneer de cijferreeks korter is dan 8 dan dient deze uitgevuld te zijn met voorloopnullen (0).	X						X	X
400	G100	‘voertuig’ ontbreekt.	Verplicht	X
400	G101	‘voertuig.kenteken’ ontbreekt.	Verplicht	X
400	G103	Waarde van 'voertuig.kenteken' voldoet niet aan de opmaak.	Regex ^[0-9A-Z]{6}$	X
400	G104	‘voertuig.validatiemethode’ ontbreekt.	Verplicht	X
400	G105	Waarde van ‘voertuig.validatiemethode’ voldoet niet aan de opmaak.	enumeratie	X
400	G106	‘voertuig.validatiedatum’ ontbreekt.	Verplicht	X
400	G107	Waarde van ‘voertuig.validatiedatum’ voldoet niet aan de opmaak.	YYYY-MM-DD	X
400	G108	Waarde van ‘voertuig.validatiedatum’ is in de toekomst.	De validatiedatum kan niet in de toekomst liggen	X
400	G110	‘andereWerkzaamheden.begintijdstip’ ontbreekt.	Verplicht als andereWerkzaamheden aanwezig is	X
400	G111	Waarde van 'andereWerkzaamheden.begintijdstip' voldoet niet aan de opmaak.	De datum/tijd is in UTC, ISO-format yyyy-MM-ddThh:mm:ss.sssZ	X
400	G120	‘andereWerkzaamheden.eindetijdstip’ ontbreekt.	Verplicht als andereWerkzaamheden aanwezig is	X
400	G121	Waarde van ‘andereWerkzaamheden.eindetijdstip’ voldoet niet aan de opmaak.	De datum/tijd is in UTC, ISO-format yyyy-MM-ddThh:mm:ss.sssZ	X
400	G122	‘andereWerkzaamheden.eindetijdstip’ is voor ‘andereWerkzaamheden.starttijdstip’.	Start moet voor einde liggen	X
400	G123	Waarde van ‘andereWerkzaamheden.eindetijdstip’ is na ‘dienst.aanmeldtijdstip’.	Einde andere werkzaamheden moet voor aanmeldtijdstip dienst liggen	X
400	G130	‘locatie’ ontbreekt.	verplicht object bij: - aanmelden rit (C) - gebeurteniscode M102 en M103			X						X
400	G131	‘locatie.breedtegraad’ ontbreekt.	verplicht op locatie			X						X
400	G132	Waarde van ‘locatie.breedtegraad’ voldoet niet aan de opmaak.	Numeric(8,6)			X						X
400	G133	‘locatie.lengtegraad’ ontbreekt.	verplicht op locatie			X						X
400	G134	Waarde van ‘locatie.lengtegraad’ voldoet niet aan de opmaak.	Numeric(9,6)			X						X
400	G140	‘afstand’ ontbreekt.	verplicht bij afmelden rit				X
400	G141	Waarde van ‘afstand’ voldoet niet aan de opmaak.	Numeric				X
400	G150	‘ritprijs’ ontbreekt.	verplicht bij rit				X
400	G151	Waarde van ‘ritprijs’ voldoet niet aan de opmaak.	Integer				X
400	G160	Waarde van padparameter ‘rit’ voldoet niet aan de opmaak.	UUID				X
400	G170	Waarde van padparameter ‘pauze’ voldoet niet aan de opmaak.	UUID						X
400	G180	‘gebeurtenistijdstip’ ontbreekt.	Verplicht op melden gebeurtenis									X
400	G181	Waarde van ‘gebeurtenistijdstip’ voldoet niet aan de opmaak.	De datum/tijd is in UTC, ISO-format yyyy-MM-ddThh:mm:ss.sssZ									X
400	G182	Waarde van ‘gebeurtenistijdstip’ is in de toekomst.	Gebeurtenissen kunnen niet voor het gebeurtenistijdstip worden gemeld.									X
400	G190	‘gebeurteniscode’ ontbreekt.	verplicht veld									X
400	G191	Waarde van ‘gebeurteniscode’ voldoet niet aan de opmaak.	String(4)									X

3.16.3 Foutmeldingen wegens verwerken inhoud

status	Code	Tekst	toelichting	A	B	C	D	E	F	G	H	I	J
400	DF01	Waarde van ‘aanmeldtijdstip’ is binnen een andere dienst.	Een dienst kan alleen aangemeld worden wanneer de begintijd van de dienst niet overlapt met een afgemelde dienst voor dezelfde chauffeur.	X
400	DF02	Waarde van ‘id’ is niet uniek.	Identificatie moet uniek zijn	X		X		X				X
400	DF03	Dienst kan niet worden gevonden op basis van het opgegeven id.	Een melding binnen een dienst kan alleen worden gedaan wanneer de dienst gevonden kan worden.		X	X	X	X	X			X
400	DF04	Dienst is reeds afgemeld.	Een dienst kan alleen afgemeld worden wanneer de dienst niet reeds afgemeld is.		X
400	DF05[1]	Er zijn niet-afgemelde verrichtingen op deze dienst.	Een dienst kan worden afgemeld als alle verrichtingen op die dienst zijn afgemeld.		X
400	DF09	Waarde van ‘afmeldtijdstip’ ligt voor ‘aanmeldtijdstip’ van de dienst	Een dienst kan niet worden afgemeld voor een tijdstip dat ligt voor het aanmeldtijdstip		X
400	DF10	Waarde van ‘afmeldtijdstip’ ligt voor ‘afmeldtijdstip’ van verrichtingen in de dienst	Een afmeldtijdstip van een dienst kan niet liggen voor aan- of afmeldtijdstippen van verrichtingen binnen de dienst.		X
400	DF11	Waarde van ‘afmeldtijdstip’ valt binnen een andere dienst	Deze kan alleen voorkomen bij achteraf aangeleverde diensten.		X
400	VF01	Waarde van ‘aanmeldtijdstip’ is voor 'dienst.aanmeldtijdstip'.	Verrichting binnen dienst kan niet eerder beginnen dan dienst			X		X
400	VF02	Verrichting kan niet worden gevonden op basis van het opgegeven id.	Een verrichting (rit/pauze) kan alleen worden afgemeld wanneer deze is aangemeld.				X		X
400	VF03	Verrichting is reeds afgemeld.	Een afgemelde verrichting (rit/pauze) kan niet worden afgemeld.				X		X
400	VF04	Waarde van ‘afmeldtijdstip’ is voor ‘aanmeldtijdstip’ van verrichting.	Een verrichting binnen een dienst kan niet eindigen voor het begin van de verrichting				X		X
400	VF05	Het maximale aantal verrichtingen is bereikt voor deze dienst.	Het aantal verrichtingen per dienst is gemaximaliseerd op 100.			X		X
400	VF06	Waarde van ‘aanmeldtijdstip’ van pauze is binnen rit of pauze.	Een pauze mag niet overlappen met een andere verrichting.					X
400	VF07	Waarde van ‘aanmeldtijdstip’ van rit is binnen gemelde pauze.	Een rit kan niet worden gestart als: • eerder een pauze is aangemeld en niet afgemeld; • het aanmeldtijdstip valt binnen een aan- en afgemelde pauze.			X
400	VF08	Waarde van ‘afmeldtijdstip’ van pauze is binnen rit of pauze.	Een pauze mag niet overlappen met een andere verrichting. NB: deze fout kan in principe alleen voorkomen als achteraf een pauze wordt gemeld.						X
400	VF09	Waarde van ‘afmeldtijdstip’ van rit niet toegestaan, pauze tijdens rit.	Een rit kan niet worden afgemeld als daardoor een pauze tijdens de rit komt te vallen.				X
400	VF10	Verrichting niet gevonden binnen de opgegeven dienst	Er wordt een rit of pauze afgemeld waarvan de ID niet bekend is op de dienst				X		X
400	VF11	Waarde van ‘aanmeldtijdstip’ van pauze is voor aangemelde verrichting	Het is niet toegestaan een pauze te melden met een aanmeldtijdstip voor het aanmeldtijdstip van een andere verrichting.					X
400	BF01	Het maximale aantal gebeurtenissen is bereikt voor deze dienst.	Het aantal gebeurtenissen per dienst is gemaximaliseerd op 100.			X		X
400	OF01	Maximum aantal opvragingen bereikt	Er geldt een maximaal aantal opvragingen van 500 per dag per ICT-dienstverlener										X

1 Bij deze code wordt ook de betreffende verrichting(en) teruggegeven in de response.

4 TECHNISCHE EISEN

4.1 Conventies

4.1.1 JSON conventies

De Centrale applicatie dient de berichten aan te bieden aan de endpoints van CDT-Meldingen-API door middel van JSON (JavaScript Object Notation) berichten en REST (Representational State Transfer).

Voor een complete technische specificatie van de JSON berichten kan de OpenAPI-specificatie geraadpleegd worden, dit is REF-1.

Velden die geen waarde hebben worden weggelaten.

4.1.2 Encoding

De character-encoding standaard van de berichten is UTF-8.

4.1.3 Hoofdlettergevoeligheid

De backend service CDT is WEL hoofdlettergevoelig.

4.1.4 Datum/tijd

Voor datum en tijd wordt IETF RFC 3339 standaard gehanteerd, specifiek de specificatie van de ‘date-time’ waarde. Alle tijdstippen zijn in UTC.

4.1.5 Berichtenverkeer

Het berichtenverkeer wordt synchroon afgehandeld. Indien er sprake is van een time-out dient de Centrale applicatie het bericht opnieuw aan te bieden. Een transactie is pas afgerond als een response is ontvangen.

De aanroeper van een transactie dient minimaal 15 seconden te wachten voordat de transactie als timed-out mag worden beschouwd.

4.1.6 Endpoints

Alle endpoints zijn gespecifieerd in de OpenAPI specificatie [REF-1].

4.2 Actualiteit van data

Berichten dienen zonder vertraging aangeleverd te worden aan de backend service CDT. Elk bericht bevat twee tijdstempels: het moment waarop het feit heeft plaatsgevonden (aanmeldtijdstip of afmeldtijdstip) en het moment waarop het bericht over deze actie wordt aangemaakt (registratietijdstip). In de header ‘verzendtijdstip’ staat het tijdstip waarop de centrale applicatie de aanroep naar de CDT Meldingen API doet.

De ICT-dienstverlener is ervoor verantwoordelijk dat berichten op chronologische volgorde van registratietijdstip worden aangeleverd.

4.3 Beschikbaarheid en performance

4.3.1 Beschikbaarheid

De API heeft een gegarandeerde beschikbaarheid van 98%.

4.3.2 Performance

De streeftijd voor het afhandelen van een bericht is < 2 seconden.

5 LOGGING EN MONITORING VERBINDING

5.1 Logging

Voor beheerdoeleinden verwacht ILT dat de ICT-dienstverlener alle transacties op de CDT-Meldingen-API logt, inclusief de response van ILT. Deze gegevens dienen minimaal 1 maand te worden bewaard.

5.2 Connectie-monitoring

Om te monitoren of verbinding tussen de ICT-dienstverlener en ILT mogelijk is, stuurt de ICT-dienstverlener als er langer dan 60 seconden geen andere melding is gestuurd een GET naar https://[host]/v2/verbinding, waarop ILT een 200 OK zal terugsturen als teken dat de verbinding tot stand is gekomen. Op deze manier kunnen de beheerorganisaties van beide partijen monitoren of de connectie in orde is.

NB: indien de aanroep naar dit endpoint niet slaagt mogen andere transacties niet worden aangeroepen totdat deze aanroep weer slaagt.

6 FOUTAFHANDELING

Het kan gebeuren dat er fouten optreden in één of meer berichten. Dit hoofdstuk beschrijft wat in welk geval moet gebeuren.

6.1 Algemeen

Als een bericht met betrekking op een dienst wordt afgewezen dienen berichten voor dezelfde dienst, die chronologisch na dat bericht moeten worden verstuurd, te worden vastgehouden totdat het afgewezen bericht (al dan niet gecorrigeerd) succesvol door de CDT-Meldingen-API is verwerkt.

Als het /verbinding-endpoint een 500-error geeft is er naar alle waarschijnlijkheid sprake van een verbindingsfout. Er dienen dan geen andere berichten verstuurd te worden naar de CDT Meldingen API en dient er in plaats hiervan iedere minuut een nieuwe oproep naar /verbinding gedaan te worden totdat deze oproep slaagt. Hierna kan het verzenden van de andere berichten weer hervat worden.

6.2 Error in aanroep dienstgerelateerde endpoints

Als in één van de aanroepen een foutsituatie optreedt dan worden acties aanbevolen zoals hieronder in de tabel beschreven.

Status code	Aanbevolen acties.
403	Ongeautoriseerde oproep. Er zijn verkeerde credentials of een onbekend endpoint opgegeven. Herstel is noodzakelijk voor een nieuwe poging.
400	Bij een 400 wegens fouten in de header of het bericht: herstel eerst de fout en stuur dan een nieuw bericht met de herstelde gegevens.
50x	De CDT Meldingen API is niet bereikbaar. Probeer na 1 minuut opnieuw (zelfde message body, ander-tijdstip, zelfde berichtId).

6.3 Error in aanroep /verbinding

Het /verbinding endpoint wordt gebruikt om te controleren of de CDT Meldingen API operationeel is. Dit is een apart geval en is daarom apart behandeld. Als er andere berichten naar de CDT Meldingen API worden verstuurd dient het /verbinding endpoint niet aangeroepen te worden.

Status code	Aanbevolen acties.
40x	Er is een fout gemaakt in de aanroep. Probeer opnieuw met een nieuw bericht.
50x	De CDT Meldingen API is niet bereikbaar. Probeer na 1 minuut opnieuw met een nieuwe aanroep van /verbinding, de huidige oproep mag niet opnieuw aangeboden worden (geen retry voor /verbinding)

6.4 Duplicaat detectie

Er is geen duplicaat-detectie, een bericht dat voor de tweede keer wordt aangeboden wordt functioneel afgewezen.

7 AUTHENTICATIE EN INFORMATIEBEVEILIGING

7.1 Authenticatie

7.1.1 PKI Certificaten

De informatie-uitwisseling met de CDT meldingen-API verloopt via de centrale API Security gateway van de ILT waarop alle ICT-dienstverleners aangesloten dienen te worden. Authenticatie door de ICT-dienstverleners vindt plaats met behulp van PKI overheid servercertificaten en clientcertificaten bij de ICT-dienstverlener. Voor meer informatie zie de website van Logius.

7.1.2 Authenticatie rijbewijs

Bij iedere dienst die wordt gestart dient het Nederlandse rijbewijs van de chauffeur elektronisch te worden geauthenticeerd via NFC. Dit wordt gedaan door de ‘Active Authentication’ van het rijbewijs uit te voeren zoals beschreven in [REF-2]. Als dit met succes is uitgevoerd wordt op het aanmelden dienst-bericht het authenticatie-object gevuld met authenticatie.middel: ‘RBNL’ en authenticatie.kenmerk: het uitgelezen rijbewijsnummer. Als de chauffeur niet beschikt over een Nederlands rijbewijs dient op één van de overige wijzen geauthenticeerd te worden. Deze zijn beschreven in paragraaf 3.3.3.

NB: voor het uitlezen van de specimen rijbewijzen die beschikbaar zijn dient u gebruik te maken van aparte certificaten die niet op de website van de RDW beschikbaar zijn. Deze kunt u verkrijgen bij de aansluitcoördinatoren van de ILT.

7.1.3 Authenticatie kentekenbewijs

Bij het aanmelden van een voertuig voor een vervoerder dient het kentekenbewijs van het voertuig te worden geauthenticeerd middels de ‘Active Authentication’ zoals beschreven in [REF-3]. Hierbij wordt het kenteken van het voertuig uitgelezen middels een smartcard-lezer. Hierna mag het kenteken worden gebruikt voor diensten en ritten van deze vervoerder.

Het is mogelijk dat een voertuig door verschillende vervoerders wordt gebruikt, voor iedere vervoerder dient het kentekenbewijs éénmalig te worden geauthenticeerd voor het in gebruik nemen van het voertuig.

NB: voor het uitlezen van de specimen kentekenbewijzen die beschikbaar zijn dient u gebruik te maken van aparte certificaten die niet op de website van de RDW beschikbaar zijn. Deze kunt u verkrijgen bij de aansluitcoördinatoren van de ILT.

7.2 Informatiebeveiliging

De informatie-uitwisseling gaat van de aanleverende ICT-dienstverleners via het openbare internet naar de beveiligde API-gateway. Alleen vooraf vrijgegeven IP-adressen kunnen berichten hierop aanbieden. De gateway bevindt zich binnen de overheidsinfrastructuur.

7.2.1 Transport Layer Security (TLS)

Het verkeer vindt plaats over TLS met certificaten aan verzendende en ontvangende zijde. Hiervoor wordt gebruik gemaakt van de actuele standaarden zoals voorgeschreven door Forum Standaardisatie. De certificaten aan ontvangende zijde zijn van de Certificate Authority (CA) van de Rijksoverheid, de certificaten aan verzendende zijde moeten van een publieke CA zijn; de meeste CA's zijn bij de Rijksoverheid bekend en worden geaccepteerd. Mocht er twijfel zijn over een CA neemt u dan contact op de ILT. De meest actuele richtlijnen zijn door het NCSC beschreven in het document ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1.

NB: de acceptatie-omgeving wijkt af van de productieomgeving: in de acceptatieomgeving is geen client-certificaat vereist.

7.2.2 API-keys

De ILT geeft per ICT-dienstverlener een API-key (ext_key-header) uit, de ICT-dienstverlener gebruikt de API-key om zich bij de ILT API-gateway te identificeren.

7.3 Headers

De CDT-Meldingen API verwacht de volgende headers:

Header	Waarde	voorbeeld
Accept	Vaste waarde	Accept: application/json
Content-Type	Vaste waarde	Content-Type: application/json
Dienstverlener	UUID	Dienstverlener: <uuid>
ext_key	UUID	ext_key: <uuid>
Bericht-Id	UUID	Bericht-Id: <uuid>
Verzendtijdstip	date-time in UTC conform IETF RFC3339	Verzendtijdstip: 20241120T17:51:01Z of Verzendtijdstip: 20241120T17:51:01.556Z
Softwareversie-Registratiemiddel	Max 20 posities	Softwareversie-Registratiemiddel: v1.0.3
Softwareversie-Centrale-Applicatie	Max. 20 posities	Softwareversie-Centrale-Applicatie: v12.6.5

Zie ook paragraaf 3.2.

TOELICHTING

Algemeen deel

1. Invoering Centrale database taxivervoer

Op grond van de Wet Personenvervoer 2000 en de Arbeidstijdenwet zijn taxivervoerders verplicht om gegevens te registreren over onder meer de arbeids- en rusttijden. De Inspectie Leefomgeving en Transport (ILT) is de toezichthouder die belast is met het toezicht op en de handhaving van de taxiregelgeving en gebruikt deze gegevens voor controles. Sinds 2014 worden taxivervoergegevens geregistreerd in een boordcomputer (hierna: BCT). Vanaf 2025 kunnen de gegevens ook worden geregistreerd via het systeem van de Centrale database taxivervoer (hierna CDT). Vanaf 1 januari 2028 is het gebruik van de BCT niet langer toegestaan en is het systeem van de CDT verplicht. Dit is geregeld in het Besluit van 25 april 2025, houdende wijziging van het Besluit personenvervoer 2000 en het Arbeidstijdenbesluit vervoer in verband met de invoering van de centrale database taxivervoer.

De Regeling centrale database taxivervoer schrijft voor hoe taxi-ondernemers (de vervoerders) en bestuurders taxivervoergegevens moeten registreren en aanleveren aan de CDT.

In het systeem van de CDT worden gegevens geregistreerd met een registratiemiddel. Het registratiemiddel stuurt de gegevens door aan een centrale applicatie die de gegevens real time doorgeeft aan de CDT. Aanlevering aan de CDT gebeurt door aanlevering aan de zogeheten CDT meldingen API. Na aanlevering aan de CDT Meldingen API landen de gegevens in de CDT en kan de toezichthouder de gegevens gebruiken voor controles.

Relatie vervoerder, bestuurder en de ICT-oplossing

De vervoerder is een natuurlijk persoon of rechtspersoon waaraan een vergunning voor taxivervoer is verleend. De bestuurder is een natuurlijk persoon die een chauffeurskaart of -pas heeft en daarmee de bevoegdheid om taxivervoer te verrichten. Een bestuurder kan ook een vervoerder zijn, bijvoorbeeld een eenmansbedrijf.

Om gegevens te kunnen aanleveren moet de vervoerder er voor zorgdragen dat zijn bestuurders aan boord van een taxi gebruik kunnen maken van een registratiemiddel. In het registratiemiddel moeten de bestuurders hun registratie bijhouden van onder meer de arbeids- en rusttijden. Het registratiemiddel is een ICT-middel. Dit middel moet bepaalde functionaliteiten en voorzieningen bevatten die in deze regeling zijn voorgeschreven.

De bestuurder en vervoerder dragen zorg voor de registratie. De geregistreerde gegevens moeten vervolgens realtime aangeleverd aan de CDT Meldingen API via een centrale applicatie. De vervoerder is verantwoordelijk voor de juiste en volledige aanlevering. De aangeleverde gegevens hebben betrekking op het voertuig, de bestuurder, de vervoerder en de afgelegde ritten. Er worden geen gegevens van passagiers geregistreerd.

De centrale applicatie is, net als het registratiemiddel, ook een ICT-middel. De vervoerder kan deze applicatie zelf bouwen en beheren maar ook inhuren bij een ICT-dienstverlener. De vervoerder kan zich tot een ICT-dienstverlener wenden voor het afnemen van dienstverlening of middelen: een registratiemiddel, functionaliteit voor de voertuig- en bestuurdersvalidatie en mogelijk nog andere functionaliteiten die buiten de werking van deze regeling vallen. Het geheel aan techniek, wat uit ICT-middelen bestaat, en (beheer)processen wat nodig is om te komen tot registratie en aanleveren van gegevens wordt aangeduid met het begrip ICT-oplossing.

De vervoerder is verantwoordelijk voor het registreren en aanleveren van de gegevens aan de CDT en daarmee ook voor het oplossen van technische problemen bij een ICT-dienstverlener. Als blijkt dat een ICT-dienstverlener niet meer voldoet, dan moet de vervoerder overstappen naar een andere ICT-dienstverlener voor het aanleveren van taxivervoergegevens aan de CDT.

ISO-normering

De keuze om beveiliging conform ISO 27001 verplicht te stellen is gemaakt om voldoende waarborgen te hebben dat de taxivervoergegevens zoals aangeleverd door de vervoerder integer worden aangeleverd aan de CDT Meldingen API. Daarnaast laat deze certificering ruimte aan de markt om innovatieve toepassingen te introduceren.

Zowel als een vervoerder ervoor kiest om zelf een ICT-oplossing te bouwen als bij het gebruik van een door de markt aangeboden ICT-oplossing, moet hij er erop toezien dat deze oplossing voldoet aan de ISO 27001.

Deze ISO norm is auteursrechtelijk beschermd en voor eigen gebruik verkrijgbaar via de site https://www.nen.nl/nen-en-iso/iec/27001/2023/nl/314206.

2. Uitvoerbaarheid en handhaafbaarheid

De ILT is de toezichthoudende instantie voor de taxiregelgeving. De ILT houdt toezicht op het registreren en aanleveren van taxivervoergegevens zoals dat in onderhavige regeling en bijbehorende koppelvlakspecificatie is opgenomen. Deze regeling is in samenspraak met de ILT tot stand gekomen. De ILT heeft praktijktoetsen over de werking van het systeem van de CDT uitgevoerd samen met grote en kleine taxibedrijven, bestuurders en ICT-dienstverleners. De bij deze praktijktoetsen betrokken partijen kunnen zich vinden in de systematiek van registratie en aanlevering aan de CDT.

3. Regeldruk en financiële gevolgen

In de toelichting op het Besluit van 25 april 2025, houdende wijziging van het Besluit personenvervoer 2000 en het Arbeidstijdenbesluit vervoer in verband met de invoering van de centrale database taxivervoer, zijn de regeldrukeffecten en financiële gevolgen van de invoering van de CDT uitgewerkt. Ten opzichte van de regels verbonden aan het systeem van de BCT zijn de regeldrukeffecten beperkt. De certificering conform ISO 27001 die in deze regeling verplicht wordt gesteld, vervangt de huidige RDW-erkenning van BCT fabrikanten en de huidige certificering van hardware en software. De verwachting is dat dit goedkoper is. Bij het opstellen van deze regeling bedroeg de prijs van de voorgeschreven norm ISO 27001 € 200,29 inclusief BTW.

4. Advies en consultatie

4.1 Handhavings- en uitvoerbaarheidstoets ILT

De ILT heeft een handhavings- en uitvoerbaarheidstoets uitgevoerd op de concept Regeling CDT. Naar aanleiding hiervan heeft de ILT een aantal verbeterpunten aangedragen ter voorkoming van discussie over terminologie gebruik en om een aantal onduidelijkheden weg te nemen. In gezamenlijk overleg zijn deze punten opgepakt en verwerkt in de regeling.

4.2 Internetconsultatie

Van 13 augustus 2024 tot en met 13 oktober 2024 heeft een openbare internetconsultatie plaatsgevonden van deze regeling. De reacties op die consultatie worden hierna afzonderlijk besproken.

De software branche maakt zich zorgen over de ISO certificeringseis en de kosten die dat systeem met zich brengt. Zij vrezen dat door deze kosten de kleinere bedrijven niet mee kunnen doen. Ook wordt getwijfeld aan kostenreductie gelet op de regelmatig benodigde vervanging van smartphones en tablets.

In reactie hierop wordt het volgende opgemerkt: Juist omdat het om taxivervoergegevens gaat, en de gegevens ook persoonsgegevens kunnen omvatten, wordt het noodzakelijk geacht om een ISO beveiligingssysteem op te nemen, opdat deze gegevens integer worden aangeleverd aan de CDT Meldingen API. Een beveiliging conform ISO 27001 is niet vrij van kosten. Voor de ISO 27001 is gekozen zodat onderscheid plaatsvindt tussen serieuze en niet serieuze aanbieders van innovatieve toepassingen. De aanschaf van een BCT en bijbehorend onderhoud is ook niet vrij van kosten. De inschatting is dat het stelsel van de CDT financieel goedkoper uitvalt voor de vervoerder dan het stelsel van de BCT. Het apparaat of de app die gebruikt wordt is vormvrij. Een vervoerder kan zelf onderzoeken welk apparaat of app voor hem, ook qua kosten, het beste werkt.

Met BCT wetgeving zijn hoge kwaliteitsstandaarden neergelegd waarbij databeschikbaarheid vanuit één bron gemeengoed is geworden. Door hieraan voorbij te gaan maakt de CDT een inferieure dan wel incomplete oplossing.

In reactie hierop wordt het volgende opgemerkt: De indiener doelt hier waarschijnlijk op de integratie van de huidige BCT met de taxamater waar bij sommige apparaten sprake van is. De CDT wetgeving staat los van de verplichting tot het hebben van een taxameter. De taxameter kan worden gekoppeld aan de door de vervoerder gekozen ICT-oplossing. Dat was en is echter geen eis.

De software branche maakt zich zorgen over de manipuleerbaarheid van de gegevens en meent dat een hack op versleutelde data niet meer nodig is om te manipuleren, maar dat louter het installeren van reeds bestaande apps hiervoor kunnen dienen.

In reactie hierop wordt het volgende opgemerkt: De taxivervoergegevens worden door gebruikmaking van een registratiemiddel realtime aangeleverd via een centrale applicatie aan de CDT. Aan de middelen en applicaties en het gebruik daarvan zijn (kwaliteits)voorwaarden gesteld. Deze voorwaarden worden gehandhaafd. Tegen misbruik wordt opgetreden.

In andere landen is er juist behoefte aan dedicated meetinstrumenten omdat opzichzelfstaande apps zonder koppeling met het voertuig onvoldoende inzicht kunnen bieden. Het is bijzonder dat wij in Nederland met de CDT-wetgeving tegen deze trend ingaan.

In reactie hierop wordt het volgende opgemerkt: Met deze wijziging in regelgeving wordt vooruit gelopen op de algemene digitalisering, ook in data verzamelen. Als gekozen wordt voor een app in plaats van een apparaat dan is deze app via validatie van het voertuig en de bestuurder digitaal gelinkt aan beide ook al is hij niet gekoppeld aan het voertuig zoals de BCT.

In de wetgeving wordt enkel gekeken naar de CDT als handhavingstool voor de ILT en niet naar andere partijen, zoals de belastingdienst. Deze andere partijen zullen dan met eigen eisen komen die deze oplossing nog complexer dan de BCT zal maken. De voordelen voor de vervoerder worden overschat.

In reactie hierop wordt het volgende opgemerkt: Andere instanties zijn in deze regelgeving niet gerechtigd om taxivervoergegevens te verzamelen uit de CDT. Dit is onder de BCT niet anders. Mogelijke toekomstige ontwikkelingen die momenteel niet te voorzien zijn, maken de inschatting dat de CDT financiële voordelen heeft voor de vervoerder, ook niet anders. De vervoerder is op grond van de Arbeidstijdenwet en het Arbeidstijdenbesluit vervoer verplicht om een eigen administratie te voeren. Taxivervoergegevens worden rechtstreeks aangeleverd aan de CDT waardoor de vervoerder ervoor moet zorgen, zo nodig via afspraken met de ICT-dienstverlener, dat de taxivervoergegevens op een server of anderszins beschikbaar blijven, zodat de vervoerder deze gegevens ook voor andere doeleinden kan gebruiken, zoals voor informatieverzoeken van andere instanties of voor de salariëring van onder zijn verantwoordelijkheid werkende bestuurders.

Vervoerders ervaren het als complex om voertuigen handmatig te gaan registreren met een kentekenbewijs. Gevraagd wordt om dit anders in te kleden. Ook wordt verwezen naar de aanzienlijke kostenverhogingen van dit proces.

In reactie hierop wordt het volgende opgemerkt: Bij overstap naar de CDT is in deze regeling voorgeschreven dat eenmalig de voertuigen moeten worden geregistreerd met het kentekenbewijs. Dit is dan ook een eenmalige exercitie die inderdaad wat extra tijd en inspanning vergt, maar niet als onoverkomelijk wordt beschouwd. Iedere vervoerder moet dit doen.

Er is geen handhaving rechtstreeks naar de ICT-dienstverlener. Hij is geen normadressaat. De vervoerder wordt aangesproken op het falen van zijn ICT-dienstverlener. Het is verder onduidelijk of er nog periodieke verificaties plaatsvinden met betrekking tot de datakwaliteit van de apps.

In reactie hierop wordt het volgende opgemerkt: De vervoerder is inderdaad de normadressaat. De vervoerder kan zelf een apparaat of app bouwen en installeren of een ICT-dienstverlener hiervoor in de arm nemen. Met deze dienstverlener zullen dan nadere afspraken moeten worden gemaakt in een overeenkomst zoals dat normaliter ook geschiedt tussen partijen. Als de ICT-dienstverlener de gemaakte afspraken niet nakomt, kan de overeenkomst met ICT-dienstverlener worden beëindigd en kan de vervoerder voor een andere ICT-dienstverlener gaan. Er moet gedurende de termijn van data-aanlevering aan de voorschriften van de regeling worden voldaan. De data die wordt aangeleverd moet juist worden aangeleverd. Als de datakwaliteit afneemt zal ILT aan de vervoerder en de ICT-dienstverlener aangeven dat de datakwaliteit niet goed is en dienen passende maatregelen te worden getroffen.

Controleren door middel van algoritmes over alle data zou niet toegestaan moeten worden. Er moet worden gecontroleerd op basis van steekproeven en bij slechte prestaties conform het principe van het SFT. Dat is wenselijker.

In reactie hierop wordt het volgende opgemerkt: Er wordt in de CDT niet gewerkt met algoritmes. Er wordt gehandhaafd door middel van data die bij controles op straat wordt ingevorderd alsook op basis van data uit de CDT. De data uit de CDT wordt geanalyseerd door een digitale inspectie, waarbij de data door een inspecteur wordt gecontroleerd op afwijkingen. ILT hanteert voor de handhaving een handhavingsstrategie. Dat er een CDT is met data wil dan ook niet zeggen dat elke minuscule overtreding ook per direct bestraft wordt. Automatische besluitvorming op basis van de data in de CDT vindt niet plaats. De tussenkomst van een inspecteur is essentieel om de beginselen van proportionaliteit en subsidiariteit toe te passen.

Er is aandacht gevraagd voor validatie van voertuigen. Het voorgestelde proces waarbij voertuigen alleen kunnen worden gevalideerd met behulp van een fysieke kentekenkaart leidt volgens deze indiener tot aanzienlijke kostenverhogingen voor ondernemers. Voor grotere, landelijke ondernemingen met een decentraal aangestuurd wagenpark is de voorgestelde werkwijze niet werkbaar. Door het logistieke proces, om al deze voertuigen en hun kentekenkaarten terug te laten komen naar verschillende werkplaatsen voor validatie, zullen de (operationele) kosten exponentieel stijgen. Daarnaast zouden op meerdere vestigingen uitleesapparatuur moeten worden geïnstalleerd en moet het personeel hiervoor getraind worden.

In reactie hierop wordt het volgende opgemerkt: Het valideren van het voertuig door het scannen van de kentekenkaart is een actie die éénmalig wordt uitgevoerd aan het begin van de ingebruikname van de auto door de vervoerder voor CDT. De rest van de gebruiksduur van de auto door de vervoerder is deze handeling niet nodig. Dit is dezelfde handeling voor grote vervoerders als voor kleine vervoerders. Grote vervoerders zullen het voordeel hebben dat ze per scanmiddel meerdere auto's kunnen scannen. Het in gebruik nemen van een auto of omzetten naar CDT zal naar verwachting vaak samenvallen met een bezoek aan een inbouwstation of garagebedrijf. Het kentekenbewijs van iedere auto dient in het bezit van de bestuurder te zijn, dus als iemand de auto naar inbouwstation of garagebedrijf brengt waar een scanmiddel is, lijkt dat een geschikt moment om de kentekenkaart te scannen.

Een indiener ziet praktische bezwaren met betrekking tot de registratie van de voertuigen van de ondernemers. Het is verplicht om voertuigen te registreren met een kentekenbewijs. Dit wijkt volgens de indiener af van de voorkeur van vervoerders om dit anders te doen, omdat zij in dat geval aanzienlijke handmatige arbeid moeten verrichten om alle kentekenbewijzen apart te scannen. De uitdaging zit in het feit dat het kentekenbewijs een smartcardchip bevat in plaats van een gebruiksvriendelijkere optie zoals NFC. Dit betekent dat de chip alleen kan worden uitgelezen na aanschaf van specifieke hardware.

In reactie hierop wordt het volgende opgemerkt: Een smartcardreader is eenvoudig aan te schaffen via alle online winkels of in de lokale telecomwinkel. De smartcardreader is daarmee geen complex onderdeel binnen de regelgeving.

KNV Zorgvervoer en Taxi heeft bij de internetconsultatie een aantal vraagpunten neergelegd. Hierop is in een aparte brief gereageerd.

Artikelsgewijs deel

Artikel 1

In artikel 1 zijn de begripsbepalingen opgenomen.

Een toelichting op de begrippen CDT, CDT meldingen API en ICT-oplossing is gegeven in paragraaf 1 van het algemene deel van deze toelichting. Het begrip ‘registratiemiddel’ is gedefinieerd in het Besluit Personenvervoer 2000.

Voor de definitie van het begrip pauze is aangesloten bij de kenmerken van dit begrip in artikel 1:7, eerste lid, onderdeel e van de Arbeidstijdenwet. De definitie uit de arbeidstijdenwet is niet rechtstreeks van toepassing op chauffeurs die als zelfstandige werken, daarom is voor het doel van deze regeling een aparte definitie opgesteld.

Een twee factor authenticatie is een methode waarbij de identiteit van een persoon wordt vastgesteld op basis van twee verschillende factoren. Er kan hierbij aan de volgende factoren worden gedacht: kennis (het weten van een wachtwoord), bezit (het bezit van een apparaat) of persoonskenmerken (bijvoorbeeld een vingerafdruk of het gelaat van een persoon). Deze factoren kunnen worden ingebouwd in een ICT-oplossing. De ICT-oplossing moet AVG compliant zijn. Deze gegevens dienen enkel ter identificatie van de bestuurder. ILT vertrouwt op de twee factor dienst van het registratiemiddel. De ILT gebruikt de gegevens die worden ingezet voor de twee factor authenticatie niet. De gegevens worden niet opgeslagen of uitgewisseld door ILT. De houder van een smartphone of tablet, in dit geval de bestuurder, moet zelf instellen of gezichtsherkenning of een vingerafdruk gebruikt mag worden. Kiest de bestuurder er voor om dit niet te gebruiken, dan kan hij kiezen voor de andere factoren waarmee hij zich kan identificeren, niet zijnde biometrische gegevens. Het registratiemiddel maakt twee factor authenticatie zonder gebruikmaking van biometrische gegevens (ook) mogelijk.

Artikel 2 (Registreren en aanleveren van taxivervoergegevens)

Als de vervoerder kiest voor het aanleveren van taxivervoergegevens aan de CDT, moet de vervoerder aangesloten zijn op de CDT Meldingen API om aan zijn verplichting tot gegevenslevering te kunnen voldoen. Vanaf 1 januari 2028 is het verplicht om aan te leveren aan de CDT en dus om aangesloten te zijn op de CDT Meldingen API. De vervoerder wordt aangesloten als hij voldoet aan de voorwaarden van deze Regeling. Het voldoen aan de voorwaarden van de Regeling is een doorlopende verplichting.

Een vervoerder meldt de door hem gebruikte ICT-oplossing bij ILT. Hij geeft aan van welk registratiemiddel en van welke centrale applicatie hij gebruik gaat maken of hij dat zelf regelt of via een ICT-dienstverlener en welke ICT-dienstverlener dat dan is. Als de applicatie(s) of appara(a)t(en) voldoen aan de voorgeschreven functionaliteiten en voorzieningen, wordt de ICT-oplossing die door de vervoerder wordt gebruikt, aangesloten op de CDT. Als de vervoerder overstapt naar een andere ICT-dienstverlener meldt hij dit ook aan de ILT.

De bestuurder registreert met een registratiemiddel, dat hij heeft toegewezen gekregen van de vervoerder, zijn taxivervoergegevens. Deze gegevens worden vervolgens direct doorgezonden aan de CDT Meldingen API middels een centrale applicatie die in beheer is bij de vervoerder of een derde private partij en die voldoet aan de voorschriften uit deze Regeling.

Het kan voorkomen dat er zich omstandigheden voordoen waardoor er niet aangeleverd kan worden. Dit kunnen een uitval van de CDT-meldingen API als gevolg van onderhoud of technische problemen zijn of een verstoring van de datacommunicatie of andere technische problemen.

De gebruikte ICT-oplossing moet dan de gegevens die zijn en worden geregistreerd vasthouden (‘bufferen’), zodat deze gegevens alsnog aangeleverd kunnen worden aan de CDT Meldingen API als de omstandigheden waardoor niet geleverd kan worden zijn opgehouden te bestaan. De alsnog te leveren gegevens moeten, zoals beschreven in de koppelvlakspecificatie in de bijlage van de regeling, in chronologische volgorde en in beperkt volume worden aangeleverd. De vervoerder is ook onder deze omstandigheden verantwoordelijk voor het bijhouden van een deugdelijke administratie.

De gegevens en de berichten die worden gehanteerd voor het aanleveren aan de CDT staan omschreven in de bijlage bij deze regeling, de ‘Koppelvlakspecificatie CDT’.

Artikel 3 (Zorgplichten vervoerder)

In dit artikel zijn zorgplichten voor de vervoerder aangegeven over de registratie en het aanleveren van gegevens. De vervoerder moet ervoor zorgen dat de bestuurder beschikt over een deugdelijk registratiemiddel en dat de bestuurder de vereiste gegevens registreert. Bij uitval of verloren gaan van het registratiemiddel moeten de taxivervoergegevens op een andere wijze worden vastgelegd, bijvoorbeeld op papier. Dit mag gedurende een periode van drie werkdagen. Daarna moet de bestuurder weer een deugdelijk registratiemiddel hebben. De vervoerder moet deze gegevens alsnog aanleveren aan de CDT.

De vervoerder is verplicht om de arbeids- en rusttijden door te geven aan de CDT. Daarnaast blijft de vervoerder ook na invoering van de CDT verplicht om op grond van artikel 2.4:1 van het Arbeidstijdenbesluit vervoer de geregistreerde arbeids- en rusttijden voor een periode van 104 weken te bewaren.

Als de CDT Meldingen API foutmeldingen of waarschuwingen geeft op berichten, dient de vervoerder actie te ondernemen om de oorzaken van de foutmeldingen of waarschuwingen te verhelpen. Het streven is er op gericht gegevens aan te leveren zonder foutmeldingen of waarschuwingen. Het voldoen aan de voorwaarden van de Regeling is een doorlopende verplichting.

Artikel 4 (Validatie van de bestuurder)

De vervoerder controleert of de betreffende bestuurder taxivervoer mag verrichten. Alleen een door de vervoerder gevalideerde bestuurder mag taxivervoer voor die vervoerder verrichten. Als een bestuurder voor meerdere vervoerders werkt, moet hij door elk van die vervoerders worden gevalideerd voor de CDT.

Artikel 5 (Validatie van de auto waarmee taxivervoer wordt verricht)

Voordat de auto wordt gebruikt moet éénmalig de validatie worden uitgevoerd. Validatie betekent dat op basis van het kentekenbewijs het voertuig is geïdentificeerd als voertuig voor taxivervoer. Er mag alleen taxivervoer worden verricht in een auto die gevalideerd is. Validatie is nodig zodat inzichtelijk is dat de vervoerder rechtmatig beschikt over de auto. De vervoerder moet in zijn eigen administratie vastleggen dat validatie heeft plaatsgevonden. Valideren van de auto wordt gedaan door de kentekenkaart elektronisch uit te lezen en de authenticiteit vast te stellen door een elektronische challenge-response transactie. Deze vastlegging is vormvrij en moet bij controle getoond kunnen worden. Bijvoorbeeld de challenge, de public key en de encrypted response zouden vastgelegd kunnen worden. Hiermee is controleerbaar of een bepaalde kentekenkaart is geauthentiseerd.

Artikel 6 (Aanmelden van de bestuurder)

De bestuurder die zich aanmeldt door zijn rijbewijs elektronisch te laten authentiseren mag taxivervoer verrichten voor de vervoerder. De vervoerder moet weten wie de auto bestuurt waarmee taxivervoer wordt verricht. De toezichthouder moet weten van wie de taxivervoergegevens afkomstig zijn. Zonder authenticatie is het daarom niet toegestaan om taxivervoer te verrichten. Het rijbewijs kan defecten vertonen, waardoor het de bestuurder niet lukt om zich op het registratiemiddel aan te melden. In dat geval kan de bestuurder zich tijdens een periode van maximaal tien aaneengesloten kalenderdagen aanmelden met twee-factor authenticatie. In die tijd kan de bestuurder vaststellen of bijvoorbeeld de chip of de antenne defect of onleesbaar is en een nieuw rijbewijs regelen. Voor het verkrijgen van een nieuw rijbewijs hanteren de RDW en gemeenten een termijn van vijf werkdagen. Ook is er een spoedprocedure voor de aanvraag van een nieuw rijbewijs. De termijn van tien dagen moet daarmee voldoende zijn om problemen met een defect rijbewijs op te lossen.

Artikel 7 (Gebruik van registratiemiddel door de bestuurder)

De CDT wordt gebruikt voor de volledige registratie van de arbeids- en rusttijden van de bestuurder. Dit maakt de controle op de arbeids- en rusttijden mogelijk. Zonder volledige en deugdelijke registratie van de arbeids- en rusttijden is het toezicht op de naleving immers niet mogelijk. Daarbij wordt ook verwezen naar artikel 4:3 van de Arbeidstijdenwet en de toelichting op dit artikel. De tijd die de bestuurder besteedt aan werkzaamheden in de taxi, wordt realtime doorgegeven aan de CDT. Dit gaat dan zowel om taxivervoer als om overige werkzaamheden in de auto, zoals het naar de wasstraat rijden. Alle overige werkzaamheden die de bestuurder heeft verricht nadat hij zich eerder heeft afgemeld, moeten handmatig in het registratiemiddel worden ingevoerd op het moment van aanmelden als taxichauffeur in de auto. Dit gaat dan zowel om werkzaamheden buiten de auto, zoals bijvoorbeeld het bijwonen van een vergadering op het kantoor van de vervoerder, als om werkzaamheden in de auto, bijvoorbeeld als een zelfstandige ondernemer zijn taxi gebruikt voor het uitvoeren van diensten als koerier. Als de bestuurder nevenwerkzaamheden heeft buiten de auto, bijvoorbeeld in loondienst bij een werkgever, moet hij die ook invoeren bij aanmelding. Ook als de bestuurder werkzaamheden verricht die gerelateerd kunnen zijn aan het taxivervoer voordat hij zich aangemeld heeft, zoals tanken, moet hij dat handmatig invoeren.

Het vervoeren van personen start zodra de eerste persoon instapt en eindigt als de laatste persoon uitstapt. Het uitvoeren van groepsvervoer, waarbij in één rit meerdere personen worden opgehaald op verschillende locaties en/of uitstappen op verschillende locaties mag worden aangeleverd als één rit of als individuele ritten per persoon.

Binnen het contractvervoer hoeft de ritprijs niet te worden geregistreerd. Bij dit type vervoer mag een 0 worden ingevoerd bij ritprijs, zoals nu ook al het geval is bij de BCT.

Genoten pauzes moeten ook realtime worden gemeld door ze bij het begin van de pauze aan te melden en aan het einde van de pauze weer af te melden. Pauzes kunnen niet achteraf worden gemeld.

Artikel 8 (Registratiemiddel)

De aanlevering van taxivervoergegevens vindt plaats via een centrale applicatie. Deze applicatie bevat de realtime geregistreerde gegevens uit het registratiemiddel bestuurder en zet deze gegevens realtime door naar de CDT Meldingen API. De registratie van taxivervoergegevens vindt plaats op een registratiemiddel. Dit is een specifiek voor dat doel gemaakt apparaat of een applicatie op een generiek apparaat dat de beschreven technische en functionele eigenschappen heeft. Het registratiemiddel zet de geregistreerde gegevens realtime door naar de centrale applicatie. De voorziening genoemd in het eerste lid, onder j, is nodig voor het bufferen in geval taxivervoergegevens niet realtime aan de centrale applicatie kunnen worden doorgegeven. De gegevens moeten beschikbaar zijn totdat ze zijn aangeleverd aan de CDT.

Artikel 9 (Centrale applicatie)

De aanlevering van taxivervoergegevens vindt plaats via een centrale applicatie. Deze applicatie bevat de realtime geregistreerde gegevens uit het registratiemiddel en zet deze gegevens realtime door naar de CDT Meldingen API. Deze applicatie moet daarvoor bepaalde eigenschappen bezitten die in dit artikel worden voorgeschreven. De bepalingen over de volgorde van aanleveren in het tweede lid onder b en c zijn in het bijzonder van belang in het geval dat taxivervoergegevens niet realtime aangeleverd konden worden bij technische problemen zoals bedoeld in artikel 2, vijfde lid. De gebufferde berichten moeten in de juiste volgorde worden aangeleverd.

Artikel 10 (Informatiebeveiliging)

Voor de informatiebeveiliging van de ICT-middelen en de bijbehorende organisatie is voorgeschreven dat de vervoerder gebruik maakt van een ICT-oplossing en een organisatie die zijn gecertificeerd voor de ISO 27001. De Raad voor Accreditatie of andere erkende accreditatie instelling in de EU toetst of deze certificering is uitgevoerd door een onafhankelijk, onpartijdig en deskundige instantie. Het werkingsgebied van deze certificering omvat alle middelen die betrokken zijn bij de levering van taxivervoergegevens aan de CDT Meldingen API. De integriteit van de levering van de taxivervoergegevens is belangrijk: de gegevens die de vervoerder, of de bestuurder in opdracht van de vervoerder aanlevert moeten juist, volledig en tijdig aan de CDT Meldingen API worden geleverd. Hierdoor kan de toezichthouder erop vertrouwen dat de informatie afkomstig is van de vervoerder en de bestuurder.

Artikel 11 (Inwerkingtreding)

De inwerkingtreding van deze regeling op 1 juli 2025 is gelijktijdig met de inwerkingtreding van de artikelen I en III van het Besluit tot wijziging van het Besluit personenvervoer 2000 in verband met de invoering van de centrale database taxivervoer. Zowel de taxibranche als de inspectie bereiden zich voor op de mogelijkheid om per 1 juli 2025 gebruik te kunnen maken van de CDT. Daarom wordt de minimuminvoeringstermijn van twee maanden niet aangehouden. Dit voorkomt de nadelen van vertraging voor de sector (Aanwijzingen voor de regelgeving 4.17 onder 5 sub). De overschakeling op de CDT is geen verplichting per 1 juli 2025. Een snelle invoering levert dan ook geen nadelen voor de branche op.