Anbieter & Produkte: Eine kleine Übersicht

Ich beobachte die Tendenz, dass Softwarehersteller zunehmend auf den Begriff "Compliance" aufmerksam geworden sind. Aber leider nicht unbedingt so, dass Software jetzt generell mehr Compliance-Konform wäre, oder es mehr spezielle Compliance-Software gibt. Es wird vielmehr als Marketing-Label für bereits bestehende Software verwendet. In anderen Branchen kennt man "Sex sells" und für Unternehmenssoftware sollte also "Compliance sells" funktionieren.


Klar sind diese Marketing-Labels in der Regel keine Lüge - denn Compliance steckt fast überall irgendwie mit drin. Es macht es aber schwieriger denn je, die Begriffe Compliance und Software zu beschreiben und sinnvoll abzugrenzen.


Nachfolgend habe ich eine kleine Zusammenstellung von Anbieter und Produkten gemacht, welche Compliance-Software oder Produkte dazu anbieten. Dabei habe ich mich in der ersten Version auf eine klassische Kategorien-Definition beschränkt, respektive auf klassische Compliance-Themen. Ich werde die Übersicht von Zeit zu Zeit aktualisieren. Und wer weiss, kommen auch neue Kategorien und so ganz andere Anbieter und Produkte hinzu.


Vermissen Sie ein Anbieter oder ein/Ihr Produkt? Bitte nehmen Sie mit mir Kontakt auf.


Anbieter und Produkte:
Kategorie: Geldwäscherei & Terrorismusfinanzierung

• Eurospider Information Technology AG, CH-Zürich
• Produkt: KYC Matching CPM
• Beschreibung: Name-Matching-System mit Content um Kunden und Transaktionen gegen Listen, Datenbanken und andere frei zugängliche Quellen zu abzugleichen.
• Bemerkung: Mein Arbeitgeber, Software von mir Mit-Konzipiert, Client wurde von mir entwickelt.
• Link: Website Eurospider
• Link: Video Desktop-Version
• KYC Spider AG, CH-Zug
• Produkt: Content
• Beschreibung: Umfassender Content mit Sanktions- und Terroristenlisten, Wanted-Listen, PEP-Datenbanken, Medien und vielem mehr.
• Bemerkung: Content wird in KYC Matching CPM verwendet.
• Link: Website KYC Spider
• Innovations Software Technology GmbH, D-Immenstaad
• Produkt: MLDS
• Beschreibung: System um u.a. regelbasiert ungewöhnliche Transaktionen von Kunden zu erkennen.
• Bemerkungen: Keine.
• Link: Website Innovations

Kategorie: Identifikation & Echtheitsprüfungen

• IDENTT GmbH Verification Systems, D-Hamburg
• Produkt: IdenTT(r)
• Beschreibung: Online Referenz-Datenbank für Banknoten und Ausweisdokumente. Damit lassen sich Echtheitsprüfungen durchführen.
• Bemerkung: Keine.
• Link: Website IdenTT

Kategorie: Börsenrecht / Marktmissbrauch

• Innovations Software Technology GmbH, D-Immenstaad
• Produkt: MAID (Market Abuse/Insider Dealing Detection)
• Beschreibung: Software zur Erkennung von Marktmissbräuchen im Börsenhandel.
• Bemerkung: Keine.
• Link: Website Innovations

Kategorie: Corporate Governance, Ethik und Riskmanagement

• Avanon AG, CH-Zürich
• Produkt: Avanon GRC (Governance, Risk & Compliance)
• Beschreibung: Software mit verschiedenen Modulen, um verschiedene Aspekte von GRC zu überprüfen/überwachen, zu reporten und Massnahmen einzuleiten.
• Bemerkung: Keine.
• Link: Website Avanon

Kategorie: ECM & BCM

• SAPERION AG, D-Berlin
• Produkt: SAPERION
• Beschreibung: ECM & BCPM-Lösung
• Bemerkung: Keine.
• Link: Website SAPERION

Kategorie: E-Learning für Compliance-Themen / Anforderungen

• TATA Interactive Systems AG, CH-Zug
• Produkte: Geldwäschereibekämpfung, Informationssicherheit, Banking Confidential, Insurance Confidential, Code of Compliance
• Beschreibung: E-Learning-Software mit Testing mit verschiedenen Standard-Programmen (siehe Produkte). Können individuell angepasst werden.
• Bemerkung: Positive Erfahrung bei eigenen Evaluation, Einführung, Nutzung und Update der Lösung.
• Link: Website TATA Interactive

Markowitz trifft auf Compliance

Ich erhielt in der Vergangenheit hin und wieder verdeckt den Hinweis, dass meine Blog-Themen zwar sehr praxisnah sind, im Inhalt aber zuweit an der Oberfläche bleiben. Dem kann ich nichts entgegnen. Leider aber fehlt mir die Zeit, diese Beiträge mit tiefen Details zu bestücken, zumal diese nicht ohne weitere Abhandlungen und Erklärungen verständlich wären. Weiter stell ich mir die Frage, ob solch lange Beiträge von Ihnen überhaupt gelesen würden. So bleibt es vorerst bei Beiträgen, welche der Horizonterweiterung dienen und hoffentlich den einen oder anderen Gedankengang von Ihnen veranlassen wird. Bis auf diesen vorliegenden Beitrag. In diesem Beitrag möchte ich für einmal konkrete Beispiele und Antworten auf Fragestellungen liefern.

Die Portfoliotheorie im Überblick

Herr Henry M. Markowitz veröffentlichte im Jahr 1952 seine Portfoliotheorie als Dissertation. 1990 erhielt er dafür den Nobelpreis der Ökonomie. Die Portfoliotheorie von Markowitz gehört zur Kapitalmarkttheorie. Über den Inhalt und die Zielsetzung der Portfoliotheorie lassen sich zwei Kernaussagen machen: Durch gute Diversifikation lässt sich das unsystematische Risiko gegen null reduzieren. Entsprechend geht man nur noch das systematische Risiko ein. Ein Ziel ist demnach die Risikodiversifikation. Während sich das Titelrisiko nicht linear zum Portfoliorisiko verhält, hat die Titelrendite eine lineare Beziehung zur Portfoliorendite. Ein weiteres Ziel ist demach die Nutzenoptimierung. Zwischen diesen beiden Zielen gibt es natürlich auch Grenzen, wo es zu einem Zielkonflickt kommt: Nur mit dem Marktrisiko lässt ich längerfristig keine höhere Rendite als die des Marktes realisieren. Es gibt drei relevante mathematische Kenngrössen: Portfoliorisiko (w^T*Ω*w), Portfoliorendite (w^T*μ) und die Anlegerpräferenz (meist als mathematische Funktion).

Compliance-Themen bei der praktischen Umsetzung

Will man die Portfoliotheorie als Bank in der Praxis umsetzen und bspw. als Produkt den Kunden anbieten, so müssen ein paar wichtige Anfordrungen/Restriktionen beachtet und eingehalten werden. Die Portfoliotheorie kann man als Bank sinnvollerweise nur im Rahmen eines Vermögensverwaltungsauftrages (VVA) umsetzen.

FINMA-RS, Eckwerte zur Vermögensverwaltung

• Nicht wirtschaftliche Umschichtungen (sog. Churning) sind zu unterlassen.
• Der Vermögensverwalter stellt sicher, dass Anlagen dauernd mit den Anlagezielen und -beschränkungen übereinstimmen.
• u.v.m.

Richtlinie für Vermögensverwaltungsaufträge der SBVg

• Es braucht eine profesionelle Organisation (u.a. Gewaltentrennug).
• Die Bank vermeidet Klumpenrisiken in den VAA durch ausreichende Diversifikation.
• Aufgrund eines VVA dürfen keine Kredite aufgenommen oder potentielle Soll-Positionen eingegangen werden.

FINMA-RS, Operationelle Risiken Banken, Anhang 1, Qualitative Grundanforderungen

Dort steht im Abs. 4: „Banken müssen die operationellen Risiken aus all ihren Aktivitäten, Produkten, Prozessen und Systemen identifizieren und beurteilen können. Vor einer Veränderung der Struktur von Aktivitäten, Produkten, Prozessen und Systemen sind diese mit Blick auf ihre operationellen Risiken adäquat zu beurteilen.“ Die nachfolgende Abbildung enthält einen möglichen Risikokataster nach den Kategorien von Anhang 2 des besagten Rundschreibens. In der letzten Spalte stehen Beispiele und Bemerkungen in Bezug auf die Umsetzung der Portfoliotheorie als VVA (zum Vergrössern anklicken):

IT-Archivierung: Mission erfüllt?

Quelle: Wikipedia

In diesem Blog-Beitrag verwende ich absichtlich den Begriff IT-Archivierung und nicht etwa elektronische Archivierung. Es geht mir nämlich um sämtliche Aspekte der Archivierung was die IT betrifft – und da geht es auch um physische Archivierung. Deshalb gefällt mir persönlich der Begriff elektronische Archivierung nicht besonders gut. Als erstes möchte ich kurz eine Übersicht geben, welche Objekte potentiell archiviert werden müssen. Dabei habe ich keinen Anspruch auf Vollständigkeit der Liste:

Entstehung in der IT ...
Anwendungsdaten (aus funktionalen Anforderungen)
System-/technische Daten (aus nicht funktionalen Anforderungen)
Software (ausführbarer Code inkl. benötigte Ressourcen)

Entstehung ausserhalb der IT, Archivierung mittels IT ...
Geschäftskorrespondenz
Geschäftsabschlüsse
Verträge

Hardware zum späteren Anzeigen ...
Rechner (Server/PC)
Anzeige- und Bedienperipherie (Tastatur, Maus, Bildschirm u.a.)
Laufwerke (CD-ROM, Festplatten etc.)


Herausforderungen im Detail

Anwendungsdaten
Anwendungsdaten können sehr vielseitig sein. Typische (Schul-) Beispiele sind etwa Kunde (Name, Vorname, Geburtsdatum etc.), Kundenadressen, Bestellungen, Rechnungen und Artikel etc. Oftmals werden solche Daten in Datenbanken gespeichert und die optimale Archivierung von Daten in Datenbanken ist alles andere als einfach. Welche Daten müssen per wann archiviert werden? Und vor allem, wie kann man diese später wieder in einem sinnvollen Kontext anzeigen? Projekte zur gesetzes konfromen Archivierung von Anwendungsdaten (insbesondere in Datenbanken) sind aufwändig in der Planung und sollten nicht unterschätzt werden. Vor allem Aspekte wie das Suchen und Wiederfinden sowie anzeigen von solchen Daten sind anspruchsvoll in der Umsetzung. Vor allem dann, wenn man aus Gründen des Datenvolumens nicht immer die ganze Datenbank archivieren kann oder auch wichtig aus Sicht Compliance, nicht die ganze Datenbanken archivieren darf.

System-/technische Daten
Zu diesen Daten zählen Informationen aus Log-Einträgen, Informationen zur Verfügbarkeit, Informationen zu Verbindungen (Protokolle etc.) sowie zur Security (Benutzeranmeldungen, Benutzen von Objekten etc.). Für diese Kategorie gibt es zwei Herausforderungen: 1) Identifikation der Daten, welche eine Software (ein Software-System) überhaupt speichert und 2) Automatische Erschliessung von allen relevanten Daten. Aber auch hier ist der Aspekt der späteren Lesbarkeit in sinnvollem Kontext nicht selten eine Herausforderung.

Software
Zu dieser Kategorie von Informationen die potenziell archiviert werden müssen, zählen zum einen die Software, welche Daten erstellt, erstellt hat und zum anderen Software, mit welche die archivierte Software wieder in sinnvollem Kontext angezeigt werden kann. Das kann dieselbe sein wie die Daten erstellende, es kann aber auch eine Software eigens für diesen Zweck sein. Die Herausforderung besteht darin, dass man eine Lauffähige Umgebung mit allen Ressourcen archiviert. Nur einfach die Installations-CD in ein Archivregal stellen reicht nicht. Zum einen hat man die Software nach der Installation parametrisiert und zum anderen braucht man auch ein Betriebssystem, um diese laufen zu lassen. Auch dieses muss archiviert sein, damit die Software Jahre später auch noch ausgeführt werden kann.

Entstehung ausserhalb der IT
Hier sind es vorwiegend digitalisierte Informationen (bspw. mittels Scanner) wie Briefe, Rechnungen, Unterzeichnete Geschäftsabschlüsse, Unterzeichnete Berichte und Meldungen etc. Die Herausforderung sind hier aus meiner Erfahrung am kleinsten und es gibt am meisten Standardlösungen für solche Aufgaben. Es werden einzelne Objekte (meist Dateien) mit ID in einem Format wie PDF/A oder Tiff erstellt. Diese werden zusammen mit einem Index mit Metadaten in einer Archvierungslösung archiviert.

Hardware
Hier geht es darum, dass jene Hardware archiviert wird, welche zum späteren Anzeigen von archivierten Daten gebraucht wird. Die Herausforderungen besteht hier vor allem im Konzept, wann welche Hardware separat funktionsfähig beiseite gestellt (archiviert) werden muss. Es braucht natürlich nicht für jede Anwendung einen eigenen Server im Archiv. Sobald es aber einen Medienbruch gibt,oder andere Einflussfaktoren ändern, muss für die Legacy-Archive entsprechend Hardware „archiviert „ werden, damit die Daten eben auch Jahre später noch gelesen werden können.


Qualitätskontrollen / Lesetests
 
Es ist unerlässlich, dass in bestimmten zeitlichen Abständen getestet wird, ob definierte archivierte Objekte mit den archivierten Ressourcen noch gelesen werden können.


Geeignete Medien / Infrastruktur
 
Es sind längst nicht alle Speichermedien geeignet oder zulässig zum Archivieren von elektronischen Daten. Billige CD-R beispielsweise sind mit weniger als 10 Jahren nicht mehr (zuverlässig) lesbar. Nebst einmal beschreibbaren optischen Datenträgern (zum Beispiel CD-R) kommen zur konformen Archivierung vor allem WORM (True-/Soft- und Hardware WORM) zum Einsatz. Diese sind jedoch relativ kostspielig und ein gutes Archivierungskonzept zur Reduktion der Datenmenge lohnt sich nach wie vor (auch aus anderen Gründen als den Speicherkosten).


Erfahrungen und Konklusion
 
Meine Erfahrung aus verschiedenen Projekten zeigt, dass die Mission IT-Archivierung alles andere als erfüllt ist. Am besten umgesetzt sind elektronische Archivsysteme, welche meist externe Dokumente als zuweisbare Objekte archivieren. Grosse Lücken gibt es hingegen, bei den meisten anderen Arten von Informationen. Beispielsweise alte Adressen. Häufig sind diese noch im produktiven System, aber eben nicht korrekt archiviert. Noch grösser ist meines Erachtens die Lücke beim Archivieren von verwendeter Software, respektive Software, mit welcher Archivierte Informationen angezeigt werden kann. Ebenfalls dazu gehört die ganze Hardware, damit die Software und somit die Daten später verwendet werden können. Die ganze Datenaufbewahrung, zu welcher auch die Datenarchivierung gehört, ist organisatorisch ein Problem, welches in vielen Unternehmungen noch nicht genügend gelöst worden ist. Es versteht sich von selbst, dass ich hier kein Menetekel an die Wand schreiben will. Dennoch darf das Risiko nicht unterschätzt werden. Ich empfehle auf jeden Fall, diese Risikokategorie im Rahmen von ORM auf dem Radar zu behalten und allenfalls geeignete Massnahmen einzuleiten. Sonst läuft man Gefahr, dass Unternehmensdaten  verloren gehen.

Wie sieht das Archivierungskonzept für Anwendungsdaten und Software bei Ihnen aus? Wann führen Sie Lesetests aus? Dies sind Fragen, welche auch Compliance interessieren müssen.

Im Code liegt Wahrheit: Software(test)-Anforderungen & Testmöglichkeiten

Was ist ein Software-Test?
Es gibt verschiedene Definitionen davon, was ein Softwaretest ist. Ich persönlich finde jene von Denert gut, bei der ein Test der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen ist. Insbesondere der letzte Teil „[...] zu vorher festgelegten Anforderungen“ ist aus meiner Sicht existenziell wichtig und entscheidend. Ein Softwaretest ohne genaue Softwarespezifikation ist demnach nicht möglich.

Anforderungen von verschiedenen Anforderungsgruppen

Es gibt ganz verschiedene Anforderungen von unterschiedlichen Anforderungsgruppen. Ich unterteile die Anforderungsgruppen in vier Hauptgruppen: Business, Technik, IT-Compliance und Fach-Compliance. Klar, jemand der nicht in Compliance-Abteilungen arbeitet oder gearbeitet hat, würde wahrscheinlich IT-Compliance und Fach-Compliance einfach unter dem Begriff „Compliance“ führen. Ich erlaube mir aber, diese zu trennen.

Business
Hier geht es um die spezifischen Anforderungen des Fachbereichs. Die meisten können mit der Frage, welche Funktionen eine Software haben muss, gruppiert werden.

Technik
Wie der Begriff sagt, geht es hier um technische Anforderungen. Beispiele sind: Plattformen, Protokolle, technische Standards, Deployment, Wartbarkeit etc.

IT-Compliance
Hier stehen häufig die gleichen Standardanforderungen im Raum: Sicherstellung von Vertraulichkeit, Verfügbarkeit, Integrität, Datenaufbewahrung und Datenschutz.

Fach-Compliance
Hier geht es um Compliance-Anforderungen, welche das spezifische Business betreffen. Wird beispielsweise eine Software für den Börsenhandel entwickelt, sind es spezifische regulatorische Anforderungen aus dem Börsenrecht (u.a.).

Testarten und -möglichkeiten

Für möglichst alle Anforderungen sollten spezielle Tests durchgeführt werden. Dazu gibt es unterschiedliche Ansätze und Methoden. Diese kann man je nach Gesichtspunkt in verschiedene Gruppen einteilen:

Nach Testkriterium: Funktionale Tests, Stresstests, Lasttest, Schnittstellentests, Sicherheitstests, GUI-Tests etc.

Nach Informationsstand: Blackbox-Tests, White-Box-Tests (auch Code-Reviews genannt)

Nach Test-Technik: Statische und dynamische Tests.

Sobald eine Software durch einen Kunden oder gar Dritten getestet und abgenommen wird, werden in der Regel Blackbox-Tests gemacht. Das heisst, dass die Tests damit gemacht werden, dass die Software gebraucht wird. Entweder fährt das Auto, oder es fährt nicht. Weshalb es genau fährt, bleibt dem Tester vorenthalten.

Wer muss Software testen? Welche Software muss man testen?
Diese Frage ist so allgemein nicht zu beantworten. Sicher gilt für Finanzintermediäre, dass sie jene Software testen müssen, welche sie für das Kerngeschäft einsetzen. Irgend eine Software für Marketingkampagnen muss nicht, oder nicht im gleichen Umfang wie beispielsweise eine E-Banking-Software, getestet werden. Eine Firma muss im IT-Reglement oder der IT-Weisung definieren, welche Software getestet werden muss und wie. Wer in einer Firma Softwaretests definiert und durchführt, hängt von der Software und den durchzuführenden Tests ab. Meist braucht es dazu Mitarbeiter aus mehreren Abteilungen (Fachbereich, Compliance und IT).

Erfahrungen und Konklusion
Nach meinen Erfahrungen ist es sehr schwierig, gute Softwaretests zu beschreiben, welche tatsächlich dafür nützlich sind, die Umsetzung der gemachten oder geforderten Anforderungen zu prüfen. Meist werden zudem nur Anforderungen aus dem Bereich Business geprüft. Es liegt aber nicht nur an den Test-Verantwortlichen, dass Software häufig nicht ausreichend und nicht effizient geprüft wird. Es liegt auch daran, dass mit Blackbox-Tests allein einfach zu wenig gut geprüft werden kann: Im Code liegt Wahrheit. Hat eine Software beispielsweise interne Limiten (die von verwendeten Datenstrukturen herrühren) ab einem bestimmten Datenvolumen, so bräuchte es schon ein Lasttest, um dies zu merken. Oder ein bestimmter Datenwert führt zu einem Fehler. Ist es da nicht Zufall, wenn Sie Tests haben, welche diese Datenwerte brauchen? Oder die Software macht Fehler, wenn parallel mehrere Benutzer gleichzeitig auf ein Objekt zugreifen wollen? Führen Sie die Tests wirklich so durch, dass Sie dies merken würden? Oder die Software führt gewisse Log-Aufträge nicht aus, wenn man sich mit einem bestimmten Benutzer anmeldet? Prüfen Sie wirklich mit allen möglichen  Benutzern alle Testfälle? Die Liste könnte beliebig erweitert werden. Es gibt so viele mögliche Fehler, die mit Blackbox-Tests in der Praxis fast nicht zu erkennen sind und schon gar nicht mit wirtschaftlich vernünftigem Aufwand. Meine Meinung ist deshalb klar: Bei Geschäftskritischer Software braucht es vermehrt Code-Reviews. Der Source-Code wird angeschaut und geprüft. Diese Code-Reviews ersetzen dabei auf keinen Fall die üblichen Anwendungstests, welche in Form von Blackbox-Tests durchgeführt werden, sondern ergänzen diese. Denn auch der Aufwand von Code-Reviews darf nicht unterschätzt werden – solche Reviews müssen von Personen mit entsprechenden Know-how gemacht werden, was mit entsprechenden Kosten verbunden ist.

Sicherlich ist diese Forderung für die meisten Softwarefirmen nicht opportun. Denn niemand, der Software unter einer proprietären Lizenz verkauft, will seinen Software-Code, oder Teile davon, zwecks Review einem Kunden offen legen. Aber genau das wäre aus meiner Sicht ein wirkungsvolles Mittel, um die Softwarequalität zu erhöhen. Dabei soll Softwarequalität an dieser Stelle vor allem als konnotierter Begriff im Anforderungskontext verstanden werden.

Aber nicht nur die Softwarehersteller sind gefordert. Auch die Kunden und insbesondere die Compliance Officer sind hier gefordert. Und zwar gleich doppelt:

1. Müssen sie sich aktiv in den Prozess der Softwarespezifikation einbringen. Denn wie Eingangs geschrieben, braucht es für einen Softwaretest eine Anforderung und diese muss gestellt werden.
2. Die Compliance Officer müssen aktiv dafür sorgen, dass ihre gestellten Anforderungen mit einem geeigneten Testverfahren auch geprüft werden.

Für einige Leser mag mein Wunsch zum Schluss vielleicht schon fast wie ein Mantra klingen. Aber Mantras haben bekanntlich eine positive Wirkung auf den Geist. Hier ist er: Es wäre wünschenswert, wenn Compliance vermehrt am gesamten Entwicklungsprozess von Software beteiligt wäre – denn nur so kann sichergestellt werden, dass neue Software Compliance konform umgesetzt wird.

Das Compliance-IT-Synergien-Paradoxon

Ich bin mir bewusst, dass dieser Beitrag in gewissem Masse als Widerspruch zu meinem ersten Beitrag empfunden werden kann. Aber es ist so, dass der erste Beitrag die Theorie, so wie es sein sollte, wiedergibt. Und in diesem vorliegenden Text widme ich mich Erfahrungen aus der Praxis.

Feststellung
Wo es theoretisch zwischen Compliance und der IT starke Synergien gibt, stellen sich diese in der Praxis doch nicht selten als Paradoxa heraus. Irgendwie wird da bei Projekten nicht immer alles so ganzheitlich und adäquat betrachtet. Doch alles der Reihe nach.

Von IT-Security zu IT-Compliance
Der Begriff IT-Compliance ist ein eher jüngerer Begriff und so scheint mir, im Deutschsprachigen Raum mehr vertreten zu sein als im Englischen. So gibt auf Deutsch mehr Treffer bei Google und bei Wikipedia gibt es im Englischen dafür (noch) keine eigene Seite. Auf der Deutschsprachigen schon. IT-Security ist hingegen ein „gestandener“ Begriff und umfasst im Wesentlichen die Attribute: Sicherstellung von Vertraulichkeit, Verfügbarkeit und Integrität. IT-Security war für die IT schon immer ein zentrales Element. Und aus dieser IT-Security wuchs auch mein Verdacht, dass es da Synergien zur rein fachlichen Compliance gibt. IT-Security ist eine Untermenge von IT-Compliance. Vereinfacht gesagt ist IT-Compliance IT-Security, erweitert um die Aspekte:  Datenaufbewahrungsrichtlinien und Datenschutz, gemeint nach Datenschutzgesetz DSG. Während in der IT-Security der Administrator noch weitgehend alles machen kann, geht dies bei IT-Compliance nicht mehr, da es Datenschutzgesetze gibt, die auch für den Administrator ihre Gültigkeit haben. Soweit zu den Begriffen.

Fach- oder Business-Compliance versus IT-Compliance?
Als Fach- oder Business-Compliance verstehe ich die klassische Compliance, wo es um die Regulatorien geht, welche das Business selber betreffen. Bei Banken sind dies Themen wie Geldwäscherei und Sorgfaltspflicht, Börsenrecht (Meldepflichten, Insiderhandel, Marktmanipulation u.a.), Vertragsrecht, Risikokontrolle etc. etc.

Meine These, dass die Synergie zwischen Fach- und IT-Compliance in der Praxis ein Paradoxon ist, kommt von der Feststellung, dass gerade auch bei der technischen Umsetzung von Anforderungen aus der Fach-Compliance, Grundsätze und Regeln der IT-Compliance, genauer der IT-Security, übersehen, ignoriert oder missachtet werden.

Lieber eine einfache Reportingschnittstelle für ein Management-Reproting-Tool, ohne Authentifizierung und Autorisierung, als eine optimale Datensicherheit und Gewährleistung der Integrität.

Fallbeispiel 1: Verbesserte Risikoaufklärung zu Lasten der Datensicherheit
Die Risikoaufklärung der Kunden soll im Zuge der negativen Erfahrungen aus der jüngsten Finanzkrise verbessert werden. Insbesondere bei der Beratung ausserhalb der Bank, soll diese verbessert werden. Dazu werden die betroffenen  Kundenberater mit neuen mobilen Geräten mit grossem Display ausgestattet. Über diese (unsicheren) Geräte haben diese Mitarbeiter nun die Möglichkeit, interne Dokumente und Informationen über Finanzprodukte zu beziehen und dem Kunden zu präsentieren. Dieser kann auch gleich sein Einverständnis „schriftlich“ über diese mobilen Geräte geben. Aus Sicht Fach-Compliance ist diese Umsetzung zu begrüssen, wird der Kunde doch besser und vor allem aktueller über Risiken informiert und gibt auch gleich schriftlich zu Protokoll, dass er darüber aufgeklärt worden ist. Leider aber sind gerade solche mobile Geräte alles andere als sicher. Sowohl für den Kunden wie auch für die Bank treten durch diese Umsetzung neue operationelle Risiken (ORM) auf. Kein IT-Security-Officer würde wohl sein Wort geben, dass diese Lösung als sicher und ohne Risiken einzustufen ist.

Fallbeispiel 2: Verbesserte Datenqualität zu Lasten der Datenintegrität
Ein neuer Fach-Compliance-Prozess soll die Datenqualität von Kundeneingaben erhöhen. Adressänderungen und Versandinstruktionen, welche über das E-Banking vom Kunden erfasst werden, sollen nicht mehr mit einem STP-Prozess (Straight Through Processing) direkt ins System übernommen werden, sondern vorerst von einem Mitarbeiter geprüft und allenfalls korrigiert werden. Dieser Schritt kann richtig implementiert durchaus sinnvoll sein. Wird die Eingabe des  Kunden als solche aber nicht unverändert ins System übernommen und die Änderung eines Mitarbeiters als Änderung eingetragen, so ist die Datenintegrität nicht mehr gewährleistet, wenn aus dem System der Eindruck entsteht, der Kunde habe die Adresse oder Versandinstruktionen so erfasst. Was nach einer Änderungen durch einen Mitarbeiter nicht mehr der Fall ist.

Lösungsansätze
Um diesem Paradoxon zu entgehen, braucht es auf verschiedenen Stufen Mitarbeiter die mitdenken und Compliance ganzheitlich betrachten. Eine ungenügende IT-Security schlägt früher oder später zurück. Fach-Compliance-Anforderungen müssen im Einklang mit IT-Compliance umgesetzt werden. Eine Bevorzugung von Fach-Compliance gegenüber IT-Compliance kann verheerend sein. Umgekehrt ist es natürlich auch an den IT-Verantwortlichen, nicht alle fachlichen Anforderungen unter dem Mantel von IT-Security zu blockieren. Nur mit gegenseitigem Respekt und Beachtung lassen sich die theoretischen Synergien erreichen.

In diesem Spannungsfeld kann ein weit- und umsichtiger Compliance Officer eine wichtige Rolle einnehmen und zu ganzheitlich korrekt umgesetzten Lösungen beitragen.

Erneuerungen

An dieser Stelle möchte ich mich für die zahlreichen Kenntnisnahmen und Rückmeldungen zu diesem Blog bedanken. Auf Grund von Anregungen gibt es bereits drei Verbesserungen:


1) Neu gibt es auf der rechten Seite eine Vorschau auf den nächsten Blog-Beitrag mit Titel und dem voraussichtlichen Publikationstermin.


2) Ebenfalls neu auf der rechten Seite gibt es eine einfache Möglichkeit, dem Blog zu folgen (Abonnieren von).


3) Ab sofort gibt es keine Werbung mehr zwischen den einzelnen Blog-Beiträgen.


Beste Grüsse,
Ronny Fuchs

Wie gut eignen sich Excel & Co. aus Sicht Compliance für Unternehmen?

Unter „Excel & Co.„ sind in diesem Artikel Programme gemeint, welche sehr unspezifisch entwickelt worden sind und daher über fast alle Branchen hinweg für eine Vielzahl von Aufgaben gebraucht werden können. Die bekannteste Vertreterin dieser Softwaregattung dürfte Excel sein. Aber auch Access und die Pendans von anderen Office-Suiten wie OpenOffice.org gehören dazu.

Die meisten Unternehmen haben irgend eine Branchenlösung im Einsatz, mit welcher ein grösserer oder kleinerer Teil der Aufgaben aus dem Kerngeschäft erledigt werden kann. Nebenbei gibt es meist zahlreiche Um- und Nebensysteme. Und nicht selten kommen von konstruktiven Mitarbeitern einige „Lösungen“ von Excel & Co. dazu. Excel-Sheets für das, eine kleine Lotus-Datenbank für jenes, ein Makro da und eines dort. Alles, um die Arbeit effizienter zu machen und die Fehlerquellen aus manuellen Eingaben und Berechnungen zu reduzieren.

In diesem Artikel möchte ich der Frage nach gehen, wie gut geeignet denn solche Programme sind, um solche kleinere oder grössere Aufgaben in Unternehmensprozessen auszuführen. Und dies nicht unter dem Aspekt der direkten Funktionen, sondern unter dem Aspekt von allgemeinen Compliance-Anforderungen an eine Software, welche in Unternehmensprozessen (oder Teilen davon) eingesetzt wird.

Es gibt sehr viele mögliche Sichten, bei der Betrachtung von Anforderungen an eine Software und auch viele und unterschiedliche nationale und internationale Gesetzte, Verordnungen und Standards  dazu. Eine Auslegung von diesen und eine Betrachtung von Sinn und Unsinn von diesen wäre an dieser Stelle wünschenswert – es würde aber den Rahmen in der zeitlichen und räumlichen Dimension sprengen. Und deshalb messen wir Excel & Co. an dieser Stelle an der Maxime des CAVR-Frameworks. CAVR ist die Abkürzung für Completeness, Accuracy, Validity und Restricted access. Ganz allgemein geht es um den Schutz und die Gewährleistung der Nachvollziehbarkeit. Untersuchen wir nun Excel & Co. mit ein paar Fragen dazu.

Zugriffsbeschränkung und Protokollierung
Bieten diese Programm eine Authentisierung mit genügendem Zugriffsschutz und einer Protokollierung der wichtigen Aktivitäten? Mit Hilfe des Betriebs- resp. Filesystems lassen sich Zugriffsbeschränkung meist realisieren. Eine andere Frage ist, ob dies in der Praxis auch genügend stark durch- und umgesetzt wird. Mit der Protokollierung sieht es aber meist schlecht aus. Eine solche gibt es bei den betroffenen Systemen nicht von Haus aus. Es lässt sich somit nicht nachvollziehen, wer der möglichen Mitarbeitern wann das Excel-Sheet angepasst hat, oder wer eine Funktion zuletzt ausgeführt hat (Letzter File-Zugriff vom Filesystem ist nicht zwingend letzter Makro-Funktionsaufruf etc.). Der Modus zur Änderungsnachverfolgung solcher Produkte ist in der Praxis meist nicht geeignet – solche Funktionen wurden auch zu anderen Zwecken entwickelt (bspw. sind die Makros nicht enthalten).

Vollständigkeit
Ob die Daten vollständig (alle Daten) sind oder dass alle notwendigen Prüfungen/Checks in diesem Schritt gemacht werden, die gemacht werden müssen – dafür kann das entsprechende Programm nichts. Die Frage ist hier viel mehr, ob die Mitarbeiter, welche solche Anwendungen definieren, in jedem Fall wissen was sie tun und was alles zur Vollständigkeit gehört. Hier ist eher der Mitarbeiter das Risiko, als die Software das Problem. Und das Risiko sollte auf keinen Fall unterschätzt werden. Folglich auch nächster Punkt.

Richtigkeit
Werden die Berechnungen richtig gemacht? Wird die richtige Formel mit den richtigen Konstanten verwendet? Auch hier liegt das Problem eigentlich nicht bei den Programmen selber. Aber dennoch bieten sie von Haus aus keine global steuerbaren Prozesse für die Freigabe von Definitionen. Und nur durch Ansätze wie ein Vier-Augenprinzip kann dieses Risiko reduziert werden. Insofern unterstützen diese Programme die Definitionen nicht und werden eher zum Risiko für ein Unternehmen.

Gültigkeit/Zulässigkeit
Wurde eine Transaktion, die durchgeführt wird, überhaupt bewilligt? Wurde eine Limite überschritten? Darf ein Mitarbeiter diesen Schritt für dieses Produkt ausführen? Darf diese Transaktion für jenen Kunden ausgeführt werden? Von Haus aus gibt es bei Excel & Co. keine Unterstützung für solche Prüfungen. Zumal auch die Datenanbindung nicht immer einfach ist. Entsprechend fehlt diese Komponente bei den meisten Anwendungen von Excel & Co.

Konklusion
Excel & Co. sind in vielen Branchen in vielen Unternehmen nicht mehr wegzudenken. Sie leisten häufig einen nicht zu unterschätzenden Beitrag zu den Prozessen – nicht zuletzt auch in sensiblen Bereichen wie Reporting und Risikomanagement. Aber aus Sicht Compliance sind solche selber entwickelten Anwendungen von Excel & Co. ein operationelles Risiko (Stichwort: ORM). Sie genügen einer internen Kontrolle in den meisten Fällen nicht. Wer wann was wie berechnet und vervollständigt oder überwacht, ist nicht sicher von Haus aus nachvollziehbar. Ein ebenfalls grosses Problem von Excel & Co. ist deren dezentrale Haltung. Zentral verlässliche Verzeichnisse/Inventare mit den wichtigsten Metadaten gibt es es meist nicht. Eine genauere Risikoeinschätzung dürfte deshalb in konkreten Fällen ein nicht leichtes Unterfangen sein.

Anonymes Surfen als Pflicht?

Das Research-Projekt Panoptclick der Electronic Frontier Foundation (EFF), eine Cyberspace-Bürgerrechtsorganisation aus den USA, brachte zu Tage, dass 8 von 10 Browsern eindeutig identifiziert werden können (84 %). Bei Browsern mit Flash und JavaScript waren es gar deren 94 %. Im angelegten Research-Projekt standen 470.000 Datensätze zur Auswertung zur Verfügung.

Das bedeutet, dass fast jeder Browser wiedererkannt werden kann. Dadurch lassen sich gesammelte Daten einem Browser-Profil zuordnen. Mit aktivem JavaScript ist es nach wie vor möglich in Erfahrung zu bringen, ob jemand schon einmal auf einer bestimmten Seite war oder nicht. Um eine Zuordnung zu einer bestimmten Firma machen zu können, reicht es demnach aus, beispielsweise die Adresse der Intranetseite dieser Firma zu kennen. Insbesondere Suchanfragen wie bei Google sind gefährlich, da Google die Suchparameter an die Seiten weitergibt, welche der Benutzer in der Resultatenliste anklickt. So kann festgestellt werden, dass eine Firma A, die Firma oder Person B gesucht hat.

Es ist in der heutigen Zeit praktisch unumgänglich, dass sich Firmen über bestehende oder potentielle Kunden Informationen im Internet beschaffen. Wie war die Telefonnummer? Was haben sie für Produkte? Dann braucht es noch den Handelsregisterauszug etc.

Insbesondere für Personen und Unternehmen, welche einem spezielles Berufsgeheimnis unterliegen (Banken, Rechtsanwälte u.a.), stellt sich die Frage, ob es aus der Sicht von Compliance erforderlich ist, dass solche Firmen im Internet anonym Informationen beschaffen können.

Technisch ist dies ein gar nicht so leichtes Unterfangen. Die wahre Herkunft auf der IP-Ebene zu verstecken ist das eine. Ein ganz anderes Problem ist die Gesprächsbereitschaft der meisten Browser und die Risiken, welche von Browser-PlugIns und JavaScript ausgehen. Dazu kommen Fragen wie Performance-Einbussen, Netzlast und vor allem die Kosten für ein solches Projekt und den späteren Betrieb. Bei den technischen Möglichkeiten gibt es verschiedene Stufen der Anonymität – mit unterschiedlichen Kosten und Auswirkungen auf den Betrieb.

Grundsätzlich dürfen Angaben über Personen nicht an Dritte weitergegeben werden, wenn die Person dies nicht erlaubt hat und es sich nicht explizit aus einem Auftrag ergibt, dass diese Informationen Zwecks ordentlicher Ausführung an diesen Dritten weitergegeben werden müssen. Gewisse Berufsgruppen wie die die Banker, haben noch viel strengere Auflagen – dürfen diese nicht einmal preisgeben, dass jemand Kunde ist.

Fazit:
Damit dem gesetzlichen Schutz der Kunden durch die Nutzung von Internet in Firmen genügend Rechnung getragen wird, braucht es im Umgang mit dem Internet interne Richtlinien. Diese sollen festlegen, welche Informationen über Kunden wie und wo im Internet preisgegeben werden dürfen und welche nicht. Für Unternehmen mit Berufsgeheimnis und hohem Informationsbedarf wie Banken, stellt sich aber die Frage, ob dies organisatorisch überhaupt sinnvoll und sicher umgesetzt werden kann. Hier habe ich ein wenig meine Zweifel und vertrete die Meinung, dass solche Berufsgruppen aus Sicht Compliance technisch mehr für den Kundenschutz im Internet durch eigene Recherchen tun müssten.

Name-Matching-Systeme für Compliance-Anforderungen

Eine Hauptaufgabe von Compliance-Officern bei Finanzintermediären ist die Umsetzung und Kontrolle von Massnahmen zur Bekämpfung der Geldwäscherei und Terrorismusfinanzierung. Dazu gehört es unter anderem zu prüfen, ob (potenzielle) Kunden als politisch exponierte Personen, sogenannte PEP, bekannt sind, ob es sich um einen Terroristen, eine terroristische Organisation oder um ein Mitglieder einer solchen handelt, oder ob es Sanktionen gegen diesen (potenziellen) Kunden gibt. Und dies sowohl bei, respektive vor, der Eröffnung einer Kundenbeziehung wie auch während der Dauer der Kundenbeziehung.

Diese drei Prüfungen lassen sich nur mit externen Daten realisieren. Dazu ist es praktisch unumgänglich, dass ein Finanzintermediär dazu Software verwendet, welche


a) die externen Daten laufend aktualisiert;
b) den Abgleich der Kundendaten mit den externen Daten vornimmt;
c) bei der Dokumentation so unterstützt, dass der ganze Abarbeitungsprozess compliance konform ist.

Um solche Lösungen zu entwickeln und zu betreiben braucht es interdisziplinäre Kompetenzen. Ich habe im Mai 2010 zusammen mit Peter Schäuble ein umfassendes Sachbuch zu diesem Thema veröffentlicht. Es dient interessierten Kreisen wie Compliance Officer, CEO, System-Betreiber und Revisoren als leichter Einstieg in die komplexe Thematik.


Hier finden Sie eine Medienmitteilung:
http://www.openpr.de/news/430511/Eurospider-publiziert-neues-Sachbuch-ueber-Name-Matching-Systeme-bei-Banken.html

Und hier eine unabhängige Buchrezension:
http://www.bankingclub.de/news/Name-Matching-Systeme/

 
Das Buch trägt den Titel "Name-Matching-Systeme: Im Einsatz gegen Geldwäscherei und Terrorismusfinanzierung".


Es ist unter der ISBN: 978-3-8391-1641-8  im Handel erhältlich.

Start!

Compliance und IT wird meiner Erfahrung nach in der Praxis oft zu stark getrennt behandelt. Dies ist nicht zu letzt deshalb oftmals so, weil Compliance-Verantwortliche mehrheitlich aus dem juristischen Ecken kommen, während IT-Verantwortliche und Softwareentwickler häufig "nur" einen technischen Hintergrund haben. Aber beide Aspekte haben doch einige Gemeinsamkeiten und können viel voneinander profitieren. In diesem Blog möchte ich deshalb meine Meinung und Erfahrung zum Zusammenspiel dieser beiden Disziplinen publizieren.