Geldig vanaf

26 mei 2018 - HDN 18

Ketenafspraak

Binnen HDN wordt gebruik gemaakt van een standaard classificatie van beroepen. Het gaat hier om de Beroepenindeling ROA-CBS (BRC 2014), een afgeleide van de  International Standard Classification of Occupations 2008 (ISCO 2008).

Deze indeling bestaat uit een viercijferige code gevolgd door een omschrijving en wordt onderhouden in de lijst BeroepType. De lijst zoals deze per HDN22 geldt is hier te raadplegen.

Geldig vanaf

16 mei 2020 - HDN 20

Ketenafspraak

Tijdens implementatie van inkomensbepaling loondienst (IBL) in de HDN Standaard is gebleken dat enkele aanbieders (nu nog) extra gegevens over de dienstbetrekking(en) in de hypotheekaanvraag, AX, willen ontvangen. Deze gegevens worden additioneel op de IBL-gegevens opgevraagd. De HDN Standaard ondersteunt drie varianten van Inkomensbepaling loondienst:

1. De aanbieder ondersteunt Inkomensbepaling loondienst in haar beleid. Gegevens over de dienstbetrekking worden uit de bewijslast herleid.

2. De aanbieder ondersteunt Inkomensbepaling loondienst in haar beleid. Gegevens over de dienstbetrekking worden uit de bewijslast herleid en in de hypotheekaanvraag (AX) opgevraagd.

3. De aanbieder heeft Inkomensbepaling loondienst (nog) niet opgenomen in haar beleid.

Onderstaand zijn deze varianten binnen de HDN Standaard toegelicht.

Ketenafspraak voor voorkantpartijen

Per HDN 20 is de ketenafspraak voor de Inkomensbepaling loondienst als volgt gedefinieerd.

• Wanneer de inkomensbepaling loondienst wordt gebruikt als onderbouwing van het inkomen, moet de entiteit InkomensbepalingLoondienst worden ingevuld. Deze entiteit is onderdeel van de generieke dataset en kan maximaal één keer per hypotheekgever worden ingevuld. In deze situatie mag de entiteit Dienstbetrekking (op het niveau direct onder Inkomen) niet meegegeven worden.

• Wanneer een maatschappij in de hypotheekaanvraag naast de IBL-gegevens ook gegevens over dienstbetrekking(en) wenst te ontvangen, is in de entiteit InkomensbepalingLoondienst de sub-entiteit Dienstbetrekking toegevoegd aan het schema. Deze sub-entiteit moet worden gebruikt voor de extra gegevens. Ook in deze situatie mag de entiteit Dienstbetrekking (op het niveau direct onder Inkomen) niet meegegeven worden.

• Wanneer een aanbieder de Inkomensbepaling loondienst (nog) niet accepteert, mag de entiteit InkomensbepalingLoondienst niet worden meegegeven. Deze wordt door de maatschappij uitgesloten middels de conditie ‘voorkomens gelijk aan 0’ op deze entiteit. Het inkomen dient te worden opgegeven in de entiteit Dienstbetrekking (op het niveau direct onder Inkomen).

De hypotheekaanvraag moet per persoon op één methode voor dienstbetrekking zijn gebaseerd: of het UWV-verzekeringsbericht of de werkgeversverklaring. Wanneer zowel een UWV-verzekeringsbericht als een werkgeversverklaring voor één persoon aanwezig is mag de werkgeversverklaring niet worden ingestuurd bij de hypotheekaanvraag. Combinaties van UWV-verzekeringsbericht en werkgeversverklaring zijn bij éénzelfde persoon niet toegestaan.

Voor het meesturen van de bewijslast worden de volgende documenttypen gehanteerd:

• Het documenttype ‘263 UWV Verzekeringsbericht’. Het eerder in gebruik genomen documenttype ‘260 UWV SV-loon document’ komt per HDN20 te vervallen.

• Documenttype ‘011 Laatste loonafrekening’ wordt gebruikt voor de salarisspecificatie.

NHG valideert de inkomensbepaling loondienst aan de hand van twee documenten: het UWV-verzekeringsbericht en de loonspecificatie(s).

Ketenafspraak voor aanbieders

Per HDN 20 is de ketenafspraak voor de Inkomensbepaling loondienst als volgt gedefinieerd.

• Wanneer de inkomensbepaling loondienst wordt gebruikt als onderbouwing van het inkomen, moet de entiteit InkomensbepalingLoondienst worden ingevuld. Deze entiteit is onderdeel van de generieke dataset en kan maximaal één keer per hypotheekgever worden ingevuld. In deze situatie mag de entiteit Dienstbetrekking niet meegegeven worden.

• Wanneer een maatschappij in de hypotheekaanvraag naast de IBL-gegevens ook gegevens over dienstbetrekking(en) wenst te ontvangen, moet in de entiteit InkomensbepalingLoondienst de sub-entiteit Dienstbetrekking worden toegevoegd met hierin de gewenste velden. Op deze wijze herkennen ketenpartijen deze extra wens.

• Wanneer een aanbieder de Inkomensbepaling loondienst (nog) niet accepteert, moet de entiteit InkomensbepalingLoondienst worden uitgesloten middels de conditie ‘voorkomens gelijk aan 0’ op deze entiteit. De conditie moet als volgt in de Beheertool worden ingericht:

• In de datacatalogus AX is ook het veld ‘SVLoon’ onder Dienstbetrekking beschikbaar. Dit veld is niet bedoeld voor een toetsinkomen op basis van IBL en het is voor aanbieders niet toegestaan om dit veld, zonder afstemming met HDN, toe te voegen aan hun schema.

Datacatalogus

De entiteit InkomensbepalingLoondienst bestaat uit de volgende velden:

• Toetsinkomen (datatype N12_2. Generiek verplicht. Conditie: ≥ € 0,-)

• AantalDienstbetrekkingen (datatype N2; generiek verplicht). Omschrijving is ‘Het aantal dienstbetrekkingen dat bijdraagt aan het opgegeven inkomen.’

• TotaalPensioenbijdrage (datatype N12_2. Generiek verplicht). Omschrijving is ‘Het totaal aan pensioenbijdrage per maand. Wanneer sprake is van meerdere dienstbetrekkingen moeten de pensioenbijdragne bij elkaar worden opgeteld en het totaal hier worden meegegeven. Een totaal van € 0,- is toegestaan. Het gaat hier specifiek om de werknemersbijdrage.’

Aanvullend hierop:

• De ingangsdatum van een dienstbetrekking en het aantal uren per maand zijn te herleiden uit (de xml van) het UWV-verzekeringsbericht. De mate van intentie is te herleiden uit het aantal arbeidsjaren bij iedere werkgever, inzichtelijk met het UWV-verzekeringsbericht. Hiermee hoeft geen extra informatie opgegeven te worden over wel of geen intentieverklaring. Hiermee is type dienstverband niet in gebruik in deze entiteit.

• Een UWV-verzekeringsbericht kan met een loonstrook gemapt worden o.b.v. naam, geboortedatum en loonheffingsnummer.

• De afgiftedatum, de datum waarop de data door de bron is vrijgegeven (‘BronAfgifteDt’), is gedefinieerd als kenmerk van het document en niet als kenmerk van de hypotheekaanvraag. Overeenkomstig met de geldigheidsdatum van een werkgeversverklaring als kenmerk bij documenten.
  Voor extra gegevens over dienstbetrekking(en) in de hypotheekaanvraag (AX), additioneel op stukken, kan de inrichting onder punt 2 worden overgenomen.

Eerdere versies

HDN19

Geldig vanaf

29 mei 2021 - HDN 21

Ketenafspraak

Correspondentie gericht aan het intermediair (distributiepartij) zal in het Offertebericht (OX) als bestand met een eigen label (DocSoort) meegegeven worden.

Aanleiding & achtergrond

Bij het versturen van bijv. een renteaanbod / offerte worden soms de correspondentie voor het intermediair en de correspondentie voor de klant in één bestand en met 1 label (DocSoort) meegegeven in het Offertebericht (OX). Denk aan de offerte en de voorbrief voor het intermediar.

Als het intermediair het rentevoorstel / offerte door wil sturen aan de klant zal hij/zij de correspondentie die voor hemzelf bedoeld is wellicht niet mee willen sturen.  Dat is erg lastig als deze correspondentie in 1 bestand wordt meegestuurd.

Geldig vanaf

29 mei 2021 - HDN 21

Ketenafspraak

In de volgende situaties verwacht de aanbieder altijd een nieuwe aanvraag en er mag dus geen gewijzigde versie van een eerder ingediende aanvraag (hetzelfde aanvraagvolgnummer met een hoger versienummer) worden ingediend. Er moet in deze gevallen een nieuwe aanvraag met een nieuw aanvraagvolgnummer worden ingediend.

• De aanvraag is in een eindstatus is terechtgekomen, dit is het geval wanneer:

  • De aanvraag definitief is beëindigd;
    Eén van de volgende SX-berichten is door de aanbieder verzonden:
    SX16 Offerteaanvraag beëindigd (Hypotheken)
    SX16 Levenaanvraag beëindigd (Verzekeren)
    SX06 Kredietaanvraag beëindigd (Kredieten)

  • Het dossier is in beheer genomen;
    Het bericht ‘SX20 Lening in beheer’ (Hypotheken) is door de aanbieder verzonden.

• De tussenpersoon wijzigt.
  Het veld TussenpersoonNr.

• De aanbieder wijzigt.
  Het veld OntvangerCode.

• De bindende offerte is uitgebracht en het onderpand wijzigt.Het bericht ‘SX23 Bindende offerte verzonden’ is door de aanbieder verstuurd en de gegevens in de entiteit Object wijzigen.

• De bindende offerte is uitgebracht en de productvorm wijzigt.Het bericht ‘SX23 Bindende offerte verzonden’ is door de aanbieder verstuurd en de productvorm wijzigt.

In alle andere gevallen moet de adviseur de mogelijkheid worden geboden om een wijziging door te voeren op de eerder ingediende aanvraag, tenzij dit niet mogelijk is door bijvoorbeeld een major schemawijziging.

Aanleiding & achtergrond

Op dit moment zijn er geen uniforme ketenafspraken over wanneer een aanbieder een wijziging op een lopende aanvraag verwacht of een geheel nieuwe aanvraag.  Hierdoor hanteren adviespakketten en hun adviseurs ook verschillende methodieken.
Door hierover eenduidige afspraken te maken, willen we duidelijkheid scheppen welke wijzigingen (automatisch) door de aanbieder kunnen worden verwerkt en waarvoor de adviseur dus een wijziging kan doorvoeren op het bestaande dossier. En in welke gevallen de aanbieder een geheel nieuwe aanvraag wenst en de adviseur hiervoor ook in zijn pakket voor een nieuwe aanvraag moet kiezen. Hierdoor scheppen we helderheid in wat adviseur en aanbieder van elkaar verwachten, verminderen we de uitval en het aantal dubbele aanvragen.

In deze eerste fase worden afspraken gemaakt over gevallen waarin de aanbieder altijd een nieuwe aanvraag verwacht. Dit omdat de wijzigingen zo groot zijn of zo laat in het proces plaatsvinden, dat een geheel nieuwe beoordeling noodzakelijk is en het niet wenselijk of niet mogelijk is om deze mutaties op het reeds lopende dossier door te voeren.

Er zijn in samenwerking met een subgroep van de Werkgroep Hypotheken 22 scenario’s beschreven die kunnen wijzigen tijdens het aanvraagtraject. Deze scenario’s zijn voorgelegd aan kennishouders van alle op HDN aangesloten aanbieders (inclusief servicers en een aantal midoffice-leveranciers) met de vraag of zij hierbij kunnen aangeven of zij in dit scenario een gewijzigde aanvraag verwachten of een geheel nieuwe aanvraag. Hierbij is ook gevraagd om, indien zij een geheel nieuwe aanvraag verwachten, een toelichting te geven met de achterliggende reden.
In een tweede deel van de uitvraag zijn verschillende processtappen benoemd en is de deelnemers gevraagd of zij per scenario kunnen aangeven of het antwoord dat zij eerder hebben gegeven bij de scenario’s, verandert als het proces een stap verder is.
Er is een analyse gedaan op de resultaten van de uitvraag. Hieruit is dit voorstel gekomen tot ketenafspraken, waarbij is gekeken naar een combinatie van de scenario’s en de processtappen waarin een groot deel van de aanbieders aangeeft een nieuwe aanvraag te wensen.

Geldig vanaf

16 mei 2020 - HDN 20

Hernieuwd kredietproces met introductie van een splitsing in blanco aanvraag, vooraanvraag en kredietaanvraag

Ketenafspraak

Intermediair:

Het intermediair heeft drie verschillende opties om een aanvraag via het HDN netwerk te versturen

• Blanco aanvraag

  • Als het intermediair de aanvraag zonder keuze voor een aanbieder richting de serviceprovider wil sturen

  • Het intermediair ontvangt als antwoord op deze blanco aanvraag, 1 of meerdere OX berichten met de mogelijkheden, en/of een SX bericht met een afwijzing.

  • In dit bericht hoeft geen ontvangercode en geen productcode (codekredietmij) te worden meegestuurd.

• Vooraanvraag

  • Als het intermediair direct bij een specifieke aanbieder de mogelijkheden terug wil stuurt hij een vooraanvraag

  • Het intermediair ontvangt als antwoord een OX bericht met daarin de mogelijkheden of een SX bericht met een afwijzing

• Contractaanvraag

  • Als het intermediair daadwerkelijk een bepaalde aanvraag wil doen dan stuurt hij een contractaanvraag

  • Als antwoord op deze contractaanvraag ontvangt hij een contract(OX) of een SX bericht met een afwijzing

Service provider

De service provider kan 3 verschillende berichten ontvangen en 2 verschillende berichten doorsturen richting de aanbieders

• Blanco aanvraag

  • De ontvangen aanvraag kan worden doorgestuurd richting de verschillende aanbieders (vooraanvraag/contractaanvraag), hiervoor moet in ieder geval de ontvangercode + productcode worden gevuld

  • De serviceprovider zal voor elk bericht wat hij doorgestuurd heeft naar de aanbieder een SX (afwijzing) of een OX ontvangen (met daarin de matrix met opties en/of een contact)

• Vooraanvraag

  • De ontvangen aanvraag kan worden doorgestuurd richting de specifieke aanbieder

  • De serviceprovider zal voor elk bericht wat hij doorgestuurd heeft naar de aanbieder een SX (afwijzing) of een OX ontvangen (met daarin de matrix met opties en/of een contact)

• Contractaanvraag

  • De ontvangen aanvraag kan worden doorgestuurd richting de specifieke aanbieder

  • De serviceprovider zal voor elk bericht wat hij doorgestuurd heeft naar de aanbieder een SX (afwijzing) of een OX ontvangen (met daarin de matrix met opties en/of een contact)

Aanbieder

De aanbieder kan 2 soorten berichten ontvangen

• Vooraanvraag

  • De ontvangen aanvraag kan worden doorgestuurd richting de specifieke aanbieder

  • De serviceprovider zal voor elk bericht wat hij doorgestuurd heeft naar de aanbieder danwel een SX (afwijzing) danwel een OX ontvangen (met daarin de matrix met opties en/of een contact)

• Contractaanvraag

  • De ontvangen aanvraag kan worden doorgestuurd richting de specifieke aanbieder

  • De serviceprovider zal voor elk bericht wat hij doorgestuurd heeft naar de aanbieder danwel een SX (afwijzing) danwel een OX ontvangen (met daarin de matrix met opties en/of een contact)

Algemene punten

• Als een aanvraag als blanco aanvraag ingediend wordt en de serviceprovider de aanvraag doorstuurt zal de versie van de aanvraag 1 blijven

• Als eerst een vooraanvraag wordt gedaan en vervolgens met dezelfde gegevens een contractaanvraag zal het versienummer opgehoogd worden met 1

• Voor een aanvraag wordt hetzelfde aanvraagvolgnummer gebruikt

• In de OX en SX kan het BKR resultaat worden teruggekoppeld

Geldig vanaf

15 oktober 2016 - HDN 18

Ketenafspraak

• De voorkant (adviesapplicaties) vullen de entiteit TussenPersoon met de tussenpersoon waarmee de klant contact heeft;

• De service providers mogen deze gegevens niet aanpassen (m.u.v. het TussenpersoonNr*) en voegen de eigen gegevens toe in de nieuwe entiteit ServiceProvider;

In het geval dat een aanbieder niet werkt met Tussenpersoon- Serviceprovidernummers kan in beide velden een dummy waarde gevuld worden.
In het geval dat een aanbieder werkt met maar 1 aanstellingsnummer dan mag in beide velden dit aanstellingsnummer gevuld worden.

Wanneer meerdere partijen/ serviceproviders tussen het klantcontact en de geldverstrekkers binnen de keten aanwezig zijn overschrijft de serviceprovider de al aanwezige gegevens in de entiteit ServiceProvider. De aanbieder ontvangt zodoende altijd de partijgegevens waarvan de aanvraag wordt ontvangen.

*) het TussenpersoonNr is, in het geval de aanvraag via een ServiceProvider wordt verzonden, niet altijd bekend bij de Tussenpersoon, maar wel bij de ServiceProvider. Deze mag het door de Tussenpersoon gevulde TussenpersoonNr dus overschrijven met het nummer waaronder de betreffende Tussenpersoon bekend is bij de ontvanger van de aanvraag.

Aanleiding & achtergrond

De Mortgage Credit Directive (MCD) (ingang 14 juli 2016) stelt dat de tussenpersoon, waarmee de klant contact heeft, bekend moet zijn; ook bij de geldverstrekker. De werkwijze vóór de MCD week hiervan af: wanneer de aanvraag via een serviceprovider liep, werden de gegevens van de tussenpersoon (het klantcontact) overschreven met die van de serviceprovider. Dit is niet meer toegestaan met de introductie van MCD.

Geldig vanaf

29 mei 2021 - HDN 21

Ketenafspraak

Er zijn drie mogelijke entiteiten om lasten van een aanvrager door te geven. Elke entiteit kent een eigen waardelijst waarin de aard van de last wordt gespecificeerd en hiernaast kunnen verschillende gegevens worden doorgegeven.

1. Geregistreerde leningen; hieronder vallen leningen die bij het BKR geregistreerd kunnen staan. Dit wordt gespecificeerd in de lijst GeregistreerdeLeningType:
   AK Aflopend kredietRK Doorlopend krediet*HY Hypothecair krediet eigen woningHO Hypothecair krediet overige onroerende zakenRH Restschuld zonder aanspraak op NHGRN Restschuld met aanspraak op NHGOA Operational AutoleaseRO Overige financiële verplichtingenZK Zakelijk kredietZO Zakelijk overige financiële verplichtingen

2. Overige leningen; hieronder vallen leningen die niet bij BKR geregistreerd kunnen staan. Dit wordt gespecificeerd in de lijst OverigeLeningType:
   01 Lening bij werkgever02 Studielening03 Studievoorschot04 Lening bij derden

3. Verplichtingen; hieronder vallen overige verplichtingen die géén lening betreffen.
   03 Pensioenpremie t.l.v. partij06 Alimentatieverplichting t.g.v. kinderen07 Alimentatieverplichting t.g.v. partner11 Bruto huurlasten17 Betalingsregeling18 Kinderopvang19 Bijdrage VVE20 Servicekosten99 Overig

*In geval van een RK Doorlopend krediet dient uitsluitend  het veld LimietDoorlopendKrediet gevuld dient te worden. Het is namelijk niet gewenst om het veld OorspronkelijkeLening te ontvangen in de situatie van een Doorlopend Krediet (geldig vanaf HDN22, mei 2022)

Studieleningen

Met ingang van HDN 22 is er rondom studieleningen en -voorschotten een toevoeging opgenomen in het AX bericht. Met de introductie van het veld StudieLeningInventarisatie dient verplicht te worden opgegeven of de inventarisatie cq navraag naar een studieschuld heeft plaatsgevonden en met welk resultaat. In geval van een aanwezige studielening en/of -voorschot is het opvoeren hiervan verplicht. Zie voor een nadere achtergrond bij dit onderwerp deze OnePager

Aanleiding & achtergrond

Voor het doorgeven van lasten werd voorheen de entiteit ‘Verplichtingen’ gebruikt. Met deze inrichting kon bij alle verplichtingsoorten dezelfde set aan velden worden meegegeven terwijl dit in veel gevallen niet relevant was (i.e. alle velden die samenhangen met een lening zijn niet van toepassing bij alimentatie of pensioenpremie). De keuzelijst die bestond was hierdoor ook hybride. Er was behoefte om hier een duidelijker onderscheid in te maken alsmede een mogelijkheid te introduceren om BKR krediettypes te gebruiken, zodat hiervoor door de hele keten heen dezelfde codes kunnen worden gehanteerd. Per HDN21 is om deze reden de splitsing gemaakt zoals hierboven weergegeven.

Met de splitsing van het typen verplichtingen is ook een mappingtabel beschikbaar gemaakt die een richtlijn geeft voor de vertaling van de ‘oude’ verplichtingtypes naar de drie nieuwe waardelijsten. Deze mappingtabel is hier te raadplegen.

Voor wat betreft alimentatieverplichtingen is de algemene waarde 01 Alimentatie komen te vervallen, waarvoor de specifieke waardes 06 en 07 voor alimentatie t.b.v. kinderen resp. ex-partner zijn geintroduceerd.

Geldig vanaf

29 mei 2021 - HDN 21

Ketenafspraak

Er zijn drie mogelijke entiteiten om lasten van een aanvrager door te geven. Elke entiteit kent een eigen waardelijst waarin de aard van de last wordt gespecificeerd en hiernaast kunnen verschillende gegevens worden doorgegeven.

1. Geregistreerde leningen; hieronder vallen leningen die bij het BKR geregistreerd kunnen staan. Dit wordt gespecificeerd in de lijst GeregistreerdeLeningType:
   AK Aflopend kredietRK Doorlopend krediet*HY Hypothecair krediet eigen woningHO Hypothecair krediet overige onroerende zakenRH Restschuld zonder aanspraak op NHGRN Restschuld met aanspraak op NHGOA Operational AutoleaseRO Overige financiële verplichtingenZK Zakelijk kredietZO Zakelijk overige financiële verplichtingen

2. Overige leningen; hieronder vallen leningen die niet bij BKR geregistreerd kunnen staan. Dit wordt gespecificeerd in de lijst OverigeLeningType:
   01 Lening bij werkgever02 Studielening03 Studievoorschot04 Lening bij derden

3. Verplichtingen; hieronder vallen overige verplichtingen die géén lening betreffen.
   03 Pensioenpremie t.l.v. partij06 Alimentatieverplichting t.g.v. kinderen07 Alimentatieverplichting t.g.v. partner11 Bruto huurlasten17 Betalingsregeling18 Kinderopvang19 Bijdrage VVE20 Servicekosten99 Overig

*In geval van een RK Doorlopend krediet dient uitsluitend  het veld LimietDoorlopendKrediet gevuld dient te worden. Het is namelijk niet gewenst om het veld OorspronkelijkeLening te ontvangen in de situatie van een Doorlopend Krediet (geldig vanaf HDN22, mei 2022)

Aanleiding & achtergrond

Voor het doorgeven van lasten werd voorheen de entiteit ‘Verplichtingen’ gebruikt. Met deze inrichting kon bij alle verplichtingsoorten dezelfde set aan velden worden meegegeven terwijl dit in veel gevallen niet relevant was (i.e. alle velden die samenhangen met een lening zijn niet van toepassing bij alimentatie of pensioenpremie). De keuzelijst die bestond was hierdoor ook hybride. Er was behoefte om hier een duidelijker onderscheid in te maken alsmede een mogelijkheid te introduceren om BKR krediettypes te gebruiken, zodat hiervoor door de hele keten heen dezelfde codes kunnen worden gehanteerd. Per HDN21 is om deze reden de splitsing gemaakt zoals hierboven weergegeven.

Met de splitsing van het typen verplichtingen is ook een mappingtabel beschikbaar gemaakt die een richtlijn geeft voor de vertaling van de ‘oude’ verplichtingtypes naar de drie nieuwe waardelijsten. Deze mappingtabel is hier te raadplegen.

Voor wat betreft alimentatieverplichtingen is de algemene waarde 01 Alimentatie komen te vervallen, waarvoor de specifieke waardes 06 en 07 voor alimentatie t.b.v. kinderen resp. ex-partner zijn geïntroduceerd.

Geldig vanaf

29 mei 2021 - HDN 21

Ketenafspraak

In de HDN Standaard kennen we de volgende velden omtrent de voornamen van een natuurlijk persoon:

• VoorNamen; de verzameling namen die aan de geboortenaam voorafgaat. Alle voornamen moeten, gescheiden door spaties, worden opgegeven zoals op het identificatiebewijs van de persoon is vermeld.

• CorrespondentieVoornaam; de voornaam waarmee iemand wordt aangesproken.

Aanleiding & achtergrond

Het wordt steeds belangrijker dat aanvragers zo vroeg mogelijk in het proces juist geïdentificeerd kunnen worden. Het ontvangen van de volledige voornamen in het begin van de keten kan daarbij helpen zodat het overeenkomt met data die later in het proces ontvangen voor de identificatie van de klant; wanneer dit b.v. vanuit een externe bron afkomstig is kan het direct worden gematcht.

Om deze reden is per HDN21 ‘Voornamen’ leidend, waarin de volledige voornamen van een personen kunnen worden opgegeven. Voor eventuele correspondentie kan een enkele voornaam worden doorgegeven in het veld ‘CorrspondentieVoornaam’. Het veld ‘Voornaam’ komt per HDN21 hiermee te vervallen.

Geldig vanaf

25 mei 2019 - HDN 19

Ketenafspraak

Wanneer geboortenaam en correspondentienaam gelijk zijn, mag geen correspondentienaam worden meegegeven. CorrespondentieNaam mag alleen gevuld worden als deze afwijkt van de geboortenaam.

Geldig vanaf

13 mei 2023

Ketenafspraak

Op het moment dat de partij nog aangesloten is op de API V1 dient de Header gevuld te worden. Wanneer deze over is op API V2 hoeft deze niet meer gevuld te worden. Berichten zullen gevalideerd worden op het platform. Mocht u dan ook nog niet over zijn op API V2, maar de Header niet gevuld hebben, zal het bericht worden afgekeurd.

Aanleiding & achtergrond

Voor doorontwikkeling van het platform en de mogelijkheden hieromtrent komt er een API V2 versie beschikbaar waarin stuurinformatie (Header) gescheiden wordt van berichtinformatie (Overige entiteiten). De Header informatie zal in JSON format meegegeven gaan worden in het bericht. In verband met de gefaseerde overgang naar de API V2 zal de Header tijdelijk optioneel worden gemaakt.

Ketenafspraak

Applicaties moeten juist omgaan met het aanvraagvolgnummer en versienummer uit de HDN header:

• Het aanvraagvolgnummer dient een uniek kenmerk te zijn. Het dient zo opgesteld te worden dat doublures op het HDN platform uitgesloten worden.

• Dezelfde (inhoudelijke) aanvraag naar verschillende ontvangers zal dus per ontvanger een ander aanvraagvolgnummer moeten hebben.

• Het unieke aanvraagvolgnummer van een aanvraagbericht dient door de gehele keten heen te worden gebruikt, wat inhoudt dat alle berichten in het proces hetzelfde aanvraagvolgnummer hanteren. Dit aanvraagvolgnummer zal bij het eerste aanvraagbericht (intermediair) gegenereerd worden. Tussenschakels in de keten mogen dit niet aanpassen. Ook opvragingen bij een bron zullen met hetzelfde aanvraagvolgnummer moeten gebeuren.

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

• Het opvragen van actuele hypotheekdata middels een IA-bericht wordt gezien als een nieuw aanvraagbericht. Hier moet dus een nieuw aanvraagvolgnummer voor gegenereerd worden. Reactie op dit bericht middels een status- of IX-bericht moet hetzelfde aanvraagvolgnummer als het aanvraagbericht (IA) hebben.

Geldig vanaf

21 mei 2022 - HDN 22

Aanleiding & achtergrond

Met ingang van de nieuwe release introduceren we een statusflow voor Kredieten met verplichte statusmeldingen en bijbehorende ketenafspraken. De volgende statussen worden geïntroduceerd:

– 01 Kredietaanvraag ontvangen

– 03 Kredietaanvraag niet te verwerken, zie toelichting

– 05 Kredietaanvraag afgewezen

– 08 Dossier finaal akkoord