Quelle: FATF

Die von der FATF genannten Typologien und Sachverhalte können zum überwiegenden Teil auch als Regeln in Research-Systemen zur Untersuchung von Transaktionen implementiert werden. Sie können zu Auffälligkeiten in den Systemen führen, die durch die Verpflichteten analysiert werden müssen. Gleichwohl erscheint es sinnvoll, sich mit den Typologien und Fallstudien intensiver auseinanderzusetzen, um eine adäquate Risikostrategie zu implementieren.

So gibt es nicht nur im Zusammenhang mit Hawala, sondern auch im Zusammenhang mit der Finanzierung des Terrorismus die Empfehlung, sogenannte „Money Collection Accounts“ zu prüfen. Gleiches gilt für den Sachverhalt „many to one“, bei dem viele verschiedene Parteien Gelder an einen Empfänger versenden. Die Beträge werden danach unmittelbar ins Ausland überwiesen beziehungsweise an Geldautomaten verfügt.

Bei der Analyse solcher Typologien kann man schnell zu der Erkenntnis kommen, dass Hawala-Banking ein Phänomen ist, bei dem es sich grundsätzlich um kleine Beträge handelt.

Das entspricht nicht den Tatsachen. Die gesamte Thematik ist deutlich komplexer. Dies haben wir in Deutschland im Jahre 2019 wahrgenommen, als das Landeskriminalamt NRW bei einem Edelmetallhändler in Duisburg im Rahmen einer Durchsuchung 26 Millionen Euro in bar beschlagnahmt hat. Man geht davon aus, dass allein dieses Netzwerk insgesamt 212 Millionen Euro über Jahre vorzugsweise in die Türkei geschleust hat.

Quelle: Tageschau

Aktuell werden wir durch die Medien mit einem ähnlich gelagerten Sachverhalt konfrontiert. Er zeigt die Komplexität des Systems, aber auch, dass sich der deutsche Staat des Risikos durchaus bewusst ist.

Quelle: Radio MK

Wenn man sich das Volumen und den Modus Operandi genau vor Augen führt, dann stellt man fest, dass keine der bis dato publizierte Typologien diesen Sachverhalt auch nur annähernd erfasst hatte.

Dass dieses über Jahrhunderte etablierte System grundsätzlich eine Daseinsberechtigung in bestimmten Regionen hat, wird am Beispiel der Fremdarbeiter auf der arabischen Halbinsel deutlich. Die dort tätigen Arbeiter, vorzugsweise aus Ländern wie Bangladesch, Nepal oder Indien rekrutiert, nutzen die dort in einer Vielzahl ansässigen HOSSP’s (Hawala and Other Similar Service Provider), um ihren Familien in der Heimat in regelmäßigen Abständen Geld für den Lebensunterhalt zu überweisen. Dieses System ist in diesen Ländern elementar wichtig, da weder Auftraggeber noch Empfänger oftmals über ein Konto verfügen.

In Deutschland besteht die große Herausforderung darin, die Anbieter derartiger Dienste zu identifizieren. Da durch neue Services, wie beispielsweise Bareinzahlungsautomaten, der Kontakt zum Kunden immer geringer wird und sich die Anzahl der persönlichen Kontakte auch aus Kostengründen seitens der Verpflichteten reduziert, kann ein wichtiges Element bei der Bekämpfung von Geldwäsche und der Finanzierung des Terrorismus nicht mehr aktiv gelebt werden: Der persönliche Kontakt zum Kunden, der nach wie vor ein elementarer Baustein einer effektiven Prävention ist.

Hawala-Banking wird in einigen Regionen dieser Welt, in denen das Bankensystem nicht so ausgeprägt ist wie in Europa, immer Bestandteil des Systems bleiben. Es muss aber darauf geachtet werden, dass es durch die Nutzer nicht missbraucht wird, um inkriminierte Werte zu legalisieren oder terroristische Aktivitäten zu unterstützen.

Gleichwohl ist Hawala in Deutschland aufgrund der Gesetzgebung nicht zulässig. Es erfordert enorme Anstrengungen von Seiten der Strafverfolgungsbehörden wie auch der Verpflichteten, derart komplexe Zahlungsverfahren ausfindig zu machen, um die Wirksamkeit der in den Kreditinstituten implementierten Präventionssysteme nicht zu unterwandern.

Quelle: Bundesfinanzministerium - Verordnung zu den nach dem Geldwäschegesetz meldepflichtigen Sachverhalten im Immobilienbereich

Als Konsequenz daraus kann es daher nicht erstaunen, dass die Anzahl der Verdachtsmeldungen aus diesem Kreis sprunghaft gestiegen ist, allen voran bei der Berufsgruppe der Notare.

Während es im Vergleich der Jahre 2018 zu 2019 zu einer Steigerung von über 100 % gekommen war (Anmerkung: 2018 wurden 8 Verdachtsmeldungen übermittelt, 2019 insgesamt 17), kam es im Jahr 2020 zu insgesamt 1.629 Meldungen an die FIU. Es wird also interessant sein zu beobachten, ob sich dieser Trend in den Folgejahren fortsetzen und dann auf hohem Niveau verbleiben wird.

Abbildung 1: Anzahl der Verdachtsmeldungen nach Verpflichteten-Gruppen (Quelle: FIU Jahresbericht 2020)

Das Thema Geldwäsche ist für Notare nicht gänzlich neu. Das Bundesministerium der Justiz hat bereits 2004 hierauf aufmerksam gemacht. Die öffentlich zugängliche Studie „Gefährdung von Rechtsanwälten, Steuerberatern, Notaren und Wirtschaftsprüfern durch Geldwäsche“

Quelle:
 

zielte darauf, diese Berufsgruppe anhand von konkreten Fallgestaltungen für das Thema zu sensibilisieren. Es bedurfte allerdings erst einer gesetzlichen Regelung, dass auch Notare fortan Verdachtsmeldungen an die FIU weiterleiten müssen. So ist beispielsweise eine Meldung zu erstatten, wenn Vertragsparteien aus Risikostaaten kommen oder wenn die Umstände der Kaufpreisabwicklung insgesamt nicht schlüssig erscheinen. Dies liegt unter anderem vor, wenn ein eklatantes Missverhältnis zwischen dem Kaufpreis und den bekannten Vermögenswerten der Klienten besteht. Hinsichtlich der Definition eines Risikostaats ist sicherlich noch Klärungsbedarf notwendig. Nur auf die Liste der EU-Delegierten-Verordnung sowie auf die durch die FATF publizierte Länderliste zu referenzieren, scheint zu kurz gegriffen. Die Länder beispielsweise, die der sogenannte „Russian Laundromat“ für seine finanziellen Aktivitäten genutzt hat, sind hier bislang nicht erfasst.

Für die Verpflichteten nach dem Geldwäschegesetz wäre es ausgesprochen hilfreich, Kenntnis zu erhalten, bei welchen Sachverhalten zum Beispiel die Berufsgruppe der Notare Verdachtsmeldungen an die FIU übermittelt hat. Dies dürfte den Verpflichteten einen Hinweis geben, mit welchen Typologien sich die Kreditwirtschaft im Zusammenhang mit Immobilienfinanzierungen auseinandersetzen muss. Hier hat die FIU in der Vergangenheit durch ihre Newsletter und die dort dargestellten Anhaltspunkte wichtige Vorarbeit geleistet, um die Verpflichteten entsprechend zu informieren.

Im Ganzen gesehen ist die Verpflichtung der Notare ein Schritt in die richtige Richtung für eine effektivere Geldwäscheprävention. Dieser kommt allerdings sehr spät. Letztendlich bleibt aber festzuhalten, dass der explosionsartige Anstieg der Meldungen gerechtfertigt und nach dem Motto „besser spät als nie“ mehr als notwendig erscheint.

Wichtig wird weiterhin sein, dass dieser Personenkreis auch stichprobenartig hinsichtlich der Einhaltung der Rechtsverordnung durch unabhängige Gremien geprüft wird. Die Herausforderung für die Prüfer wird darin bestehen, zunächst einmal einen Katalog von Indikatoren zu erstellen, um standardisierte Prüfungshandlungen vornehmen zu können.

Nach den Erfahrungen aus den Notariaten wird es nun auch interessant zu verfolgen sein, ob die Fallzahlen der weiteren Verpflichteten, wie Immobilienmakler oder Steuerberater, ebenfalls signifikante Steigerungen in der Zukunft aufweisen werden. 

 Abbildung 2: Anzahl Verdachtsmeldungen nach Verpflichteten-Gruppen

Wir sind gespannt auf den FIU Jahresbericht 2021, um zu erfahren, ob sich dieser Trend entsprechend fortsetzt.

Die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) hat am 08.06.2021 mit der Veröffentlichung der Auslegungs- und Anwendungshinweise (AuA) für Kreditinstitute die gesetzlichen Pflichten für Verpflichtete nach § 2 Absatz 1 Nummer 1 GwG konkretisiert. Wie im Blog-Beitrag meines Kollegen Uwe Weber bereits dargestellt, wurde den Kreditinstituten unter Ziffer 1 der AuA BT auferlegt, dass die Mittelherkunft bei Bartransaktionen abzuklären ist und die damit einhergehenden Prüf- und Dokumentationspflichten bis zum 08.08.2021 anzuwenden sind.

Mein Blog-Beitrag befasst sich mit Ziffer 6 der AuA BT. Die BaFin gibt hier Konkretisierungen in Bezug auf die Angemessenheit der eingesetzten Datenverarbeitungssysteme (DV-Systeme):

Auswahl, Beschaffenheit, Eignung:

Das Kreditinstitut hat sicherzustellen, dass das eingesetzte DV-System

1. flexibel parametrisiert werden kann, um an die Geschäftstätigkeit des Kreditinstituts angepasst zu werden, und jederzeit aktualisiert werden kann, sofern neue oder veränderte Erkenntnisse aus der institutsspezifischen Risikoanalyse vorliegen.

2. das Kreditinstitut grundsätzlich in die Lage versetzt, Transaktionsmuster, Auffälligkeiten und Abweichungen zu erkennen.

3. ein Indizienmodell enthält, das ein individuelles Konfigurieren ermöglicht unter Einbezug der einschlägigen Typologien im Bereich Geldwäsche, Terrorismusbekämpfung und sonstiger strafbarer Handlungen sowie der aktuellen Veröffentlichungen der FIU.

4. neben Kunden- und Produktrisiken auch Länderrisiken sowie Risiken der Terrorismusfinanzierung abbildet.

5. es erlaubt, Indizien unter dem Aspekt der Prävention von Geldwäsche, von Terrorismusfinanzierung und – soweit geboten – der Verhinderung sonstiger strafbarer Handlungen zu parametrisieren.

6. die erhöhten Risiken im Sinne des § 15 Abs. 3 GwG adäquat abdeckt.

7. die Überprüfung von Namen auf Ähnlichkeiten mittels unscharfer Suchlogik („fuzzy logic“) im Rahmen des Sanktionsscreenings zulässt.

8. das Verwenden und regelmäßige Aktualisieren der die gesetzlichen Vorgaben abbildenden Listen (Sanktionslisten, Embargolisten, PEP-Listen, etc.) unterstützt.

9. Auswertungs- und Statistikfunktionen enthält oder von diesen unterstützt wird, um Ad-hoc Recherchen durchzuführen und auf Auswertungen zur regelmäßigen Aktualisierung und    Weiterentwicklung der Risikoanalyse zurückzugreifen.

10. alle relevanten Daten aus den relevanten IT-Systemen, d.h. vor allem aus den Zahlungsverkehrs- und Transaktionssystemen und den Kundenstammdatenbanken des Kreditinstitutes aufnehmen und verarbeiten kann. Die Aktualität der Daten muss jederzeit gewährleistet sein.

11. dazu in der Lage ist, bestimmte Fallkonstellationen abzubilden, die aufgrund ihrer Gestaltung keine geldwäscherechtlichen Risiken darstellen und somit ausgeschlossen werden können.

12. die generierten Treffer vollständig anzeigen kann (vgl. § 6 Abs. 1 Satz 2 GwG).

13. insbesondere bei IT-basierten Entscheidungen bei jedem generierten Treffer die wesentlichen Einflussfaktoren aufzeigt und das Zustandekommen des Trefferergebnisses plausibel darstellt (Verbot von „Blackboxen“).

14. fehlende Daten kennzeichnen kann und bis zu deren Korrektur mit „default“-Werten arbeitet. Konkret bedeutet dies, dass bei fehlenden Daten, die risikorelevant sind, immer von einem Risiko-erhöhenden Standard-Wert ausgegangen werden muss.

15. auch historische Daten aufnehmen kann.

Es ist zulässig, für die verschiedenen Aufgaben (z. B. Monitoring, Screening) auch verschiedene Systeme anzuwenden. Entscheidend ist, dass die eingesetzten Systeme die oben genannten Aspekte in ihrer Gesamtheit abdecken.

Alles in allem sind dies keine neuen oder bisher unbeachteten Faktoren, jedoch hat die BaFin hiermit die bisher eher schwammigen Definitionen konkretisiert und mehr Klarheit geschaffen. Insgesamt wird deutlich, dass bei Einführung eines neuen Systems der Markt intensiv analysiert werden muss, um sicherzustellen, dass bei der Systemauswahl alle Aspekte der Angemessenheit hinreichend berücksichtigt werden. Dem Bereich Geldwäscheprävention kommt in diesem Zusammenhang eine besondere Rolle zu, da neben den rein technischen Komponenten insbesondere die fachlichen Komponenten entscheidend sind für die Auswahl eines geeigneten Systems.

Neben der Beschaffenheit der eingesetzten DV-Systeme und deren Effizienz spielt weiterhin die Daten- und Informationsqualität eine maßgebliche Rolle in der Bewertung des Gesamtsystems. Je höher die Qualität der Daten in den Quellsystemen ist, desto höher ist auch die Qualität der Ausgaben aus einem DV-System, die sogenannte Informationsqualität, und damit die Funktionsfähigkeit des Systems.

Datenqualität:

Um Datenqualität zu messen, werden typischerweise folgende Kriterien herangezogen:

- Korrektheit,
- Vollständigkeit,
- Zuverlässigkeit,
- Genauigkeit,
- Einheitlichkeit,
- Eindeutigkeit,
- Relevanz,
- Konsistenz und
- Aktualität.

Funktionsfähigkeit:

Die Funktionsfähigkeit eines DV-Systems ist gegeben, wenn

1. die Richtigkeit und Aktualität der Indizien, Regeln, Schwellenwerte, Scores und Risikoklassifizierungssysteme unter besonderer Berücksichtigung aller relevanten gesetzlichen Änderungen, regulatorischen Vorgaben, Warnungen und Informationen regelmäßig und anlassbezogen überprüft wird.
2. wesentliche Änderungen in der Risikoanalyse des Instituts in der Kalibrierung des Systems berücksichtigt werden.
3. regelmäßig fachgerechte Wartung, Überholung und − soweit nötig − technische Aufrüstung der Hardware des DV-Systems zur Sicherung seiner Funktionsfähigkeit stattfinden.
4. die reibungsfreie Zusammenarbeit der Einzelkomponenten und deren Schnittstellen zu den DV-Systemen jederzeit gewährleistet ist („End-to-End“). Das Kreditinstitut hat die ordnungsgemäße Funktionalität der DV-Systeme laufend zu überprüfen und regelmäßig für eine Qualitätskontrolle der DV-Systeme durch einen unabhängigen Prüfer zu sorgen.
5. das Kreditinstitut den Fall einer Störung oder eines Ausfalls des DV-Systems im Notfallkonzepts gemäß AT 7.3 der MaRisk berücksichtigt.
6. Änderungen der gesetzlichen Anforderungen hinsichtlich des Einsatzes von DV-Systemen und deren Regelungsgegenstand unverzüglich nach deren Inkrafttreten umgesetzt werden.

Auch diese Anforderungen sind nicht gänzlich neu, konkretisieren aber die Notwendigkeit, dass der fachliche und technische Bereich eng zusammenarbeiten, damit die Funktionsfähigkeit gewährleistet werden kann. Es wird deutlich, dass neben den Kreditinstituten auch die Anbieter solcher EDV-Lösungen eine Verantwortung tragen und dafür zu sorgen haben, dass ihre Systeme regelmäßig um sich ändernde oder neue Anforderungen ergänzt werden.

Ebenso wie die oben angesprochene Daten- und Informationsqualität auf die effektive und effiziente Verwendung der DV-Systeme einzahlt, gehört ein sachgerechtes Mapping der aus den Quellsystemen gelieferten Daten zu den Datenbankfeldern des DV-Systems zur Basis einer vollumfänglichen Funktionsfähigkeit. Bei der Auswahl des DV-Systems ist darauf zu achten, dass das DV-System ausreichend konzipiert ist, um die erforderlichen Daten auch nachhaltig (wiedererzeugbar) in der Datenbank aufzunehmen. Die Anforderungen an das Mapping eines DV-Systems im Bereich der Geldwäsche- und Terrorismusfinanzierungsprävention sind sehr hoch, da es nicht ausreichend ist, die Daten einfach abzulegen. Vielmehr müssen die Daten wiedererkennbar und innerhalb der gesetzlichen Fristen auch reproduzierbar sein, selbst wenn sich das Datenfeld inhaltlich ändert, aber sie dürfen nicht manipulierbar sein. Idealerweise ist das DV-System dazu in der Lage, die Datenfelder entsprechend den Bezeichnungen aus den Quellsystemen zu benennen.

Dokumentation:

Das DV-System muss erlauben, sämtliche Anpassungen an den Parametern (Einstellungen, Indizien, Berechtigungen) sowie alle erzeugten Treffer nebst Trefferdokumentation und gegebenenfalls erfolgte Verdachtsmeldungen gem. § 8 GwG so zu dokumentieren und zu archivieren, dass ein sachkundiger Dritter diese Vorgänge in angemessener Zeit nachvollziehen kann.

Dabei ist zu berücksichtigen, dass

1. erzeugte Treffer so zu dokumentieren sind, dass die Treffer-Analyse und die sich daraus ergebenden Erkenntnisse erkennbar und nachvollziehbar sind.
2. die Verantwortlichkeiten jederzeit erkennbar sind.
3. eine hinreichende Begründung angegeben wird, welche die Ordnungsmäßigkeit und Rechtmäßigkeit der Änderung schlüssig darlegt.

Die Anforderungen an die Dokumentation werden also nun zum ersten Mal konkretisiert und auch vom Umfang her klar beschreiben. Waren es bisher lediglich allgemeine Dokumentationsanforderungen, so sind es jetzt eindeutigere Definitionen. Es bleibt jedoch weiterhin ein Ermessensspielraum gegeben. Insbesondere im Zusammenhang mit Dokumentationspflichten werden die Prüfungsstellen, die Verbände und Organisationen sowie Revisoren bei Banken und Sparkassen wohl zukünftig genau hinsehen.

Eine wesentliche Anforderung der Ziffer 6 ist, dass die DV-Systeme die einschlägigen Typologien im Bereich Geldwäsche, Terrorismusbekämpfung und sonstiger strafbarer Handlungen sowie die aus den aktuellen Veröffentlichungen der FIU hervorgehenden Anhaltspunkte abbilden können müssen. Neben den schon dargestellten Anforderungen an die gelieferten Daten und deren Verwendbarkeit im DV-System ergehen hieraus auch Anforderungen an die Dokumentation und Prüfung: Alle relevanten Sachverhalte in Bezug zur Parametrisierung der DV-Systeme (wie Regeln, Indizien, etc.) müssen bei der Dokumentation berücksichtigt werden.

Hinsichtlich der Typologien und Anhaltspunkte gibt es eine Vielzahl an Dokumenten, die das Erfassen sämtlicher Typologien erschweren. Denn allein die FATF hat in den Jahren 2019 und 2020 mehr als 50 Publikationen mit Bezug zu Geldwäsche, Terrorismusfinanzierung und Proliferation veröffentlicht. Nimmt man den Bereich der sonstigen strafbaren Handlungen hinzu, kommen mehr als 300 Typologien zusammen. msg Rethink Compliance empfiehlt hier klar das Führen eines entsprechenden Registers, samt regelmäßiger Aktualisierung.

Management:

Bei der Vergabe von Benutzerrechten für das DV-System muss beachtet werden, dass der betroffene Benutzer alle erforderlichen fachlichen Qualifikationen und Expertisen aufweist. Dies gilt sowohl für eigene Mitarbeiter als auch für externe Berater.

Bei der Rechtevergabe ist sicherzustellen, dass erkennbar ist, welche Funktion der jeweilige Nutzer ausüben soll, und dass ihm nur die hierfür relevanten Rechte zugewiesen werden. Daraus erwächst die Anforderung, die mit der Nutzung des DV-Systems betrauten Mitarbeiter hinreichend zu schulen und fachlich weiterzubilden, um einen MaRisk-konformen und transparenten Betrieb zu gewährleisten.

Die fachliche Verantwortung liegt beim Geldwäschebeauftragten. Er ist verantwortlich für die fachliche Weiterentwicklung des DV-Systems, die Änderung der vorhandenen Indizien, Regeln oder Szenarien, Schwellenwerte und Scores sowie deren Generierung und Kalibrierung, und er hat über entsprechende Kenntnisse zu verfügen. Der Geldwäschebeauftragte muss die Möglichkeiten und Grenzen des DV-Systems kennen, um zu beurteilen, ob und wie neue Anforderungen umgesetzt werden können. Die letztliche technische Umsetzung kann durch spezialisierte Mitarbeiter oder durch externe Dienstleister erfolgen.

Auswahl des Datenverarbeitungssystems:

Sind die gesetzlich vorgegebenen Kriterien erfüllt, sind die Kreditinstitute hinsichtlich der Wahl des DV-Systems grundsätzlich ungebunden. Dass es keine Systemvorgaben gibt, unterstreicht die Aussage unter 6.2.6, dass bei Einführung eines neuen Systems der Markt intensiv analysiert werden muss und dass hierzu nicht nur fachliche, sondern auch technische Kenntnisse erforderlich sind.

Konkretisiert wurde jetzt auch, unter welchen Voraussetzungen von einem Einsatz eines DV-Systems abgesehen werden kann. § 25h Abs.2 Satz 1 KWG sieht einen generellen Einsatz von DV-Systemen für alle Kreditinstitute vor, erlaubt es der BaFin jedoch entsprechende Ausnahmen zu definieren. Dies wurde jetzt unter Ziffer 6.2.7 AuA BT getan.

Ein Kreditinstitut kann davon absehen, ein DV-System einzusetzen, wenn nur eine geringe Anzahl von Vertragspartnern/wirtschaftlich Berechtigten oder Transaktionen bestehen und diese auch ohne DV-System wirksam überwacht werden können. Die BaFin nennt als Richtgröße eine Bilanzsumme von unter 250 Mio. Euro.

Auslagerungen ins Ausland:

Unter 6.2.8 wird konkretisiert, dass eine Auslagerung an einen Dritten mit Sitz im Ausland möglich ist, jedoch nur, wenn sich die Niederlassung des Dritten nicht in einem Drittstaat mit hohen Risiken befindet.

In Bezug auf Auslagerungen ist allgemein darauf hinzuweisen, dass mit einer Auslagerung (Inland oder Ausland) das Kreditinstitut nicht die Verpflichtung nach dem Geldwäschegesetz auslagern kann. Die Verantwortung für die Erfüllung der Sicherungsmaßnahmen bleibt beim Verpflichteten. Dazu führt die BaFin unter 6.2.8 der AuA BT aus, dass sicherzustellen ist, dass der Geldwäschebeauftragte Zugriff auf alle Treffer hat und er unverzüglich über relevante Treffer informiert wird, so dass die Zeitvorgaben für die Abgabe von Verdachtsmeldungen eingehalten werden. Somit muss auch nach Auslagerung eine sachkundige Person im Kreditinstitut vorhanden sein.

Fazit:

Die Auswahl des richtigen oder auch passenden Systems ist keine einfache Aufgabe und stellt viele Institute vor Probleme. Die vorliegende Konkretisierung der BaFin in Bezug zur Angemessenheit von DV-Systemen kann für die Auswahl herangezogen werden und ist hilfreich für die Prüfung der Eignung. Zu den anderen Aspekten eines Auswahlverfahrens, den Methoden oder Instrumenten gibt es keine Konkretisierung. Es bleibt daher von meiner Seite zu empfehlen, das Auswahlverfahren und die getroffenen Entscheidungen zu dokumentieren, um auch hier den Spielraum und mögliche Konsequenzen einer Falschauswahl zu minimieren.

Software ist immer ein bewegliches Ziel. Software kann niemals komplett „fertig“ sein, sondern unterliegt einem ständigen Wandel durch Weiterentwicklungen und Erweiterungen. Selbst Microsoft kündigt nach dem Versprechen einer endgültigen Version 10, mit schrittweisen Upgrades, eine neue Windows-Version an. Im AML Compliance-Bereich, d.h. AML, KYC und Transaktionsscreening, befindet sich das nächste Upgrade- oder Migrationsprojekt nach einem erfolgreichen Go-Live schon fast in der Vorbereitung, da neue Vorschriften und Sicherheitsfunktionen immer erweiterte Versionen erfordern. Bei der Auswahl eines neuen Compliance-Systems stellen sich viele Fragen - eine davon ist die "Cloud-Frage", zu der ich mit diesem Beitrag kurz einige wichtige Aspekte für die Entscheidungsfindung liefern möchte. Es gibt viele Cloud-Versprechen, wie niedrigere Kosten, schnellere Bereitstellung, Skalierbarkeit, Flexibilität, Zukunftssicherheit u.v.m., die man in verschiedenen Varianten auf den Webseiten aller Cloud-Software-Anbieter finden kann.

Je nach Rechtsraum müssen verschiedene Restriktionen und Gesetze im Zusammenhang mit der Speicherung sensibler Daten in der Cloud beachtet werden. Ich werde diesen Themenkomplex nicht einmal oberflächlich umreißen, werde aber dennoch zwei wichtige Vorschriften benennen. Die DSGVO und all ihre Aspekte können leicht eine Woche voller Workshops füllen, die MaRisk (siehe BaFin AT9) machen es schwieriger, compliant zu sein. Ein wichtiger Punkt ist der Standort der Cloud-Server. Es kann notwendig oder zumindest vorteilhaft sein, dass die Daten das Land nicht verlassen. Kommerzielle Cloud-Plattformen wie AWS, Google und Azure bieten ihre Dienste in länderübergreifenden Regionen an, was für Unternehmen in kleineren Ländern ein K.o.-Kriterium darstellen könnte. Wenn eine geeignete Region gefunden ist, die außerhalb der Hauptregionen (wie USA, Vereinigtes Königreich) liegt, kann es auch vorkommen, dass nicht alle Cloud-Dienste aktuell angeboten werden.

Der nächste wichtige Faktor ist die Erfahrung. Ist im Unternehmen (jenseits von Office365) bereits Cloud-Software im Einsatz und ist die jeweilige Compliance-Software, z. B. das Screening-, Monitoring- oder Research-System, Cloud-ready oder vorzugsweise Cloud-nativ? Die Compliance-Abteilung sollte aufgrund ihrer übergeordneten Bedeutung nicht in eine Position gebracht werden, neue Technologien zu pilotieren, sondern eher der Strategie folgen als sie zu definieren. Die kniffligere Frage ist die letztgenannte: Ist die Software Cloud-nativ? Da es sich bei den meisten Lösungen um Closed-Source-Software handelt, anbei einige Anhaltspunkte, wie dies festgestellt werden kann:

• Integrierte Skalierbarkeit und Hochverfügbarkeit
• Eine überzeugende Anzahl von bestehenden Installationen
• Eine vollständig automatisierte Deploymentpipeline
• Aufgeteilt in Microservices statt monolithischer Blöcke
• Open-Source-Nutzung mit adäquaten Versionen (OpenJDK 12 vs. Oracle Java 8, oder PostgreSQL vs. Oracle Database)

In der Vergangenheit galt Open-Source-Software aufgrund von Sicherheits- und Support-Problemen oft als ein „No-Go“ im Banken- und Compliance-Bereich. Es gibt kontroverse Diskussionen darüber, ob Closed- oder Open-Source-Software als sicherer angesehen wird. Die meisten Linux-Distributionen bieten kommerziellen Support an. Auch bei Datenbanksystemen wie Mongo, PostgreSQL oder Couchbase stehen Unternehmen hinter der Entwicklung, deren Geschäftsmodell darin besteht, kostenpflichtigen Support zu leisten. Diese Unternehmen können durch Kunden gezwungen werden, Schutz gegen etwaige Sicherheitsschwachstellen zu bieten und Sicherheitslücken gleich zu schließen. In gewissem Sinne kann dieser Trend als "das Beste aus beiden Welten" betrachtet werden: Der Code ist immer noch frei verfügbar, aber man kann dennoch Enterprise Level Support erwarten.

Der Betrieb von Legacy-Software in einer Cloud-Umgebung ist möglich, vereint aber in gewisser Weise „das Schlechteste aus beiden Welten“. Der Einrichtungsprozess kann komplex sein. Es können Abhängigkeiten zu Datenbanken und (Windows-) Betriebssystemen bestehen. Die Hardwarekosten könnten viel höher ausfallen, da virtuelle Maschinen anstelle von leichtgewichtigen Containern verwendet werden. Eines der größten Versprechen der Cloud sind Kostensenkungen. Letztendlich kostet ein virtueller Server mit echten CPUs und exklusiv reserviertem Speicher bei eigenem Hosting viel mehr, gerade wenn ein Dritter auch noch seinen Anteil daran haben möchte. Für einen schnellen Vergleich geht man einfach zu ein paar Webhosting-Unternehmen und vergleicht deren Serverkosten z. B. AWS EC2 oder Microsoft Azure VM (die nicht einmal Speicherplatz inkludieren). Daher sollte man sorgfältig zwischen dem Betrieb virtueller Maschinen im "Internet" und Cloud-nativen Lösungen unterscheiden. Erstere helfen niemals Kosten zu sparen, letztere haben das Potenzial Kosten zu senken. Es ist sehr wichtig, ein Konzept für die laufenden Kosten der Lösung zu haben, die direkt oder indirekt von der Bank gezahlt werden müssen.

Ein weiterer wichtiger Aspekt ist die Performance der Lösung. Garantiert der Anbieter Antwortzeiten und Betriebszeiten (und werden diese vom Cloud-Lieferant im Hintergrund abgedeckt)? Bei Kauf von Software-as-a-Service sind alle diese Aspekte idealerweise im Vertrag und im Verantwortungsbereich des Software-Anbieters enthalten.

Insbesondere wenn das Backend der Umgebung für den Endnutzer oder das technische Team der Bank nicht zugänglich ist, ist es wichtig, gute APIs für die Extraktion von Berichten, Protokollen und Audit-Trails zu haben. Das Compliance-Team der Bank bleibt verantwortlich für die Einhaltung der Vorschriften, daher sollten die verfügbaren Berichte gut aufgebaut und getestet sein. Niemand möchte eine solche imaginäre Unterhaltung hören:

F: Sehr geehrter Anbieter, können Sie bitte einen Bericht über alle auffällig gewordenen Transaktionen der letzten 13 Monate und die jeweiligen Nutzer, die an diesen Auffälligkeiten arbeiten, zur Verfügung stellen?

A: Sehr geehrter Kunde, wir verweisen auf das von Ihnen bestellte Standard-API-Paket, das keine Transaktionsdetails enthält.

Wenn die Lösung vor Ort betrieben wird, könnten technisch versierte Berater hinzugezogen werden, die in der Lage sind, ein paar Ad-hoc-Auszüge aus der Datenbank zu generieren und den Prüfer zufriedenzustellen. Ein solcher Backend-Zugriff ist bei einer echten Cloud-Lösung höchstwahrscheinlich nicht möglich - insbesondere nicht mit der zeitlichen Einschränkung wie in der imaginären Situation.

Bei Tendenz in Richtung Cloud-Implementierung ist ein potenzielles Anbieter-Lock-In zu berücksichtigen. Ist es beispielsweise möglich und machbar von AWS zur Google Cloud zu wechseln? Alle großen Cloud-Angebote verfügen über Hunderte von speziellen Diensten, auf denen die Anwendungsarchitektur aufgebaut werden kann. Die Nutzung dieser Dienste für die Entwicklung einer Cloud-Lösung mag intelligent und modern sein, aber wenn der Cloud-Anbieter sich als „böse“ erweist oder einfach zu teuer wird, könnte es schwierig oder gar unmöglich werden, den Anbieter zu wechseln. Es gibt auch Software-Anbieter für Anwendungs-Middleware, wie dapr.io und ähnliche Frameworks, um die Flexibilität bezüglich AWS/Google/Azure zu erhalten und Lock-in-Effekte zu vermeiden.

Die Hybrid-Cloud könnte eine dritte Option sein, insbesondere für zustandslose Anfragen wie das Screening von Namen und Transaktionen in Echtzeit. In diesem Szenario wird das Benutzer-Frontend vor Ort gehostet und die CPU/IO-Schwerstarbeit wird in der Cloud erledigt. Aufgrund der nahezu unbegrenzten Hardware-Flexibilität könnte es eine gute Idee sein, die Cloud auch für zeitlich begrenzte Projekte wie Parallelbetrieb und Systemmigrationen zu nutzen.

Die Antwort auf die Cloud-Frage lautet höchstwahrscheinlich "es kommt darauf an". Neu gegründete Unternehmen tendieren dazu, von Anfang an auf Cloud-native zu setzen. Größere Organisationen bauen gerne eigene Cloud-Umgebungen auf, da Cloud nicht unbedingt bedeutet, einen der großen Anbieter einzukaufen, sondern eher ein Deployment- und Software-Design-Muster einzusetzen. Für das Finden der richtigen Antwort in diesem Bereich sind meine msg Rethink Compliance Kollegen und ich bestens gerüstet. Wir verfügen über fundierte Erfahrungen mit Cloud-, Hybrid-Cloud- und On-Premise-Implementierungen, um unsere Kunden bei solch einer wegweisenden Entscheidung optimal zu unterstützen.