Hypotheken Data Netwerk

Transcriptie

1 Hoogoorddreef BA Amsterdam ZO t f Handboek HDN Certificering 2015 Periode 1 januari december 2015 voor HDN Gebruikers Januari 2015, versie 1.0

2 Handboek HDN Certificering Voorwoord Inleiding Doel certificeren Welke partijen moeten zich certificeren? Wat valt er binnen de certificering? Wanneer moet een partij zich certificeren? Organisatie en procedures Organisatie van HDN Zelfevaluatie Procedures certificering Initiële of applicatie gebonden certificering Reguliere certificering Aantekenen van bezwaar Kosten Beschikbaar stellen applicatie generieke applicaties Certificeringvereisten Functionele eisen Technische eisen Juist gebruik HDN Berichten Aanvullende informatie Contact Belangrijke documenten

3 Bijlage 1) Eisen certificering Aanbieders Bijlage 2) Eisen certificering Intermediaire Organisaties en/of applicaties Bijlage 3) Validatieregels

4 Voorwoord In de markt ervaren circa 3800 intermediairs, 30 maatschappijen, 28 service providers en ketens en de meest gebruikte software leveranciers dagelijks de toegevoegde waarde van het werken met HDN. HDN is hiermee de breedst gedragen standaard binnen de financiële dienstverlening. Alle organisaties die communiceren via de door HDN geboden technische omgeving dienen gecertificeerd te zijn. Berichten vanuit een niet gecertificeerde bron mogen niet verzonden worden over het HDN Platform. Dit HDN Handboek Certificering 2015 beschrijft de wijze waarop certificering plaatsvindt. De belangrijkste verschillen met de vorige versie van het handboek zijn: Procedures en functionele certificeringseisen duidelijk gescheiden o Zuiver de certificeringsprocedure beschreven in hoofdstuk 2.3; o De functionele eisen in hoofdstuk 3.1 beschreven en in Bijlage 1 en 2 herzien; Verbreding in toetsing op gebruik HDN Berichten o o o o Voorschrijven van verplichte statusberichten; Inzichtelijk krijgen in gebruik offertedata bij adviespakketten DA/DX mappingstabel aanleveren door aanbieders Meer focus op synchronisatie tussen berichten (bijv. OX en DA bericht) Verruiming technische analyses o Productiegegevens (hitratio s en berichtinhoudelijk) o Technische informatie rondom servers en calls Voor de actuele versie van dit Handboek en andere formele HDN documenten kunt u terecht op Indien u vragen heeft, kunt u contact opnemen met HDN Beheer via info@hdn.nl. HDN Beheer December

5 1. Inleiding 1.1. Doel certificeren De Coöperatieve Vereniging HDN Beheer B.A. (HDN) stelt zich als doel het faciliteren van informatie-uitwisseling in de hypotheek waardeketen. HDN biedt de voorzieningenn die zorg dragen voor een optimale uitwisseling (betrouwbaar en veilig) van de informatie (volledig en correct) tussen intermediair en aanbieder. Het doel van certificering is het bieden van garanties voor de hele keten voor een betrouwbaree en efficiënte communicatie. Certificering van de in dit proces gebruikte systemen is een voorwaarde voor het verkrijgen en behouden van het digitale certificaat waarmee men toegang verkrijgt tot de technische omgeving van HDN. Indien een partij haar certificering kwijt raakt zal het digitale certificaat worden terug getrokken en is deze partij vanaf dat moment niet meer in staatt via de HDN infrastructuur berichten uit te wisselen. De procedure die hieraan voorafgaat, staat beschreven in hoofdstuk 2. Elke partij die met behulp van HDN wil communiceren, moet daarom gebruik maken van gecertificeerde software. Dit waarborgt efficiënte en betrouwbaree communicatie tussen de gebruikers van HDN. Daarnaast zijn er nog andere voordelen voor HDN deelnemers verbonden aan certificering: In de HDN communicatie, waaronder in ieder geval op zal een opsomming van gecertificeerde pakketten, intermediaire organisaties en aanbieders worden gepubliceerd. Aanbieders zullen van gecertificeerde pakketten berichten ontvangen en zullen worden aangemoedigdd afspraken te maken met deze softwarehuizen ten aanzien van de inregeling van producten wat de STP graad bevordert. Leveranciers van gecertificeerde pakketten en gecertificeerde aanbieders krijgen inspraak in de verderee uitbreiding of aanpassing van de HDN dienstverlening. Er vindt afstemming plaats tussen de HDN Helpdesk en de Helpdesk van gecertificeerdee organisaties. Bij problemen kan ondersteuning worden verleend of naar de juiste contactpersonen worden verwezen. Gecertificeerdee deelnemers kunnen gebruik maken van het HDN Keurmerk ter profilering van de eigen organisatie. Gecertificeerdee gebruikers hebben toegang tot de HDN Beheertool waarin altijd de laatste generieke en maatschappij specifieke schema s alsmede wijzigingsdocumenten te vinden zijn. De HDN Beheertool verzendt notificaties aan deze gebruikers bij wijzigingen Welke partijen moeten zich certificeren? De HDN standaard is een beschermdee standaard. Dit betekent dat gebruik van de standaard gereguleerd en bewaakt wordt door de vereniging. Verder houdt dit in dat de applicaties van alle partijen die gebruik maken van het HDN platform gecertificeerd dienen te worden. Hieronder een uitsplitsing van de diverse partijen: 5

6 Aanbieders die gebruik maken van de HDN standaard en communiceren via de technische omgeving van HDN, met de door HDN geleverdee communicatiesoftware. Indien een aanbieder zijn geautomatiseerde verwerking heeft uitbesteed aan een servicer wordt de certificering verstrekt aan de aanbieder, welke immers lid en afnemer is van de HDN dienstverlening; Intermediaire organisaties (ketens en service providers) die in hun adviessoftware gebruik maken van de HDN standaard en communiceren via de technische omgeving van HDN, met de door HDN geleverde communicatiesoftware (HDN Enterprise); Softwarehuizen die generieke of single-label adviessoftware gebaseerd op het HDN protocol leveren aan tussenpersonen, die met de communicatiemodulee HDN Basic of HDN Enterprise direct verbonden zijn aan de technische omgeving van HDN 1 1 ; Organisaties anders dan hierboven, die door middel van extranetten, portals of netwerkenn of software gebruik maken van het HDN protocol om te communiceren met bij HDN aangesloten partijen; 1.3. Wat valt er binnen de certificering? De certificering is niet versie gebonden. Dit heeft te maken met de ingangsdatum van de set aan HDN berichten. Dit betekent dat de versie die gecertificeerd wordt, afhankelijk is van de datum in het jaar dat de partij gecertificeerd wordt. Ieder bericht wat gebruikt maakt van HDN Communicatie Software zal gecertificeerd moeten worden. De certificering is wel applicatie gebonden. Dit betekent dat op het moment dat een applicatie wordt vervangenn of significant wordt aangepast (op het gebied van HDN), de nieuwe applicatie opnieuw moet worden gecertificeerd. Tevens zal een applicatie die door verschillende marktpartijen wordt gebruikt, per HDN gebruiker, dan wel HDN lid worden gecertificeerd om zo maatwerkfunctionaliteitenn niet uit te sluiten. Vanaf 2014 is er een extra deel aan de certificering toegevoegd. Binnen de certificering zal elke partij een Zelfevaluatie m.b.t. HDN binnen de organisatie dienen in te vullen voorafgaand aan de certificeringstest. Deze Zelfevaluatie is eenmaal in de 2 jaar onlosmakelijk verbonden aan de certificering en zal volledig ingevuld dienen te worden om te kunnen starten en uiteindelijk tot afronding van de certificering te komen. Nieuwe toetredende partijen op het HDN platform zullen de Zelfevaluatiee na het eerste jaar van toetreding invullen. Meer informatie staat in hoofdstuk Wanneer moet een partij zich certificeren? Er zijn verschillende momenten waarop er gecertificeerd moet worden. 1. Ten eerste zal, om gebruik te kunnen maken van HDN, een nieuwe bij HDN aangesloten partij, zich moeten laten certificeren. Pas na certificering kan de partij starten met communiceren via HDN. De tijdslijnen hiervoor zijn dat een aan te sluiten partij zich tijdig voor livegangg bij HDN meldt, waarbij minimaal 2 weken voor geplande livegang de certificering opgestart is. 2. Het tweede en doorlopende moment is na de initiële certificering. Dan zullen de gecertificeerde partijen maximaal één keer per jaar de certificeringprocedure moeten doorlopen. 1 Softwareleveranciers die applicaties leveren die een interface hebben met gecertificeerde software (bijv. workflow management software of financiële planning software) en hiervoor het HDN protocol gebruiken, wordt dringend geadviseerd zich aan te sluiten bij HDN en gebruik te maken van de meest recente versie van het protocol om problemen voor de gelieerde software te voorkomen. Zij hoeven zich echter niet te certificeren. 6

7 Bij vervanging van een gecertificeerde applicatie (mid-office, advies applicatie). Bij het in gebruik nemen van één of meer secundaire sets berichten. In overeenstemming met HDN wordt besloten of het proces c.q. de applicatie voor aanvang van de productie gecertificeerd dient te worden of dat dit tijdens de eerstvolgende reguliere certificering kan plaatsvinden. Indien HDN Beheer een gegronde klacht ontvangt van partijen die trachten elektronische communicatie tot stand te brengen met bijvoorbeeld een aanbieder, intermediaire organisatie of gebruikers van een specifiek systeemhuis, zal HDN Beheer in samenwerking met die partij opnieuw een test doorlopen om problemen op te sporen en op te lossen. De procedures en vereisten van de momenten van certificering zullen worden uiteengezet in respectievelijk hoofdstuk 2 en 3. 7

8 2. Organisatie en procedures 2.1. Organisatie van HDN In tegenstelling tot het verleden is de Werkgroep Beleidsadviescommissie (BAC) niet meer actief betrokken bij de certificering van de aangesloten partijen. De HDN Directeur heeft het toezicht op de uitvoering van de HDN certificering en is daarmee zelfstandig besluitvormend in het oordeel van certificering. De HDN Directeur Heeft de actieve besluitvorming van het verstrekken of afwijzen van certificering gedelegeerd naar HDN Beheer; Neemt bij twijfel besluiten op basis van de door HDN Beheer en de partij aangeleverde informatie; Behandelt bezwaren over intrekking van de certificering; Doet een review op alle documentatie die ten grondslag ligt aan de certificering. Indien de HDN Directeurr en de te certificeren partij het niet eens worden tijdens de voornoemdee bezwaarprocedure, kan de partij bezwaar aantekenen bij de Raad van Commissarissen van HDN. De verder te volgen bezwaarprocedure staat beschreven in artikel 15 (Geschillenbesl lechting en toepasselijk recht) van de Aansluitovereenkomst voor leden. HDN Beheer Stelt het Handboek Certificering op Assisteert de gebruiker en, indien van toepassing, servicer 2 met het testen en voert vervolgens de initiële en periodieke certificering uit; Ontvangt verzoeken voor of nodigt uit tot certificering; Is eerste aanspreekpunt voor het gehele traject; Stelt een rapport samen en besluit op basis van de uitkomsten over de certificering van de partijen Zelfevaluatiee Vanaf januari 2014 is het certificeringproces in de even jaren (startend in 2014) aangevuld met een extra onderdeel in de vorm van een zelfevaluatie. Nieuwe toetredende partijen zullen in de volgende certificeringsronde na toetreding de zelfevaluatie dienen in te vullen. De zelfevaluatie heeft als doel HDN gebruikers beter voor te bereiden op de jaarlijkse certificering en heeft een adviserend karakter. 2 Vanaf nu: indien maatschappij staat genoemd, geldt in het geval dat de maatschappij de geautomatiseerde verwerking heeft uitbesteed aan een servicer, dat bedoeld wordt maatschappij en/of servicer. 8

9 Inhoud zelfevaluatie De zelfevaluatie is in te vullen via een online questionnaire. Deze questionnaire is opgebouwd uit verschillende categorieën. Elk facet in een organisatie die potentieel van invloed kan zijn op de procesoptimalisatie met betrekking tot het HDN gebruik, is meegenomen in de questionnaire. De categorieën variëren van het gebruik van digitale HDN berichten tot aan de inrichting van organisatie en management met betrekking tot HDN. Proces beschrijving In januari ontvangt iedere partij een uitnodiging voor de jaarlijkse certificering. Op het antwoordformulier kon vervolgens aangegeven worden welke persoon de online zelfevaluatie per mail dient te ontvangen. Dit zal een maand voorafgaand aan de certificeringdatum gebeuren. Iedere partij heeft drie weken de tijd om de zelfevaluatiee in te vullen. De zelfevaluatie is een onderdeel van de certificering en dient dan ook een week voorafgaand aan de certificering ingevuld te zijn. Uitkomsten van de zelfevaluatie zullen opgenomen worden in een apart onderdeel van het certificeringrapp port en zal dus gelijktijdig opgeleverd worden met het certificeringrapport, ongeveer twee weken na afloop van de certificering. Meer informatie Voor meer informatie en achtergrond over de zelfevaluatie verwijzen wij u door naar het Handboek Zelfevaluatie op Procedures certificering Zoals gezegd in paragraaf 1.4 zijn er verschillende momenten van certificering met een eigen procedure. De initiële of applicatie gebonden certificering en de vervolgcertificering worden hieronder beschreven Initiële of applicatie gebonden certificering Hierbij ligt het initiatief bij de aanvrager van de certificering. Nieuwe HDN relaties of relaties die hun systemen (gaan) vervangen, dan wel een major update van een applicatie uit gaan voeren, kunnen gebruik maken van de initiële of applicatie gebonden certificering. Met het aanvragen van certificering geeft een organisatie aan dat zij voldoet aan alle eisen zoals gesteld in hoofdstuk 3 en desbetreffende bijlagen van dit Handboek Certificering, ook indien deze niet getest of onderzocht zullen worden door HDN Beheer. Een partij die voor het eerst gebruik gaat maken van HDN zal eerst gecertificeerd moeten zijn, alvorens haar HDN certificaat geactiveerd wordt en daarmee communicatie mogelijk wordt. Het volledig testen van de systemen is de verantwoordelijkheidd van de partij zelf. 1. Op het moment dat een partij naar eigen inzicht aan alle certificeringeisen voldoet, meldt zij dit aan HDN Beheer. Dit kan door het indienen van een verzoek per info@hdn.nl. HDN Beheer zal een ontvangstbevestiging terug sturen met een in te vullen formulier voor contactgegevens. Tevens wordt in dit formulier aangegeven voor welke set berichten de partij gecertificeerd dient te worden (primaire set is een vereiste). Een partij kan in haar aanvraag expliciet vermelden wie de contactpersoon is voor de verdere procedure. Certificering gaat niet van start voordat het contactgegevens formulier ontvangen is. 2. HDN Beheer zal binnen 1 week na ontvangst van het formulier contact opnemen met de partij om een dag af te spreken waarop de certificeringtest zal plaatsvinden. Dezee test voor certificering dient compleet te worden doorlopen; gedeeltelijke certificering is niet mogelijk. De certificeringtest zal minimaal 2 weken na het initiële verzoek plaatsvinden. 9

10 3. Tijdens de test zal er communicatie over de HDN lijn plaats vinden tussen de te certificeren partij en HDN Beheer. Een toelichting op deze test is terug te vinden in hoofdstuk Fout! Verwijzingsbron niet gevonden.. 4. Op basis van de testresultaten besluit HDN Beheer over de certificering. Uit de test kunnen een tweetal besluiten resulteren: a). Besluit tot directee goedkeuring. Naast het positieve advies is HDN Beheer vrij de partij aanbevelingen tot verbeteringen te doen. b). Negatief besluit met de eis tot het doen van aanpassingen om opnieuw het certificeringtraject in te gaan. 5. Op basis van voorgaand punt zal HDN Beheer het volgende ondernemen: a). Bij een positief besluit zal HDN Beheer binnenn een week de partij een oorkonde versturen. Met de ondertekening van de oorkonde geeft de gecertificeerde partij expliciet aan, te voldoen aan de eisen zoals vastgesteld in hoofdstuk 3 van dit handboek, ook indien deze in de momentopnamee van certificering niet expliciet getoetst zijn door HDN Beheer. De status van certificering wordt bekend gemaakt op b). Bij een negatief besluit zal HDN Beheer de partij hierover informeren d.m.v. het rapport. Vervolgens wordt op initiatief van de partij weer bij stap 2 begonnen. Indien de te certificeren partij het niet eens is met het besluit is er de mogelijkheid tot bezwaar, zoals beschreven in hoofdstuk Fout! Verwijzingsbron niet gevonden.. Hiervoor heeft de partij een maand de tijd. 6. In geval van positief besluit zal het tijdspad van certificering na de aanvraag maximaal 8 weken zijn. Bij een negatief besluit hangt het tijdspad af van het aantekenen van bezwaar en de periode noodzakelijk voor het doen van aanpassingen. Uitgangspunt blijft dat HDN communicatie niet is toegestaan voordat de certificering met een goed resultaat is afgerond Reguliere certificering Reguliere certificering vindt maximaal één maal per jaar plaats. 1. Bij de regulieree certificering ligt het initiatief bij HDN Beheer. HDN beheer zal alle partijen uitnodigen voor de reguliere certificering. In deze uitnodiging staat een voorgestelde datum voor certificering, jaarlijks rondom dezelfde datum als voorgaand jaar. Bij deze uitnodiging zit ook een bevestiging- en contactformulier, waarop de partij dient aan te geven voor welke berichtenset de partij gecertificeerd dient te worden (primaire set is een vereiste). De partijen hebben één maand de tijd om in te gaan op de uitnodiging en de voorgestelde datum. Indien gewenst kan er, in samenspraak met HDN Beheer, ook een andere datum voor de certificering gekozen worden. De nieuwe datum mag niet meer dan twee maanden later zijn dan de oorspronkelijk voorgestelde datum. Indien in jaar 1 certificering plaats vindt in oktober en het in jaar 2 uitgeschoven wordt naar december, zal de partij in jaar 3 weer uitgenodigd worden voor de oorspronkelijkee maand oktober. Na uitnodiging zal na uiterlijk vier weken een definitievee afspraak gemaakt worden. De test voor de reguliere certificering dient compleet te worden doorlopen; gedeeltelijke certificeringen zijn niet mogelijk. 2. Er is minimaal één release van het generieke schema per jaar. De reguliere certificering zal op het laatst gepubliceerde schema plaatsvinden. De versie is afhankelijk van het tijdstip van certificering van uw organisatie. 3. Vier weken voor de certificeringdatum zal de partij een uitnodiging ontvangen voor het invullen van de zelfevaluatie. Deze zelfevaluatie dient uiterlijk 1 week voor certificeringdatum volledig te zijn ingevuld. Bij niet volledig invullen kan 10

11 certificering geen doorgang vinden. Extra gemaakte uren voor uitstel van de certificering door niet ingevulde zelfevaluaties tellen mee in de vanuit de vereniging beschikbaar gestelde dag (8 uur). Zie ook hoofdstuk Tijdens de certificering zal er communicatie over de HDN lijn plaats vinden tussen de te certificeren partij en HDN Beheer. Een toelichting op deze certificering is terug te vinden in hoofdstuk Op basis van de testresultaten besluit HDN Beheer over de certificering. Uit de test kunnen een tweetal besluiten resulteren: a). Besluit tot directe goedkeuring. Naast het positieve advies is HDN Beheer vrij de partij aanbevelingen tot verbeteringen te doen. b). Negatief besluit met de eis tot het doen van aanpassingen om opnieuw het certificeringtraject in te gaan. 6. Op basis van voorgaand punt zal HDN Beheer het volgendee ondernemen: a). Bij een positief besluit zal HDN Beheer binnen een week de partij een oorkonde versturen. Met de ondertekening van de oorkonde geeft de gecertificeerde partij expliciet aan, te voldoen aan de eisen zoals vastgesteld in hoofdstuk 3 van dit handboek, ook indien deze in de momentopname van certificering niet expliciet getoetst zijn door HDN Beheer. De status van certificering wordt bekend gemaakt op b). Bij een negatief besluit zal HDN Beheer de partij hierover informeren d.m.v. het rapport. Vervolgens wordt op initiatief van de partij weer bij stap 4 begonnen. Indien de te certificeren partij het niet eens is met het besluit is er de mogelijkheid tot bezwaar, zoals beschreven in hoofdstuk 2.4. Hiervoor heeft de partij een maand de tijd. 7. In geval van positief besluit zal het maximale tijdspad van vervolgcertificering na de eerste uitnodiging maximaal 8 weken zijn. Bij negatief advies is het tijdspad afhankelijk van het aantekenen van bezwaar. 8. Bij het besluit tot intrekking van certificering volgt, indien een partij dit wenst, een bezwaarprocedure, zoals beschreven in hoofdstuk 2.4. Bij het aantekenen van bezwaar wordt de intrekking van certificering gedurende een maand opgeschort. 9. Indien partijen tijdens de bezwaarprocedure geen overeenstemming bereiken, volgt intrekking van het digitale certificaat waardoor communicatie via de technische omgevingg van HDN niet meer mogelijk is Naar aanleiding van gegrondee klachten van andere gebruikers van het HDN Platform, kan HDN Beheer besluiten ook buiten de reguliere certificeringen om de partij een certificeringtest te laten doorlopen. Aantekenen van bezwaar Een partij kan een bezwaar tegen het intrekken van het certificaat richten aan HDN Beheer. Dit kan door middel van het zenden van een brief aan HDN Beheer. HDN Beheer zal een ontvangstbevestiging terug sturen. HDN Beheer zal binnen drie werkdagen de brief doorsturen aan de HDN Directeur. De HDN Directeur zal binnen een maand na ontvangst van het document in een officiële brief meedelen dat: a) Zij het bezwaar gegrond verklaart. Zij zal in deze brief komen met een voorstel om zo spoedige mogelijke certificering van de partij te bewerkstelligen en certificering te verstrekken. b) Zij het bezwaar ongegrond verklaart. 11

12 Indienn de partij wederom bezwaar wil aantekenenn kan zij dit doen middels een brief aan de Raad van Commissarissen van HDN. De vervolgprocedure staat beschreven in de HDN Gebruikersovereenkomst vanaf artikel Kosten Vanuit de vereniging HDN wordt maximaal één dag (8 uur) kosteloos per te certificeren organisatie of applicatie besteed aan de certificering. Deze uren kunnen ook over meerdere dagen verdeeld worden. Indien overschrijding van deze uren plaats vindt, zal HDN u hierover informeren en zullen de extra benodigde uren om tot afronding van de certificering in rekening worden gebracht. Indien uit inventarisatie blijkt dat er op voorhand meer tijd nodig is dan is het mogelijk om extra dagen in te kopen tegen het dan geldende tarief Beschikbaar stellen applicatie generieke applicaties Tijdens en na het certificeren zal HDN beheer: Kosteloos de beschikking krijgen over de te certificeren applicatie en eventuele benodigdee updates. De applicatie zal alleen gebruikt worden voor de volgende doeleinden: 1. Het uitvoeren van de daadwerkelijke certificering controle; 2. Controle of berichten daadwerkelijkk met genoemde applicatie zijn geproduceerd; 3. Voortdurend monitoren van het gebruik van de validatieregels; 4. Gedurende het jaar dat de applicatie gecertificeerd is controleren of de applicatie blijft voldoen aan de gestelde vereisten; 5. Gedurende het jaar dat de applicatie gecertificeerd is vragen van gebruikers van de applicatie die rechtstreeks bij HDN Beheer binnenkomen te beantwoorden HDN beheer dient voor de afgesproken certificeringdatum alles te ontvangen waarmee de software op een lokale machine werkend gemaakt kan worden. Indien de organisatie niet in staat is om aan bovenstaand verzoek te voldoen door bijvoorbeeld omvang of specificatie van de software, dient dit voor de certificering kenbaar gemaakt te worden. Daarnaast dient HDN Beheer in voorgenoemde situatie kosteloos begeleiding te krijgen op locatie van de organisatie bij het uitvoeren van de certificering van de partij of applicatie om punt 1 en 2 van de certificering uit te kunnen voeren. Mocht er aanleiding zijn om punt 3, 4 of 5 gedurende het jaar waarin de applicatie gecertificeerd is uit te voeren, dient er wederom kosteloos begeleiding verstrekt te worden op locatie van de organisatie bij het uitvoeren van de controles. 12

13 3. Certificeringvereisten 3.1. Functionele eisen Onder de functionele eisen voor certificering worden de eisen ten aanzien van het kunnen verzenden en ontvangen van de HDN berichtsets verstaan. We hanteren uitdrukkelijk het begrip set aangezienn bijvoorbeeld bij een aanvraag altijd een statusbericht en retourbericht hoort. Bij de certificering wordt de communicatie met het HDN Platform en het op de juiste wijze beantwoorden, samenstellen en verwerken van de HDN berichten getoetst. De HDN certificering vindt plaats op de productieomgeving van de organisatie, waarbij deze HDN omgeving door partij van te voren is getest. De certificering zal zich naast het testen van de keten ook toespitsen op het inhoudelijk goed verwerken van de aanvraag en het versturen van status en offerte berichten. Minimaal dient de partij aan te kunnen tonen dat het een bericht automatisch kan verwerken middels inleesverslagen, het versturen van een SX en of OX bericht (of ander retour bericht) met waarden die overeenkomen met de waarden uit het AX bericht (of ander aanvraagbericht). Naast de gegevens uit de OX met dataset dient de bewijsvoering ondersteund te worden middels een inleesrapport (bijvoorbeeld in XML formaat) of schermafdrukken van de applicatie waar de ingelezen data wordt getoond. Uit de verslaglegging moet blijken wat er met de toegezonden data is gebeurd nadat er een vertaling vanuit het XML bericht heeft plaatsgevonden. De controle bestaat uit het vergelijken van de oorspronkelijk toegezonden dataa met de vertaalde/ingelezen data. Dit wordt gedaan om een beoordeling te kunnen doen of er geen dataverlies of verminking plaats vindt. Hierbij wordt het criterium gehanteerd dat verplichte velden of conditionele velden altijd ondersteund moeten worden. In dit verband dient zowel aan de verzendende kant als aan de ontvangende kant aangetoond te worden dat verplichte, conditioneel verplichte en van toepassing zijnde optionele velden juist gebruikt en gevuld worden. Tevens wordt gecontroleerd of het generiekee schema qua entiteiten en velden correct ondersteundd wordt. Daarnaast is het niet toegestaan om in de keten informatie wederom op te vragen die reeds verzonden was, anders dan ter verificatie van het gegeven. Ditzelfde geldt ook voor het muteren van eerdere aanvragen. Hierna een voorbeeld. In het AX bericht wordt een juist rekeningnummer voor incasso opgegeven. Dan is het niet toegestaan om in de offerte of overige correspondentie een blanco rekeningnummer op te voeren en nogmaals te vragen om het rekeningnummer. Dit is niet in lijn met de ketenintegratie gedachtee die HDN nastreeft. Met andere woorden, de toegezonden gegevens moeten in het proces gebruikt worden, en niet onnodig opnieuw opgevraagd worden. Uiteraard geldt bovenstaande niet voor (bewust) foutieve gegevens. Die mogen genegeerd of verwijderd worden. Bij het certificeren spelen kwaliteitsaspecten als gebruikersvriendelijkheid en onderhoudsvriendelijkheid van de applicatie geen rol. 13

14 HDN Beheer stelt een set met berichten samen waarin alle berichten zullen worden opgenomen. HDN Beheer zal certificeringberichten gebaseerd op partij specifieke producten opstellen. De te certificeren partij zal zelf kenbaar maken voor welke berichtset, naast de standaard berichtset, zij gecertificeerd wil worden. HDN Beheer stuurt certificeringberichten naar de te certificeren ontvangende partij of ontvangt certificeringberichten vanuit een applicatie van de te certificeren versturende partij. HDN Beheer werkt met standaard TP gegevens en verzender/ ontvangernummer, indienn deze organisatie specifiek dienen te zijn moet dit vooraf kenbaar gemaakt worden. 1. HDN Beheer heeft per berichtset een generieke set opgesteld. Deze set bestaat uit meerdere berichten en bevatten een diversiteit aan situaties, welke een weerspiegelingg van de werkelijkheid zijn. 2. HDN zal meer aandacht focussen op de samenwerking van data uitwisseling over de verschillende berichtsets heen, voorbeeld hiervan is de synchronisatie tussen het OX bericht en het DA bericht. 3. Er wordt niet gecertificeerd op basis van een specifieke HDN generieke versie. Dit heeft te maken met de verschuiving van de ingangsdatum van de generieke versie. Echter, er blijft wel gecontroleerd worden op de berichtinhoud van de op dat moment geldende versie. Certificering vindt plaats op bericht opbouw en verwerking vanuit en in applicaties op entiteit en veldniveau. Er zal getoetst worden op logica binnen de (conditionele) verplichte velden. Daarnaast zal worden gecontroleerd of interpretatieverschillen binnen het gebruik van schema s zijn uitgesloten. 4. Naast het versturen van berichten zal de certificering ook productiedata en het berichtenproces van de organisatie beoordelen. 5. a. De ontvangendee partij dient op elk aanvraagbericht een ontvangstbevestiging (SX) retour te zenden, overige SX vereisten staan in bijlage 1; b. De verzendende partij dient een ontvangen SX bericht in te kunnen lezen in de applicatie; 6. a. De ontvangende partij dient tevens van de aanvraag een retourbericht (OX, etc) te verzenden; b. De verzendende partij dient een ontvangen retourbericht (OX, etc.) in te kunnen lezen in de applicatie; Indienn een ingezonden bericht tijdens de certificering niet (volledig) voldoet aan de acceptatie- en productvoorwaarden van een aanbieder om tot een OX bericht te komen, dan is mutatie op gegevens toegestaan. Wel dient er een gedetailleerde verslaglegging te worden gedaan van de gegevens die gemuteerd zijn. 7. HDN Beheer zal vragen om een inleesrapport uit de (mid-office) applicatie; 8. HDN Beheer voert een HDN connecttest uit waarbij minimaal de volgende zaken worden getest: a. De versie van de HDN Software, waarop de partij draait; b. Responstijd van de HDN Enterprise van de partij; c. Of er een overloop-server is ingesteld. Het is niet meer toegestaan om een andere dan node te gebruiken; d. Demilitarized Zone Er dient een architectplaat te worden aangeleverd, waarin de HDN Enterprise software staat opgenomen. Het is niet toegestaan de HDN Enterprise software te hebben geïnstalleerd binnen een DMZ omgeving. 9. HDN Beheer kijkt na of de berichten van alle te certificeren berichtensets over het HDN Platform zijn gegaan de maanden voorafgaand aan de certificering; 10. HDN Beheer doet een analyse op het berichten verkeer op het HDN Platform qua processtroom van de berichten en verschillende berichtsoorten binnenn de het proces; 11. Op basis van het rapport van voorgaand jaar, de analyse van het berichtenverkeer en infrastructuur, ontvangen en verzonden berichten tijdens de certificering en het inleesrapport wordt een analyse gemaakt van het berichtenverkeer op het HDN Platform; 14

15 12. Naar aanleiding van de analyse wordt (eventueel) een aanbeveling tot aanpassing gedaan of er vindt positieve advisering plaats voor de certificering. 13. HDN geeft door middel van een rapport een terugkoppeling, waarin de bevindingen, aanbevelingen en uitkomst van de zelfevaluatie staan opgenomen. 14. Indienn er in het certificeringsrapport openstaande actiepunten worden vastgelegd zal HDN navraag doen over deze punten gedurende de periode tussen het rapport en de volgende certificering. Voor verdere specifieke vereisten per partij wordt u verwezen naar de bijlagen Technische eisen HDN als goed en betrouwbaar communicatiemiddel is niet alleen afhankelijk van de bewaking van het juist hanteren van de standaard. Hieraan is ook een technische component verbonden: 1. De organisatie moet aantoonbaar minimaal de voorlaatste versie van de HDN Enterprise in de productieomgeving hebben draaien op het moment van certificering. Op een verouderde versie zal geen certificering plaats vinden. 2. De partij moet voldoen aan een maximale response tijd waarop de server reageert op een pull van een HDN Basic ( staat er een bericht voor me klaar ). Dit is dus puur een reactie van de server op de HDN Basic en staat los van het versturen van een statusbericht. 3. Vanuit HDN is er per soort organisatie een geadviseerde configuratie m.b.t. de installatie van de communicatiesoftware. Tijdens de certificering wordt bekeken wat in het specifieke geval de configuratie is. De gecertificeerde organisatie zal hiervoor een architectuurplaat dienen aan te leveren. Om ondersteuning te krijgen bij aanpassingen van de configuratie kunnen zaken als capaciteit, kennis e.d. tegen kostprijs door HDN Beheer geleverd worden. 4. Vanuit voorgaande certificeringen is gebleken dat de reguliere certificering op de testomgeving in veel gevallen afwijkingen opleverde ten opzichte van de productieomgeving. Het is dan ook niet meer toegestaan om op een testomgeving de reguliere certificering te doen. Mocht een organisatie zwaarwegende bezwaren hebben tegen het certificeren op een productieomgeving, dan kan hier van afgeweken worden als er een schriftelijke verklaring door een geautoriseerde partij c.q. persoon (bijv. Accountantsorganisatie, Chief Information Officer (CIO), Chief Compliance Officer (CCO) of Verantwoordelijk directielid) wordt opgesteld waarin verklaard wordt dat de testomgeving, voor de HDN functionaliteit, die ter certificering wordt aangeboden een exacte kopie van de productieomgeving betreft. Mocht na certificering blijken dat test- en productieomgeving niet exact overeenkomen, dan kan dat intrekking van het certificaat tot gevolg hebben. Ook zal er in het geval van een initiële certificering op een acceptatie of testomgevingg pas akkoord worden gegevens als het in productie staat en er een hertest op die omgeving heeft plaatsgevonden. 5. HDN Beheer zal alvorens van start te gaan met de certificering controleren of bovenstaande het geval is middels een uitgebreide HDN connecttest. 6. Alle organisaties dienen de XX berichten, deze technische infrastructurele meldingsberichtenn vanuit de HDN software, te ondersteunen. 7. Load balancing Het centrale deel (onder andere administratie en archief) van het HDN platform is, om de betrouwbaarheid en schaalbaarheid te optimaliseren, verdeeld over meerderee systemen. Deze systemen staan over meerdere geografisch gescheiden locaties opgesteld. Dit maakt het mogelijk om de geleverde diensten middels logische namenn te adresseren en de infrastructuur daar op 15

16 basis van beschikbaarheid de (meerdere) fysieke adressen van de corresponderende systemen bij te laten zoeken. Echter, wanneer beveiligingssoftware (firewall) van banken werkt op basis van fysieke adressen en niet op basis van logische namen is het van belang al deze adressen in de firewall configuratie op te nemen ten einde optimaal gebruik te kunnen maken van deze verbeterdee beschikbaarheid. Voorheen werd hier niet specifiek op gecontroleerd. In de certificering zal op deze infrastructurele inrichting gecontroleerd worden. Enkele voorbeelden zijn cs.hdn.nl, certs.hdn.nl en bericht.hdn.nl. De IP-adressen die betrekking hebben op de HDN hostnamen zijn: Demilitarized Zone De HDN enterprise software is binnen de muren en omgeving van een organisatie geïnstalleerd voor het kunnen communiceren over het HDN platform. De HDN software maakt gebruik van beveiligingsprotocollen om de security van de berichten te kunnen garanderen. Een van de beveiligingscriteria is dat de HDN Enterprise software niet geïnstalleerd mag zijn binnen een DMZ omgeving. De HDN software de- en encrypt data binnen de berichten, dezee de- en encryptie vindt, bij installatie van de HDN enterprise software binnen een DMZ, dan ook plaats binnen de DMZ. Vanuit HDN is dit niet toegestaan, daar dan privacygevoelige data op een niet wenselijke locatie gedecrypted worden. Ketenstraat Naast de bovenstaandee technische vereisten adviseert HDN partijen om een test, acceptatie en productie omgeving beschikbaar te hebben voor HDN, waarbij in optimale setting de gehele keten (incl. advies applicatie) is opgenomen. Voor het inrichten van een teststraat adviseert HDN, zowel de Basic- als Enterprise software te downloaden, beide in een aparte server omgeving (los van de productie omgeving) en voor beide een testcertificaat aan te vragen. De teststraat wordt onmiddellijk op het systeem beschikbaar gesteld en is kosteloos Juist gebruik HDN Berichten HDN streeft er naar de zuiverheid van de HDN standaard te waarborgen en dus het ontstaan van dialecten tegen te gaan. Hiermee staat of valt het succes van HDN als dé Branchestandaard. Het oneigenlijk gebruik van HDN Berichten (buiten het HDN platform om, of bestemd voor niet-hdn leden) is niet geoorloofd sinds de HDN standaardd als beschermde standaard is aangemerkt. De achterliggende gedachtee is dat een aanvraag via de HDN Software altijd gevalideerd wordt met VaLidate. Met het via de HDN Software doorlopen van validatie kan HDN de zuiverheid van een bericht garanderen. Oneigenlijk gebruik zijn de volgende situaties; - HDN berichten aanmaakt voor niet-hdn aanbieders en op welke wijze dan ook verzonden. - Zonder goedkeuring vanuit HDN het gebruik van HDN Berichten op anderee communicatie protocollen of platforms. 16

17 Indien partijen met oneigenlijk HDN gebruik te maken krijgen, dan dienen zij in het belang van de standaard dit te vermelden bij HDN. Daarnaast staat open voor optimalisatie van de standaard, indien dit noodzakelijk is om voor aangesloten partijen uniform te communiceren.. 17

18 4. Aanvullende informatie 4.1. Contact Voor vragen of opmerkingen m.b.t. dit document en/of de certificering, kunt u contactt opnemen met: Algemene vragen HDN Beheer Hoogoorddreef BA Amsterdam ZO Tel: info@hdn.nl Website: Technische vragen HDN Helpdesk Tel: helpdesk@hdn.nl Website: (voor downloaden communicatiesoftware) 4.2. Belangrijke documenten HDN Handboek Implementatie Draaiboek Paperless Mortgage HDN Software Reference Manual HDN Handleiding Gebruik logo HDN Handboek Zelfevaluatie Indien nieuwe documenten gepubliceerd worden, kunt u deze altijd vinden op 18

19 Bijlage 1) Eisen certificering Aanbieders De certificering zal zich richten op de maatschappij specifieke schema s. Het maatschappij specifieke schema bestaat uit de verzameling definities, validatie regels, codelijsten en verbandcontroles waarvan is afgesproken dat ze voor iedere deelnemende partij gelden (generieke schema) plus de maatschappij specifieke kenmerken. De aanbieder wordt geacht zich aan deze generieke productopbouw te houden. Aanbieder is verplicht om 100 ontvangen AX berichten aan te leveren om de validatieregels te kunnen controlerenn van de bij de aanbieder binnengekomen AX berichten. De aanvragen mogen geanonimiseerd worden. De vastgestelde validatieregels staan benoemd in Bijlage 3. De berichten dienen van XML formaat te zijn en via een ZIP bestand te worden aangeleverd. Om wille van uitvoerbaarheid van de complete test zullen de certificeringberichten tijdens de certificering gebaseerd zijn op de maatschappij specifieke schema s. Dit dienen gepubliceerde en geactiveerde maatschappij specifieke schema s te zijn. Aandachtspunten tijdens de certificering In de procedure van de certificering in hoofdstuk 2.3 staan enkelee processtappen in de certificering vermeld. Hieronder is daarnaast nog op berichtniveau het berichtverkeer schematische weergegeven. Inzoomend op de bovenstaande berichten wordt hier per bericht de volgende puntenn verwacht van aanbieder & HDN; Aanvraag berichten (AX/LX/KX/MX) HDN stuurt meerdere aanvraagberichten aan aanbieder, hierin zijn bijvoorbeeld onderstaande items benoemd; o Enkele en meerdere leningdelen; o Nieuwbouw/Bestaande woning (met & zonder verbouw) o Diakritische tekens (bijvoorbeeld á of ë, maar ook ) in meerdere alfanumerieke velden. o Mutatie op een eerdere ingediende AX (controle werking aanvraagvolg- en versienummer) Aanbieder levert per bericht een inleesverslag en controleert de validatieregels; o De validatieregels zijn te vinden in bijlage 3. Om de kwaliteit van de berichten over het platform te verhogen is een ieder die gebruik maakt van het HDN platform er bij gebaat dat deze validatieregels nageleefd worden. Tijdens de certificering dienen aanbieders 100 AX berichten aan HDN Beheer aan te leveren, die vervolgens op de validatieregels worden gecontroleerd. De aanvragen mogen geanonimiseerd worden, maar de 19

20 aanvraagvolgnummers moeten te herleiden zijn tot productieberichten. De verdeling dient een goede weerspiegeling te zijn van de aanlevering vanuit de verschillendee advies applicaties. Om naleving van het gebruik van de validatieregels en kwaliteit te monitoren, is elke HDN gebruiker verplicht om te melden als door aanleverende partijen niet wordt voldaan aan de validatieregels en dit zorgt voor uitval bij ontvangende partij. SX Berichten Aanbieder stuurt automatisch per ingestuurd bericht een SX bericht voor elke statusovergang retour; o De volgende lijst aan statusberichten (in code) dient de aanbieder minimaal te ondersteunen; Bij AX bericht: 01 Offerte vervallen, 05 Dossier finaal akkoord, 07 Akte gepasseerd, 09 Aanvraag ontvangen, 11 Offerteaanvraag afgewezen, 14 Offerteaanvraag niet te verwerken, zie toelichting. Bij LX bericht: 04 Medisch akkoord, 08 Polis verzonden, 09 Levenaanvraag ontvangen, 12 Levenaanvraag afgewezen, 13 Levenaanvraag niet te verwerken, zie toelichting. Bij KX bericht: 01 Kredietaanvraag ontvangen, 03 Kredietaanvraag niet te verwerken, zie toelichting, 05 Kredietaanvraag afgewezen, 06 Offerte vervallen, 07 Dossier finaal akkoord, 08 Gelden uitbetaald. De laatste 3 zijn van toepassing vanaf generiekee versie SX (mei 2015); Bij MX bericht: 01 Mutatieverzoek ontvangen, 02 Mutatie verwerkt, 04 Mutatie niet te verwerken, zie toelichting, 05 Mutatie afgewezen. OX Berichten Aanbieder stuurt per ingestuurd bericht een OX-bericht retour. Dit OX bericht bevat naast een PDF file minimaal de verplichte datavelden; Elk separaat toegevoegd document dient een juiste codering te krijgen binnen de entiteit PrintDoc; DA Berichten Aanbieder stuurt na iedere status wijziging van het dossier een DA berichten aan HDN; Aanbieder houdt rekening met de voorschriften die beschreven zijn in het document Implementatie draaiboek Paperless Mortgage ; In het DA bericht opgevraagde stukken zijn inhoudelijk gelijk aan de genoemde stukken in de offerte; Mappingstabel documenten vanuit Mid office applicatie naar het HDN DA bericht. DX Berichten HDN stuurt meerdere DX berichten aan aanbieder; Aanbieder levert per ingestuurd bericht de vertaalde file uit de DX aan HDN per mail aan; Aanbieder houdt rekening met de voorschriften die beschreven zijn in het document Implementatie draaiboek Paperless Mortgage. Overige diensten/berichten (Externe Bronnen, Poortwachter, IA/IX/MX, GX, Taxcon, enz.) Aanbieder stuurt per mail productie berichten richting HDN; Toetsing van inrichting en proces Systemen De systemen die de HDN berichten ondersteunen moeten aan de volgende minimale eisen voldoen. De applicaties moeten de berichtenuitwisseling via de HDN Enterprise software laten verlopen; 20

21 De applicaties mogen maximaal op de voorlaatste versie van de HDN Software draaien (bijv. Software versiee is 5.1, dan is toegestaan versie 5.0. Bij een oudere versie zal certificering niet plaats vindenn voordat de software is geüpdatet naar de laatste versie); De applicaties hanteren de laatst beschikbare berichtversie van zowel het generieke als maatschappij specifieke schema; De applicaties gebruiken de tabellen (veldwaarden) en condities (verplicht indien), zoals vastgelegd in de berichtdefinities; De applicaties zorgen dat alle verplichte, conditioneel verplichtee en optionele (die niet verplicht gemaakt kunnen worden) velden van de generieke schema ss van de verschillende berichten, op een juiste wijze worden gevuld, dan wel worden verwerkt; Het default vullen van velden met default waarden en het leeg meegeven van velden is niet toegestaan Berichten worden gevalideerd in VaLidate alvorens te worden verstuurd; In de HDN configuratie dient de service CSE Schema Updater aan te staan; De applicatie koppelt meldingen van VaLidate terug middels een pop-up of VX bericht; De applicaties moeten bij het gebruik van het offertebericht in staat zijn het bericht zodanig aan te maken dat de te printen gegevens conform PDF formaat kunnen worden geprint door het intermediair; De applicaties moeten juist omgaan met het Aanvraagvolgnummer en versienummer uit de HDN header: o o o Het aanvraagvolgn ummer dient een uniek kenmerk te zijn. Het dient zo opgesteld te worden dat doublures op het HDN platform uitgesloten worden (voorbeeld van een opbouw: databasekenmerk - verzendernummer-datum-tijd aanmaak tot op seconde zal in de meeste gevallen afdoende zijn. Een voorbeeld van dergelijk nummer is: HDN ). Het unieke aanvraagvolgnummer van een aanvraagbericht dient door de gehele keten heen te worden gebruikt, wat inhoud dat alle berichten in het proces hetzelfde aanvraagvolgnummer hanteren. Dit aanvraagvolgnummer zal bij het eerste aanvraagbericht (bij de bron, adviserende intermediair) gegenereerd worden. Tussenschakels in de keten (zoals een service provider) mogen dit niet aanpassen. Een gelijk aanvraagvolgnummer met een hoger versienummer wordt gezien als een mutatie op eerdere offerte. Hiermee zal de aanbieder alleen dienen te reageren op de hoogste versienummer; Applicaties welke DA & DX berichten ondersteunen, moeten voldoen aan de voorwaarden opgenomen in de laatste versie van het Implementatie draaiboek Paperless Mortgage (zie hiervoor HDN.nl of neem contact op met HDN Beheer); Het staat de aanbieder vrij om de applicatie verder van functionaliteit te voorzien die van nut zijn bij berichtuitwisseling en verwerking van de HDN berichten. elektronische Onderdelen die aanbieders dienen aan te leveren zijn de volgende; aanvraagberichten ten behoeve van de Validatie controles - De architectuurplaat - Inleesverslagen vanuit de applicatie (inclusief verslaglegging aangepaste data ten opzichte van aanvraag) - Berichten in het proces via het HDN Platform (communicatie tijdens HDN Certificering) - Aanlevering van berichten vanuit communicatie met NHG (GX), NWWI (Taxcon) en eventuele overige partijen. - Mappingstabel DA/DX - Ontvangen DX bestand per mail retour naar HDN 21

22 Bijlage 2) Eisen certificering Intermediaire Organisaties en/ /of applicaties Voor HDN bestaat de groep intermediaire organisaties uit 2 soorten, namelijk: Softwareleveranciers (generieke applicaties) en Ketens (werkend op eigen applicaties) Service providers, waarbij deze zijn onder te verdelen in: o o Service providers, die zich bezig houden met het verwerken en bewerken van de HDN berichten. Deze organisaties kunnen aanpassingen doen op de AX-berichten die uiteindelijk naar de aanbieders worden gestuurd; Service providers, die zich alleen maar richten op het doorzetten zonder enigee aanpassing van de HDN berichten naar de aanbieders. 2.a. Primaire certificering eisen Softwareleveranciers en Ketens Aandachtspunten tijdens de certificering In de procedure van de certificering in hoofdstuk 2.3 staan enkelee processtappen in de certificering vermeld. Hieronder is daarnaast nog op berichtniveau het berichtverkeer voor softwareleveranciers en ketens schematische weergegeven. Inzoomend op de bovenstaande berichten wordt hier per bericht de volgende puntenn verwacht van gebruiker & HDN; AX Berichten Softwareleverancierr en Keten sturen per certificering (of gecombineerd (zie paragraaf 2.3 lid 2)) AX berichten aan HDN Beheer; HDN Beheer levert een aantal vooraf vastgesteldee aanvragen aan, die 1 op 1 opgevoerd dienen te worden in de applicatie en als AX bericht aangeleverd te worden aan HDN Beheer. Indien een organisatie wijzigingen op de testcasee heeft moeten doen, dient dit door gegeven te worden aan HDN; SX Berichten HDN stuurt meerdere SX berichten met verschillende statussen aan Softwareleverancier en Keten; 22

23 Softwareleverancierr en Keten leveren per ingestuurd status bericht een inleesverslag. OX Berichten HDN stuurt één of meerdere OX berichten aan Softwareleverancier en Keten; Softwareleverancierr en Keten leveren per ingestuurd bericht een inleesverslag waaruit blijkt dat de dataset in de OX kan worden verwerkt in de applicatie; o De verschillen in data vanuit de aanvraag en de offertee moeten getoond worden aan de tussenpersonen. De PDF file in de OX wordt door softwareleverancier en keten teruggestuurd naar HDN (per mail). DA Berichten HDN stuurt initieel en na status wijzigingen DA berichten naar de softwareleverancier en keten; De softwareleverancier en keten leveren hierop een inleesverslag aan HDN. DX Berichten De softwareleverancier en keten stuurt meerdere DX berichten aan HDN; Systemen Nieuwe versies van applicaties worden door HDN gecertificeerd op basis van het laatst gepubliceerde generieke schema. De systemen die de HDN berichten ondersteunen moeten aan de volgende minimale eisen voldoen. De applicaties moeten de berichtenuitwisseling via de HDN software laten verlopen; De applicaties mogen maximaal op de voorlaatste versie van de HDN Software draaien (bijv. Software versiee is 5.1, dan is toegestaan versie 5.0. Bij een oudere versie zal certificering niet plaats vindenn voordat de software is geüpdatet naar de laatste versie); De applicaties hanteren de laatst beschikbare berichtversie van zowel het generieke als maatschappij specifieke schema; De applicaties gebruiken de tabellen (veldwaarden) en condities (verplicht indien), zoals vastgelegd in de berichtdefinities; De applicaties zorgen dat alle verplichte, conditioneel verplichtee en optionele (die niet verplicht gemaakt kunnen worden) velden van de generieke schema ss van de verschillende berichten, op een juiste wijze worden gevuld, dan wel worden verwerkt; Het default vullen van velden met default waarden en het leeg meegeven van velden is niet toegestaan Berichten worden gevalideerd in VaLidate alvorens te worden verstuurd; In de HDN configuratie dient de service CSE Schema Updater aan te staan; De applicatie koppelt meldingen van VaLidate terug middels een pop-up of VX bericht; De applicaties moeten bij het gebruik van het offertebericht in staat zijn het bericht zodanig aan te maken dat de te printen gegevens conform PDF formaat kunnen worden geprint door het intermediair; De applicaties moeten juist omgaan met het Aanvraagvolgnummer en versienummer uit de HDN header: o o Het aanvraagvolgn ummer dient een uniek kenmerk te zijn. Het dient zo opgesteld te worden dat doublures op het HDN platform uitgesloten worden (voorbeeld van een opbouw: databasekenmerk - verzendernummer-datum-tijd aanmaak tot op seconde zal in de meeste gevallen afdoende zijn. Een voorbeeld van dergelijk nummer is: HDN ). Het unieke aanvraagvolgnummer van een aanvraagbericht dient door de gehele keten heen te worden gebruikt, wat inhoud dat alle berichten in het proces hetzelfde aanvraagvolgnummer hanteren. Dit 23

24 aanvraagvolgnummer zal bij het eerste aanvraagbericht (bij de bron, adviserende intermediair) gegenereerd worden. Tussenschakels in de keten (zoals een service provider) mogen dit niet aanpassen. o Een gelijk aanvraagvolgnummer met een hoger versienummer wordt gezien als een mutatie op eerdere offerte. De applicatie dient een mutatie te kunnen aanmaken en deze via een correct aanvraagvolg- en versienummering versturen naar de aanbieders;; Applicaties welke DA & DX berichten ondersteunen, moeten voldoen aan de voorwaarden opgenomen in de laatste versie van het Implementatie draaiboek Paperless Mortgage (zie hiervoor HDN.nl of neem contact op met HDN Beheer); De applicaties moeten automatische updates van de communicatiesoftware kunnen ontvangenn en verwerken. Het is voor certificering dus niet verplicht om: Een vaste lay-out van het aanvraagscherm te bouwen. In het pakket een HDN software installatieprocedure in te bouwen. Administratiefuncties toe te voegen, etc. De aangemaakte HDN berichten uit de applicaties worden gecontroleerd op de vastgestelde validatieregels. Elke applicatie die HDN berichten aanmaakt, dient op de juiste manier om te gaan met de vastgestelde validatieregels, welke zijn benoemd in Bijlage 3. HDN Ontvangernummers In verband met het algemene HDN principe dat alle gebruikers van het HDN platform elkaar moeten kunnen bereiken is er sinds 2010 een eis dat zogenaamde generieke of mulitlabel pakketten (meer dan 1 aanbieder te berekenen of administreren) alle HDN ontvangernummers van zowel eindontvangers ( lees aanbieder e.d.) alsmedee tussenliggende organisatiess (lees service providers, service providers e.d.) dienen te ondersteunen. De meest recente HDN Ontvangernummers zijn te raadplegen via een webservice op DARTS op te vragen (zie hiervoor de documentatie op Onderdelen die softwareleveranciers en ketens dienen aan te leveren zijn de volgende; - De architectuurplaat bij HDN Enterprise gebruikers; - Inleesverslagen (retourberichten) vanuit de applicatie (inclusief verslaglegging aangepaste dataa ten opzichte van aanvraag) - Berichten in het proces via het HDN Platform (communicatie tijdens HDN Certificering) - Aanlevering van berichten vanuit communicatie met NHG (GX), NWWI (Taxcon) en eventuele overige partijen. 2.b. Aanvullendee certificeringeisen intermediaire organisaties (Service providers) Voor intermediaire organisaties die zelf berichten openen (bv. in het geval van een volmacht) en eventueel muteren (bv. in het geval van aanvullen of muteren van een aanvraag door een servicee provider) of berichten rechtstreeks door sturen gelden er naast bovengenoemde eisen aanvullende certificeringeisen. Is het bovenstaande van toepassing dan moet de applicatie: Een offerte aanvraagbericht (AX) kunnen inlezen; Binnen 15 minuten na het versturen van het AX bericht een ontvangstbevestiging ( SX 1 ) kunnen versturen. 24

25 Verder moet een intermediaire organisatie in staat zijn: Een offertebericht (OX) door te sturen of, wanneer deze organisatie zelf offertes (in volmacht) verstrekt, op te maken en te versturen; Bij elke status overgang een bijbehorende generieke status via een SX bericht te versturen; Het unieke aanvraagvolgnummer intact te laten en te gebruiken voor verdere communicatie door de keten heen, naar zowel de aanbieder als terug richting het intermediair (de oorspronkelijke bron). Aandachtspunten tijdens de certificering In de procedure van de certificering in hoofdstuk 2.3 staan enkelee processtappen in de certificering vermeld. Hieronder is daarnaast nog op berichtniveau het berichtverkeer voor softwareleveranciers en ketens schematische weergegeven. In deze opstelling zal HDN tijdens de certificering zowel de rol van intermediair als die dan aanbieder innemen. Inzoomend op de bovenstaande berichten wordt hier per bericht de volgende puntenn verwacht van gebruiker & HDN; Aanvraag berichten (AX/LX/KX/MX) HDN Intermediair stuurt meerderee aanvraagberichten aan service provider, hierin zijn bijvoorbeeld onderstaande items benoemd; o Enkele en meerdere leningdelen; o Nieuwbouw/Bestaande woning (met & zonder verbouw) o Diakritische tekens (bijvoorbeeld á of ë, maar ook ) in meerdere alfanumerieke velden. o Mutatie op een eerdere ingediende AX (controle werking aanvraagvolg- en versienummer) Service provider levert per bericht een inleesverslag en controleert de validatieregels; 25