Handboek HDN Certificering 2016 Periode 1 januari 2016 – 31 december 2016
voor HDN Gebruikers
Januari 2016, versie 1.0
Handboek HDN Certificering 2016 .........................................................................................................................1 Voorwoord ........................................................................................................................................................................4 Inleiding .............................................................................................................................................................................5 1.1.
Doel certificeren ................................................................................................................................................5
1.2.
Welke partijen moeten zich certificeren? ................................................................................................6
1.3.
Wat valt er binnen de certificering? ..........................................................................................................6
1.4.
Wanneer moet een partij zich certificeren? ............................................................................................7
Organisatie en procedures .........................................................................................................................................8 2.1.
Organisatie van HDN .......................................................................................................................................8
2.2.
Zelfevaluatie .......................................................................................................................................................8
2.3.
Procedures certificering .................................................................................................................................9
2.3.1
Initiële of applicatie gebonden certificering............................................................................. 9
2.3.2
Reguliere certificering ..................................................................................................................... 10
2.4.
Aantekenen van bezwaar.............................................................................................................................12
2.5.
Kosten ..................................................................................................................................................................12
2.6.
Beschikbaar stellen applicatie generieke applicaties .......................................................................12
Certificeringvereisten ................................................................................................................................................14 3.1.
Functionele eisen.............................................................................................................................................14
3.2.
Technische eisen ..............................................................................................................................................16
3.3.
Juist gebruik HDN Berichten ......................................................................................................................18
Aanvullende informatie .............................................................................................................................................19 4.1.
Contact ................................................................................................................................................................19
4.2.
Belangrijke documenten ..............................................................................................................................19 2
Bijlage 1) Eisen certificering Aanbieders ............................................................................................................20 Bijlage 2) Eisen certificering Intermediaire Organisaties en/of applicaties ........................................24
3
Voorwoord In de markt ervaren circa 3600 intermediairs, 35 maatschappijen, 40 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 2016 beschrijft de wijze waarop certificering plaatsvindt. Voor de actuele versie van dit Handboek en andere formele HDN documenten kunt u terecht op www.hdn.nl. Indien u vragen heeft, kunt u contact opnemen met HDN via
[email protected]. HDN December 2015
4
Inleiding 1.1. Doel certificeren De Coöperatieve Vereniging HDN Beheer B.A. (HDN) stelt zich als doel het faciliteren van informatieuitwisseling in de hypotheek waardeketen. HDN biedt de voorzieningen 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 betrouwbare 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 staat 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 betrouwbare 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 www.hdn.nl, zal een opsomming van gecertificeerde pakketten, intermediaire organisaties en aanbieders worden gepubliceerd. • Aanbieders zullen van gecertificeerde pakketten berichten ontvangen en zullen worden aangemoedigd 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 verdere uitbreiding of aanpassing van de HDN dienstverlening. • Er vindt afstemming plaats tussen de HDN Helpdesk en de Helpdesk van gecertificeerde organisaties. Bij problemen kan ondersteuning worden verleend of naar de juiste contactpersonen worden verwezen. • Gecertificeerde deelnemers kunnen gebruik maken van het HDN Keurmerk ter profilering van de eigen organisatie. • Gecertificeerde 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.
5
1.2. Welke partijen moeten zich certificeren? De HDN standaard is een beschermde 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: •
Aanbieders die gebruik maken van de HDN standaard en communiceren via de technische omgeving van HDN, met de door HDN geleverde 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 communicatiemodule HDN Basic of HDN Enterprise direct verbonden zijn aan de technische omgeving van HDN1;
•
Organisaties anders dan hierboven, die door middel van extranetten, portals of netwerken 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 vervangen 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 maatwerkfunctionaliteiten 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
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.
6
afronding van de certificering te komen. Nieuwe toetredende partijen op het HDN platform zullen de Zelfevaluatie na het eerste jaar van toetreding invullen. Meer informatie staat in hoofdstuk 2.2.
1.4. 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 livegang 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.
3.
Bij vervanging van een gecertificeerde applicatie (mid-office, advies applicatie).
4. 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. 5.
Indien HDN 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 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
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; •
Neemt bij twijfel besluiten op basis van de door HDN 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 Directeur en de te certificeren partij het niet eens worden tijdens de voornoemde bezwaarprocedure, kan de partij bezwaar aantekenen bij de Raad van Commissarissen van HDN. De verder te volgen bezwaarprocedure staat beschreven in artikel 15 (Geschillenbeslechting en toepasselijk recht) van de “Aansluitovereenkomst” voor leden. HDN • Stelt het Handboek Certificering op •
Assisteert de gebruiker en, indien van toepassing, servicer2 met het testen en voert vervolgens de
•
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.
initiële en periodieke certificering uit;
2.2. Zelfevaluatie 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. Inhoud zelfevaluatie
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
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 kan 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 twee weken de tijd om de zelfevaluatie in te vullen. De zelfevaluatie is een onderdeel van de certificering en dient dan ook twee weken voorafgaand aan de certificering ingevuld te zijn. Uitkomsten van de zelfevaluatie zullen opgenomen worden in een apart onderdeel van het certificeringrapport en zal dus gelijktijdig opgeleverd worden met het certificeringrapport, ongeveer twee weken na afloop van de certificering.
2.3. 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. 2.3.1 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. 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 verantwoordelijkheid van de partij zelf. 1.
Op het moment dat een partij naar eigen inzicht aan alle certificeringeisen voldoet, meldt zij dit aan HDN. Dit kan door het indienen van een verzoek per email:
[email protected]. HDN 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 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. Deze test voor certificering dient
9
compleet te worden doorlopen; gedeeltelijke certificering is niet mogelijk. De certificeringtest zal minimaal 2 weken na het initiële verzoek plaatsvinden. 3.
Tijdens de test zal er communicatie over de HDN lijn plaats vinden tussen de te certificeren partij en HDN. Een toelichting op deze test is terug te vinden in hoofdstuk Fout! Verwijzingsbron niet gevonden..
4. Op basis van de testresultaten besluit HDN over de certificering. Uit de test kunnen een tweetal besluiten resulteren: a). Besluit tot directe goedkeuring. Naast het positieve advies is HDN 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 het volgende ondernemen: a). Bij een positief besluit zal HDN 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 0 van dit handboek, ook indien deze in de momentopname van certificering niet expliciet getoetst zijn door HDN. De status van certificering wordt bekend gemaakt op www.hdn.nl. b). Bij een negatief besluit zal HDN 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. 2.3.2 Reguliere certificering Reguliere certificering vindt maximaal één maal per jaar plaats. 1.
Bij de reguliere certificering ligt het initiatief bij HDN. HDN 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, 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 oorspronkelijke maand oktober. Na uitnodiging zal na uiterlijk vier weken een definitieve afspraak gemaakt worden.
10
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 2 weken voor certificeringdatum volledig te zijn ingevuld. Bij niet volledig invullen kan 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 2.5.
4. Tijdens de certificering zal er communicatie over de HDN lijn plaats vinden tussen de te certificeren partij en HDN. Een toelichting op deze certificering is terug te vinden in hoofdstuk 0. 5.
Op basis van de testresultaten besluit HDN over de certificering. Uit de test kunnen een tweetal besluiten resulteren: a). Besluit tot directe goedkeuring. Naast het positieve advies is HDN 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 het volgende ondernemen: a). Bij een positief besluit zal HDN 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. De status van certificering wordt bekend gemaakt op www.hdn.nl. b). Bij een negatief besluit zal HDN 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.
11
9. Indien partijen tijdens de bezwaarprocedure geen overeenstemming bereiken, volgt intrekking van het digitale certificaat waardoor communicatie via de technische omgeving van HDN niet meer mogelijk is. 10. Naar aanleiding van gegronde klachten van andere gebruikers van het HDN Platform, kan HDN besluiten ook buiten de reguliere certificeringen om de partij een certificeringtest te laten doorlopen.
2.4. •
Aantekenen van bezwaar
Een partij kan een bezwaar tegen het intrekken van het certificaat richten aan HDN. Dit kan door middel van het zenden van een brief aan HDN. HDN zal een ontvangstbevestiging terug sturen.
•
HDN 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.
•
Indien de partij wederom bezwaar wil aantekenen kan zij dit doen middels een brief aan de Raad van Commissarissen van HDN. De vervolgprocedure staat beschreven in de “HDN Gebruikersovereenkomst” vanaf artikel 10.0.
2.5.
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.
2.6.
Beschikbaar stellen applicatie generieke applicaties
Tijdens en na het certificeren zal HDN: •
Kosteloos de beschikking krijgen over de te certificeren applicatie en eventuele benodigde updates. De applicatie zal alleen gebruikt worden voor de volgende doeleinden: 1.
Het uitvoeren van de daadwerkelijke certificering controle;
2.
Controle of berichten daadwerkelijk 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;
12
HDN 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 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 of,4 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.
13
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’ aangezien 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 data 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 generieke schema qua entiteiten en velden correct ondersteund 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 gedachte 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.
14
Bij het certificeren spelen kwaliteitsaspecten als gebruikersvriendelijkheid en onderhoudsvriendelijkheid van de applicatie geen rol. HDN stelt een set met berichten samen waarin alle berichten zullen worden opgenomen. HDN 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 stuurt certificeringberichten naar de te certificeren ontvangende partij of ontvangt certificeringberichten vanuit een applicatie van de te certificeren versturende partij. HDN werkt met standaard TP gegevens en verzender/ ontvangernummer, indien deze organisatie specifiek dienen te zijn moet dit vooraf kenbaar gemaakt worden. 1.
HDN heeft per berichtset een generieke set opgesteld. Deze set bestaat uit meerdere berichten en bevatten een diversiteit aan situaties, welke een weerspiegeling van de werkelijkheid zijn.
2.
HDN zal de samenwerking van data uitwisseling over de verschillende berichtsets heen bekijken, 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 ontvangende 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; Indien 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 zal vragen om een inleesrapport uit de (mid-office) applicatie;
8. HDN 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 300000 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 kijkt na of de berichten van alle te certificeren berichtensets over het HDN Platform zijn gegaan de maanden voorafgaand aan de certificering;
15
10. HDN doet een analyse op het berichten verkeer op het HDN Platform qua processtroom van de berichten en verschillende berichtsoorten binnen 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; 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. Indien 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.
3.2.
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 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 testomgeving pas akkoord worden gegeven als het in productie staat en er een hertest op die omgeving heeft plaatsgevonden.
16
5.
HDN 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, de technische infrastructurele meldingsberichten vanuit de HDN software, te ondersteunen.
Load balancing Het centrale deel (onder andere administratie en archief) van het HDN platform is, om de betrouwbaarheid en schaalbaarheid te optimaliseren, verdeeld over meerdere systemen. Deze systemen staan over meerdere geografisch gescheiden locaties opgesteld. Dit maakt het mogelijk om de geleverde diensten middels logische namen te adresseren en de infrastructuur daar op 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 verbeterde 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: 194.69.31.76 194.69.31.110 194.69.31.120 194.69.28.69 194.69.28.76 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, deze 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 bovenstaande 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.
17
3.3.
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 standaard als beschermde standaard is aangemerkt. De achterliggende gedachte 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 andere communicatie protocollen of platforms.
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.
18
Aanvullende informatie 4.1. Contact Voor vragen of opmerkingen m.b.t. dit document en/of de certificering, kunt u contact opnemen met: Algemene vragen HDN Hoogoorddreef 5 1101 BA Amsterdam ZO Tel: 020 - 550 37 58 Email:
[email protected] Website: www.hdn.nl Technische vragen HDN Helpdesk Tel: 0182 - 750 585 Email:
[email protected] Website: https://www.hdn.nl/platform/#software (voor downloaden communicatiesoftware)
4.2. Belangrijke documenten •
HDN Handboek Implementatie Draaiboek Paperless Mortgage
•
HDN Software Reference Manual
•
HDN Handleiding Gebruik logo
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 controleren van de bij de aanbieder binnengekomen AX berichten. De aanvragen mogen geanonimiseerd worden. 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 enkele 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 punten 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;
20
o
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 de validatieregels nageleefd worden. Tijdens de certificering dienen aanbieders 100 AX berichten aan HDN aan te leveren, die vervolgens op de validatieregels worden gecontroleerd. De aanvragen mogen geanonimiseerd worden, maar de aanvraagvolgnummers moeten te herleiden zijn tot productieberichten. De verdeling dient een goede weerspiegeling te zijn van de aanlevering vanuit de verschillende 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 dient de aanbieder te versturen; Bij AX bericht: 16 Offerteaanvraag beëindigd, zie toelichting, 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, 14 Gezondheidsverklaring ontvangen, 15 Gezondheidsverklaring verzonden, 02 Medische stukken ontvangen, 11 Medische stukken opgevraagd. Bij KX bericht: 01 Kredietaanvraag ontvangen, 03 Kredietaanvraag niet te verwerken, zie toelichting, 05 Kredietaanvraag afgewezen, 07 Offerte vervallen, 08 Dossier finaal akkoord, 09 Gelden uitbetaald. 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;
21
•
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;
•
De applicaties mogen maximaal op de voorlaatste versie van de HDN Software draaien (bijv. Software versie is 5.1, dan is toegestaan versie 5.0. Bij een oudere versie zal certificering niet plaats vinden 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 verplichte en optionele (die niet verplicht gemaakt kunnen worden) velden van de generieke schema’s 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
Het aanvraagvolgnummer 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: HDN305674-28032009124459).
o
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.
o
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;
22
•
Applicaties welke DA & DX berichten ondersteunen, moeten voldoen aan de voorwaarden opgenomen in de laatste versie van het Implementatie draaiboek Paperless Mortgage.
Het staat de aanbieder vrij om de applicatie verder van functionaliteit te voorzien die van nut zijn bij elektronische berichtuitwisseling en verwerking van de HDN berichten. Onderdelen die aanbieders dienen aan te leveren zijn de volgende; 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
23
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
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;
o
Service providers, die zich alleen maar richten op het doorzetten – zonder enige 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 enkele 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 punten verwacht van gebruiker & HDN;
AX Berichten •
Softwareleverancier en Keten sturen per certificering (of gecombineerd (zie paragraaf 2.3 lid 2)) AX berichten aan HDN;
•
HDN levert een aantal vooraf vastgestelde aanvragen aan, die 1 op 1 opgevoerd dienen te worden in de applicatie en als AX bericht aangeleverd te worden aan HDN. Indien een organisatie wijzigingen op de testcase heeft moeten doen, dient dit door gegeven te worden aan HDN;
24
SX Berichten •
HDN stuurt meerdere SX berichten met verschillende statussen aan Softwareleverancier en Keten;
•
Softwareleverancier en Keten leveren per ingestuurd status bericht een inleesverslag.
OX Berichten •
HDN stuurt één of meerdere OX berichten aan Softwareleverancier en Keten;
•
Softwareleverancier 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 offerte 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 versie is 5.1, dan is toegestaan versie 5.0. Bij een oudere versie zal certificering niet plaats vinden 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 verplichte en optionele (die niet verplicht gemaakt kunnen worden) velden van de generieke schema’s 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;
25
•
De applicaties moeten juist omgaan met het Aanvraagvolgnummer en versienummer uit de HDN header: o
Het aanvraagvolgnummer 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: HDN305674-28032009124459).
o
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.
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;
•
De applicaties moeten automatische updates van de communicatiesoftware kunnen ontvangen 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.
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.) alsmede tussenliggende organisaties (lees 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 www.hdn.nl). 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 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.
26
2.b. Aanvullende 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 service 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 (SX09) kunnen versturen.
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).
27
Aandachtspunten tijdens de certificering In de procedure van de certificering in hoofdstuk 2.3 staan enkele 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 punten verwacht van gebruiker & HDN;
Aanvraag berichten (AX/LX/KX/MX) •
HDN Intermediair stuurt meerdere 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; o
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 de validatieregels nageleefd worden.
•
Service providers sturen per certificering (of gecombineerd (zie paragraaf 2.3 lid 2)) AX berichten aan de HDN Aanbieder;
28
SX Berichten •
HDN Aanbieder stuurt meerdere SX berichten met verschillende statussen aan service provider;
•
Service provider leveren per ingestuurd bericht een inleesverslag. o
De volgende lijst aan statusberichten (in code) dient de Service provider minimaal te ondersteunen en/of door te kunnen sturen: Bij AX bericht: 16 Offerteaanvraag beëindigd, zie toelichting, 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, 14 Gezondheidsverklaring ontvangen, 15 Gezondheidsverklaring verzonden, 02 Medische stukken ontvangen, 11 Medische stukken opgevraagd. Bij KX bericht: 01 Kredietaanvraag ontvangen, 03 Kredietaanvraag niet te verwerken, zie toelichting, 05 Kredietaanvraag afgewezen, 07 Offerte vervallen, 08 Dossier finaal akkoord, 09 Gelden uitbetaald. Bij MX bericht: 01 Mutatieverzoek ontvangen, 02 Mutatie verwerkt, 04 Mutatie niet te verwerken, zie toelichting, 05 Mutatie afgewezen.
•
Service provider levert binnen de gestelde statustermijnen reactie naar HDN Intermediair
OX Berichten •
HDN Aanbieder stuurt één of meerdere OX berichten aan service provider;
•
Service providers 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 offerte moeten getoond worden aan de tussenpersonen.
•
De PDF file in de OX wordt door de service provider teruggestuurd naar HDN (per mail).
•
De service provider stuurt de OX retour naar de HDN Intermediair.
•
Elk separaat toegevoegd document dient een juiste codering te krijgen binnen de entiteit PrintDoc.
DA Berichten •
HDN Aanbieder stuurt na iedere status wijziging van het dossier een DA berichten aan service provider;
•
De service providers leveren hierop een inleesverslag en naar HDN;
•
Service providers die zelf een DA bericht vanuit hun eigen applicatie genereren dienen een mappingstabel van de documenten aan te leveren;
•
De service provider stuurt het DA bericht door naar de HDN Intermediair.
•
In het DA bericht opgevraagde stukken zijn inhoudelijk gelijk aan de genoemde stukken in de offerte;
•
Service provider houdt rekening met de voorschriften die beschreven zijn in het document ‘Implementatie draaiboek Paperless Mortgage’.
DX Berichten •
HDN Intermediair stuurt meerdere DX berichten aan service provider;
29
•
De service provider stuurt meerdere DX berichten aan HDN Aanbieder;
•
Service provider houdt rekening met de voorschriften die beschreven zijn in het document ‘Implementatie draaiboek Paperless Mortgage’.
Systemen De systemen die de HDN berichten inlezen en/of versturen, moeten aan de volgende minimale eisen voldoen: 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;
•
De applicaties mogen maximaal op de voorlaatste versie van de HDN Software draaien (bijv. Software versie is 5.1, dan is toegestaan versie 5.0. Bij een oudere versie zal certificering niet plaats vinden 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 verplichte en optionele (die niet verplicht gemaakt kunnen worden) velden van de generieke schema’s 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
Het aanvraagvolgnummer 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: HDN305674-28032009124459).
o
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.
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;
30
•
Applicaties welke DA & DX berichten ondersteunen, moeten voldoen aan de voorwaarden opgenomen in de laatste versie van het Implementatie draaiboek Paperless Mortgage (zie hiervoor www.HDN.nl of neem contact op met HDN);
Het staat de aanbieder vrij om de applicatie verder van functionaliteit te voorzien die van nut zijn bij elektronische berichtuitwisseling en verwerking van de HDN berichten. Onderdelen die service providers dienen aan te leveren zijn de volgende; De architectuurplaat bij HDN Enterprise gebruikers -
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 NWWI (Taxcon) en eventuele overige partijen.
-
Mappingstabel DA/DX
-
Ontvangen DX bestand per mail retour naar HDN
2.c. Aanvullende infrastructurele certificeringeisen online adviesapplicaties Systeemhuizen die hun software online voor hun gebruikers ter beschikking stellen, zullen onderhevig zijn aan extra vereisten die de technische inrichting van de “Cloud” c.q. SAAS oplossing betreffen. De volgende eisen zijn daarvoor van belang: •
De verbinding tussen werkstation en server moet minimaal een beveiligde “HTTPS” verbinding zijn
•
Extra functionaliteit rondom de toegang tot en bescherming van de HDN berichten die in de “Cloud” zijn opgeslagen. Authenticatie via DARTS is een voorbeeld van deze functionaliteit.
•
Beheer en bescherming van het gebruikers- en certificatenbestand. Ook hier is authenticatie via DARTS is een voorbeeld van deze functionaliteit.
31
