Te allen tijde en in verschillende situaties kan een reisdocument door de houder of een andere persoon worden ingeleverd bij een autoriteit van afgifte. Volg de onderstaande procedure.

Voorbeelden van situaties waarin een onttrekking door inleveren relevant is:

• De houder krijgt een nieuw reisdocument uitgereikt van dezelfde soort. Het oude reisdocument dient te worden onttrokken conform artikel 32 Paspoortwet.
• Er vindt één van de situaties ingevolge artikel 47 Paspoortwet of artikel 48 Paspoortwet plaats en het reisdocument wordt hierbij getoond en is direct beschikbaar voor onttrekking. Zie ook Veranderingen met gevolgen voor reisdocumenten.
• De houder toont een reisdocument wat in het verleden al geregistreerd is als ongeldig (of zelfs geregistreerd definitief onttrokken). Conform Artikel 54 Paspoortwet dient het reisdocument direct te worden onttrokken.
• Een nabestaande of betrokkene van een (bevestigd) overleden houder levert het reisdocument van de overledene in. Zie ook Persoon overleden.

Handelingen

1. Gebruik Opvragen reisdocumentinformatie en zoek en vind gegevens over (het) reisdocument(en) van de persoon in het Basisregister reisdocumenten. Bespreek de huidige status van het reisdocument of reisdocumenten met de persoon.
2. Gebruik Meldingregistratie en registreer de onttrekking volgens onderstaande registratie procedure.
3. Vernietig of maak het reisdocument onbruikbaar conform de geldende regelgeving.

Registratie procedure

1. Registreer de definitieve onttrekking: 
   • Melding: reisdocument is definitief onttrokken (RDO).
   • Reden: reisdocument is ingeleverd (REDO).
   • Datum reden: de datum waarop het reisdocument daadwerkelijk wordt/werd onttrokken aan het verkeer. In de meeste gevallen is dit dezelfde datum als de datum van de melding.
2. Werk de BRP/PIVA bij als de melding een reisdocument van een ingezetene betreft.
   • Registreer een I bij het reisdocument in de BRP/PIVA, of
   • Stuur een C3 met notificatie van onttrekking naar de gemeente/land/openbaar lichaam van inschrijving van de houder ter verwerking in de BRP/PIVA.

1 Probleemstelling

1.1 Omschrijving

Nu tabel 34 Landentabel is geactualiseerd per 1 april 2026 en alle namen in overeenstemming zijn gebracht met de adviezen van de Nederlandse Taalunie, is het ook goed om dit te doen voor tabel 32 Nationaliteitentabel. Het is immers niet logisch om te spreken van Kenia in plaats van Kenya, maar de nationaliteit nog wel “Kenyaans” te noemen. Ook staan er wat onjuiste namen in de tabel. Met deze wijziging wordt de nationaliteitentabel “opgefrist”.

1.2 Herkomst

Deze wijziging komt voort uit een analyse van verschillen tussen de namen nationaliteitentabel en de aanwijzingen van de Nederlandse Taalunie en de wens om die verschillen te minimaliseren.

1.3 Raakvlakken

Er zijn geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

In de huidige nationaliteitentabel komen namen soms niet overeen met de aanbevelingen van de Nederlandse Taalunie.

2.2 Oplossing

Namen van nationaliteiten worden aangepast conform de aanwijzingen van de Nederlandse Taalunie. Als zowel de spelling met oe is toegestaan, als die met een u (zoals bij Oeganda / Uganda), kiezen we voor oe. Als de naam van een nationaliteit wijzigt, wijzigt alleen de inhoud van element 05.12 Omschrijving nationaliteit. De datum ingang tabelregel en de eventuele datum beëindiging tabelregel wijzigen niet. Er is dan ook geen impact op persoonslijsten.

Hieronder volgt een overzicht van alle wijzigingen in de namen van nationaliteiten:

2.3 Openstaande punten

Er zijn na de inwerkingtreding van deze wijziging geen openstaande punten.

3 Invoering

De wijzigingen worden bij voorkeur doorgevoerd op 1 januari 2027.

4 Gevolgen

4.1 Documentatie

Deze wijziging hoeft alleen doorgevoerd te worden in tabel 32 Nationaliteitentabel.

4.2 Gemeenten

Gemeenten moeten er rekening mee houden dat de aangepaste namen van nationaliteiten kunnen worden getoond op schermen en op uittreksels uit de hun burgerzakensystemen. Verder moeten ze de bijbehorende tabelberichten kunnen verwerken.

4.3 Afnemers

Afnemers moeten er rekening mee houden dat de aangepaste namen kunnen worden getoond op schermen en in documenten. Verder moeten ze de bijbehorende tabelberichten kunnen verwerken.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

De (ei)landen van het Caribisch deel van het Koninkrijk moeten er rekening mee houden dat de aangepaste namen van nationaliteiten kunnen worden getoond op schermen en op uittreksels uit de PIVANOBO.

4.6 RvIG-systemen

De BRP-V en de RNI moeten de aangepaste namen kunnen tonen op schermen en in documenten. Verder moeten ze de bijbehorende tabelberichten kunnen verwerken.

1 Probleemstelling

1.1 Omschrijving

Met ingang van Logisch Ontwerp BRP 2024.Q1 wordt een vaste koppeling afgedwongen tussen het te registreren actuele woon- of briefadres in de BRP en een geldig adresseerbaar object in de BAG. Dit betekent dat zowel rubriek 08.11.80 Identificatiecode verblijfplaats als rubriek 08.11.90 Identificatiecode nummeraanduiding voor een actueel adres in de BRP altijd een geldige identificatiecode van een adres van een adresseerbaar object uit de BAG moet bevatten. De Identificatiecode nummeraanduiding moet altijd verwijzen naar het hoofdadres van het adresseerbaar object in de BAG tenzij de briefadresgever een gemeente of een organisatie is. In dat geval mag de Identificatiecode nummeraanduiding ook verwijzen naar een nevenadres van het adresseerbaar object in de BAG. 

Op deze wijziging in LO BRP (W180 Vaste koppeling BAG-BRP) zijn twee aanvullingen gekomen ter nuancering:

• In LO 2024.Q2 is toegevoegd dat ook nevenadressen in de BRP mogen worden opgenomen als het om een briefadres gaat, mits de briefadresgever een gemeente of organisatie is (W190 1e Aanvulling op W180).
• In LO 2025.Q3 is een nuancering aangebracht dat adresgegevens in de BRP niet overeen hoeven te komen met die in de BAG als een verblijfsobject in de BAG de indicatie “geconstateerd” heeft of als het adresgegeven in de BAG in onderzoek staat.

In het Logisch Ontwerp is de koppeling tussen BAG en BRP zo geformuleerd dat bepaalde adreselementen, te weten 11.50 Aanduiding bij huisnummer en 12.10 Locatieomschrijving niet voorkomen in categorie 08 (maar nog wel in categorie 58). Die formulering is misleidend. Als voorschrift is het volkomen terecht: het is niet de bedoeling dat die elementen nog gebruikt worden, maar als beschrijving van hoe het systeem werkelijk werkt klopt het niet, omdat deze elementen nog wel voor kúnnen komen in de BRP. Het schrappen van dit element in de aangesloten systemen kan zorgen voor protocolfouten, omdat ontvangende partijen het element niet (meer) verwachten. Met onderhavige LO-wijziging wordt dit rechtgezet.

1.2 Herkomst

Deze wijziging komt voort uit kritische opmerkingen van binnen en buiten RvIG.

1.3 Raakvlakken

Er zijn vooralsnog geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

In de beschrijving van categorie 08/58 in het LO staat nu: “Groep 12 komt niet voor.” In de beschrijving van groep 11 staat: “Voor categorie 08 geldt: […] Het element 11.50 komt niet voor.” Als voorschrift is dit correct, maar als beschrijving van de werkelijke stand van zaken niet. Een gemeente moet iemand immers inschrijven op het adres dat hij opgeeft en het kan dus voorkomen dat dit (al was het maar tijdelijk) een adres is dat (nog) niet voorkomt in de BAG, of waarvoor een locatieomschrijving of aanduiding nodig is. Ook kan het element voorkomen in categorie 08 van een persoonslijst die is opgeschort wegens overlijden voor de datum invoering van LO.2024.Q1. Deze gegevens kunnen nog verstrekt worden aan afnemers endaarom moeten zij element ook kunnen ontvangen.

2.2 Oplossing

In de beschrijvingen van categorie 08/58, groep 11, groep 12, element 11.50 en element 12.10 wordt expliciet vermeld dat deze elementen (en dus ook groep 12) niet voor mogen komen, maar nog wel voor kunnen komen. 

2.3 Openstaande punten

Er zijn na de inwerkingtreding van deze wijziging geen openstaande punten.

3 Invoering

Omdat deze wijziging geen impact heeft op systemen, maar vooral een verheldering betreft in het LO, is deze wijziging gepland voor LO 202j.Qk (1 ??? 2027).

4 Gevolgen

4.1 Documentatie

Deze wijziging in LO BRP heeft geen gevolgen voor andere logisch ontwerpen (LO BSN, LO BRPk, LO BES en LO PBK), ook niet voor de HUP en de WIR. 

4.2 Gemeenten

Geen gevolgen.

4.3 Afnemers

Geen gevolgen. Alleen wordt duidelijk dat element 11.50 en 12.10 nog wel voor kunnen komen op persoonslijsten (en dus ook in berichten), ook al mag dat niet meer.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

Geen gevolgen.

1 Probleemstelling

1.1 Omschrijving

De mailboxserver ondersteunt alleen berichten met een MessageBody van maximaal 19.000 tekens, waarbij geldt dat diakritische tekens als een afzonderlijk teken worden geteld. Er zijn op dit moment een aantal persoonslijsten waarvan de maximale lengte is of dreigt te worden overschreden. Om die persoonslijsten toch te kunnen verhuizen naar den andere gemeente of de RNI, of om deze na een mutatie te kunnen synchroniseren met de BRP-Verstrekkingsvoorziening, adviseert RvIG de gemeente of de RNI om zo’n persoonslijst in te korten. RvIG verzoekt de gemeente dan om een deel van de adreshistorie te verwijderen uit categorie 58. Op de persoonslijst bij de woongemeente gaan hierdoor adresgegevens verloren, maar in BRP-V is de gehele persoonslijst zichtbaar voor afnemers. Door deze werkwijze kan een te lang geworden persoonslijst alsnog verhuizen naar een andere gemeente of synchroniseren met BRP-V.

Ondanks dat de technische beperking van de mailboxserver in het Logisch Ontwerp wordt vermeld, is nergens aangegeven wat gemeenten moeten doen als een persoonslijst de maximale lengte van 19.000 tekens dreigt te overschrijden. Door een enkele zin toe te voegen aan het LO, wordt aan gemeenten en RNI-loketten duidelijk gemaakt hoe in zulke gevallen te handelen. 

1.2 Herkomst

Deze wijziging komt voort uit ervaringen uit het verleden met lange persoonslijsten.

1.3 Raakvlakken

Er zijn geen raakvlakken met andere LO-wijzigingen. 

2 Oplossing

2.1 Huidige situatie

In het Logisch Ontwerp BRP, in de beschrijving het sPd-protocol, de algemene definities staat bij het element Length dat de MessageBody van een bericht een maximale lengte heeft van 19.000 octets (bytes) ofwel tekens (elk teken in de Teletex tekenset wordt gecodeerd in één byte). Ook staat in het LO dat wanneer een bericht wordt aangeboden dat langer is, de mailboxserver een foutcode zal retourneren: 1241. Deze code betekent dat er een bericht is aangeboden waarvan de body meer dan 19.000 tekens bevat. Van een eindsysteem wordt verwacht dat het de lengte controleert voordat het bericht aan de berichtendienst wordt aangeboden. Er staat echter niet wat de afzender moet doen in zo’n geval om het bericht alsnog verzonden te krijgen.

RvIG adviseert in zulke gevallen om de persoonslijst in te korten, maar gemeenten zijn hier huiverig voor omdat in de BRP slechts bij hoge uitzondering gegevens van een persoonslijst mogen worden verwijderd. De BRP-V beschikt echter altijd over de volledige inhoud van de persoonslijst, ook als die door gemeenten of de RNI wordt ingekort. Hoewel gemeenten dus terughoudend zijn met verwijderen van gegevens, garandeert RvIG dat de afslag van volledige PL via BRP-V beschikbaar blijft voor wettelijke doeleinden.

Op dit moment worden 24 persoonslijsten gemonitord omdat ze te lang dreigen te worden; dit gebeurt door wekelijks een Lq01-bericht te sturen naar de huidige gemeente van inschrijving. Daarvan zijn 18 persoonslijsten al ingekort.

NB: Berichtendienstberichten die worden uitgewisseld via de webservice StuurGBAbericht of via de BRP Berichten API kennen géén maximale lengte van de berichtinhoud!

2.2 Oplossing

Aan de beschrijving van foutcode 1241 in paragraaf 6.2.5.4 van het Logisch Ontwerp BRP wordt een zin toegevoegd, en wel als volgt:

Berichtinhoud te lang (Body too long).
Er is een bericht aangeboden waarvan de body meer dan 19000 tekens bevat. Van een eindsysteem wordt verwacht dat het de lengte controleert voordat het bericht aan de berichtendienst wordt aangeboden. Om te zorgen dat een persoonslijst toch via de mailboxserver kan worden verzonden, kan RvIG een gemeente of de RNI adviseren de persoonslijst in te korten.

Deze wijziging maakt expliciet duidelijk dat gemeenten en RNI een persoonslijst mogen, zelfs moeten inkorten om ervoor te zorgen dat die alsnog via de mailboxserver kan worden uitgewisseld.

2.3 Openstaande punten

Er zijn na de inwerkingtreding van deze wijziging geen openstaande punten.

3 Invoering

Omdat deze wijziging in het Logisch Ontwerp géén impact heeft op de software van de verschillende systemen in het BRP-stelsel, is deze wijziging gepland voor LO BRP 2026.Q4 (1 oktober 2026). 

4 Gevolgen

4.1 Documentatie

Deze wijziging in LO BRP heeft geen gevolgen voor andere logisch ontwerpen (LO BSN, LO BRPk, LO BES en LO PBK) of voor de HUP en de WIR.

4.2 Gemeenten

Voor gemeenten is straks duidelijk dat het LO expliciet toestaat dat te lange persoonslijsten worden ingekort. Dit mag alleen op advies van of in overleg met RvIG. 

4.3 Afnemers

Geen gevolgen.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

Geen gevolgen.

1 Probleemstelling

1.1 Omschrijving

Sinds 2014 wordt er geen vreemde nationaliteit naast de Nederlandse meer geregistreerd in de Basisregistratie Personen (BRP) als mensen de Nederlandse nationaliteit al vanaf de eerste inschrijving hadden. De vreemde nationaliteiten naast de Nederlandse die vóór 2014 zijn geregistreerd, zijn op 31 januari 2015 “beëindigd” met reden 404, maar nooit verwijderd. Het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK) heeft hier klachten over ontvangen. Naar aanleiding van deze klachten en met oog op datakwaliteit heeft BZK de afgelopen periode onderzocht of en hoe deze gegevens over vreemde nationaliteiten naast de Nederlandse worden gebruikt door afnemers van de BRP. Uit deze inventarisatie is gebleken dat de noodzakelijkheid van deze gegevens voor de uitvoeringspraktijk zeer beperkt is. De Rechtbank Rotterdam heeft in lijn hiermee op 11 februari 2025 geoordeeld dat het bewaren van de beëindigde vreemde nationaliteiten naast de Nederlandse niet noodzakelijk en daarmee in strijd met de Wet BRP (artikel 2.7 eerste lid, aanhef, onder a en onder 5) en de AVG is. Tevens oordeelt de rechtbank dat op grond van art. 2.58 burgers het recht hebben om te verzoeken deze gegevens te wissen uit de BRP.

Met LO-wijziging LO-444 Beëindigde vreemde nationaliteiten verwijderen bij individuele PL is mogelijk gemaakt dat een vreemde nationaliteit wordt verwijderd uit de BRP als een burger die naast die vreemde nationaliteit de Nederlandse nationaliteit of het bijzonder Nederlanderschap al sinds de geboorte of eerste inschrijving heeft, daarom verzoekt. Als bij een aangifte of verwerking van een brondocument blijkt dat iemand de Nederlandse nationaliteit of het bijzonder Nederlanderschap al had vanaf de geboorte of vanaf de eerste inschrijving in de BRP, dan worden eventuele vreemde nationaliteiten zelfs zonder zo’n verzoek verwijderd van de persoonslijst.

Met onderhavige LO-wijziging wordt een conversieprocedure voorgeschreven waarin alle vreemde nationaliteiten in bulk worden verwijderd uit de BRP van personen die de Nederlandse nationaliteit of het bijzonder Nederlanderschap hebben sinds de geboorte of sinds de eerste inschrijving in de BRP.

1.2 Herkomst

Deze wijziging komt voort uit een verzoek van BZK om te regelen dat beëindigde vreemde nationaliteiten die personen al vanaf de geboorte hebben, worden verwijderd uit de BRP.

1.3 Raakvlakken

Er zijn vooralsnog geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

Sinds 2014 wordt er geen vreemde nationaliteit naast de Nederlandse meer geregistreerd in de Basisregistratie Personen (BRP) als mensen de Nederlandse nationaliteit al vanaf de eerste inschrijving hadden. De vreemde nationaliteiten naast de Nederlandse die vóór 2014 zijn geregistreerd, zijn echter nooit verwijderd; ze zijn alleen historisch geworden door ze te beëindigen met code 404: Beëindiging registratie (niet-Nederlandse) nationaliteit. Het komt echter ook na 2014 nog voor dat mensen al vanaf de eerste inschrijving naast de Nederlandse nationaliteit ook nog een beëindigde vreemde nationaliteit hebben, bijvoorbeeld als pas na het moment van de eerste inschrijving blijkt dat iemand ook toen al de Nederlandse nationaliteit had. Er zijn op dit moment ongeveer 800.000 personen met zo’n beëindigde vreemde nationaliteit, terwijl ze de Nederlandse nationaliteit of het bijzonder Nederlanderschap al vanaf geboorte of vanaf eerste inschrijving hadden.

Het handmatig verwijderen van een vreemde nationaliteit is geregeld in LO-wijziging LO-444 Verwijderen beëindigde vreemde nationaliteiten bij individuele pl. Maar zolang een burger zo’n verzoek niet indient en geen aangifte doet waaruit blijkt dat hij de Nederlandse nationaliteit of het bijzonder Nederlanderschap al vanaf geboorte of vanaf eerste inschrijving had, blijven eventuele beëindigde vreemde nationaliteiten op zijn persoonslijst staan. Bovendien zijn de voorwaarden waaraan een persoonslijst moet voldoen om vreemde nationaliteiten te verwijderen in LO-444 nog iets te streng, waardoor te weinig vreemde nationaliteiten in aanmerking komen.

2.2 Oplossing

Aan (leveranciers van) gemeentelijke burgerzakensystemen en de RNI wordt gevraagd om alle met reden 404 beëindigde nationaliteiten van personen die al vanaf de geboorte of vanaf de eerste inschrijving ook de Nederlandse nationaliteit of het bijzonder Nederlanderschap hadden, in bulk te verwijderen. Om precies te zijn moet een PL voldoen aan de volgende voorwaarden om een beëindigde vreemde nationaliteit te mogen verwijderen (overal waar hieronder sprake is van de Nederlandse nationaliteit geldt het zelfde voor het bijzonder Nederlanderschap):

• De persoon is niet overleden EN
• De persoon heeft (of had!) een vreemde nationaliteit EN 
• De persoon heeft de Nederlandse nationaliteit EN

• (

  • De ingangsdatum van de Nederlandse nationaliteit is ongelijk aan de standaardwaarde OF
  • De opnamedatum van de Nederlandse nationaliteit is kleiner dan of gelijk aan de datum van eerste inschrijving in de BRP

  ) EN

• De persoon heeft de Nederlandse nationaliteit nooit verloren EN (

  • De ingangsdatum van de Nederlandse nationaliteit is gelijk aan de geboortedatum van de persoon, OF 
  • De ingangsdatum van de Nederlandse nationaliteit is kleiner dan of gelijk aan die van de vreemde nationaliteit, OF
  • De ingangsdatum van de Nederlandse nationaliteit is kleiner dan of gelijk aan de datum van eerste inschrijving in de BRP

  )

Let wel: vreemde nationaliteiten die aan deze voorwaarden voldoen, zouden met reden 404 beëindigd moeten zijn en daarom komt die code (opgenomen in rubriek 04.64.10 Reden beëindigen nationaliteit) zelf niet in de voorwaarden voor. Als iemand ná zijn geboorte of na eerste inschrijving in de BRP pas de Nederlandse nationaliteit of het bijzonder Nederlanderschap heeft gekregen, dan zijn eventuele vreemde nationaliteiten óók beëindigd met reden 404, maar die nationaliteiten mogen niet verwijderd worden.

Na het verwijderen van nationaliteiten van een persoonslijst moet er voor die PL een Lg01-berihcht worden verzonden naar BRP-V. In principe verstuurt BRP-V na verwerking van deze mutaties géén Ag31-berichten, tenzij afnemers daar expliciet om vragen. Er zijn ruim 125 afnemers geautoriseerd voor gegevens uit categorie 04/54, maar die hebben uiteraard niet allemaal bij al die 800.000 persoonslijsten een afnemersindicatie geplaatst.

2.3 Openstaande punten

Er zijn na de inwerkingtreding van deze wijziging geen openstaande punten meer.

3 Invoering

Voordat een leverancier overgaat tot het verwijderen van de met reden 404 beëindigde nationaliteiten, is het goed om te verifiëren dat de juiste categoriestapels worden verwijderd. Dit zal worden gedaan door leveranciers te vragen om voor één of twee gemeenten een proefconversie te doen (net als bij een gemeentelijke herindeling), waarna RvIG die met DAFT (Data Analysis & Fingerprint Tool) zal vergelijken met diezelfde persoonslijsten uit BRP-V. DAFT kan de verwachte verschillen (die het gevolg zijn van de verwijdering van de nationaliteiten) negeren en zien of er daarnaast nog verschillen zijn tussen de PL’en uit de gemeente en die uit BRP-V. Zo kan met behulp van bestaande tools en procedures worden vastgesteld dat beide partijen de zelfde categoriestapels op het oog hebben.

De verwijdering van de bewuste stapels gebeurt alleen nadat deze test is geslaagd. Hoewel deze verwijdering ambtshalve gebeurt, worden de getroffen burgers niet geïnformeerd via een voornemen of een besluit.

Aan alle afnemers die geautoriseerd zijn voor spontane verstrekking van gegevens uit cat. 04/54 wordt van te voren gevraagd of zij Ag31-berichten wensen te ontvangen die het gevolg zijn van het verwijderen van vreemde nationaliteiten. BRP-V kan configureren of een afnemer Ag31-berichten moet krijgen of niet.

Voor afnemers die géén Ag31-berichten willen ontvangen, wordt een alternatieve werkwijze uitgewerkt in een plan van aanpak dat, samen met een draaiboek voor de uiteindelijke conversie/bulkverwijdering, door RvIG zal worden opgesteld.

Tijdens een nader te bepalen weekend worden de conversies bij alle gemeenten gedraaid, buiten kantoortijden.

4 Gevolgen

4.1 Documentatie

Deze wijziging in LO BRP heeft ook gevolgen voor de HUP en de WIR, maar niet voor de andere logisch ontwerpen (LO BES, LO BSN, LO BRPk en LO PGK). De versoepelde voorwaarden gelden voortaan ook voor het verwijderen van vreemde nationaliteiten op individuele persoonslijsten, bijvoorbeeld wanneer bij de opname van de Nederlandse nationaliteit blijkt dat iemand die al vanaf geboorte had.

4.2 Gemeenten

Gemeenten moeten hun leveranciers vragen om de conversie uit te voeren conform de voorschriften in het LO. Van elke PL waarvan een nationaliteit verwijderd is, moet een Lg01-bericht worden verzonden naar BRP-V. Daarnaast moeten gemeenten er alert op zijn dat in meer gevallen vreemde nationaliteiten moeten worden verwijderd bij individuele persoonslijsten.

4.3 Afnemers

Afnemers die geautoriseerd zijn voor spontane verstrekking van gegevens uit cat. 04/54 én die dit wensen zullen voor elke PL waarvan één of meer nationaliteiten zijn verwijderd, een Ag31-bericht ontvangen. Zij moeten, ongeacht of zij Ag31-berichten wensen te ontvangen, de gegevens over de verwijderde nationaliteiten ook verwijderen uit hun eigen gegevensmagazijnen.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

RvIG moet eveneens eenmalig de voorgeschreven conversie uitvoeren in de RNI. Van elke PL waarvan een nationaliteit verwijderd is, moet een Lg01-bericht worden verzonden naar BRP-V. Daarnaast moet RvIG de leveranciers ondersteunen door de resultaten van de proefconversie in DAFT te vergelijken met de verwachte resultaten op grond van dezelfde PL’en in BRP-V.

1 Probleemstelling

1.1 Omschrijving

In het verleden (voor invoering van de BRP-V) kon voor een vervolginschrijving gebruik worden gemaakt van diverse identificerende gegevens in het Ii01-bericht om een vervolginschrijving tussen gemeenten te initiëren. De definitie van het bericht kent dan ook de term ‘persoonsidentificerende gegevens’ als inhoud van het bericht. Dit betekent dat bij de verwerking van inkomende Ii01-berichten rekening moet worden gehouden met een heel gevarieerde set aan gegevens die moet worden vergeleken met de PL’en om tot een juist antwoord te komen.

In de huidige praktijk maken de burgerzakenapplicaties van Centric, PinkRoccade en Shift2 voor dit proces gebruik van de BRP-V. De gebruiker zoekt eerst de te verhuizen persoon op voordat de verhuiscyclus wordt opgestart. In de Ii01-berichten worden dan alleen gegevens uit groep 01 van categorie 01 opgenomen: 01.01.10 A-nummer en/of 01.01.20 Burgerservicenummer. De huidige systemen houden nog wel rekening met uitgebreidere berichten, maar dat gebeurt alleen nog omdat het Logisch Ontwerp BRP (LO) die mogelijkheid toestaat en er bij Schouwen en Toetsen ook op wordt getest.

Centric, PinkRoccade en Shift2 stellen voor om in het LO vast te leggen dat de inhoud van een Ii01 alleen het A-nummer of het Burgerservicenummer mag bevatten. Deze wijziging zal geen invloed hebben op de werking van de applicaties in de praktijk, maar maakt de logica die nodig is voor de verwerking van andere identificerende gegevens dan het A-nummer of het Burgerservicenummer overbodig. De drie leveranciers hanteren deze werkwijze ook in Ji01-berichten (vervolginschrijvingen naar de RNI) en stellen voor om de bewuste logica uit hun systemen te verwijderen. Vanaf 1 januari 2027 sluiten zij uit dat er nog andere gegevens kunnen worden gebruikt voor de identificatie van een persoon in Ii01- en Ji01-berichten.

1.2 Herkomst

Deze wijziging komt voort uit verzoek van de drie leveranciers van burgerzakensystemen.

1.3 Raakvlakken

Er zijn vooralsnog geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

In de huidige definitie van Ii01- en Ji01-berichten mag een persoon geïdentificeerd worden aan de hand van de gegevens die zijn opgesomd in paragraaf 5.1.3.2 van het Logisch Ontwerp BRP. Tenminste moeten op dit moment één of meer van de volgende gegevens worden gebruikt:

• 01.01.10 A nummer
• 01.01.20 Burgerservicenummer
• 01.02.40 Geslachtsnaam
• 08.11.60 Postcode

Eventueel kunnen deze gegevens worden aangevuld met andere gegevens op een persoonslijst. In de praktijk gebruiken de burgerzakensystemen van gemeenten alleen de eerste twee, nadat ze via de Ad hoc webservice het A-nummer of het BSN van de persoon hebben opgezocht.

2.2 Oplossing

Het Ii01- en het Ji01-bericht worden verwijderd uit het lijstje in par. 5.1.3.2, zodat de eisen ten aanzien van persoonsidentificatie die in die paragraaf zijn opgesomd, niet langer van toepassing zijn op deze berichten. De definitie van beide berichten in paragraaf 5.2.23 wordt dit eveneens aangepast, zodat alleen nog gebruik mag worden gemaakt van het A-nummer en/of het Burgerservicenummer om een persoon te identificeren.

2.3 Openstaande punten

Er zijn na implementatie van deze LO-wijziging geen openstaande punten.

3 Invoering

De drie leveranciers sluiten uit dat na 1 januari 2027 nog gebruik wordt gemaakt van andere identificerende gegevens dan het A-nummer en het BSN. Naar verwachting kan deze wijziging dan ook in werking treden op die datum, en dus worden opgenomen in LO BRP 2027.Q1.

4 Gevolgen

4.1 Documentatie

Deze wijziging in LO BRP heeft geen gevolgen voor andere logisch ontwerpen (LO BSN, LO BRPk, LO BES en LO PBK) en ook niet voor de HUP en de WIR.

4.2 Gemeenten

Gemeenten hoeven niets te wijzigen in hun processen: de huidige werkwijze is al zo dat er geen andere gegevens worden gebruikt bij het initiëren van een verhuiscyclus. De leveranciers van de burgerzakensystemen moeten wel zeker stellen dat het gebruik van andere gegevens echt niet meer mogelijk is.

4.3 Afnemers

Geen gevolgen.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

RvIG kan na de inwerkingtreding van deze wijziging óók de overbodige logica verwijderen uit de RNI.