HDN Standaard 25

STAN-1037

Analyse

XSDValidation

Aanpassen XSDValidation (VX) ten behoeve van het toevoegen van brondata statusmeldingen

STAN-408

Onderhanden in werkgroep

Generiek

Ketenafspraak over requestVersion via platform afdwingen

STAN-23

Voorstel akkoord

Generiek

Verwijderen XML-Header

STAN-63

Voorstel akkoord

Generiek

Aanscherping patroon Email

STAN-1101

Voorstel akkoord

Generiek

Wijziging omschrijving van veldnaam LeningLopendJN

STAN-2230

Voorstel akkoord

Generiek

LandType updaten

STAN-293

Voorstel akkoord

Generiek

Naamsverbetering nieuwbouw

STAN-2068

Voorstel akkoord

Offerte

Minder verplichte velden voor OfferteBericht Verzekeren

STAN-958

Voorstel akkoord

Offerte

Opschonen niet gebruikte velden OfferteBericht

STAN-88

Voorstel akkoord *

Offerte Doc.aanvraagBerichtDocumentBericht

Klantbeeld en dubbele woonlastenformulier ondersteunen in Offerte en Documentberichten

STAN-1308

Voorstel akkoord

Doc.aanvraagBericht Documentbericht

Uitbreiding Documenten “Verklaring van gemoedsbezwaren”

STAN-923

Voorstel akkoord

Doc.aanvraagBericht Documentbericht

Verwijderen Document Soort ‘024 Kopie identiteitsbewijs’

STAN-1036

Vervallen

Doc.aanvraagBericht Documentbericht

Herinrichting DocumentBericht t.b.v. meegeven brondatasleutel

STAN-162

Voorstel akkoord

OfferteAanvraag

Herinrichten entiteit Object

STAN-647

Voorstel akkoord

OfferteAanvraag

ArrangementNr vervangen voor Arrangement

STAN-510

Voorstel akkoord

OfferteAanvraag

Verwijderen niet gebruikte velden OfferteAanvraag HDN25

STAN-93

Voorstel akkoord

OfferteAanvraag

Verwijderen AanvullendeVerzendwijze

STAN-94

Voorstel akkoord

OfferteAanvraag

Klantbeeld mee kunnen geven in OfferteAanvraag

STAN-2058

Voorstel akkoord

OfferteAanvraag

NHG termen kortingsconstructie en kortingsdeel wijzigen naar koperssteun en ondersteuningsdeel

STAN-1035

Voorstel akkoord

OfferteAanvraag

Herinrichting meegeven sleutel dataleverancier in OfferteAanvraag

STAN-1060

Onderhanden in werkgroep

OfferteAanvraag

Verbeteren ketenafspraken leningdelen en/of schema

STAN-59

Ter akkoord bij de werkgroep

OfferteAanvraag

Doc.aanvraagBericht

Ondersteuning digitale ondertekening

STAN-2361

Ter akkoord bij de werkgroep

OfferteAanvraag

LegitimatieGeslacht X generieke ondersteuning in OfferteAanvraag

STAN-2360

Ter akkoord bij de werkgroep

OfferteAanvraag

Ondersteunen BAG-ID

STAN-716

Vervallen

OfferteAanvraag

Uitbreiding financieringsopzet

STAN-791

Voorstel akkoord

OfferteAanvraag

LevenAanvraag

Beschrijven attributen "Verplicht maken toestaan" Binnen PartijNAWData

STAN-1402

Voorstel akkoord

LevenAanvraag

Serviceprovider toevoegen aan generiek schema

STAN-915

Voorstel akkoord

LevenAanvraag

Structuurwijziging LevenAanvraag IdentificatieVerificatieJN

STAN-920

Voorstel akkoord

LevenAanvraag

DoelVerzekering generiek verplicht maken

STAN-1604

Voorstel akkoord

LevenAanvraag

Verwijderen niet gebruikte velden LevenAanvraag HDN25

STAN-719

Voorstel akkoord

LevenAanvraag

GeweigerdRedenOmschr en UitsluitingRedenOmschr in LevenAanvraag organisatiespecifiek maken

STAN-2095

Voorstel akkoord

LevenAanvraag

Nieuwe verplichte velden in LevenAanvraag

STAN-2094

Voorstel akkoord

LevenAanvraag

Optimalisatie van velden in de LevenAanvraag

STAN-57

Voorstel akkoord

Statusmelding

Beëindigingsbrief bij afwijzing meesturen via StatusMelding

STAN-1216

Voorstel akkoord

Statusmelding

Kenmerk verplichten bij statusmelding Polis Verzonden

STAN-567

Ter akkoord bij de werkgroep

Waarborgbericht

LegitimatieGeslacht 'X' Waarborgbericht toevoegen

STAN-1025

Voorstel akkoord

Waarborgbericht

Bedrijfsnaam verplichten bij rechtspersonen

STAN-988

Ter akkoord bij de werkgroep

InformatieAanvraagbericht

Informatiebericht

Dataminimalisatie InformatieAanvraag- en Informatie bericht plus optimaliseren bericht- Versie HDN25

STAN-2045

Ter akkoord bij de werkgroep

Informatiebericht

Informatiebericht uitbreiden met beheersignaal

STAN-1160

Onderhanden in werkgroep

Informatiebericht

Tariefklasse verplicht veld geven

STAN-1179

Onderhanden in werkgroep

Beheerverzoek

Uitbreiding t.b.v. Bouwdepot Declaraties

STAN-1346

Ter akkoord bij de werkgroep

BrondataBerichten

Dataminimalisatie doormiddel van beperking op entiteiten Hypotheekgever & PartijNAWData

STAN-1040

Ter akkoord bij de werkgroep

Brondataberichten

DocSoort en SoortDocument scheiden

STAN-2320

Voorstel akkoord

Voorafingev.aangiftebericht

Herinrichten schema VoorafIngevuldeAangiftebericht (VIA)

STAN-1349

Voorstel akkoord

BAsisreg.personenBERICHT

Uitbreiden met ontbrekende velden

Scopebepaling

Releasespecificaties HDN 25 worden in concept gepubliceerd

Tot +/- 6 maanden voor go-live

Dec 12, 2024

Jan 30, 2025

Consultatieperiode

Definitieve scope

5 weken

Dec 12, 2024

Jan 16, 2025

Consultatieperiode

Definitieve releasenotes

2 weken

Jan 30, 2025

Opbouwen schema’s

Basisberichtschema’s worden door HDN opgebouwd en gepubliceerd

2 weken

Jan 16, 2025

Jan 30, 2025

Opbouwen schema’s

Organisatieschema’s zijn ter review aangeboden

6 weken

Jan 30, 2025

Mar 13, 2025

Review door HDN

Organisatieschema’s worden gepubliceerd en naar de testomgeving gedistribueerd

4 weken

Mar 13, 2025

Apr 10, 2025

Test

Schema’s gedistribueerd naar productie

6 weken

Apr 10, 2025

May 24, 2025

Freezeperiode

Periode waarin geen nieuwe berichtschema’s naar productie kunnen worden gebracht anders dan HDN 24.1 release gerelateerd.

6 weken

Apr 24, 2025

Jun 5, 2025

Go-live

Afronding release

-

00:30 May 24, 2025

STAN-408

Generiek

Ketenafspraak over requestVersion via platform afdwingen

Wijziging:

De validatie van de requestVersion vindt plaats op het platform. Op het moment dat de meegegeven requestVersion meegegeven wordt, leeg of 0 is, wordt er geen record gemaakt in het dossier en wordt deze beantwoordt met, HTTP foutcode ‘400’, met de foutmelding ‘Invalid request body.header.requestVersion does not match allowed format of 1 to 3 digits and must be greater than 0”’

Samenvatting:

Door het afdwingen van ketenafspraken op het platform, kunnen wij een hogere kwaliteit van het berichtenverkeer garanderen. Het afdwingen van een gedeelte van de ketenafspraak over requestVersion geeft eenieder de mogelijkheid om te wennen aan deze manier van valideren.

STAN-23

Generiek

Verwijderen XML-Header

Wijziging:

De //Header met onderliggende velden wordt verwijderd uit alle berichtschema’s waarin deze nog is opgenomen.

Samenvatting:

In 2023 is de APIv2 versie neergezet waarin de Header in de XML, die stuurinformatie bevat, overbodig is geworden. Stuurinformatie is sindsdien onderdeel van de JSON en daarom niet meer nodig in de XML berichtenstructuur.

Na uitvraag bij onze leden en gebruikers, over het gebruik van de Header op XML niveau, konden we concluderen dat niemand de Header nog nodig heeft met de HDN25 versie. Daarom wordt de Header dan ook verwijderd uit alle berichtschema’s waar deze nog onderdeel van uitmaakt.

STAN-63

Generiek

Aanscherping patroon Email

Wijziging:

Het patroon voor het datatype EmailType wordt gewijzigd naar: [a-zA-Z0-9._%+-]{1,64}@[A-Za-z0-9.-]{0,255}[A-Za-z0-9]{1}\.[A-Za-z]{1,63}

Samenvatting:

Door het patroon aan te passen, wordt het emailadres wat verzonden wordt via de XML berichten betrouwbaarder.

STAN-1101

Generiek

Wijziging omschrijving veldnaam LeningLopendJN

Wijziging:

De omschrijving van het veld LeninglopendJN wordt gewijzigd naar: ‘Betreft het een lening waar een actieve of toekomstige betaalverplichting voor geldt?’

Samenvatting:

Er wordt een wijziging in de omschrijving doorgevoerd zodat het duidelijker is waarvoor dit veld dient.

STAN-2230

Generiek

LandType updaten

Wijziging:

Aan de waardelijst LandType wordt de waarde XK Kosovo toegevoegd.

Samenvatting:

Met HDN24 is de waardelijst aangepast aan de ISO landenlijst, daarbij was Kosovo verwijderd omdat deze niet op de ISO landenlijst voorkomt als geaccepteerd land. Nederland heeft Kosovo echter wel geaccepteerd.

Bij de jaarlijkse analyse zal voortaan naast de ISO landenlijst ook gekeken worden naar de door Nederland geaccepteerde landen.

STAN-293

Generiek

Naamsverbetering nieuwbouw

Wijziging:

Het veld BouwPlanNr wordt vervangen voor Bouwplan

Het veld SituatieNr wordt vervangen door Bouwnummer

Samenvatting:

Het was onduidelijkheid hoe en welke velden gevuld moeten worden in het geval van nieuwbouw. Om deze reden vervangen we een aantal velden. Hiermee zou het doel van deze velden duidelijker moeten zijn. Deze velden zijn tevens in lijn met de inrichting van het OfferteAanvraag bericht.

STAN-2068

Offerte

Minder verplichte velden voor OfferteBericht Verzekeren

Wijziging:

//OfferteData/VerleningingMogelijkJN is verplicht als //OfferteData/ResponsOpBerichtSoort heeft waarde (AX OfferteAanvraag, MX BeheerVerzoek of WX WaarborgBericht heeft. Dit veld was nu altijd verplicht.

/OfferteData/FinancieleDekking/Fiscaal​Geruisloze​Voortzetting​J​N wordt optioneel.

Samenvatting:

De werkgroep verzekeren heeft aangegeven dat bij het versturen van de Offerte teveel verplichte velden moesten worden gevuld terwijl de informatie niet altijd beschikbaar is. Daarom is gekeken welke velden optioneel gemaakt kunnen worden in geval van een LevenAanvraag.

STAN-958

Offerte

Opschonen niet gebruikte velden OfferteBericht

Wijziging:

De entiteit Hypotheekgever wordt verwijderd, inclusief alle onderliggende velden en entiteiten. Dit betreft het veld Hypotheekgever/RefPartijNAWData en de sub entiteiten Verplichtingen, GeregistreerdeLening, OverigeLening en alle velden in deze entiteiten.

Samenvatting:

Jaarlijks wordt gekeken naar velden die niet gebruikt worden. De te verwijderen entiteiten en onderliggende velden werden niet gebruikt. In samenspraak met de werkgroep is besloten deze te verwijderen.

STAN-88

Offerte Doc.aanvraagBerichtDocumentBericht

Waarden toevoegen DocSoortType

Wijziging:

• Uitbreiding waardelijst, binnen documentberichten, SoortDocumentType met de waarde ‘(code) Klantbeeldformulier’ en ‘(code) Dubbele woonlastenformulier’. Ook wordt de entiteit Hypotheekgever verplicht wanneer SoortDocument heeft de waarde ‘(code) Klantbeeldformulier’

• Uitbreiding waardelijst, binnen Offerte, DocSoortType met de waarde ‘(code) Klantbeeldformulier ’ en ‘(code) Dubbele woonlastenformulier’.

Samenvatting:

Gebruikers hebben aangegeven bij de Offerte ook een klantbeeldformulier en/of dubbele woonlastenformulier mee te sturen. Er is gevraagd om de waardelijst DocSoortType uit te breiden zodat deze documenten gestandaardiseerd meegestuurd kunnen worden. Ook is het nodig om deze documenten ingevuld en/of ondertekend te retourneren. Daarom worden ook de documentberichten uitgebreid met deze waarde.

STAN-1308

Doc.aanvraagBericht Documentbericht

Uitbreiding Documenten “Verklaring van gemoedsbezwaren”

Wijziging:

Uitbreiding waardelijst SoortDocumentType met de waarde ‘(code) Verklaring van gemoedsbezwaren’. De uitbreiding geldt voor het DocumentBericht en het DocumentAanvraagBericht.

Samenvatting:

Met een ‘Verklaring van gemoedsbezwaar’, van het SVB, heeft een consument de mogelijkheid om aantoonbaar te maken dat deze zich vanuit levensovertuiging niet hoeft te verzekeren. Meer informatie hierover is te vinden op:

• https://wetten.overheid.nl/BWBR0019150/2024-01-01/#Hoofdstuk4

• https://www.rijksoverheid.nl/wetten-en-regelingen/productbeschrijvingen/ontheffing-verzekeringsplicht-sociale-verzekeringen-bij-gemoedsbezwaren

STAN-923

Doc.aanvraagBericht Documentbericht Beheerverzoek

Verwijderen Document Soort ‘024 Kopie identiteitsbewijs’

Wijziging:

Waarde ‘024 Kopie identiteitsbewijs’ wordt verwijderd uit de waardelijst SoortDocument.

Samenvatting:

Met de HDN23 zijn er twee documenten geïntroduceerd ‘267 Kopie identiteitsbewijs zonder BSN’ en 268 Kopie identiteitsbewijs met BSN'. Het doel hiervan is om duidelijker onderscheid te kunnen maken in het aan te leveren document. Na een overgangsperiode van twee jaar wordt het oude document verwijderd.

STAN-162

OfferteAanvraag

Herinrichten entiteit Object

Wijziging:

De entiteit //Objectwordt heringericht. Een deel van de bestaande velden zijn in nieuwe subentiteiten geplaatst: BestaandeBouw, Nieuwbouw, Adres, Verbouwing, Meerwerk en Erfpacht.

Zie Overzicht nieuwe Object-entiteit m.i.v. HDN25 voor alle wijzigingen. Er is ook een Mappingtabel Object wijzigingen gemaakt.

Samenvatting:

De entiteit //Object bestaat uit veel velden. Dit zorgt ervoor dat, de entiteit onoverzichtelijk is, er fouten ontstaan in het verplichten van velden, stellen van regels en het doorgeven/mappen van de data. Ook ontvangen aanbieders niet altijd alle informatie die benodigd is en/of foutieve informatie. Met de vernieuwde inrichting is de entiteit veel overzichtelijker en duidelijker wat er ingevuld moet worden in specifieke situaties.

Met deze change zijn adviespakketten veel beter in staat gestructureerde data te versturen en ontvangen aanbieders betrouwbaardere data.

STAN-647

OfferteAanvraag

ArrangementNr vervangen voor Arrangement

Wijziging:

Binnen de entiteit Lening wordt het veld ArrangementNr vervangen door Arrangement

Samenvatting:

Het veld ArrangementNr en Arrangement werden met hetzelfde doel gebruikt. In het kader van eenduidigheid is besloten het veld Arrangement te behouden.

STAN-510

OfferteAanvraag

Verwijderen niet gebruikte velden OfferteAanvraag HDN25

Wijziging:

De volgende velden worden verwijderd uit het de entiteit //Leningdeel : KortingsBedrag, ComplexProductJN, RefDebiteurNAWData. Ook wordt verwijderd uit de entiteit //object: EnergieEfficientiewaardeBerekenMethode, EnergieEfficientieWaarde en EnergieEfficientieWaardeEindDt.

Samenvatting:

Jaarlijks wordt gekeken naar velden die niet gebruikt worden. De te verwijderen velden werden niet gebruikt. In samenspraak met de werkgroep is besloten deze velden te verwijderen.

STAN-93

OfferteAanvraag

Verwijderen AanvullendeVerzendwijze

Wijziging:

Het veld AanvullendeVerzendwijze wordt verwijderd uit de OfferteAanvraag.

Samenvatting:

Het veld AanvullendeVerzendwijze is niet meer benodigd en wordt daarom verwijderd.

STAN-94

OfferteAanvraag

Klantbeeld mee kunnen geven in OfferteAanvraag

Wijziging:

De volgende velden worden organisatiespeficiek toegevoegd binnen de entiteit //Hypotheekgever, KVKinschrijvingJN, AantalOnroerendGoedObjectenBox3, Woonsituatie en TijdelijkeHuurwoningJN.

De waardelijst WoonsituatieType wordt toegevoegd en bevat de volgende waardes: 01 Inwonend, 02 Huurwoning en 03 Koopwoning.

Het veld EindDt binnen de entiteit //Hypotheekgever/Verplichtingen wordt conditioneel verplicht indien //Hypotheekgever/Verplichtingen/Verplichting heeft waarde 11 Bruto huurlasten en //Hypotheekgever/TijdelijkeHuurwoningJN heeft waarde Ja.

Samenvatting:

Er bovenstaande velden worden toegevoegd om het hypotheek aanvraagproces verder te optimaliseren. Aanbieders kunnen hiermee in een vroegtijdig stadium bepalen of de aanvrager aan de voorwaarden voldoet en de juiste documenten opvragen.

STAN-791

OfferteAanvraag

Beschrijven attributen "Verplicht maken toestaan" Binnen PartijNAWData

Wijziging:

Verplicht maken toestaan wordt voor de volgende velden in de entiteit PartijNAWData in het schema uitgezet: VoorNamen, GeboorteAchternaam, GeboorteTussenvoegsels, CorrespondentieVoornaam , CorrespondentieNaam, CorrespondentieTussenvoegsels, Nationaliteit, GeboortePlaats, GeboorteLand, VoorLetters, GeboorteDt, HuisNrToevoeging, VoorTitel en RekeningNr.

Dit betekend dat het alleen mogelijk is om het veld Land te verplichten.

Samenvatting:

Het kunnen leggen van de restrictie op het schema vanuit een basisschema heeft als doel dat de kwaliteit van de berichtschema’s omhoog gaat. Afgelopen jaren hebben wij meermaals incidenten gehad waarbij invalide schema’s ontstonden door het verplichten van velden binnen de entiteit PartijNAWData. Daarom is nu kritisch gekeken welke velden binnen deze entiteit nooit verplicht kunnen zijn. Daarvoor wordt nu de restrictie ‘Verplicht maken toestaan’ uitgezet.

STAN-2058

OfferteAanvraag

NHG termen kortingsconstructie en kortingsdeel wijzigen naar koperssteun en ondersteuningsdeel

Wijziging:

Verwijderde velden worden vervangen door:

• ErfpachtofKortingsConstructieAnders → ErfpachtconstructieOfKoperssteunAnders

• BedragKortingsdeel → BedragOndersteuningsdeel

• VolledigeAfbetalingKoringsdeel → VolledigeAfbetalingOndersteuningsdeel

Verwijderde waardelijst wordt vervangen door:

• ErfpachtOfKortingsConstructieAndersType → ErfpachtconstructieOfKoperssteunAndersType

Verwijderde enum’s worden vervangen door:

• 01 Kortingsconstructie met vermogensrisico → 01 Koperssteun met vermogensrisico

• 02 Erfpachtconstructie met vermogensrisico → 02 Erfpachtconstructie met vermogensrisico

• 03 Kortingsconstructie zonder vermogensrisico → 03 Koperssteun zonder vermogensrisico

• 04 Erfpachtconstructie zonder vermogensrisico → 04 Erfpachtconstructie zonder vermogensrisico

Verwijderde enum in de waardelijst MutatieType:

• 36 Volledige afbetaling van het kortingsdeel → 37 Volledige afbetaling van het ondersteuningsdeel

Samenvatting:

NHG heeft de termen Kortingsconstructie en Kortingsdeel gewijzigd naar Koperssteun en Ondersteuningsdeel. Om aansluiting te houden bij de NHG terminologie, hebben wij op verzoek van de leden ook de termen aangepast.

STAN-1035

OfferteAanvraag

Herinrichting meegeven sleutel dataleverancier in OfferteAanvraag

Wijziging:

Verwijderd wordt de entiteit //ExterneIdentificatie met de daaronder liggende velden RefDataleveranciers en PersoonsID

De entiteit //Dataleverancier wordt uitgebreid met de velden: RefPartijNAWData, RefHuidigObject, RefObject en DataleverancierSleutel.

De entiteit krijgt de volgende structuur:

//Dataleverancier → voorkomens 0-99

/RefPartijNAWData → Optioneel

/RefHuidigObject –> Optioneel

/RefObject → Optioneel

/DataleverancierNaam → Verplicht

/DataleverancierID → Optioneel

/DataleverancierSleutel → Verplicht

Samenvatting:

Ter ondersteuning van de uitbreiding van brondata wordt de benodigde informatie gecentraliseerd in het berichtschema opgenomen. De wijziging maakt het mogelijk om niet alleen voor de aanvrager maar ook voor het object brondata aan te leveren. Hiermee kan bijvoorbeeld het taxatierapport in een vroegtijdig stadium worden aangeleverd waarmee verwezen wordt naar het object en/of de koopovereenkomst. Op termijn kan met een relatief kleine aanpassing ‘het product’ worden toegevoegd waarmee gerichter brondata kan worden meegegeven.

STAN-57

Statusmelding

Beëindigingsbrief bij afwijzing meesturen via StatusMelding

Wijziging:

De entiteit //Printdoc met daarin de velden: DocSoort, BestandType, Encoding en EncodedData wordt toegevoegd aan het schema. Op de entiteit //Printdoc wordt een regel geplaatst dat deze alleen mag wordt gevuld als de statusmelding 11 Offerteaanvraag afgewezen wordt verstuurd als reactie op de OfferteAanvraag.

Daarnaast wordt de waardelijst DocSoortType uitgebreid met de waarde ‘(code) Afwijsbrief’. De uitbreiding geldt voor de Statusmelding en is de enige waarde die in de Statusmelding wordt aangeboden.

Samenvatting:

Een afwijsbrief van een hypotheekaanvraag wordt op dit moment door veel aanbieders per mail verstuurd. Om te zorgen dat deze brief veilig verstuurd kan worden is in overleg met de werkgroep hypotheken besloten om om de afwijsbrief als bijlage bij de bijbehorende StatusMelding via HDN te versturen. Er is een overgangsperiode tot HDN26 besproken om dit te ondersteunen. Afgesproken is dat partijen de periode tussen HDN25 en HDN26 dit kunnen inregelen. Dit betekend dat er gedurende deze periode twee processen actief zijn.

STAN-2361

Ter akkoord bij de werkgroep

OfferteAanvraag

Legitimatiegeslacht X generieke ondersteuning in OfferteAanvraag

Wijziging:

Het is niet meer toegestaan om regels te leggen op het veld Legitimatiegeslacht.

Samenvatting:

De werkgroep hypotheken is voor het generiek ontvangen van alle mogelijke waarden die aanwezig kunnen zijn bij het geslacht op het identiteitsbewijs. Het voorkomt dat een financieel adviseur voor een moeilijke keuze komt te staan wanneer een LegitimatieGeslacht ‘X’ niet kan worden meegegeven. Bovendien zijn, zodra de systemen de waarde 'X' voor LegitimatieGeslacht wel ondersteunen, dan al bekend welke consumenten dit betreft. Het volledig ondersteunen van alle waarden van Geslacht op het legimatiebewijs maakt geen onderdeel uit van deze wijziging, maar het kunnen ontvangen van deze informatie wel.

STAN-2360

Ter akkoord bij de werkgroep

OfferteAanvraag

Ondersteunen BAG-ID

Wijziging:

Er wordt een nieuw veld BagID* toegevoegd aan het schema onder Object.

Samenvatting:

Met het Bag-ID kan verschillende brondata worden geraadpleegd zoals, EP-online, KadastraleKaart, WOZ-waardeloket. Dit biedt aanbieders de mogelijkheid om versneld brondataprocessen te doorlopen en onderpanddata te verifiëren.

STAN-1402

Levenaanvraag

Serviceprovider toevoegen aan generiek schema

Wijziging:

De entiteit //Tussenpersoon/Serviceprovider/, met de daarin behorende velden Ref​Contact​Persoon​Data, ServiceproviderNaamen Service​Provider​A​F​M​Registratie​Nr, wordt toegevoegd aan het generieke berichtschema.

Samenvatting:

De entiteit Serviceprovider binnen Tussenpersoon was organisatiespeficiek en niet in lijn met de ketenafspraak: KET-001: Het doorgeven van intermediair en serviceprovider informatie en wijzigingen door tussenstations. Ook liep hier een serviceprovider tegenaan dat zij aanvragen niet volgens deze ketenafspraak konden doorsturen. Met deze wijziging wordt de inconsistentie gecorrigeerd.

STAN-915

Levenaanvraag

Structuurwijziging LevenAanvraag IdentificatieVerificatieJN

Wijziging:

Het veld IdentificatieVerificatieJN wordt verplaatst naar //PartijNAWData/Identificatie.

Samenvatting:

Het veld IdentificatieVerificatieJN was initieel geplaatst in de entiteit Tussenpersoon, echter kon de tussenpersoon hiermee niet aangeven voor elke aanvrager of de Identificatie is uitgevoerd. Door het veld te verplaatsen naar //PartijNAWData/Identificatie, kan per aanvrager aangegeven worden of de identificatie is uitgevoerd.

STAN-920

Levenaanvraag

DoelVerzekering generiek verplicht maken

Wijziging:

Het veld DoelVerzekering wordt generiek verplicht gemaakt binnen //FinancieleDekking/ProductCategorie/Overlijdensrisicoverzekering

Samenvatting:

Het veld DoelVerzekering is voor elke organisatie verplicht wanneer er sprake is van een overlijdensrisicoverzekering, daarom wordt deze nu in het basis berichtschema verplicht gemaakt.

STAN-1604

Levenaanvraag

Verwijderen niet gebruikte velden LevenAanvraag HDN25

Wijziging:

Verwijdering van niet gebruikte entiteiten en velden:

• //TekstRegels/ (gehele entiteit met onderliggende velden)

• HandenArbeidOmschr binnen //FinancieleDekking/ProductCategorie/Overlijdensverzekering/Verzekerde/

• OpleidingsNiveau binnen //FinancieleDekking/ProductCategorie/Overlijdensverzekering/Verzekerde/

• PctVerzekerdeDekking binnen //FinancieleDekking/ProductCategorie/Lastenverzekering/Verzekerde/VerzekerdeBedragen/

• RekenRentePct binnen //FinancieleDekking/ProductCategorie/Overlijdensrisicoverzekering/Verzekerde/VerzekerdeBedragen/

• VerplichtingInMnd binnen //FinancieleDekking/ProductCategorie/Kredietbeschermer/Verzekerde/VerzekerdeBedragen/

• EindDt binnen //FinancieleDekking/ProductCategorie/Kredietbeschermer/Verzekerde/VerzekerdeBedragen/

• Verzekerde binnen //FinancieleDekking/

• WWDekkingJN binnen //FinancieleDekking/Verzekerde/

• VerzekerdeBedragen binnen //FinancieleDekking/Verzekerde/

• SoortVerzekerdKap binnen //FinancieleDekking/Verzekerde/VerzekerdeBedragen/

• CodeUitkering binnen //FinancieleDekking/Verzekerde/VerzekerdeBedragen/

Samenvatting:

In het kader van dataminimalisatie wordt jaarlijks gekeken welke velden binnen berichtschema’s niet gebruikt worden.

STAN-719

LevenAanvraag

GeweigerdRedenOmschr en UitsluitingRedenOmschr in LevenAanvraag organisatiespecifiek maken

Wijziging:

De velden GeweigerdRedenOmschr en UitsluitingRedenOmschr worden organisatiespecifiek gemaakt.

Samenvatting:

Deze velden worden door veel partijen niet gebruikt. Daarnaast zijn dit vrije tekst velden die gevoelige data kunnen bevatten. Door de velden organisatiespecifiek te maken kan de aanbieder kiezen of hij deze velden wil ontvangen.

STAN-791

LevenAanvraag

Beschrijven attributen "Verplicht maken toestaan" Binnen PartijNAWData

Wijziging:

Verplicht maken toestaan wordt voor de volgende velden in de entiteit PartijNAWData in het schema uitgezet: VoorNamen, GeboorteAchternaam, GeboorteTussenvoegsels, CorrespondentieVoornaam , CorrespondentieNaam, CorrespondentieTussenvoegsels, Nationaliteit, GeboortePlaats, GeboorteLand, VoorLetters, GeboorteDt, HuisNrToevoeging, VoorTitel, RekeningNr, BedrijfsNaam en BurgerlijkeStaat.

Dit betekend dat het alleen mogelijk is om de volgende velden in de entiteit PartijNAWData te verplichten: Land, TelefoonNr en E-mailadres.

Samenvatting:

Het kunnen leggen van de restrictie op het schema vanuit een basisschema heeft als doel dat de kwaliteit van de berichtschema’s omhoog gaat. Afgelopen jaren hebben wij meermaals incidenten gehad waarbij invalide schema’s ontstonden door het verplichten van velden binnen de entiteit PartijNAWData. Daarom is nu kritisch gekeken welke velden binnen deze entiteit nooit verplicht kunnen zijn. Daarvoor wordt nu de restrictie ‘Verplicht maken toestaan’ uitgezet.

STAN-2094

LevenAanvraag

Optimalisatie van velden in de LevenAanvraag

Wijziging:

Het schema van de LevenAanvraag optimaliseren door de velden:

• DigitaleCommunicatieKlantJN en PremieDepotJN organisatiespecifiek te maken.

• PremieBetalingAan en PremieBetaalWijze te verwijderen.

• PremieBetaalWijze te vervangen door BetaalWijze. Deze wordt organisatiespecifiek en bevat de waardelijst BetaalWijzeType. Deze bevat de volgende waardes: 01 Incasso, 02 Overschrijven, 03 Acceptgiro, 04 Ideal.

Samenvatting:

In het kader van dataminimalisatie heeft de werkgroep Verzekeren gekeken welke velden niet (voor alle aanbieders) noodzakelijk zijn. Op basis daarvan worden enkele velden verwijderd of organisatiespecifiek gemaakt zodat de aanbieder zelf kan bepalen of deze het veld wil ontvangen.

STAN-2095

LevenAanvraag

Nieuwe verplichte velden in LevenAanvraag

Wijziging:

De volgende velden worden verplicht:

• StrafrechterlijkVerledenJN in //FinancieleDekking/ProductCategorie/Overlijdensrisicoverzekering/Verzekerde/Acceptatie/

• CodeWelkeVerzekeraar in //FinancieleDekking/ProductCategorie/Overlijdensrisicoverzekering/VerzekeringNemer/Geweigerd/

• MaatschappijPolisLopend en PolisNr in //FinancieleDekking/PolisLopend/

• HypotheekBedrag en PasseerDt in //Lening/

• DuurInMnd , LeningDeelBedrag, RentePct en AflossingsVorm in //Lening/Leningdeel

• LegitimatieSoort, LegitimatieGeslacht in //PartijNAWData/Identificatie

• ServiceProviderNr in //TussenPersoon/ServiceProvider

Samenvatting:

Er wordt regelmatig een LevenAanvraag verstuurd met lege entiteiten. Dit kan tot onverwachte fouten en onduidelijkheid leiden. Daarom wordt in de entiteiten minimaal 1 veld verplicht in niet verplichte entiteiten. Dit betekend dat wanneer de entiteit wordt opgenomen er een veld gevuld moet zijn.

STAN-1216

Statusmelding

Kenmerk verplichten bij statusmelding Polis Verzonden

Wijziging:

De entiteit //Status/Kenmerk wordt verplicht als //Status/LXBerichtStatusSpecificatie/StatusLXBericht heeft waarde (10 Levenaanvraag in behandeling genomen, of 08 Polis verzonden).

Deze afspraak wordt ook toegevoegd aan de ketenafspraak: https://hdn.atlassian.net/wiki/spaces/HW/pages/2558034003

Samenvatting:

Het is gewenst om altijd een kenmerk te ontvangen wanneer er een polis wordt verzonden. Daarom wordt het veld bij deze status verplicht gesteld.

STAN-567*

Ter akkoord bij de werkgroep

Waarborgbericht

LegitimatieGeslacht 'X' Waarborgbericht toevoegen

Wijziging:

Waarde 'X' in LegitimatieGeslacht wordt toegevoegd aan het berichtschema.

Samenvatting:

Met de HDN24 release wordt LegitimatieGeslacht ‘X' ondersteund binnen verschillende domeinen. Binnen het bankgarantie domein is deze wijziging nog niet doorgevoerd. Hiermee wordt LegitimatieGeslacht 'X’ ook ondersteund binnen het bankgarantie domein.

STAN-1025

Waarborgbericht

Bedrijfsnaam verplichten bij rechtspersonen

Wijziging:

BedrijfsNaam wordt toegevoegd aan de entiteit //PartijNAWData en deze wordt conditioneel verplicht als //PartijNAWData/SoortPartij heeft waarde (02 Rechtspersoon).

Samenvatting:

De BedrijfsNaam werd wanneer er sprake was van een rechtspersoon niet in alle gevallen meegegeven. Door BedrijfsNaam te verplaatsen en een regel te leggen, wordt dit opgelost.

STAN-988*

Ter akkoord bij de werkgroep

InformatieAanvraagbericht

Informatiebericht

Optionele of verwijderen klantdata in het Informatiebericht

Wijziging:

Informatieaanvraagbericht

Het veld GeboorteAchternaam wordt conditioneel verplicht als //PartijNAWData/SoortPartij heeft waarde (01 Natuurlijk persoon)

De velden Voornamen, CorrespondentieNaam, CorrespondentieTussenvoegsels, Voorletters, TelefoonNr en E-mailadres worden verwijderd uit het berichtschema.

Informatiebericht

Binnen de entiteit //PartijNAWData worden de velden Voornamen, GeboorteTussenvoegsels, CorrespondentieNaam, CorrespondentieTussenvoegsels, Voorletters, Straatnaam, HuisNr, HuisNrToevoeging, Postcode, Plaatsnaam, Land en RekeningNr verwijderd uit het berichtschema.

De entiteit //Leningdeel wordt opgehoogd naar 1-25 voorkomens.

Het veld LeningdeelIngangsDt wordt vervangen voor IngangsDt binnen de entiteit //Leningdeel

Samenvatting:

In relatie tot dataminimalisatie is een analyse gedaan van de berichten. Er is daarnaast gekeken naar consistentie van veldnamen en naar het aantal voorkomens van entiteiten zodat dit aansluit over de verschillende domeinen heen.

STAN-2045*

Ter akkoord bij de werkgroep

Informatiebericht

Informatiebericht uitbreiden met beheersignaal

Wijziging:

De entiteit //TekstRegels wordt toegevoegd, met daarin de velden TekstRegel, TekstRegel2, TekstRegel3, TekstRegel4, TekstRegel5.

Samenvatting:

Om de aanbieder de mogelijkheid te geven aanvullende informatie mee te sturen naar de adviseur voor adviesdoeleinden, vindt er een uitbreiding plaats.

STAN-1160*

Onderhanden in werkgroep

Informatiebericht

Tariefklasse wordt conditioneel verplicht veld

Wijziging:

De entiteit //Tariefklasse wordt conditioneel verplicht als //Hypotheek/Lening/Leningdeel/NHGJN heeft waarde (N Nee). De velden TariefklasseOndergrensPct en TariefklasseBovengrensPct worden verplicht.

Samenvatting:

Vorig jaar is deze optioneel gemaakt naar aanleiding van een incident wanneer er sprake was van een NHG hypotheek. Dat is door deze regel opgelost.

STAN-1179*

Onderhanden in werkgroep

Beheerverzoek

Uitbreiding t.b.v. Bouwdepot Declaraties

Wijziging:

Uitbreiden van de waardelijst BouwdepotType met de waarde 06 Verduurzaming.

Samenvatting:

De gebruiker van het beheerbericht heeft het verzoek gedaan om de waardelijst uit te bereiden met verduurzaming zodat alle benodigde data uitgewisseld kan worden.

STAN-1346*

Ter akkoord bij de werkgroep

BAsisreg.personenBERICHT studieleningBericht objectBerichtloonDIENSTinkomstenBerichtDIgitaleidentificatieberichtIVOAanvraageigenaarsinformatieBERICHT

Dataminimalisatie doormiddel van beperking op entiteiten Hypotheekgever & PartijNAWData

Wijziging:

Voorkomens van de entiteiten is aangepast naar 1-1.

• Hypotheekgever in het schema: BAsisreg.personenBERICHT / studieleningBericht / objectBericht / loonDIENSTinkomstenBericht / DIgitaleidentificatiebericht /IVOAanvraag

• PartijNAWData in het schema: BAsisreg.personenBERICHT / objectBericht / loonDIENSTinkomstenBericht/ eigenaarsinformatieBERICHT, met uitzondering van de IVOAanvraag deze is 1-2.

Samenvatting:

In verschillende bronberichten is het mogelijk om meer dan één keer de entiteiten Hypotheekgever en PartijNAWData door te geven. Aangezien een bronbericht alleen de gegevens van één persoon bevat, wordt het maximale aantal voorkomens beperkt. Dit voorkomt dat er ongewenst meer data wordt meegegeven.

STAN-2320

Voorafingev.aangiftebericht

Herinrichten schema VoorafIngevuldeAangiftebericht (VIA)

Wijziging:

Herinrichten van het schema:

• Verwijderen van de subentiteiten Hypotheekgever en Inkomsten en het veld //Bron/Hypotheekgever/RefPartijNAWData.

• Verplaatsen van het veld BelastingJaarVia en de subentiteit Vermogen naar de entiteit //Bron.

• Aanpassen van de minimale en maximale voorkomens van de entiteit PartijNAWData naar 1

Samenvatting:

Het schema wordt heringericht om het duidelijker te maken en in lijn te brengen met de standaard. Daarnaast wordt het aantal voorkomens van PartijNAWData op minimaal 1 gezet, zodat in het bronbericht altijd de persoonsgegevens van de aanvrager zijn opgenomen.

STAN-1349*

Ter akkoord bij de werkgroep

BAsisreg.personenBERICHT

Bronbericht BRP: Uitbreiden met ontbrekende velden en analyse toegevoegde waarde van het veld Land (partijNAW

Wijziging:

Het schema wordt uitgebreid met het veld Gemeente en SoortAdres in //Bron/PartijNAWData.

SoortAdres bevat de waardelijst SoortAdresType met de waardes 01 Woonadres, 02 Postadres en 03 Recreatie

Samenvatting:

Een gebruiker heeft gevraagd om de velden Gemeente en SoortAdres toe te voegen aan PartijNAWData waar het huidige adres van de aanvrager wordt vermeld. Deze informatie is benodigd en werd wel ontvangen bij het raadplegen van de bron direct en niet via HDN.

STAN-1040*

Ter akkoord bij de werkgroep

BAsisreg.personenBERICHTDIgitaleidentificatiebericht loonDIENSTinkomstenBericht objectBericht pensioenOverichtBericht studieleningBericht Voorafingev.aangiftebericht

DocSoort en SoortDocument scheiden

Wijziging:

• In de bronberichten BAsisreg.personenBERICHT, DIgitaleidentificatiebericht, loonDIENSTinkomstenBericht , objectBericht, pensioenOverichtBericht,studieleningBericht en Voorafingev.aangiftebericht wordt het veld DocSoort vervangen door SoortDocument.

• De volgende waardes worden verwijderd uit de waardelijst DocSoortType:
  26 vooraf ingevulde aangifte, 27 Kadastergegevens,100 Dataleverancier oorspronkelijke output , 101 UWV Verzekeringsbericht, 102 Mijnpensioenoverzicht, 103 BRP document opgesteld door dataleverancier , 104 DUO document opgesteld door dataleverancier , 105 Verificatie persoonsidentificatie, 106 Geverifieerde Koopovereenkomst en 107 Koopovereenkomst.

• De volgende waardes worden toegevoegd aan de waardelijst SoortDocumentType:
(code) Dataleverancier oorspronkelijke output, (code) Pensioenoverzicht,(code) BRP document opgesteld door dataleverancier, (code) DUO document opgesteld door dataleverancier, (code) Verificatie persoonsidentificatie,(code)Koopovereenkomst, (code) Inkomensverklaring,(code) Vooraf ingevulde aangifte, (code) Kadastergegevens.

• In het BAsisreg.personenBERICHT wordt het alleen mogelijk om bij SoortDocument de waardes: BRP document opgesteld door dataleverancier en (code) Dataleverancier oorspronkelijke output aan te leveren.

• In het DIgitaleidentificatiebericht wordt het alleen mogelijk om bij SoortDocument de waardes:(code) Verificatie persoonsidentificatie en (code) Dataleverancier oorspronkelijke output aan te leveren.

• In het loonDIENSTinkomstenBericht wordt het alleen mogelijk om bij SoortDocument de waardes: 263UWV Verzekeringsbericht en (code) Dataleverancier oorspronkelijke output aan te leveren.

• In het objectBericht wordt het alleen mogelijk om bij SoortDocument de waardes:(code) Kadastergegevens en (code) Dataleverancier oorspronkelijke output aan te leveren.

• In het pensioenOverichtBericht wordt het alleen mogelijk om bij SoortDocument de waardes:(code) Pensioenoverzicht en (code) Dataleverancier oorspronkelijke output aan te leveren.

• In het studieleningBericht wordt het alleen mogelijk om bij SoortDocument de waardes: (code) DUO document opgesteld door dataleverancier en (code) Dataleverancier oorspronkelijke output aan te leveren.

• In het Voorafingev.aangiftebericht wordt het alleen mogelijk om bij SoortDocument de waardes:(code) Vooraf ingevulde aangifte en (code) Dataleverancier oorspronkelijke output aan te leveren.

Samenvatting:

In de bronberichten wordt nu DocSoort gebruikt. DocSoort wordt gebruikt in het OfferteBericht als document dat de aanbieder verstuurd, terwijl SoortDocument gebruikt wordt in de documentberichten en de aan te leveren documenten betreft. In bronberichten gaat het om aan te leveren informatie. De huidige inrichting zorgt voor onduidelijkheid en een onjuiste inhoud van de waardelijst DocSoort. Daarom wordt het veld vervangen en de waardelijst bijgewerkt.

STAN-1037*

Analyse

Validatiemelding

Aanpassen XSDValidation (VX) ten behoeve van het toevoegen van brondata statusmeldingen

Wijziging:

De statusmeldingen worden uit de bron berichten gehaald en zullen op een andere manier verstuurd worden.

Samenvatting:

Statusmeldingen/validatiemeldingen zijn nu verweven in de bronberichten. Dit maakt het niet mogelijk om elementen in de berichtenstructuur van de bronberichten te kunnen verplichten. Om te zorgen voor een compleet bericht, is het noodzakelijk om de statusberichten uit het bronbericht te halen en los te versturen.

Analyse

Het wijzigingsverzoek is geprioriteerd en er wordt gewerkt aan een impactanalyse.

Onderhanden in werkgroep

Het wijzigingsverzoek is geprioriteerd, maar dat de uitwerking hiervan nog gedaan moet worden.

Ter akkoord bij de werkgroep

Het wijzigingsverzoek 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 redenen kan deze niet worden opgenomen in de release.