Nicht selten werden Anforderungen von Aufsicht und Gesetzgeber als zusätzliche Bürde und Kostenfaktor im Compliance-Umfeld betrachtet. Die Umsetzungs- beziehungsweise Überprüfungsanforderungen aus dem BaFin AuA Besonderer Teil – Kapitel 6 (nachfolgend kurz BT 6) können aber auch als Grundlage oder Hilfestellung verstanden werden, welche wesentlich helfen, die Monitoring- und Screening-Systemlandschaft stabil und robust zu betreiben. Die frühzeitige Berücksichtigung der BT 6 Anforderungen können insbesondere bei System-Neueinführungen einen Grundsockel bilden, um im Business-as-Usual-Modul effektiv und ohne Feststellungen zu bleiben.
Alter Wein in neuen Schläuchen? Hintergrund BT 6.2.3
Die im Juni 2021 von der BaFin veröffentlichten Auslegungs- und Anwendungshinweise zum Geldwäschegesetz – Besonderer Teil für Kreditinstitute (nachfolgend kurz BaFin AuA) konkretisierten erstmalig spezifische Anforderungen an die Eignung und Ausgestaltung der Monitoring- und Screeningsysteme der Institute, wobei der Fokus der BaFin Auslegungshinweise auf dem Geldwäschemonitoring, der Prüfung der politisch exponierten Personen (PeP) und der Adverse Media-Prüfung liegt. Nach dem ersten Lesen der Absätze im relevanten Kapitel 6 („Monitoringsysteme“) kann der Eindruck entstehen, dass hier lediglich bereits bestehende Anforderungen der Aufsicht noch einmal wiederholt wurden.
Geldwäscheanforderungen inklusive der betroffenen Systeme sind allerdings kein neuer Prüfungsfokus und wurden unter anderem als Teil der Jahresabschlussprüfung schon seit langem vom Prüfer betrachtet.
Anders als man beim schnellen Lesen über die Auslegungshinweise vermuten kann, verbirgt sich in Kapitel 6.2.3 („Funktionsfähigkeit der Datenverarbeitungssysteme“) jedoch die konkrete Anforderung einer regelmäßigen Überprüfung durch unabhängige Dritte.
Nach wie vor führen Fragen wie die Bedeutung der Regelmäßigkeit, der Definition, wer unabhängiger Prüfer ist und was der Fokus dieser Überprüfung ist, die häufig auch fälschlicherweise als Systemvalidierung bezeichnet wird, bei Instituten zu Interpretationsproblemen.
Aber warum?
Interpretationsherausforderungen in der Praxis
Auch noch knapp vier Jahre nach der Veröffentlichung erhalten Prüfungs- und Beratungsunternehmen Anfragen zur erstmaligen Überprüfung der Systeme in Instituten. Blickt man in die IT- und Compliance-Vorgaben für den Systembetrieb der Institute, werden die BT 6 Anforderungen nicht immer explizit als eigenständiger Anforderungsblock konkret benannt.
Daneben wird häufig die Frequenz hinterfragt. „Regelmäßig“ lässt sich auf einen mindestens zweijährigen Rhythmus umstellen, sofern keine wesentlichen Veränderungen an den Systemen vorgenommen wurden. Durch Änderungen an den Systemen kann auch eine kürzere, erneute Überprüfung notwendig werden.
Hauptfragestellung in der Praxis ist bei den Instituten aber meist der Systemumfang und der Überprüfungsumfang. Der BT 6 zielt primär auf die Geldwäsche-Monitoringsysteme ab, inkludiert aber PeP- und Adverse Media-Prüfung, sowie indirekt in der Regel auch den Sanktionsfilter als solchen, da dieser in der Praxis meist im selben System zusammengefasst ist. Über die Einbeziehung der sonstigen strafbaren Handlungen werden auch die Systembausteine zur Betrugsprävention in den Betrachtungsfokus gerückt.
Die BT 6 Anforderungen unterscheiden zudem nicht zwischen der Überprüfung von Neu- oder Bestandskunden und Transaktionen.
Neben der Frage des „wie oft“ und „welches System“ könnte auch interpretiert werden, dass Kern der Überprüfung das Regel- und Szenarien-System der Monitoring- und Screeningsysteme ist.
Aus dem Abschnitt 6.2.3 leitet sich jedoch ein anderer Schwerpunkt ab: Die Integration der Anwendung in das IT-Ökosystem des Instituts einschließlich Datenversorgung, Hardwareausstattung, IT-Notfallmanagement und Security. Kern der Überprüfung ist somit die Sicherstellung einer vollständigen Datenbelieferung und eines geregelten, stabilen IT-Betriebs; ergänzt um Aspekte wie Governance, Mitarbeitende und Reporting.
Die Anforderungen erfordern zudem keine vollumfängliche Detailevaluation beispielsweise von Datenströmen durch umfangreiche Stichproben aller Datenquellen und Systeme, Schnittstellen und APIs, sondern eine Überprüfung der grundlegenden Abläufe und Kontrollen durch den Geldwäschebeauftragten. Unsere Erfahrung hat bestätigt, dass eine Ausweitung der Überprüfung (zum Beispiel mit zusätzlichen Stichproben) Probleme unter anderem in der Datenversorgung der Systeme aufdecken kann, welche durch die Mindestanforderungen nur bedingt oder stark zeitverzögert aufgedeckt werden.
Abbildung 1: Fokus der Aufsicht, Interpretationssicht vieler Institute und sinnvolle Ergänzungen; Bildquelle: Deloitte
Im obigen Abbild sind die Kernanforderungen des BT 6 überblicksartig hinterlegt, ergänzt um Erweiterungsstufen und Ergänzungen. Grundsätzlich kann eine BT 6.2.3 Überprüfung auch als Startpunkt genutzt werden, um die Geldwäsche (GW)-Systeme und die darin enthaltenen Szenarien, Schwellenwerte und Einstellungen einer 360°-Evaluation zu unterziehen. Hieraus kann ein Mehrwert in der operativen Prozessdurchführung gewonnen werden: Dazu zählt die Optimierung des Systems in Bezug auf Daten- und Datenqualität sowie die Verfeinerung von Szenarien- und Filterregeln, um relevante Auffälligkeiten zu identifizieren und ergänzend False-Positives zu reduzieren.
Wichtige Aspekte für eine effektive Review-Praxis
Mit dem BT 6 verbundene Beratungs- und Überprüfungsprojekte der vergangenen Jahre haben verschiedene Optimierungspunkte und Herausforderungen aufgezeigt, welche institutsübergreifend relevant sind. Auch hat sich bei Einführungs- und Anpassungsprojekten von Softwarelösungen ein breites Spektrum an Schwerpunkten herauskristallisiert, welche nachfolgend kurz beleuchtet werden.
Dokumentation: Vollständigkeit, Konsistenz und Aktualität
Eine der ersten Schritte des Reviews ist in der Regel die Sichtung der bestehenden Dokumentation und Nachweise. Klassisch werden bei diesem ersten Schritt der Überprüfung verschiedenste Dokumente beim betroffenen Institut angefragt.
Qualitätskriterien in Bezug auf die Dokumentation an sich sind:
- Verfahrensdokumente, technische Beschreibungen zu Datenanbindungen etc. Aktualität, Vollständigkeit der Freigaben (Status „Final“) sowie eingehaltene Review-Zyklen.
- Die relevanten Dokumente sind beim jeweiligen Institut den Mitarbeitenden zugänglich (beispielsweise veröffentlicht im Intranet).
- Die Dokumente enthalten bei Zuständigkeiten und Rollen (sofern immer möglich) Abteilungs- und Rollenbezeichnungen.
- Dokumente sind in sich konsistent und es treten keine Widersprüche bei verschiedenen Dokumenten in Bezug auf beispielsweise Zuständigkeiten und IT-Zusammenhänge auf.
Das gesamte Prozessrahmenwerk wird nicht selten als zusammenhängendes Paket aktualisiert, um Inkonsistenzen und veraltete Verweise etc. zu vermeiden.
Abbildung 2: Schwerpunkt & Herausforderungen in der Praxis; Bildquelle: Deloitte
Auch in Zeiten von Digitalisierung und Automatisierung spielen fachkundige Mitarbeitende im Institut eine wichtige Rolle beim stabilen Betrieb der Monitoring- und Screeninglösung. Die Anforderungen fokussieren hier insbesondere auf die für den Betrieb und die Konfiguration relevanten Rollen und Mitarbeitenden und stellen fachliche Kompetenz sowie ausreichende Ressourcenausstattung in den Vordergrund.
Spezialkenntnisse über die jeweiligen genutzten Lösungen beziehungsweise erfahrene Mitarbeitende mit den entsprechenden Berechtigungen sind Schlüsselfaktoren für einen stabilen Systembetrieb. Die genauen Anforderungen an die Vergabe von Berechtigungen sollte daher eng mit dem Schulungskonzept verknüpft sein und formell definierte Anforderungen sollten mit der Berechtigungsvergabe an Mitarbeitende verbunden sein. Fehlen qualifizierte, routinierte Mitarbeitende, können folglich Fehler im operativen Betrieb der Lösung oder auch der Konfiguration entstehen. Parallel dazu zeigt sich der Fachkräftemangel auch bei der Betreuung und dem Betrieb der Monitoringsysteme.
Grundsätzlich sollte eine Konzentration auf wenige Schlüsselressourcen für Kern-Prozesse in den AML-Lösungen und administrative Aktivitäten (beispielsweise bei der Freigabe von Parametern) wo möglich vermieden werden, eine adäquate Ressourcenausstattung auch beim Fachpersonal ist zu planen.
So können Verzögerungen bei Changes und Backlogs, aber auch kritische Fehler in der Administration und Betreuung der Monitoring- und Screeninglösungen durch krankheitsbedingte Ausfälle, Urlaubsabwesenheiten und die generelle Arbeitsbelastung in der Compliance-Linienorganisation vermieden werden.
Datenkontrolle: Sicherstellung einer End-to-End-Kontrolle der Vollständigkeit über alle Verarbeitungsschritte hinweg
Neben der technischen Ressourcenausstattung der relevanten Systeme liegt ein Augenmerk auf der Sicherstellung der korrekten und vollständigen Datenbelieferung aus den dafür notwendigen Vorsystemen wie KYC/Kundenmanagement, Kernbankensystem oder Transaktionssysteme.
Hierbei geht es um weit mehr als nur die Sicherstellung der Datenvollständigkeit an der Schnittstelle zu der Monitoring-, Screening- beziehungsweise Fraud-Lösung. Es muss über die Lieferstrecke der verschiedenen Quellsystemen über gegebenenfalls zwischengeschaltete Datenbanken eine Vollständigkeit der relevanten Kunden beziehungsweise Transaktionen sichergestellt sein.
Insbesondere stark fragmentierte Systemlandschaften mit historischen (Kunden-) Datenbeständen in dezentralen Anwendungen stellen hierbei eine der größten Herausforderungen dar. Daneben ist die Frage nach der Definition des „Kunden“ häufig eine fachlich-technische Herausforderung. Für Screening-Themen wie Sanktionen geht die Notwendigkeit der Überprüfung über den eigenen Kundenbestand hinaus und erweitert sich auch auf Dritte, welche im Zuge einer Transaktion einen Mittelzufluss erhalten würden. Als zielführend hat sich eine vollständige Dokumentation der Datenflüsse von den Quellsystemen hin bis zum Monitoring- und Screeningsystem als hilfreich für die BT 6 Überprüfung aber auch den Tagesbetrieb gezeigt. Egal ob in Excel- oder einer anderen Dokumentationsform: Der Datenfluss muss auf der Ebene der einzelnen Attribute nachvollziehbar sein, Filter und Verarbeitungsprozesse an Schnittstellen und Datenbanken und Co. müssen transparent und Zuständigkeiten und Kontrollen klar ersichtlich sein.
Die Datenqualität sowie die Qualität der Datendokumentation der verschiedenen Systeme und ihrer Datenstrukturen sind von hoher Bedeutung. Besonders das Fachwissen über die Datenarchitektur spielt bei der Auswahl der richtigen Attribute für Filter- und Sortiervorgänge eine entscheidende Rolle. Es ist wichtig sicherzustellen, dass Entscheidungen zu Schnittstellen-Attributen und deren fachlicher Bedeutung auf fundiertem Wissen basieren. Dies minimiert das Risiko, fehlerhafte Datensätze im Monitoring oder Screening zu verwenden.
In fragmentierten Systemlandschaften gibt es aus historischen Gründen häufig keine eindeutige Entscheidung zur Trennung zwischen juristischen und natürlichen Personen. Werden dafür „Hilfsattribute“ oder Kombinationen hieraus herangezogen, kann das richtig sein – muss es aber nicht. Betrachtet man dieses Beispiel und untersucht die Ursachen für eine falsche Interpretation zum Beispiel bei der PEP-Prüfung eines vermeintlichen Unternehmens, sind fehlende Eingabemöglichkeiten in den Vorsystemen häufig die Ursache. Eine konsistente Datenarchitektur im Institut mit klaren Vorgaben zu Attributen und deren Werteausprägungen ist daher nicht nur für AML- und Sanktionsfragestellungen entscheidend. Beispielhaft hierfür sind klare Kennzeichen für Einzelpersonen vs. Gemeinschaftskonten. So kann verhindert werden, dass aufgrund fehlerhafter Interpretation aus anderen Datenmerkmalen zum Beispiel im PeP-Filter eine vermeintlich juristische Person nicht gegen die einschlägigen Listen geprüft wird. Ähnliche Fehlerstrecken sind in der Praxis beispielsweise auch beim Datum der Accountanlage oder der Trennung zwischen Interessenten und tatsächlichem Kunden zu vermeiden.
Für die Überprüfung stellen daher die Nachvollziehbarkeit der Datenströme und die Zusammensetzung des Datenhaushaltes über die verschiedenen Systeme eine Kernanforderung dar. Je besser sich Datenherkunft, mögliche Ausprägungen und das Mapping auf Datenfelder und Tabellen nachvollziehen lassen, desto geringer sind Fehlerrisiken bei der Implementierung. An diesem Punkt gibt es wiederum eine Verbindung zum operativen Management der IT-Systeme: Wie wird sichergestellt, dass bei Veränderungen in der Systemlandschaft die Datenbelieferung vollständig bleibt?
Neben der Sicherstellung von initial korrekt aufgesetzten Datenstrecken und Schnittstellen stellen besonders die Kontrollmechanismen für eine vollständige Datenbelieferung ein Schwerpunktthema dar. Besonders die Frage nach den verfügbaren Kontrollmöglichkeiten für den Geldwäschebeauftragten (GWB), um Lücken in der (täglichen) Datenbelieferung zu erkennen, stehen im Fokus.
In Bezug auf die Überprüfung der Datenvollständigkeit darf sich der GWB nicht nur auf Kontrollen zwischen Liefer- und Monitoring- und Screeningsystem fokussieren, sondern muss die gesamte Lieferkette in die risikoorientierte Betrachtung einbeziehen. Hierfür sollten möglichst täglich oder bei jedem Import-Export-Vorgang die Mengen zwischen der jeweiligen Datenquelle und den tatsächlich eingelesenen Datensätzen (technisch) abgeglichen und im Abweichungsfall eskaliert werden. Die alleinige Überprüfung auf die reine Vollständigkeit der Datensätze / Datenzeilen ist aber nicht ausreichend, da i.d.R. zusätzliche Datenattribute wie das oben bereits herangezogene Datenmerkmal zur Trennung nach juristischer und natürlicher Person für die eigentliche Überprüfungsqualität im Pep- und Sanktionsfilter wesentlich ist.
Wie kann also auch die Vollständigkeit der relevanten Lieferattribute innerhalb eines Datensatzes zeitnah evaluiert werden?
Für die Beantwortung dieser Frage ist ein kurzer Blick auf die möglichen Ursachen notwendig. Nicht selten führen Eingabeänderungen in den Frontsystemen (zum Beispiel im Customer Management) dazu, dass Datenfelder leer sind und wiederum für diesen einzelnen Kunden am Liefertag ein Attribut leer sein kann (sofern es sich nicht um ein Pflichtfeld handelt).
Treten hingegen für eine Vielzahl von Kunden an einem Tag eine auffällige Häufigkeit von fehlenden Attributen auf, liegt dies meist an technischen Problemen wie vorangegangenen Anpassungen an Eingabemasken, Auswahlmöglichkeiten, Datentypen und weiterem.
Sollten auffällige Abweichungen in der Datenbelieferung auftreten, sind statistische Verfahren als Teil des Importvorganges notwendig, welche einen Alert oder Incident generieren, sofern zu einem Vergleichszeitpunkt (zum Beispiel Vortag oder Monatsdurchschnitt) Dateninhalte unter einer Schwelle liegen.
Im Fokus einer Überprüfung stehen zusätzlich mögliche Datenausschlüsse. Diese betreffen die zugelieferten Kunden und Transaktionen, aber auch Ausschlüsse in Datenlisten wie PeP und anderen Kategorien. Neben einer schlüssigen, risikoorientierten Herleitung von Filterkriterien (zum Beispiel welche SWIFT-Nachrichtentypen für die Überwachung relevant sind und warum gegebenenfalls nicht) spielt wiederum die Etablierung von Mechanismen und Kontrollen eine wichtige Rolle, welche sicherstellen sollen, dass bei technischen aber auch bei fachlichen Veränderungen eine Überprüfung der systemseitigen Ausschlüsse vorgenommen wird (Stichwort Integration Change-Management). Der GWB sollte daher eng in den Neu-Produkt-Prozess integriert sein und zum Beispiel als Teil der jährlichen Risikoanalyse seine Ausschlüsse und Annahmen kritisch überprüfen und gegebenenfalls in den Systemen nachjustieren.
Auslagerung: Kontrolle über den Dienstleister und Konsistenz der Anforderungen an IT-Security und BCM mit dem Institut
Mit Blick auf den eigentlichen IT-Betrieb und die Wartung und Betreuung der betroffenen Anwendungen greifen Institute nicht selten auf externe Dritte beziehungsweise die IT-Dienstleister ihrer Gruppe zurück. Die Spannbreite der Verlagerung reicht von einem reinen IT-Betrieb bis hin zur Auslagerung von Sorgfaltspflichten gemäß § 17 GWG.
Für den IT-Dienstleister gelten grundsätzlich unabhängig des Umfanges der Verlagerung die gleichen Anforderungen, in der Praxis werden jedoch gesonderte Aktivitäten und Schwerpunkte vorgenommen.
Als Teil der Überprüfung werden daher neben den Vertragswerken, Servicekatalogen und Leistungsscheinen insbesondere die Schnittstellen zum Dienstleister in den Fokus gerückt. Kernfrage ist, ob bei Incidents, Notfällen, Changes und Datenproblemen der GWB des Instituts zeitnah eingebunden wird und jederzeit die Steuerungshoheit für die ihn betroffenen Pflichten innehält.
Auslagerung von Sorgfaltspflichten vs. IT-Verlagerung
Es ist entscheidend, dass in den Service Agreements und Leistungsbeschreibungen mit dem Dienstleister der konkrete Umfang klar definiert wird und Zuständigkeiten eindeutig abgegrenzt sind. Konkrete Leistungsscheine mit einer klaren Aufgabenbeschreibung sollten erstellt werden, um Grauzonen zu vermeiden und die Transparenz zu gewährleisten.
Je nach Reifegrad des Auslagerungsmanagements und der Compliance-Organisation sollten die exakten Aufgaben und Befugnisse klar und schriftlich fixiert und die Entscheidungskompetenz eindeutig definiert sein. Sind in der Praxis Abweichungen zwischen zum Beispiel Leistungskatalog und gelebter Prozesspraxis vereinbart, müssen diese nachvollziehbar und konsistent über alle Dokumente hinterlegt werden. Insbesondere dann, wenn der Dienstleister mehr als einen reinen IT-Betrieb übernimmt und auch in die operativen Compliance-Prozesse eingebunden ist, bestehen Zweifel an einer reinen IT-Verlagerung. Häufig sind die Dienstleister in die Vorklärung von Treffern involviert, was wiederum auf eine Auslagerung hindeutet.
Verlagerung und Notfallmanagement (Business Continuity Management / BCM) sowie IT-Sicherheit.
Die u.a. aus der MaRisk abgeleiteten Anforderungen an das Risikomanagement der IT spielen eine wichtige Rolle auch im Umfeld der Geldwäsche-Systeme. Die vom Institut vorgenommene Schutzbedarfseinwertung und die dazugehörige Definition der Kritikalität der AML-Systeme inklusive der Anforderungen an Wiederherstellungszeiten, maximaler Ausfallzeit, etc. werden auch von den Auslegungshinweisen aufgegriffen und fließen folglich in die Überprüfung ein. Zwar ist kurzzeitig die Aufrechthaltung der Geschäftsprozess mit entsprechenden, aufwändigen Mitigationsmaßnahmen möglich (zum Beispiel Definition von manuellen Prüfungen für betriebsrelevante Transaktionen), über einen Zeitraum von mehr als ein bis zwei Tagen kann aber aus Ressourcen- und Risikogesichtspunkten kein Betrieb erfolgen. Institutsspezifisch kann lediglich abgeleitet werden, ob und eventuell wie lange ohne die Systeme operativ gearbeitet werden kann, sowie welche Einschränkungen, wie ein Stopp von Auszahlungen von Finanzmitteln, überhaupt realistisch sind.
Hier ergeben sich in der Praxis zwei Schwerpunkte der Überprüfung: Einerseits, ob der GWB in die Einstufungen (aktiv) eingebunden ist, und andererseits, wie die Business Continuity-Maßnahmen auszusehen haben, welche sich hieraus ableiten. Besonders bei ausgelagertem Betrieb der Systeme müssen diese Anforderungen vertragsseitig berücksichtigt sein.
Häufig zeigt sich bei der Sichtung der relevanten Vertragsbestandteile, dass zwar entsprechende (Sicherheits-) Zertifizierungen des Dienstleisters und Nachweise wie ISAE 3402 vorliegen, die Anforderungen der Bank an IT-Sicherheit und BCM aber nicht deckungsgleich mit den SLAs im Vertrag sind.
Kritisch sind insbesondere im Krisenfall die Kommunikationsabläufe zwischen IT-Verantwortlichen und dem GWB. Bei IT-Auslagerungen wird die Kommunikation häufig über das Auslagerungsmanagement oder andere zentrale Steuerungsfunktionen in den Instituten vorgenommen. Auch hier muss sichergestellt werden, dass der GWB (oder seine Stellvertreter) direkt informiert beziehungsweise einbezogen wird.
Change-Management und Kontrolle über Veränderungen (Governance)
Auch wenn Begriffe wie Change-Management, Release Management, Incident und ähnliche nicht unbedingt Kernbestandteil des Sprachportfolios des GWB sind, sind diese ITIL (IT Infrastructure Library) geprägten Begriffe und die dahinterliegenden Prozesskonzepte essenziell für einen stabilen und konsistenten Betrieb der AML-Systeme.
Wie bereits mehrfach angemerkt, spielt die Einbindung der relevanten Rollen in der Compliance-Organisation bei fachlichen und technischen Veränderungen eine wichtige Rolle.
Folgende Aspekte sind in der Praxis besonders zu beachten:
- Der GWB ist in die relevanten Change Boards integriert
- Änderungen an vorgelagerten IT-Systemen und DWHs werden konsistent an alle Stakeholder inkl. GWB kommuniziert
- Optimierung der Impact-Analysen und des Testings der Veränderungen (end-to-end entlang der Lieferstecken)
- Die Einbindung bei fachlichen Anpassungen (inkl. neuen Produkten) wird in den Governance-Prozessen definiert
- Direkte Einbindung bei Veränderungen bei Dienstleistern
Eigenentwicklungen und weitere Möglichkeiten im Umfeld AFC
Allgemein ging der Trend in den letzten Jahren sehr stark in die Nutzung von markterprobten Compliance-Lösungen. Nur noch in wenigen Sonderfällen werden individuelle Lösungen von den Banken für Spezialfälle entwickelt und betrieben. Dies liegt primär am hohen Reifegrad dieser in Bezug auf Performance und fachlich-technische Features; auch wenn man bei älteren Release-Versionen zumeist bei der Performance der Trefferqualität Abstriche machen muss. Bedingt durch die rasche Etablierung von KI-gestützten Lösungsansätzen auch in der Finanzindustrie versuchen auf der anderen Seite Institute AFC-Lösungsbausteine selbst weiterzuentwickeln und meist als „Add-on“ an die bestehende Lösungslandschaft zu integrieren. Hier sind u.a. agentenbasierte Lösungsbausteine sowie GenAI-gestützte Dokumentengenerierung punktuell bereits im Einsatz.
Aus Sicht des BT 6 liegt bei Eigenentwicklungen ein besonderes Augenmerk auf dem Change-Management und der Testing-Umsetzung. Auch selbst entwickelte Lösungen benötigen Wartung und Weiterentwicklung, welche gesteuert und getestet werden müssen. Je nach Bank und deren IT-Prozessframework sind die Testing-Anforderungen unterschiedlich streng ausgelegt und können zu Lücken (auch in der Überprüfung) führen.
Ein Stolperstein in Bezug auf Eigenentwicklungen kann bei IDV-nahen Lösungen mittels MS Access und Excel (mit Scripten und anderen einfachen Programmieransätzen für die Logik) liegen. Solche Anwendungen müssen analog zu komplexen Softwareentwicklungsprojekten gemäß der IT-Vorgaben umgesetzt werden. Für den späteren Betrieb dieser „Light“-Lösungen muss zudem der Zugriffsschutz gewährleistet werden, Änderungs- oder sogar Überschreibemöglichkeiten der Dateien reguliert werden.
Ausblick
Nicht transparent ist, ob und wann die Aufsicht das Themengebiet aus den Auslegungshinweisen zum Thema Monitoring novelliert oder ob bzw. wie konkret auf europäischer Ebene technisch-prozessuale Anforderungen an die Institute bzw. die Systeme definiert werden. Nachschärfungen und Abstimmungen von Seiten der BaFin erfolgen in der Regel primär über das Institut der Wirtschaftsprüfer (IDW).
Da die Zuständigkeit für das Themenfeld Sanktionen nicht bei der BaFin, sondern bei der Bundesbank liegt, sind gegebenenfalls auch von dieser Seite weitere Konkretisierungen neben den bestehenden Veröffentlichungen wie dem Merkblatt zur Einhaltung von Finanzsanktionen (zuletzt aktualisiert 2024) zu erwarten oder sogar eine langfristige Konsolidierung der Zuständigkeiten und daraus folgenden Konsolidierungen der Anforderungen.
Insbesondere Anforderungen in Bezug auf das Spannungsfeld KI – GenAI im Geldwäscheumfeld und deren Umsetzung in IT-Systemen – könnte den verpflichteten Instituten zu mehr Klarheit verhelfen. Da der Fokus der AuA BT-Veröffentlichung(en) auf Kreditinstituten liegt, bleibt auch abzuwarten, ob gleichartige Anforderungen an Versicherungen und weitere Finanzmarktakteure mit Geldwäsche- und Sanktionsbezug gestellt werden.
Auch wenn die Einhaltung der Anforderungen aus den AuA BT 6 Zeit- und ressourcenintensiv für die Institute scheint: Sie helfen neben der Vermeidung von Feststellungen auch, das Fundament für eine dauerhaft hohe Qualität der Anti-Geldwäsche-, Sanktions- und Betrugsmechanismen sicherzustellen sowie langfristig robust auf neue Herausforderungen der Finanzkriminalität reagieren zu können.
Autoren:
Peter Schadt
Partner Deloitte / Financial Crime
Sebastian Hainzl
Senior Manager Deloitte / Financial Crime
| (Möchten Sie beim Thema Geldwäsche auf dem Laufenden bleiben? Dann können Sie sich hier für unseren Newsletter anmelden – kostenlos und unverbindlich) |
