Sinds 25 mei 2018 is artikel 20 AVG in alle EU-lidstaten, dus ook in Nederland, juridisch afdwingbaar. Het recht op dataportabiliteit betekent dat een natuurlijke persoon bepaalde persoonsgegevens kan ontvangen in een gestructureerd, gangbaar en machineleesbaar formaat, en die gegevens eventueel rechtstreeks naar een andere organisatie kan laten overdragen. Dat klinkt als een privacyverzoek, maar voor banken, hypotheekverstrekkers, makelaars, taxateurs, verzekeraars en gemeenten is het vooral een vraagstuk van datamodellering, identiteit, toestemming en API-governance. (Autoriteit Persoonsgegevens over dataportabiliteit)

Voor woningmarktorganisaties ligt de uitdaging niet alleen in het beschikbaar stellen van een export. Jullie moeten eerst vaststellen welke records de klant zelf heeft aangeleverd, welke gegevens door het gebruik van een dienst zijn ontstaan en welke informatie door jullie systemen is afgeleid. Deze scheiding bepaalt wat je technisch mag exporteren, hoe je een ontvangende partij informeert en hoe je voorkomt dat interne risicomodellen of classificaties onbedoeld buiten de organisatie terechtkomen.

Meta description: Dataportabiliteit voor de Nederlandse woningmarkt. Leer welke woningdata portable is en hoe je AVG-conforme exports en API's bouwt.

Wat dataportabiliteit onder de AVG precies inhoudt

Dataportabiliteit is het recht om bepaalde persoonsgegevens te ontvangen en zonder belemmering aan een andere verwerkingsverantwoordelijke over te dragen. Artikel 20 AVG koppelt dit recht aan een gestructureerd, gangbaar en machineleesbaar formaat. Als rechtstreekse overdracht technisch mogelijk is, kan de betrokkene daarom vragen. Het recht omvat niet automatisch alle informatie die een organisatie over iemand bezit. De verwerking moet onder meer geautomatiseerd plaatsvinden en gebaseerd zijn op toestemming of een overeenkomst. (Artikel 20 AVG toegelicht)

Voor woningmarktorganisaties begint een correcte export bij datamodellering. Een hypotheekverstrekker kan bijvoorbeeld inkomensgegevens, adresgegevens of andere velden exporteren die de klant zelf in een aanvraag heeft ingevoerd. Een makelaarsplatform kan opgeslagen zoekvoorkeuren of door de woningzoeker verstrekte contactgegevens beschikbaar stellen. Die velden zijn vergelijkbaar met ingevulde formulieren in een digitaal dossier: ze zijn traceerbaar naar de gebruiker.

Een afgeleid profiel vraagt een andere beoordeling. Een woningwaardemodel dat op basis van meerdere bronnen een waarde-indicatie berekent, maakt daarmee niet automatisch de volledige berekening portable. Ook interne risicoscores, classificaties en modeluitkomsten mogen niet zonder meer als gebruikersdata in een export belanden. Leg daarom per veld de herkomst, verwerkingsgrondslag, eigenaar en exportstatus vast.

Hoe verschilt dataportabiliteit van andere AVG-rechten

Het recht op inzage uit artikel 15 AVG geeft iemand toegang tot persoonsgegevens en informatie over de verwerking. Dat hoeft geen technisch importeerbaar bestand te zijn. Dataportabiliteit is gericht op hergebruik bij een andere dienstverlener.

Het recht op gegevenswissing uit artikel 17 AVG gaat over verwijderen onder de daarvoor geldende voorwaarden. Een exportverzoek vraagt om overdracht of beschikbaarstelling. Beoordeel deze rechten daarom afzonderlijk, ook wanneer een klant ze in één bericht combineert.

Architectuurprincipe: behandel inzage, wissing en dataportabiliteit als afzonderlijke workflows met eigen autorisatie, logging en beslisregels.

Een exportservice voor Nederlandse woningmarktpartijen mag dus geen database-back-up aanbieden. Pas artikel 20 AVG toe op veldniveau en documenteer de selectie. Altum AI beschrijft in een analyse van AVG-compliance bij datadiensten hoe gegevensbescherming onderdeel wordt van de inrichting van datadiensten.

De vier voorwaarden van artikel 20 AVG uitgelegd

Voor een verzoek onder dataportabiliteit moeten vier voorwaarden gelijktijdig vervuld zijn. De gegevens moeten door de betrokkene zijn aangeleverd of door het gebruik van de dienst zijn ontstaan. Ook moet de verwerking geautomatiseerd zijn en berusten op toestemming of een overeenkomst, zoals uitgelegd in de Nederlandse uitleg van de Autoriteit Persoonsgegevens.

Wat betekent “door de betrokkene verstrekt”

Deze voorwaarde omvat meer dan een ingevuld tekstveld. Ook gegevens die tijdens het gebruik van een dienst ontstaan, kunnen eronder vallen. Voorbeelden zijn een historiek van handelingen in een klantportaal en een voorkeur die iemand zelf heeft ingesteld. De toelichting op het recht op dataportabiliteit beschrijft deze ruimere uitleg.

Een woningmarktorganisatie moet vervolgens onderscheid maken tussen vastgelegde gebruikersinput en eigen berekeningen. Een interne kredietscores, een fraudepatroon, een risicocategorie of een uitkomst van een prijsmodel is een afgeleid profiel. Zulke informatie is niet rechtstreeks door de betrokkene verstrekt en hoort daarom niet automatisch in een export voor artikel 20 AVG.

Gebruik hiervoor een beslismatrix per datadomein. Registreer de bron, verwerkingsgrondslag, eigenaar en transformatielaag. Leg ook vast of een veld rechtstreeks uit een JSON-record komt, tijdens dienstgebruik is gegenereerd of door een model is afgeleid. Zo kunnen banken, gemeenten, makelaars en verzekeraars dezelfde exportregel consequent toepassen en blijft de selectie controleerbaar bij een verzoek.

Welke woningdata wel en niet portable is

Bij dataportabiliteit moet de organisatie precies definiëren welke woningdata exporteerbaar is en welke niet. Een scheiding tussen user-supplied data en afgeleide profielen is daarbij essentieel. Leg deze classificatie vast in het datamodel, zodat een API niet willekeurig velden uit verschillende lagen samenvoegt.

Een gemeente kan bijvoorbeeld gegevens over een aanvraag voor een woonkostentoeslag verwerken. Ingevulde huishoudgegevens, aangeleverde documenten en door de aanvrager gekozen communicatievoorkeuren kunnen in beginsel portable zijn. Een interne geschiktheidsclassificatie of een berekende aanspraak op basis van gemeentelijke regels is een afgeleide uitkomst. Die hoort niet zonder verdere beoordeling als oorspronkelijke gebruikersdata in hetzelfde exportrecord te staan.

Dezelfde logica geldt voor verzekeraars en makelaars. Objectkenmerken die een klant zelf aanlevert, moeten worden onderscheiden van een interne risicoklasse, woningwaardering of selectie voor een aanbod. Ook een bezichtigingshistorie vraagt controle: de gebeurtenis kan portable zijn, terwijl namen of contactgegevens van andere personen moeten worden afgeschermd.

Modelleer daarom per veld de bron, de betrokkene, de verwerkingsgrondslag, de portable-status en eventuele afhankelijkheid van derden. Noteer ook of het veld rechtstreeks uit een JSON-record komt, tijdens dienstgebruik is ontstaan of door een model is berekend. Een beslismatrix per datadomein maakt uitzonderingen zichtbaar en ondersteunt dezelfde beoordeling bij banken, gemeenten, makelaars en verzekeraars.

De exportlaag selecteert vervolgens alleen records met een passende status. Zo wordt de juridische beoordeling een herhaalbare datamapregel, met controleerbare uitzonderingen, in plaats van een handmatige zoekactie door product- of supportmedewerkers.

Technische vereisten voor een compliant exportpijplijn

Een AVG-conforme export begint met scopecontrole. Verifieer de identiteit van de verzoeker, bepaal de gekozen datadomeinen en controleer per record de portable-status. Leg ook vast welke directe overdracht naar een andere organisatie technisch mogelijk is. De export moet gestructureerd, gangbaar en machineleesbaar zijn, zodat een bank, gemeente, makelaar of verzekeraar de gegevens zonder handmatige herinvoer kan verwerken.

Welke formaten passen bij welke overdracht

Gebruik JSON als primaire vorm bij een directe API-koppeling. Modelleer person, consents, mortgage_application en property_data als afzonderlijke domeinen. Neem per object source, collected_at, legal_basis en portability_status op. Maak portability_status een beheerd enum-veld, geen vrije tekst, zodat validatie alleen toegestane waarden accepteert.

Een schema moet bovendien de herkomst van waarden onderscheiden. Een door de klant ingevuld adresrecord vraagt een andere behandeling dan een interne risicoscore of modeluitkomst. Gebruik daarom versiebeheer voor het JSON-schema en leg vast welke velden verplicht, optioneel of uitgesloten zijn.

Identiteit, toestemming en transport

Koppel ieder verzoek aan sterke identificatie, bijvoorbeeld via iDIN, DigiD-substantieel of OAuth 2.0 met PKCE, afhankelijk van de dienst en betrokken partijen. Bewaar toestemming per datadomein. Toestemming voor hypotheekgegevens geeft dus niet automatisch toegang tot een taxatiedossier of BAG-view.

Versleutel gegevens tijdens transport met TLS 1.3 en opgeslagen bestanden met een passend mechanisme zoals AES-256. Pas sleutelrotatie toe, beperk toegang tot de exportbucket en registreer actor, tijdstip, scope, uitkomst en ontvangende partij. Bewaar de audit-traceability volgens het vastgestelde bewaarbeleid en de verwerkingsdoelen, niet langer dan noodzakelijk.

Praktische regel: een exportlog moet aantonen wat is geleverd, aan wie, op basis van welke bevoegdheid en met welke selectie.

Een kleine export kan synchroon worden verwerkt. Grotere datasets passen beter bij een asynchrone job-queue met statusendpoint en webhook-callback. Bij bestanden boven 100 MB zijn streaming responses en chunked transfers geschikte patronen, zodat het volledige archief niet in werkgeheugen hoeft te staan. Een privacy-by-design-aanpak voor API-architectuur laat zien hoe expliciete scope en autorisatie schaalbare ontsluiting van woningdata ondersteunen.

Praktijkcase dataportabiliteit tussen hypotheekverstrekkers

Klant Jansen wil na vijf jaar zijn hypotheekgegevens overdragen aan een andere aanbieder. Via het klantportaal dient hij het verzoek in. Na identificatie met iDIN kiest hij de relevante datadomeinen en geeft hij toestemming voor overdracht aan de ontvangende bank.

De bronbank verzamelt daarna het dossier. De selectie bevat de hypotheekofferte, jaaropgaven, een BKR-peildatum, het taxatierapport en het woondossier met onderhoudshistorie. Per record controleert de exportservice de herkomst. Het interne kredietrisicoprofiel blijft buiten het exportbestand, omdat het een afgeleide beoordeling is en geen door Jansen verstrekte brondata.

Zo krijgt de ontvangende bank een controleerbare gegevensset, geen ondoorzichtige modeluitkomst.

Hoe de API-keten eruitziet

Een werkbare keten gebruikt drie endpoints:

1. POST /data-export registreert de aanvraag met geverifieerde identiteit, doelorganisatie en gekozen datadomeinen.
2. GET /data-export/{id} toont status, validatiefouten of gereedmelding.
3. POST /data-transfer start overdracht naar de API van de ontvangende partij, als de technische en organisatorische afspraken dit toestaan.

De bronbank levert een versleuteld JSON-archief met manifest. Daarin staan de exportversie, opgenomen domeinen, checksums, bronidentificatie en validatiestatus. De ontvangende bank controleert eerst handtekening, integriteit, identiteit van de verzender en de overeenkomst tussen manifest en inhoud. Daarna toetst zij het JSON Schema en importeert alleen records die binnen haar eigen gegevensmodel passen. Een gestandaardiseerd hypotheekgegevensmodel, bijvoorbeeld volgens ISO 20022 voor financiële gegevensuitwisseling, kan de mapping tussen beide banken verduidelijken, zonder afgeleide risicoscores als brondata te behandelen.

De casus heeft een beoogde doorlooptijd van zeven werkdagen. De AVG hanteert voor behandeling van het verzoek een termijn van één maand. Zeven werkdagen is dus een interne operationele afspraak, geen algemene wettelijke termijn. De uiteindelijke selectie hangt af van grondslag, betrokken gegevens en informatie over derden.

Implementatiechecklist voor woningmarktorganisaties

De implementatie van dataportabiliteit begint met een duidelijk onderscheid tussen user-supplied data en afgeleide profielen. Leg die grens vast in het datamodel, zodat een export niet alleen technisch leesbaar is, maar ook juridisch verklaarbaar blijft. Wijs een Functionaris voor Gegevensbescherming aan of benoem een verantwoordelijke binnen de governance. Registreer elk verzoek en maak de responstermijn zichtbaar voor product, engineering en klantcontact.

Welke controles horen in de organisatie

• Leg de scope vast: beschrijf per datadomein welke gegevens door de betrokkene zijn verstrekt, tijdens gebruik zijn ontstaan of door modellen zijn afgeleid.
• Registreer verzoeken: gebruik een centraal register met identiteit, grondslag, geselecteerde domeinen, status, uitkomst en eventuele weigering.
• Bouw de exportlaag: implementeer een /data-export endpoint met OAuth 2.0-autorisatie, JSON Schema-validatie en expliciete versiecontrole.
• Beveilig opslag en overdracht: versleutel exportarchieven, stel een retention-policy in en gebruik webhook-notificaties voor asynchrone exports.
• Organiseer controle: train klantcontactcenters, publiceer een procedurepagina en audit exportlogs periodiek. Gebruik daarbij de compliance-audit voor dataportabiliteit als controlekader.

Hoe je dit koppelt aan woningdata

Gebruik afzonderlijke objecten voor klantinvoer, hypotheekgegevens, taxatiedossier, woningkenmerken en verduurzamingsinformatie. Een waarde-indicatie of energie-inschatting uit bronnen en modellen krijgt een eigen status en herkomst. Zo blijft zichtbaar welke records portable zijn en welke een afgeleid profiel vormen.

API-first patronen voor woningdata kunnen deze scheiding afdwingen via versioned endpoints, herkomstvelden en aparte JSON-schema's. Dat ondersteunt uitwisseling tussen hypotheeksoftware, verzekeraars en gemeenten. Houd de ontwikkeling in samenhang met de Data Act. Volgens overheidsonderzoek naar dataportabiliteit en Data Act wordt die wet per 12 september 2025 van toepassing in Nederland en houden de AP en ACM toezicht.

Veelgestelde vragen over dataportabiliteit

Wat is het verschil tussen inzage en dataportabiliteit

Inzage geeft iemand toegang tot persoonsgegevens en informatie over de verwerking. Dataportabiliteit gaat over het ontvangen van gegevens in een gestructureerd, machineleesbaar formaat, zodat de betrokkene ze zelf kan hergebruiken of aan een andere verwerkingsverantwoordelijke kan laten doorgeven. Een klant die wil weten welke gegevens een hypotheekverstrekker verwerkt, dient een inzageverzoek in. Wie die gegevens naar een andere aanbieder wil meenemen, gebruikt het recht op dataportabiliteit. Zie ook Artikel 20 AVG bij GDPR Info.

Wat verandert de Data Act voor woningdata en IoT

De Data Act breidt dataportabiliteit uit naar niet-persoonsgebonden data uit connected products. Voor slimme thermostaten, energiemonitoringssystemen en andere IoT-toepassingen in woningen moet een organisatie per product en gegevensstroom vaststellen welke regels gelden, wie toegang mag krijgen en welke API of exportroute beschikbaar is. Gegevens die naar een natuurlijke persoon herleidbaar blijven, vallen onder de AVG-regels. Leg daarom in het datamodel vast of een record gebruikersinvoer, apparaatgegevens of een afgeleid profiel bevat. De Data Act is vanaf 12 september 2025 van toepassing in Nederland; de AP en ACM houden toezicht.

Kan geheimhouding een export blokkeren

Geheimhoudingsplichten, zoals het bankgeheim of regels rond notariële registers, blijven relevant bij een verzoek. Controleer of de export persoonsgegevens van derden, vertrouwelijke informatie of wettelijk beschermde gegevens bevat. Een beperking vraagt om een concrete wettelijke grond of bescherming van de rechten van anderen. Documenteer de beslissing, de betrokken records en de gemaakte afweging. Zo kan een weigering later worden gecontroleerd en blijft duidelijk welke gegevens wel beschikbaar waren.

Wat doet een organisatie met een verzoek van een niet-klant

Een niet-klant kan persoonsgegevens in jullie systemen hebben. Denk aan een huurder die gegevens opvraagt bij een verhuurder of makelaar, terwijl een andere partij de contractuele relatie beheert. Controleer de identiteit, bepaal wie verwerkingsverantwoordelijke is en traceer daarna de grondslag, herkomst en status van de records. Voer het verzoek niet uit zonder passende verificatie. De afwezigheid van een huidige klantrelatie is op zichzelf geen reden voor automatische afwijzing.

Altum AI biedt via API's toegang tot herleidbare woningdata en samengestelde inzichten voor hypotheekacceptatie, taxatie, portefeuille-analyse en verzekeringsprocessen. Bezoek Altum AI voor informatie over woningdata-API's en bespreek hoe portable datadomeinen veilig in jullie architectuur passen.