Geldig vanaf

May 29, 2021- HDN 21

 Ketenafspraak

• DocumentData

  • Kenmerk: De aanbieder stuurt zijn eigen kenmerk mee in dit bericht. Dit kan een leningnummer of een dossiernummer zijn. Deze mag niet overschreven worden door de intermediair. Dit veld geeft de aanbieder de mogelijkheid om ontvangen documentberichten te koppelen aan het dossier. De Intermediair die het DA bericht ontvangt geeft in zijn DX bericht altijd automatisch dit kenmerk mee.

  • ResponsOpBerichtSoort: Hier zal de aanbieder het bericht moeten noemen op basis waarvan het dossier opgebouwd is. Aangezien Documentenverkeer alleen binnen de hypotheek- en kredietdossiers gebruikt wordt zal hier dus respectievelijk AX danwel KX vermeld moeten worden.

  DocumentKenmerk

  • Aanlevermoment: De aanbieder kan aangeven op welk moment in het proces het betreffende document aangeleverd moet worden door het intermediair.

  • SoortDocument: De aanbieder dient ieder document, welke opgevraagd wordt bij het intermediair, te selecteren. Wanneer een nieuw stuk, welke in eerste instantie niet in het initiële DA bericht voorkwam, kan deze toegevoegd worden aan een nieuw DA bericht.

  • SoortDocumentOmschr: In dit veld dient de aanbieder verplicht zijn eigen benaming van het document mee te geven, zodat de vraag verduidelijkt wordt voor het intermediair De ontvangende partij dient vervolgens deze omschrijving ook verplicht te tonen aan de gebruiker en mee terug te geven (in het DX bericht) naar de aanbieder (de verzender van het DA bericht). Dit minimaliseert uitval in het proces en is essentieel.

  • SoortDocumentOmschrPortal: In het geval dat de Aanbieder, naast de communicatie met het intermediair, ook nog een (andere) omschrijving ten behoeve van de consument mee wil geven dan is dat mogelijk in dit veld. Dit veld zal door het ontvangende intermediair niet gezien worden. Omdat het hier gaat om de communicatie van de MidOffice van de Aanbieder naar de consumentenportal van de Aanbieder kan de Aanbieder hier zelf een keuze maken of dit veld gevuld wordt met een Code of met de uiteindelijke omschrijving zelf. Een code zou dan in de Portal gemapt kunnen worden naar de uiteindelijke omschrijving.

  • DocumentMijNr: De aanbieder stuurt per document een eigen kenmerk mee in het bericht. Hiermee kan bij ontvangst van een DX bericht een directe koppeling worden gelegd met het opgevraagde document. Deze mag niet overschreven worden door de intermediair. De Intermediair die het DA bericht ontvangt geeft in zijn DX bericht altijd dit kenmerk automatisch mee terug. Het DocumentMijNr moet uniek zijn binnen het DA-bericht en mag per opgevraagd document niet wijzigen gedurende het proces.

  • DocumentStatus: Dit is een voor de aanbieder verplicht veld, die de intermediair op de hoogte brengt van de voortgang van het dossier.

  • DocumentStatusOmschr: Het is mogelijk om eigen statusinformatie mee te geven bij een dossierstuk in het DA bericht, namelijk via <DocumentStatusOmschr>. Bij afkeuren en vervallen is dit verplicht. De omschrijving in <DocumentStatusOmschr> moet een toelichting zijn op de documentstatus.

  • DocumentStatusDt: De statuswijzigingsdatum dient te worden meegegeven in het bericht. Bij elke statuswijziging van een document dient dit veld te worden geüpdate.

  • DocumentStatusTijd: De statuswijzigingstijd dient te worden meegegeven in het bericht. Bij elke statuswijziging van een document dient dit veld te worden geüpdate.

  • UitersteAanleverdatum: De aanbieder kan in het bericht mee geven wat de uiterste aanleverdatum is van een dossierstuk. Dit element kan gekoppeld worden aan het workflowsysteem van de intermediair, welke een melding geeft indien deze (bijna) verstreken is.

  • BronNaam:

  • BronNr: Hierin kan een unieke identificatie van de bron worden opgenomen.

  • BestandsType: De aanbieder slaat de dossierdocumenten op. De aanbieder kan hier zelf zijn eigen voorkeur aangeven. De DX verzendende partij dient hier zich dan aan te conformeren.

  • RefPartijNawData: Om persoonsherkenning optimaal mogelijk te maken is de structuur voor personen gelijk getrokken aan die van het AX bericht.
    Persoonsherkenning is uiteraard alleen van belang als er meerdere aanvragers zijn. De rol van de personen kan in het dossier wisselend zijn en daarom is de referentie naar PartijNAWData een structurele oplossing. Voor het ene stuk is iemand hypotheekgever, maar voor het andere stuk verzekerde, contractant, rekeninghouder, borgsteller etc.Indien een dossierstuk niet te relateren is aan een persoon dan mag je het veld niet meegeven.De aanbieder is leidend en geeft dit aan middels de informatie in het DA bericht. Per stuk moet worden meegegeven voor welke persoon (aanvrager) het stuk wordt opgevraagd.  De documenten die als Persoonsgebonden aangemerkt kunnen worden zijn in dit overzicht te vinden Kijk voor de richtlijn hoe om te gaan met twee hypotheekgevers hier.

  • StatusKetenPartij: Het kan zijn dat tussen een aanbieder en intermediair een derde partij opereert die betrokken is bij de verzameling en beoordeling van de documenten. Indien dit het geval is kan de hierbij behorende beoordeling opgenomen worden in StatusKetenPartij.

  • Elementen ten behoeve van TaxCon: De toegevoegde elementen ten behoeve van het TaxCon-proces worden in een apart document beschreven. In het reguliere DA-DX berichtenverkeer zijn deze elementen niet van toepassing.

  • OntvangerNrTaxconRapport: Dit veld is toegevoegd voor “TaxCon” en is niet bedoeld voor regulier gebruik.

  • SoortBerichtType: Dit veld is toegevoegd voor “TaxCon” en is niet bedoeld voor regulier gebruik..

Versiebeheer