Das Narrativ einer Verdachtsmeldung (Suspicious Activity Report, SAR) ist ein juristisches Dokument, das Strafverfolgungsbehörden lesen und noch Jahre später per Vorladung anfordern können. Das sichere Vorgehen ist eng gefasst: Ein Ermittler trägt die Nachweise zusammen und validiert sie, entscheidet, dass der Fall meldepflichtig ist, und erst dann verfasst das Modell den Fließtext, verankert in genau diesen Nachweisen. Ein Mensch prüft und unterschreibt. Das Modell reicht niemals ein und behauptet niemals einen nicht nachvollziehbaren Fakt.
Ein Großteil eines SAR-Narrativs ist Nacherzählung. Wenn das Verfassen beginnt, hat ein Ermittler bereits festgestellt, dass die Aktivität meldepflichtig ist. Das Narrativ erklärt lediglich in klarem Fließtext, was passiert ist, wer beteiligt war und warum es verdächtig aussah. Genau deshalb passt ein LLM hierher: Die eigentliche Bewertung ist erledigt, und was bleibt, ist diszipliniertes Schreiben über einen festen Satz von Fakten.
Der Fehlermodus, auf den es hier ankommt, ist ein selbstbewusster Satz, der eine falsche Zahl transportiert. Ein holpriger Satz wird in der Prüfung korrigiert. Ein flüssiger Satz jedoch, der behauptet, ein Kunde habe 48.000 USD an drei Gegenparteien überwiesen, während das Transaktionsprotokoll 84.000 USD an zwei ausweist, kann an einem müden Prüfer vorbeirutschen und in einer bundesbehördlichen Meldung landen. Kein noch so eleganter Text repariert das. Deshalb zielt das gesamte Design auf ein einziges Ziel: niemals einen ungeprüften Fakt in den Entwurf gelangen lassen.
Jeden Satz in Nachweisen verankern
Das Narrativ wird aus einem strukturierten Nachweisset erzeugt, nicht aus dem Gedächtnis des Modells über den Fall. Vor der Generierung wird die Akte des Ermittlers in einzelne Objekte aufgelöst: Transaktionen mit Beträgen und Valutadaten, Gegenpartei-Entitäten nach der Entity Resolution, KYC-Attribute, frühere SARs zum selben Subjekt sowie der Alert oder die Alerts, die den Fall eröffnet haben. Jedes Objekt trägt eine stabile Kennung.
Das Modell erhält diese Objekte und schreibt das Narrativ mit Bezug auf sie. Anschließend führen wir eine Grounding-Prüfung durch, die strenger ist als die Generierung selbst:
- Jeder Geldbetrag, jedes Datum, jede Kontonummer und jede benannte Entität im Entwurf muss mit einem Wert im Nachweisset übereinstimmen. Zahlen werden nach Normalisierung verglichen, nicht als Zeichenketten, sodass “48.000,00 USD” und “48000” abgeglichen werden.
- Jede Tatsachenbehauptung wird auf mindestens eine Nachweiskennung abgebildet. Sätze, die etwas ohne stützendes Objekt behaupten, werden markiert und entfernt, bevor ein Mensch den Entwurf sieht.
- Ein vollständiges Narrativ deckt fünf Elemente ab: wer, was, wann, wo und warum die Aktivität verdächtig ist. Die Prüfung bestätigt, dass jedes davon vorhanden ist. Ein Entwurf, dem das “Warum” fehlt, ist unvollständig, so gut er sich auch liest.
Das ist dieselbe Disziplin, die man schon anwendet, wenn man Kennzahlen überhaupt erst aus Quelldokumenten extrahiert. Die Extraktion muss zeitpunktgenau korrekt sein, und sie muss ihre Herkunft (Lineage) mitführen. Wurde das Transaktionsprotokoll nach Auslösen des Alerts geändert, sollte das Narrativ den Stand der Nachweise zum Meldezeitpunkt widerspiegeln, und man sollte belegen können, welchen Snapshot man verwendet hat. Wenn später korrigierte Daten in ein Narrativ einsickern, das einen früheren Zeitraum beschreibt, ist das ein stiller Weg, etwas Falsches zu melden.
Das Modell aus der Meldeentscheidung heraushalten
Es besteht eine starke Versuchung, das System entscheiden zu lassen, ob ein Fall eine SAR rechtfertigt. Widerstehen Sie ihr. Die Entscheidung über die Meldepflicht hat unter dem Bank Secrecy Act rechtliches Gewicht und gehört in die Hände eines geschulten Ermittlers. Das LLM kommt erst danach ins Spiel, als Werkzeug zum Verfassen.
Praktisch bedeutet das: Die Pipeline hat ein hartes Gate. Ein Fall erreicht die Narrativ-Generierung erst, nachdem ein Ermittler ihn als meldepflichtig dispositioniert und das Nachweisset gesperrt hat. Die Ausgabe des Modells ist immer ein Entwurf in einer Prüf-Queue, niemals eine Einreichung. Straight-through processing ist der richtige Anspruch für risikoärmere Automatisierung wie die Alert-Triage, aber hier ist es der falsche Anspruch. Zielen Sie auf einen guten ersten Entwurf, der die Prüfung verkürzt, und halten Sie den Prüferplatz besetzt.
Structured Output hilft, dies durchzusetzen. Statt Freitext liefert das Modell das Narrativ als Abschnitte mit den zugehörigen stützenden Nachweiskennungen zurück, sodass der Prüfer jede Behauptung neben dem sieht, was sie belegt. Der Prüfer bearbeitet direkt im Text, und jede Bearbeitung wird erfasst. Ändert jemand “48.000 USD” in “84.000 USD”, halten Sie fest, wer es geändert hat, wann und gegen welches Nachweisobjekt, denn diese Bearbeitung ist nun Teil davon, wie das Institut entschieden hat, was es meldet.
Den Audit-Trail bauen, bevor Sie den Prompt bauen
Aufsichtsbehörden benoten keinen Prosastil. Sie verlangen, dass Sie Entscheidungen rekonstruieren. Deshalb verdient das Logging-Schema mindestens so viel Aufmerksamkeit wie die Generierungslogik, und es sollte existieren, bevor der erste Prompt geschrieben wird.
Für jedes verfasste Narrativ persistieren Sie:
- Das exakte an das Modell übergebene Nachweisset, mit Kennungen und den Snapshot-Zeitstempeln jeder Quelle.
- Die Version der Prompt-Vorlage und die Modellversion, damit ein im März verfasster Entwurf auch dann noch erklärbar ist, wenn sich beide geändert haben.
- Den rohen erzeugten Entwurf, die Ergebnisse der Grounding-Prüfung, jede Bearbeitung durch den Prüfer mit Autor und Zeitstempel sowie den final eingereichten Text.
Modellversionen und Prompt-Vorlagen driften. Wenn ein Anbieter ein Modell aktualisiert oder Sie eine Vorlage überarbeiten, verschieben sich Stil und Verhalten des Narrativs, und Sie müssen wissen, welche Version eine Meldung erzeugt hat, die später überprüft wird. Behandeln Sie die Prompt-Vorlage wie versionierten Code und pinnen Sie das Modell. Lassen Sie nicht zu, dass “latest” stillschweigend verändert, wie Ihre Meldungen von einem Quartal zum nächsten aussehen.
Die Evaluierung ergibt sich aus denselben Aufzeichnungen. Bauen Sie ein Eval-Set aus vergangenen Fällen, bei denen das eingereichte Narrativ bekannt ist, und messen Sie neue Entwürfe daran: gefangene Grounding-Fehler, Beträge und Daten, die sich gegen die Nachweise abgleichen lassen, Abdeckung der fünf Elemente sowie wie stark Prüfer vor dem Unterschreiben nachbearbeiten. Die Editierdistanz ist ein nützlicher Näherungswert für die Entwurfsqualität über die Zeit. Beginnen Prüfer, mehr umzuschreiben, ist irgendwo weiter oben etwas gedriftet, sei es die Nachweisauflösung, die Vorlage oder das Modell, und das Eval-Set sagt es Ihnen, bevor es eine Aufsichtsbehörde tut.
Nichts davon macht das Narrativ in einem rechtlich relevanten Sinne “KI-geschrieben”. Ein Mensch prüft es, ein Mensch unterschreibt es, und ein Mensch trägt die Verantwortung dafür. Das Modell stellt einen belegten ersten Entwurf zusammen und legt seine Arbeit offen. Das ist die Aufgabe, und sie ist eine echte.
Häufige Fragen
Kann ein LLM eine Verdachtsmeldung automatisch einreichen?
Nein. Das Modell verfasst das Narrativ aus Nachweisen, die ein Ermittler bereits zusammengetragen hat, und ein Mensch prüft und unterschreibt, bevor irgendetwas die FinCEN erreicht. Die Meldeentscheidung bleibt bei einem Menschen.
Wie verhindert ihr, dass das Modell Fakten in einem Narrativ erfindet?
Jeder Satz ist an einem abgerufenen Nachweisobjekt mit Kennung verankert, und eine nachgelagerte Prüfung verwirft jede Behauptung, jeden Betrag und jedes Datum, das sich nicht auf eine Quelle zurückführen lässt. Unbelegte Entwürfe erreichen den Prüfer nie.
Was muss der Audit-Trail enthalten?
Das an das Modell übergebene Nachweisset, den Prompt und die Modellversion, den erzeugten Entwurf, jede Bearbeitung durch den Prüfer und den final eingereichten Text. Man will exakt rekonstruieren können, warum jeder einzelne Satz geschrieben wurde.