So integrieren Sie goAML in AML-Screening und Fallmanagement

Ein Alarm ist noch keine Meldung. Dazwischen liegen Untersuchung, Nachweise, Verdachtsbewertung, eine autorisierte Meldeentscheidung, die Vorbereitung der Meldung und eine länderspezifische technische Übergabe. Eine verlässliche goAML-Integration verbindet diese Schritte, ohne sie als ein und dieselbe Kontrolle darzustellen.

Der Praxistest ist einfach: Kann Ihr Team ein Signal von der Erkennung über Untersuchung und Entscheidung bis zur Übermittlung an die FIU lückenlos nachvollziehen und den Übermittlungsnachweis aufbewahren, ohne den Vorgang nachträglich aus voneinander getrennten Systemen rekonstruieren zu müssen?

Die Rolle von goAML im AML-Betriebsmodell

UNODC beschreibt goAML als Plattform, die Financial Intelligence Units (FIUs) bei der Erfassung, Analyse und Weitergabe von Finanzinformationen zu verdächtigen Aktivitäten unterstützt.¹ Die Produktübersicht nennt ein Portal für Verpflichtete, Validierungsfunktionen und die Interoperabilität mit anderen Systemen.²

Dies beschreibt den globalen Produktkontext, nicht einen universellen Meldeprozess. Die FIU, die eine nationale Implementierung betreibt, legt verfügbare Meldearten, Felder, Übermittlungswege, Berechtigungen und Verfahren fest. Andere Rechtsordnungen nutzen wiederum ganz andere Meldesysteme. Die FATF setzt internationale Standards, die Staaten über eigene rechtliche, administrative und operative Rahmenwerke umsetzen.³

Für einen Verpflichteten ist goAML daher dem übergreifenden AML-Compliance-Betriebsmodell nachgelagert:

Geschäfts- oder Kontrollsignal → Alarm → Fall und Untersuchung → Verdachts- oder Meldepflichtbewertung → autorisierte Meldeentscheidung → Meldungsvorbereitung → FIU-spezifische Übermittlung → FIU-Antwort oder -Bestätigung → aufbewahrter Nachweis

Die Abfolge kann mit Transaktionsmonitoring, Transaktionsscreening, laufendem Monitoring, einem Sanktions- oder PEP-Alarm, einer internen Meldung oder einer anderen Quelle beginnen. Keiner dieser Auslöser begründet automatisch einen Verdacht oder eine universelle Meldepflicht.

Erkennung, Entscheidung und Meldung nicht vermischen

Die zentrale Anforderung an das Design lautet, jedem Kontrollstatus eine eigene Zuständigkeit, Nachweisführung und ein eigenes Ergebnis zu geben.

Diese Trennung verhindert, dass aus einem automatisierten Alarm eine automatisierte Verdachtsentscheidung wird. Ebenso verhindert sie, dass eine technisch gültige Datei als genehmigte oder angenommene Meldung dargestellt wird. Die Meldeentscheidung und Nachweisführung des MLRO bleiben eine von Menschen gesteuerte Verantwortung nach dem geltenden Rahmen und dem Berechtigungsmodell der Organisation.

Mit einem kontrollierten Fall beginnen, nicht mit einem Meldeformular

Bevor Sie Feldzuordnungen entwerfen, muss die vorgelagerte Untersuchung reproduzierbar sein. Der Fall sollte den Alarm mit dem richtigen Kunden, dem richtigen Konto, der richtigen Transaktion und den beteiligten Parteien verknüpfen, die Zuständigkeit erkennen lassen, Notizen, Anhänge und Quellenmaterial sichern sowie Anfragen, Feststellungen, Prüfungen und Entscheidungen chronologisch abbilden.

Entsteht das Signal aus einem Sanktionsscreening, schließen Sie zunächst die Identitätsprüfung und die Analyse der einschlägigen Sanktionsregime ab, bevor Sie den Fall als Angelegenheit der Verdachtsmeldung behandeln. Der Leitfaden zur Dokumentation der Untersuchung eines Sanktionsalarms erläutert diese vorgelagerte Kontrolle im Detail.

Ein für die Meldung ausreichend vorbereiteter Datensatz kann Folgendes enthalten:

• das ursprüngliche Signal, die Quelldaten und die relevante Konfigurations- oder Regelreferenz;
• den zum betreffenden Zeitpunkt verfügbaren Kunden-, CDD-, Eigentums- und Beziehungskontext;
• relevante Personen, Unternehmen, Konten und Transaktionen;
• unterstützende und widersprüchliche Nachweise, Anhänge und frühere verbundene Fälle;
• Feststellungen des Analysten, offene Fragen und Informationsanfragen;
• die Verdachts- oder Meldepflichtbewertung, Entscheidungsbefugnis und Freigabehistorie sowie
• interne Referenzen, die die vorbereitete Meldung und eine spätere FIU-Antwort mit dem Fall verknüpfen.

Dies ist ein internes Kontrollmodell, keine universelle Liste von goAML-Feldern. Die Zielmeldeart und das technische Paket der FIU bestimmen, welche Daten für die Übermittlung transformiert oder ergänzt werden müssen.

Vor der Übergabe eine autorisierte Entscheidung vorsehen

Ein Ermittler kann eine Eskalation empfehlen, ohne zur externen Meldung befugt zu sein. Das System sollte diese Unterscheidung sichtbar machen.

Ein kontrollierter Freigabeschritt legt fest, wer den Fall bewerten darf, wer zur Meldeentscheidung befugt ist, welche Nachweise vorlagen, was entschieden wurde und ob wesentliche Änderungen eine erneute Prüfung erfordern. Software kann die Arbeit weiterleiten, interne Status durchsetzen und die Dokumentation sichern. Sie sollte weder die rechtliche Verdachtsbewertung noch die Meldeentscheidung anstelle der nach dem geltenden Rahmen befugten Person treffen oder unterstellen, dass jeder Alarm gemeldet werden muss.

Die Meldungsvorbereitung beginnt erst nach der nach Organisationsrichtlinie und geltendem Recht erforderlichen Entscheidung. Ändern sich Informationen während der Vorbereitung, sollte der Ablauf anzeigen, ob Entscheidung oder Freigabe erneut geprüft werden müssen, statt die Grundlage der Meldung unbemerkt zu verändern.

Falldaten der Meldestruktur der FIU zuordnen

Die Zuordnungsebene überführt kontrollierte Fallinformationen in die Struktur, die eine bestimmte FIU, Meldeart und Implementierungsversion verlangt. Dazu können Personen und Unternehmen, Konten, Transaktionen, Indikatoren, Freitext, Anhänge und Kennungen des Verpflichteten gehören.

Gehen Sie nicht davon aus, dass ein einziges goAML-XML-Modell überall funktioniert. Maltas FIAU veröffentlicht Implementierungsunterlagen einschließlich XSD, Beispielen und einem Offline-XML-Validator.⁴ Die Schweizer MROS veröffentlicht landesspezifische XML-Spezifikationen und Handbücher.⁵ Die neuseeländische FIU dokumentiert neben anderen Übermittlungswegen den XML-Upload für Prescribed Transaction Reports (PTRs).⁶

Klären Sie für jedes Ziel:

1. Welche FIU und welcher Kreis von Verpflichteten sind betroffen?
2. Welche Meldearten sind für den Anwendungsfall zulässig oder vorgeschrieben?
3. Welche Regeln gelten für Felder, Werte, Anhänge und Freitext?
4. Welches aktuelle Schema, technische Paket oder Portalformular bestimmt die Übergabe?
5. Welche internen Daten sind maßgeblich, und wo muss ein befugter Nutzer meldespezifische Angaben ergänzen?
6. Wie werden Änderungen an Zuordnungen getestet, genehmigt und versioniert?

Diese Fragen sind auch bei manueller Übermittlung relevant. Ein strukturiertes Meldepaket kann Mehrfacheingaben reduzieren und die Portaleingabe mit dem freigegebenen Fall in Einklang halten. Ein befugter Nutzer muss jedoch weiterhin das aktuelle Verfahren der FIU befolgen.

Das tatsächlich unterstützte Integrationsmodell wählen

„goAML-Integration“ bedeutet nicht zwangsläufig API. Wählen Sie das Betriebsmodell erst, nachdem Sie die aktuelle FIU-Schnittstelle, Meldeart und Zugangsregeln geprüft haben.

Länderspezifische Beispiele zeigen die Unterschiede. Für neuseeländische PTRs dokumentiert die FIU Webformulare, XML-Upload und automatisierte B2B-Übermittlung; vor dem genehmigten automatisierten Produktivbetrieb sind Tests erforderlich.⁶ Südafrikas FIC dokumentiert Einzel-, Stapel- und System-zu-System-Meldungen in bestimmten Meldekontexten.⁷ Diese Beispiele belegen keine öffentliche oder für Verpflichtete verfügbare API für jede goAML-Implementierung.

Dieselbe Architektur sollte auch Ziele ohne goAML unterstützen. Das Meldeumfeld der spanischen SEPBLAC verdeutlicht beispielsweise, warum eine Organisation FIU-spezifische Übergaben vorsehen sollte, statt einen universellen goAML-Ablauf fest zu programmieren.

Übergabe validieren, ohne technische und rechtliche Prüfungen zu verwechseln

Die Validierung sollte erfolgen, bevor eine freigegebene Meldung den kontrollierten Ablauf verlässt. Je nach FIU-Verfahren können Prüfungen Pflichtfelder, zulässige Werte, interne Referenzen, Anhangsregeln, Dateistruktur, die geltende XSD und weitere veröffentlichte Geschäftsregeln umfassen.

Drei Fragen müssen getrennt bleiben:

1. Ist die Datei oder das Formular technisch gültig? Die geltenden Struktur- und Validierungsregeln werden erfüllt.
2. Wurde die Meldung empfangen oder zur Bearbeitung angenommen? Das Zielsystem hat die im betreffenden FIU-Ablauf definierte Antwort erzeugt.
3. War die Meldeentscheidung rechtlich und tatsächlich angemessen? Das befugte Team hat das einschlägige Recht auf den Sachverhalt angewandt.

Das Bestehen der ersten Prüfung beantwortet die dritte nicht. Die neuseeländische FIU weist in ihren PTR-Testleitlinien ausdrücklich darauf hin, dass eine erfolgreiche Dateiprüfung keine regulatorische oder gesetzliche Konformität bestätigt.⁶ Ebenso sollte eine interne Validierung niemals die Annahme durch die FIU garantieren.

Ablehnung, Korrektur und Abstimmung in den Ablauf integrieren

Die Integration ist unvollständig, wenn sie mit der Dateierstellung oder dem Klick auf „Senden“ endet. Der Ursprungsfall benötigt einen kontrollierten Weg, um die zum gewählten Verfahren passende Antwort des Zielsystems zu erfassen.

Mögliche interne Status sind vorbereitet, zur Übergabe freigegeben, übergeben, Antwort ausstehend, eingegangen, abgelehnt, Korrektur erforderlich und abgeglichen. Dies sind zweckmäßige Betriebsstatus, keine Behauptung, dass jede FIU dasselbe Statusmodell anbietet.

Maltas FIAU liefert ein länderspezifisches Beispiel: Sie dokumentiert Rückmeldungen zur Übermittlung und verlangt, dass abgelehnte Meldungen entsprechend der Ablehnungsnachricht korrigiert und erneut eingereicht werden.⁴ Ein interner Ablauf sollte das abgelehnte Artefakt und den Grund aufbewahren, das Problem einem Verantwortlichen zuweisen, klären, ob eine erneute Freigabe erforderlich ist, und die korrigierte Übermittlung mit dem ursprünglichen Fall verknüpfen. Der genaue Mechanismus für Korrekturen oder Ergänzungsmeldungen muss den aktuellen Anweisungen der FIU entnommen werden.

Bei einem Ausfall oder einer fehlgeschlagenen Übergabe sind ein Verantwortlicher, ein sichtbarer offener Status und ein dokumentiertes Ersatzverfahren vorzusehen. Gehen Sie nicht davon aus, dass ein technischer Fehler eine gesetzliche Frist verlängert. Maßgeblich sind das anwendbare Recht und die FIU-Leitlinien.

Einen Prüfpfad für Meldungen aufbewahren

Die Meldedokumentation sollte es einem befugten Prüfer ermöglichen, nachzuvollziehen, was bekannt war, entschieden, vorbereitet und übergeben wurde. Je nach Integration sollten Sie Folgendes aufbewahren oder verknüpfen:

• den ursprünglichen Alarm und die Untersuchungsnachweise;
• Meldebewertung, Entscheidung, genehmigende Person und Zeitstempel;
• das freigegebene Meldeartefakt oder den Nachweis der Portaleingabe;
• gegebenenfalls die verwendete Zuordnungs-, Export- oder Schemaversion;
• den übermittelnden Nutzer oder das System sowie den Übermittlungsversuch;
• sofern verfügbar, FIU-Referenz, Bestätigung oder Ablehnungsnachricht sowie
• Korrekturen, ergänzende Informationen und spätere Rückfragen.

Diese Liste beschreibt einen belastbaren internen Prüfpfad, kein weltweit vorgeschriebenes goAML-Datenformat und keine universelle Aufbewahrungsfrist. Bewahren Sie Unterlagen gemäß den für Ihre Organisation geltenden Rechts- und Richtlinienvorgaben auf. Siehe Prüfpfad & Nachweise zum übergreifenden Modell der Nachweiskontrolle.

Änderungen nach dem Go-live steuern

FIU-Formulare, Schemas, Werte, Berechtigungen und Anweisungen können sich ändern. Behandeln Sie sie als gesteuerte Abhängigkeiten und nicht als einmalige Implementierungsdetails.

Ein praxistauglicher Änderungsprozess sollte die Verantwortung für die Pflege der maßgeblichen FIU-Quellen festlegen, neues technisches Material erkennen, es mit der aktuellen Zuordnung vergleichen, kontrollierte Tests durchführen, fachliche und Compliance-Freigaben einholen, die Änderung über den normalen Release-Prozess bereitstellen und die ersten produktiven Übergaben abstimmen. Verwenden Sie synthetische oder angemessen geschützte Testdaten und befolgen Sie die Vorgaben des Zielsystems: Neuseeland weist Verpflichtete an, in der Testumgebung keine identifizierbaren Echtdaten zu verwenden; die Schweiz warnt ebenfalls vor realen Kundendaten im Demosystem.⁶⁵

Auch Ersatzverfahren müssen getestet werden. Eine technisch elegante Verbindung ist keine wirksame operative Kontrolle, wenn das Team nicht weiß, wer eine fehlgeschlagene Übermittlung verantwortet oder wie freigegebene Informationen die FIU erreichen, wenn der reguläre Weg nicht verfügbar ist.

Was sich je nach Land und FIU unterscheidet

Praxischeckliste für die goAML-Integration

• Zuständige FIU, Verpflichtetenstatus, Rechtsordnung und Meldearten bestimmen.
• Verantwortliche für Untersuchung, Verdachtsbewertung, Meldefreigabe, Vorbereitung, Übergabe und Abstimmung benennen.
• Alarm, Untersuchung und Meldeentscheidung als getrennte Fallstatus führen.
• Festlegen, welche Nachweise vor Beginn der Meldungsvorbereitung vollständig sein müssen.
• Aktuelle Formulare, Schemas, Validierungsregeln, Schnittstellenleitlinien und Zugangsanforderungen der FIU beschaffen.
• Maßgebliche Falldaten dem Ziel zuordnen, ohne ursprüngliche Nachweise zu überschreiben.
• Manuelle, Upload-, Stapel-, System-zu-System- oder Hybridverarbeitung anhand bestätigter FIU-Unterstützung wählen.
• Technische Validierung und Geschäftsregeln testen, ohne sie als Nachweis rechtlicher Konformität darzustellen.
• Einen autorisierten menschlichen Entscheidungsschritt beibehalten und kontrollieren, wer die Meldung übermitteln darf.
• Definieren, wie Bestätigungen, Ablehnungen, Korrekturen, Ausfälle und offene Übermittlungen in den Fall zurückfließen.
• Relevante Artefakte, Entscheidungen, Zeitstempel und FIU-Antworten gemäß den geltenden Aufbewahrungsregeln sichern.
• Verantwortung für technische Änderungen der FIU, Regressionstests und Ersatzverfahren zuweisen.

Häufig gestellte Fragen

Gibt es eine universelle goAML-API?

Von einer universellen API für Verpflichtete darf nicht ausgegangen werden. UNODC beschreibt Interoperabilität auf Produktebene, während einzelne FIUs unterschiedliche Übermittlungswege anbieten. Einige FIUs dokumentieren automatisierte oder System-zu-System-Meldungen, darunter Neuseeland für PTRs und Südafrika in einschlägigen Meldekontexten. Schnittstelle, Authentifizierung, Meldearten und Freigabeprozess sind mit der zuständigen FIU zu klären.

Ist goAML-XML in jedem Land gleich?

Nein. Mehrere FIUs nutzen XML, doch Schema, Meldearten, Pflichtwerte und technische Regeln können implementationsspezifisch und versioniert sein. Verwenden Sie das aktuelle, von der Ziel-FIU veröffentlichte oder genehmigte Paket.

Kann AML-Software automatisch über eine Meldung entscheiden?

Software kann Signale erkennen, Nachweise zusammenführen, Prüfungen weiterleiten und strukturierte Informationen vorbereiten. Sie sollte weder die rechtliche Verdachtsbewertung noch die autorisierte Meldeentscheidung eigenständig treffen. Diese hängen vom Sachverhalt, dem anwendbaren Recht und der Governance der Organisation ab.

Übernimmt goAML das Transaktionsmonitoring des Verpflichteten?

Behandeln Sie es nicht als Ersatz für die Kontrollen des Verpflichteten. UNODC ordnet goAML der Erfassung, Analyse und Weitergabe durch FIUs zu. Screening- oder Transaktionsmonitoring-Systeme können vorgelagerte Signale erzeugen, die später in einen kontrollierten Meldeprozess einfließen.

Garantiert gültiges XML die Annahme?

Nein. Schemavalidität, technischer Eingang und inhaltlich-rechtliche Angemessenheit sind unterschiedliche Fragen. Eine Datei kann die strukturelle Validierung bestehen und nach den Regeln der FIU dennoch eine Korrektur oder weitere Prüfung erfordern.

Was sollte bei Ablehnung einer Meldung geschehen?

Befolgen Sie das Verfahren der zuständigen FIU. Intern sollten Sie Ablehnungsnachricht und Artefakt aufbewahren, die Korrektur zuweisen, prüfen, ob die Änderung erneut genehmigt werden muss, die korrigierte Ausgabe validieren und die spätere Übergabe mit dem ursprünglichen Fall verknüpfen. Setzen Sie kein universelles Korrektur- oder Wiedereinreichungsverfahren voraus.

AML-Fälle mit dem Meldeprozess verbinden

Checklynx unterstützt Teams dabei, Übergaben aus Screening und Monitoring mit kontrollierten Fällen, Nachweisen, Notizen, Anhängen, Entscheidungen und Zeitachsen zu verbinden. Strukturierte Vorbereitung, Meldepakete, Exporte sowie AML-Integrationen und Systemübergaben können den Weg in goAML oder ein anderes Meldesystem unterstützen. Die autorisierte Compliance-Funktion des Kunden behält dabei die Verantwortung für Verdachtsbewertung, Richtlinienauslegung, Meldefreigabe und Einreichung.

Das Integrationskonzept sollte zur FIU-Schnittstelle passen, die der Organisation tatsächlich zur Verfügung steht. Ob dies die Vorbereitung einer Portaleingabe, einen strukturierten Export oder einen anderen unterstützten Weg umfasst, ist für jede Implementierung zu klären – es handelt sich nicht um ein universelles Produktversprechen.