FOD Financiën haalt UBO-register offline na mogelijk uitlekken persoonsgegevens

De Belgische Federale Overheidsdienst Financiën heeft het UBO-register offline gehaald na een mogelijke kwetsbaarheid. In het register staan gegevens van vennootschappen en andere organisaties, maar het bleek mogelijk er rijksregisternummers van Belgen uit te achterhalen.

Het gaat om het register van Ultimate Beneficial Owners, een databank met iedereen die bij vennootschappen of stichtingen is betrokken. Het register is onderdeel van een antiwitwaswet en maakt het mogelijk om die betrokkenen te achterhalen. De Belg Koen van den Wijngaert, die op Tweakers bekend is als vdwijngaert, ontdekte dat hij via een tool om het register te raadplegen, gevoelige informatie over landgenoten kon vinden.

Via de tool kunnen gebruikers met de voor- en achternaam en geboortedatum iemand opzoeken in het register. Daarbij wordt echter het rijksregisternummer gebruikt als een unieke identifier. Dat is de Belgische tegenhanger van het burgerservicenummer.

De FOD Financiën heeft de tool inmiddels uit voorzorg offline gehaald. De dienst bevestigt dat aan het Nieuwsblad. "Er is een probleem met een van de toepassingen van de FOD, namelijk die voor de aanleg van een UBO-register. De toepassing is intussen niet meer toegankelijk. We lossen het probleem op", zegt een woordvoerder. Het UBO-register bestaat sinds oktober 2018. Volgens van den Wijngaert zit het lek daar waarschijnlijk al sinds die tijd in.

Reacties (72)

[vdwijngaert]

Een samenvatting: https://twitter.com/vdwijngaert/status/1347063269136207873

[kodak]

Heb je overwogen om het eerst in vertrouwen te melden?
Het had ook mis kunnen gaan met deze vraag. Of was toen al bekend dat er meerdere opmerkingen over waren geweest?

[vdwijngaert]

Werd al meerdere malen gemeld, en er blijven reacties toestromen van mensen die het ook al gemeld hadden. Blijkbaar vonden ze het toen niet belangrijk.

Nergens de toepassing bij naam genoemd, uiteraard. Dat heeft het FOD zelf gedaan in een officiëel statement, nadat ze hem offline hebben gehaald.

[kodak]

Dat is helaas geen antwoord op de vraag of je dat overwogen hebt voor je het blijkbaar publiek vroeg zodat iedereen er ook van kon weten.

edit:
Kunnen de tweakers die deze vraag wegmodereren naar ongewenst misschien verduidelijken waar ze dat doen. Het lijkt me een heel normaal om verduidelijking te vragen bij een mogelijk datalek die veel mensen lijkt aan te gaan. Doorvragen is niet perse negatief bedoeld of ongepast. Je ziet ook aan de antwoorden waarom het waardevol is: omdat het verduidelijking geeft over de situatie, die bijvoorbeeld niet in het tweakers nieuws staan of de bron.

[Reactie gewijzigd door kodak op 22 juli 2024 21:25]

[vdwijngaert]

Ik verduidelijk: méér dan overwogen, gedaan zelfs. Destijds ontdekt met @siteoptimo, en toen hadden we ook al de GBA op de hoogte gesteld.

[Thekilldevilhil]

Omdat in de gelinkte tweets (die ouder zijn dan het tweakers bericht en dus niet achteraf zijn toegevoegd) staat:

Pittig detail: dit lek bestaat waarschijnlijk al vanaf het begin van de lancering. Er werden ook meerdere aangiftes gedaan van het lek, maar daar werd blijkbaar nooit gevolg aan gegeven.

Dus het is dus al, meermaals, aangegeven. Je wordt gok ik naar -1 gemod (niet door mij overigens) omdat men vindt dat je de tweets beter had moeten lezen. Maar dat zou eerder een 0 moeten zijn, niet een -1.

[Reactie gewijzigd door Thekilldevilhil op 22 juli 2024 21:25]

[Anoniem: 1322]

Je doet dat ook verkeerd. Bij overheden komt niemand van zijn stoel af. Inactiviteit is het hoogste doel.. Tot 16:00 uiteraard... tenzij ze bang zijn voor de gevolgen. Niemand is daar verantwoordelijk voor iets dus je moet ze verantwoordelijk maken.

Je had bijvoorbeeld de gegevens van Jean-Paul Janssens kunnen tweeten. Of in ieder geval de eerste drie cijfers van zijn identifier... Als je ze dan verwijst naar de publieke tweet, wedden dat je binnen een uur contact hebt...
https://justitie.belgium....rzitter_en_directiecomite

/s

[Smurf9852]

Je doet dat ook verkeerd.

Kom op gast, serieus? De beste stuurlui zitten aan wal to the max

[The Zep Man]

Via de tool kunnen gebruikers met de voor- en achternaam en geboortedatum iemand opzoeken in het register. Daarbij wordt echter het rijksregisternummer gebruikt als een unieke identifier. Dat is de Belgische tegenhanger van het burgerservicenummer.

Er zijn dus potentieel twee problemen:

1.
Het rijksregisternummer wordt getoond.

2.
Het rijksregisternummer mag mogelijk niet voor dit doel gebruikt worden. Bij het Nederlandse BSN is er een witte lijst van zaken waar het wel voor gebruikt mag worden. Voor andere doelen mag het niet gebruikt worden. Ik weet niet hoe dit zit in België, en met specifiek dit doel (gebruiken als unieke identifier, wat misschien wel mag als het niet getoond wordt aan de opvrager).

[Reactie gewijzigd door The Zep Man op 22 juli 2024 21:25]

[Oon]

Lijkt me inderdaad niet de bedoeling, zelfs al is het alleen omdat het totaal overbodig is.

Ik werk in een branche waar veel klanten een BSN willen opslaan (gewoon omdat ze dat kunnen), maar 9/10 keer hebben ze daar geen reden voor nodig en raden wij ze dat af. Vrijwel niemand heeft meer nodig dan voorletters, achternaam en geboortedatum om de juiste persoon op te zoeken. Ik denk dat in onze databases van tientallen miljoenen personen uit verschillende landen misschien 10 records aanwezig zijn (die geen duplicaat zijn) waar dezelfde voornaam en achternaam op dezelfde geboortedatum voorkomt, als je daar dan ook nog eens geboorteplaats of tweede namen bij meetelt zijn het er gewoon geen.

[StefanJanssen]

Ik ben waarschijnlijk een van die mensen. Ik heb mijn tegenhanger ontmoet via m'n werk. Ik kreeg op de eerste dag de vraag van de IT afdeling of ik zeker wist dat ik niet al bij het bedrijf werkte omdat ik volgens de administratie al een laptop en email had gekregen.
Voornaam + Achternaam was hetzelfde, Geboortedatum was hetzelfde en ook de eerste letter van onze tweede naam was hetzelfde.
Het heeft twee dagen geduurd voordat ik daadwerkelijk kon beginnen met werken.

Ik snap dat het niet veel voorkomt maar als het gebeurd is het voor die persoon wel heel vervelend. (ik heb ooit ergens geen account met mijn echte gegevens kunnen aanmaken omdat ik er al 1 had).

[Oon]

Als je username je echte naam is dan snap ik dat wel, zowel voornaam als achternaam komen veel voor.

Maar dat lijkt me wel flink onhandig, zeker in zo'n situatie als je schetst waar letterlijk je inkomen er vanaf kan hangen. Heb je daar verder nooit problemen mee gehad met bijv. je salaris uitbetaald krijgen of andere officiële registraties?

[Arnoud Engelfriet]

Specifiek bij de salarisadministratie mag en moet een bedrijf wél het bsn gebruiken. Het mag alleen geen algemene identifier voor werknemers worden, ook niet als hele hordes mensen Jan de Vries heten en op 1/1/1970 zijn geboren.

[StefanJanssen]

Ja dat is mijn echte naam. Ik ken zelf 4 mensen die hetzelfde heten maar daarvan is er 1 dus ook op dezelfde dag geboren.
Ik ben pas 25 en heb er nog geen echte problemen mee gehad maar ik hou er zeker wel rekening mee dat dit in de toekomst wel zou kunnen gebeuren.

[lawlhalla]

Het zou zeker kunnen gebeuren inderdaad. Persoonlijk is mijn tegenhanger met Geboortedatum, voorletter en deels de achternaam (ze kijken vaak niet naar tussenvoegsel) in de schuldsanering te vinden. En mag ik bij van alles en nog wat bewijzen dat ik dat niet ben.

[The Zep Man]

Als je username je echte naam is dan snap ik dat wel, zowel voornaam als achternaam komen veel voor.

Dat is dan slecht ingericht binnen de organisatie, want het maakt het raden van gebruikersnamen makkelijk.

Gebruik wat voor de organisatie een unieke identifier is (personeelsnummer). Maak het unieke identifier door het te koppelen aan alle unieke en bedrijfsspecifieke karakteristieken van een persoon die gebruikt kunnen worden (volledige naam, geboortedatum, geboorteplaats, datum eerste indiensttreding...).

[Reactie gewijzigd door The Zep Man op 22 juli 2024 21:25]

[MSalters]

Wat je vergeet is dat namen geen stabiele identificaties zijn. Zelfs geboortedatum is dat niet. Dat klinkt vreemd - hoe kan je geboortedatum nu veranderen? Maar dat zie je immigratie over het hoofd.

Een BSN is wél een stabiele indicatie.

[Oon]

Niks in een database is stabiele informatie op de primary key na, dus dat maakt helemaal niet zoveel uit. De persoon die aan een ID hangt blijft meestal hetzelfde, maar al hun gegevens kunnen aangepast worden.

Een BSN is dus wel vergelijkbaar met een database record ID, maar het is niet alsof bij het wijzigen van een (achter)naam het record niet ook aangepast kan worden

[MSalters]

Dat is redelijk hetzelfde als wat ik zeg: de naam kan geen primary key zijn, ook niet in combinatie met de geboortedatum, maar de BSN kan wel een primary key zijn.

[Oon]

Maar dat is het probleem juist wettelijk gezien, BSN mag geen primary key zijn. Zie bijvoorbeeld deze reactie: Arnoud Engelfriet in 'nieuws: FOD Financiën haalt UBO-register offline na mog...

Ben het verder wel met je eens hoor, maar aangezien een BSN niet gebruikt mag worden voor identificatie intern (zeker wanneer BSN überhaupt al niet opgeslagen mag worden) dan kun je best een nette schatting doen met naam, achternaam, geboortedatum en evt. e-mailadres en/of geboorteplaats. Hoe meer je meeneemt hoe stabieler het wordt, mits de dataset waarin je zoekt up to date is.

[MSalters]

Tja, daar staat toch echt dat het wél een primary key mag zijn in de salarisadministratie. Vergeet niet, in een DB mag je een primary key kolom ook gebruiken voor "normale" doelen, en in een goed genormaliseerde dtabase heb je geen geduplicaeerde informatie. Een synthetische primary key in combinatie met een BSN kolom (noodzakelijkerwijs óók uniek en sorteerbaar) is zo'n duplicatie die je wil vermijden.

[mcDavid]

Dit is een punt waarop softwarearchitectuur en privacy strijdig zijn wat betreft best practices. Vanuit een privacy oogpunt is het juist zeer wenselijk een synthetische PK te gebruiken. Dit maakt de kans op uitlekken van het BSN nummer véél kleiner, aangezien deze maar op één plaats in de database gebruikt wordt, in plaats van overal waar een koppeling met een persoon gemaakt moet worden.

[Sakkesa]

Volgens mij zijn de best practises het niet strijdig, ook in databasedesign is het een best practice dat een PK geen betekenis heeft en zeker niet afhankelijk is van een derde partij.
Indien je het rijksregister/BSN als PK gebruikt, dan geeft je deze een waarde die van een andere partij komt.

[Blokker_1999]

Zelfs met de volledige voornaam, achternaam en geboortedatum ga je vroeg of laat op duplicaten uitkomen, hoe kom je er dan bij dat de voorletters op zich voldoende zijn? Om even iets uit de statistiek te nemen: neem 30 willekeurige mensen en je hebt meer dan 90% kans dat 2 dezelfde geboortedatum hebben.

[MSteverink]

Die kans wordt wel veel kleiner als je het geboortejaar ook meeneemt.

[Reactie gewijzigd door MSteverink op 22 juli 2024 21:25]

[MSalters]

Ruw gezegd is de kans een factor 50 kleiner, maar dat betekent dus dat het probleem alsnog in volle hevigheid terugkomt als je populatie sqrt(50)=7 keer zo groot is. Dus met 210 willekeurige mensen heb je ~90% kans op dezelfde geboortedatum. Veel helpt het dus niet.

[XIU]

Dat is natuurlijk dan wel enkel maar op de dag van het jaar die kans, als je de volledige naam erbij neemt zakt die kans natuurlijk wel enorm (iets meer combinaties dan enkel 366).

[K-aroq]

Daarom moet je ook naam+geboortedatum+geboorteplaats gebruiken. Dan is de kans minimaal dat er 2 dezelfde zijn. Uiteraard is de BSN uniek, maar naam+geboortedatum+geboorteplaats is veiliger en in veruit de meeste gevallen goed genoeg.

[TheWickedD]

Dat is wat kort door de bocht, wat dacht je van een naam als Li Li? Ik ken een vrouw met die naam die veel problemen heeft gehad omdat haar dossier was gemixed met dat van een man met dezelfde naam en geboortedatum die hetzelfde proces aan het doorlopen was.

[Oon]

Zoals ik aangaf komt dezelfde combinatie in onze data maar heel weinig voor, dat wil zeker niet zeggen dat het nooit gebeurt. Veel klanten gebruiken voor selectie voornamen + achternaam + geboortedatum intern, en voegen daar e-mailadres aan toe als het vanuit de gebruiker zelf gebeurt. Dat e-mailadressen uniek zijn lost het probleem in dat geval al op, maar in andere gevallen is het handwerk om dan toch door te vragen naar postcode oid.

Er is altijd wel uit te zoeken wie een persoon is zonder BSN, is mijn punt vooral. Een BSN hoef je eigenlijk alleen maar op te slaan als je het wettelijk verplicht bent (zoals een bank bijvoorbeeld volgens mij is) of als je verplicht bent die door te geven aan een andere partij (zoals wanneer je voor personen met de overheid moet communiceren). Maar dat zijn echt uitzonderingen, vrijwel niemand heeft zomaar BSNs van hun klanten nodig.

[Reactie gewijzigd door Oon op 22 juli 2024 21:25]

[Blokker_1999]

War het dus om gaat is dat je bij het registreren van een begunstige die begunstigde ergens moet opzoeken. Dit doe je aan de hand van naam en geboortedatum van die persoon. Evenwel geeft de API die de opzoeking doet meer informatie terug, namelijk het rijksregisternummer. Het gaat dus vermoedelijk niet alleen om gebruik van het RRN in de applicatie, maar net die openbaar bereikbare API die gewoon teveel info geeft. Al vraag ik me wel af hoe je dit probleem goed moet oplossen, want er is altijd een reëele kans dat je twee mensen met dezelfde naam hebt geboren op dezelfde dag. Ergens moet je een onderscheid kunnen maken tussen die mensen.

[D11]

Daarvoor kun je voor dit systeem natuurlijk ook gewoon een (door de database gecreëerde oplopende) primaire sleutel gebruiken (of bijvoorbeeld een pseudo random gegenereerde).

[Dasprive]

Het is een overheidsdienst, die vallen onder de entiteiten die volgens de Rijksregisterwet het RRN mogen gebruiken. Daar is het nummer ook voor bedoeld uiteindelijk: burgers uniek identificeren in hun communicatie met de overheid. Idem aan BSN.
Dat is wel voor intern gebruik uiteraard, het is niet de bedoeling dat mensen RRNs kunnen query-en in een publieke tool.

[Reactie gewijzigd door Dasprive op 22 juli 2024 21:25]

[Ayiko]

Het insz (inschrijvingsnummer sociale zekerheid) is juist bedoeld om een persoon uniek te identificeren in België, toch zeker in communicatie met de overheid en tussen overheidsdiensten onderling.

In principe mag een overheidsinstelling geen gegevens aan een persoon vragen als ze die zelf ook kan opvragen bij een andere instelling. In een ideale situatie vul je dan enkel je insz in en niet meer je naam, voornaam, geboortedatum, volledig adres, burgerlijke staat, pensioendatum, naam van partner, ...
In de praktijk wordt naam/voornaam/adres toch nog altijd gevraagd, want als iemand een fout in dat insz maakt of er iets totaal anders invult, dan krijg je een formulier waar niemand nog kan achterhalen over wie het gaat.

Het insz is géén paswoord of autorisatiemethode, of zou toch nooit zo gebruikt mogen worden. Het dient enkel om te weten over welke persoon het gaat. Bewijzen dat je recht hebt om gegevens over die specifieke persoon te verkrijgen moet op een andere manier.

En helaas is het insz ook wijzigbaar, al is er een historiek. Als iemand van geslacht of geboortedatum verandert, dan krijgt die een nieuw insz.

Het is in ieder geval een beter systeem dan naam+voornaam+beginletter 2e voornaam+geboortedatum. Of zoals in Spanje, we duwen we der nog de volledige namen van beide ouders bij? Ik heb al een persoonsverwisseling meegemaakt bij een tweeling met beide dezelfde naam+voornaam en 2e voornaam die met dezelfde letters begon.

[Ma_rK]

Het UBO register komt voort uit Europe's wetgeving en ook in Nederland moet je je sinds 27 september 2020 registreren als eigenaar van een bedrijf of belanghebbende in een stichting ea. De grondslag ligt in de Wet op het financieel toezicht. Dit moet je voor 10 maart 2021 doen. Alle betaalinstellingen hebben plicht UBO te checken. Eenmanszaken hoeven zich overigens niet te registreren, net als bv beursgenoteerde BV's en NV's.

UBO's zijn de mensen die de uiteindelijke eigenaar zijn van of zeggenschap hebben over een organisatie.

In Nederland handelt de KvK de registratie af maar digitaal ondertekenen is al maanden stuk dus je kunt de registratie niet afronden. Daarnaast is het systeem een met 15 stappen per legal entity een drama.

UBO-gegevens zijn overigens openbaar. Iedereen mag deze gegevens inzien. Het gaat om de volgende gegevens:

• voor- en achternaam
• geboortemaand en geboortejaar
• nationaliteit
• woonland
• het belang dat een UBO in een organisatie heeft

Wil je de UBO-gegevens van een organisatie inzien, dan kun je bij de KvK een toegangscode aanvragen. Het KVK uittreksel UBO-register is ook te bestellen via de KVK Dataservice.

De reden dat de UBO een vlaggetje isMinor heeft is omdat een UBO minderjarig kan zijn of onder politiebescherming, curatele of bewindvoering kan staan. Op dat moment kunnen de persoonsgegevens afgeschermd worden.

[Reactie gewijzigd door Ma_rK op 22 juli 2024 21:25]

[Maurits van Baerle]

Ik vind veel landen hier nog rijkelijk laat mee eerlijk gezegd. Hier in het Verenigd Koninkrijk is eigendom van een bedrijf al zolang als ik hier een bedrijf heb (sinds 2013) een openbaar onderdeel van de KvK registratie. Hier, een willekeurig Brits bedrijf (AAA Ltd., een BV dus) waarbij je onder 'People' en dan ' Persons with significant control' kunt zien dat één persoon meer dan 75% van de aandelen heeft. Ze doen het in delen van 25% omdat dat dat van belang is. Wie heeft er een meerderheidsbelang, wie heeft er een minderheidsbelang? Zo kun je je niet zo makkelijk verschuilen achter meerdere lagen van schimmige BV's.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 21:25]

[themrme]

Digitaal indienen bij KVK van wijzigingen handelsregister en opgaves UBO is vrijwel altijd beschikbaar.

[Anoniem: 150119]

Dat het gebruik van het RRN als unieke ID voor een dataveld door een code review of (hopelijk) verplichte security audit is geraakt, is al even erg als het lek zelf. Bedankt @vdwijngaert ! Kudos !

[Blokker_1999]

privacy != security. Vanuit security oogpunt is dit geen probleem. De applicatie wordt er niet onveilig van. En je moet mensen nu eenmaal op een unieke manier registreren. In België hebb je dus het rijksregister waarin iedereen die in België woont genoteerd staatr met een 11 cijferig uniek nummer. Het enige nummer dat je in België op een unieke manier identificeert. Simpelweg naam en geboortedatum zijn niet uniek genoeg.

De enige oplossing die ik hiervoor zie is dat men in de toekomst ofwel mensen moet vragen om hun RRN en dat nummer dan mee moet ingeven (maar dat zet je open voor brute-force aanvallen) of bijv. aan de hand van het nummer van de identiteitskaart daar dat een niet statisch nummer is.

[Anoniem: 150119]

Het is een unieke ID van een dataveld ... daar heb je helemaal geen RRN voor nodig. Dat die RRN word gebruikt in het dataveld kan ik inkomen, maar niet als unique ID eigenlijk. Is voor niks nodig als de RRN géén invoer is om een search te doen!

[Blokker_1999]

Maar wanneer naam en geboortedatum niet uniek zijn moet je nog altijd de juiste keuze kunnen maken. Ik neem dan ook aan dat het RRN ook zichtbaar was zodat je bij die persoon kon gaan vragen wat zijn/haar RRN is om de juiste persoon aan te duiden.

[Anoniem: 150119]

Een random Unique ID/ UUID is dan evenwel voldoende. De toepassing heeft geen lookup functie op basis van het RRN (noch nodig), de sleutel van het UBO register is de organisatie, niet het individu. Het is dus incorrect gebruik van het unieke karakter van het RRN.

[stijn014]

Ik kan je een hele waslijst van bedrijven/overheidsdiensten geven die een RRnummer als klantnummer gebruiken.

[MSalters]

Nu lijkt dat laatste (overheidsdiensten) me terecht. Het lijkt me contraproductief als elke overheidsorganisatie zelf een eigen incompatible RRnummer-alternatief gaat implementeren, om het nog maar niet over de kosten te hebben.

[vdwijngaert]

Sad but true.

[Karsten88]

Bedoel je niet is geraakt?

[bilgy_no1]

Zo'n UBO-register is uitermate handig voor de financiële sector. Voor investeringen in bedrijven moeten partijen allemaal zo'n UBO-formulier invullen, wat een hoop gedoe is en lastig te controleren (vooral bij ingewikkelde concernrelaties).

Maar dat gemak is soms strijdig met de privacy, zeker als de informatie wordt gekoppeld aan andere gegevens die in principe los staan van het doel waarvoor zo'n UBO-register is opgesteld.

Ik ben wel benieuwd hoe dat Rijksregisternummer hier wordt getoond/zichtbaar is. Misschien zoiets doms als dat het in de url staat?

[R4gnax]

Ik ben wel benieuwd hoe dat Rijksregisternummer hier wordt getoond/zichtbaar is. Misschien zoiets doms als dat het in de url staat?

Het plaatje wat hier onderaan het artikel staat lijkt afkomstig uit de Chrome developer tools.

Ziet er naar uit dat die informatie wel eens iterug kan komen als onderdeel v/e XmlHttpRequest, bijv. als dit aan een autocomplete functie voor zoeken op naam gekoppeld zit. Als dat zo is, dan is er ergens wss. gewoon een JSON endpoint wat die data al netjes gestructureerd uitspuugt.

Super makkelijk misbruik van te maken middels een scraper, natuurlijk.

[Reactie gewijzigd door R4gnax op 22 juli 2024 21:25]

[vdwijngaert]

Nee, gewoon ook mooi zichtbaar voor de eindgebruiker.

[Techprice]

En waarom is er een veld "isMinor" aanwezig bij zo'n UBO-register?
Ik bedoel, vermoedelijk geeft het aan wanneer iemand minderjarig is, maar is dat eigenlijk wel relevante informatie/data die hoogstnodig is? En mocht dat niet zo zijn, druist dat dan niet in tegen het principe van data minimalisatie?

Hoogstwaarschijnlijk komt aan dit alles nog wel een staartje, je ziet nu maar hoe voorzichtig je moet omspringen met persoonlijke gegevens. Zeker bij de overheid zou je dat mogen verwachten...

[Magic]

die waarde of iemand minderjarig is kan beter uit de birthdate bepaald worden. Mijn vermoeden is dat het betekend of iemand een meerderheids of minderheidsbelang heeft

[stijn014]

Je kan ook meerderjarig verklaard worden voor je 18de verjaardag.
Edit: Het omgekeerde kan ook. Je kan ook verlengd minderjarig worden.

[Reactie gewijzigd door stijn014 op 22 juli 2024 21:25]

[Blokker_1999]

Daar heb ik nog nooit van gehoord, wel over verlengd minderjarig.

[MSteverink]

In Nederland word je meerderjarig wanneer je trouwt voor je 18e verjaardag.
Of als je voor je 18e moeder wordt, en een verzoek tot meerderjarigverklaring door de rechter wordt toegewezen. Vreemd genoeg geldt dit niet voor een minderjarige vader die zijn kind erkent.

Het levert ook geen stemrecht op, dat is gekoppeld aan leeftijd en niet aan meerderjarigheid.

[Magic]

Ah, dat is een goed punt, daar had ik niet bij stilgestaan

[MSalters]

Ik vermoed dat je denkt aan "handlichting". Dat is een procedure waarmee je als 16-jarige zelf een B.V. kunt oprichten. Dan ben je nog steeds niet meerderjarig. Handlichting is een vrij beperkte procedure.

[stijn014]

Ontvoogding is het in België. Je kan inderdaad bepaalde dingen doen en andere niet (personen en familierecht is een vak van lang geleden )

[vdwijngaert]

Helaas moet ik je teleurstellen.

[Techprice]

Daar heb je een punt
Anderzijds, als het toch zou duiden op "minderjarig", is het zelfs nog een veel groter probleem. Dat zou betekenen dat in die database ook data van minderjarigen was opgeslagen. Als die op dezelfde roekeloze manier werd bewaard als van "niet-minors" dan heeft de FODF wel echt een groot probleem.

Waarom daarnaast iemand ook maar dacht dat een een goed idee was om überhaupt de geboortedatum te koppelen aan het RRN is me ook een raadsel, ongeacht het lek of niet. Zeker als bij dit alles al dan niet minderjarigen waren betrokken.

[densoN]

Gemakzucht. RRN is een uitstekende UID. Het verandert namelijk nooit en is altijd aan één uniek persoon gekoppeld.

[Reactie gewijzigd door densoN op 22 juli 2024 21:25]

[Gunirus]

Depends. Strikt genomen is het geen RRN, maar een buitenlander die bvb in België werkt krijgt eerst een bisnummer als INSZ nummer in plaats van een RRN. Dit is het identificatienummer voor die persoon dan. Als die persoon later naar België verhuist krijgt hij een nieuw nummer en vervalt het bisnummer.

[fiammybe]

Toen hadden ze nog nooit gehoord van geslachtsveranderingen :-)

In het RRN zit namelijk ook het geslacht van de persoon gecodeerd in de eerste 3 cijfers na de omgekeerde geboortedatum. Dat is even voor een vrouw en oneven voor een man.
Bij geslachtsverandering wordt het RRN nu geannuleerd, en wordt er een nieuw gecreëerd.

[sayf4u]

En waarom is er een veld "isMinor" aanwezig bij zo'n UBO-register?

Als de UBO minderjaarig is met belang in een onderneming. Er gelden dan andere regels voor het regelen van juridische zaken. Zo moet de minderjarige UBO steeds toestemming vragen aan de ouders voor het regelen van deze zaken. Dit is relevante informatie voor de opvragende partij. Bij wet in nederland moeten witwas-gevoelige ondernemingen weten met wie ze zaken doen. Weten dat de UBO minderjarig is en dat het afhankelijk is van zijn/haar ouders voor het doen van zaken is dan belangrijk.

[Techprice]

Ok, dat je moet weten met wie je zaken doet is inderdaad van belang om witwas-praktijken te ontmoedigen. Maar waarom is het feit of iemand minderjarig is daar belangrijk bij? Zolang je de naam weet is dat op zich toch al voldoende, uiteindelijk is dat UBO-register ook niet echt bedoeld om door derden intensief gebruikt te worden, maar eerder door de overheid zelf.

Het UBO-register is trouwens enkel voor vennootschappen, dus

Weten dat de UBO minderjarig is en dat het afhankelijk is van zijn/haar ouders voor het doen van zaken is dan belangrijk.

dat argument is niet geldig, aangezien er bij een vennootschap kapitaal (of inbreng) wordt ingebracht in de vennootschap. Aangezien (bijna) alle courante vennootschappen met beperkte aansprakelijkheid werken, maakt het op zich dus net of het al dan niet om een minderjarige gaat ten opzichte van die derde. Die kan enkel aanspraak maken op het kapitaal/inbreng en niet op de persoon zelf (of ouders ervan).

Ja, het feit dat iemand minderjarig is heeft wel enkele implicaties ten opzichte van hoe iemand kan handelen, maar uiteindelijk lijkt deze data toch ruimschoots overbodig te zijn, ten opzichte van de baten.

[Reactie gewijzigd door Techprice op 22 juli 2024 21:25]

[Blokker_1999]

Omdat iemand die minderjarig is zelf geen beslissingrecht heeft en geen financiële onafhankelijkheid. Met een minderjarige mag je dan ook niet zomaar over die dingen communiceren. Dat moet via een voogd gaan die dus ook bekend moet zijn.

En het UBO is niet enkel voor venootschappen. Ook vzws, stichtingen en trusts dienen hun begunstigden in UBO aan te melden, en dan zit je ineens met organisaties waarbij begunstigden wel degelijk een persoonlijke verantwoordelijkheid hebben. En bij minderjarigen wordt die verantwoordelijkheid weer doorgeschoven.

[n41r0j]

Het overkoepelende probleem is het steeds groter wordende mandaat om alsmaar meer data te verzamelen in de strijd tegen witwassen en terrorismefinanciering.

Zie deze uiteenzetting hierover: https://twitter.com/finhs.../1276412510820880384?s=21

[Sjapmeister]

Sterker: het overkoepelde probleem is het steeds groter wordende mandaat om meer data te verzamelen in het algemeen. Zowel door publieke als private organisaties.

Bij publieke organisaties kun je niet weigeren want "het is de wet" en bij private organisaties kun je niet weigeren want dan raak je compleet afgesneden van gangbare breed maatschappelijke geaccepteerde en geïmplementeerde oplossingen.

Bijvoorbeeld: ik ben niet verplicht een Whatsapp account te hebben, maar alle communicatie tussen familie, vrienden, ouders op de school van de kinderen, etc loopt via Whatsapp.
Nog een voorbeeld: ik hoef geen Google of Facebook account maar half internet werkt een login met één van deze twee grootmachten.
Nog een voorbeeld: ik hoef geen Google of Apple account, maar alle voor niet IT-ers bereikbare en gewoon basaal werkende smartphones werken met een account van één van die twee.

En zo kan ik nog wel even doorgaan.

[kodak]

Wat heeft dat met dit publiek maken van deze gevens te maken? Je kan niet zomaar stellen dat het probleem van waarschijnlijk te publiek maken komt door verzamelen of door verzamelen voor een bepaald doel. Tenminste niet als het publiek maken niet onderdeel van die doelen van verzamelen is. Je kan ook niet zomaar zeggen dat als jij lekkage in de afvoer van je wasbak hebt dat komt door gebruik van water. Anders kan je net zo goed ook stellen dat het komt omdat de wereld bestaat. Een verband is niet altijd een oorzaak.

[Lord_indigo]

Vingerafdrukken zijn verplicht op de volgende identiteitskaarten.
Dit artikel benadrukt nog eens waarom niemand dat ziet zitten.
Niet omdat ik iets te verbergen heb, maar omdat ze er niet in slagen deze data te beschermen zodat enkel de mensen die toegang nodig hebben deze kunnen raadplegen....

als ze het met deze data al niet kunnen, ....

[fiammybe]

Binnen de overheid is het RRN een unieke identificatiesleutel voor personen, net zoals het KBO er één is voor bedrijven. Doordat het om persoonsinformatie gaat is het natuurlijk beter beschermd dan het KBO nummer en moet er normaal gezien toestemming gevraagd worden om het te mogen gebruiken. Dat is geen triviale procedure, daar moet je aantonen waarom je de informatie nodig hebt en wie die gegevens zal zien onder welke omstandigheden.
Natuurlijk is dat geen beveiliging tegen een ontwikkelaar die nietsvermoedend zijn sleutel meegeeft in een API call.

Vingerafdruk gegevens zijn iets complexer, ik denk niet dat die alomtegenwoordig zullen worden als identificatie van een persoon, gewoon doordat het een veel langere karakter-reeks is.

Persoonlijk ben ik ook geen grote fan van het plaatsen van meer informatie op de ID kaart. Geen idee welke business case ze voor vingerafdrukken hanteren.

[joyrider3774]

heeft dit ergens invloed voor belgische notarissen ? Moeten zij dat systeem niet gebruiken of heb ik dat verkeerd voor ?