Inleiding

Binnen organisaties vinden verschillende processen plaats, afhankelijk van het type organisatie. Eén proces dat in iedere organisatie plaatsvindt, ongeacht het type of de grootte van het bedrijf, is het betalingsproces. De mate van complexiteit van dit proces kan echter aanzienlijk variëren, afhankelijk van de omvang van het bedrijf en de bedrijfstak. Ook de mate van internationalisatie van een organisatie is van invloed op de complexiteit van het betalingsproces. Een organisatie die internationaal opereert, heeft te maken met grensoverschrijdende betalingen. Ook moeten internationale organisaties voldoen aan diverse buitenlandse wet- en regelgeving die van invloed kan zijn op de interne bedrijfsprocessen. Internationale organisaties hebben dikwijls een gecentraliseerde betalingsorganisatie, ook wel geïntegreerd met een treasuryafdeling. Lokale organisaties hebben echter een kleinschaliger, minder complexe betalingsorganisatie.

In dit artikel wordt ingegaan op de betalingsprocessen binnen een lokaal georganiseerde organisatie, met een kleinschalige betalingsorganisatie. Dit artikel streeft na inzicht te verschaffen in de specifieke risico’s van het uitvoeren van elektronische betalingen. Een veelgebruikt programma voor het uitvoeren van elektronische betalingen is OfficeNet van ABN AMRO. Verschillende pakketten van OfficeNet zijn beschikbaar, met ieder pakketspecifieke beveiligingsmogelijkheden. Daarnaast is er nog een aantal procedurele controles die binnen de organisatie gehanteerd kunnen worden ter waarborging van de juistheid, de volledigheid en de autorisatie van betalingen. In dit artikel worden allereerst de verschillende betalingsprocessen binnen OfficeNet beschreven. Vervolgens worden per processtap de risico’s geïdentificeerd. Daarna wordt een overzicht gegeven van de te nemen maatregelen om deze risico’s af te dekken. Ten slotte worden de aandachtspunten voor de auditor weergegeven in een controlematrix. Voor deze controlematrix is specifiek gekeken naar het pakket OfficeNet Extra. Voor andere pakketten van OfficeNet kunnen de beschreven instellingen afwijkend zijn.

Aansluitend is een korte paragraaf gewijd aan de verschillen tussen een lokaal georiënteerde organisatie en een internationale organisatie, waarbij enkele invloeden van globalisering op het betalingsproces worden aangeduid.

OfficeNet Extra

OfficeNet Extra is opgebouwd uit OfficeNet Direct met, afhankelijk van de betreffende versie, een aantal additionele modules, die ieder optioneel te installeren zijn. De meest recente versie, OfficeNet Direct 1.5, heeft drie modules. Versie 1.4 heeft er vier. Met OfficeNet Direct is het mogelijk een directe koppeling te maken met een financieel systeem. Door middel van deze koppeling kunnen betalingsopdrachten worden ingelezen. Met de modules ‘Binnenland betalen’, ‘Buitenland betalen’ en ‘Incasso’ kunnen zelf betalingsopdrachten worden aangemaakt. Daarnaast worden in versie 1.4 met de module ‘Rapportage’ rapportagemogelijkheden geboden ([AVEB]). In versie 1.5 is deze functionaliteit geïntegreerd in OfficeNet Direct. OfficeNet kan op het netwerk geïnstalleerd worden, daarnaast kan OfficeNet apart op een pc worden geïnstalleerd. Batchbestanden kunnen via het netwerk worden ingelezen, of via een floppy of USB-stick worden overgebracht. De structuur van OfficeNet Extra 1.4 is in figuur 1 weergegeven.

Figuur 1. Structuur OfficeNet Extra 1.4. (Bron: Pakketspecifieke aanvullingen op de richtlijnen ‘Veilig elektronisch bankieren bij ABN AMRO’.)

Beveiliging

Aan het betalingsproces zijn verschillende inherente risico’s verbonden (zie paragraaf ‘Risico’s’). Een inadequate beheersing van de betalingsapplicatie is er één van. Om dit risico te reduceren zijn door ABN AMRO diverse maatregelen genomen binnen OfficeNet. Daarnaast kan de organisatie zelf controlemaatregelen implementeren. Deze maatregelen zijn zowel op applicatieniveau als op netwerkniveau van toepassing. Hieronder worden de belangrijkste beveiligingsmaatregelen opgesomd.

Om toegang te verkrijgen tot OfficeNet moet worden ingelogd met een gebruikersnaam en wachtwoord. OfficeNet dwingt niet af dat wachtwoorden periodiek gewijzigd moeten worden, dit moet procedureel worden afgedwongen. Wel dienen wachtwoorden minimaal acht karakters lang te zijn en minimaal een cijfer en een letter te bevatten. Alleen de hoofdgebruiker (dit is de gebruiker met alle bevoegdheden binnen OfficeNet) heeft de mogelijkheid om wachtwoorden van andere gebruikers te resetten.

Voordat betalingsopdrachten naar de bank verstuurd kunnen worden, moeten deze in OfficeNet door een of twee gebruikers gefiatteerd worden. Voor het fiatteren van betalingsopdrachten in OfficeNet kan men kiezen uit twee beveiligingsmiddelen, een calculator en een smartcard. De smartcard bevat een sleutel die correspondeert met een sleutel van de server bij ABN AMRO. Op deze server zijn de bevoegdheden opgeslagen die aan een specifiek gebruikersnummer zijn gekoppeld. Deze bevoegdheden betreffen rechten om betalingsopdrachten ‘alleen’ of ‘samen’ te fiatteren en/of te verzenden naar de bank. In het Electronic Banking Contract met ABN AMRO zijn de bevoegdheden per smartcard beschreven en wordt een overzicht gegeven van de in gebruik genomen smartcards. In OfficeNet moet vervolgens door de hoofdgebruiker worden vastgelegd welke gebruiker van welk gebruikersvolgnummer met bijbehorend beveiligingsmiddel gebruikmaakt. Bovendien kan de hoofdgebruiker in OfficeNet aan gebruikers beperkende bevoegdheden opleggen, zoals fiatteringslimieten en schermprocuraties. Het is weliswaar mogelijk in OfficeNet andere rechten toe te kennen aan een gebruiker, deze opdrachten zullen echter niet kunnen worden gefiatteerd of worden verzonden naar de bank.

De smartcard biedt extra mogelijkheden in vergelijking met de calculator, zoals het autoriseren van opdrachten met twee handtekeningen en het op afstand laten tekenen van opdrachten (de zogenaamde ‘remote sign’-mogelijkheid) ([VEB]).

Als men gebruikmaakt van een smartcard voor het fiatteren van opdrachten, is ook een viercijferige pincode vereist. Iedere smartcard heeft een unieke initiële pincode, die vervolgens in OfficeNet kan worden gewijzigd. Het is mogelijk dergelijke wijzigingen af te dwingen in OfficeNet.

Ten slotte is ook een apart bankwachtwoord vereist om betalingsopdrachten te kunnen verzenden naar de bank.

Een andere beveiligingsmaatregel is functiescheiding. Binnen OfficeNet kunnen de volgende functies worden onderscheiden ([VEB]):

• data entry functie: het invoeren van betalingsopdrachten. Autoriseren en verzenden zijn niet mogelijk. Hierbij is geen beveiligingsmiddel nodig (smartcard of calculator).
• autorisatiefunctie: het elektronisch ondertekenen (fiatteren) van ingevoerde betalingsopdrachten. Hierbij is een beveiligingsmiddel (smartcard) nodig.
• verzendfunctie: het verzenden van de betalingsopdrachten naar de bank, nadat deze zijn geautoriseerd. Hierbij is een beveiligingsmiddel nodig. Bij het gebruik van een calculator zijn de autorisatie- en de verzendfunctie gecombineerd.

Binnen het betaalproces is het van essentieel belang dat er functiescheiding is tussen het invoeren en het autoriseren van betalingsopdrachten. In principe kan deze functiescheiding niet technisch worden afgedwongen; daarom is het van belang dat organisatorische maatregelen zijn geïmplementeerd om op deze wijze de functies invoeren en autoriseren van betalingsopdrachten te scheiden. OfficeNet biedt de mogelijkheid om functiescheiding af te dwingen tussen het autoriseren en verzenden van betalingsopdrachten.

Daarnaast is het ook mogelijk beveiligingsmaatregelen op netwerkniveau te implementeren om zodoende de verschillende modules en directories van OfficeNet af te schermen van ongeautoriseerd gebruik.

Procesbeschrijvingen

Binnen OfficeNet kunnen twee typen betalingen plaatsvinden, losse betalingen en batchbetalingen. In figuur 2 is het verloop van beide processen schematisch weergegeven.

Figuur 2. Procesdiagram betalingen in OfficeNet.

In onderstaande subparagrafen worden beide processen beschreven.

Batchbetalingen

1 Betaallijst

In externe financiële systemen (bijvoorbeeld Exact, FIS2000 of Oracle Financials) worden de betalingen ingevoerd. Vervolgens worden deze in een batch klaargezet om te worden geëxporteerd naar een betalingsbestand.

2 Clieop03-betalingsbestand

Het financieel systeem genereert een Clieop03-bestand (binnenlandse betalingen of incasso) of een BTL91-bestand (buitenlandse betalingen) met hierin de betalingsopdrachten. Een Clieop03-bestand is een onversleuteld tekstbestand dat met bijvoorbeeld de tool Notepad kan worden geopend. Dit Clieop03-bestand dient in een specifieke directory van OfficeNet te worden geplaatst. Standaard geldt de volgende directory: C:Program FilesOfficeNet ExtraClieop03.

3 Import file

De opdrachten uit de directory worden automatisch geïmporteerd zodra OfficeNet wordt opgestart en in de map ‘Opdrachten’ de optie ‘Geïmporteerd’ wordt aangeklikt. Deze map is alleen toegankelijk als de gebruiker hiervoor geautoriseerd is (via de schermprocuraties); is de gebruiker niet geautoriseerd, dan is de map niet zichtbaar.

Na import van het Clieop03-bestand in OfficeNet wordt het bestand automatisch uit de directory verwijderd.

In OfficeNet kan na import de mate van correctheid van de geïmporteerde bestanden worden gezien. Indien een opdrachtbestand één of meer fouten bevat, kan dit bestand niet worden verwerkt door de bank. Ook kunnen foutieve bestanden niet worden geautoriseerd in OfficeNet. Deze betalingsopdracht heeft dan de status ‘geweigerd’. Tevens kan de reden van weigering worden weergegeven. Een geweigerd bestand kan worden verwijderd; de gebruiker dient hier wel voor geautoriseerd te zijn ([OND]).

Ook kan de status ‘gecorrigeerd’ worden getoond. Dit bestand bevat dan betalingen waarin bij het importeren aanpassingen zijn gemaakt door OfficeNet. Deze aanpassingen zijn niet van invloed op de ‘kritische’ gegevens (bedrag, rekeningnummers) van de opdracht, maar zijn wel noodzakelijk om het opdrachtenbestand te kunnen laten verwerken door de bank. Het betreft dan bijvoorbeeld de lengte van de naam van de begunstigde. De tekenbevoegde gebruiker heeft dan de mogelijkheid om de correctie te accepteren en de opdracht te tekenen of de gehele opdracht te verwijderen. Indien de gebruiker niet geautoriseerd is, zijn deze opties niet mogelijk en blijft het bestand aanwezig ([OND]).

4 Controle betaallijst

Na import van het Clieop03-bestand zijn de geïmporteerde gegevens in detail of als totalen zichtbaar onder het scherm ‘Geïmporteerd’. Deze gegevens dienen te worden vergeleken met de betaallijst uit de boekhoudapplicatie. De gegevens die vergeleken kunnen worden, zijn:

• Som rekeningnummers;
• Totaalbedrag;
• Aantal opdrachten.

Hiervoor kan een verslag van de ingelezen bestanden bekeken worden in OfficeNet (onder ‘Import verslagen’). Tevens kan de gebruiker individuele opdrachtbestanden uit een batch bekijken. Een voorbeeld van een importverslag is in figuur 3 weergegeven, waarbij de te vergelijken items zijn omcirkeld.

Figuur 3. Importverslag in OfficeNet.

5 Autorisatie batch

Na controle wordt de betalingsopdracht klaargezet voor autorisatie. Binnen OfficeNet kan per rekening worden ingesteld of betalingsopdrachten door één of twee personen moeten worden geautoriseerd. Autorisatie vindt plaats door middel van een smartcard of calculator, waarbij het opdrachtbestand wordt voorzien van een (of twee) elektronische handtekening(en). Ook kan per gebruiker een fiatteringslimiet worden aangegeven.

Daarnaast bestaat de mogelijkheid om betalingsopdrachten op afstand te laten tekenen, de zogenaamde ‘Remote Sign’-optie. Hierbij worden betalingsopdrachten door twee personen geautoriseerd, waarbij de eerste autorisatie ‘lokaal’ plaatsvindt. De tweede persoon haalt met OfficeNet vanaf een andere locatie de geautoriseerde bestanden op, waarna hij deze voor de tweede maal autoriseert ([OND]).

6 Verzending batch

Na autorisatie kan de betalingsbatch worden verzonden naar de bank. Naast de smartcard moet voor de communicatie met de bank een bankwachtwoord worden ingevoerd. De communicatie vindt alleen plaats bij een juiste combinatie van pincode en bankwachtwoord of calculator en respons.

7 Ontvangst bank

Na verzending wordt de betalingsopdracht ontvangen door de bank. Het transport van de gegevens naar de bank is beveiligd door middel van encryptie. Hierbij wordt gecontroleerd of de gegevens bij de bankcomputer aankomen zoals ze zijn verzonden.

8 Controle dagafschrift

Na ontvangst van het dagafschrift van de bank dient dit afschrift vergeleken te worden met de uitdraai uit OfficeNet van ‘verzonden opdrachten’. In OfficeNet versie 1.5 is het tevens mogelijk de status van de verzonden opdrachten te bekijken (verstuurd, goed ontvangen, etc.).

Losse betalingen

In het geval van losse betalingen kan gebruik worden gemaakt van een vast adresboek. Deze crediteuren zijn vooraf geregistreerd in OfficeNet. Het is echter ook mogelijk geen gebruik te maken van dit vaste adresboek. In deze situatie worden de naam en het rekeningnummer direct in de betalingsopdracht ingevoerd. Het is in OfficeNet niet mogelijk af te dwingen dat betalingen alleen naar deze geregistreerde crediteuren worden overgemaakt. Ook als gebruik wordt gemaakt van het adresboek is het mogelijk direct naam en rekeningnummer in de betalingsopdracht in te voeren. Het gebruik van bestemmingsrekeningen kan wel bij de bank worden vastgelegd in een afzonderlijk contract, namelijk het Electronic Banking Contract. Als er betalingsopdrachten worden gegeven, verwerkt de bank deze uitsluitend als de rekening van de crediteur is opgenomen als bestemmingsrekening ([VEB]).

1 Factuur

Een medewerker ontvangt de factuur. In het geval dat gebruik wordt gemaakt van een vaste crediteurenlijst, wordt gecontroleerd of de crediteur al geregistreerd staat in OfficeNet. In het geval dat de crediteur niet geregistreerd staat in OfficeNet, kan deze eerst worden toegevoegd aan de vaste crediteurenlijst, of kan direct een betalingsopdracht worden aangemaakt.

2 Aanmaken betalingsopdracht

Als de crediteur geregistreerd is in OfficeNet, wordt de betalingsopdracht aangemaakt. Hiervoor wordt de crediteur geselecteerd en het bedrag wordt conform de factuur ingevoerd.

Als er geen gebruik wordt gemaakt van het adresboek, wordt op basis van de gegevens van de factuur de betalingsopdracht aangemaakt. Hiertoe worden het rekeningnummer, NAW-gegevens en het bedrag ingevoerd.

3 Import file

Net als bij batchbetalingen uit financiële systemen maakt OfficeNet bij een losse betalingsopdracht een zogenaamd ‘Cliaab’ (Clieop03 ABN AMRO-bestand) aan dat in een specifieke directory wordt geplaatst. Dit is dezelfde directory als de directory waarin de Clieop03-bestanden met batchbetalingen worden opgeslagen. De losse betalingsopdrachten in het Cliaab zijn, in tegenstelling tot de batchbetalingen, standaard voorzien van een ‘hash’-controlegetal. Dit controlegetal wordt volgens een bepaald algoritme berekend op basis van de betalingsinformatie in het bestand. Bij het inlezen van de betalingsopdrachten in OfficeNet wordt het ‘hash’-getal opnieuw berekend. Indien dit berekende ‘hash’-getal afwijkt van het ‘hash’-getal dat in het Cliaab is opgeslagen, wordt het bestand door OfficeNet geweigerd en wordt het bestand niet geïmporteerd.

4 Autorisatie

Bij losse betalingen moeten de betalingsopdrachten voor autorisatie worden vergeleken met de facturen, waarbij controle moet plaatsvinden op naam en rekeningnummer van de crediteur en op het bedrag. Technisch verloopt de autorisatie vervolgens identiek aan de autorisatie van de batchbetalingen.

De stappen ‘Verzenden’, ‘Ontvangst bank’ en ‘Controle dagafschrift’ verlopen ook identiek aan de batchbetalingen.

Risico’s

Binnen de beschreven processtappen is een aantal risico’s te onderscheiden die van invloed zijn op de juistheid, de volledigheid en de autorisatie van betalingen. Ook hierbij kan een onderverdeling worden gemaakt naar batchbetalingen en losse betalingen. In tabel 1 wordt een overzicht gegeven van de risico’s en de te treffen controlemaatregelen binnen de organisatie, welke zijn toegespitst op het gebruik van OfficeNet. Algemene computercontroles (general IT controls) vormen een onderdeel van de te treffen beheersingsmaatregelen. Gezien het algemene karakter van de general IT controls zijn deze in dit artikel buiten beschouwing gelaten.

Tabel 1. Risico’s en controlemaatregelen betalingsproces. [Klik hier voor grotere afbeelding]

De loggingfunctie van OfficeNet biedt beperkte mogelijkheden voor controle. Er zijn zeven verschillende ‘log levels’ waarop logging kan plaatsvinden. Logging van beveiligingsgerelateerde informatie is beperkt tot de maximumgrootte van het logbestand. Dit kan worden ingesteld door de hoofdgebruiker. Daarnaast is de gebruiker in staat het logbestand te wissen.

Gezien de aard van het proces is het daarom raadzaam te steunen op de detectieve maatregelen, zoals die in tabel 1 zijn beschreven.

Globalisatie

Binnen het betalingsproces dienen de betrouwbaarheid en de rechtmatigheid van betalingen te worden gewaarborgd. Echter, een internationale organisatie met grensoverschrijdende betalingen wordt behalve aan bovenstaande risico’s ook blootgesteld aan risico’s die zijn ontstaan als gevolg van de globalisering. Schaalvergroting en een toename van wet- en regelgeving zijn hier enkele voorbeelden van.

Wijzigingen in wet- en regelgeving kunnen aanleiding zijn tot aanpassing van bestaande applicaties, door bijvoorbeeld toenemende rapportage-eisen ([Beug06]).

Schaalvergroting van een organisatie kan ertoe leiden dat de betalingsorganisatie centraal wordt georganiseerd, en eventueel wordt gecombineerd met een treasuryafdeling. De betalingsorganisatie heeft hierdoor een grotere omvang dan wanneer zij lokaal zou zijn georganiseerd. Dit geldt zowel voor de personele omvang als voor de hoeveelheid betalingen die worden verricht. Hierdoor ontstaan er additionele uitdagingen aan de technische instellingen van de betalingsapplicatie. Er dienen voldoende waarborgen te worden geïnstalleerd om functievermenging te voorkomen ([Piep99]). Autorisatiebeheer (functiescheiding en betalingslimieten) dient dan ook voldoende aandacht te krijgen.

Een ander gevolg van globalisatie is 24 × 7. In vergelijking met lokaal opererende bedrijven stellen internationaal georiënteerde organisaties andere eisen aan de beschikbaarheid van gegevens en toeleverende processen, zoals het aanleveren van koers- en valuta-informatie ([Beug06]). Daarnaast dient een betalingsapplicatie te kunnen voldoen aan de eisen van de organisatie, rekening houdend met verschillende valuta en het hierbijbehorende marktrisico (valutaschommelingen). Tevens dienen maatregelen te worden genomen ten aanzien van back-up- en disaster recovery-faciliteiten ([Beug06]). Door dit toenemende aantal eisen aan een applicatie bestaat het risico dat de betalingsapplicatie zeer complex wordt.

Niet alleen het pakket, ook de keuze van de leverancier is belangrijk ([Beug06]. De leverancier dient over voldoende kennis te beschikken van zowel de organisatie als van de markt waarin zij opereert.

Conclusie

Binnen het betalingsverkeer is betrouwbaarheid het belangrijkste kwaliteitsaspect. Betrouwbaarheid wordt hierbij opgedeeld naar integriteit, exclusiviteit, authenticiteit en controleerbaarheid ([Piep99]). Deze aspecten zijn op iedere betalingsorganisatie van toepassing, zowel lokaal als internationaal georiënteerd. De maatregelen die organisaties dienen te nemen om deze kwaliteitsaspecten te kunnen waarborgen, kunnen echter wel verschillen. Internationale organisaties zijn aan additionele risico’s blootgesteld en dienen hier ook voldoende aandacht aan te besteden. Echter, de belangrijkste maatregel om de betrouwbaarheid van het betalingsverkeer te kunnen garanderen is functiescheiding. Dit is van toepassing op zowel lokale als internationale organisaties.

Een voordeel van een grotere betalingsorganisatie is dat procedurele functiescheiding eenvoudiger te implementeren is (vierogenprincipe). Een kleine betalingsorganisatie kan uit enkele personen bestaan, waardoor organisatorische functiescheiding tussen invoer, fiattering en verzending van betalingen niet in alle gevallen eenvoudig is te implementeren. Echter, autorisatiebeheer is aanzienlijk complexer binnen een organisatie van grote omvang; hier dient dan ook voldoende aandacht aan te worden besteed.

Tijdens een audit van de betalingsorganisatie moeten de beschreven controlemaatregelen worden getoetst om de betrouwbaarheid en rechtmatigheid van de betalingen te kunnen vaststellen. Daarnaast wordt duidelijk dat, hoewel OfficeNet goede beveiligingsmogelijkheden biedt, een goede inrichting en naleving van het betalingsproces noodzakelijk is. Tevens dienen ook de general IT controls effectief te zijn. Bij batchbetalingen is het bovendien essentieel om de controles in en rondom de aanleverende systemen te toetsen. Het vierogenprincipe bij het wijzigen van crediteuren, periodieke controles op nieuwe en gewijzigde crediteuren, en autorisaties voor het blokkeren (en opheffen van blokkades) van crediteuren zijn hierbij van cruciaal belang om de juistheid, volledigheid en autorisatie van batchbetalingen te kunnen waarborgen.

Om de controlemaatregelen uit tabel 1 te kunnen toetsen is een werkprogramma opgezet. In dit werkprogramma worden per controlemaatregel de uit te voeren activiteiten beschreven. Onderdelen hiervan zijn bijvoorbeeld het opvragen van het contract met de bank, controle op speciale instellingen, etc. Dit werkprogramma kan een praktische handleiding vormen tijdens een audit naar de betalingsorganisatie waarbij gebruik wordt gemaakt van OfficeNet.

De auteur heeft een aanzet gegeven tot een overzicht van de maatregelen die kunnen worden geïmplementeerd om de risico’s tijdens het betalingsproces af te dekken. Het overzicht is echter niet uitputtend. Daarnaast zijn ook de specifieke instellingen van OfficeNet Extra van invloed op de aanwezige risico’s en de te nemen maatregelen. Voorbeelden hiervan zijn de keuze tussen een netwerk-pc of een stand-alone-pc, en de keuze tussen gedeeld datagebruik of individueel datagebruik. Bij installatie van OfficeNet is het dan ook van belang de verschillende instellingen aan te passen aan de specifieke bedrijfsbehoeften. Advies van een ABN AMRO-accountmanager is hierbij aan te bevelen.