MASAK-Compliance und Transaktionsüberwachung im Bankensektor

Die Verpflichtung zur Bekämpfung von Geldwäsche im Bankensektor besteht aus der Kette von KYC, Transaktionsüberwachung und Meldung verdächtiger Aktivitäten gemäß dem Gesetz Nr. 5549. Der MASAK-Leitfaden zur Meldung verdächtiger Transaktionen für Banken listet branchenspezifische Indikatoren einzeln auf, und die meisten dieser Indikatoren können nicht über ein einziges System erkannt werden: Sie erfordern die gemeinsame Analyse von Kunden-, Konto-, Transaktions- und Kanaldaten.

Wer ist verpflichtet und wie läuft der Prozess ab?

Banken und, beschränkt auf Bankaktivitäten, die PTT sind Verpflichtete gemäß dem Gesetz Nr. 5549 zur Verhinderung der Wäsche von Erträgen aus Straftaten. MASAK veröffentlicht einen separaten Leitfaden zur Meldung verdächtiger Transaktionen für diese Gruppe und erwartet, dass Meldungen elektronisch über das System MASAK.Online eingereicht werden.

Der Umfang des Leitfadens beschränkt sich nicht auf die Frage, „welche Transaktion verdächtig ist“. Er definiert auch, welche Felder jeder Abschnitt des Meldeformulars enthalten muss, welche Referenztabellen zur Codierung von Transaktionen zu verwenden sind und in welche Kategorie der Verdacht eingeordnet wird. Dies bestimmt direkt die Ergebnisse, die eine Bank von ihrer Überwachungssoftware erwartet.

Welche Indikatoren listet der Leitfaden auf?

Die Verteilung der 112 Banktypen, welche die größte Gruppe darstellen, bestimmt die Überwachungsstruktur, die eine Bank einrichten muss: 41 beziehen sich auf Überweisungen und Inlandsüberweisungen, 18 auf Bargeld und Strukturierung (Structuring), 19 auf digitale Kanäle, 12 auf Kredite und Sicherheiten sowie 9 auf Karten- und Geldautomaten-Transaktionen.

Warum sind Indikatoren nicht in einem einzigen System sichtbar?

Das Lesen der Typen im Leitfaden und der Blick auf die erforderlichen Daten zeigen, warum das Thema nicht mit dem bloßen Kauf eines Überwachungsprodukts erledigt ist.

Wenn man diese vier Punkte zusammen betrachtet, liegt der Schluss nahe: Die eigentliche Frage für eine Bank ist nicht, welches Überwachungsprodukt sie kaufen soll, sondern wie nahtlos dieses Produkt in das Kernbanksystem und die peripheren Systeme integriert werden kann. Das Zugriffsprotokoll für Schließfächer befindet sich auf Filialebene, während die Finanztransaktion im Kernbanksystem liegt: Ohne die Zusammenführung beider Welten wird T-001-3.95 niemals ausgelöst.

Verknüpfte Konten

T-001-3.7 fasst Kunden unter einem einzigen Typ zusammen, die scheinbar unabhängig voneinander agieren, aber dieselben Adress- und Telefondaten angeben, Überweisungen an dieselben Begünstigten senden, Überweisungen von denselben Absendern erhalten oder denselben Personen Zeichnungsberechtigung für ihre Konten erteilen.

Vier Signale befinden sich an vier verschiedenen Orten: Kontaktinformationen in den Kundenstammdaten, Details zu Begünstigten und Absendern in den Überweisungsdaten und die Zeichnungsberechtigung in der Kontoeröffnungsakte. Einzelne Transaktionsprüfungen verknüpfen diese Daten nicht miteinander.

T-001-3.16 listet zahlreiche Personen auf, die ohne plausible Erklärung Geld auf dasselbe Konto einzahlen, oder Überweisungen, die von vielen separaten Konten auf dasselbe Konto getätigt werden. Dies erfordert die Abbildung des Netzwerks rund um ein einzelnes Konto.

Strukturierung, Bargeld und Beruf als Referenz

T-001-3.14 listet Kunden auf, die Geld auf mehrere Konten, Überweisungen oder Bargeld aufteilen, um Meldeverfahren zu umgehen, und erfasst auch Versuche. Dies bedeutet, dass auch eine nicht ausgeführte Transaktion meldepflichtig sein kann: Das System muss daher auch abgelehnte und unvollständige Transaktionen speichern.

T-001-3.18 betrachtet die Unfähigkeit, Bargeldbewegungen auf Konten mit dem Lebensstandard, dem Beruf und dem Einkommensniveau des Kunden in Verbindung zu bringen, als Indikator. Dies zeigt, dass Berufs- und Einkommenserklärungen keine Felder sind, die beim Onboarding erfasst und dann vergessen werden: Sie sind Referenzwerte, die mit jeder Transaktion abgeglichen werden. T-001-3.2 listet bereits Schwierigkeiten bei der Erlangung von Angaben zu Aktivität, Beruf oder Identität, Adresse und Telefonnummer des Kunden als separaten Typ auf.

Was erfordert das Meldeformular?

Der Leitfaden definiert die Abschnitte des Meldeformulars und die Felder jedes Abschnitts. Dies ist das Ergebnis, das die Überwachungssoftware liefern muss.

Verdachtsmomente, die keinen Geldwert enthalten, wie verdächtige Kontoeröffnungen und -schließungen, Schließfachbesuche sowie Garantie- oder Vollmachtstransaktionen, werden im Beschreibungsabschnitt des Formulars erfasst, nicht im Abschnitt für verdächtige Transaktionen. Dies bedeutet, dass ein Fall (Case) auch nicht-monetäre Ereignisse abbilden können muss.

Eine Meldung kann auf einer einzelnen Transaktion oder auf mehreren Transaktionen innerhalb eines bestimmten Datumsbereichs basieren. Bei mehreren Transaktionen werden der Gesamtbetrag und der Datumsbereich zusammen gemeldet. Wenn sich verdächtige Transaktionen auf verschiedene Kanäle, Filialen oder Typen konzentrieren, kann der Formularabschnitt für jedes Cluster wiederholt werden.

Diese drei Anforderungen zusammen verlangen Konkretes vom Case Management: Ein Fall muss in der Lage sein, nicht-monetäre Ereignisse zu erfassen, Transaktionen innerhalb eines Datumsbereichs zu aggregieren, um sie als eine einzige Position darzustellen, und separate Cluster basierend auf Kanal und Filiale zu generieren.

Wie wird die Verdachtskategorie ausgewählt?

Bei der Erstellung einer Meldung wird der Verdacht in eine der 38 Kategorien der MASAK-Referenztabelle eingeordnet, und jede Kategorie wird mit der entsprechenden gesetzlichen Regelung abgeglichen. Wucher und POS-Wucher sind mit Artikel 241 des Gesetzes Nr. 5237 verknüpft, die Förderung oder Vermittlung von Prostitution mit Artikel 227. Die Liste reicht von Steuerhinterziehung und betrügerischem Konkurs bis hin zu illegalen Wetten und der Finanzierung der Verbreitung von Massenvernichtungswaffen.

Dies bedeutet, dass das Case Management mit dieser Taxonomie arbeiten muss und nicht mit eigenen, frei gestaltbaren Tags. Die Auswahl der Kategorie ist ein integraler Bestandteil der Meldung selbst.

Wie hoch ist die Schwelle für Meldungen mit einem Antrag auf Aussetzung?

Die auf Artikel 19/A des Gesetzes Nr. 5549 basierende Regelung mit dem Titel „Aussetzung von Transaktionen“ regelt die Aussetzung von Transaktionen auf der Grundlage einer Meldung. Der Leitfaden legt eine klare Schwelle für Meldungen mit einem Antrag auf Aussetzung fest: Anstelle eines bloßen Verdachts, dass der Vermögenswert, der Gegenstand der Transaktion ist, mit Geldwäsche oder Terrorismusfinanzierung in Verbindung steht, müssen unterstützende Dokumente oder schwerwiegende Indizien vorliegen, die den Verdacht untermauern und zusammen mit den Begründungen übermittelt werden müssen.

Diese Schwelle führt direkt zu einer Systemanforderung: Die Nachweise müssen an den Case angehängt, die Begründung dokumentiert und die entscheidende Person erfasst werden. Ein einfacher Hinweis auf dem Alert-Bildschirm reicht hierfür nicht aus.

Wo verbleiben die Daten?

Die Informationssysteme von Banken unterliegen der Prüfung durch die BDDK. Dadurch wird die Frage, wo das Überwachungsprodukt läuft und wohin die Kundendaten fließen, von einer technischen Präferenz zu einer prüfungsrelevanten Angelegenheit.

TruvaLI unterstützt On-Premise-Bereitstellungen: Die Software läuft auf der bankeigenen Infrastruktur, die Kundendaten verbleiben in den Informationssystemen der Bank, und Schlüssel sowie der Audit Trail stehen unter der Kontrolle der Bank. Cloud und Private Cloud bleiben ebenfalls Optionen; die Entscheidung liegt bei der Bank.

Wie erfüllt TruvaLI diese Anforderungen?

Einheitliche Kundenansicht (Single Customer View)

Konto- und Transaktionsdaten aus dem Kernbanksystem, Geldautomaten- und Ausgabenbelege aus dem Kartensystem, Sicherheitenbewegungen auf der Kreditseite und Aufzeichnungen auf Filialebene werden mit demselben Datensatz verknüpft. Das Field Mapping ist dynamisch und stellt Verbindungen her, ohne das eigene Datenmodell der Bank zu verändern; wird ein neues Feld eingeführt, steht es sofort für Regeln zur Verfügung. Transaktionen, die im Versuchsstadium verblieben oder abgelehnt wurden, werden ebenfalls gespeichert, da T-001-3.14 auch Versuche abdeckt.

Rule Engine und Beziehungsanalyse

Die Typen im Leitfaden werden in Regeln umgewandelt: mit verschachtelter Logik, flexiblen Aggregationsfenstern und Callbacks aus Regeln. Netzwerke verknüpfter Konten werden über gemeinsame Adressen, Telefonnummern, Geräte und IPs abgebildet; beziehungsbasierte Typen wie T-001-3.7 und T-001-3.16 werden nicht bloß Einzeltransaktionsprüfungen überlassen.

Bevor Sie eine neue Regel in der Produktivumgebung bereitstellen, können Sie diese in einer Regelsimulation auf historischem Datenverkehr testen, um das zu erwartende Alert-Volumen zu sehen. Sie können auch ein vergangenes Datum angeben und das Ergebnis für den Datenverkehr dieses Tages anzeigen lassen. Sie können die Regel mithilfe eines Prompts in Ihrer eigenen Sprache beschreiben und den Entwurf freigeben.

Case, Nachweise und Kategorie

Ein Alert wird in einen Case mit einem Verantwortlichen, einer Frist und Nachweisen umgewandelt. Der Case enthält auch nicht-monetäre Ereignisse, kann Transaktionen innerhalb eines Datumsbereichs als Gesamtsumme darstellen und separate Cluster nach Kanälen generieren. Die Verdachtskategorie wird aus der 38-Kategorien-Taxonomie von MASAK ausgewählt.

Informationen darüber, wer mit welcher Befugnis, auf Basis welcher Daten und wann entschieden hat, werden in den unveränderlichen Audit Trail geschrieben; die Freigabe nach dem Vier-Augen-Prinzip erfolgt über Maker/Checker. Die für Meldungen mit Aussetzungsantrag erforderlichen Dokumente und Begründungen werden an den Case angehängt. Der Entwurf der Meldung wird aus denselben Case-Daten erstellt, und die Freigabe verbleibt bei der Bank.

Die Aufsichtsbehörde für Banken ist die BDDK; der Partner für Geldwäscheverpflichtungen ist MASAK, und das Rahmenwerk finden Sie auf der Seite MASAK-Verpflichtungen. Verwandte Prozesse: Kunden-Onboarding, fortlaufende Überwachung, Sanktions-Compliance, Prüfung der Mittelherkunft und regulatorisches Meldewesen. Die Regelseite finden Sie auf der Seite Rule and Scenario Engine und die Bereitstellung auf der Seite On-Premise-Bereitstellung.

Quelle

MASAK, „Leitfaden zur Meldung verdächtiger Transaktionen für Banken und auf Bankaktivitäten beschränkte PTT“, MSK-RHB-ŞİB-001, Version 2.0.

Diese Seite stellt keine regulatorische Auslegung dar; sie gibt die im Leitfaden aufgeführten Indikatoren und Verfahren wieder. Regeln, Schwellenwerte und Maßnahmen werden gemäß der eigenen Risikopolitik und den Verpflichtungen der Bank konfiguriert.