🤝 Ketenafspraak

...

Tips (blok verwijderen in definitieve versie):

...

Puntsgewijs elk scenario afvangen

...

Geen HDN-versienummers en datums gebruiken, zodat ketenafspraak ook na die datum actueel oogt.

...

...

Reden waarom het een ketenafspraak is en geen conditie of omschrijving.

...

Oud: Voor voorkantpartijen: hoe moet worden omgegaan met verschillende scenario's? In welke gevallen moet welke data worden meegegeven? --> Liefst zoveel mogelijk afvangen met condities (zie boven). 

...

Oud: Voor aanbieders: hoe moeten partijen verschillende scenario's ondersteunen in het schema? Welke maatschappijspecifieke condities / uitsluitingen moeten in bepaalde gevallen worden gedaan (voor zover dit niet kan worden afgevangen met generieke condities)? Hoe herkent een voorkantpartij een wens om bepaalde gegevens wel / niet te ontvangen?

Vereisten voor Rol 1: Softwarepakketten (voorkant)

• In het geval van een

  Status
  colour Blue title OfferTeaanvraag (AX)

  moet het intermediar de mogelijkheid hebben een gewijzigde aanvraag in te dienen op een al eerder verstuurde aanvraag.

  • Een uitzondering hierop geldt als de HDN-versie waarop het oorspronkelijke bericht verstuurd is niet meer actief is

    • Voorbeeld: het is niet verplicht een wijziging op een HDN23.0 te ondersteunen wanneer de HDN 23.1 versie is ingegaan (en daarmee HDN 23.0 niet meer geldig is).

  • Hierbij moet rekening worden gehouden met de situaties waarin dit expliciet niet is toegestaan en die in Wijziging op lopende aanvragenzijn vastgelegd.

  • Bij het indienen van een wijziging op een aanvraag moeten de regels uit de ketenafspraak KET-XX 003 Het gebruik van requestversion in HDN-berichten worden opgevolgd.

Vereisten voor Rol 3: Tussenstations met aanpassingen

• In het geval van een

  Status
  colour Blue title OfferTeaanvraag (AX)

  moet een medewerker en/of intermediar de mogelijkheid hebben een gewijzigde aanvraag in te dienen op een al eerder doorgestuurde aanvraag.

  • Een uitzondering hierop geldt als de HDN-versie waarop het oorspronkelijke bericht verstuurd is niet meer actief is

    • Voorbeeld: het is niet verplicht een wijziging op een HDN23.0 te ondersteunen wanneer de HDN 23.1 versie is ingegaan (en daarmee HDN 23.0 niet meer geldig is).

  • Hierbij moet rekening worden gehouden met de situaties waarin dit expliciet niet is toegestaan en die in Wijziging op lopende aanvragenzijn vastgelegd.

  • Bij het indienen van een wijziging op een aanvraag moeten de regels uit de ketenafspraak KET-XX 003 Het gebruik van requestversion in HDN-berichten worden opgevolgd.

Aanleiding en achtergrond

Voor aanbieders in het Hypotheekproces is het wenselijk dat wanneer de aanvraag inhoudelijk niet sterk veranderd veel verandert (voor definitie zie Wijziging op lopende aanvragen), er een gewijzigde aanvraag wordt ingediend in plaats van een nieuwe aanvraag. Een gewijzigde aanvraag leidt niet tot een nieuw dossier en kan daardoor verder gaan in het proces welke al gestart is. Hierdoor kunnen al verzonden en ontvangen documenten gekoppeld blijven en blijft in veel gevallen ook de rentedatum in tact.

Om het hypotheekproces zo optimaal mogelijk te laten verlopen dient het intermediar dus in zijn pakket de mogelijkheid te hebben een nieuwe versie van een al verstuurde aanvraag op te sturen. Ook tussenstations die het recht hebben berichten aan te passen moeten dit kunnen aanbieden voor hun medewerkers en/of intermediar zodat ook hier geen onterecht nieuwe aanvragen worden verstuurd.

Er is een uitzondering toegevoegd in geval van het ingaan van een nieuwe HDN-versie. Hierin kunnen veel wijzigingen zitten, waardoor het voor Rol 1 en Rol 3 niet meer mogelijk is om een nieuwe versie aan te maken zonder daarbij (grote) wijzigingen voor de nieuwe HDN versie mee te nemen. Ook voor aanbieders die dit bericht zouden ontvangen is het dan lastig te zien wat de exacte wijzigingen zijn.