- Gemaakt door Agnes van Holten (Unlicensed), laatste wijziging op 12 feb. , 2023
- Tasks
Je bekijkt een oude versie van deze pagina. Bekijk de huidige versie.
Vergelijk met huidige Toon pagina geschiedenis
« Vorige Versie 6 Volgende »
Inleiding
Het verzekeringsproces omvat het gehele proces rondom het aanvragen van leven- en overlijdensrisicoverzekeringen. Het doel van het verzekeringsproces is op een efficiënte wijze, namelijk snel, veilig, accuraat en goedkoop, van verzekeringsaanvraag tot polis te komen. Het domein Verzekeren beheert de inhoud van het aanvraagbericht verzekeren (LX) en de ketenafspraken hieromtrent, evenals de aansluiting op de procesberichten (SX, OX, DA/DX). Hierin is een belangrijke rol weggelegd voor de Werkgroep Verzekeren.
Ketenafspraken
Financiële dekking
Bron middelen
Geldig vanaf
16 december 2021
Ketenafspraak
In het LX-bericht is het veld BronMiddelen geïntroduceerd. Hiermee kan worden aangegeven wat de herkomst van de middelen is waarvan de premie wordt betaald. Dit veld bevat de volgende mogelijke waarden:
Code |
01 Loon / pensioen / uitkering |
02 Inkomen uit eigen onderneming |
03 Spaargeld |
04 Inkomen uit vermogen of investeringen |
Aanleiding & achtergrond
In het kader van de Wwft is het van belang om te weten wat de bron is van inkomsten waarvan de premie wordt betaald.
Doel verzekering
Geldig vanaf
16 december 2021
Ketenafspraak
Met ingang van de HDN 21 Decemberrelease (16-12-2021) wordt het veld DoelVerzekering geïntroduceerd. Dit veld vervangt het veld VerzekeringsMotief en kent de volgende waardes:
Code | Omschrijving |
01 Hypotheek | Doel van de verzekering is om bij overlijden van de verzekerde de hypotheeklening af te lossen (al of niet verpand), waardoor de nabestaanden in het woonhuis kunnen blijven wonen. |
02 Verlies van inkomen (nabestaanden) | Doel van de verzekering is om bij overlijden van de verzekerde het verlies van inkomen op te vangen |
03 Compagnon | Doel van de verzekering is om bij overlijden van de verzekerde de aandeelhouders de mogelijkheid te geven de erfgenamen uit te kopen met de uitkering uit de verzekering . De overblijvende compagnons kunnen dan de onderneming voort zetten. |
04 Keyman/-woman | Doel van de verzekering is het beschermen van een bedrijf tegen financieel verlies veroorzaakt door overlijden van een persoon (de keyman of sleutelfiguur) die van essentieel belang is voor de onderneming. |
05 Afdekking erfbelasting | Doel is het verschaffen van financiële middelen om de erfbelasting te betalen. Omdat de nalatenschap vaak bestaat uit aandelen, onroerend goed en andere waardevolle bezittingen voorkomt deze verzekering dat de erven delen van de nalatenschap moeten verkopen om liquide middelen te krijgen om de erfbelasting te voldoen |
06 Fiscale claim bij overlijden | Doel van de verzekering is het verschaffen van financiële middelen om te voldoen aan de fiscale claim als het bedrijf niet door de kinderen worden voortgezet |
07 Financiering/kredietverstrekking | Doel van de verzekering is om een lening (geen hypotheek) te kunnen terug betalen. |
08 Lijfrente/aanvullend pensioen opbouw | Doel van de verzekering is de opbouw van kapitaal/vermogen met als doel de aankoop van een periodieke uitkering als aanvulling op het inkomen na pensionering/overbrugging |
Aanbieders moeten verzekeringsdoelen die zij niet ondersteunen, uitsluiten middels een conditie op het veld DoelVerzekering.
Aanleiding & achtergrond
In het kader van de Wwft is het van belang om zo duidelijk mogelijk aan te geven wat het doel en de aard van het sluiten van de verzekering moeten zijn. De huidige waardelijst VerzekeringsMotief is voor verschillende uitleg vatbaar. Om deze reden heeft is voorgesteld om aan te sluiten op de terminologie zoals gehanteerd wordt in wet – en regelgeving. Ook moet hierbij in de omschrijving ook een betekenis worden opgenomen in de documentatie.
Productcategorieën
Geldig vanaf
29 mei 2021 - HDN 21
Ketenafspraak
Binnen het LX-bericht worden vanaf HDN21 productcategorieën gehanteerd. In elk bericht moet een keuze gemaakt worden voor een productcategorie, aan de hand hiervan kunnen bepaalde door de aanbieder benodigde gegevens worden aangeleverd.
De productcategorieën zijn:
Lastenverzekering
Inkomensverzekering
Overlijdensrisicoverzekering
Kapitaalverzekering
Uitvaartverzekering
Kredietbeschermer
Aanleiding & achtergrond
Het LX-bericht is van oudsher vooral geënt geweest op het aanvragen van een overlijdenrisiscoverzekering. Door de jaren heen zijn er verschillende aanbieders bijgekomen en is het productenpalet ook uitgebreid en voor het aanvragen van deze nieuwe producten zijn ook toevoegingen gedaan aan het bericht, maar altijd binnen de bestaande structuur. Hierdoor is data soms op een onlogische plek geplaatst en zijn er ook gegevens die worden opgevraagd die niet in alle producten van toepassing zijn. Om deze reden is met HDN21 het LX-bericht opnieuw gestructureerd, waarin de gekozen productsoort de basis is van de aanvraag en aan de hand hiervan wordt bepaald welke data door de adviseur kan (en moet) worden aangeleverd.
Inkomen
Beroep
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.
Lening & Leningdelen
Hypotheekbedrag
Ketenafspraak
De algemene ketenafspraak met betrekking tot de definitie van het HypotheekBedrag is dat dit de optelling van alle leningdelen betreft, exclusief het overbruggingsbedrag.
Persoon
Voornamen en Correspondentie voornaam
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.
Fiscaal inwonerschap en belastingverplichting per aanvrager
Geldig vanaf
25 mei 2019 - HDN 19
Ketenafspraak
Deze ketenafspraak is van toepassing op Hypotheken (AX) en Verzekeren (LX).
FiscaalInwonerVanNederlandJN – sluit aan bij vraag 2a van het CRS-formulier. In AX is het een generiek veld, optioneel te vullen. In LX is het een maatschappij specifiek veld.
UitsluitendOfMedeFiscaalInwonerBuitenNedJN – sluit aan bij vraag 2b van het CRS-formulier. In AX is het een generiek veld, optioneel te vullen. In LX is het een maatschappij specifiek veld.
Entiteit FiscaleWoonstaat – in AX is deze conditioneel verplicht als UitsluitendOfMedeFiscaalInwonerBuitenNedJN = Ja (Update 14 jan 2019: Nee aangepast naar Ja). In de LX bestaat geen generieke conditie. De conditie die in AX aanwezig is moet in de LX door de aanbieder toegevoegd worden bij gebruik van het veld UitsluitendOfMedeFiscaalInwonerBuitenNedJN
Aanleiding & achtergrond
In het kader van de wet CRS/ Fatca moet het mogelijk zijn aan te geven of de aanvrager uitsluitend belastingplichtig is in Nederland en zo niet, wat zijn fiscale woonstaten zijn (dat kunnen er meerdere zijn) inclusief de daarbij horende TIN codes.
Geboortenaam en Correspondentienaam
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.
Offertebericht
Correspondentie voor het intermediair apart meegegeven in het Offertebericht (OX)
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.
Bevestiging medische acceptatie en/of polis per OX
Geldig vanaf
16 mei 2020 - HDN 20
Ketenafspraak
In alle gevallen waar een bevestiging van medisch akkoord als document wordt afgegeven moet dit document in een Offertebericht (OX) per HDN aan het intermediair verzonden worden.
Het soort document (OX.PrintDoc.DocSoort) dat dan meegegeven moet worden is [20 Acceptatiebevestiging verzekering].
Het kan voorkomen dat er geen medisch akkoord wordt afgegeven (omdat de polis meteen wordt opgemaakt).
In alle gevallen waar een polis als document wordt afgegeven moet dit document in een Offertebericht (OX) per HDN aan het intermediair verzonden worden.
Het soort document (OX.PrintDoc.DocSoort) dat dan meegegeven moet worden is [17 Polis].
Overig
Header optioneel
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.
Aanvraagvolgnummer en versienummer
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.
Proces
Lopende polissen
Geldig vanaf
21 mei 2022 - HDN 22
Ketenafspraak
Met betrekking tot lopende polissen geldt:
Ten eerste dat in geval van nieuwe aanvragen, uitsluitend indien er sprake is van het oversluiten van een lopende polis, in dit geval de entiteit PolisLopendJN en PolisLopend gebruikt worden
Daarnaast geldt dat het totale verzekerde kapitaal op leven van een verzekerde opgenomen blijft worden in de entiteit AndereOVR
Met ingang van HDN22 zijn daarbij de volgende verplichtingen komen te vervallen: binnen de entiteit PolisLopend zijn de velden PolisNr en MaatschappijPolisLopend niet langer verplicht.
Wijzigingen op lopende aanvragen
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.
Statusmelding
Statusmeldingen Verzekeren
Geldig vanaf
16 mei 2020 - HDN 20
Ketenafspraak
Verplichte statusmeldingen▪ 09 Levenaanvraag ontvangen
▪ 10 Levenaanvraag in behandeling
▪ 15 Gezondheidsverklaring verzonden
▪ 14 Gezondheidsverklaring ontvangen
▪ 08 Polis verzonden
▪ 13 Levenaanvraag niet te verwerken, zie toelichting
▪ 16 Levenaanvraag beëindigd, zie toelichting*
*Voor ‘SX16 Levenaanvraag beëindigd, zie toelichting’ geldt reeds de ketenafspraak dat in de tekstregels moet worden aangegeven waarom de aanvraag wordt beëindigd. Om deze afspraak af te dwingen worden de tekstregels verplicht gemaakt wanneer sprake is van SX16. De inhoudelijke vulling van de tekstregels is vrij te bepalen (geen waardelijst).
Betekenis, timing & frequentie per statusmelding
Tussenpersoon
Identificatie verificatie
Geldig vanaf
16 december 2021
Ketenafspraak
In het kader van de Wwft is het van belang dat de adviseur de identiteit van de klant(en) vaststelt en verifieert. Om deze reden wordt met ingang van de HDN 21 Decemberrelease (16-12-2021) het veld IdentificatieVerificatieJN toegevoegd onder Tussenpersoon in het LX-bericht. Dit veld geeft aan dat de adviseur verklaart de identiteit van de aanvrager(s) te hebben vastgesteld en deze identiteit te hebben geverifieerd conform de Wwft.
Tussenpersoon- en Serviceprovidergegevens
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;
Velden | Verplicht / optioneel |
|
Entiteit Tussenpersoon |
|
|
RefContactPersoonData | O | Niet muteren. |
Bedrijfsnaam | V | Niet muteren. |
TussenpersoonNr | V | Overschrijf het nummer dat hier gevuld staat met het nummer waaronder deze Tussenpersoon bekend is bij de Geldverstrekker waar de aanvraag heen gaat. |
AanvullendeVerzendwijze | O | Niet muteren. |
TelefoonNrWerk | V | Niet muteren. |
E-mailadres | O | Niet muteren. |
TelefoonNrMobiel | O | Niet muteren. |
AFMRegistratieNr | V | Niet muteren. |
Internetadres | O | Niet muteren. |
BeheerovereenkomstJN | O | Niet muteren. |
BeheerrelatieJN (beschikbaar per 01-07-2021) | O | Niet muteren. |
|
|
|
Entiteit Serviceprovider |
|
|
RefContactPersoonData | O | Optioneel te vullen. |
ServiceProviderNaam | V | Vullen. |
ServiceProviderNr | V | Vul hier het nummer waaronder de Serviceprovider bekend is bij de Geldverstrekker waar de aanraag heen gaat. |
TelefoonNrWerk | V | Vullen. |
TelefoonNrMobiel | O | Optioneel te vullen. |
E-mailadres | O | Optioneel te vullen. |
ServiceProviderAFMRegistratieNr | V | Vullen. |
Internetadres | O | Optioneel te vullen. |
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.
- Geen labels