AMLR definiert die Risikoanalyse neu: Fünf Stolpersteine der praktischen Umsetzung
Trotz klarer Zielrichtung der AMLR bereiten die neuen AMLR-Anforderungen an die AFC-Risikoanalyse in der Praxis Bauchschmerzen. Daten-Silos, Tool-Brüche (Excel), fehlende Audit-Trails, Jahresprojekt-Prozesse und unklare Ownership bremsen die Umsetzung ein.
Teil 2 unserer Blogserie zeigt die Praxis Hürden.
- 1. Daten: Der größte Hebel – und die größte Bremse
- 2. System: Excel wird zum De facto System – ohne System Eigenschaften
- 3. Prozess: Aus Steuerung wird ein Jahresprojekt (mit hohem manuellem Aufwand)
- 4. Methodik: Konzepte sind klar – die Operationalisierung scheitert
- 5. Governance & Ownership: Ohne klare Zuständigkeiten bleibt es ein Projekt — kein System
Im ersten Teil der Blogserie rund um die AFC-Risikoanalyse haben wir die Richtung der Bankenaufsicht klar aufgezeigt: Sie will kein besseres Dokument, sondern ein betreibbares, prüfbares System. Das wird insbesondere daran sichtbar, dass die unternehmensweite Risikobewertung dokumentiert, auf dem neuesten Stand gehalten und regelmäßig überprüft werden muss – und Aufsehern auf Anfrage bereitzustellen ist (vgl. Verordnung (EU) 2024/1624, Art. 10 Abs. 2).
Genau hier entstehen in vielen Instituten die Probleme: Man versteht die Zielsetzung – aber die Umsetzung im Alltag bereitet Sorgen. Dabei ist nicht die Regulierung das Problem, sondern die operative Abbildung in Daten, Organisation, Prozessen und (teilweise) Methodik.
Doch warum ist das so? Warum trifft es ausgerechnet die Risikoanalyse so häufig und so hart?
1. Daten: Der größte Hebel – und die größte Bremse
Eine AFC‑Risikoanalyse steht und fällt mit Daten. In der Praxis liegen die relevanten Informationen jedoch oft fragmentiert vor: Kundendaten, Produkt-/Kanalinformationen, länderspezifische Aspekte, Erkenntnisse aus Monitoring/Screening sowie Fallzahlen und Typologien verteilen sich über mehrere Systeme und Teams. Genau diese Muster – fragmentierte Datenquellen, inkonsistente Definitionen, fehlende Datenqualität und keine zentrale Risikodatenbasis – zählen zu den häufigsten Ursachen, warum Risikoanalysen in der Umsetzung instabil bleiben.
Die Folge ist tückisch: Bewertungen wirken auf den ersten Blick plausibel, sind aber nicht reproduzierbar. Es wird dann schwierig, belastbar zu erklären, welche Daten in welcher Version und mit welchen Annahmen in die Bewertung eingeflossen sind. Das kollidiert mit der regulatorischen Stoßrichtung: Risikoanalysen sollen nicht nur „begründbar“, sondern vergleichbar, nachvollziehbar und auditierbar sein – und sich in einem konsistenten Datenhaushalt bewegen.
2. System: Excel wird zum De‑facto‑System – ohne System‑Eigenschaften
Viele Häuser organisieren die Risikoanalyse faktisch über Dateien, Tabellen und manuelle Konsolidierung. Das funktioniert, solange Umfang und Änderungsdynamik gering bleiben. Sobald aber mehrere Beteiligte parallel an Skalen, Gewichtungen, Quellen und Textbausteinen arbeiten, entstehen typische Systemdefizite: Medienbrüche zwischen Analyse, Bewertung und Reporting, fehlende Versionierung, fehlender Audit‑Trail und damit eine begrenzte Prüf- und Erklärungstiefe.
Das Problem ist nicht „Excel an sich“, sondern der fehlende Nachweischarakter: Ohne Historisierung und Audit‑Logging lässt sich über Zeit nur eingeschränkt zeigen, was sich wann geändert hat – und warum. Genau diese Fähigkeit wird jedoch im Zielbild einer kontinuierlichen, prüfbaren Risikoanalyse zentral.
Zusätzlich fehlt in Excel‑basierten Setups oft eine robuste Handhabung für den laufenden Betrieb: Paralleles Arbeiten, eindeutige Freigaben/Reviews, Rollen‑ und Rechtekonzepte, Plausibilitätschecks sowie eine konsistente Datenführung müssen „drumherum“ organisiert werden. Das macht Lösungen fehleranfällig, intransparent und aufwändig zu verwalten – und erschwert die Revisionssicherheit.
Online-Seminar zur Risikoanalyse "AMLR Decoded – Was sich für die Risikoanalyse wirklich ändert"
In unserer Veranstaltung am 28. Mai um 11 Uhr zeigen wir, wie Banken regulatorische Anforderungen an die Risikoanalyse in eine praxistaugliche, softwaregestützte Umsetzung überführen.
3. Prozess: Aus Steuerung wird ein Jahresprojekt (mit hohem manuellem Aufwand)
Wenn Datenbasis und Systemunterstützung nicht tragen, rutscht die Risikoanalyse in vielen Instituten in ein Muster: Sie wird zum jährlichen Großprojekt mit hohem Abstimmungs- und Pflegeaufwand. Aktualisierungen entstehen dann selten „im laufenden Betrieb“, sondern als Sonderaufgaben – etwa bei neuen Produkten, geänderten Kundensegmenten, neuen geografischen Schwerpunkten oder relevanten externen Ereignissen.
Genau dadurch geht der eigentliche Nutzen verloren: Statt Steuerung entsteht häufig „Berichtsstress“ – und die Risikoanalyse liefert nur punktuell eine Momentaufnahme. Das steht im Widerspruch zur Erwartung, dass Risikoverständnis fortlaufend gepflegt werden muss: Die AMLR verlangt ausdrücklich Dokumentation, Aktualität, regelmäßige Überprüfung und die Bereitstellung gegenüber Aufsehern auf Anfrage. Auch internationale Standards betonen, dass ein belastbares Risikoverständnis dynamisch ist, neue Informationen kontinuierlich aufnehmen muss und als laufender Prozess betrieben werden sollte – nicht als punktuelle Pflichtübung.
4. Methodik: Konzepte sind klar – die Operationalisierung scheitert
Viele Institute verfügen konzeptionell über sinnvolle Bewertungsmodelle. In der praktischen Umsetzung entsteht jedoch häufig ein Bruch: Bewertungslogiken werden nicht durchgängig entlang konsistenter Datenpunkte, klarer Skalen und nachvollziehbarer Herleitungen operationalisiert.
Genau deshalb treiben europäische Stellen eine stärkere Harmonisierung voran: Die AMLA hat im Kontext von Art. 40(2) der AMLD6 Entwürfe für Regulatory Technical Standards (RTS) vorgelegt, die eine gemeinsame, risikobasierte Methodik für Aufseher definieren sollen – inklusive Klassifizierung inhärenter und residualer Risikoprofile sowie Vorgaben zur Überprüfungsfrequenz. Ziel ist ausdrücklich, heutige Fragmentierung und divergierende Bewertungsresultate zu reduzieren und eine vergleichbare, effizientere Aufsicht zu ermöglichen.
Für Institute ist die Stoßrichtung klar: Bewertungsansätze müssen so strukturiert sein, dass sie Risikotreiber (inhärentes Risiko = Bruttorisiko) und die Qualität/Wirksamkeit der Kontrollen sauber trennen – und daraus ein residuales Risiko (Nettorisiko) ableiten, das sich konsistent erklären lässt. Wo Trennung, Gewichtung und Aggregation nicht sauber im Prozess verankert sind, wirkt ein Scoring schnell wie eine „Black Box“ – und verliert damit an Erklärbarkeit, Vergleichbarkeit und Auditierbarkeit, insbesondere wenn Methodikänderungen oder neue Datenpunkte hinzukommen.
5. Governance & Ownership: Ohne klare Zuständigkeiten bleibt es ein Projekt — kein System
Selbst ein gutes methodisches Modell wird im Alltag nicht tragfähig, wenn Zuständigkeiten, Freigaben und Änderungen nicht sauber geregelt sind. Wie bereits an diversen Stellen erwähnt, macht die AMLR Governance-Erwartungen hier sehr konkret: Die unternehmensweite Risikobewertung muss dokumentiert, aktuell gehalten und regelmäßig überprüft werden und ist Aufsehern auf Anfrage bereitzustellen. Außerdem muss der Geldwäschebeauftragte sie erstellen und das Leitungsorgan sie billigen (vgl. Verordnung (EU) 2024/1624, Art. 10 Abs. 2).
Auch internationale Standards betonen, dass Risikoverständnis keine statische Momentaufnahme ist, sondern ein laufender, dynamischer Prozess, der sich an veränderte Umweltfaktoren anpassen und neue Informationen systematisch aufnehmen muss.
Praktisch bedeutet das: Ohne klare Rollen (wer liefert Daten, wer bewertet, wer reviewed, wer genehmigt?), ohne definierte Änderungslogik (wann wird neu bewertet?) und ohne nachvollziehbare Historie entsteht kein dauerhaft betriebenes System – sondern wiederkehrende Projektarbeit, die Aktualität und Auskunftsfähigkeit eher zufällig als verlässlich erreicht.
Abbildung: Kurzdiagnose: typische Symptome – und warum sie kritisch sind
Takeaway von Teil 2 der Blogserie
Die größte Hürde liegt selten im Verstehen der Anforderungen – sie liegt in der Übersetzung in Daten, System, Prozesse und Governance. Genau deshalb bereiten die neuen AMLR-Anforderungen rund um die AFC‑Risikoanalyse vielen Häusern Bauchschmerzen. Ein mögliches Scheitern ist dabei zumeist nicht konzeptionell, sondern operational.
Im nächsten Beitrag drehen wir die Perspektive: Wie sieht ein realistisches Zielbild aus – und welche Bausteine machen die Risikoanalyse kontinuierlich, datengetrieben und audit‑ready? Dabei zeigen wir auch, wo Softwarelösungen als Systemunterstützung den entscheidenden Unterschied machen: zentrale Risikodatenbasis, rollenbasierte Workflows, Versionierung/Audit‑Trail und „Report‑Readiness“ im laufenden Betrieb – statt manueller Konsolidierung und Stichtagsstress.



Sie müssen sich anmelden, um einen Kommentar zu schreiben.