Spring naar het einde van metadata
Ga nar het begin van metadata

Je bekijkt een oude versie van deze pagina. Bekijk de huidige versie.

Vergelijk met huidige Toon pagina geschiedenis

« Vorige Versie 36 Huidig »

HDN versie

24.0

Release datum

Geraakte domeinen

Hypotheken, Leven, Kredieten, Bankgaranties, Actief klantbeheer, Brondata.

Geraakte berichten

OFFERTEAANVRAAG (AX)/STATUSBERICHT (SX) / BEHEERVERZOEK (MX) / KREDIETAANVRAAG (KX)/ LEVENAANVRAAG (LX)/OFFERTE (OX)/INFORMATIEBERICHT (IX) / INFORMATIEAANVRAAG (IA) / DOCUMENTAANVRAAG (DA)/ DOCUMENTBERICHT (DX) / WAARBORG (WX)/ INKOMENSVERKLARINGONDERNEMERAANVAAG (ZX) /

Releasecontent

Hieronder staan de verschillende backlogitems genoteerd die door de daarvoor verantwoordelijke werkgroep zijn geprioriteerd voor deze release, en de daarbij behorende actuele status.

#

Status*

Bericht(en)

Naam

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

* Status geeft de status aan van de wijziging weer.

Planning

De planning moet is vastgesteld in overeenstemming met de werkgroepen en is in lijn met het releasebeleid.

Fase

Resultaat

Gebruikelijke termijn

Van

Tot

Scopebepaling

Releasespecificaties HDN 24 worden in concept gepubliceerd

Tot +/- 6 maanden voor go-live

Consultatieperiode

Definitieve scope

5 weken

Consultatieperiode

Definitieve releasenotes

2 weken

Opbouwen schema’s

Basisberichtschema’s worden door HDN opgebouwd en gepubliceerd

2 weken

Opbouwen schema’s

Organisatieschema’s zijn ter review aangeboden

6 weken

Review door HDN

Organisatieschema’s worden gepubliceerd en naar de testomgeving gedistribueerd

3 weken

Test/freezeperiode

Schema’s gedistribueerd naar productie

6 weken

Go-live

Afronding release

-

00:30

Scope van de release

Generiek

#

Bericht(en)

Naam

Beschrijving

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.

Vervallen: Deze wijziging is komen te vervallen voor de HDN24-release omdat, meerdere leden en gebruikers hebben aangegeven de APIV2-overgang te koppelen aan de HDN24-release. Indien HDN de Header dan ook echt verwijderd heeft, dan is er geen fallback-scenario voor deze partijen als er incidenten optreden. Het uitgangspunt is dat de header in de volgende release wordt verwijderd.

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}

Vervallen: Deze wijziging is komen te vervallen. Met het testen bleek het patroon verkeerd gegenereerd te worden in de XSD waarmee deze ongeldig wordt. Dit probleem kan niet op tijd worden opgelost. Wij zullen deze wijziging agenderen voor een volgende release.

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

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

Domein Hypotheken

#

Bericht(en)

Naam

Beschrijving

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 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-20240205-090538.png

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 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:

image-20240119-161437.png

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 ketenafspraak Verkoopkosten 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 verhoging, interne oversluiting of omzetting. Status wordt verstuurd voor SX26 Gelden worden uitbetaald.

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

  • BoeteVervroegdeAflossing

  • BeheerovereenkomstJN

In een eerdere versie is gecommuniceerd dat ook clientNr verwijderd worden, deze is echter nog wel in gebruik en wordt daarmee niet verwijderd.

Domein Verzekeren

#

Bericht(en)

Naam

Beschrijving

HDN-4

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 om vanuit de Standaard hierbij aan te sluiten zodat ook toekomstige integraties gestandaardiseerd ingeregeld kunnen worden.

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

HDN-43

LevenAanvraag (LX)

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 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. Dit komt 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.

HDN-70

LevenAanvraag (LX)

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: Bestaande Regel: SubsidieRegeling heeft waarde 02 Starterslening, vervalt. alleen de waarde 03 SVn Starterslening is nog beschikbaar.

HDN-74

LevenAanvraag (LX)

Certificeringspunten ondervangen in regels

Aanleiding: We hebben een analyse gedaan op de certificeringpunten binnen de verzekeringsberichten. 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:

  • //LevenAanvraag/FinancieleDekking

    • DuurInMnd is groter dan 0

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

  • //LevenAanvraag/FinancieleDekking/ProductCategorie/Lastenverzekering/Verzekerde/VerzekerdeBedragen

    • DuurInMnd is groter dan 0

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

  • //LevenAanvraag/FinancieleDekking/ProductCategorie/Inkomensverzekering/Verzekerde/VerzekerdeBedragen

    • DuurInMnd is groter dan 0

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

  • //LevenAanvraag/FinancieleDekking/ProductCategorie/Overlijdensrisicoverzekering/Verzekerde/VerzekerdeBedragen

    • DuurInMnd is groter dan 0

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

  • //LevenAanvraag/FinancieleDekking/ProductCategorie/Kredietbeschermer/Verzekerde/VerzekerdeBedragen

    • DuurInMnd is groter dan 0

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

  • //LevenAanvraag/FinancieleDekking/PremieAfspraken

    • DuurInMnd is groter dan 0

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

STAN-173

LevenAanvraag (LX)

Vervallen EindWaardeDekking en WaarvanGegarandeerd

Aanleiding: In HDN23 is het veld MinVerzBedragOpEindDt geïntroduceerd binnen LEVENAANVRAAG (LX). Doel hiervan is om de velden EindwaardeDekking en WaarvanGegarandeerd te vervangen. Deze velden zijn echter nog wel in het bericht te vinden. Om te voorkomen dat beide manieren kunnen worden gebruikt (en daarmee potentieel tegenstrijdige informatie wordt doorgegeven, is het voorstel om de EindwaardeDekking en WaarvanGegarandeerd te verwijderen.

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:

  • EindwaardeDekking

  • WaarvanGegarandeerd

STAN-26

LevenAanvraag (LX)

Uitfaseren niet gebruikte velden Verzekerenbericht

Aanleiding: Elk jaar onderzoekt HDN of er velden zijn die in geen enkel organisatiespecifiek schema zijn opgenomen. Uit de analyse van dit jaar blijkt dat de entiteit //LevenAanvraag/BancaireDekking door geen enkele organisatie (meer) wordt gebruikt.

In dit voorstel wordt deze entiteit en onderliggende entiteiten en velden daarom uit het basisschema van LevenAanvraag gehaald.

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: Wij verwijderen de entiteit BancaireDekking met de daarbij behorende velden:

  • BedragBetaaldLopendJaar

  • ContractLopendInlegHoog

  • ContractLopendInlegLaag

  • CumulatieveInlegEindDt

  • InlegBerekeningsUitgangspunt

  • SoortAdvies

Domein Kredieten

#

Bericht(en)

Naam

Beschrijving

HDN-4

KredietAanvraag (KX)

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 KredietAanvraag worden, om aan te sluiten bij de Fotowijzer Woningen, twee nieuwe waardelijsten geïntroduceerd:

ObjectSoort (verplicht)

BijzObjectSoort (optioneel)

Aanvullend wordt het veld GarageJN 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

KredietAanvraag (KX)

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 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: 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. Dit komt 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.

HDN-73

KredietAanvraag (KX)

Certificeringspunten ondervangen in Regels

Aanleiding: We hebben een analyse gedaan op de certificeringpunten binnen de kredietberichten. 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:

  • //KredietAanvraag/KredietAanvraagGegevens/BedragKrediet

    • BedragKrediet is groter dan 0,00

    • Melding: het BedragKrediet moet groter dan 0,00 zijn.

Domein Bankgaranties

#

Bericht(en)

Naam

Beschrijving

HDN-43

WaarborgBericht (WX)

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 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. De entiteit Identificatie wordt beschikbaar gemaakt binnen Hypotheekgever. Binnen de entiteit Identificatie wordt het veld Legitimatiegeslacht verplicht met daarin de waarde 01 M en 02 V. De 03 X wordt vooralsnog niet ondersteund.

HDN-70

WaarborgBericht (WX)

Uniformeren Starterslening

Aanleiding: Binnen het verzekerendomein bleek verschillend gebruik 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:

  • Starterslening

Toegevoegd wordt aan de entiteit Lening:

  • entiteit Subsidie voorkomens 0-1

  • SubsidieRegeling voorwaarde Verplicht

  • SubsidieRegelingBedrag voorwaarde Verplicht

HDN-90

WaarborgBericht (WX)

Arrangement verplicht bij Bankgarantie

Aanleiding: Arrangement blijkt voor elke bankgarantieaanvraag benodigd te zijn.

Doel: Het voorstel raakt de volgende HDN Standaard-principes

Principe van procesoptimalisatie: Het is noodzakelijk dat bij elke aanvraag het duidelijk is onder welk arrangement de bankgarantie wordt aangevraagd.

Aanpassing: Arrangement wordt verplicht gemaakt.

HDN-91

WaarborgBericht (WX)

Bankgarantie geldigheid onderscheid bestaande bouw/nieuwbouw

Aanleiding: Tijdens de bijeenkomsten van de werkgroep Bankgaranties is aangegeven dat er problemen zijn met het ontvangen bericht betreffende de looptijd van de bankgarantie. Bij Nationale Waarborg geldt voor bestaande bouw een maximale looptijd van 1 jaar, terwijl dit voor nieuwbouw maximaal 2 jaar is.

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

Principe van procesoptimalisatie: Het is essentieel om onjuistheden in de looptijd van de bankgarantie te vermijden, zodat Nationale Waarborg niet genoodzaakt is om contact op te nemen met de adviseur.

Aanpassing: De volgende regel wordt geplaatst op het veld Bankgarantiegeldigheid:

  • Bankgarantiegeldigheid heeft niet waarde (02 2 jaar) als //Object/Onderpand heeft waarde (01 bestaand, 02 bestaand verbouw)

HDN-41

WaarborgBericht (WX)

Verwijderen bedrijfsnaam in PartijNAWData

Aanleiding: In de entiteit PartijNAWData hebben we nu een veld genaamd Bedrijfsnaam toegevoegd. Er is een regel ingesteld waardoor dit veld verplicht is wanneer PartijNAWData/SoortPartij = 02 rechtspersoon. Verder hebben de entiteiten Notaris en Tussenpersoon ook het veld Bedrijfsnaam. In beide entiteiten is dit veld eveneens verplicht. Dit betekent dat de Bedrijfsnaam voor zowel de Notaris als de Tussenpersoon dubbel wordt verstrekt. Dit is niet wenselijk.

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

Principe van procesoptimalisatie: Het is cruciaal om te waarborgen dat identieke gegevens niet tweemaal binnen één bericht worden weergegeven.

Aanpassing: het veld Bedrijfsnaam wordt verwijderd binnen de entiteit PartijNAWData.

HDN-42

WaarborgBericht (WX)

Bedrijfsnaam benodigd als Verkoper

Aanleiding: In de entiteit PartijNAWData is het veld Bedrijfsnaam verwijderd. Dit is gedaan om overlap te voorkomen, omdat Bedrijfsnaam ook al in de entiteiten Notaris en Tussenpersoon staat. Hierdoor ontbreekt er echter informatie over de verkoper. Als de verkoper een bedrijf is, is de bedrijfsnaam essentieel om te weten.

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

  • Principe van procesoptimalisatie: Het is belangrijk om te voorkomen dat dezelfde gegevens tweemaal in een bericht worden vermeld.

  • Principe van eenduidigheid: Het is essentieel om te waarborgen dat er geen velden bestaan waarin gelijksoortige informatie wordt overgedragen.

Aanpassing: het veld Bedrijfsnaam wordt toegevoegd binnen de entiteit Verkoper. Dit veld is conditioneel verplicht:

  • BedrijfsNaam is verplicht als //PartijNAWData/SoortPartij heeft waarde (02 rechtspersoon)

HDN-92

WaarborgBericht (WX)

Verwijderen overbodige velden Eigen middelen

Aanleiding: Er waren meerdere velden voor eigen middelen beschikbaar, echter was maar één veld hierin leidend. Daarom is besloten de overige velden te verwijderen.

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

Principe van procesoptimalisatie: Het is noodzakelijk dat bij elke aanvraag het duidelijk is of er eigen middelen worden ingebracht in de hypotheek. Dit voorkomt uitval in het proces.

Principe van dataminimalisatie: Het veld IngebEigenMiddelen verschaft afdoende informatie voor de beoordeling van de aanvraag. Hierdoor zijn de overige velden in het schema, die betrekking hebben op eigen middelen, overbodig geworden.

Aanpassing:

De volgende velden worden verwijderd:

  • SchenkingIngebracht

  • OverigIngebracht

  • IngebAndersOmschr

STAN-151

WaarborgBericht (WX)

InitieelPakket toevoegen

Aanleiding: InitieelPakket is met de HDN23.1 geïntroduceerd en zal met de HDN24 ook in het waarborgbericht worden opgenomen.

Aanpassing: InitieelPakket wordt toegevoegd binnen de entiteit Tussenpersoon

Domein Actief Beheer

#

Bericht(en)

Naam

Beschrijving

HDN-4

InformatieBericht (IX)

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 het InformatieBericht. Er wordt geen nieuw veld geïntroduceerd

HDN-43

Beheerverzoek (MX)

InformatieBericht (IX)

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 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: Voor het Beheerverzoek is het volgende van toepassing: Geslacht komt te vervallen en LegitimatieGeslacht wordt als veld toegevoegd binnen de entiteit Identificatie met daarin de waardelijst LegitimatieGeslachtType bestaande uit de waarden:

  • 01 M

  • 02 V

  • 03 X

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

HDN-40

Beheerverzoek (MX)

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 OfferteAanvraag en BeheerVerzoek 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-288

Beheerverzoek (MX)

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

STAN-541*

Beheerverzoek (MX)

Uitbreiden velden

Aanleiding: ABN-Amro heeft het verzoek ingediend om het BeheerVerzoek uit te breiden. Met de uitbreiding kan het proces tussen ABN-Amro en Stater efficiënter verlopen.

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: De gewenste uitbreiding bestaat uit reeds bestaande velden in de taxonomie. De volgende velden worden toegevoegd:

  • Object/VerduurzamingToepassen

  • Object/VerduurzamingBesprokenJN

  • Object/BedragKwaliteitsverbeteringEBV

  • Object/BedragKwaliteitsverbeteringEBB

  • Object/Verbouwingskosten

  • Lening/Leningdeel/NHGJN

  • Lening/BestedingsDoel

  • Lening/ToelichtingBestedingsDoel

STAN-261*

InformatieBericht (IX)

Dataminimalisatie

Aanleiding: Dataminimalisatie is een belangrijk principe binnen de gegevensbescherming en privacy. Het principe houdt in dat je alleen die persoonsgegevens verwerkt die noodzakelijk zijn voor het vooraf bepaalde doel.

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: De volgende entiteiten/velden worden verwijderd:

  • Depot/DuurInMnd

  • Hypotheek/DuurInMnd

  • Lening/NHG

  • Lening/SaldoBestaandeHyp

  • Lening/IngsngsDtLening

  • Lening/EindDtLening

  • Lening/AflossingsvrijDeel

  • Lening/EindDtHypotheek

  • Lening/IncassoAfspraak

  • Leningdeel/DuurInMnd

  • Object/Land

  • Object/WOZWaarde

  • Object/WOZWaardeTaxatieDt

  • Tariefklasse/Garantie

  • Tussenpersoon

STAN-49*

InformatieBericht (IX) en Beheerbericht (MX)

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: Toegevoegd wordt:

Entiteit:

  • Overbrugging (0-2)

Met daarin de velden:

  • CodeOverbruggingMij (O)

  • DuurInMnd (O) → Alleen BeheerVerzoek (MX)

  • RenteVastInMnd (O)

  • IngangsDt (O)

  • EindDt (O)

Het veld CodeOverbruggingMij betreft een waardelijst met daarin de productnamen voor de overbrugging. Organisaties die hier gebruik van willen maken, dienen het Overbruggingsproduct aan HDN door te geven.

STAN-534

InformatieBericht (IX)

Toevoegen Energieklasse

Aanleiding: Veel marktpartijen laten hun rentetarief afhangen van het energielabel van de woning. Het is wenselijk om het intermediair informatie te verschaffen op basis van welk energielabel het rentetarief is bepaald.

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

Toevoegen:

EnergieKlasse

HDN-70

BeheerVerzoek (MX)

Uniformeren Starterslening

Aanleiding: Binnen het verzekerendomein bleek verschillend gebruik 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:

Aanpassing: Velden die komen te vervallen:

  • SubsidieRegeling

  • SubsidieRegelingBedrag

Toegevoegd wordt aan de entiteit Lening:

  • entiteit Subsidie voorkomens 0-1

  • Binnen de entiteit Subsidie wordt opgenomen:

  • SubsidieRegeling voorwaarde Verplicht

  • SubsidieRegelingBedrag voorwaarde Verplicht

STAN-648

InformatieAanvraag (IA)

Uitbreiding met KvKNr

Aanleiding: Momenteel zijn enkele organisaties bezig met het inregelen van het InformatieAanvraag-bericht. uit hun onderzoek komt naar voren dat de huidige informatie in het InformatieAanvraag-bericht onvoldoende is om een volledige overeenkomst te garanderen met de gegevens van de tussenpersoon in hun systeem. Dit vormt een obstakel voor de succesvolle implementatie van deze berichten.

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.

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: Uitbreiding van de entiteit Tussenpersoon met KvKnr (V)

Domein Brondata

Toelichting Statussen

Status

Betekenis

ONDERHANDEN IN WERKGROEP

Houdt in dat de wijziging wel is geprioriteerd door de werkgroep voor de release, maar dat de uitwerking hiervan nog gedaan moet worden.

TER AKKOORD BIJ DE WERKGROEP

Voorstel is uitgewerkt en ter akkoord aangeboden aan de daarvoor verantwoordelijke werkgroep.

VOORSTEL AKKOORD

Voorstel is ter akkoord door de daarvoor verantwoordelijke werkgroep aangenomen en zal worden meegenomen in de release.

VERVALLEN

Wijziging was geprioriteerd voor de release, maar vanwege verschillende redeneren kan deze niet worden opgenomen in de release.

  • Geen labels