NEDERLANDSE PROCES ARCHITECTUUR SBR

Bijlage 5.2 NEDERLANDSE PROCES ARCHITECTUUR SBR Versie 1.0 Datum 01-01-14 Status Definitief Concept

Colofon Projectnaam NPA Versienummer 1.0 Contactpersoon S.G.J. Kockelkoren Organisatie Logius Postbus 96810 2509 JE Den Haag servicecentrum@logius.nl Bijlage(n) Documentbeheer Datum Versie Auteur Opmerkingen 26-6-13 0.1 SK Concept 23-10-13 0.3 SK Concept na bespreking leden werkgroep NPA. 22-11-13 0.4 SK Aanvulling na bespreking werkgroep NPA 28-11-13 0.5 SK Aanvulling na review SBR partners 29-11-13 0.51 SK Aanvulling na review BD 01-01-14 0.9 SK Definitief concept na bespreking EG P&T 12-03-14 1.0 JPB Ter vaststelling voorgelegd aan SBR Beraad Pagina 2 van 19

Inhoud Colofon... 2 Inhoud... 3 1 Inleiding... 5 1.1 Context... 5 1.2 Doel... 5 1.3 Betrokkenen... 5 1.4 Definities... 6 2 Governance... 7 2.1 Werkgroep NPA... 7 2.2 Totstandkoming NPA... 7 2.2.1 Opstellen startdocument... 7 2.2.2 Input Expertgroep Processen en Techniek... 7 2.2.3 Adviseren Platform... 7 2.2.4 Bekrachtiging NPA... 7 2.3 Governance NPA... 7 2.3.1 Input voor aanpassingen... 7 2.3.2 Verwerking aanpassing... 7 2.3.3 Vaststellen aanpassing... 8 3 NPA: Scope... 9 4 NPA: Processen... 11 4.1 Aanleveren... 11 4.1.1 Interactie... 11 4.1.2 Bouwblokken... 11 4.2 emededelen... 12 4.2.1 Interactie... 12 4.2.2 Bouwblokken... 12 4.3 Statusinformatie... 12 4.3.1 Interactie... 12 4.3.2 Bouwblokken... 13 5 NPA: Bouwblokken... 14 5.1 Algemeen... 14 5.1.1 Niet-Functionele eisen... 14 5.1.2 Functionele eisen... 14 5.1.3 Randvoorwaardelijke voorzieningen... 14 5.2 Authenticatie... 15 5.2.1 Functionele eisen... 15 5.2.2 Rand voorwaardelijke voorzieningen... 15 5.3 Beveiliging... 15 5.3.1 Functionele eisen... 15 5.3.2 Randvoorwaardelijke voorzieningen... 15 Pagina 3 van 19

5.4 Autorisatie: machtiging controleren... 15 5.4.1 Functionele eisen: Aanleveren... 15 5.4.2 Randvoorwaardelijke voorzieningen: Aanleveren... 15 5.4.3 Functionele eisen: Statusinformatie... 15 5.4.4 Randvoorwaardelijke voorzieningen: Statusinformatie... 16 5.4.5 Functionele eisen: emededelen... 16 5.4.6 Randvoorwaardelijke voorzieningen: emededelen... 16 5.5 Validatie... 16 5.5.1 Functionele eisen... 16 5.5.2 Randvoorwaardelijke voorzieningen... 16 6 Bijlage A: BPMN Procesplaten... 17 Pagina 4 van 19

1 Inleiding 1.1 Context SBR streeft naar standaardisatie van (financiële-)rapportagestromen in richting van de overheid en private partijen. Optimalisatie van de rapportageketens vergt dat het helder is welke standaarden, processen en technieken gebruikt kunnen worden. Dit geldt zowel voor de publieke en private afnemers als voor de partijen die rapportages aanleveren of ontvangen (ophalen) of daar anderszins bij betrokken zijn. Het SBR Platform heeft opdracht gegeven om, in analogie met de Nederlandse Taxonomie Architectuur (NTA), de Nederlandse Proces Architectuur (NPA) uit te werken. De richtlijnen in de NPA geven zowel marktpartijen als nieuwe (en bestaande) SBR partners handvatten om op gestandaardiseerde wijze de onderlinge digitale interactie met een SBR infrastructuur in te richten om tot een beperking van kosten voor marktpartijen die aansluiten op deze infrastructuur te komen. De NPA en de NTA bepalen gezamenlijk de invulling van SBR. 1.2 Doel Overheden en Banken streven, in het kader van SBR, naar standaardisatie van de system-to-system interactie met een SBR-infrastructuur. Doel van de NPA is te komen tot een overzicht met richtlijnen en generieke architectuur principes die handvatten bieden voor deze standaardisatie. Principes moeten toekomst vast zijn en onafhankelijk van de huidige implementatie opgesteld worden. Met de NPA wordt geborgd dat SBR implementaties aan generieke- en kwaliteitseisen voldoen: er wordt zo veel mogelijk één standaard gehanteerd richting marktpartijen (softwareontwikkelaars) waarbij de informatieprocessen op eenduidige wijze worden afgehandeld. Nieuwe en bestaande SBR partners dienen zich, bij gebruik en de implementatie van een SBR-infrastructuur, volgens de SBR Governance zoveel mogelijk aan de NPA principes te houden. SBR Partners kunnen, met duidelijke verantwoording en onderbouwing, hierbij wel afwijken van de NPA principes. 1.3 Betrokkenen Stephan Kockelkoren Niels de Winne Marcel Ermers Ton Wessels Maurice Mesman / John Sloof Okko Smit Alie van Nieuwenhoven Emiel Kahlmann Victor Pekárek Logius Logius Belastingdienst CBS Kamer van Koophandel FRC FRC FRC FRC Pagina 5 van 19

1.4 Definities De in dit document gehanteerde begrippen worden in de onderstaande tabel gedefinieerd: SBR Partner Zowel publieke als private partijen die voldoen aan alle eisen/ingen vanuit het SBR-stelsel en die derhalve voluit als zodanig binnen het stelsel participeren en onderdeel zijn van de publiek-private governancestructuur, zoals beschreven in de SBR Governance. (zie SBR_governance_april_2013) Afnemer Een entiteit (overheid of banken) die voor de uitoefening van een publieke of private taak elektronisch verkeer met andere overheden, burgers en/of bedrijven wenselijk acht en daarbij gebruik maakt van SBR om elektronische berichten te ontvangen of versturen (mede te delen). (Afnemer wordt ook wel uitvragende partij genoemd) Gebruiker Een onderneming, rechtspersoon of natuurlijke persoon die gebruik maakt van SBR ten behoeve van het elektronische verkeer met één of meerdere Afnemers (ook wel aanleveraar, bedrijf of intermediair) Belanghebbende Een onderneming, rechtspersoon of natuurlijke persoon namens wie een gebruiker of die zelf als gebruikergebruik maakt van SBR. De aan te leveren of op te halen informatie heeft betrekking op deze entiteit. Certificaat Een digitaal document dat gegevens bevat voor de waarborging van de integriteit van bestanden en/of opzetten van een beveiligde verbinding. Ook kan een certificaat worden gebruikt voor authenticatie, zowel op technisch niveau als ook op het niveau van een persoon of organisatie. SBRinfrastructuur Een voorziening die geautomatiseerd keteninformatieprocessen uitvoert op basis van SBR gegevensstandaarden, processtandaarden en technische standaarden. Een SBR-infrastructuur zorgt voor het gestandaardiseerd uitvoeren en beheren van informatie-uitwisselingsprocessen, en bestaat uit een digitale toegangspoort van bijvoorbeeld de overheid of Banken. Koppelvlak Proces De aanleverportalen (van SBR partners) maken geen deel uit van de SBR infrastructuur en vallen buiten scope van de NPA. Een koppelvlak is een system-to-system verbinding tussen informatiesystemen dat de uitwisseling van informatie faciliteert. Het definieert de interactie tussen SBR-infrastructuur en de gebruiker of de interactie tussen SBR-infrastructuur en afnemer Een doelgericht samenhangend geheel van opeenvolgende activiteiten in de tijd. Pagina 6 van 19

2 Governance 2.1 Werkgroep NPA Er wordt een nieuw overleg gremium in het leven geroepen: de SBR werkgroep NPA. Alle SBR Partners nemen deel aan dit overleg. Het overleg staat onder leiding van Logius (beheer NPA) en zal minimaal 4 keer per jaar plaatsvinden. Indien er geen agendapunten zijn ingebracht zal de werkgroep geen doorgang vinden, als agenda punten aanleiding geven tot het beleggen van een extra bijeenkomst zal deze georganiseerd worden. 2.2 Totstandkoming NPA Aangezien de NPA nog tot stand moet worden gebracht ziet de initiële Governance ook toe op het totstandkomingsproces. 2.2.1 Opstellen startdocument In de Werkgroep NPA (SBR Partners) wordt dit document opgesteld met de scope van de NPA, bouwblokken (onderwerpen die aan bod komen) en een voorstel rond de Governance. 2.2.2 Input Expertgroep Processen en Techniek Het startdocument wordt voorgelegd aan EG P&T. De EG geeft input en advies op de bouwblokken en scope van de NPA. 2.2.3 Adviseren Platform In de Werkgroep NPA wordt de input uit de EG P&T verwerkt en een definitief document, met daarin de NPA, opgesteld. Dit definitieve document zal aan de EG P&T en het Platform verstuurd worden. Het advies en de procesgang (afstemming) wordt in de vorm van een oplegnotitie meegestuurd. 2.2.4 Bekrachtiging NPA Het SBR-Beraad beslist, op voordracht van het Platform, over bekrachtiging van de NPA. Het Beraad vergewist zich ervan dat de brede SBR-community, vertegenwoordigd in de expertgroep P&T, in de gelegenheid is gesteld hierover te adviseren. 2.3 Governance NPA Logius beheert de NPA. Aanpassingen op de NPA kunnen worden ingebracht via onderstaand afsprakenstelsel. Details worden weergegeven in de BPMN procesplaten in de bijlage. 2.3.1 Input voor aanpassingen Op verschillende manieren kunnen zowel marktpartijen / softwareleveranciers als NPA-partners aanpassingsvoorstellen op de NPA indienen. Het NPA beheerteam van Logius agendeert het voorstel in de werkgroep NPA. Zie bijlage A, Procesplaat 1. 2.3.2 Verwerking aanpassing De werkgroep NPA komt bijeen en beoordeelt wenselijkheid, eventueel na afstemming met technische experts. Indien er een mogelijk grote impact Pagina 7 van 19

bestaat zal een Request for Comments worden gepubliceerd (op website SBR-nl.nl) en verstuurd aan de deelnemers van de EG P&T. De werkgroep NPA doet, na impact bepaling op implementatie, een voorstel over de voorgenomen aanpassing van NPA en implementatie termijn. Zie bijlage A, Procesplaat 2. 2.3.3 Vaststellen aanpassing Voor in gebruik name van een aanpassing van de NPA wordt de Expertgroep Processen en Techniek geïnformeerd en om advies gevraagd, waarna de aanpassing wordt bekrachtigd in het Platform en voorgelegd aan het SBR Beraad. Zie bijlage A, Procesplaat 3. Pagina 8 van 19

3 NPA: Scope Onderstaande punten en schema geven de scope weer van de op te stellen NPA. Zoals de NTA over gegevens (harmonisatie) en XBRL (technische standaard) gaat, zal de NPA over processen en het gebruik van en de eisen aan de onderliggende technische standaarden gaan. De NPA ziet op de interactie met de SBR infrastructuur. De verschillende interacties tussen gebruiker en verwerkende infrastructuur zijn gebundeld in een SBR proces. Ieder proces stelt functionele eisen aan de standaard bouwblokken waaruit het proces bestaat. Er wordt onderscheid gemaakt tussen functionele eisen en randvoorwaardelijke voorzieningen, o Functionele eisen in de NPA zien, per bouwblok op eenduidige terminologie, conventies en requirements ten aanzien van randvoorwaardelijke voorzieningen. o Randvoorwaardelijke voorzieningen (standaarden, technische aspecten en stelsels) die buiten de SBR Governance liggen worden in de NPA als zodanig benoemd. In de NPA wordt bepaald welke onderdelen van standaarden aarden gebruikt worden in het kader van SBR. De NPA is gebaseerd op de huidige SBR architectuur principes zoals geïmplementeerd in Digipoort en BIV. SBR processen en bouwblokken die door één partij zijn ontwikkeld en geïmplementeerd vormen de facto de huidige standaard en zijn Pagina 9 van 19

opgenomen in de NPA om standaardisatie te bevorderen. Bij in gebruik name van deze processen of bouwblokken door andere SBR partners zullen de principes en richtlijnen, zoals geformuleerd in dit document, als leidraad gelden. Afwijkende wensen en usecases zullen in de werkgroep NPA besproken worden en kunnen leiden tot een aanpassing van de NPA. SBR Partners streven naar standaardisatie, maar domein specifieke invulling door de afnemers (SBR Partners) is mogelijk. Zij blijven zelf beslissingsbevoegd over voorschriften uit de NPA, maar moeten verantwoording in Expertgroep en Platform afleggen over hun keuzes. Buiten scope Procesafwikkeling en berichtverwerking volgend op interactie met de gebruiker valt buiten de scope van de NPA. Dit ziet zowel op interne berichtafhandeling binnen een SBR infrastructuur als berichtafhandeling door een afnemer. De aanleverportalen (van SBR Partners) maken geen deel uit van de SBR infrastructuur en vallen buiten scope van de NPA. Aspecten van de een SBR service organisatie zoals bijvoorbeeld aansluitondersteuning, klantondersteuning, machtingsprocessen (B2), het verzorgen van een ingerichte beheerorganisatie, interactie tussen SBR infrastructuur en afnemer (bijvoorbeeld Digipoort Belastingdienst) en afspraken rond service niveaus (openstellingstijden, verwerkingscapaciteit, betrouwbaarheid, etc.) vallen buiten de scope van de NPA. De NPA is geen "SBR roadmap": er wordt geen toekomst visie / roadmap voor de komende jaren geschetst. Er wordt wel rekening gehouden met ontwikkelingen in de nabij toekomst. Pagina 10 van 19

4 NPA: Processen De gebruiker (aanleverende partij) communiceert met de SBR infrastructuur door interacties met een SBR proces. Ieder proces (aanleveren, e-mededelen en statusinformatie) bestaat uit een aantal bouwblokken, welke in het volgende hoofdstuk worden weergegeven. 4.1 Aanleveren Aanleveren bestaat uit het door de gebruiker versturen van een bericht naar een SBR-infrastructuur en het ontvangen van het resultaat van de verwerking. 4.1.1 Interactie Er zijn twee vormen van aanlever interactie te onderkennen: een synchroon en een a-synchroon proces: Synchroon: Indien de gehele verwerking van een aanleververzoek (request) binnen de SBR infrastructuur, inclusief aflevering aan een afnemer, succesvol verlopen is, wordt er een SOAP response verzonden. De response maakt melding van het kenmerk van het proces. A-Synchroon: Indien de technische verwerking van een aanleververzoek (request) in de aanleverservice succesvol verlopen is, wordt er een SOAP response verzonden. De response maakt melding van het kenmerk van het proces. Dit kenmerk moet worden gebruikt om de status van verwerking te bekijken met de statusinformatieservice. Voor beide processenimplementaties gelden onderstaande generieke interactie principes: 4.1.2 Bouwblokken Iedere aanlevering is voorzien van een gestandaardiseerde set (conform het afgesproken koppelvlak) gegevens om het bericht op de juiste wijze te verwerken. Indien de technische verwerking van een verzoek (request) niet succesvol verlopen is, wordt er een SOAP fault verzonden. o Het foutbericht bevat een gedetailleerde beschrijving van de fout en een code waarmee in documentatie toelichting van de fout is te achterhalen. o Het foutbericht is op eenduidige wijze opgesteld: syntax (gedefinieerde velden voor foutbericht) en semantiek (standaard wijze van fout(code) opmaak) zijn gestandaardiseerd. Bouwblok Authenticatie Beveiliging Validatie Autorisatie: machtiging controleren Eis optioneel* * optioneel ziet op de eisen van de afnemer. Pagina 11 van 19

4.2 emededelen emededelen bestaat uit het ophalen van een bericht door een (gemachtigde) gebruiker uit een SBR-infrastructuur en verifiëren of diegene die het bericht ophaalt gerechtigd is dit te doen. 4.2.1 Interactie Hierbij gelden onderstaande generieke interactie principes: Ieder verzoek om een bericht op te halen is voorzien van gegevens om het op te vragen bericht te identificeren. Ieder verzoek om een bericht op te halen wordt getekend met een certificaat waarin identificerende gegevens van de gemachtigde zijn opgenomen. Indien de gebruiker geen kenmerk heeft van het op te halen bericht zal, voordat een bericht wordt opgehaald, moeten worden vastgesteld welke berichten opgehaald kunnen worden. Er wordt een lijst met klaarstaande berichten opgevraagd (totale lijst, of overzicht van mutaties sinds de vorige lijst) en daarna aan de hand van een specifiek kenmerk het bericht zelf. Indien de technische verwerking van een ophaalverzoek (request) succesvol verlopen is, wordt er een SOAP response verzonden. De SOAP respons bevat het op te halen bericht. Indien de technische verwerking van een verzoek (request) niet succesvol verlopen is, wordt er een SOAP fault verzonden. o Het foutbericht bevat een gedetailleerde beschrijving van de fout en een code waarmee in documentatie toelichting van de fout is te achterhalen. 4.2.2 Bouwblokken Bouwblok Authenticatie Beveiliging Validatie Autorisatie: machtiging controleren Eis 4.3 Statusinformatie De gebruiker dient op eenduidige wijze statusinformatie te kunnen inzien met betrekking tot de aangeleverde berichten. De statusinformatieservice is een webservice waarbij gebruikers informatie kunnen opvragen met betrekking tot het verwerkingsproces van een door hen zelf aangeleverd bericht. Er dient gecontroleerd te worden of een gebruiker gerechtigd is de statusinformatie in te zien. 4.3.1 Interactie Indien een afnemer na ontvangst van een bericht, eigen controles toepast op de berichtinhoud alvorens het bericht te accepteren voor inhoudelijke behandeling, dient de statusinformatie uit dit proces beschikbaar te worden gesteld via dezelfde service als de statusinformatie uit de SBR-infrastructuur. Pagina 12 van 19

Hiertoe dient een tussen afnemers gestandaardiseerde syntax (gedefinieerde velden voor statusbericht) en semantiek (standaard wijze van status(code) opmaak) te worden gebruikt. In documentatie dient aangegeven te worden welke statuscodes een 'eindstatus' betreffen en wat het juridische betekenis is van een bepaalde status. De documentatie en juridische betekenis kan per SBR-partner verschillen. De statusinformatie met betrekking tot aangeleverde berichten, kan op verschillende manieren worden opgevraagd: 1. Door het opgeven van een specifiek kenmerk, zoals ontvangen in de respons bij het aanleveren van het betreffende bericht, geeft de statusinformatieservice de statusinformatie met betrekking tot dit specifieke bericht terug. 2. Optioneel kan door het opgeven van een berichtsoort en eventueel een periode, een lijst met kenmerken van berichten opgevraagd worden, die onder een bepaalde berichtsoort zijn aangeleverd. Aan de hand van de ontvangen kenmerken kan vervolgens de statusinformatie, behorende bij de betreffende gegevens, worden opgevraagd volgens de methode onder punt 1. 4.3.2 Bouwblokken Bouwblok Authenticatie Beveiliging Validatie Autorisatie: machtiging controleren Eis * * indien statusinformatie niet wordt opgehaald met een zelfde certificaat als gebruikt bij aanlevering (overheid). Pagina 13 van 19

5 NPA: Bouwblokken Zoals in de scope is aangegeven wordt ieder SBR proces opgebouwd op basis van bouwblokken. Er wordt onderscheid gemaakt tussen functionele eisen en randvoorwaardelijke voorzieningen die gebruikt worden in de SBR infrastructuur om aan de functionele eisen te voldoen. 5.1 Algemeen 5.1.1 Niet-Functionele eisen Alle wijzigingen in een SBR infrastructuur worden op die wijze aangebracht dat het voor aangesloten partijen mogelijk blijft de bestaande functionaliteit een reële periode te blijven gebruiken alvorens over te gaan op gewijzigde functionaliteit. Iedere wijziging zal, waar mogelijk, worden ingeleid door een overgangsperiode, die na consultatie in de markt (expertgroep) is vastgesteld, om partijen de tijd te geven nieuwe functionaliteit te implementeren. Tijdens de overgangsperiode wordt de oude functionaliteit ondersteund. 5.1.2 Functionele eisen SBR informatie stromen worden system-2-system afgehandeld. Interactie met een SBR-infrastructuur gebeurt middels webservices. N:1:N: De SBR-infrastructuur kent zowel aan aanlever- als afleverkant meerdere koppelingen met ketenpartners. 1:1:1: Ieder bericht wordt vanuit 1 partij naar 1 partij verzonden. Berichten worden niet opgesplitst, samengevoegd of naar meerdere partijen verzonden. Berichtverwerking is transactiegewijs (in tegenstelling tot batchgewijs). Ieder bericht betreft één transactie en is zodanig te herkennen. Het endpoint waarop de webservice wordt aangesproken kan zowel generiek (voor meerdere berichtsoorten) als specifiek (per berichtsoort / operatie) worden ingezet. 5.1.3 Randvoorwaardelijke voorzieningen SBR implementaties door overheidspartijen gebruiken de door Digikoppeling voorgeschreven koppelvlak standaarden: o WUS voor bedrijven 2.0 versie 1.2 SBR implementaties door private partijen gebruiken op Digikoppeling gebaseerde koppelvlak standaarden om een zo groot mogelijke eenduidigheid naar de markt te creëren Pagina 14 van 19

5.2 Authenticatie 5.2.1 Functionele eisen De authenticiteit van systemen in de SBR-infrastructuur en van de gebruikers van een service moet door alle deelnemende partijen vastgesteld kunnen worden voordat een datacommunicatiesessie (transportniveau) wordt gestart. 5.2.2 Rand voorwaardelijke voorzieningen De verbinding tussen de client en de SBR-infrastructuur dient volgens het TLS/SSL-protocol met een certificaat opgezet te worden. De authenticiteit dient te worden gecontroleerd met behulp van PKIoverheid-certificaten (X.509). De geldigheid van het client certificaat dient aan de hand van de gegevens in het certificaat gecontroleerd te worden. Er dient tegen een Certificate Revocation List (CRL) gecontroleerd te worden of het certificaat niet is ingetrokken. 5.3 Beveiliging 5.3.1 Functionele eisen Op berichtniveau moet de integriteit van het bericht zelf vastgesteld kunnen worden (bericht is ongewijzigd tijdens transport). Hiertoe dienen aangeleverde berichten te worden ondertekend met een certificaat die voldoet aan de informatie beveiligingseisen voor het desbetreffende bericht. De ondertekening bestaat uit de met het certificaat versleutelde digest (hash van het bericht). 5.3.2 Randvoorwaardelijke voorzieningen Zowel het aanleverbericht (request) als het retourbericht (respons) wordt ondertekend (met behulp van PKIoverheidcertificaten (X.509) met de WS-Security standaard. Het bericht dient beveiligd te zijn met een handtekening over de SOAP body- en de SOAP header-elementen (die door de koppelvlakspecificaties zijn vereist), volgens het WS-Security protocol. 5.4 Autorisatie: machtiging controleren 5.4.1 Functionele eisen: Aanleveren De relatie tussen de verzender van een bericht (Gebruiker) en de belanghebbende kan (optioneel, door de eigenaar van de berichtstroom bepaald) worden vastgelegd in een extern machtiging register. Bij aanlevering van een bericht dient het adres van de AuSP meegegeven te worden zodat de SBR infrastructuur de machtigings relatie kan controleren. 5.4.2 Randvoorwaardelijke voorzieningen: Aanleveren Machtigingen ten behoeve van aanlevering van SBR berichten kunnen (optioneel) worden vastgelegd bij een extern Autorisatie Service Provider, welke het register door middel van een webservice beschikbaar stelt. 5.4.3 Functionele eisen: Statusinformatie De statusinformatie service controleert of de gebruiker voor elke status of kenmerk geautoriseerd is. Pagina 15 van 19

Een gebruiker is geautoriseerd als óf de statusinformatie wordt opgevraagd met hetzelfde certificaat waarmee het oorspronkelijke bericht is aangeleverd en het certificaat een PKIoverheidscertificaat is. Of een externe AuSP succesvol vaststelt dat de gebruiker geautoriseerd is de statusinformatie in te zien. 5.4.4 Randvoorwaardelijke voorzieningen: Statusinformatie Machtigingen ten behoeve van aanlevering van SBR berichten kunnen (optioneel) worden vastgelegd bij een extern Autorisatie Service Provider, welke het register door middel van een webservice beschikbaar stelt. 5.4.5 Functionele eisen: emededelen De relatie tussen de partij die een bericht ophaalt (Gebruiker) en de belanghebbende, in combinatie met de dienst waarop het betrekking heeft, dient expliciet te zijn vastgelegd in een machtiging register. Bij het ophalen van een bericht worden controles uitgevoerd ter autorisatie van de handeling: Het KvK nummer in het certificaat waarmee het bericht wordt opgehaald moet identiek zijn aan het nummer dat is vastgelegd in het machtigingen register. De relatie tussen het op te halen bericht (dienst / berichtsoort) en de gemachtigde wordt gecontroleerd op basis van identificerend nummer (KvK) van de gemachtigde in het certificaat. 5.4.6 Randvoorwaardelijke voorzieningen: emededelen Alle machtigingen ten behoeve van het ophalen van mededeling dienen te worden geregistreerd in het B2 machtigingen register. 5.5 Validatie 5.5.1 Functionele eisen Ieder aangeleverd bericht (inhoud) door een gebruiker wordt gevalideerd door de SBR infrastructuur om de kwaliteit van het ingestuurde bericht te toetsen en de gebruiker direct terugkoppeling te geven over de verwerkbaarheid van het bericht. Validatie kan o.a. plaatsvinden op basis van de voorgeschreven taxonomie. 5.5.2 Randvoorwaardelijke voorzieningen Alle XBRL berichten worden minimaal gevalideerd op: o XML validatie o XML schema validatie o XBRL validatie Pagina 16 van 19

6 Bijlage A: BPMN Procesplaten Procesplaat 1: NPA Wijzigen: Input Pagina 17 van 19

Procesplaat 2: NPA Wijzigen: Verwerken Input Pagina 18 van 19

Procesplaat 3: NPA Wijzigen: Vrijgeven Pagina 19 van 19