Assurance tijdens en na SEPA implementatie. Een SEPA framework ter identificatie van de risico s

Assurance tijdens en na SEPA implementatie Een SEPA framework ter identificatie van de risico s De doelstelling van dit onderzoek is het realiseren van een generiek SEPA framework waaraan de huidige SEPA implementatie (aanpak) binnen een organisatie getoetst kan worden op juistheid en volledigheid en daarmee risico s voor de continuïteit van het betalingsverkeer gedurende en na het implementatieproject kan identificeren. Nadine Lamotte 7/22/2013

Deze scriptie is geschreven als afstudeerproject van de IT Audit opleiding aan de Faculteit Economische en Bedrijfswetenschappen van de Vrije Universiteit Amsterdam. De supervisor voor dit onderzoek was Paul Harmzen, hoofddocent IT Audit opleiding aan de Vrije Universiteit. Nadine Lamotte Juli 2013 te Amsterdam Scriptie IT Audit 2013 Page 2

Inhoudsopgave Management samenvatting... 4 1. Inleiding... 6 2. Opzet van het onderzoek... 7 2.1 Aanpak van het onderzoek... 7 2.2 Verzamelen van onderzoeksgegevens... 8 2.3 Uitvoeren van de case study... 8 3. Beschrijving en oorsprong SEPA... 10 3.1 SEPA producten... 10 3.2 Oorsprong van SEPA... 19 3.3 Toelichting wet en regelgeving SEPA... 19 4. Ontwikkelen van een SEPA Framework... 22 4.1 Doel van het framework... 22 4.2 Totstandkoming van het framework... 22 4.3 Toelichting op gebruik van het framework... 23 5. Case study gebruik Framework... 29 5.1 Gebruik SEPA framework... 29 5.2 Samenvatting belangrijkste bevindingen... 40 6. Conclusie... 42 7. Implicaties voor het vakgebied van de IT auditor... 45 Bijlage A Literatuurlijst... 46 Bijlage B Betekenis van kleuren in framework... 47 Scriptie IT Audit 2013 Page 3

Management samenvatting Deze scriptie bespreekt de impact en risico s van de invoering van SEPA, presenteert een framework dat inzichtelijk maakt wat de impact van SEPA is op de betaalprocessen, en toetst dat het voorgestelde framework inzicht kan geven in de continuïteit van de betaalprocessen tijdens en na de implementatie van SEPA. SEPA is de verplichte standaard vanaf 1 februari 2014 voor het betalingsverkeer in zowel de nationale als de grensoverschrijdende euro betalingen binnen het SEPA gebied. De voornaamste veranderingen betreffen de overgang van BBAN naar IBAN, het verdwijnen van de acceptgiro, de overgang van overboekingen en incasso s op SEPA Credit Transfer en SEPA Direct Debit, het bijhouden en meesturen van mandaatinformatie en het gebruik van de ISO 20022 XML standaard. De risico s voor de continuïteit van de betaalprocessen zitten met name in de tijdigheid van de implementatie en het tot in detail voldoen aan de gegevenseisen en bestandsformaten, niet 100% voldoen aan de bestandsformaten zal leiden tot afgekeurde betalingsbestanden bij de bank. Het is voor organisaties cruciaal dat de continuïteit van de betaalprocessen ook na de invoering van SEPA gewaarborgd is. SEPA raakt in veel gevallen de hele organisatie en moet met name in de aanlevering naar de banken tot in de details correct geïmplementeerd zijn. Dit document geeft een beschrijving van de key onderdelen van SEPA, namelijk IBAN, ISO 20022 XML, SEPA Credit Transfer, SEPA Direct Debit, Mandaatmanagement en Tijdslijnen. Deze scriptie presenteert een SEPA framework die inzichtelijk maakt welke key onderdelen van SEPA op koers liggen of reeds voldoen aan de SEPA requirements en op welke key onderdelen extra aandacht gelegd moet worden om de continuïteit van de betaalprocessen te blijven waarborgen. Het SEPA framework is ontwikkeld op basis van de Verordening 260/2012 van de Europese Commissie en het Nationaal Migratieplan en vormt een generiek toetsingskader om op diverse punten van het SEPA implementatie project inzicht te krijgen in de juistheid en de volledigheid van de geplande SEPA implementatie. Het framework is getoetst door middel van een case study bij een Nederlandse verzekeraar. Dankzij de toepassing van het framework werden risico s gesignaleerd ten aanzien van de invoering van de IBAN, het hanteren en converteren van bestaande machtigingen naar mandaten en de haalbaarheid van de tijdslijnen gesteld door NFS. Op basis van de evaluatie kunnen we concluderen dat het framework een goed inzicht geeft in de mate waarin een organisatie reeds aan de SEPA requirements voldoet en op welke key onderdelen van SEPA de risico s ten aanzien van de continuïteit van de betaalprocessen liggen. De toepassing van het framework heeft er toe geleid dat de verzekeraar inzicht heeft gekregen in de continuïteitsrisico s van de betalingsprocessen. Hieruit kan geconcludeerd worden dat het framework voldoende diepgang heeft en de focus legt op de belangrijkste elementen van SEPA. Naar aanleiding van de evaluatie met de verzekeraar is een globaal overzicht met de key elementen van SEPA en de risicoscore opgenomen in het SEPA framework. Echter, door de toetsing van het framework bij een enkele organisatie in één Scriptie IT Audit 2013 Page 4

sector, is de hanteerbaarheid van het framework op brede schaal nog niet aangetoond. Vervolgonderzoek kan uitwijzen in hoeverre het framework ook generiek toepasbaar is. Scriptie IT Audit 2013 Page 5

1. Inleiding In februari 2012 werd bekend dat de Europese Commissie een deadline stelt aan de invoering van SEPA. Vanaf 1 februari 2014 is SEPA de verplichte standaard voor het betalingsverkeer in zowel de nationale, als de grensoverschrijdende euro betalingen. Wanneer een organisatie niet volgens deze standaard kan werken bestaat het risico dat de organisatie geen betalingen en/of geen automatische verwerking van afschriften kan uitvoeren na 1 februari 2014. Sinds de bekendmaking van de deadline worden organisaties en banken door de overheden, nationale banken en Europese bank geïnformeerd en gemonitored op de voortgang van de SEPA implementatie. Gezien het risico op het niet kunnen uitvoeren van betalingen zijn grote betaalorganisaties (denk bijvoorbeeld aan verzekeraars) en banken op zoek naar een wijze om zekerheid te verkrijgen over de mate waarin zij voldoen aan de SEPA wet en regelgeving. Daarom is de hoofdvraag van dit onderzoek als volgt geformuleerd: Hoe krijgt een organisatie zekerheid dat de continuïteit van de betaalprocessen na de implementatie van SEPA geborgd is? Om deze hoofdvraag goed te kunnen beantwoorden zal deze scriptie starten met het beschrijven van de gehanteerde onderzoeksmethode in hoofdstuk 2. De achtergrond, impact en risicoʹs van SEPA worden in hoofdstuk 3 besproken. Hoofdstuk 4 introduceert een framework dat gebaseerd is op de nieuwste wet en regelgeving, dat in hoofdstuk 5 getoetst wordt in de praktijk. Deze stappen zijn hieronder uiteengezet in deelvragen die in de genoemde hoofdstukken behandeld worden. Hoofdstuk 6 en 7 geven een antwoord op de onderzoeksvraag en de implicaties die dit onderzoek heeft voor de IT auditor. Deelvraag Hoofdstuk 1 Wat is SEPA en waar heeft dit impact op de huidige betaalprocessen? Hfds 3 2 Wat zijn de risicoʹs van het implementeren van SEPA en daarbij Hfds 3 behorende betalingsproducten (SEPA Credit Transfer en SEPA Direct Debit) met betrekking tot de continuïteit van de betaalprocessen en de organisatie? 3 Wat zijn de requirements vanuit de wet en regelgeving voor SEPA Hfds 4 compliancy (framework)? 4 Wat is het resultaat van het gebruik van het framework? Hfds 5 5 Kan het framework voldoende zekerheid geven over de continuïteit van de betaalprocessen na de implementatie van SEPA? Hfds 5 De scope van dit onderzoek beperkt zich tot de betaalprocessen en IT oplossingen binnen organisaties in Nederland. Het bredere change management proces (wijzigingen communiceren binnen organisatie, training en acceptatie beleid) valt buiten scope. Ook de implementatie van SEPA binnen organisaties buiten Nederland vallen buiten scope. Andere Scriptie IT Audit 2013 Page 6

Euro landen ervaren mogelijk andere implementatie problemen in vergelijking met Nederland. Het identificeren en onderzoeken van deze implementatieproblemen kan in verband met de beperkte tijd voor dit onderzoek niet uitgevoerd worden. 2. Opzet van het onderzoek Dit hoofdstuk beschrijft de wijze waarop het onderzoek is opgezet en uitgevoerd, inclusief een rationale voor deze werkwijze. Het onderzoeksontwerp beschrijft het raamwerk waarbinnen het verzamelen van gegevens en het analyseren van deze gegevens wordt uitgevoerd [A1]. Het onderzoeksontwerp wordt toegelicht om herhaling van het onderzoek mogelijk te maken en daarmee de resultaten te kunnen valideren. 2.1 Aanpak van het onderzoek Om de hoofdvraag te beantwoorden, wordt een kwalitatief onderzoek uitgevoerd. Het doel van het onderzoek zal zijn om een antwoord te vinden op de vraag op welke wijze organisaties de continuïteit van hun betaalprocessen kunnen waarborgen na de implementatie van SEPA. Binnen het auditvak is het gebruik van frameworks een dagelijkse praktijk en herkenbaar voor zowel de beroepsgroep, als de geauditeerde klant. Door middel van het voorstellen van een (getoetst) framework, wordt een bruikbare bijdrage geleverd aan zowel de beroepsgroep, als aan organisaties die meer grip willen krijgen op de implementatie van SEPA. Het framework is gebaseerd op de requirements zoals deze gesteld zijn in de wet en regelgeving [A4] en het migratieplan dat opgesteld is door De Nederlandsche Bank om tijdige SEPA implementatie binnen Nederland te sturen en te waarborgen [A5]. De scope van dit onderzoek beperkt zicht tot de SEPA implementatie in Nederland. Het onderzoek richt zich met name op betaalprocessen en IT oplossingen binnen de organisatie. In dit onderzoek is ervoor gekozen om de case study bij één grote Nederlandse verzekeringsmaatschappij uit te voeren. Deze organisatie is zeer sterk afhankelijk van haar betalingsverkeer en de impact van de SEPA is derhalve groot. Door het uitvoeren van de case study bij één organisatie kan een redelijk beeld gegeven worden over de bruikbaarheid van het voorgestelde framework, maar ook een inzicht geven in de manier van gebruiken en verbeterpunten. Het framework is eerst in concept versie gemaakt, deze versie is gebruikt voor het onderzoek bij de verzekeraar. Tijdens de bespreking van de resultaten naar aanleiding van het onderzoek is ook het gehanteerde framework besproken om zo tot verbeteringen te komen. Scriptie IT Audit 2013 Page 7

2.2 Verzamelen van onderzoeksgegevens Voor dit onderzoek zijn gegevens uit verschillende bronnen gehanteerd. Hieronder is in Tabel 1 een beknopt overzicht van de belangrijkste bronnen. Deelvragen 1 Wat is SEPA en waar heeft dit impact op de huidige betaalprocessen? 2 Wat zijn de risicoʹs van het implementeren van nieuwe betalingsproducten met betrekking tot de continuïteit van de betaalprocessen en de organisatie? 3 Wat zijn de requirements vanuit de wet en regelgeving voor SEPA compliancy (framework)? 4 Wat is het resultaat van het gebruik van het framework? 5 Kan het framework voldoende zekerheid geven over de continuïteit van de betaalprocessen na de implementatie van SEPA? Tabel 1 Bron Zie Appendix A Zie Appendix A a. Wet en regelgeving, met name Verordening EU 260/2012 d.d. 14 maart 2012 [A4] b. Nationaal SEPA migratie plan d.d. 17 maart 2012 [A5] Onderzoek bij verzekeringsorganisatie op basis van: a) Inspectie van documentatie b) Houden van interviews Beantwoording van de deelvragen 1 tot en met 4 Een vijftal (deel )onderzoeksvragen zijn geformuleerd om tot een antwoord van de hoofdvraag te komen. Deze onderzoeksvragen worden beantwoord door gebruik te maken van verschillende methode van gegevensverzameling. Vraag 1 en 2 over het huidige betalingsverkeer en de beschrijving wat SEPA is, worden beantwoord door een literatuurstudie. Vraag 3 gaat over de SEPA requirements: deze zullen worden vastgesteld aan de hand van de wet en regelgeving van de Europese Commissie. Tenslotte zullen vraag 4 en 5 over het gebruik van het framework worden beantwoord door het toetsen van het framework bij een Nederlandse verzekeraar. 2.3 Uitvoeren van de case study In deze paragraaf is de methode case study nader toegelicht. Een case study is een methode vergelijkbaar met een experiment of simulatie [A2]. Deze methode wordt regelmatig gebruikt voor het toetsen van een nieuwe methode of techniek [A3]. In deze scriptie wordt een framework ontworpen aan de hand van wet en regelgeving met als doel een organisatie een bepaalde mate van zekerheid te kunnen bieden over de continuïteit van haar betalingssystemen na de implementatie van SEPA. De case study zal plaatsvinden door het gebruik van het ontworpen framework in een bestaande organisatie. Op deze wijze wordt de Scriptie IT Audit 2013 Page 8

bruikbaarheid van het framework getoetst, worden verbeterpunten geconstateerd en geeft de case study een inzicht in de mogelijkheid een bepaalde mate van zekerheid over de continuïteit van de betaalprocessen na de implementatie van SEPA te kunnen verschaffen. De case study, of toetsing van het voorgestelde framework heeft plaatsgevonden bij een Nederlandse verzekeringsmaatschappij. De verzekeraar heeft als doel om de continuïteit van de betaalprocessen na de implementatie van SEPA te waarborgen. Daarbij wil de verzekeraar de kans op verstoringen tijdens en na de implementatie zoveel mogelijk beperken en in ieder geval niet groter laten worden dan de kans op verstoringen in de huidige non SEPA situatie. Om de verzekeraar te helpen is het SEPA framework gehanteerd als basis om de volledigheid van de aanpak voor de SEPA implementatie te toetsen. Tijdens de case study is zowel het framework als methodiek, als de aanpak van de SEPA implementatie bij de verzekeraar getoetst. Tijdens het uitvoeren van de case study zijn de volgende werkzaamheden uitgevoerd: Kick off meeting met de project leiders, business analisten en eindverantwoordelijken voor het betalingsverkeer. In deze meeting werd het framework en aanpak toegelicht. Inlezen in beschikbare documentatie, deze bestond uit: o Impact analyses van SEPA implementatie op huidige betaal en klantprocessen en IT systemen. o Communicatie naar de projectgroep Houden van interviews met de business analisten en project leiders Opleveren van een rapportage aan de verzekeraar gebaseerd op het framework, met daarin beschreven de huidige situatie, het plan van aanpak voor de SEPA implementatie en de mogelijk bevindingen die hierbij gezien werden. Evaluatie van gehanteerde aanpak met het SEPA framework en het algemene resultaat naar aanleiding van het gebruik van het SEPA framework met de verzekeraar. Het gehele proces is in een tijdbestek van 2 maanden uitgevoerd in de zomer van 2012. Scriptie IT Audit 2013 Page 9

3. Beschrijving en oorsprong SEPA Dit hoofdstuk heeft als doel om de SEPA producten, de achtergrond, en de onderliggende wet en regelgeving te beschrijven om een beeld te scheppen van de veranderingen die de implementatie van SEPA bij organisaties met zich mee brengen. SEPA zal beschreven worden aan de hand van de volgende key onderdelen: IBAN, ISO 20022 XML, SCT, SDD, Mandaatmanagement en Tijdslijnen gesteld door de wetgevers. Dit hoofdstuk begint met de beschrijving van de SEPA producten SEPA Credit Transfer en SEPA Direct Debit. Om deze goed te kunnen beschrijven is het nodig om ook de IBAN (rekeningnummer gehanteerd in SEPA producten) te beschrijven. Vervolgens gaat dit hoofdstuk kort in op de achtergrond van de implementatie van SEPA. Het hoofdstuk eindigt met de beschrijving van de onderliggende wet en regelgeving. Deze wet en regelgeving vormt de basis van het SEPA framework voor het toetsen van continuïteit van de betaalprocessen na de implementatie van SEPA. 3.1 SEPA producten Binnen de SEPA wet en regelgeving zijn een tweetal betaalproducten onderkend, namelijk de SEPA Credit Transfer en de SEPA Direct Debit. De SEPA Credit Transfer kennen wij nu als overboeking, het initiatief van de betaling ligt bij de betaler. De SEPA Direct Debit kennen wij nu als incasso, hierbij ligt het initiatief voor de betaling bij de ontvanger. Om deze producten door de EU op een eenduidige wijze te gebruiken heeft de Europese Commissie het formaat van het bankrekeningnummer (IBAN) en de berichtenstandaard (ISO 20022 XML) vastgelegd in wet en regelgeving, zie ook paragraaf 3.3. In de sub paragrafen 3.1.1 tot en met 3.1.6 wordt dieper ingegaan op de SEPA producten en daar bijbehorende standaarden. 3.1.1 IBAN Beschrijving In Nederland wordt momenteel het 9 cijferig rekeningnummer (bank) of 7 cijferig rekeningnummer (giro) gehanteerd. Dit wordt ook wel de Basic Bank Account Number, oftewel BBAN genoemd. Voor internationale transacties en ook voor SEPA transacties wordt de IBAN gehanteerd. IBAN staat voor International Bank Account Number en kan uit maximaal 34 tekens bestaan. De IBAN is opgebouwd uit vier onderdelen, namelijk de landidentificatie, een controlegetal, de bankidentificatie en het rekeningidentificatienummer zoals deze bekend is bij de bank. De landidentificatie bestaat uit 2 tekens welke aangeven in welk land het rekeningnummer geregistreerd staat. Voor Nederland zijn deze tekens NL, voor Belgie BE, voor Duitsland DE etc. Het controlegetal bestaat uit 2 tekens en is een getal welke gebruikt kan worden om de validiteit van de IBAN te berekenen. Op de rekeningnummers die nu gehanteerd worden, kan een zogenaamde elf proef gebruikt worden om te controleren of het geregistreerde rekeningnummer een valide rekeningnummer is. De elfproef is niet toepasbaar op de IBAN. Scriptie IT Audit 2013 Page 10

Voor de IBAN is daarom een zogenaamde 97 proef ontwikkelt, welke gebruik maakt van het controlegetal. De bankidentificatie bestaat uit 4 tekens, cijfers en/of letters. Deze bankidentificatie geeft aan bij welke bank het achterliggende rekeningnummer hoort. De verschillende landen in de SEPA zone representeren hun bankidentificatie anders. In Nederland worden de 4 tekens gebruikt voor letters. Een rekening behorende bij de ABN AMRO heeft dan ook als bankidentificatie de letters ABNA, een rekening behorende bij de ING Bank heeft als bankidentificatie in de IBAN INGB. Ander landen, waaronder bijvoorbeeld Duitsland hanteren 4 cijfers om de bank waar de rekening bij hoort aan te duiden, bijvoorbeeld bankidentificatie 3704 staat voor Commerzbank. De rekeningidentificatie bestaat uit een aantal cijfers. In totaal mag de IBAN niet langer zijn dan 34 tekens. De verschillende landen hanteren verschillende lengtes voor de rekeningidentificatie. Als we naar Nederland kijken, dan zien we dat de rekeningidentificatie in de IBAN altijd 10 cijfers is. Het bankrekeningnummer met 1 of meerdere voorloopnummers (dit is nodig in het geval van een girorekening). Een Nederlands IBAN bestaat daarom uit precies 18 tekens. Buitenlandse IBAN nummers kunnen tot 34 tekens lang zijn. Impact op het betaalproces De impact en de hoeveelheid werk die de overgang van BBAN naar IBAN met zich meebrengt verschilt per organisatie. Dit is onder andere afhankelijk van de grootte van de organisatie, in welke mate processen geautomatiseerd zijn en of er sprake is van legacy systemen. De overgang van BBAN naar IBAN betekent voor veel organisaties dat er wijzigingen moeten plaatsvinden. De wijzigingen kunnen op verschillende niveaus plaatsvinden. Te denken valt aan aanpassingen in de administratiesystemen (software), het aanpassen van het huidige bestand van rekeningnummers, maar ook het aanpassen van de communicatiemiddelen. Administratiesystemen/software: De administratiesystemen moeten de IBAN kunnen opslaan en accepteren in de rekeningvelden. Dit betekent dat de rekeningvelden rekeningnummers tot 34 tekens moeten kunnen accepteren, maar daarbij ook een reeks van cijfers en letters moeten kunnen accepteren in tegenstelling tot de huidige situatie met alleen cijfers. Administratie systemen bevatten veelal ook een automatische elf proef welke het ingevoerde rekeningnummer valideert. Deze elf proef moet vervangen worden door de 97 proef. De IBAN moet voortaan meegegeven worden in het aanmaken van betalingsbestanden of het handmatig aanmaken van een overboeking. Dit verandert niet zozeer het proces, alswel de gegevens die benodigd zijn tijdens het proces. Omzetten BBAN naar IBAN: In de huidige situatie worden betalingen verwerkt met behulp van de BBAN. Veel organisaties hebben een administratie waarbij de BBAN van klanten en leveranciers is vastgelegd en als input wordt gebruikt om betalingen (overboekingen en incasso s) uit te sturen. De administratie met BBAN moet eenmalig overgezet worden naar IBAN, zodat Scriptie IT Audit 2013 Page 11

deze administratie kan blijven dienen als input voor de rekeningnummers voor de betaaltransacties. Aanpassen van communicatie naar klanten/leveranciers/medewerkers: De bankgegevens van de organisatie die vermeld worden op communicatiemiddelen zoals facturen, brieven en websites moeten aangepast worden naar het IBAN nummer. Bij het aanmelden van nieuwe klanten/leveranciers/nieuwe medewerkers moet de IBAN opgevraagd worden in plaats van de BBAN. 3.1.2 BIC Beschrijving De BIC staat voor Bank Identifier Code en wordt gebruikt naast de IBAN. De BIC geeft aan bij welke bank de IBAN geregistreerd staat. De BIC codes zijn per bank door SWIFT vastgesteld. De BIC bestaat uit 8 of 11 tekens. Een BIC die uit 8 tekens bestaat is opgebouwd uit de bankaanduiding, de landcode en de stadcode. Een BIC die uit 11 tekens bestaat, heeft aanvullend hierop een aanduiding voor het kantoor waar het rekeningnummer is geregistreerd. De bankaanduiding bestaat uit 4 tekens welke de bank aangeven. In Nederland zijn dat bijvoorbeeld ABNA voor ABN AMRO en INGB voor ING Bank, vergelijkbaar zoals in de IBAN. De landcode bestaat uit 2 tekens en geeft de identificatie van het land, bijvoorbeeld voor een BIC van een Nederlandse bank is dit NL. De stadcode bestaat uit twee tekens en voor Nederlandse BIC s geldt dat deze tekens de stad waar het hoofdkantoor staat aangeven. Voor ABN AMRO is 2A, waarbij de A voor Amsterdam staat. Voor Rabobank is dat stadcode 2U, waarbij de U voor Utrecht staat. De kantooraanduiding bestaat uit 3 tekens en is facultatief om te gebruiken. De BIC code is een vanuit de wet en regelgeving verplicht om mee te sturen in SEPA transacties. In Nederland hebben de banken onderling overleg gevoerd over de deadlines van 1 februari 2014 en 1 februari 2016 voor het verplicht meesturen van de BIC bij transacties. De banken zijn overeengekomen dat de BIC voor Nederlandse transacties per 1 januari 2013 al aangevuld kan worden door de banken zelf. Een aantal banken heeft aangegeven dat zij de BIC ook voor SEPA overboekingen over de landsgrenzen heen ook al kan aanvullen. Voor organisaties betekent dit dat zij een afweging kunnen maken of zij de BIC in hun systemen willen administreren. Organisaties die beperkte of geen overboekingen naar het buitenland doen en dit ook niet zien veranderen in de komende drie jaar, kunnen er nu voor kiezen om de BIC niet te administreren en dit direct door de bank te laten aanvullen. In het geval van legacy systemen, waarbij het toevoegen van een extra veld complex kan zijn, kan het een gunstige invloed hebben op het implementatie traject voor SEPA met betrekking tot tijd en kosten. Scriptie IT Audit 2013 Page 12

Impact op het betaalproces De impact voor organisaties op het betaalproces is vergelijkbaar met de punten die bij IBAN genoemd zijn. Een enkele aanvulling is hieronder beschreven: Administratiesystemen/software: Wanneer wordt gekozen om de BIC te hanteren en mee te sturen in het betaalbestand zal de BIC ook geadministreerd moeten worden. 3.1.3 SEPA Credit Transfer (SCT) Beschrijving De SEPA Credit Transfer is een girale overboeking. De betaler moet voor het gebruik van SEPA Credit Transfer de IBAN en BIC van de ontvanger aanleveren, in plaats van het huidige bankrekeningnummer. Ook zijn er meer invulvelden beschikbaar voor de betaler, het volledige adres van de ontvanger kan meegegeven worden, maar ook het opmerkingenveld is ruimer geworden. De ontvanger ziet op zijn/haar rekeningafschrift de IBAN en BIC van de betaler, eventueel het adres en het gehele opmerkingenveld (mits gevuld door de betaler). Hieronder is in Figuur 1 een schematische tekening van de SEPA Credit Transfer procesflow. Het SEPA Credit Transfer proces loopt als volgt: De betaler wil een betaling doen aan de ontvanger. De reden hiervoor kan verschillend zijn, te denken valt bijvoorbeeld aan het betalen van online gekocht product, het betalen van een rekening, het overmaken van salaris etc. De betaler voert de betaalinstructie in. Dit kan in het boekhoudprogramma, in de internetbankierenomgeving of via een SEPA overboekingsformulier. De betaalinstructie bevat de IBAN en BIC van de betaler en de ontvanger, een omschrijving en een uniek transactie ID, welke door de hele keten wordt meegestuurd. De betaalinstructie wordt door de bank van de betaler ontvangen. In het geval dat de betaling binnen de bank blijft, verwerkt de bank de betaling zelf. In het geval dat de betaling naar een rekening van een andere bank moet, wordt de betaalinstructie naar een betalingsdienstverlener gestuurd. Een voorbeeld hiervan in Nederland is Equens. De betalingsdienstverlener verwerkt de betaling en stuurt de betaling naar de bank van de ontvanger. De bank van de ontvanger ontvangt de betaling en schrijft het bedrag, inclusief de gegevens van de betaler, de omschrijving en het transactie ID bij op de rekening van de ontvanger. Scriptie IT Audit 2013 Page 13

Figuur 1 SCT procesflow Impact op het betaalproces Het proces van de SCT verschilt niet ten opzichte van de huidige manier voor het doen van overboekingen. De betalingen worden verzameld door de organisatie en aangeboden aan de bank. De verwerking wordt verder afgehandeld door de bank, eventueel met behulp van een betalingsdienstverlener. Na de verwerking van de betalingen wordt een rekeningafschrift op papier, danwel electronisch naar de organisatie verstuurd. De invoer van SEPA heeft wel invloed op de wijze van aanlevering van de betaalbestanden en het verwerken van de retourinformatie, of bankafschriften, zie hieronder. Administratiesystemen/software: De software die de betalingen verzamelt en bij elkaar voegt om er een betaalbestand van te maken, zal enkele wijzigingen moeten doormaken: IBAN i.p.v. BBAN opvragen/aangeleverd krijgen en deze meenemen in de transacties Betalingen in het ISO 20022 XML bestand maken i.p.v. de ClieOp Organisaties hebben vaak ook software (boekhoudprogramma s) welke rekeningafschriften van banken automatisch kunnen inlezen. De impact op deze software beslaat in ieder geval de volgende punten: De huidige rekeningafschriften (GMU, MT940, etc) worden uitgefaseerd. Scriptie IT Audit 2013 Page 14

Banken zullen rapporteren in MT940 structured of MT940 extended. Deze formaten kunnen verschillen per bank. Software systeem zal per bank het afschrift moeten kunnen inlezen. Op termijn zal ook de CAMT053 beschikbaar komen, dit is de ISO 20022 XML variant voor de rekeningafschriften of terugmeldingen van betalingen. De software zal dan ook XML moeten kunnen inlezen. 3.1.4 SEPA Direct Debit (SDD) Beschrijving De SEPA Direct Debit is een automatische afschrijving, ofwel een incasso. Een incasso is een betaling die verstuurd wordt vanuit de ontvangende partij aan de betalende partij. De ontvangende partij verstuurt een betaalverzoek aan haar bank, met daarin dezelfde velden als bij de SCT, aangevuld met velden voor machtiging informatie en het soort incasso. Hieronder is in Figuur 2 een schematische tekening van de SEPA Direct Debit procesflow. Figuur 2 SDD procesflow Het SEPA Direct Debit proces loopt als volgt: De ontvanger en de betaler hebben een contract afgesloten voor het leveren van een dienst, bijvoorbeeld het leveren van een verzekering. Bij het afsluiten van het contract is opgenomen dat de betaling voor het leveren van de verzekering plaatsvindt middels het SEPA Direct Debit product. De klant ondertekent een fysiek formulier waarop staat dat de verzekeraar voor het afgesproken product, bedrag en termijn een SEPA Direct Debit mag insturen om het verschuldigde bedrag te incasseren. Dit fysieke formulier wordt een mandaat genoemd, deze is ook wel bekend als machtiging. Dit mandaat wordt door de verzekeraar Scriptie IT Audit 2013 Page 15

gedematerialiseerd, wat betekent dat de NAW gegevens, de datum van ondertekening en het unieke mandaatreferentienummer worden opgeslagen in een database. Deze gegevens worden met elke SEPA Direct Debit meegestuurd, zodat de klant/betaler ten alle tijd kan zien waar de incasso vandaan komt en onder welk mandaat geincasseerd wordt. Vervolgens maakt de verzekeraar een betaalbestand met SEPA Direct Debits aan en verstuurt deze naar haar bank. In dit bestand staan per SDD de IBAN, de mandaatinformatie en of het een eerste, eenmalige of herhalende incasso betreft. De bank ontvangt dit bestand en wanneer de SDD binnen de bank blijft, verwerkt de bank de incasso zelf. In het geval dat de SDD naar een rekening van een andere bank moet, wordt de betaalinstructie naar een betalingsdienstverlener gestuurd. De betalingsdienstverlener verwerkt de SDD en stuurt de incasso naar de bank van de klant/betaler. De bank van de betaler ontvangt het bestand en debiteert de IBAN van de betaler en stuurt dit bedrag naar de betalingsdienstverlener die het SDD verzoek stuurde. De betalingsdienstverlener ontvangt het bedrag en stuurt dit bedrag door naar de bank die het SDD verzoek stuurde. De bank van de verzekeraar schrijft het ontvangen bedrag bij op de IBAN van de verzekeraar. Impact op het betaalproces De impact en de hoeveelheid werk die de overgang van incasso naar SDD met zich meebrengt verschilt per organisatie. Dit is onder andere afhankelijk van de grootte van de organisatie, in welke mate processen geautomatiseerd zijn en of er sprake is van legacy systemen. De overgang van incasso naar SDD betekent voor de meeste organisaties die incasso s hanteren dat er wijzigingen moeten plaatsvinden. De wijzigingen kunnen op verschillende niveaus plaatsvinden. Te denken valt aan aanpassingen in de administratiestystemen (software), het aanpassen van het huidige bestand van machtigingen, maar ook het aanpassen van de communicatiemiddelen. Administratiesystemen/software: IBAN i.p.v. BBAN opvragen/aangeleverd krijgen en deze meenemen in de transacties Betalingen in het ISO 20022 XML bestand maken i.p.v. de ClieOp Mandaatgegevens moeten beschikbaar komen in administratie, een digitale mandaatadministratie moet worden opgezet Mandaatgegevens meesturen in SDD bestanden Mandaatadministratie en mandaatbeheerproces moet worden ingericht SDD bestanden moeten met verschillende tijdslijnen bij de bank aangeleverd worden (5 dagen voor de verwerkingsdag voor eerste en eenmalige SDD s, 2 dagen voor de verwerkingsdag voor herhalende transacties) SDD bestanden moeten onderscheid maken in Core transacties en B2B transacties, dit mag niet in 1 bestand zitten. Conversie machtigingen naar mandaten: In de huidige situatie worden machtigingen op verschillende wijze verkregen en bewaard. Organisaties laten een machtigingformulier tekenen, vragen een machtigingsakkoord via de telefoon of laten de klant een vinkje op een website aanklikken om zo tot toestemming voor het incasseren te komen. Deze machtigingen worden op papier of digitaal bewaard. Alle bestaande machtigingen moeten een uniek kenmerk krijgen Scriptie IT Audit 2013 Page 16

Alle bestaande machtigingen die geconverteerd worden naar mandaten moeten de tekendatum van 1 11 2009 krijgen. Dit is afgesproken op Europees niveau om geconverteerde machtigingen altijd te kunnen herkennen Alle bestaande machtigingen moeten digitaal geregistreerd worden bij de organisatie Aanpassen van communicatie naar klanten/leveranciers/medewerkers: Klanten moeten geïnformeerd worden over het mandaatkenmerk en CreditorID. De CreditorID is de identificatie van de incasserende organisatie, waaraan de klant kan herkennen wie de incasso uitvoert. Klanten moeten tenminste 14 dagen voor de verwerkingsdag geïnformeerd worden over het bedrag en de datum van de SDD, tenzij anders afgesproken met de klant. Algemene voorwaarden (of andere documenten) aanpassen naar de informeringstermijn voor de incasso s, indien afgeweken wordt van 14 dagen voorafgaand aan de SDD. 3.1.5 ISO 20022 XML Beschrijving ISO 20022 XML is de berichten standaard die in Verordening 260/2012 is vastgelegd als zijnde de standaard die voor het SEPA berichten verkeer gehanteerd dient te worden [A4]. De ISO 20022 XML standaard is een ISO standaard ontwikkeld voor het financiële berichtenverkeer [A7]. De ISO 20022 XML standaard geeft de mogelijkheden om de berichten vorm te geven op basis van het financiële proces dat doorlopen wordt. Voor de SEPA producten SCT en SDD zijn de invulling, gebruik en gebruiksregels van de ISO 200022 XML vastgelegd in aparte Rulebooks en Implementation Guidelines. Deze rulebooks zijn sinds de introductie van de beide producten ieder jaar gewijzigd en deze aanpassing zijn ook gewijzigd in het betalingsverwerkingsproces. Voor de SEPA deadline van 1 februari 2014 zal er geen nieuw rulebook meer uitkomen. Wel moeten de rulebooks die in 2012 zijn gepubliceerd voor de SEPA deadline van 1 februari 2014 geïmplementeerd zijn [A8]. Impact op het betaalproces Het hanteren van ISO 20022 XML berichtenstandaard heeft op het betaalproces zelf geen impact. Het hanteren van XML heeft wel impact op de wijze waarop betalingsbestanden worden aangemaakt en hoe deze eruit zien. Software: Software moet de betalingen in het ISO 20022 XML bestand maken i.p.v. de ClieOp Software moet in staat zijn om NAW gegevens van de ontvanger, danwel betaler, mee te sturen in het betalingsbestand Software moet voor verschillende banken een ander formaat aanleveren. De verschillen zijn miniem, maar cruciaal om het bestand geaccepteerd te krijgen bij de bank. De rulebooks moeten jaarlijks geëvalueerd worden en wijzigingen op de bestandsformaten moeten doorgevoerd worden. Scriptie IT Audit 2013 Page 17

Communicatie/externe partijen Nieuwe contracten moeten afgesloten worden met de banken om XML bestanden te mogen aanleveren 3.1.6 Acceptgiro Beschrijving De acceptgiro is een typisch Nederlands betaalproduct. Het is een overboekingformulier met een specifieke layout wat het voor de bank mogelijk maakt om het formulier electronisch in te lezen [A9]. De acceptgiro bevat verschillende velden voor het bedrag, het rekeningnummer, de begunstigde, het kenmerk van de betaling en de handtekening van de betaler. In Nederland worden acceptgiro s gebruikt om betalingen te doen, bijvoorbeeld voor het afnemen van een dienst, maar ook om een bijdrage aan een goed doel te leveren of een eenmalige of niet regelmatige rekening te betalen, denk bijvoorbeeld aan gemeente belastingen. De acceptgiro kan ingeleverd worden bij de bank, verstuurd worden per post of via internetbankieren ingevoerd worden. Inmiddels worden in Nederland de meeste acceptgiro s via een internetbankieren overgemaakt. De acceptgiro is niet beschikbaar in andere EU landen en is dus geen europees breed product. Om deze reden heeft de Europese commissie geen SEPA alternatief voor de acceptgiro ontwikkelt en is de acceptgiro niet meegenomen in de wet en regelgeving van SEPA. In Nederland wordt de acceptgiro nog volop gebruikt en om deze reden heeft de Nederlandse overheid bij de ECB een uitstel gevraagd voor het tijdelijk blijven gebruiken van de acceptgiro, een zogenoemd niche product. Dit uitstel is verleend en Nederland mag de acceptgiro blijven hanteren tot 1 januari 2019, daarna moet de acceptgiro uitgefaseerd zijn. De acceptgiro is een manier van het initieren van een betaalinstructie, een overboeking. Het equivalent in SEPA hiervoor is het een SCT. Na 1 februari 2014 worden alle overboekingen via een SCT uitgevoerd, onafhankelijk van de wijze van aanleveren van de betaalinstructie. Het aanleveren van een acceptgiro zal dus ook leiden tot een SCT. Om deze reden zijn een aantal wijzigingen op de acceptgiro in gang gezet. Vanaf juli 2013 is de zogeheten IBANacceptgiro klaar voor gebruik. Deze IBAN acceptgiro verschilt op een aantal punten van de huidige acceptgiro, zo is het bijvoorbeeld verplicht om de IBAN in te vullen ipv het BBAN nummer. Daarnaast is de begunstigde rekenining ook een IBAN nummer, zowel op de controlestrook als de acceptgiro zelf. De layout van de IBAN acceptgiro is gewijzigd ten opzichte van het de huidige acceptgiro. Dit betekent dat de drukmachines die acceptgiro s printen opnieuw ingesteld moeten worden. Ook de machines die de acceptgiro s automatisch inlezen moeten opnieuw ingesteld worden om de correcte informatie van de acceptgiro af te halen. Impact op het betaalproces Het proces voor het gebruiken van de acceptgiro verandert niet door de komst van SEPA en de SEPA acceptgiro. Wel zijn er wijzigingen nodig in de software om de SEPA acceptgiro te blijven hanteren. Daarbij zal de SEPA acceptgiro uitgefaseerd worden en is de deadline hiervoor 1 januari 2019. Organisaties zullen voor die tijd alternatieve betaaloplossingen moeten implementeren en aanbieden. Scriptie IT Audit 2013 Page 18

Administratiesystemen/software: Acceptgiro moet IBAN ontvanger bevatten Acceptgiro moet aan nieuwe layout voldoen, layout moet geimplementeerd in de printersystemen. Acceptgiro drukkerijen moeten opnieuw het certificeringsproces doorlopen 3.2 Oorsprong van SEPA SEPA is niet nieuw. SEPA is ontwikkeld door de Europese Commissie om de Europese Unie op het gebied van betalingsverkeer te harmoniseren en te standaardiseren. De oorsprong van SEPA gaat terug tot 1992 naar het Verdrag van Maastricht. In dit verdrag staat de afspraak tussen de landen van de Europese Unie om tot de invoer van een gezamelijke munt over te gaan. Dit is de Euro geworden. In 2000 is het door de landen van de Europese Unie de zogenaamde Lissabon agenda afgesproken. In deze set van afspraken staan plannen om de Europese Unie op financieel gebied meer te integreren en te harmoniseren. Hieruit is ook het plan gekomen om wet en regelgeving te ontwikkelen om het girale betalingsverkeer te harmoniseren, de voorloper van SEPA. Een ander voorbeeld is de ontwikkeling van MiFID, welke de markt en regelgeving voor beleggingsdiensten in de Europese Economische Ruimte integreert [A6]. In 2002 zijn de landen in de Europese Unie overgegaan naar de gezamelijke munteenheid, de Euro. Tussen 2000 en 2007 is de Europese Commissie bezig geweest met het ontwikkelen van een generiek framework voor alle landen van de Europese Unie waarbinnen de rechten en plichten ten aanzien van betalingsverkeer zijn beschreven. Dit is het Payment Service Directive geworden. In 2009 is het Payments Service Directive (hierna: PSD) opgenomen in de nationale wetgeving van de EU landen. Terwijl het PSD geimplementeerd werd, zijn ook de SEPA producten SCT en SDD ontwikkeld. In jukebox staan de specificaties van de producten beschreven. Op 28 januari was de eerste SCT transactie een feit. De invoer en gebruik van SDD was gereed in november 2009. 3.3 Toelichting wet en regelgeving SEPA De wet en regelgeving met betrekking tot de invoer van SEPA bestaat uit de volgende drie onderdelen: Payment Service Directive Verordening 924/2009 Verordening 260/2012 Het Payments Service Directive (PSD) heeft de juridische basis van een geharmoniseerde betaalmarkt gelegd en daarbij ook de fundamenten voor het ontwikkelen van SEPA beschreven. Het PSD is in 2009 geïmplementeerd in de Nederlandse wetgeving. Financiële instellingen en organisaties hebben, voor zover van toepassing, wijzigingen naar aanleiding van het PSD reeds geïmplementeerd. Omdat het PSD geen verdere veranderingen vereist, maar de Verordeningen wel, wordt in deze scriptie verder ingegaan op de Verordeningen 924/2009 en 260/2012. Deze verordeningen beschrijven de requirements ten aanzien van de SEPA implementatie. Hieronder staat een toelichting op de Verordening 924/2009 en Scriptie IT Audit 2013 Page 19

Verordening 260/2012. Deze Verordeningen geven een concrete invulling aan de implementatie, de standaarden en diensten die SEPA vereist en hanteert. 3.3.2 Verordening EC 924/2009 De Verordening EC 924/2009 beschrijft de grensoverschrijdende betalingen binnen de euro zone [A11] en geeft aanvullende richtlijnen om de verdere integratie van het financiële landschap en het transactieverkeer te bewerkstelligen. De Verordening 924/2009 gaat in op de uitvoering en implementatie van SEPA. Een belangrijke beslissing die in de Verordening 924/2009 naar voren komt is dat alle banken binnen de Europese Unie verplicht zijn om SEPA Direct Debits te accepteren. Deze beslissing heeft veel impact gehad. Incasso s, of direct debits, zijn niet in alle landen een gebruikelijke betaalvorm. Om deze reden bieden niet alle banken het ontvangen en/of versturen van incasso s aan hun klanten. Ook voor enkele Nederlandse banken heeft de beslissing banken altijd incasso s moeten accepteren impact gehad. Enkele Nederlandse banken bieden beperkte betaalrekening en betaalfaciliteiten aan, bijvoorbeeld omdat het vermogensbanken zijn. Deze banken kenden nauwelijks tot geen incasso s op hun betaalrekeningen, door deze Verordening 924/2009 waren ook zij verplicht om inkomende SDD s op hun betaalrekeningen te faciliteren. In 3.3.5 zal verder uitgelegd waarom de banken de SDD s niet per definitie hoeven te accepteren. 3.3.3 Verordening EC 260/2012 Grof geschetst bestaat de Verordening 260/2012 uit 3 delen. Deel 1 beschrijft de doelstelling van de verordening, de achtergrond en het verschil tussen de gewenste situatie (alle Eurolanden zijn SEPA compliant) en de huidige situatie (alle Euro landen voeren betalingen op hun eigen, nationale wijze uit). Deel 2 van de Verordening 260/2012 bestaat uit de punten die door de Europese Commissie zijn vastgesteld, vastgelegd in achttien wetsartikelen. Hierin is onder andere de deadline van 1 februari 2014 voor het algemene gebruik van SEPA vastgesteld, maar ook het gebruik van IBAN als bankrekeningidentificatie en ISO 20022 XML voor het berichten formaat. Deel 3 van de Verordening 260/2012 bestaat uit de bijlage, welke de technische vereisten aan de SEPA berichten vaststelt. 3.3.4 Toezicht van De Nederlandsche Bank en tijdslijnen gesteld door NFS Het Nationaal Migratieplan is geschreven door het Nationaal SEPA migratie forum (hierna: NFS) met als doel de implementatie van SEPA in Nederland te ondersteunen en te bevorderen [A5]. In dit plan is onderscheid gemaakt tussen software leveranciers, banken, grootzakelijke gebruikers van het betalingsverkeer en kleinzakelijke gebruikers van het betalingsverkeer. Software leveranciers bieden veelal de ondersteunende IT applicaties voor het uitvoeren van betalingsverkeer, bijvoorbeeld polissystemen, grootboeksystemen, betaalapplicaties en ERP systemen. Organisaties zijn steeds vaker in grote mate afhankelijk van hun IT systemen voor het verzamelen en insturen van betalingen naar de bank. Om deze reden is door het NFS gesteld dat software leveranciers in oktober 2012 gereed moesten zijn met de aanpassingen in hun systemen. Banken zijn een andere schakel in het betalingsproces. De Nederlandse banken kunnen sinds 2008 SCT s verwerken en sinds 2009 SDD s in ieder geval ontvangen en verwerken. De banken zijn echter nog niet volledig over op de SEPA wijze van betalen en de grote bulk gebeurt nog via het nationale Scriptie IT Audit 2013 Page 20

betalingssysteem. De infrastructuur van de banken was nog niet gereed voor de massale migratie naar SEPA. Het NFS heeft gesteld dat de banken per 1 oktober 2012 voor SCT en per januari 2013 voor SDD gereed moeten zijn voor de massale migratie naar SEPA. De volgende groep zijn grootzakelijke gebruikers van het betalingsverkeer. Welke organisaties onder grootzakelijke gebruikers vallen is door het NFS vastgesteld [A5] en de betreffende organisaties zijn per brief op de hoogte gesteld. Van grootzakelijke gebruikers wordt verwacht dat zij volledig over zijn op het gebruik van SEPA, in plaats van de nationale betaalproducten, uiterlijk 30 juni 2013. Voor kleinzakelijk gebruikers geldt de deadline van 1 februari 2014. De tijdslijnen zoals gesteld door het NFS zijn opgenomen in het framework om zo ook de tijdigheid van het implementatie project te kunnen evalueren bij de onderzochte organisatie. Scriptie IT Audit 2013 Page 21

4. Ontwikkelen van een SEPA Framework Dit hoofdstuk geeft een overzicht van de requirements die er vanuit wet en regelgeving gesteld zijn aan de implementatie van SEPA binnen organisaties. Deze requirements zijn afkomstig uit de Verordening 260/2012 van de Europese Commissie d.d. 14 maart 2012 en uit het migratieplan van het Nationaal Forum SEPA migratie in Nederland. In hoofdstuk 6 zal het voorgestelde framework getoetst worden binnen een bestaande organisatie. 4.1 Doel van het framework In hoofdstuk 3 is inzichtelijk gemaakt wat SEPA inhoudt en wat de mogelijke impact is op de betaalprocessen. De analyse van de mogelijke impact is gebaseerd op de beschrijving van de SEPA producten, maar geeft nog weinig houvast aan de volledigheid en juistheid van de mogelijke impact bij een organisatie. Bij het implementeren van wet en regelgeving op een belangrijk deel van de bedrijfsvoering, namelijk het incasseren en uitvoeren van betalingen, tot wijzigingen leidt, is het wenselijk om op een gestructureerde wijze de juistheid en volledigheid van de voorgenomen implementatie aanpak te toetsen. Om deze reden is SEPA framework ontwikkeld. Het SEPA framework is een generiek toetsingskader om binnen verschillende omgevingen en op diverse punten van het SEPA implementatie project een inzicht te krijgen in de juistheid en de volledigheid van de (geplande) SEPA implementatie. Het framework kan gebruikt worden om te waarborgen dat alle aspecten van SEPA worden ingevoerd in de organisatie, inzicht te krijgen in de gestelde tijdslijnen en de daarbij behorende risico s die tijdens of na het project relevant zijn. 4.2 Totstandkoming van het framework Het framework is ontwikkelt op basis van de Verordening 260/2012 van de Europese Commissie d.d. 14 maart 2012 [A4] en het Nationaal Migratieplan [A5]. In hoofdstuk 3 is beschreven dat de Verordening uit 3 delen bestaat. Voor het ontwikkelen van het SEPA framework zijn deel 2 en deel 3 van de Verordening 260/2012 gebruikt om de requirements vast te stellen. De artikelen 3 tot en met 7 in de Verordening 260/2012 zijn een belangrijke bron van requirements voor het SEPA framework. Voor het framework zijn alleen de requirements die impact hebben op de huidige wijze van het uitvoeren van betalingen binnen een organisatie zijn opgenomen. Naast de Verordening 260/2012 is ook het nationaal SEPA migratieplan is als input gebruikt voor het ontwikkelen van het framework. Zoals beschreven in paragraaf 4.2.3 zijn in het nationaal SEPA migratie plan een aantal tijdslijnen opgenomen voor de verschillende groepen, namelijk software leveranciers, banken, grootzakelijke gebruikers en kleinzakelijke gebruikers van het betalingsverkeer. Deze tijdslijnen zijn meegenomen als requirement in het framework. Scriptie IT Audit 2013 Page 22

4.3 Toelichting op gebruik van het framework Hieronder is het volledig framework uitgewerkt met de SEPA requirements, welke afgeleid zijn uit de Verordening 260/2012 en het nationaal SEPA migratieplan. Deze paragraaf beschrijft een korte leeswijzer van het framework. Het framework bestaat uit 6 kolommen, namelijk 1. Identificatie, 2. Requirement, 3. Huidige situatie, 4. Bevindingen, 5. Risico en 6. Aanbevelingen. De eerste kolom vermeldt het identificatienummer van de SEPA requirement. De tweede kolom beschrijft de interpretatie van de SEPA requirement, zoals deze in de Verordening 260/2012 staat. Het framework is verdeeld in elf onderdelen en elk onderdeel verwijst naar een specifiek artikel in de verordening of nationaal SEPA migratieplan. De derde kolom is bedoelt om de situatie bij de organisatie te beschrijven. De huidige situatie ten opzichte van de requirement wordt hier beschreven, bijvoorbeeld in het geval van het gebruiken van IBAN kan het zo zijn dat de organisaties de IBAN al volledig hanteert, alleen voor buitenland overboekingen of nog helemaal niet. Elk van deze drie opties heeft consequenties voor de impact van de SEPA implementatie. In de vierde kolom worden de bevindingen beschreven. Hierin wordt de huidige situatie bij de organisatie ten opzichte van de requirement vergeleken met de gewenste situatie van de organisatie, namelijk volledig voldoen aan de requirement. In de kolom worden de bevindingen, zowel positief als negatief beschreven. Het is bijvoorbeeld mogelijk dat een organisatie de IBAN nog niet hanteert, maar wel inzichtelijk heeft waar de IBAN gehanteerd dient te worden en een gedegen plan van aanpak heeft beschreven om de IBAN in de organisatie tijdig in te voeren. In de kolom risico kan vervolgens door middel van het toekennen van de kleuren Groen, Amber of Rood een indicatie worden gegeven over zwaarte van de bevinding. De laatste kolom tenslotte geeft de mogelijkheid om aanbevelingen, praktische tips en ervaringen te delen vanuit het oogpunt van de gebruiker van het framework. Scriptie IT Audit 2013 Page 23

Requirement Huidige organisatie Bevindingen Prio Aanbeveling 1 Vereisten voor credit transfers en direct debits (Verordening 260/2012 Artikel 5.1) 1.1 De betalingsdienstaanbieder moet de IBAN voor de identificatie van de betaalrekeningen gebruiken 1.2 De betalingsdienstaanbieder moet de ISO 20022 XML formaat hanteren voor het versturen transacties en/of het verwerken van betalingen van andere betalingsdienstaanbieders 1.3 De gebruikers van de betaaldiensten zijn verplicht om de IBAN te hanteren als identificatie van de betaalrekeningen, dit geldt voor zowel de nationale als crossborder betaalrekeningen. 1.4 Organisaties die hun overboekingen en incasso s gebundeld aanleveren aan de betalingsdienstaanbieder, moeten deze gebundelde transacties in het ISO 20022 XML pain formaat aanleveren aan de betalingsdienstaanbieder. 2 Vereisten voor credit transfers en direct debits (Verordening 260/2012 Artikel 5.2) 2.1 SCT: De betaler moet de data elementen, zoals beschreven in Appendix A aan de betalingsdienstverlener verstrekken 2.2 SCT: De betalingsdienst van de betaler moet de in Appendix A beschreven data elementen aan de betalingsdienstverlener van de ontvanger verstrekken 2.3 SCT: De betalingsdienstverlener van de ontvanger moet de in Appendix A beschreven data elementen beschikbaar maken aan de ontvanger 3 Vereisten voor credit transfers en direct debits (Verordening 260/2012 Artikel 5.3) 3.1 SDD: De betaler moet de data elementen, zoals beschreven in Appendix A aan de Scriptie IT Audit 2013 Page 24