HDN Standaard 24.0

HDN-68

vervallen

Generiek

Header verwijderen

HDN-94

Voorstel akkoord

Generiek

Opschonen taxonomie

HDN-4

Voorstel akkoord

Generiek

Vervangen CodeObject

HDN-98

Voorstel akkoord

Generiek

Geslacht

HDN-43

vervallen

Generiek

Aanscherpen patroon E-mail

HDN-37

Voorstel akkoord

Generiek

Verwijderen vervallen landen

HDN-81

Voorstel akkoord

Generiek

Corrigeren BeroepsType

STAN-40

Voorstel akkoord

Generiek

Organisatie "MD Me Home Loans" verwijderen

HDN-35

Voorstel akkoord

Generiek

Ketenafspraak gebruik AanvraagVersie in vervolgberichten

STAN-134

Voorstel akkoord

Generiek

Verduidelijking ketenafspraak Hypotheekbedrag

STAN-313

Voorstel akkoord

OfferteAanvraag

Verplicht ondersteunen gewijzigde aanvraag (hypotheekdomein)

HDN-40

Voorstel akkoord

OfferteAanvraag

BeheerVerzoek

Levensloop niet meer van toepassing

STAN-345

Voorstel akkoord

OfferteAanvraag

SV-Loon wordt verwijderd

HDN-72

Voorstel akkoord

OfferteAanvraag

Certificeringspunten ondervangen in regels

HDN-89

Voorstel akkoord

OfferteAanvraag

Toevoeging toekomstige EnergieKlasse

STAN-185

Voorstel akkoord

OfferteAanvraag

Opschonen energieklasse naar aanleiding Trhk 2024

STAN-288

Voorstel akkoord

OfferteAanvraag

BeheerVerzoek

Actualiseren BKR-waardelijst

HDN-105

Voorstel akkoord

OfferteAanvraag

Verwijderen Duurhuur

HDN-86

Voorstel akkoord

OfferteAanvraag

Afdwingen DuurInMnd of EindDt

STAN-262

Voorstel akkoord

OfferteAanvraag

Ketenafspraak in regel: Verkoopkosten

STAN-407

Voorstel akkoord

OfferteAanvraag

Generieke regel op VerplichtingPerJaar t.b.v. studielening

STAN-660

nvt

OfferteAanvraag

Dataleverancier uitbreiding

STAN-343/283

Voorstel akkoord

OfferteAanvraag

Verwijderen niet-gebruikte velden

HDN-101

Voorstel akkoord

OfferteAanvraag / InformatieBericht / BeheerVerzoek

Uitbreiding Overbrugging

HDN-70

Voorstel akkoord

OfferteAanvraag / LevenAanvraag

Uniformeren Starterslening/Subsidieregeling

HDN-74

Voorstel akkoord

LevenAanvraag

Certificeringspunten ondervangen in regels

STAN-173

Voorstel akkoord

LevenAanvraag

Vervallen EindWaardeDekking en WaarvanGegarandeerd

STAN-26

Voorstel akkoord

LevenAanvraag

Uitfaseren niet-gebruikte velden LevenAanvraag

HDN-73

Voorstel akkoord

KredietAanvraag

Certificeringspunten ondervangen in regels

HDN-90

Voorstel akkoord

WaarborgBericht

Arrangement verplicht bij bankgarantie

HDN-91

Voorstel akkoord

WaarborgBericht

Bankgarantie geldigheid onderscheid bestaande bouw/nieuwbouw

HDN-41

Voorstel akkoord

WaarborgBericht

Verwijderen bedrijfsnaam in PartijNAWData

HDN-42

Voorstel akkoord

WaarborgBericht

Bedrijfsnaam benodigd als Verkoper

HDN-92

Voorstel akkoord

WaarborgBericht

Verwijderen overbodige velden voor eigen middelen

STAN-151

Voorstel akkoord

WaarborgBericht

Toevoegen InitieelPakket

HDN-60

Voorstel akkoord

StatusMelding

Extra statusmelding wanneer stukken naar de notaris zijn gestuurd

HDN-75

Voorstel akkoord

StatusMelding

Nieuw SX-bericht Tweede beoordeling afgekeurd

STAN-541

Voorstel akkoord

BeheerVerzoek

Uitbreiden velden

STAN-49

Voorstel akkoord

InformatieAanvraag/ InformatieBericht

Dataminimalisatie

STAN-534

Voorstel akkoord

InformatieBericht

Toevoegen Energieklasse

STAN-648

Voorstel akkoord

InformatieAanvraag

Uitbreiding met KvKNr

Scopebepaling

Releasespecificaties HDN 24 worden in concept gepubliceerd

Tot +/- 6 maanden voor go-live

Jul 4, 2023

Dec 14, 2023

Consultatieperiode

Definitieve scope

5 weken

Dec 14, 2023

Jan 19, 2024

Consultatieperiode

Definitieve releasenotes

2 weken

Jan 19, 2024

Feb 1, 2024

Opbouwen schema’s

Basisberichtschema’s worden door HDN opgebouwd en gepubliceerd

2 weken

Jan 19, 2024

Feb 1, 2024

Opbouwen schema’s

Organisatieschema’s zijn ter review aangeboden

6 weken

Feb 1, 2024

Mar 14, 2024

Review door HDN

Organisatieschema’s worden gepubliceerd en naar de testomgeving gedistribueerd

3 weken

Mar 14, 2024

Apr 11, 2024

Test/freezeperiode

Schema’s gedistribueerd naar productie

6 weken

Apr 11, 2024

May 25, 2024

Go-live

Afronding release

-

00:30 May 25, 2024

HDN-68

vervallen

Generiek

Header verwijderen

Aanleiding: Om de mogelijkheden van het HDN Platform optimaal te benutten maken we een onderscheid in:

• Stuurinformatie: wat er met informatie die we uitwisselen moet gebeuren (van wie, naar wie, welke controles, te gebruiken schema’s etc.)

• Meta-informatie: waar het over gaat / extra informatie van de verzender / extra informatie voor de ontvanger

• Inhoud: het HDN-bericht zelf, de data/informatie van die specifieke case (persoon, object, lening, etc.)

Waar we met de introductie van het vernieuwde HDN Platform mee begonnen zijn is stuurinformatie en meta-informatie opnemen in de het JSON-deel van de API.

Waarmee we verder willen gaan is:

• De Header-entiteit uit de XML volledig opnemen in de API. Hiervoor is API V2 uitgerold waarbij een implementatieperiode is afgegeven van mei 2023 tot mei 2024

Doel: Door het verwijderen van de Header, verwijderen wij informatie die reeds in de JSON is opgenomen uit de XML.

Aanpassing: Header komt in alle berichten te vervallen.

HDN-94

Generiek

Opschonen taxonomie

Aanleiding: Als HDN Standaard bewaken wij een marktstandaard voor het uitwisselen van gegevens binnen het financiële woondomein. Dit doen wij door continu in verbinding te staan met onze leden en gebruikers en marktontwikkelingen te volgen. Volgend jaar vieren wij ons 30-jarig bestaan. Gedurende al die jaren is de omvang van de datacatalogus gegroeid tot wat het vandaag de dag is. De datacatalogus is een essentieel onderdeel geworden van de HDN Standaard en daarom hebben we besloten om deze naar een nog hoger niveau te tillen.

Dit doen wij onder andere door de datacatalogus om te zetten naar een taxonomiemodel. Hiervoor hebben we nieuwe gespecialiseerde tooling aangeschaft. Dit is tevens het moment om de opgebouwde datacatalogus tegen onze samen gemaakte afspraken binnen de HDN Standaard en de marktstandaarden aan te houden.

Aanpassing: Na een eerdere marktconsultatie waarin wij al onze leden en gebruikers hebben meegenomen in de impact van het opschonen van de taxonomie en afstemming met verschillende werkgroepen, worden de attributen in onderstaand bestand gewijzigd. Deze zijn per berichttype in kaart gebracht met eerst het oude attribuut genoemd met het pad waarin het attribuut valt in de berichtstructuur en de nieuwe attributen.

Datum-en tijdentiteiten wijzigen naar velden. Er komen twee type velden beschikbaar. Eén DatumType (Dt) en één DatumTijdType (Dtt).

Aanvullend: Oude attributen krijgen een einddatum in de taxonomie waarmee wij deze wel herkennen, maar niet meer actief kunnen gebruiken. Om de volgordelijkheid van de berichten en bestaande regels (condities) te waarborgen, vindt in de schemabeheertool een migratie plaats. Hierbij worden de nieuwe attributen op dezelfde plek geplaatst en blijven regels op vervangen attributen behouden, of blijven een afhankelijkheid hebben van een vervangen attribuut.

HDN-98

vervallen

Generiek

Aanscherpen patroon E-mail

Aanleiding: Het bestaande pattern email was niet toereikend en liet onterecht incorrecte emailadressen door.

Doel: Het voorstel raakt de volgende HDN Standaard-principes:

• Principe van accuraatheid: Door deze wijziging wordt de kans dat er fouten in het e-mailadres worden gemaakt sterk verminderd.

Aanpassing:

Het pattern wordt aangepast naar: ^(?!^\.)(?!.*\.\.)[a-zA-Z0-9._%+-]+(?<!\.)@(?!-)[a-zA-Z0-9.-]+(?<!-)\.[a-zA-Z]{2,63}

HDN-37

Generiek

Verwijderen vervallen landen

Aanleiding: De landenlijst zoals wij deze kennen in de HDN Standaard is niet meer actueel. Deze lijst is gekoppeld aan de ISO normering 3166.

De landenlijst blijkt een combinatie van actuele landen als vervallen landen.

Doel: Het voorstel raakt de volgende HDN Standaard-principes:

• Principe van accuraatheid: de HDN Standaard is gebaat bij nauwkeurigheid tot op detailniveau. Elke veldnaam en de bijbehorende datatypes en omschrijvingen moeten zeer nauwkeurig worden ingevuld.

• Principe van interoperabiliteit: de HDN Standaard moet kunnen aansluiten op andere systemen. Mapping is onontkombaar maar indien mogelijk wordt aansluiting gezocht op (inter)nationale standaarden.

• Principe van validiteit: de data binnen de HDN Standaard moet zoveel mogelijk valide zijn. Wanneer informatie niet gevalideerd is of kan worden, moet duidelijk zijn waar de informatie vandaan komt (herleidbaarheid).

Aanpassing: De landen die vermeld staan op de ISO landenlijst 3166-3 zullen verwijderd worden uit de waardelijst van het FieldType LandType. De twee landen die vermeld staan die op geen van de lijsten voorkomen worden ook verwijderd.

Open

HDN-81

OFFERTEAANVRAAG (AX)/ BEHEERVERZOEK (MX) KREDIETAANVRAAG (KX)/ LEVENAANVRAAG (LX)

Corrigeren BeroepsType

Aanleiding: De beroepenlijst in de waardenlijst ‘BeroepType’ bevat een aantal fouten ten opzichte van de officiële beroepenlijst van het CBS (zie Beroepenclassificatie (ISCO en SBC)

Doel: Het voorstel raakt de volgende HDN Standaard-principes:

• Principe van accuraatheid: de HDN Standaard is gebaat bij nauwkeurigheid tot op detailniveau. Elke veldnaam en de bijbehorende datatypes en omschrijvingen moeten zeer nauwkeurig worden ingevuld.

Aanpassing: we corrigeren de volgende beroepsType (In het groen de verschillen)

• 0211 Bibliothecarissen en conservatoren

• 0521 Managers zakelijke en administratieve dienstverlening

• 0633 Beveiligingspersoneel

• 0711 Biologen en natuurwetenschappers

STAN-40

Generiek

Organisatie "MD Me Home Loans" verwijderen

Aanleiding: MeHomeLoans is geen actief label, nooit live gegaan en zal niet in productie worden genomen.

HDN-35

Generiek

Ketenafspraak gebruik aanvraagversie in vervolgberichten

Aanleiding: Op dit moment is er geen ketenafspraak over het gebruik van het veld requestVersion, behalve:
Een gelijk aanvraagvolgnummer met een hoger versienummer wordt gezien als een mutatie op een eerdere offerte. Hiermee zal de aanbieder alleen dienen te reageren op het hoogste versienummer.
Het versienummer mag nooit 0 zijn.

Dit leverde problemen op binnen de keten en verduidelijking van het gebruik van de aanvraagversie/requestversion was wenselijk.

Doel: Het voorstel raakt de volgende HDN Standaard-principes:

• Principe van doelbinding: binnen de HDN Standaard wordt alleen data verzonden die partijen wensen te ontvangen voor het uitvoeren van hun processen. De partijen bepalen zelf voor welk(e) doeleinde(n) zij data verwerken.

  • Dit speelt met name bij documenten: omdat er nog geen afspraken waren wat er moet gebeuren met een DA als een nieuwe requestVersion binnen komt, kan het voorkomen dat er documenten worden verstuurd die na het wijzigen van de aanvraag niet meer nodig zijn.

• Principe van procesoptimalisatie: de HDN Standaard staat voor een efficiënt, gestandaardiseerd proces waarin snel duidelijkheid ontstaat voor alle betrokken partijen.

  • Omdat het nu niet duidelijk is hoe omgegaan moet worden met het aanpassen van de requestVersion, ontstaat er uitval in het proces en ontstaat er inefficiëntie.

Aanpassing: Nieuwe ketenafspraak.

KET-003 Het gebruik van requestversion in HDN-berichtenarchived

STAN-134

Generiek

Verduidelijken ketenafspraak Hypotheekbedrag

Aanleiding: Binnen de keten is het niet duidelijk wat wel en niet onder een hypotheekbedrag verstaan wordt. Er wordt per domein verschillend gebruik gemaakt van het veld Hypotheekbedrag.

Doel: Met het voorstel raakt de volgende HDN Standaard-principes:

• Principe van accuraatheid: de HDN Standaard is gebaat bij nauwkeurigheid tot op detailniveau. Elke veldnaam en de bijbehorende datatypes en omschrijvingen moeten zeer nauwkeurig worden ingevuld.

• Principe van data-integriteit: de data binnen de HDN Standaard moet consistent worden vormgegeven. Begrippen zijn herbruikbaar binnen verschillende domeinen en wijzigingen in naamgeving of betekenis wordt altijd gelogd.

Aanpassing: Vernieuwing ketenafspraak:

KET-001 Verduidelijking vulling HypotheekBedragarchived

HDN-4

OfferteAanvraag (AX)

Offerte (OX)

Vervangen Code Object

Aanleiding: De lijst CodeObject sluit niet aan bij de acceptatiekaders van de aanbieders. Hierdoor kan als adviespakket niet goed de aanvraag worden gecontroleerd alvorens deze wordt opgestuurd naar de geldverstrekker.

Doel: Uniformiteit binnen de keten: De Waarderingskamer biedt een standaard objecttype lijst Fotowijzer Woningen. Deze is samengesteld door NRVT, NVM, VastgoedPro, VBO en de Vereniging van Nederlandse Gemeenten en de Waarderingskamer. Het is wenselijk is om vanuit de Standaard hierbij aan te sluiten zodat ook toekomstige integraties gestandaardiseerd ingeregeld kunnen worden.

Aanpassing: CodeObject komt te vervallen voor alle berichten. Voor de OfferteAanvraag worden, om aan te sluiten bij de Fotowijzer Woningen, twee nieuwe waardelijsten geïntroduceerd:

ObjectSoort (verplicht)

BijzObjectSoort (optioneel)

Aanvullend worden de velden GarageJN en RecreatieveBewoningJN geïntroduceerd om aan te duiden of de woning een garage bevat.

Voor de Offerte is het niet meer nodig om het objecttype terug te geven. Dit komt in zijn geheel te vervallen.

HDN-43

OfferteAanvraag (AX)

Offerte (OX)

DocumentAanvraag (DA)

Geslacht

Aanleiding: Op dit moment moet een persoon een verzoek indienen bij de rechter om het geslacht in het paspoort en de geboorteakte aan te laten passen.
Er zijn geen officiële cijfers bekend, maar naar schatting zijn er nu tussen de 400 en 700 mensen met een X in hun paspoort.

De registratie wordt ook met een “X” aangeduid. In het paspoort is dit twee keer; X/X (Nederlands / internationaal).

De Vereniging Nederlandse Gemeenten is, met een aantal andere partijen, bezig om het proces om X in het paspoort te krijgen zonder tussenkomst van de rechter te laten plaatsvinden. Momenteel is dit nog niet aangenomen. Eenmaal aangenomen is te verwachten dat het aantal personen zal gaan toenemen.

Doel: Het voorstel raakt de volgende HDN Standaard-principes:

• Principe van accuraatheid: Het wordt verhelderd dat geslacht alleen nodig is voor legitimatiegegevens. Daarmee wordt ook direct duidelijk dat hier een legitimatiebewijs als bron dient.

• Principe van doelbinding: dataminimalisatie: Door geslacht niet meer op te vragen en aanspreekvorm niet generiek te maken wordt er geen data verzonden die niet nodig is voor de aanvraag.

Aanpassing: Geslacht komt te vervallen en LegitimatieGeslacht wordt als organisatiespecifiek veld toegevoegd binnen de entiteit Identificatie, met daarin de waardelijst LegitimatieGeslchtType bestaande uit de waarde:

• 01 M

• 02 V

• 03 X

Voor Offerte en DocumentAanvraag is het niet meer nodig om geslacht terug te geven en komt dit in zijn geheel te vervallen.

Ketenafspraak:

Gedurende de overgangsperiode van een jaar, tot de HDN25, mogen organisaties in hun organisatieberichtschema 03 X uitsluiten middels een regel op het veld Legitimatiegeslacht: “Geslacht heeft niet waarde X". Dit zodat elke organisatie de tijd heeft om in te regelen hoe zij met deze waarde willen omgaan.

STAN-313

OfferteAanvraag (AX)

Verplicht ondersteunen gewijzigde aanvraag (hypotheekdomein)

Aanleiding: Tijdens het overleg over Verduidelijking gebruik requestVersion in vervolgberichten is besproken dat veel aanbieders in het hypothekendomein er last van hebben dat niet elk intermediair een nieuwe versie van een aanvraag kan maken wanneer bijvoorbeeld een SX 14 Offerteaanvraag niet te verwerken wordt teruggegeven door de aanbieder. Dit speelt met name bij intermediairs die het HDN-bericht via hun CRM-pakket hebben verstuurd.

Hierdoor komt er een geheel nieuwe aanvraag bij de aanbieder binnen, terwijl het ook met een gewijzigde aanvraag kon volstaan. De aanbieder moet hierdoor deze aanvraag weer opnieuw verwerken en met de hand zaken als de juiste rentes en al verstuurde documenten koppelen. Dit is inefficiënt.

In dit wijzigingsvoorstel komt een nieuwe ketenafspraak die voor de rollen die een OFFERTEAANVRAAG (AX) mogen wijzigen (Rol 1 (softwarepakketten voorkant), Rol 3 (tussenpartijen met aanpassingen) ) de verplichting geeft om dit ook te ondersteunen. Het wordt daarbij dus een ketenafspraak die de tegenovergestelde situatie uit de ketenafspraak Wijziging op lopende aanvragen behandeld: namelijk wanneer je juist wel een gewijzigde aanvraag moet sturen.

Doel: Het voorstel raakt de volgende HDN Standaard-principes

• Principe van procesoptimalisatie: de HDN Standaard staat voor een efficiënt, gestandaardiseerd proces waarin snel duidelijkheid ontstaat voor alle betrokken partijen.

Aanpassing: Nieuwe ketenafspraak:

KET-002: Ondersteuning voor het wijzigen van een aanvraagarchived

HDN-40

OfferteAanvraag (AX)

Levensloop niet meer van toepassing

Aanleiding: Per 1 januari 2012 is Levensloopregeling vervallen. Bestaande levensloopregelingen moesten per 1 november 2021 worden omgezet. Bron: https://www.belastingdienst.nl/wps/wcm/connect/nl/werk-en-inkomen/content/overgangsrecht-levensloopregeling

In de hypotheekberichten AX en MX is het nog mogelijk bij een dienstverband de LevensloopPerJaar op te geven. Dit veld kan komen te vervallen.

Doel: Het voorstel raakt de volgende HDN Standaard-principes

• Principe van dataminimalisatie:  Regelingen die niet meer voor komen hoeven niet meer in berichten te kunnen worden opgegeven.

Aanpassing: LevensloopPerJaar komt te vervallen.

STAN-345

OfferteAanvraag (AX)

Veld SV loon verwijderd

Aanleiding: Dit veld was specifiek voor één aanbieder geïntroduceerd. Aangezien deze aanbieder dit veld inmiddels heeft uitgesloten uit zijn bericht, kan dit veld worden verwijderd.

Doel: Het voorstel raakt de volgende HDN Standaard-principes

• Principe van dataminimalisatie:  Attributen die niet meer (actief) gebruikt worden, verwijderen uit de berichtenstructuur.

Aanpassing: Veld SVLoon is verwijderd uit de entiteit Dienstbetrekking

HDN-72

OfferteAanvraag (AX)

Certificeringspunten ondervangen in Regels