Die technische Validierung einer goAML-Meldung ist nur der erste Schritt. Viele Verpflichtete gehen davon aus, eine Verdachtsmeldung sei „korrekt”, sobald das XML-Schema akzeptiert wird und der Upload im goAML-Portal funktioniert. In der Praxis beginnt das eigentliche Problem jedoch oft erst danach.

Denn ein XML kann technisch vollständig valide sein – und gleichzeitig inhaltlich unplausibel, unvollständig oder für die Financial Intelligence Unit (FIU) nur eingeschränkt auswertbar. Über die Qualität einer Verdachtsmeldung entscheidet nicht allein die technische Struktur, sondern vor allem die semantische Konsistenz der Daten.

Das Wichtigste in Kürze

  • Eine goAML-Meldung kann das XML-Schema bestehen und trotzdem fachlich lückenhaft sein – die Schemaprüfung kontrolliert die Struktur, nicht die inhaltliche Stimmigkeit.
  • Seit dem 1. März 2026 verschärft die GwG-Meldeverordnung (GwGMeldV) die Vorgaben für Form und Inhalt von Verdachtsmeldungen nach §§ 43, 44 GwG – Datenqualität ist damit kein „Nice-to-have” mehr.
  • Typische semantische Schwächen sind fehlende Beziehungen, unvollständige Entitäten, ungültige Identifikatoren und fehlender Transaktionskontext.
  • Der GoAML Navigator prüft Meldungen zweistufig: technische Schemaprüfung plus mehr als 20 kontextsensitive Plausibilitätsregeln.

Technisch valide bedeutet nicht fachlich korrekt

Eine XML-Schema-Validierung (XSD) prüft zunächst, ob eine Datei dem vorgegebenen Aufbau entspricht. Sie erkennt zuverlässig:

  • fehlende Pflichtfelder,
  • falsche XML-Strukturen,
  • ungültige Datentypen,
  • Formatfehler.

Was eine reine Schemaprüfung jedoch typischerweise nicht erkennt:

  • fehlende oder nicht verknüpfte wirtschaftlich Berechtigte,
  • widersprüchliche Rollenbeziehungen,
  • unplausible Konto- und Beteiligtenstrukturen,
  • rechnerisch ungültige Identifikationsnummern,
  • logisch unvollständige Transaktionskontexte.

Eine Verdachtsmeldung soll Ermittlerinnen und Ermittlern ein nachvollziehbares Gesamtbild liefern – Angaben zu Personen, Organisationen, Konten und Transaktionen müssen klar gegliedert und in ihren Beziehungen erkennbar sein. Genau hier, in der Semantik, entstehen in der Praxis die meisten Probleme.

Neu seit März 2026: die GwG-Meldeverordnung

Dass es auf die inhaltliche Qualität ankommt, ist seit Kurzem nicht mehr nur eine Frage der guten Praxis. Mit der GwG-Meldeverordnung (GwGMeldV), die zum 1. März 2026 in Kraft getreten ist, gelten bundeseinheitliche Standards für Form und Inhalt von Verdachtsmeldungen nach §§ 43, 44 GwG.

Wesentliche Punkte:

  • Meldungen sind in einem strukturierten Format (goAML-XML oder die vorgesehenen Datenfelder) zu übermitteln.
  • Pflichtangaben gehören in das strukturierte Meldeformular – Anlagen ergänzen den Sachverhalt nur dort, wo er erst durch sie verständlich wird. Wichtige Informationen „in den Anhang zu verschieben” ist damit kein gangbarer Weg mehr.
  • Fehlende oder unvollständig ausgefüllte Pflichtfelder können dazu führen, dass eine Meldung technisch gar nicht erst übermittelt wird.
  • Unrichtige oder unvollständige Meldungen können bußgeldbewehrt sein (vgl. § 56 GwG).

Wichtig zur Einordnung: Die GwGMeldV hebt das Mindestniveau bei formaler Vollständigkeit und Standardisierung an. Die in diesem Beitrag beschriebene semantische Konsistenz geht darüber noch hinaus – ein Formular kann vollständig ausgefüllt und trotzdem inhaltlich widersprüchlich sein.

Häufige Datenqualitätsprobleme bei goAML-Meldungen

Besonders betroffen sind häufig Verpflichtete aus dem Nichtfinanzsektor (DNFBP) – etwa Immobilienmakler, Güterhändler oder Juweliere –, die Verdachtsmeldungen nur selten erstellen und deshalb stärker auf manuelle, fehleranfällige Abläufe angewiesen sind. Die folgenden Konstellationen treten in der Praxis besonders häufig auf:

Organisation erfasst – aber keine Kontroll- oder Eigentumsbeziehung

Ein häufiger Praxisfall: Eine Organisation wird als Transaktionsbeteiligte erfasst, ohne dass eine handelnde Person oder ein wirtschaftlich Berechtigter verknüpft ist. Technisch kann das XML valide sein – fachlich bleibt die zentrale Frage offen: Wer steht tatsächlich hinter der Organisation? Angaben zu wirtschaftlich Berechtigten gehören regelmäßig zu den wichtigsten Ermittlungsinformationen einer Meldung.

Kontodaten vorhanden – aber unvollständig

Eine IBAN ist angegeben, doch BIC, Bankbeziehung oder Kontoinhaber fehlen – oder das Konto ist keiner Transaktionsrolle zugeordnet. Solche Meldungen sind technisch oft akzeptabel, erschweren die operative Analyse aber erheblich.

Formal vorhandene, aber ungültige Identifikatoren

Viele Systeme prüfen nur, ob ein Feld befüllt ist und die Zeichenkette die richtige Länge hat – nicht jedoch, ob eine IBAN rechnerisch gültig ist, ob ein Ausweisdokument plausibel aufgebaut ist oder ob Datumsangaben logisch konsistent sind. So gelangen formal vorhandene, faktisch aber unbrauchbare Daten in die Meldung.

Beteiligte ohne saubere Transaktionsstruktur

Werden lediglich Gegenparteien genannt, ohne Rollen wie Auftraggeber, Begünstigten oder Kontoinhaber differenziert abzubilden, verliert die FIU wichtige Beziehungsinformationen – obwohl die XML-Datei problemlos verarbeitet werden kann.

Warum schlechte Datenqualität teuer werden kann

Schwache semantische Datenqualität verursacht vor allem operative Kosten: manuelle Nacharbeiten, interne Rückfragen, erneute Dokumentation, Abstimmungen mit Kundinnen und Kunden sowie Korrektur- und Nachmeldungen.

Hinzu kommt ein oft unterschätzter Faktor: Interne Compliance- und Freigabeprozesse können sich verzögern, wenn sie wegen unvollständiger oder widersprüchlicher Informationen nicht abgeschlossen werden können – besonders bei Immobiliengeschäften, komplexen Firmenstrukturen, internationalen Zahlungen oder Hochrisikokonstellationen.

Internationale Standards der FATF betonen seit Langem, dass die Wirksamkeit des Meldewesens nicht von der Zahl der Verdachtsmeldungen abhängt, sondern von ihrer Qualität und Nutzbarkeit. Entscheidend ist, ob eine Meldung der FIU verwertbare, handlungsrelevante Hinweise liefert – im FATF-Kontext als „actionable intelligence” beschrieben. Eine technisch übermittelte, aber inhaltlich schwache Meldung trägt zur operativen Auswertung dagegen kaum bei.

Was kontextsensitive Plausibilitätsprüfungen leisten

Die Schwäche vieler einfacher XML-Generatoren ist, dass sie Syntax prüfen, aber keinen Kontext. Kontextsensitive Plausibilitätsprüfungen setzen genau dort an und stellen Fragen, die eine XSD-Validierung nicht beantwortet:

  • Ist zu einer Organisation eine handelnde Person oder Eigentumsbeziehung erfasst?
  • Ist jedes Konto einem Inhaber zugeordnet?
  • Sind bei internationalen Transaktionen die Länderangaben konsistent?
  • Sind die Identifikationsdaten beteiligter Personen vollständig und plausibel?
  • Ergeben die Transaktionsrollen ein logisch nachvollziehbares Bild?

Wie der goAML Navigator dabei unterstützt

Der GoAML Navigator ist auf genau diese Lücke zwischen technischer und fachlicher Korrektheit ausgelegt. Vor dem Export prüft er jede Meldung in zwei Stufen.

Stufe 1 – Technische Schemaprüfung

Die erzeugte XML-Datei wird gegen das offizielle goAML-XML-Schema (XSD) validiert. Erkannt werden klassische technische Fehler: fehlende Pflichtfelder, ungültige Datentypen, unzulässige Werte und strukturelle Fehler. Diese Stufe entscheidet, ob die Meldung technisch gültig ist; die rohen Schema-Meldungen werden dabei in verständliche deutsche Hinweise übersetzt.

Stufe 2 – Kontextsensitive Plausibilitätsprüfungen

Die zweite Stufe geht über die Schemaprüfung hinaus: Mehr als 20 Plausibilitätsregeln prüfen die Meldung auf inhaltliche Konsistenz. Sie blockieren die Meldung nicht, sondern erscheinen als verständliche Warnungen und Hinweise – also dort, wo eine reine XSD-Validierung schweigt. Einige Beispiele zeigen, wie das in der Praxis aussieht:

  • IBAN-Prüfziffer: Geprüft wird nicht nur, ob eine IBAN die richtige Länge hat, sondern ob sie nach dem MOD-97-Verfahren (ISO 7064) rechnerisch gültig ist. So fällt eine syntaktisch „richtige”, in Wahrheit aber fehlerhafte Kontonummer auf, bevor die Meldung das Haus verlässt.
  • Konto ohne Kontoinhaber: Ist ein Konto erfasst, aber keiner Person oder Organisation als Inhaber zugeordnet, wird darauf hingewiesen – eine der häufigsten stillen Lücken in goAML-Meldungen.
  • Organisation ohne Kontroll-/Eigentumsbezug: Wird eine Organisation als Beteiligte geführt, ohne dass eine handelnde Person oder eine Eigentums-/Kontrollbeziehung hinterlegt ist, macht der Navigator dies sichtbar.
  • Mögliche Dubletten: Tauchen zwei Personen mit identischem Namen und Geburtsdatum, aber unterschiedlichen Identifikationsdaten auf, deutet das auf eine Doppelerfassung hin.
  • Zeitliche Inkonsistenz: Transaktions- und Wertstellungsdaten werden auf logische Stimmigkeit geprüft – etwa Datumsangaben in der Zukunft oder eine Wertstellung vor dem Transaktionsdatum.

Daneben prüft der Navigator weitere Formate und Identifikatoren – darunter BIC, LEI, USt-IdNr. sowie Handelsregister- und Ausweisnummern – und kontrolliert die Länderkonsistenz von IBAN und BIC. Alle Meldungen sind nach Schweregrad gegliedert: technische Fehler, die die Gültigkeit blockieren, sind klar von Warnungen und Hinweisen getrennt, die „nur” die Qualität betreffen.

Wichtig bleibt die Einordnung: Plausibilitätsprüfungen können fachliche Auffälligkeiten sichtbar machen, ersetzen jedoch weder die risikobasierte Bewertung noch die rechtliche Prüfung durch die Verpflichteten. Sie sorgen dafür, dass typische Erfassungs- und Konsistenzfehler nicht übersehen werden – die fachliche Verantwortung für die Meldung bleibt beim Anwender.

Meldungen prüfen, bevor sie zur FIU gehen

Der GoAML Navigator validiert jede Verdachtsmeldung zweistufig – technische Schemaprüfung plus kontextsensitive Plausibilitätskontrollen – und gibt verständliche Hinweise vor dem Export.

GoAML Navigator ansehen

Fazit

Eine goAML-Meldung kann technisch vollkommen valide sein und dennoch erhebliche fachliche Schwächen enthalten. Das eigentliche Risiko liegt selten im XML-Format selbst, sondern in fehlenden Beziehungen, unvollständigen Entitäten, logisch inkonsistenten Daten und fehlendem Transaktionskontext.

Mit der GwG-Meldeverordnung ist Datenqualität seit März 2026 auch regulatorisch klar adressiert. Über die formale Vollständigkeit hinaus entscheidet jedoch die semantische Konsistenz darüber, ob eine Verdachtsmeldung für die FIU wirklich brauchbar ist. Kontextsensitive Plausibilitätsprüfungen – wie sie der GoAML Navigator vor dem Export durchführt – nehmen die fachliche Bewertung nicht ab, decken aber einen großen Teil der typischen Fehler zuverlässig auf.

Stand: Mai 2026. Dieser Beitrag dient der allgemeinen Information und ersetzt keine Rechtsberatung im Einzelfall. Maßgeblich sind die jeweils geltenden Gesetzes- und Verordnungstexte sowie die technischen Vorgaben der FIU.

Quellen und weiterführende Informationen