Ich habe die vergangenen Jahre damit verbracht, Systeme für das Transaktionsmonitoring zu bauen und zu reparieren – für Banken, die täglich Millionen von Transaktionen verarbeiten. Über vier verschiedene Projekte hinweg bin ich immer wieder auf dieselbe Lehre gestoßen: AML-Software scheitert selten daran, dass die Regeln falsch sind. Sie scheitert daran, dass ein halbes Jahr später niemand mehr erklären kann, warum ein Alarm ausgelöst hat – genau dann, wenn die Aufsicht nachfragt.
Dieser Beitrag geht durch diese vier Systeme: was wir gebaut haben, was im Produktivbetrieb zerbrochen ist und was ich heute anders machen würde. Geldwäschebekämpfung steht dabei nie für sich allein. Sie ist ein Baustein der Softwareentwicklung für die Finanzbranche, die eine Bank am Laufen hält – vieles von dem, was folgt, gilt deshalb weit über AML hinaus. Wenn Sie als CTO oder Leiter Financial Crime über einen Neubau nachdenken, lesen Sie das hier als Praxisnotizen, nicht als Verkaufsbroschüre.
Was ist AML-Software?
Fangen wir bei den Grundlagen an, denn jedes dieser vier Projekte begann bei derselben Definition. Sie ist die Basis jeder Plattform zur Geldwäschebekämpfung: Die Software überwacht Finanztransaktionen in Echtzeit, markiert Muster, die auf Geldwäsche oder Betrug hindeuten – das ist dasselbe Mustererkennungsproblem, das hinter den meisten Lösungen zur Betrugserkennung für Finanzunternehmen steckt – und erzeugt die Unterlagen, die eine Bank für eine Verdachtsmeldung braucht. In den USA schreibt das der Bank Secrecy Act vor, in Deutschland das Geldwäschegesetz (GwG). Freiwillig ist das in keinem der beiden Rechtsräume.
Technisch betrachtet ist es eine Pipeline: Ingestion, Bewertung über Regeln oder Modelle, Fallbearbeitung – und darunter ein durchgehender Audit-Trail. Keines der vier Systeme, die ich gebaut habe, hatte Mühe mit dem offensichtlichen Teil, dem Erkennen auffälliger Transaktionen. Zerbrochen ist jedes Mal der Teil, für den niemand Budget einplant: eine Entscheidung Monate später zu rekonstruieren und zu verteidigen.
Dieser Kreislauf erklärt auch, warum reines Monitoring auf Transaktionsebene nicht ausreicht. Placement, Layering und Integration hinterlassen jeweils andere Spuren: Bargeldeinzahlungen, Kettenüberweisungen über Offshore-Strukturen, später der Kauf realer Vermögenswerte. Ein System, das nur die einzelne Buchung sieht, erkennt die mittlere Phase fast nie.
Die Architektur einer AML-Lösung beim ersten Mal richtig zu schneiden erspart Jahre an Nacharbeit. Lassen Sie uns über Ihr System sprechen, bevor Sie es bauen.
Mit unserem AML-Engineering-Team sprechen
Wie AML Transaction Monitoring tatsächlich funktioniert
Um zu sehen, wo das Rekonstruktionsproblem beginnt, lohnt sich der Weg einer einzelnen Transaktion. Sie trifft im Kernbankensystem ein, egal über welche Strecke der Zahlungsverkehr sie dorthin geroutet hat. Zunächst wird sie innerhalb von Millisekunden in eine Streaming-Pipeline aufgenommen, etwa Kafka – aus dem Kernbankensystem, von Kartennetzwerken oder aus aufgesetzten Embedded-Finance-Diensten, zusammen mit Kundenprofildaten aus der KYC-Software und dem bisherigen Verhalten.
Von dort geht es in die Bewertung: regelbasierte Prüfungen wie Structuring (ein Muster, das in Überweisungs-Apps ständig auftaucht), runde Beträge und schnelle Bewegungen zwischen Konten – parallel dazu statistische oder ML-Modelle, die auf Abweichungen vom normalen Kundenverhalten achten. Dazu kommt die Sanktionslistenprüfung, die Beteiligte gegen EU-, OFAC- und UN-Listen abgleicht; dieses AML-Screening läuft synchron mit, weil ein Treffer die Transaktion sofort stoppen muss.
Überschreitet die Transaktion einen Schwellenwert, bekommt sie nicht einfach einen Alarm. Sie bekommt einen Fall – jene Ebene, die oft getrennt als AML-Case-Management verkauft wird – mit jedem Eingangswert, der die Bewertung geformt hat. Eine Analystin prüft den Fall, und wenn er verdächtig bleibt, wird genau dieser Fall zum Rückgrat der Verdachtsmeldung. In Deutschland geht sie an die FIU, die Zentralstelle für Finanztransaktionsuntersuchungen, in den USA an FinCEN. Die gesamte Kette von der Transaktion bis zur Entscheidung muss auf unbestimmte Zeit rekonstruierbar bleiben. An dieser letzten Anforderung sind drei meiner vier Projekte irgendwann hängengeblieben.
Die vier Pflichten im Schaubild klingen nach Checkliste, verhalten sich im System aber sehr unterschiedlich. KYC und Bargeldmeldung sind weitgehend Stammdaten- und Schwellenwertthemen. AML Transaction Monitoring und Verdachtsmeldung dagegen sind Entscheidungen – und nur für Entscheidungen muss man sich später rechtfertigen.
Die hybride Alternative: Regeln, die man im Vorstand vorlesen kann
Beim dritten Neubau hatte ich aufgehört, hinter immer ausgefeilteren Modellen herzulaufen. Die Systeme, die Prüfungen überstanden, waren die, bei denen ein Geldwäschebeauftragter die zugrunde liegende Logik laut vorlesen konnte – und sie ergab aus sich heraus Sinn. Das wurde von da an die Entwurfsvorgabe: Jeder Alarm muss auf etwas Erklärbares zurückführbar sein, auch in den Teilen der Pipeline, in denen ein Modell mitspielt.
Warum dreimal mehr Alarme besser sind als eine niedrige False-Positive-Rate
Klingt verkehrt herum, aber mir ist ein lautes System, das ich verteidigen kann, lieber als ein leises, das ich nicht erklären kann. Wenn ein Prüfer fragt, warum ein Alarm ausgelöst hat – oder warum eben nicht –, ist „das Modell hat so entschieden“ keine Antwort, auf der sich etwas aufbauen lässt. Mehr Alarme an klaren Regeln verlangsamen die Triage, ja. Sie nehmen aber die Momente aus dem Prozess, in denen das eigene Team vor der Aufsicht über die eigene Logik rätselt.
Wo gezieltes Machine Learning seinen Platz hat
Nichts davon heißt, dass Machine Learning keine Rolle spielt. Es heißt nur, dass die Rolle eng bleibt. In diesen Projekten haben wir Machine Learning für konkrete Aufgaben eingesetzt: Entitätsauflösung über Konten hinweg, Clustering ähnlicher Typologien, Priorisierung von Fällen für die Analysten – nie als alleinigen Grund, aus dem ein Alarm entsteht. Halten Sie es auf die Unterstützung menschlicher Prüfung begrenzt statt als Ersatz für den Audit-Trail, dann gewinnt es Vertrauen, statt neue Fragen aufzuwerfen.
Die Frage vor jedem AML-Modernisierungsprojekt
Bei diesem dritten Neubau habe ich angefangen, jedes neue Projekt mit derselben Frage zu eröffnen – und das ist die Frage, die ich jedem mitgeben würde, der das hier liest: Können Sie diesen Alarm in zwei Jahren einem Prüfer erklären, allein mit dem, was das System gespeichert hat? Die meisten Teams können das nicht bejahen. Und genau diese Lücke ist das eigentliche Risiko – nicht die Treffergenauigkeit, nicht das Alarmvolumen, nicht die Modellgüte.
Modernisierungsprojekte beginnen gern beim spannenden Teil: bessere Bewertung, schnellere Ingestion, klügeres Clustering. Diese Bausteine sind wichtig, aber dort gehen Prüfungen selten schief. Prüfungen gehen in dem Raum schief, der zwischen „das System hat das markiert“ und „hier ist genau warum, mit jedem erhaltenen Eingangswert“ liegt. Wer diese Frage am Anfang überspringt, poliert am Ende den Teil des Systems, der nie das eigentliche Risiko war.
Für den europäischen Raum kommt hinzu, dass sich der Rahmen gerade verschiebt: Mit dem EU-Geldwäschepaket und der neuen Aufsichtsbehörde AMLA werden Anforderungen an Dokumentation und Nachvollziehbarkeit eher strenger als lockerer. Ein System, das heute schon jede Entscheidung belegen kann, muss dafür nicht umgebaut werden.
«AML ist schwierig, weil das Scheitern nicht technischer Natur ist. Sie fangen nicht nur auffällige Transaktionen ab – Sie verteidigen Monate später Ihre Begründung gegenüber jemandem, der nicht dabei war. Bei Elinext bauen wir den Audit-Trail, bevor wir die Bewertungslogik anfassen, damit jeder Alarm seinen Beleg vom ersten Tag an mitbringt. Der eigentliche Gewinn ist nicht eine niedrigere False-Positive-Quote. Es ist eine Prüfungssaison, in der Ihr Team Stunden mit dem Zusammentragen von Belegen verbringt – und nicht Wochen.»
— Anastasia Timoshenko, Leiterin FinTech-Lösungen bei Elinext
Das Wichtigste in Kürze
Fasst man diese vier Neubauten zusammen, bleiben dieselben fünf Lehren:
- Nachvollziehbarkeit schlägt Raffinesse. Ein Modell, das sich nicht in klarer Sprache rechtfertigen kann, fällt zur Prüfungszeit durch, egal wie gut es in Tests abschneidet. Entwerfen Sie zuerst für Rekonstruktion, dann für Erkennung – diese Reihenfolge wiegt schwerer, als die meisten Neubauten anfangs zugeben.
- Mehr Alarme sind nicht der Feind. Ein lauteres System auf Regeln, die Sie verteidigen können, schlägt ein leises, das Sie nicht erklären können. Triage-Last ist ein Personalproblem, ein unerklärbarer Alarm ein regulatorisches.
- Halten Sie ML eng begrenzt. Nutzen Sie es für Entitätsauflösung, Clustering und Fallpriorisierung – nicht als alleinigen Auslöser eines Alarms. Machine Learning soll das Urteil der Analysten stützen, nicht die Belegkette ersetzen, nach der Prüfer früher oder später fragen.
- Der Audit-Trail ist Architektur, kein Nachgedanke. Jede Bewertung, jeder Eingangswert und jeder Schwellenwert muss dauerhaft gespeichert und abrufbar sein. Das nachträglich einzubauen kostet mehr, als es von Anfang an in die Pipeline zu legen.
- Stellen Sie die unbequeme Frage früh. Vergewissern Sie sich vor dem Start, dass das System jeden Alarm Jahre später allein aus dem Gespeicherten erklären kann. Diese Frage sagt mehr über den Erfolg des Neubaus aus als jede Modellkennzahl.
Fazit
Vier Systeme, vier verschiedene Bruchstellen – und doch jedes Mal dieselbe Ursache: Wir haben für Erkennung gebaut und Nachvollziehbarkeit als Dokumentationsaufgabe behandelt statt als Architekturentscheidung. Das ist verkehrt herum. Die Banken, die Prüfungen reibungslos bestehen, fahren keine klügeren Modelle. Sie fahren Systeme, in denen sich jeder Alarm bis zu seinem Beleg zurückverfolgen lässt, ohne dass jemand hektisch suchen muss.
Wenn Sie einen Neubau planen, fangen Sie nicht bei der Bewertungslogik an. Fangen Sie bei der Frage an, die Prüfer in zwei Jahren stellen werden, und bauen Sie von dort rückwärts. Das ist der eigentliche Prüfstein jedes Projekts zur AML-Software-Entwicklung. Alles andere – Regeln, ML, Fallbearbeitung – sollte dieser Antwort dienen und nicht umgekehrt.
Wer zunächst einen Überblick über Funktionsumfang und Entwicklungsschritte sucht, findet ihn in unserem Leitfaden zu AML-Software. Dieser Beitrag setzt eine Ebene darüber an: bei den Architekturentscheidungen, die darüber bestimmen, ob das fertige System eine Prüfung übersteht.
AML-Systeme neu zu bauen ist unser Tagesgeschäft. Wir tauschen uns gern über Ihres aus.
Mit unserem AML-Engineering-Team sprechen
Häufige Fragen
Was ist AML-Software?
Es ist das System, das Transaktionen in Echtzeit überwacht, auffällige Muster markiert und die Fallakten erzeugt, die Banken gegenüber der Aufsicht brauchen. Erkennung plus Dokumentation – nicht das eine ohne das andere.
Wofür steht AML in der Softwareentwicklung?
Für Anti-Money Laundering, also Geldwäschebekämpfung. In der Praxis umfasst der Begriff jedes System, das Finanzaktivitäten erkennt, dokumentiert und meldet, hinter denen Geldwäsche, Betrug oder Sanktionsverstöße stehen könnten.
Welche Werkzeuge kommen bei AML zum Einsatz?
Streaming-Pipelines wie Kafka, Regel-Engines, Plattformen für die Fallbearbeitung und mitunter ML-Modelle für Clustering oder Entitätsauflösung. Der konkrete Stack ist weniger entscheidend als die Frage, wie prüffest das Zusammenspiel bleibt.
Wie erkennt AML Transaction Monitoring verdächtige Aktivitäten?
Es bewertet Transaktionen gegen Regeln – etwa Structuring oder schnelle Bewegungen – und gegen Verhaltensbasislinien. Überschreitet die Bewertung einen Schwellenwert, öffnet das System einen Fall, an dem jeder beitragende Eingangswert für die Prüfung hängt.
Was ist eine Verdachtsmeldung?
Die Verdachtsmeldung ist die förmliche Meldung, die ein Institut abgibt, wenn eine Transaktion auf Geldwäsche oder andere Finanzkriminalität hindeuten könnte. In Deutschland geht sie an die FIU und ist nach dem Geldwäschegesetz verpflichtend; das US-Pendant ist der Suspicious Activity Report an FinCEN.
Sollte AML-Software auf Regeln oder auf Machine Learning setzen?
Auf beides, aber nicht gleichgewichtig. Die Entscheidung über einen Alarm sollten Regeln tragen, weil sie erklärbar sind. Machine Learning wirkt am besten in unterstützender Rolle – Priorisierung, Clustering – und nicht als alleiniger Auslöser.
Welche AML-Compliance-Software ist die wirksamste?
Darauf gibt es keine einzelne Antwort: Es hängt vom Transaktionsvolumen, der bestehenden Infrastruktur und der Risikoneigung ab. Am wirksamsten sind die Systeme, die um Nachvollziehbarkeit herum gebaut sind und nicht allein um Treffergenauigkeit.
Wie lange dauert die AML-Software-Entwicklung für eine Bank?
Für ein mittelgroßes Institut dauert ein vollständiger Neubau typischerweise 12 bis 18 Monate – abhängig davon, wie komplex die Altsysteme sind und wie viel vom Audit-Trail von Grund auf entstehen muss.
