Am Tag der VASP-Prüfung muss das Compliance-Programm Aufzeichnungen statt Versprechen liefern. Eine aufsichtsrechtliche Prüfung zwingt den Anbieter von Dienstleistungen für virtuelle Vermögenswerte, auf Anfrage die tatsächlich laufende Transaktionsüberwachung zu belegen. Der Prüfer will kein Richtliniendokument lesen. Er will einem konkreten Alarm von der Erkennung bis zur Bearbeitungsentscheidung folgen und die Aufzeichnung jedes Schritts bestätigen. Bei automatisierten Entscheidungen folgt eine weitere Frage: Ob Compliance-Alarme automatisch geschlossen werden dürfen, hängt davon ab, was die Automatisierung belegen kann. Fehlt diese Spur, liegt eine Programmlücke vor, unabhängig von der Güte der Screening-Engine. Dieser Leitfaden behandelt die Anforderungen nach dem risikobasierten FATF-Ansatz: prüfbereite Audit-Trails, erklärbare Scores ohne Black Box, vollständige STR-Aufzeichnungen und eine Probeprüfung. Den übergeordneten Workflow hinter diesen Aufzeichnungen beschreibt Phalcon Compliance. Diese Seite ist Teil des KYT-Wissensportals.
Was Prüfer nach dem risikobasierten FATF-Ansatz anfordern
Der Prüfrahmen ist der risikobasierte Ansatz der FATF für Anbieter von Dienstleistungen für virtuelle Vermögenswerte, verankert in Empfehlung 1. Empfehlung 1 verpflichtet VASPs, Geldwäsche- und Terrorismusfinanzierungsrisiken zu identifizieren, zu bewerten und zu verstehen sowie angemessene Kontrollen anzuwenden. Daraus ergeben sich drei prüfbare Elemente: laufende Überwachung, Erkennung verdächtiger Transaktionen und prüfbare Aufzeichnungen. KYT als Onchain-Transaktionsrisikoüberwachung fällt unter die ersten beiden. Es beobachtet jede Einzahlung, Auszahlung und Gegenparteiexposition, bewertet das Risiko und erzeugt Alarme für den Verdachtsmeldeprozess.
Wichtig ist die Abgrenzung: FATF-Empfehlung 16, die Travel Rule, betrifft separat die Übermittlung von Angaben zu Auftraggeber und Begünstigtem zwischen VASPs. KYT erfüllt diese Pflicht nicht. KYT erfüllt die Überwachungsseite der Empfehlungen 10 und 11: überwachen, erkennen und beides durch Aufzeichnungen belegen.
In der Praxis verlangen Prüfer die Risikobewertung hinter dem Überwachungsumfang, eine Stichprobe von Alarmen mit Untersuchungen sowie eingereichte Verdachtsmeldungen und deren Unterlagen. Hinzu kommt der verbindende Audit-Trail. Er macht aus Alarm, Untersuchung, Entscheidung und Meldung eine durchgehende Aufzeichnung. Wer etwas davon erst auf Anfrage rekonstruieren muss, hat die Prüfung bereits nicht bestanden. Die Rekonstruktion selbst belegt, dass die Aufzeichnungen vorher nicht geführt wurden.
Den Audit-Trail vor der Prüferanfrage aufbauen
Ein Audit-Trail macht aus einem Screening-Programm ein belastbares Programm. Prüfungserfahrene Compliance-Verantwortliche formulieren den Maßstab direkt: Vollständige Audit-Trails entscheiden zwischen beanstandungsfreier Prüfung und Mängelschreiben. Fehlender Audit-Trail bedeutet für Prüfer fehlende Kontrolle, weil es keine andere Lesart gibt. Eine ausgeführte, aber nicht aufgezeichnete Kontrolle unterscheidet sich aus ihrer Sicht nicht von einer nie ausgeführten.
Ein belastbarer Audit-Trail für Onchain-Überwachung hat drei Ebenen, die bereits vor Prüfungsbeginn vorhanden sein müssen. Erstens der Alarmverlauf: welches Screening auf welcher Adresse oder Transaktion zu welchem Zeitpunkt den Alarm ausgelöst hat und welche Risikoindikatoren den Score bestimmten. Zweitens der Untersuchungsverlauf: wer den Fall übernahm, welche Geldflussspuren verfolgt, welche Expositionswerte beobachtet und welche Schlussfolgerungen gezogen wurden. Drittens der Entscheidungsverlauf: wer Schlussfolgerung und Entscheidung prüfte oder freigab, was wann und auf welcher Grundlage gemeldet oder geschlossen wurde.
Phalcon Compliance erzeugt alle drei über Audit Trails, Audit Logs und Risk Engine Details, jeweils exportierbar als PDF oder CSV. Audit Trail erfasst die Folge der Untersuchungshandlungen. Audit Logs ordnen Handlungen Personen und Zeitpunkten zu. Risk Engine Details dokumentieren die auslösenden Indikatoren und deren Score-Berechnung und machen das Scoring verständlich statt undurchsichtig. Gemeinsam liefern sie eine lückenlose Aufzeichnung vom Alarm bis zur Bearbeitungsentscheidung. Sie begleiten die Fallakte, damit Beleg- und Audit-Paket nicht auseinanderlaufen.
Der praktische Bereitschaftstest lautet: Kann ein zweiter Analyst oder Prüfer die Entscheidung allein aus den Aufzeichnungen rekonstruieren? Braucht es die Erinnerung des ursprünglichen Analysten, ist der Audit-Trail unvollständig.
Risikoscores ohne Black Box gegenüber der Aufsicht erklären
Prüfer akzeptieren einen Risikoscore nicht ungeprüft. Eine Zahl ohne Erklärung ist eine Black Box und damit eine Kontrolle, die das Institut nicht begründen kann. Prüfungserfahrene Compliance-Verantwortliche benennen das Kernproblem direkt: Die Fähigkeit zu erklären, warum eine Transaktion markiert und so behandelt wurde, löst Prüfungsfragen. Ein nicht zerlegbarer Score ist in der Prüfung eine Belastung, kein Vorteil.
Die Unterscheidung zwischen transparentem Modell und Black Box ist deshalb nicht nur eine Produkt-, sondern eine Prüfungsfrage. Eine Engine mit bloßem Score zwingt das Team, ein Urteil ohne sichtbare Herleitung zu verteidigen. Eine Engine mit Score und konkreten Indikatoren erlaubt es, dem Prüfer den Entscheidungsweg in denselben Begriffen wie die Engine zu zeigen. Ersteres macht die Prüfung zum Streit, Letzteres zur Nachprüfung.
Phalcon Compliance nutzt ein transparentes Modell mit 17 Risikoindikator-Kategorien. Jeder Score enthält die konkreten auslösenden Indikatoren. Er ist ein vom Team aufschlüsselbares Gesamtergebnis statt eines von oben gelieferten Urteils. Auf die Frage nach einer Hochrisiko-Markierung gibt es drei Antwortteile: benannte Indikatoren, ihre Onchain-Belege und die zum Score führende Gewichtung. Das macht das Scoring belastbar: Die Aufsicht sieht dieselben Eingaben wie der Analyst, erreicht dieselbe Schlussfolgerung und kann fortfahren.
Dieselbe Verständlichkeit gilt umgekehrt. Bei der Frage nach einer Freigabe muss das Team zeigen, welche Indikatoren nicht ausgelöst wurden und warum das eine niedrige Risikobewertung stützte. Ein transparentes Modell beantwortet dies direkt. Eine Black Box antwortet gar nicht. Aus dieser Lücke wird ein Prüfungsbefund.
SAR- und STR-Aufzeichnungen vollständig halten
Eine Verdachtsmeldung gehört zu den früh angeforderten Dokumenten. Sie zeigt Überwachung, Untersuchung und Analystenentscheidungen an einer Stelle. Die Meldung selbst ist aber nur die halbe Aufzeichnung. Die andere Hälfte ist die Fallakte dahinter: Ausgangsalarm, Onchain-Sachverhalt, Expositionswerte, Risikoindikatoren, Prüf- und Freigabekette sowie der verbindende Audit-Trail. Ein STR oder SAR ohne diese Grundlage lässt sich nicht begründen. Der Prüfer kann nicht bestätigen, dass eine echte Untersuchung statt reflexhafter Vorlagenbefüllung zugrunde lag.
FATF-Empfehlung 20 legt die Verdachtsmeldepflicht fest und verbindet sie mit der Aufzeichnungspflicht aus Empfehlung 11. In den USA ist es der SAR an FinCEN nach den Vorschriften zur Meldung verdächtiger Aktivitäten (31 CFR 1022.320). Die Aufzeichnungen müssen vor der Prüfung existieren, nicht erst als Reaktion entstehen.
Die Plattform unterstützt STR-Erstellung ab Essential. Fallakte, Audit-Trail und STR-Export entstehen damit in derselben Umgebung. Alarm, Untersuchung, Bearbeitungsentscheidung, Audit-Trail und Meldung liegen in einer gemeinsam exportierbaren Aufzeichnung. Auf die Anforderung von Unterlagen zu einer Meldestichprobe folgt ein Export pro Fall statt einer Rekonstruktion über getrennte Tools.
Aufbewahrung ist ebenso wichtig wie Erstellung. FinCEN erwartet fünf Jahre Aufbewahrung für SAR-Unterlagen; FATF-orientierte Rechtsräume setzen vergleichbare Fristen. Ein prüfbereites Programm hält die vollständige Fallakte statt nur der Meldung während der gesamten Frist abruf- und exportierbar.
Häufige Prüfungsbefunde und ihre Vermeidung
Prüfungsbefunde in Krypto-Compliance häufen sich bei wenigen Fehlermustern. Meist geht es um dieselbe Ursache: eine nicht dokumentierte ausgeführte Kontrolle oder eine nicht exportierbare Aufzeichnung.
Erstens eine Überwachungslücke, bei der zwischen Prüfungen Gelder bewegt werden konnten. Echtzeitprüfung jeder Ein- und Auszahlung statt periodischer Batches schließt dieses Fenster. Der Audit-Trail muss die tatsächlich im laufenden Fluss ausgeführte Prüfung belegen.
Zweitens eine unerklärte Bearbeitungsentscheidung: Das Institut schloss oder eskalierte einen Alarm ohne dokumentierten Grund. Ein transparentes Modell mit benannten Indikatoren verhindert dies. Die Gründe werden zum Entscheidungszeitpunkt in Risk Engine Details festgehalten, nicht aus der Erinnerung rekonstruiert.
Drittens ein STR oder SAR ohne unterstützende Unterlagen. Die Meldung existiert, die Fallakte ist auf Anfrage nicht verfügbar. Die gemeinsame Erstellung von STR und Audit-Trail verhindert ihre Trennung.
Viertens ein Aufbewahrungsfehler: Aufzeichnungen existierten, wurden aber gelöscht, waren nicht mehr über das Tool zugänglich oder konnten nicht in einem für Prüfer lesbaren Format exportiert werden. PDF- und CSV-Export aus einer Umgebung machen den Datensatz portabel und unabhängig von einer laufenden Lizenz abrufbar.
Alle vier vermeidet dieselbe Disziplin: Aufzeichnungen im Handlungszeitpunkt in portablem Format erzeugen und dem Fall beifügen.
Checkliste zur Probeprüfung: Vor der Aufsicht selbst durchführen
Eine Probeprüfung ist der günstigste Weg, Lücken vor der Aufsicht zu finden. Das Institut muss dabei leisten, was die echte Prüfung verlangt: Für Stichproben von Alarmen und Meldungen auf Anfrage die vollständige Aufzeichnung vorlegen. Die folgende Checkliste nennt die Unterlagen je Fall.
Audit-Trail je Fall. Exportieren Sie zu jedem Stichprobenalarm Audit Trail, Audit Logs und Risk Engine Details gemeinsam. Ein nicht beteiligter Prüfer muss die Entscheidung allein aus dem Export rekonstruieren können.
Risikoscore-Erklärung je Fall. Zeigen Sie je Bearbeitungsentscheidung die benannten auslösenden Indikatoren, ihre Onchain-Belege und die kombinierende Gewichtung. Die Erklärung muss sowohl Markierung als auch Freigabe begründen.
Vollständige STR- oder SAR-Unterlagen je Meldung. Stellen Sie Fallakte, Onchain-Sachverhalt, Expositionswerte, Prüf- und Freigabekette sowie Audit-Trail bereit. Meldung und Grundlage müssen ein Paket bilden.
Entscheidungsbegründung je Fall. Legen Sie bei Abschluss oder Eskalation die zum Entscheidungszeitpunkt dokumentierte Begründung vor. Sie darf nicht nachträglich rekonstruiert sein.
Nachweis der Überwachungsabdeckung. Belegen Sie Screening im laufenden Ein- und Auszahlungsfluss statt nur nach periodischem Zeitplan, ohne Fenster zwischen den Prüfungen. Die Zeitstempel müssen kontinuierliche Überwachung stützen.
Aufbewahrung und Abruf. Bestätigen Sie für Meldungen über die gesamte Aufbewahrungsfrist die Abrufbarkeit und den PDF- oder CSV-Export der vollständigen Fallakte. Dies muss auf Anfrage und unabhängig von einer aktiven Sitzung oder abgelaufenen Tool-Lizenz möglich sein.
Ein Programm, das alle sechs Punkte für jeden Stichprobenfall liefert, ist prüfbereit. Andernfalls hat die Probeprüfung genau den künftigen echten Befund gefunden. KYT erfüllt die laufende Überwachungsseite aus FATF-Empfehlung 10. Audit-Trail, Score-Erklärung und STR-Aufzeichnung erfüllen die Aufzeichnungsseite aus Empfehlung 11. Erfahren Sie, wie Phalcon Compliance Audit-Trail und 17 Risikoindikator-Kategorien in einer Aufzeichnung vereint – für die Prüfung, die Ihrem Programm bevorsteht.