AO/IC maatregelen General IT controls
Operationele applicaties
Hardware infrastructure Netwerk infrastructure Message infrastructure Reconciliatie applicatie
Financiële applicatie suite
Ontvangstomgeving ETL/ Rules engine
Grootboek DWH
FA rapportage MA rapportage
Reconciliatie bij Service Oriented Architecture (SOA)
Controle ‘around the computer’ met geautomatiseerde reconciliatie voor de f inanciële verslaglegging bij de
implementatie van SOA bij banken bekeken vanuit een IT audit perspectief.
C.J.A. Wever
Studentnummer 9100111 Scriptiestudentnummer 703 VU Amsterdam
Postdoctoraal IT audit Datum 2-6-2007 Versie 1.1 Definitief
Inhoudsopgave
1 Inleiding ...3
2 Informatiearchitectuur bij banken met SOA ...5
2.1 Service Oriented Architecture bij banken... 5
2.2 Applicatie architectuur met SOA ... 5
2.3 Logische informatiearchitectuur financiële domein ... 6
2.4 Technische SOA infrastructuur ...10
3 Reconciliatieproces voor financiële verslaglegging...13
3.1 Inleiding ...13
3.2 Doelstelling reconciliatieproces...14
3.3 Processtappen ...14
3.4 Reconciliatierapportages...16
3.5 Functiescheiding binnen het reconciliatieproces ...16
4 Wettelijk en theoretisch kader...17
4.1 Inleiding ...17
4.2 Interpretatie FIRM voor SOA en reconciliatie ...17
4.3 Interpretatie SOx voor SOA en reconciliatie...21
4.4 Interpretatie van CoP voor SOA en reconciliatie...21
4.5 Interpretatie van Clark & Wilson model voor SOA en reconciliatie...25
5 Risico’s en beheersmaatregelen voor reconciliatie bij SOA ...28
5.1 Inleiding ...28
5.2 Risico’s en beheersmaatregelen voor AO/IC voor reconciliatie bij SOA ...28
5.3 Risico’s applicaties met SOA...29
6 General IT controls voor reconciliatie bij SOA ...31
6.1 Inleiding ...31
6.2 CoP 10.1.4 Separation of environments ...31
6.3 CoP 10.8.2 Exchange agreements ...32
6.4 CoP 10.8.4 Electronic messaging...32
6.5 CoP 11.2.2 Privilege management ...33
6.6 CoP 11.5.2 User authentication and identification ...33
6.7 CoP 11.4.7 Network routing control en Cop 12.2.3 Message integrity ...33
6.8 Applicatieve beheersmaatregelen op basis van Clark & Wilson ...34
7 Reconciliatie voor de financiële verslaglegging...35
7.1 Inleiding ...35
7.2 Eisen informatiebeveiliging voor reconciliatie applicatie ...35
7.3 Reconciliatie IT controletotalen ...35
7.4 Reconciliatie basisadministratie ...36
7.5 Reconciliatie ontvangstomgeving...37
7.6 Reconciliatie grootboek ...38
7.7 Reconciliatie datawarehouse ...39
7.8 Reconciliatie financiële rapportage ...41
7.9 Monitoring en audit trail van de reconciliatie ...41
7.10 Positionering van reconciliatieapplicatie ...42
8 Conclusies en aanbevelingen ...43
8.1 Inleiding ...43
8.2 SOA veroorzaakt risico’s voor de financiële verslaglegging ...43
8.3 SOA vereist extra aandacht voor general IT controls ...43
8.4 Reconciliatie is vereist van de bron tot en met de rapportage bij SOA...43
8.5 Reconciliatie ondersteunt de functiescheiding binnen de financiële verslaglegging ....43
8.6 Reconciliatie ondersteunt SOx regelgeving ...43
8.7 Reconciliatie informatie als koppeling naar ‘audit around the computer’ ...44
8.8 Tot slot ...44
I Bijlage Literatuurlijst...45
1 Inleiding
Deze inleiding heeft als doelstelling de context te creëren voor de IT auditor die gevraagd wordt om het reconciliatieproces te controleren bij een bank met een (deels) service oriented
architecture. In dit referaat wordt ingegaan op de keuze door banken voor een Service Oriented Architecture (SOA) en de bijbehorende informatiebeveiligings- en reconciliatieproblematiek voor de administratieve bancaire informatiesystemen bij de banken (ING, ABN Amro, Rabobank e.a.).
De ‘Dikke van Dale’ definieert conciliatie als ‘verzoening’ of ‘afstemming tot stand brengen’.
Reconciliatie wordt in dit referaat gedefinieerd als het proces dat controleert dat het grootboek aansluit op de gegevens in basisadministraties (sparen, hypotheken, rekening courant, etc.) en andere gegevensverzamelingen, die gebruikt worden voor financiële verslaglegging, zodat de basisadministratie, het grootboek en de rapportages op elkaar zijn afgestemd.
Informatiebeveiliging wordt in dit referaat gedefinieerd als het geheel van maatregelen om de vertrouwelijkheid, integriteit en beschikbaarheid van de informatievoorziening te waarborgen.
De bancaire sector moet de operationele kosten reduceren om concurrerend te zijn en te blijven.
Hierbij is flexibiliteit en dynamiek van bedrijfsprocessen van essentieel belang, zodat stappen in bedrijfsprocessen kunnen worden geoptimaliseerd. In het streven naar de laagste kosten, moeten (delen van) bedrijfsprocessen worden uitgevoerd op de plaats, waar de vereiste kwaliteit geleverd kan worden tegen de laagste kosten. Dit geldt zowel voor de bedrijfsorganisatorische positie (service centra, outsourcing van operationele processen naar lage lonen landen), de
informatievoorziening (hosting, outsourcing van IT operatie) als voor de fysieke locatie (o.a.
outtasking naar externe call centra).
De consequentie is dat vastlegging van financiële gebeurtenissen op diverse locaties plaatsvindt met regelmatig ook verschillende applicaties. Een eenvoudige betalingsopdracht bijvoorbeeld kan vanuit de verschillende plekken worden vastgelegd, zoals met overschrijvingsformulieren, met telefonische opdrachten, via Internet, via mobiele telefoon, via geldautomaten, etc. Door de standaardisatie van de bankproducten doet deze ‘multi-channel’ ontwikkeling zich ook voor bij andere financiële producten (o.a. transactie op financiële markten, effectentransacties,
hypotheken, beleggingen en verzekeringen).
De bancaire bedrijfsprocessen moeten zich aanpassen aan de nieuwe technologische
mogelijkheden. De vereiste flexibilisering van de bedrijfsprocessen in de bancaire sector wordt het laatste decennium geremd door de oude bestaande automatisering. Dit wordt mede
veroorzaakt, doordat het vervangen van deze oude applicaties grote investeringen met zich meebrengt. Door de lange doorlooptijd van de migraties is de vraag ontstaan om nieuwe technologische mogelijkheden aan te sluiten op (delen van) de bestaande (legacy) applicaties.
De informatietechnologie heeft de object georiënteerde benadering als antwoord op deze vraag.
Echter een volledig object-georiënteerde benadering zorgt voor problemen in de aansluiting op de processen. De object georiënteerde programmatuur bevat kennis van de status van
bedrijfsprocessen. Hierdoor leidt een wijziging van een bedrijfsproces tot een wijziging van de objectprogrammatuur, waardoor de flexibiliteit van de bedrijfsprocessen wordt beperkt. Deze beperking van de flexibiliteit is één van de voorname redenen, waardoor de objectgeoriënteerde architectuur niet grootschalig is doorgevoerd in de bancaire sector. Een tweede reden is dat de oude systemen niet op deze wijze zijn gebouwd, waardoor integratie van objectgeoriënteerde programmatuur en de oude systemen moeizaam verloopt.
De computerindustrie is gekomen met een verbeterde versie van de objectgeoriënteerde benadering, namelijk de Service Oriented Architecture (SOA).
De bancaire sector in Nederland heeft inmiddels strategisch gekozen voor de Service Oriented Architecture met integratie en hergebruik van bestaande systemen. In deze scriptie wordt niet verder ingegaan of deze strategische keuze juist is. SOA biedt verschillende mogelijkheden, zowel functioneel als technisch, om de connectie tussen de basisadministraties en het grootboek te realiseren.
De keuze voor SOA brengt een aantal consequenties en vraagstukken met zich mee voor de interne controle en financiële verantwoording. In deze scriptie worden deze toegelicht vanuit een IT audit-perspectief.
Treasury
Product administraties
Grootboek per juridische
entiteit Rapportage
(IFRS, Basel2 US GAAP) Overschot
Funding (debet)
Verkoop kanalen Klanten
Debet (bijv. Lenen) Credit
(bijv. Sparen)
Registratie Debet/credit
Geconsolideerd grootboek
Rapportage
Registratie Consolideren Rapportage Tegenpartij
Overschot/
Afdekken risico Te kort/
Risico nemen
Voor de financiële verantwoording is het noodzakelijk, dat de subadministraties en het grootboek volledig aansluiten. Door de verschillende rapportage-eisen (US GAAP, IFRS, Basel2, etc.) en het vereiste detailniveau voor de diverse rapportages is het niet mogelijk om de volledige rapportage te baseren op alleen het grootboek. De grote leveranciers van grootboeksoftware gebruiken hiervoor aanvullend datawarehouse-technologie, zodat specifieke rapportages kunnen worden geleverd van dezelfde cijfers naar verschillende inzichten. Hierbij is de consistentie tussen het datawarehouses en het grootboek een belangrijk vraagstuk.
Daarnaast speelt het vraagstuk welke interne controlemaatregelen getroffen moeten worden om de vertrouwelijkheid, integriteit, beschikbaarheid en controleerbaarheid te waarborgen in de verschillende onderdelen, als gebruik gemaakt wordt van SOA.
De financiële verslaglegging bij banken is gebaseerd op de contractadministratie en geldstromen.
Hierbij wordt opgemerkt dat de waardenkringloop bij banken (Starreveld) abstracter is dan typologieën met goederen stromen, doordat de contractadministraties worden gezien als producten waarbij de aantallen in geld worden uitgedrukt.
Figuur 1 Globaal bedrijfsproces van een bank met financiële gegevensstromen
De verschillende bedrijfsprocessen, waarmee financiële producten worden geadministreerd door banken kunnen door verschillende services worden gerealiseerd. In het onderstaande schema wordt weergegeven welk proces een overboeking van een rekening courant naar een
spaarrekening doorloopt.
Figuur 2 Overzicht van bedrijfsproces met de processtappen
De verschillende stappen van het bedrijfsproces worden ondersteund met één of meerdere bedrijfsapplicaties, die op verschillende platformen (hardware, operating system, DBMS en netwerken) verwerkt kunnen worden. Deze verschillende bedrijfsapplicaties zullen op de juiste momenten de financiële applicaties moeten voeden met de juiste gegevens.
Credit (bijv. Sparen) Service Oriented Enterprise bus
Riskmanagement
Finance Treasury Treasury Marketeing E-business Telefoon Face
Customers&parties Accounts &payments Savings Loans Mortgages Securities Foreignexchange Money markets
Credit (bijv. Sparen) Service Oriented Enterprise bus
Riskmanagement
Finance Treasury Treasury Marketeing E-business Telefoon Face
Customers&parties Accounts &payments Savings Loans Mortgages Securities Foreignexchange Money markets
2 Informatiearchitectuur bij banken met SOA
2.1 Service Oriented Architecture bij banken
De informatie architectuur (o.a. James Martin – Strategic data planning) met SOA voor de banken leidt tot een indeling in domeinen. Elk domein is eigenaar van een verzameling gerelateerde gegevens. Zo is het Finance domein verantwoordelijk voor de financiële verantwoording. Voor deze financiële verantwoording ontvangt het financiële domein gegevens zonder hier expliciet om gevraagd te hebben (push services) en haalt het financiële domein gegevens uit andere domeinen (pull services).
De verschillende domeinen communiceren met elkaar via deze services. Om te zorgen dat de verschillende domeinen elkaar verstaan is een zgn. ‘domain exchange model’ noodzakelijk. In dit model wordt op logisch niveau beschreven welke diensten een domein kan bieden (services), welke gegevens aangeboden worden (logische entiteiten en elementen) en de betekenis van deze gegevens (semantiek).
De inrichting van domeinen voor de banken in Nederland is een sterke beheersmaatregel, want hierdoor kan de optimalisatie van de systemen per domein plaatsvinden. Voor gefuseerde ondernemingen, zoals ABN AMRO of ING leidt deze optimalisatie tot een beheersbaar proces om per domein de fusies te realiseren en zo het beoogde kostenvoordeel uit de fusies te realiseren.
Strategisch biedt deze indeling in domeinen ook de mogelijkheid om delen te outsourcen of af te stoten.
2.2 Applicatie architectuur met SOA
De generieke opzet van SOA is gebaseerd op de logische architectuur bestaande uit applicaties, die samengesteld worden uit services. Voor het realiseren van de applicaties worden verschillende soorten services gebruikt.
• Process centric services – Verzorgen de besturing van een bedrijfsproces, en roepen task centric services aan. In de praktijk wordt de process centric service vaak verward met de task centric service. Echter een essentieel onderscheid tussen beide is dat de process centric service de functiescheiding realiseert en controleert dat een bedrijfsproces binnen de richtlijnen wordt uitgevoerd. Een process centric service zorgt ook dat verschillende processtappen geautomatiseerd kunnen worden uitgevoerd en uitzonderingen correct worden afgehandeld.
• Task-centric business services – verzorgen de besturing van een bedrijfsprocesstap, waarbij de taak automatisch wordt uitgevoerd (transactie valt binnen de limieten) of een eindgebruiker heeft de autorisatie heeft om de betreffende taak uit te voeren. Door de task centric business services worden de juiste applicatie-services aangeroepen. Hierbij kan de invoer van de gebruiker worden gebruikt om de processtap te realiseren.
• Application services – verzorgen de communicatie tussen de eindgebruiker en het systeem. Dit gebeurt door schermen te tonen, waarop gebruikers hun gegevens zien en kunnen bewerken. Een belangrijke functie van application services is de integriteit tussen entity centric services te bewaken, zodat de response van entity centric services correct wordt afgehandeld.
• Entity-centric services – verzorgen het beheer van de data objecten, die ter beschikking worden gesteld aan de eindgebruiker. De belangrijke functie van entity centric services is de integriteit van de gegevens te bewaken. Dit wordt gerealiseerd door te zorgen, dat als een functie wordt uitgevoerd, een entiteit altijd in een integere situatie wordt
achtergelaten.
Door de verschillende services te combineren wordt het mogelijk om vanuit verschillende kanten een mutatie gerealiseerd te krijgen.
2.3 Logische informatiearchitectuur financiële domein 2.3.1 Overzicht
Het financiële domein wordt gevoed met gegevens vanuit de basisadministraties, want daar worden de vastleggingen gedaan, die leiden tot registraties in het grootboek. De vastleggingen worden bij SOA via gebeurtenissen (events) aan het financiële domein gemeld. De events worden door de services in de vorm van berichten (messages) naar het financiële domein verstuurd voor verwerking in het grootboek. Dit kunnen ook massamutaties (batch) zijn, doordat de betreffende gegevens massaal beschikbaar komen. Een voorbeeld hiervan is renteberekening.
De events leiden op deze wijze tot registraties in de financiële administratie. Bij een bank worden zowel on-balance als off-balance registraties onderkend. De off-balance mutaties zijn
verplichtingen of rechten die een bank aangaat met haar klanten en vormen een materieel onderdeel van de activiteiten van een bank. De on-balance mutaties resulteren in mutaties van balansposten. Daarnaast wordt in de financiële administratie onderscheid gemaakt in registratieve mutaties en resultatieve mutaties. De registratieve mutaties zijn gericht op het veranderen van verplichtingen en rechten met klanten. De resultatieve mutaties zijn gericht op de interne financiële besturing van de bank, bijv. voorzieningen.
De event-georiënteerde benadering voor de financiële administratie is gelijktijdig geïntroduceerd met de objectgeoriënteerde wijze van inrichten van de basisadministraties. Voor alle banken geldt echter dat het migreren naar een service oriented architecture en een event-georiënteerd
grootboek een zeer grote operatie is, die verschillende jaren in beslag neemt. In de legacy systemen leveren de basisadministraties journaalposten aan i.p.v. events. Bij de legacy systemen wordt de inhoud en het formaat van de journaalposten in de legacy systemen bepaald. Bij event- georiënteerde systemen wordt de inhoud en het formaat van de journaalpost bepaald in het grootboek op basis van de kenmerken van de aangeleverde mutatie.
De consequentie van het aanleveren van journaalposten door de basisadministraties was, dat de basisadministraties rekening moesten houden met de inrichting van het grootboek. De inrichting van het grootboek kon niet aangepast worden zonder de aanlevering door basisadministraties aan te (laten) passen. Voor het reconciliatieproces had dit als voordeel, dat als de controle tussen basisadministratie en opgeleverde journaalposten correct was en de registratie van de
journaalposten in het grootboek correct was, het grootboek als volledig beschouwd werd. Door het aanleveren van journaalposten bevatte het grootboek echter een beperkte hoeveelheid detailinformatie. De ontbrekende detailinformatie is echter wel noodzakelijk om aan de financiële rapportage eisen te voldoen. Een voorbeeld van een eenvoudige wijziging is bijvoorbeeld de indeling van leningen in termijnen. Als DNB besluit deze indeling aan te passen en de indeling in looptijd wordt via journaalposten geregeld vanuit de basisadministratie, dan moet door de nieuwe indeling de aanlevering door de basisadministratie worden aangepast. Om dit te voorkomen worden allerlei bypasses gecreëerd om de detailgegevens toch te combineren met gegevens uit het grootboek, zodat de betreffende rapportages toch opgeleverd kunnen worden.
Voor de huidige (regelmatig wijzigende) financiële rapportage bevat een grootboekadministratie onvoldoende detailinformatie om aan de eisen te voldoen. Deze verschillende rapportage eisen ontstaan, doordat banken moeten voldoen aan verschillende richtlijnen en/of (belasting) wetgeving o.a. IFRS, Basel2, DNB rapportages en US GAAP. De juridische organisatievormen (bijvoorbeeld Europese vennootschap = SE) leiden ook tot nieuwe rapportage-eisen. Deze
ecoR
ilinc
vieat
zoer
eke n
Reconciliatie verzoeken
berichten Berichten via gegevens ontvanst omgeving
Reconciliatie verzoeken Reconciliatie verzoeken Reconciliatie verzoeken Reconciliatie verzoeken
Reconciliatie verzoeken Mutatie s
verplichte externe financiële rapportage wordt in dit referaat verder Financial Accounting (FA) genoemd.
In de praktijk blijkt het niet mogelijk om met de huidige ERP pakketten (SAP, Peoplesoft,
Hyperion, etc.) of maatwerk-software de verschillende rapportage-eisen te realiseren op basis van alleen het grootboek. Als daarnaast ook nog een gedetailleerd inzicht noodzakelijk is t.b.v.
management accounting (MA) en financiële sturing (bijvoorbeeld liquiditeitsmanagement, interest management, budgettering) wordt gekozen voor een datawarehouse oplossing. De ERP
leveranciers (bijvoorbeeld SAP met Business Warehouse) zijn overgegaan tot de inrichting van een datawarehouse-oplossing binnen hun platform. Een essentiële eis hierbij is dat de
basisadministraties, grootboek en datawarehouse consistent zijn, de aansluiting kan worden aangetoond en deze aansluiting door de externe accountant kan worden gevolgd. Hierdoor is het onafhankelijke reconciliatieproces in toenemende mate van belang.
Als gevolg van de vergaande integratie van de automatisering en ‘straight-through-processing STP’ wordt de interne controle gerealiseerd door logische toegangsbeveiliging en applicatieve controlemaatregelen. Het reconciliatieproces verzorgt een onafhankelijke controle op de juiste werking van deze controlemaatregelen door het gebruik van omspannende verbandcontroles. Om de consistentie tussen de verschillende gegevensverzamelingen te waarborgen moet een
reconciliatie-model worden gedefinieerd, waarbij het netwerk van controletotalen wordt
gerealiseerd. Dit reconciliatiemodel kan op verschillende manieren worden gerealiseerd. Hierbij is het van belang, dat de basisadministraties en het financiële domein rekening houden met de eisen die gesteld worden vanuit de reconciliatie. Deze reconciliatievragen kunnen van
verschillende aard zijn. Door deze vragen onafhankelijk van de gegevensverwerking te stellen aan de verschillende administraties kan de consistentie tussen de verschillende administraties worden vastgesteld. In het schema hieronder zijn de vereiste reconciliaties schematisch weergegeven. In de volgende paragrafen worden de componenten nader toegelicht.
2.3.2 Basisadministraties
De basisadministraties worden gevoerd met pakketten en zelf ontwikkelde applicaties. Deze basisadministraties zijn bronsystemen voor de voeding van het grootboek. De basisadministraties worden regelmatig aangepast voor nieuwe producten en herinrichting van processen.
Eerder is al aangegeven, dat de basisadministraties geen kennis van de opzet van het grootboek moeten bevatten, maar de mutaties (events) aan het grootboek moeten aanleveren. Vanuit het grootboek moet duidelijk gedefinieerd worden op welke wijze de gegevens aangeleverd worden.
Dit wordt vastgelegd in het domain exchange model.
De basisadministraties versturen de ‘events’ naar het grootboek via de ‘message bus’. Hierbij zijn er verschillende type interfaces bij SOA mogelijk:
• Elk event een message, bijvoorbeeld de mutatie van een contract
• Een batch van messages naar aanleiding van een event, bijvoorbeeld renteberekening
• Een message over een batchbestand dat met message verstuurd wordt, en vervolgens wordt het batchbestand buiten de bus om opgehaald. Bijvoorbeeld alle
betalingstransacties.
• Alleen een batchbestand met messages geheel buiten de bus om
Tijdens de audit van het reconciliatieproces moet de IT auditor dit onderscheid duidelijk in beeld krijgen, aangezien de verschillende soorten interfaces nadrukkelijk verschillende eisen aan de reconciliatie stellen.
Om de operationele activiteiten verder te optimaliseren worden basisadministraties voor verschillende juridische entiteiten bij elkaar gevoegd. De IT auditor zal voor de audit van het reconciliatieproces moeten beoordelen op welke wijze wordt gegarandeerd, dat de mutaties voor de afzonderlijke juridische eenheid, correct worden verantwoord in het grootboek.
Ook worden administraties uitbesteed aan externe bedrijven, bijv. ONVZ zorgverzekeringen, die de administratie voor verschillende bedrijven realiseren in één systeem. Ook hier zal de IT auditor moeten verifiëren op welke wijze de verantwoording volledig is.
2.3.3 Ontvangstomgeving
In de ontvangstomgeving worden alle gegevens ontvangen, die aangeleverd worden door de basisadministraties. De ontvangstomgeving (staging area) heeft vier belangrijke functies, die impact hebben op het reconciliatieproces:
- De eerste functie is de bewaking dat alle gegevens worden ontvangen. Hiermee wordt operationeel bewaakt, dat de verwachte gegevens ook daadwerkelijk worden ontvangen.
Als er bijvoorbeeld dagelijks een batch met rentemutaties moet worden ontvangen en dit gebeurt niet, wordt dit gesignaleerd en kan er actie worden ondernomen. (volledigheid) - De tweede functie is het bewaken van de datakwaliteit van de ontvangen gegevens,
waarmee wordt gecontroleerd dat de aangeleverde gegevens correct zijn. Deze controle zorgt ervoor dat er bijvoorbeeld geen events worden aangeleverd, die niet verwerkt kunnen worden in het grootboek. (integriteit)
- De derde functie is het overbruggen van tijdverschillen, want niet alle gegevens komen op hetzelfde moment binnen. De ontvangstomgeving zorgt ervoor dat deze verschillen
worden gladgestreken. Mutaties kunnen bijvoorbeeld pas worden verwerkt in het
grootboek, nadat een periode in het grootboek is afgesloten. De ontvangstomgeving zorgt dan dat de gegevens worden vastgehouden totdat de periode is afgesloten. (integriteit) - De reconciliatie van de ontvangstomgeving met de basisadministratie gebeurt door
periodiek een reconciliatie-verzoek af te stemmen. Het initiatief voor deze reconciliatie is een aandachtspunt voor de IT auditor. Enerzijds kan een basisadministratie aangeven, dat een periode is afgesloten (bijv. een uur of een dag), waarbij het initiatief bij de
basisadministratie ligt en direct aangeeft welke totalen in de betreffende periode zijn aangeleverd volgens de eisen van het financiële domein. Anderzijds kan het initiatief bij de financiële administratie liggen om een controletotaal op te vragen naar aanleiding van een ontvangen bericht over een afgesloten periode. Deze reconciliatie is essentieel om te bewaken dat alle gegevens zijn geleverd aan de ontvangstomgeving.
2.3.4 Grootboek
Het grootboek is de centrale administratie, waarin de registratie van financiële mutaties
plaatsvindt. De structuur van het grootboek van een internationale bank is een complex geheel, waarin financiële gegevens volgens verschillende principes worden geregistreerd. De complexiteit van het grootboek zit in de hoeveelheid verschillende inzichten die geboden moeten worden:
multi-currency, multi-book, multi-account; multi-legal entity, multi-business, multi-country. De verschillende juridische entiteiten leidt tot de inrichting van verschillende grootboeken binnen de
grootboekapplicatie, die vervolgens worden geconsolideerd naar één grootboek voor de holding.
Afhankelijk van de karakteristieken van de juridische entiteit kan de inrichting van het grootboek verschillen. Dit leidt ook tot verschillen in eisen voor de reconciliatie. Binnen het grootboek voor een juridische entiteit worden meerdere boeken voor de verschillende producten gecreëerd, waarin de mutaties volgens de verschillende principes worden geregistreerd.
De IT auditor moet zich bij de audit van het reconciliatieproces bewust zijn van de grenzen van de onderzochte reconciliatie. Hierbij moet de IT auditor inzicht hebben in de grootboekstructuur van de onderzochte juridische entiteit(en).
2.3.5 Transformatie naar financial logical model – rules engine/ETL
De grote diversiteit van mutaties uit de verschillende applicaties moeten worden omgezet naar de grootboeken, waarbij de verschillende principes voor het boeken moeten worden toegepast.
Hierdoor heeft het financiële domein behoefte heeft aan een ‘intelligent’ mechanisme, waarmee de gegevens (events) uit de basisadministraties op correcte wijze getransformeerd kunnen worden naar het grootboek-formaat. Deze transformatie bevat de ‘business logic’ van de controller. Deze regels kunnen geprogrammeerd worden in (semi)statische programma’s, maar ook als ‘rules’ met scripts worden gerealiseerd.
Om maximale flexibiliteit te creëren voor de controller zijn hiervoor specifiek pakketten op de markt o.a. OST, PEGA-rules, Oracle FSAH, etc. Deze zgn. ‘rules engines’ bevatten een taal, waarmee de transformatieregels dynamisch kunnen worden gedefinieerd. Vanuit een accountants en IT audit-perspectief vereist een ‘rules engines’ module de nodige aandacht, zodat vastgesteld kan worden dat de ‘rules’ consequent (correct) zijn toegepast. Vanuit een reconciliatie-perspectief kan de ‘rules engine’ verschillen veroorzaken. Het reconciliatieproces kan om deze reden als een controlerende functie worden beschouwd op deze transformatie. De ‘rules engines’ bevatten reconciliatie functionaliteit om te reconciliëren tussen input en output. De ‘rules engines’
verwerken in principe elk event afzonderlijk. Dit heeft als consequentie, dat de ‘rules engines’
IT-technisch gezien een zware belasting kan zijn voor de infrastructuur.
Ook zijn er semi-statische oplossingen met ETL-programmatuur (= Extract, Transfer, Load).
Hiermee worden de rules gedefinieerd om juiste transformaties realiseren. Deze ETL-
programmatuur biedt echter geen standaard reconciliatiemogelijkheden anders dan technische controles dat een verwerking correct is verlopen. De reconciliatie moet dan afzonderlijk worden ontwikkeld.
In de logische architectuur is aangegeven, dat de datawarehouse-component tegenwoordig ook een ‘onmisbare’ component is. De datawarehouse-component moet meegenomen worden in de keuze tussen een dynamische en semi-statische oplossing voor de rules engines. Hierbij is de keuze van de rules engine van invloed op de maatregelen om de consistentie tussen grootboek en datawarehouse te bewaken.
2.3.6 Datawarehouse
Het financiële datawarehouse kan een subset van het ‘corporate datawarehouse’ of een
geïsoleerd datawarehouse zijn. In dit referaat wordt uitgegaan van een financieel datawarehouse dat qua scope overeenkomt met de business scope van FA en MA en verplichte risicorapportages.
De kracht van het datawarehouse is gelegen in het feit, dat een datawarehouse veel
detailinformatie inclusief historie kan vasthouden. Hierbij kan de detailinformatie in principe naar een oneindig aantal dimensies worden gerapporteerd.
De consistentie tussen het grootboek en het datawarehouse is essentieel om een datawarehouse te kunnen gebruiken voor financiële verslaglegging. Hierbij is een belangrijk uitgangspunt dat het grootboek leidend is en het datawarehouse hier op een meer gedetailleerd niveau invulling aan geeft. De IT auditor moet bij de beoordeling van het reconciliatie-proces onderzoeken in hoeverre dit principe niet doorbroken wordt.
Dit uitgangspunt biedt een grote mate van flexibiliteit aan het datawarehouse, want hierdoor kan het datawarehouse gekalibreerd worden met de basisadministratie, zodra aangetoond is dat de basisadministratie en het grootboek consistent zijn. Kalibreren is het proces, waarmee het datawarehouse wordt ‘gelijkgetrokken’ met details uit de basisadministratie. Hiermee wordt het relatief eenvoudig om bij een gewijzigd datamodel van de basisadministratie het financieel datawarehouse weer consistent te krijgen. Het is belangrijk te onderkennen dat hiervoor het
grootboek wel voldoende detailgegevens moet bevatten om de consistentie tussen de basisadministratie en het grootboek aan te tonen.
Het datawarehouse kan gegevens bevatten t.b.v. de FA- en MA-rapportages. Hierbij is het
belangrijk, dat bekend is welke gegevens noodzakelijk zijn voor de FA-rapportages en additioneel nodig zijn voor de MA-rapportages. Bij voorkeur wordt er nagestreefd dat de verwerking van deze stromen onafhankelijk plaatsvindt. Hiermee wordt voorkomen, dat door het ontbreken van MA- gegevens de FA-verwerking verstoord wordt.
2.3.7 Financial Accounting rapportage
De Financial accounting-rapportage (FA) zijn alle verplichte financiële rapportages voor banken aan de diverse externe partijen. Hierbij zijn er diverse wetgevingen, waaraan moet worden voldaan o.a. Wet op de jaarrekening (Titel 9 Boek 2 Burgerlijk Wetboek), US GAAP, IFRS GAAP, Basel2 (financieel risico) en belastingwetgeving. Bij de inrichting van het grootboek wordt hier al rekening mee gehouden door verschillende boeken te hanteren voor de verschillende
boekhoudprincipes en/of valuta’s. Hiervoor wordt voor de verschillende indelingen met memo- accounts gewerkt.
Uitgangspunt voor de FA rapportages is dat de rapportages opgesteld worden vanuit het grootboek. In de praktijk komen rapportages voor, waarvoor de noodzakelijke details niet beschikbaar zijn in het grootboek. Dit kunnen bijvoorbeeld criteria zijn gerelateerd aan
zekerheidsstellingen, landen van zekerheidsstellers, indelingen in rentepercentages en looptijd, typologieën van producten. De regelgeving voor de FA rapportages wordt regelmatig gewijzigd, waarbij er nieuwe eisen worden geïntroduceerd. Als deze wijzigingen consequent in het
grootboek zouden moeten worden doorgevoerd, zou de inrichting van het grootboek regelmatig moeten wijzigen. Dit is een ongewenste situatie, want hierdoor wordt de controle van het grootboek over een heel jaar verstoord door aanpassingen en conversies.
In het datawarehouse zijn de detailgegevens wel beschikbaar en kunnen de betreffende wijzigingen wel sneller doorgevoerd worden. Als er gegevens uit het datawarehouse worden gebruikt moet via het reconciliatieproces aangetoond worden, dat de geselecteerde gegevens uit het datawarehouse consistent zijn met de grootboekstanden. De IT auditor moet controleren dat deze reconciliatie-stap onderdeel is van de rapportage-procedure.
2.3.8 Management Accounting rapportage
De Management Accounting-rapportage (MA) is noodzakelijk voor de besturing van de
organisatie. Vanuit de organisatie is er een sterke informatiebehoefte om de grootboekgegevens te gebruiken voor het plannen en begroten van de toekomst. Daarnaast is er voor de besturing vaak ook andere detailinformatie noodzakelijk, bijvoorbeeld HR gegevens, bezettingsresultaten, etc. Binnen het bankbedrijf wordt voor deze informatie ook gebruik gemaakt van datawarehouse technologie.
2.4 Technische SOA infrastructuur
Deze paragraaf beschrijft de SOA infrastructuur. Het schema op de volgende pagina geeft een generieke vereenvoudigde infrastructuur. Hieruit blijkt dat er op verschillende punten overdracht van gegevens plaatsvindt. De overdrachtspunten vormen risico’s voor de vertrouwelijkheid,
integriteit en beschikbaarheid van de gegevens. De message infrastructuur moet hierdoor voldoen aan stringente security eisen.
Voor het realiseren van de technische SOA infrastructuur moeten een aantal componenten worden onderscheiden:
1. Message broker (server met middleware bijv. WEB Sphere/MQ Series of Oracle Fusion) De message broker verzorgt de gegevensuitwisseling tussen de verschillende applicaties.
Daarnaast verzorgt de ‘message broker’ op functioneel niveau dat de gegevensberichten volledig en correct worden aangeleverd. De message broker verzorgt hiermee de BUS- functionaliteit. De message broker bestaat uit een server-applicatie en een client-applicatie.
De server-applicatie zorgt voor de distributie en het beheer van de berichten. De client- applicatie communiceert met de business-applicatie. De ontvangstomgeving in het financiële domein maakt intensief gebruik van de client-functionaliteit.
Er worden verschillende type messages onderkend, waarvan de volgende de meest bekende zijn:
● Push message – een message wordt door een domein naar een ander specifiek domein verzonden als gevolg van het optreden van een gebeurtenis. Optioneel kan de verzender om een expliciete ontvangstbevestiging vragen. Deze vorm wordt vaak gehanteerd voor informatie die verzonden wordt naar het financiële domein. Essentieel is dat het
verzendende domein zich bewust is naar welk domein de message wordt verzonden. Het voordeel is dat het verzendende domein invloed heeft op het moment dat de actie wordt uitgevoerd. Dit kan in het geval van performance-kritische systemen een overweging zijn om deze message typologie te hanteren.
● Pull message – een message wordt naar een ander domein verzonden met een verzoek om gegevens, die als response worden teruggegeven. Hiermee kan het financiële domein o.a.
reconciliatie-gegevens ophalen uit een ander domein, maar ook een ‘batch van mutaties’.
Hierbij is essentieel dat het vragende domein zich bewust is uit welk domein de gegevens moeten komen. Als het financiële domein de vragende partij is, kan dit als voordeel hebben dat de vraag gesteld wordt op het moment dat de gegevens nodig zijn. Hierdoor beschikt het financiële domein over de meest recente situatie. De belasting van de beantwoordende systemen kan hierbij een rol spelen.
● Fire forget – een message wordt vanuit een domein verzonden en alleen op de bus geplaatst, zodat andere domeinen deze message van de bus kunnen halen als zij dit willen. Hierbij is essentieel dat de verzender zich niet bewust is wie het bericht van de bus haalt en de message ook niet nogmaals zal versturen. Dit type mag alleen worden
gebruikt voor niet-kritische gegevens. Het financiële domein maakt zelden gebruik van dit type message. Het grote voordeel dit type berichten is dat er minimale eisen aan de exchange agreement gesteld worden. Dit vereist wel dat de ontvanger continu controleert (listner) of er berichten op de bus worden geplaatst, die bestemd zijn voor het
betreffende domein. Het risico van deze berichtensoort is dat als de ‘listner’ tijdelijk niet beschikbaar is, de berichten voorgoed verloren zijn. Dit is een onwenselijke situatie voor het financiële domein.
Deze drie soorten zijn slechts een selectie uit de vele typen messages. Voor de reconciliatie moet de IT auditor aandacht schenken aan de keuzes die zijn/worden gemaakt voor het berichtenverkeer, zodat de volledigheid van het berichtenverkeer is gewaarborgd.
Een belangrijk aandachtspunt voor de IT auditor is wie direct toegang heeft tot de message- brokers, want hiermee kunnen direct messages worden gecreëerd en verzonden. Hiermee kan de integriteit van de gegevens worden verstoord. Dit kan leiden tot fouten in de financiële verslaglegging. Het reconciliatieproces kan deze ‘verstoringen’ aan het licht brengen.
2. Netwerk
De SOA infrastructuur kan alleen werken als er een netwerk is. Een belangrijke reden voor het ontstaan van de Service Oriented Architecture is het feit dat applicaties over verschillende (sub)netwerken moeten werken en er online data verkeer noodzakelijk is tussen de
verschillende applicaties. De message broker zorgt dat de communicatie tussen de netwerken en de applicaties gerealiseerd wordt. Hiermee worden versieverschillen tussen de
verschillende netwerken en business applicaties opgelost zonder dat hier op applicatieniveau maatregelen moeten worden getroffen. Voorbeelden van dergelijke overbruggingen zijn proprietary software in telefooncentrales, die berichten moeten versturen naar operationele systemen.
Bij de reconciliatie is het van belang om duidelijk te krijgen dat de verstuurde en ontvangen berichten tussen de verschillende netwerken consistent zijn. De technische reconciliatie kan eventuele verschillen aan het licht brengen.
3. Firewall voor externe connecties
De message broker applicatie moet op de juiste wijze geautoriseerd worden in de firewall om te kunnen communiceren met andere netwerken. De message broker kan hierbij ook encryptie en decryptie faciliteiten bieden. In de DMZ kan een message client staan om berichtenverkeer tussen de WEB-server en de message-broker te verzorgen. De firewall moet zo specifiek mogelijk worden ingericht, zodat de messages niet misbruikt kunnen worden voor andere doelstellingen dan is bedoeld met de messages. In de opzet van de messages moet specifiek worden bepaald welke messages wel en niet ‘extern’ gebruikt mogen worden. De ‘externe’
messages en firewall instellingen zijn onderhevig aan de procedure voor review van externe connecties. De IT auditor moet controleren dat de instellingen en messages ook daadwerkelijk door de review commissie zijn beoordeeld.
4. Applicatie servers (zowel WEB-server voor Internet als interne applicatie servers)
De applicaties communiceren met de message broker. Hiervoor wordt op de applicatie server een message client geïnstalleerd. De business applicatie stuurt naar en ontvangt berichten van deze client. De client stuurt vervolgens deze berichten naar de message-broker, die de berichten verstuurt naar de volgende applicatie of plaatst deze op de ‘bus’. De message client werkt ook als een zgn. ‘listner’. Dit proces controleert constant welke berichten op de bus geplaatst worden. Op het moment dat de ‘listner’ een bericht leest, dat gewenst is door de betreffende client, wordt dit gelezen en verwerkt door de applicatie.
5. Werkstations van gebruikers
De werkstations van de gebruikers (intern en extern) communiceren met de server applicatie.
Bij de opzet van SOA roepen de gebruikers services aan. Deze services worden direct aangeroepen bijvoorbeeld vanuit een WEB-applicatie.
3 Reconciliatieproces voor financiële verslaglegging
3.1 Inleiding
In het vorige hoofdstuk is beschreven, dat een reconciliatieproces voor de gegevensverwerking noodzakelijk is voor het financiële rapportageproces. In dit hoofdstuk wordt het
reconciliatieproces beschreven vanuit de AO/IC voor de controller van een bankbedrijf.
Uitgangspunt voor het reconciliatieproces is de functiescheiding beschreven door Starreveld:
• Beschikken – In veel gevallen is dit proces binnen het bankbedrijf volledig
geautomatiseerd d.m.v. logische toegangsbeveiliging en limietensysteem, waarbinnen een externe klant kan beschikken over de faciliteiten (geld op rekening-courant, kredietlimiet, etc.) en hier zonder tussenkomst van een bankmedewerker over kan beschikken. In een aantal gevallen is het vaststellen van de limieten ook geautomatiseerd.
• Uitvoeren – Er is in het algemeen een beperkte goederenstroom binnen een bank. De uitvoeringsfunctie (operations) is bij banken met name gericht op het correct vastleggen van financiële mutaties voor klanten. Ook het vastleggen van deze mutaties is vaak in hoge mate geautomatiseerd.
• Bewaren – De bewaarfunctie bij banken bestaat uit twee categorieën te weten een echte bewaarfunctie (bijv. kluisruimte, chartaal geld en effectenstukken) en een meer abstracte bewaarfunctie, namelijk het beheren van girale saldi in geautomatiseerde systemen.
• Registreren – De registratiefunctie is in het algemeen centraal belegd bij de controller van een bank. Met deze registrerende taak moet de controller aantonen (o.a. vanuit SOx- wetgeving en wetgeving voor jaarrekening, IFRS GAAP), dat het grootboek een getrouwe weergave van de werkelijkheid is. Door de controle van het grootboek door de interne en externe accountant toont de controller aan, dat de registrerende functie is vervuld. Als een bankbedrijf volgens verschillende ‘accounting principles’ de registratie voert, dan levert het reconciliatieproces een bijdrage aan het verklaren van verschillen in de
rapportages tussen de diverse ‘accounting principles’ (bijv. US GAAP versus IFRS GAAP).
• Controleren – In de basisadministraties en financiële administratie zijn diverse interne controlemaatregelen getroffen, o.a. functiescheiding, general IT controls, application controls, om de volledigheid van de financiële verslaglegging te waarborgen. Het
reconciliatieproces controleert de omspannende controletotalen, zodat de werking van de interne controlemaatregelen kan worden gevalideerd.
Het bankbedrijf is in hoge mate geautomatiseerd, waardoor de beschikkende, uitvoerende, bewarende en registrerende functie grotendeels geautomatiseerd plaatsvindt. De
geautomatiseerde reconciliatie zorgt ervoor, dat ook deze controle automatisch gaat.
In deze scriptie worden in het financiële domein de volgende rollen onderscheiden:
1. Operational controller – de financiële controller verantwoordelijk de registratieve mutaties in het grootboek voor verschillende juridische entiteiten;
2. Business unit controller – verantwoordelijk de resultatieve mutaties in het grootboek per juridische entiteit (bijv. Postbank, ING Bank) en verantwoordelijk voor de financiële rapportage voor de betreffende juridische entiteit;
3. Holding controller – verantwoordelijk voor de consolidatie van verschillende juridische entiteiten en de financiële rapportage van de holding;
4. Toezichthoudende reconciliatie functionaris – verantwoordelijk voor de controle op de operational controller en business controller t.a.v. administratieve reconciliatieprocedures die gevold moeten worden door de operational- en business controller.
De toezichthoudende rol op de business unit moet organisatorisch worden opgehangen bij de holding controller. Indien er business unit controllers zijn die verantwoordelijk zijn voor meerdere juridische entiteiten, dan kan de rol voor afzonderlijke juridische entiteiten worden opgehangen als staffunctionaris bij de business unit controller. Essentieel is dat de toezichthoudende rol onafhankelijk is van de operational controller en business controller.
3.2 Doelstelling reconciliatieproces De doelstelling van het reconciliatieproces is:
1. Controleren dat alle transacties zijn vastgelegd en volledig zijn geregistreerd in het grootboek (volledigheid registratieve mutaties);
2. Controleren dat alle resultatieve financiële mutaties zijn vastgelegd en volledig zijn geregistreerd in het grootboek (volledigheid resultatieve mutaties);
3. Controleren dat de opgeleverde financiële rapportages alle transacties verantwoorden, die volgens de specificaties van de rapportages moeten worden gerapporteerd en
overeenkomen met de waarden uit het grootboek (volledigheid rapportages).
4. Verklaren verschillen tussen verschillende ‘accounting principles’, die gehanteerd worden voor de financiële verslaglegging.
3.3 Processtappen
Bij banken wordt de functiescheiding gerealiseerd met logische toegangsbeveiliging. De general IT controls zorgen ervoor dat de juiste procedures worden gevolgd door de IT organisatie, zodat aangetoond kan worden dat de logische toegangsbeveiliging correct werkt. Daarnaast worden er geprogrammeerde applicatie controles gerealiseerd (bijvoorbeeld limieten), die controleren of de betreffende gebruiker binnen de (directie)richtlijnen blijft. Deze interne controlemaatregelen zijn preventief.
Praktisch alle registrerende processen verlopen bij de banken ook volledig geautomatiseerd. De controller moet in staat worden gesteld om te controleren, dat de geautomatiseerde verwerking van de basisadministraties tot en met de uiteindelijke financiële verslaglegging correct is
verlopen. Hiervoor moet de controller een controleproces inrichten. Dit reconciliatieproces bestaat uit verschillende stappen, waardoor met toenemende zekerheid kan worden aangetoond, dat de eerder gedefinieerde doelstellingen worden gerealiseerd.
Stap 1 Controleer de volledigheid van de ICT verwerking
Voordat de reconciliatie van de financiële gegevens kan plaatsvinden moet eerst vastgesteld worden, dat de ICT-verwerking correct heeft plaatsgevonden. Hiervoor worden in de verwerking controletotalen op bestanden en databases bepaald en vergeleken. Hiermee wordt aangetoond, dat technisch alle mutaties aan het financiële domein zijn aangeleverd en verwerkt. Met SOA is het belangrijk om synchronisatiepunten te hebben, zodat vastgesteld kan worden dat alle messages technisch correct zijn verwerkt.
De eerste stap is dus om de bevestiging te krijgen van de ICT afdeling, dat de technische gegevensverwerking is afgerond en correct is verlopen.
Stap 2 Controleer de volledigheid van stamgegevens in het grootboek
In de moderne grootboektoepassingen (Peoplesoft Enterprise General Ledger, SAP ERP GL, Hyperion Essbase) wordt veel detailinformatie vastgelegd, zodat deze gebruikt kan worden voor de verschillende rapportage-eisen. Hiervoor is een grote hoeveelheid stamgegevens noodzakelijk.
Dit zijn o.a. organisatiestructuur(mutaties), klant(mutaties), product(mutaties),
tarieven(mutaties). Deze gegevens worden deels vastgelegd in het grootboek. Het kenmerkende van deze gegevens is dat zij geen financiële waarde vertegenwoordigen.
Voor de controle van de volledigheid van deze gegevens krijgt de controller van de basisadministraties controletotalen vanuit verschillende dimensies, bijv. aantallen klanten
gedifferentieerd naar segmenten. Er moeten duidelijke afspraken zijn op welk moment de totalen worden bepaald. De operationele systemen moeten deze informatie onafhankelijk bepalen van de aanlevering van de gegevens aan het financiële domein. Bij de vaststelling van de controletotalen moet nadrukkelijk bewaakt worden, dat het grootboek een vergelijkbaar controletotaal kan opleveren. Het kenmerkende voor deze controletotalen is dat dit GEEN financiële controletotalen zijn. De volledigheid van de niet-financiële mutaties moet vastgesteld worden, want anders kunnen er mogelijk ook financiële mutaties niet verwerkt worden door het ontbreken van de stamgegevens. De afgekeurde financiële mutaties kunnen daardoor op tussenrekeningen terechtkomen.
Stap 3 Controleer de volledigheid van contracten en posities in het grootboek
De controle van contracten en posities is een controle, waarbij de aantallen en financiële posities in de basisadministraties vergeleken worden met de controletotalen uit het grootboek op een specifiek moment. Deze momentopname is het typerende kenmerk voor deze controle. Ook bij deze controle moet bij de opzet nadrukkelijk beoordeeld worden of het grootboek de
controletotalen op identieke wijze kan vaststellen. Deze controletotalen worden per productgroep(segment) vastgesteld.
Ook hierbij is het moment van het vaststellen van het controletotaal essentieel, waarbij als uitgangspunt geldt dat de administratieve verwerkingsdatum (dus niet valutadatum) als richtlijn geldt. Indien de boekdatum niet per definitie dezelfde datum is als de administratieve datum moet de IT auditor vaststellen op welke wijze vastgesteld wordt dat het controletotaal een duidelijk gedefinieerd moment is en deze ook vast te stellen is in het grootboek. Dit kan betekenen dat deze gegevens additioneel doorgegeven moeten worden aan het grootboek.
Stap 4 Controleer de volledigheid van mutaties in het grootboek
Deze stap controleert dat alle mutaties, die tot een registratieve mutatie moeten leiden, ook daadwerkelijk zijn doorgegeven aan het grootboek. De controletotalen bestaan uit aantallen, totaal toename saldi en totaal afname saldi. Het kenmerkende van deze controletotalen is dat deze over een periode gelden. De periode van de mutaties moet gelijk zijn aan de periode tussen twee reconciliatiemomenten van de contracten en posities. Hiermee kan het omspannende
controletotaal worden bepaald:
Beginsaldo periode + toename – afname = eindsaldo periode
Stap 5 Controleer de volledigheid van resultatieve mutaties in het grootboek
De resultatieve mutaties zijn mutaties die in het grootboek worden aangebracht als gevolg van de analyse van de registratieve mutaties. Het toenemen van het kredietrisico kan leiden tot
additionele reserveringen. Ook kan op basis van de resultaten bepaald moeten worden welke overige voorzieningen getroffen moeten worden, zoals ‘te betalen belasting’. Voor deze
resultatieve mutaties gelden verschillende regels en elke periode moeten deze mutaties worden uitgevoerd.
De volledigheid van deze resultatieve mutaties wordt in het algemeen procedureel afgehandeld.
Na afronding van de resultatieve mutaties kunnen de controletotalen voor deze mutaties worden bepaald.
Stap 6 Controleer de consistentie tussen grootboek en datawarehouse
De controletotalen van het grootboek zijn na de vergelijking met de basisadministratie leidend.
Het datawarehouse moet zich conformeren aan het grootboek. De opbouw van het datawarehouse is echter een aparte applicatie (ETL en/of rules engine). Hierdoor zouden verschillen kunnen ontstaan. De controletotalen, bepaald bij stap 1 t/m 4, moeten dan ook gereconcilieerd worden met de controletotalen in het datawarehouse. Het datawarehouse moet hiervoor dezelfde selectiecriteria hanteren als het grootboek. Hierbij is het belangrijk dat er ook controletotalen zijn die ALLE gegevens selecteren, want het risico van controletotalen is dat er producten niet geselecteerd worden voor het controletotaal, maar later wel in de rapportages worden opgenomen.
Stap 7 Controleer de rapportage gebaseerd op het grootboek en datawarehouse
De rapportage wordt gemaakt op basis van het grootboek (eerste keuze) en het datawarehouse (indien het grootboek onvoldoende details bevat). Bij de gemaakte FA rapportages moet
gecontroleerd worden dat de totalen van de rapportage aansluiten met het grootboektotalen en de datawarehouse-totalen. Deze controle moet onderdeel zijn van de definitieve goedkeuring van de FA rapportage. Tenslotte moet de gehele rapportagebasis en rapportage worden bevroren, zodat hierop geen wijzigingen meer kunnen plaatsvinden.
3.4 Reconciliatierapportages
De reconciliatie rapportages zijn de audit trail van het reconciliatieproces. Ook de reconciliatie kan in grote mate geautomatiseerd worden. Bij materiële afwijkingen moet de controller
onderzoek gaan uitvoeren. Nadrukkelijk moeten hierbij richtlijnen gegeven worden, die bepalen of een afwijking wel of niet materieel is. Dit kan in percentages, absolute bedragen of een
combinatie van beide. In de administratieve procedure voor de controller moet worden opgenomen, dat het reconciliatieverslag wordt afgetekend in combinatie met de bijbehorende grootboekverslagen.
3.5 Functiescheiding binnen het reconciliatieproces
De hoge mate van automatisering binnen het bankbedrijf leidt ertoe, dat de functiescheiding wordt gerealiseerd met logische toegangsbeveiliging en applicatieve maatregelen. Ook in het reconciliatieproces kan er functiescheiding worden aangebracht. De controle op de reconciliatie moet door een functionaris worden uitgevoerd die niet verantwoordelijk is voor de verwerking van de gegevens. Deze controlerende functionaris moet in een onafhankelijke eenheid vallen. In mijn opzet is dit het team financiële administratieve organisatie, maar dit zou ook een interne audit afdeling kunnen zijn. Desgewenst kan ook functiescheiding worden aangebracht tussen de verschillende controle stappen.
4 Wettelijk en theoretisch kader
4.1 Inleiding
In dit hoofdstuk wordt de Service Oriented Architecture en de financiële reconciliatie gepositioneerd voor een aantal relevante theoretische en wettelijke kaders.
Uit de beschikbare kaders zijn de volgende gekozen:
• Financiële Instellingen Risicoanalyse Methode van de Nederlandse Bank (FIRM)
• ISO 17799 Code of practice for information security management (CoP)
• Sarbanes Oxley act 404 (SOx)
• Clark & Wilson model (C&W)
De context van Financial Instellingen Risicoanalyse Methode (FIRM) heb ik gekozen, doordat hiermee nadrukkelijk gekeken wordt naar de risicobeoordeling door banken. Hiermee worden de risico’s geïnventariseerd, die de implementatie van SOA met zich meebrengt gezien vanuit DNB.
Daarnaast wordt beschreven welke risico’s juist worden gemitigeerd door de opzet van reconciliatie, zodat het netto risico aanvaardbaar is en door financiële reserves kan worden afgedekt.
De US Act 404 Sarbanes Oxley (SOx) geeft richtlijnen (control objectives), die gericht zijn op de beheersing van de informatiesystemen betrokken bij financiële verslaglegging van
ondernemingen, die genoteerd zijn aan de Amerikaanse beurs (bijv. ABN AMRO en ING). In deze paragraaf wordt ingegaan op welke wijze SOA consequenties heeft voor de IT controls van Sarbanes Oxley. In dit referaat wordt beschreven op welke wijze SOA en het reconciliatiemodel een bijdrage leveren aan de versterking van de interne controle, die vanuit SOx wordt geëist.
De ISO 17799 Code of Practice for information security (CoP) management geeft invulling aan de general IT controls . De CoP richt zich nadrukkelijk op de maatregelen van de vertrouwelijkheid, integriteit en beschikbaarheid. In dit referaat wordt beschreven welke van de controls relevant zijn voor de implementatie van SOA en reconciliatie.
Het Clark & Wilson model wordt in dit referaat gebruikt om de applicatieve richtlijnen voor de integriteit van de gegevens te waarborgen voor de implementatie van SOA en reconciliatie.
Er zijn verschillende richtlijnen en wetten (o.a. US GAAP, Basel2 en IFRS) voor de financiële rapportage door financiële instellingen, maar deze richten zich nadrukkelijk op de eisen aan de financiële rapportage en de correcte interpretatie van de financiële gegevens. Deze richtlijnen zijn wel essentieel voor de financiële verslaglegging, maar zijn minder gericht op interne controle en daardoor minder relevant voor de beheersing van de IT. Om deze reden wordt in dit referaat niet verder op deze richtlijnen ingegaan.
4.2 Interpretatie FIRM voor SOA en reconciliatie 4.2.1 Inleiding
De banken staan onder het toezicht van De Nederlandsche Bank. Voor de risico bepaling bij financiële instellingen gebruikt DNB FIRM, Financiële Instellingen Risicoanalyse Methode. DNB brengt hiermee het risicoprofiel van de verschillende financiële instellingen objectief in beeld. De techniek bestaat uit verschillende onderdelen:
a) Solvabiliteitspositie en solvabiliteitsbeheersing;
b) Liquiditeitspositie en liquiditeitsbeheersing c) Organisatie en beheersing
d) Integere bedrijfsvoering
Vanuit IT audit perspectief is met name groep C, Organisatie en beheersing, relevant, want hierin worden de IT-risico’s geanalyseerd en beoordeeld. Binnen FIRM worden twee bronnen van risico’s onderkend, namelijk risicocategorieën en beheersingscategorieën.
Risicocategorieën
Financiële risico's Niet-financiële risico's Beheersingscategorieën
Matching-/renterisico Omgevingsrisico Risicospecifieke beheersing
Marktrisico Operationeel risico Organisatie
Kredietrisico Uitbestedingsrisico Management
Verzekeringstechnisch risico IT-risico Solvabiliteitsbeheersing
Integriteitsrisico Liquiditeitsbeheersing
Juridisch risico
Het IT-risico wordt gedefinieerd als het risico dat bedrijfsprocessen en informatievoorziening onvoldoende integer, niet continu of onvoldoende beveiligd worden ondersteund door IT. Binnen de categorie IT-risico worden de volgende risico items onderkend:
a) Strategie en beleid – het risico als gevolg van het niet of onvoldoende toegesneden zijn van IT- strategie en IT- beleid op de bedrijfsprocessen en de bestaande informatie- en dataverwerking, waardoor onvoldoende ondersteuning wordt geboden aan processen en informatievoorziening.
b) Beveiliging – het risico als gevolg van
• Het onvolledig of inaccuraat zijn van de informatie, de informatiesystemen en/of de processen;
• Het niet toegankelijk zijn van de informatie voor geautoriseerde gebruikers;
• Het toegankelijk zijn van informatie voor ongeautoriseerde gebruikers.
c) Beheersbaarheid – het risico als gevolg van
• Ontoereikende beheersing van de ICT-omgeving en/of processen;
• Het onvoldoende (tijdig) kunnen anticiperen op ontwikkelingen in de business, op technische innovatie of op overige externe factoren.
d) Continuïteit – het risico dat de continuïteit van de (kritische) bedrijfsprocessen en/of de gehele instelling in gevaar komt als gevolg van het onbeschikbaar zijn van de IT-
infrastructuur (waaronder applicaties en systemen).
De IT-risico’s moeten adequaat worden afgedekt door IT-beheersmaatregelen. FIRM zegt niets over de specifieke maatregelen die moeten worden getroffen. In de volgende paragraaf wordt het kader voor deze maatregelen beschreven a.d.h.v. de Code of Practice for information security management. Voor de beoordeling van het inherente IT-risico hanteert DNB een viertal gradaties, namelijk:
1. Laag inherent risico – geringe kans dat het optreden van het risico leidt tot hoge impact;
2. Beperkt inherent risico – wijziging van omstandigheden zou kunnen leiden tot hoge impact. Dit risico moet bewaakt worden. Hiervoor moeten maatregelen getroffen zijn;
3. Aanzienlijk inherent risico – aanmerkelijk hoge waarschijnlijkheid dat het optreden van het risico leidt tot hoge impact;
4. Hoog inherent risico – het risico zal zich, zonder adequate beheersing, zeker voordoen en een aanzienlijke tot hoge impact hebben. De beheersing van het risico door de instelling verdient grote aandacht.
Uitgangspunt voor FIRM is dat een instelling door het treffen van beheersmaatregelen het inherente risico kan reduceren. Er zal altijd een restrisico overblijven, waarvoor de financiële instellingen dan financiële reserves moet aanhouden.
Voor de banken is het hierdoor financieel aantrekkelijk om goede beheersmaatregelen te treffen.
De beoordelingscriteria voor de beheersing van de IT-risico’s richt zich op de volgende categorieën:
1. Risico-identificatie – worden IT-risico’s adequaat onderkend en zijn hier standaard processen voor ingericht. Dit kan plaatsvinden door business impactanalyses uit te laten voeren voor de verschillende ICT-componenten. Daarnaast kan door een CIA-rating mechanisme worden aangetoond, dat een beoordeling is gemaakt van de IT-risico’s.
2. Risicobeleid – duidelijke richtlijnen en beleid voor IT-organisatie op welke wijze de risico’s moeten worden beheerst.
3. Risicobewaking – IT-management zorgt ervoor dat zij inzicht hebben in de risico’s, dat de risico’s worden bewaakt en dat zij op de hoogte zijn van de regelgeving t.a.v. IT.
4. Organisatie – binnen de IT-organisatie worden de risico’s beheerst d.m.v. IT-governance, security management proces, management richtlijnen en adequate beschrijving en
inrichting van de taken, verantwoordelijkheden en bevoegdheden van de IT organisatie.
5. Beveiligingscriteria – vertrouwelijkheid, integriteit en continuïteit is gewaarborgd 6. Beheerprocessen – de verschillende IT-processen zijn adequaat ingericht (bijv. volgens
ITIL of Cobit4).
7. Systeem c.q. applicatiegebonden – systemen en applicaties maken maximaal gebruik van de mogelijkheden van geprogrammeerde controles en beveiligingsfaciliteiten.
De risicobeheersmaatregelen die getroffen zijn, reduceren het risico. DNB verwacht van de financiële instellingen in Nederland, dat zij zichtbaar maken welk netto risico resteert na het nemen van de beheersmaatregelen. Voor het resterende netto risico moeten de financiële instellingen een reserve aanhouden bij DNB. Deze reserve gaat voor de volle 100% af van het economisch kapitaal van de financiële instelling. Daarom is dit onvoordelig voor de financiële instellingen. De controllers van de financiële instellingen streven ernaar deze verplichte reserve zo laag mogelijk te houden. Hiermee heeft DNB een krachtig instrument om beheersmaatregelen bij de financiële instellingen af te dwingen.
4.2.2 FIRM analyse en SOA
Het inherente IT-risico bij de banken (ING, Fortis, Rabobank, ABN Amro e.d.) in Nederland wordt als hoog beoordeeld door de DNB om o.a. de volgende redenen:
1. Internationale geografische spreiding
2. IT omgeving ondersteunt Asset & Liability management, trading en brokerage 3. Transacties door klanten rechtstreeks op het Internet
4. Veel verschillende platformen, applicaties en leveranciers 5. Veel IT projecten per jaar
6. IT systemen zijn beperkt geïntegreerd
7. Er vinden aanzienlijke wijzigingen in de functionaliteit van applicaties plaats 8. Aanzienlijke externe koppelingen met systemen bij andere partijen
9. Aanzienlijke hoeveelheid administratieve mutaties en transacties
Dit hoge risico vereist sterke (risicomitigerende) beheersmaatregelen, zodat het netto risico gereduceerd wordt tot een aanvaardbaar niveau volgens de richtlijnen van DNB. Voor dit netto risico moeten dan financiële reserves worden aangehouden.
De implementatie van SOA brengt een aantal inherente IT-risico’s met zich mee, waarvoor IT beheersmaatregelen moeten worden getroffen. De toename van IT-risico’s moet worden afgewogen tegenover de versterking van de beheersmaatregelen in de andere DNB risicocategorieën die door de implementatie van SOA en het reconciliatie model wordt gerealiseerd. De beheersing op de volgende gebieden wordt versterkt:
• Matching- en renterisico
o De voor de risicomodellering gehanteerde data wordt actueler. Door de
reconciliatie wordt de volledigheid, juistheid en betrouwbaarheid verhoogd. Door de reconciliatie kan het financieel datawarehouse worden gebruikt om de
risicomodellering verder te versterken en de analyse horizon te versterken, doordat de gegevens uit het grootboek gecombineerd worden met externe bronnen.
• Marktrisico
o Identiek aan het matching- en renterisico.
o Met SOA wordt het mogelijk om uitgevoerde transacties, ingenomen risicoposities en aangegane verplichtingen juister, tijdiger en vollediger vast te leggen. SOA biedt de mogelijkheid om vanuit de verschillende domeinen ‘near real-time’ de gegevens te verwerken, zodat de limieten adequaat bewaakt kunnen worden. De reconciliatie kan vervolgens bewaken, dat aangegane risico’s voldoende zijn afgedekt.
• Kredietrisico
o Met SOA kunnen de relevante kredietrisico’s zeer frequent en gedetailleerd in kaart worden gebracht. Op basis van het grootboek zijn de kredietrisico’s bekend. Het financieel datawarehouse biedt de mogelijkheid om de details toe te voegen en bij gewijzigde risicomodellen toch de juiste aspecten in kaart te brengen. De
reconciliatie tussen grootboek en financieel datawarehouse zorgt dat DNB het datawarehouse als bron accepteert.
o De informatie-eisen voor het kredietrisico is om frequente, juiste en volledige informatie over de kredietposities te bieden. SOA biedt de mogelijkheid om de risicoposities veel sneller integraal in beeld te hebben. Het datawarehouse biedt de mogelijkheid om een verdieping aan het brengen in de aard van de kredietposities, en flexibel andere indelingscriteria te kiezen voor de rapportage en de
bijbehorende voorzieningen. De reconciliatie bewaakt de volledigheid.
De IT auditor moet bij het beoordelen van het reconciliatieproces inzicht hebben op deze
financiële risico’s en consequenties voor het economisch kapitaal bij de financiële instellingen. Bij de audit van het reconciliatieproces moet specifiek aandacht worden geschonken aan de volledige verantwoording van deze risico’s. Vanuit de DNB wordt vereist dat banken deze volledigheid over het gehele risico management proces inzichtelijk kunnen maken.
Voor het reconciliatieproces met SOA moet worden vastgesteld op welke wijze de ‘pipeline’
transacties correct in de risicoposities worden opgenomen, zodat een consistent beeld tussen de risicoposities ontstaat. Het reconciliatieproces kan dit verzorgen door bij de controletotalen de
‘pipeline’ transacties te verbijzonderen.
