Pagina-vergelijking

HDN-68

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

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.

HDN-81

Corrigeren BeroepsType

Aanleiding: De beroepenlijst in de waardenlijst ‘BeroepType’ bevat een aantal fouten ten opzichte van de officiële beroepenlijst van het CBS (zie https://www.cbs.nl/nl-nl/onze-diensten/methoden/classificaties/onderwijs-en-beroepen/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 hetgroende 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-berichten

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 HypotheekBedrag

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

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 aanvraag

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

Aanleiding: We hebben een analyse gedaan op de certificeringpunten binnen de hypotheekberichten. Hieruit is naar voren gekomen dat een aantal van deze certificeringspunten in de bestaande berichtschema’s met een regel kan worden afgedwongen.

Doel: Het voorstel raakt de volgende HDN Standaard-principes

• Principe van accuraatheid: Door deze controles middels regels af te vangen zal elk aanvraagbericht hierop worden gecontroleerd.

Aanpassing:

• //Offerteaanvraag/HuidigObject/HuidigeFinanciering/Rangorde

  • Rangorde is groter dan 0

  • Melding: De rangorde moet groter dan 0 zijn.

• //Offerteaanvraag/HuidigObject/HuidigeFinanciering/HuidigLeningdeel/DuurInMndHuidigLeningdeel

  • DuurInMndHuidigLeningdeel is verplicht als //HuidigObject/HuidigeFinanciering /HuidigLeningdeel/AflossenJN heeft waarde (N Nee) DuurInMndHuidigLeningdeel is groter dan 0

  • Melding: De duur in maanden moet groter dan 0 zijn.

• //Offerteaanvraag/Object/Bouwjaar

  • BouwJaar is verplicht als //Lening/NHG heeft waarde (J Ja) EN als //Object/Onderpand heeft waarde (01 bestaand, 02 bestaand verbouw)

    Bouwjaar is groter dan 1000

    Melding: Het bouwjaar moet na 1000 zijn.

• //Offerteaanvraag/Lening/Rangorde

  • RangOrde is groter dan of gelijk aan 2 als //Lening/Regeling heeft waarde (09 tweede of hoger in rang hypotheek).

    Rangorde is groter dan 0

  • Melding: Rangorde moet groter dan 0 zijn

• //Offerteaanvraag/Lening/NotarisKosten

  • NotarisKosten is groter dan 0,00

  • Melding: De notariskosten moeten hoger dan 0,00 zijn

• //Offerteaanvraag/Lening/Leningdeel/DuurInMnd

  • DuurInMnd is verplicht als //Lening/Leningdeel /VasteEindDtLeningdeelJN heeft waarde (N Nee)

    Nieuw: DuurInMnd is groter dan 0

  • Melding: De duur in maanden moet groter dan 0 zijn.

HDN-89

OfferteAanvraag (AX)

Toevoegen toekomstige energieklasse

Aanleiding: In verband met een uitgebreider palet aan producten binnen het hypothekendomein, en de ontwikkeling van producten waarbij toekomstige energieklasse in de aanvraag een rol speelt, is gevraagd of het model uitgebreid kan worden met de toekomstige energieklasse van de woning.

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

• Principe van doelbinding:Wanneer een partij wil weten wat een toekomstige nieuwe Energieklasse is om een aanvraag voor een (nieuw) product te kunnen beoordelen, moet deze kunnen worden doorgegeven.

Aanpassing: Het veld ToekomstigeEnergieKlasse met daarin de waardelijst EnergieKlasseType wordt als organisatiespecifiek veld toegevoegd aan de entiteit Object. Hiermee kan een aanbieder, indien wenselijk, dit veld opnemen in zijn berichtschema en heeft de adviseur de mogelijkheid het te bereiken energielabel mee te geven.

STAN-185

OfferteAanvraag (AX)

Opschonen energieklasse naar aanleiding Trhk 2024

Aanleiding: De waardelijst energielabels is gewijzigd ten aanzien van de oorspronkelijke implementatie van de waardelijst. Het idee met deze wijziging is om alleen de actuele waardes op te nemen in de waardelijst.

Aanvullend is bij de analyse gekeken naar de regels die een afhankelijkheid hebben van deze waardelijst en deze is tegen de herziene Trhk gehouden om de relevantie te bepalen.

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

• 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.

• Principe van eenduidigheid: de data binnen de HDN Standaard moet een eenduidige betekenis hebben. We streven naar definities die maar voor één uitleg vatbaar zijn en ook door alle partijen op dezelfde wijze worden geïnterpreteerd.

Aanpassing: De waardelijst EnergieKlasseType wordt geactualiseerd naar de waardelijst zoals deze ook bekend is bij https://wetten.overheid.nl/BWBR0020921/2023-07-25. Wij zullen deze waardelijst overnemen met als toevoeging daarop 14 A++++ (EP Garantie) en 91 Geen energielabel beschikbaar n.a.v. de Trhk.

Concreet houdt dit in dat onderstaande waardelijst wordt gehanteerd:

Image RemovedImage Added

Ook zal de regel op EnergieKlasseAfgifteDt worden aangepast naar: EnergieKlasseAfgifteDt is verplicht als //Object/EnergieKlasse heeft waarde (01 A++, 02 A+, 03 A, 04 B, 05 C, 06 D, 07 E, 08 F, 09 G, 10 A+++, 11 A++++, 12 Energie Neutraal, 13 Nul-op-de-Meter 14 A++++ (EP Garantie))

STAN-288

OfferteAanvraag (AX)

Actualiseren BKR-waardelijst

Aanleiding: De soorten BKR-coderingen zijn niet in alle HDN-schema’s gelijk. Zo mist in de OfferteAanvraag en het Beheerverzoek, de coderingen voor SH Schuldhulpverlening en SK Saneringskrediet.

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

• 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.

• Principe van eenduidigheid: de data binnen de HDN Standaard moet een eenduidige betekenis hebben. We streven naar definities die maar voor één uitleg vatbaar zijn en ook door alle partijen op dezelfde wijze worden geïnterpreteerd.

Aanpassing: Uitbreiding waardelijst SoortGeregisteerdeLeningType met:

• SH Schuldhulpverlening

• SK Saneringskrediet

HDN-105

OfferteAanvraag (AX)

Verwijderen Duurhuur

Aanleiding: NHG is per 21 sep. 2023 gestopt met de pilot duurhuur, omdat deze niet bracht wat zij hadden verwacht. Voor de pilot duurhuur was binnen de entiteit MaatwerkOplspec in de waardelijst onder ExplainReden een waarde opgenomen 12 Duurhuur . Met het vervallen van de pilot kan de code uit de generieke Explainredenen worden verwijderd.

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

• Principe van dataminimalisatie:binnen de HDN Standaard wordt alleen data verzonden die partijen wensen te ontvangen voor het uitvoeren van hun processen. De partijen bepalen zelf welke minimale dataset zij nodig hebben.

Aanpassing: Uit de generieke waardelijst ExplainRedenType wordt de waarde 12 Duurhuur verwijderd. Indien een organisatie die deze nu heeft opgenomen als maatwerkreden wenst te hanteren, dient er een verzoek te worden gedaan voor organisatiespecifiek maatwerk.

HDN-86

OfferteAanvraag (AX)

Afdwingen DuurInMnd of EindDt

Aanleiding: Op dit moment is het mogelijk dat in de HDN OfferteAanvraag zowel DuurInMnd als EindDtLeningdeel wordt ingevuld.
De boolean VasteEindDtLeningdeelJN bepaalt welke van de twee verplicht is, maar de ander wordt niet geblokkeerd.
De wens is om vanuit HDN het onmogelijk te maken dat beide velden worden ingevuld:

• Als VasteEindDtLeningdeelJN == J, dan moet alleen EindDtLeningdeel gevuld zijn.

• Als VasteEindDtLeningdeelJN ==N, dan moet alleen DuurInMnd gevuld zijn.

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

• Principe van doelbinding: Enkel gewenste velden moeten worden opgestuurd. Door technische controles toe te voegen kun je niet (per ongeluk) te veel data opsturen.

• Principe van procesoptimalisatie: Met het toevoegen van technische controles ontstaat voor het versturen al duidelijkheid over de aanvraag.

Aanpassing: Er wordt een nieuw type regel geïntroduceerd: de VoorwaardeNull-regel. Hiervoor hebben wij een aanpassing in zowel de validator als de schemabeheertool doorgevoerd. In de controle XML wordt deze als volgt getoond:

De volgende regels worden toegepast:

• EindDt mag niet voorkomen als //lening/leningdeel/VasteEindDtLeningdeelJN heeft waarde (N Nee)

• DuurInMnd mag niet voorkomen als //Lening/Leningdeel/VasteEindDtLeningdeelJN heeft waarde (J Ja)

Note: Het is vooralsnog alleen mogelijk voor HDN-medewerkers om deze regel te leggen.

HDN-101

OfferteAanvraag (AX)

Uitbreiding overbrugging

Aanleiding: De HDN Standaard biedt momenteel beperkte mogelijkheden voor diversificatie van overbruggingskredieten. Dit houdt marktpartijen tegen om innovatieve producten te introduceren die passen bij de actuele marktomstandigheden.

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: Uitbreiding van de entiteit Overbrugging met de velden:

• DuurInMnd

• RenteVastInMnd

Deze velden worden organisatiespecifiek toegevoegd.

HDN-70

OfferteAanvraag (AX)

Uniformeren Starterslening

Aanleiding: Binnen het verzekerendomein bleek verschillend gebruik gemaakt te worden van de starterslening. Dit is uiteraard niet wenselijk. Naar aanleiding hiervan is het hypothekendomein gevraagd hoe omgegaan dient te worden met de starterslening.

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 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: Velden die komen te vervallen:

• SubsidieRegeling

• SubsidieRegelingBedrag

• AflossingSVnStarterslening

Toegevoegd wordt aan de entiteit Lening:

• entiteit Subsidie voorkomens 0-1

• AflossingSVnStarterslening voorwaarde Optioneel

• Binnen de entiteit Subsidie wordt opgenomen:

• SubsidieRegeling voorwaarde Verplicht

• SubsidieRegelingBedrag voorwaarde Verplicht

STAN-262

OfferteAanvraag (AX)

ketenafspraak in regel: Verkoopkosten

Aanleiding: De ketenafspraakVerkoopkosten vereist het volgende:

• Het organisatiespecifieke veld VerkoopKosten is beschikbaar binnen de entiteit HuidigObject. Wanneer een aanbieder dit veld in zijn berichtschema opneemt, moet dit veld conditioneel verplicht worden gemaakt als OverbruggingJN is waar.

Deze vereiste kan ook via een regel op het veld worden afgedwongen.

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:

Generieke regel op het veld VerkoopKosten (is alleen van toepassing wanneer een aanbieder deze in zijn berichtschema heeft opgenomen). VerkoopKosten is verplicht als //HuidigObject/OverbruggingJN heeft waarde (J Ja)

De bestaande ketenafspraak Verkoopkosten zal met ingang van de HDN24-release komen te vervallen.

HDN-60

StatusBericht (SX)

Extra statusmeldiing wanneer stukken naar de notaris zijn gestuurd

Aanleiding: Het moment dat de stukken naar de notaris worden verzonden is een belangrijke mijlpaal binnen het hypotheekproces, daarom is ervoor gekozen om op dit moment expliciet een statusbericht te versturen naar het intermediair.

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:

SX 31 Dossier verzonden naar notaris. Betekenis: Het dossier is naar de notaris verzonden en klaar om te passeren. Dit is een verplichte status met een uitzondering voor onderhandse verhogingen.

HDN-75

StatusBericht (SX)

Extra statusmelding wanneer het dossier door de tweede beoordelaar wordt teruggestuurd naar de eerste beoordelaar.

Aanleiding: Vanuit verschillende serviceproviders is het verzoek gekomen om in navolging van de SX 29 een aanvullende status te introduceren waarmee het dossier bij 2e beoordeling teruggestuurd kan worden naar de 1e beoordelaar.

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:

SX 30 Herbeoordeling na tweede beoordeling. Betekenis: Dossier wordt door de tweede beoordelaar teruggestuurd naar de eerste beoordelaar voor herbeoordeling. Dit is een optionele status. wanneer hier gebruik van gemaakt wenst te worden, dienen hier afspraken over gemaakt te worden tussen betrokkenen.

STAN-407

OfferteAanvraag (AX)

Generieke regel op VerplichtingPerJaar t.b.v. studielening

Aanleiding: Met de wijziging van de Trhk 2024 is de jaarlast van de studielening benodigd om de juiste studieleninglast te bepalen. Daarom wordt een generieke regel op het gebruik LeningPerJaar geïntroduceerd waarmee deze wordt verplicht bij basisbeurs of leenstelsel.

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.

Aanpassing:

Generieke regel op veld //Hypotheekgever/OverigeLening/VerplichtingPerJaar: VerplichtingPerJaar is verplicht als SoortOverigeLening heeft waarde (05 Basisbeurs. 06 Leenstelsel)

STAN-660

OfferteAanvraag (AX)

Dataleverancier Uitbreiding

Aanleiding: per 1 februari 2024 is de waardelijst DataleveranicerNaam uitgebreid met de waarden 08 Datakeeper en 10 Veilig Ophalen.

Aanpassing: Om een uitbreiding van dataleveranciers nu en ook in de toekomst goed te ondersteunen dienen dataleveranciers voortaan middels de volgende regel te worden Ingesloten in het berichtschema:

DataleverencierNaam heeft waarde (x , x)

STAN-343

OfferteAanvraag (AX)

Verwijderen niet gebruikte velden

Aanleiding: HDN heeft een analyse gedaan op het veldgebruik van organisatiespecifieke velden. Enkele velden werden maar door een paar organisaties gebruikt. Bij deze organisaties is nagevraagd of de velden nog toegevoegde waarde hebben. Voor een aantal velden bleek dat niet het geval te zijn.

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

• Principe van dataminimalisatie:binnen de HDN Standaard wordt alleen data verzonden die partijen wensen te ontvangen voor het uitvoeren van hun processen. De partijen bepalen zelf welke minimale dataset zij nodig hebben.

Aanpassing:

De volgende velden worden verwijderd:

• OorspronkelijkeWaardeWoning

• OfferteAanvraagDt

• AantalKinderen

• ClientNr

• BoeteVervroegdeAflossing

• BeheerovereenkomstJN