Zahlungskonto- und Guthabenrisiko bei E-Geld-Instituten
Bei einem E-Geld-Institut konzentriert sich das Risiko auf das Zahlungskonto selbst und nicht auf eine einzelne Transaktion. Der MASAK-Leitfaden für Zahlungs- und E-Geld-Institute analysiert Konten aus drei Blickwinkeln: Woher stammen die Einzahlungen, wie verhält sich das Guthaben und wohin fließen die Auszahlungen? Truvali vereint diese drei Aspekte in einer einzigen Kundenansicht (Single Customer View). Identitäts-, E-Mail- und IP-Daten, die während des Onboardings erfasst werden, nutzen dieselbe Rule Engine wie die nachfolgenden Kontoaktivitäten, anstatt in isolierten Systemen zu verbleib
Bei E-Geld-Instituten konzentriert sich das Geldwäsche-Risiko auf das auf dem Konto aufgelaufene Guthaben und das Muster zwischen Ein- und Auszahlungen, anstatt auf eine einzelne Transaktion. Die Institute sind Verpflichtete nach dem Gesetz Nr. 5549; ihre zuständige Aufsichtsbehörde ist die TCMB.
Wo konzentriert sich das Risiko?
E-Geld-Institute sind Verpflichtete nach dem Gesetz Nr. 5549 zur Verhinderung der Geldwäsche von Erträgen aus Straftaten. MASAK veröffentlicht einen gemeinsamen Leitfaden für Verdachtsmeldungen (Suspicious Transaction Reports) für Zahlungs- und E-Geld-Institute und erwartet, dass Meldungen elektronisch über MASAK.Online eingereicht werden.
Das gemeinsame Merkmal der auf Zahlungskonten bezogenen Typologien im sektorspezifischen Teil des Leitfadens besteht darin, dass sie über das Verhalten des Kontos im Zeitverlauf definiert werden und nicht über eine einzelne Transaktion.
T-006-2.66 betrachtet eine plötzliche und erhebliche Änderung des Guthabens eines Zahlungskontos im Vergleich zu seinem langfristigen Durchschnitt als Verdachtsindikator. Um diese Typologie abzudecken, muss der Kontoverlauf gespeichert und verglichen werden; eine einfache Echtzeit-Schwellenwertprüfung reicht nicht aus.
Welche Indikatoren listet der Leitfaden auf?
| Gruppe | Anzahl der Typologien | Worauf geachtet wird |
|---|---|---|
| Kundenprofil | 16 | Erklärungen, Dokumente und Verweigerung von Angaben |
| Zahlungs- und E-Geld-Institute | 76 | Zahlungskonto, Einzahlungen, Auszahlungen, Händler |
| Terroristische Vereinigungen und Risikoländer | 23 | Vertragspartner und Geografie |
| Gemeinnützige Organisationen | 10 | Transaktionen von Managern und Finanzverantwortlichen |
| Finanzierung von Massenvernichtungswaffen | 17 | Sanktionsregime |
Die Einzahlungsseite
| Typologie | Inhalt | Erforderliche Daten |
|---|---|---|
| T-006-2.59 | Einzahlung auf ein Zahlungskonto von zahlreichen verschiedenen Karten oder Konten ohne plausible Erklärung | Identität der Einzahlungsquelle |
| T-006-2.20 | Einzahlung hoher Bargeldbeträge auf ein Konto mit sehr geringem Guthaben und Abhebung in bestimmten Abständen | Guthabenverlauf |
| T-006-2.4 | Mehrere Kunden, die ihre aufgelaufenen Guthaben auf ein gemeinsames Bankkonto überweisen | Kontenübergreifender Empfängervergleich |
| T-006-2.62 | Einzahlungen auf Zahlungskonten verschiedener, nicht miteinander verbundener Personen von denselben IPs | Registrierungs- und Sitzungs-IP |
T-006-2.62 ist besonders bemerkenswert: Es erfordert, dass IP-Daten bereits beim Onboarding erfasst, gespeichert und kontenübergreifend verglichen werden. Wenn diese Daten in diesem Moment nicht erfasst werden, können sie später nicht mehr rekonstruiert werden.
Die Auszahlungsseite
T-006-2.60 beschreibt die Einzahlung auf ein inaktives Zahlungskonto und die anschließende Abhebung dieser Gelder, meist über maximale Bargeldabhebungen an Geldautomaten, während T-006-2.69 den Transfer von Geldern, die an Geldautomaten in verschiedenen Provinzen auf Zahlungskonten eingezahlt wurden, per EFT auf das Bankkonto des E-Geld-Kontoinhabers aufführt.
Bei Prepaid-Karten sieht T-006-2.26 kontinuierliche Bargeldabhebungen in auffälliger Höhe von der Karte als Indikator an, während T-006-2.27 auf die kontinuierliche oder auffällige Nutzung der Karte zum Kauf von leicht in Bargeld umwandelbaren Edelmetallen oder Luxusgütern wie Gold hinweist. Letzteres lässt sich ohne Händlerkategoriedaten (Merchant Category Codes) nicht analysieren: Ohne zu wissen, wo die Karte eingesetzt wird, lässt sich nicht feststellen, was gekauft wurde.
Strukturierung
T-006-2.8 führt Kunden auf, die Gelder auf mehrere Konten, Überweisungen oder Bargeld aufteilen, um Meldepflichten zu umgehen, und erfasst auch versuchte Transaktionen. Dies bedeutet, dass auch eine nicht ausgeführte Transaktion meldepflichtig sein kann; das System muss daher auch abgelehnte und unvollständige Transaktionen speichern.
T-006-2.5 ergänzt das Aufteilen von Finanztransaktionen, die normalerweise in einer Summe durchgeführt werden sollten, ohne logische Begründung, um Entdeckung und Meldung zu vermeiden.
Was verlangt das Meldeformular?
Verdachtsmomente ohne monetären Wert werden im Beschreibungsfeld des Formulars eingetragen, nicht im Bereich für verdächtige Transaktionen. Das bedeutet, dass ein Fall auch nicht-monetäre Ereignisse abbilden können muss.
Eine Meldung kann auf einer einzelnen Transaktion oder auf mehreren Transaktionen innerhalb eines bestimmten Zeitraums basieren; bei mehreren Transaktionen werden der Gesamtbetrag und der Zeitraum zusammen gemeldet. Wenn sich verdächtige Transaktionen auf verschiedene Kanäle oder Typologien konzentrieren, kann der entsprechende Formularabschnitt für jedes Cluster wiederholt werden.
Wie wird die Verdachtskategorie ausgewählt?
Bei der Meldung wird der Verdacht einer der Kategorien in der Referenztabelle von MASAK zugeordnet, und jede Kategorie ist der entsprechenden gesetzlichen Regelung zugewiesen. Das bedeutet, dass das Case Management mit dieser Taxonomie arbeiten muss und nicht mit eigenen, frei definierbaren Tags.
Wie hoch ist die Hürde 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 Grundlage einer Meldung. Der Leitfaden setzt hierfür eine klare Schwelle: Anstelle eines bloßen Verdachts müssen Dokumente oder schwerwiegende Indizien vorliegen, die den Verdacht stützen, dass die der Transaktion zugrunde liegenden Vermögenswerte mit Geldwäsche oder Terrorismusfinanzierung im Zusammenhang stehen, und diese müssen zusammen mit den Begründungen eingereicht werden.
Diese Schwelle führt direkt zu einer Systemanforderung: Beweise müssen dem Fall beigefügt, die Begründung schriftlich festgehalten und die Person, die die Entscheidung getroffen hat, protokolliert werden.
Wo verbleiben die Daten?
E-Geld-Institute werden sowohl von der TCMB als auch von der BDDK reguliert und beaufsichtigt. Daher ist der Betriebsort der Monitoring-Software und der Verbleib der Kundendaten ein prüfungsrelevantes Thema.
Truvali unterstützt das On-Premise-Deployment: Die Software läuft auf der eigenen Infrastruktur des Instituts, die Kundendaten verbleiben in den Informationssystemen des Instituts, und die Schlüssel sowie der Audit Trail stehen unter der Kontrolle des Instituts.
Wie löst Truvali das?
Beim Onboarding erfasste Daten
Bei der digitalen Identitätsprüfung laufen das Auslesen des Dokumentenchips, die Lebendigkeitserkennung (Liveness) und der Gesichtsabgleich in einem einzigen Prozess ab. Gleichzeitig werden E-Mail- und IP-Scores berechnet: Auf der E-Mail-Seite werden Provider-Listen, die Verknüpfung der Adresse mit dem Namen und Geburtsdatum der Person sowie ein Fuzzy-Vergleich mit ähnlichen Adressen im System herangezogen; auf der IP-Seite die Lokalisierung über ip2location, die Inhaberschaft über RIPE und die Prüfung auf Proxys oder VPNs über rDNS.
Diese Scores verbleiben im Kundendatensatz und dienen als Input für nachfolgende Regeln. Typologien wie T-006-2.62, die Konten verschiedener Personen über dieselbe IP verknüpfen, können ohne diese Daten nicht erkannt werden.
Überwachung des Kontoverhaltens
Die Rule Engine unterstützt verschachtelte Logik und flexible Aggregationsfenster. Das bedeutet, dass Regeln wie „basierend auf dem Durchschnitt der letzten 90 Tage des Kontos“ in einer einzigen Regel definiert werden können. Für Typologien, die einen Vergleich mit dem Verlauf erfordern, wie T-006-2.66, bestimmt die eigene Risikorichtlinie des Instituts den Schwellenwert.
Auch versuchte und abgelehnte Transaktionen werden gespeichert, da T-006-2.8 auch Versuche abdeckt.
Bevor Sie eine neue Regel in Betrieb nehmen, testen Sie diese in einer Regelsimulation am historischen Datenverkehr und sehen das zu erwartende Alert-Volumen. Sie können die Regel mithilfe eines Prompts in Ihrer eigenen Sprache beschreiben und den Entwurf freigeben.
Beziehungsnetzwerk
Über gemeinsam genutzte IPs, Geräte, Telefonnummern und E-Mail-Adressen wird ein Beziehungsnetzwerk zwischen Konten erstellt. Typologien, die mehrere Konten an einem gemeinsamen Punkt zusammenführen, wie T-006-2.4 und T-006-2.62, können durch reine Einzelkontenprüfungen nicht erkannt werden.
Fall, Beweise und Kategorie
Ein Alert wird zu einem Fall (Case) mit einem Bearbeiter, einer Frist und Beweisen. Der Fall bildet auch nicht-monetäre Ereignisse ab, kann Transaktionen innerhalb eines Zeitraums als Gesamtsumme darstellen und separate Cluster basierend auf dem Kanal bilden. Die Verdachtskategorie wird aus der Taxonomie von MASAK ausgewählt.
Beweise und Entscheidungsbegründungen werden in einem unveränderlichen Audit Trail protokolliert, die Freigabe nach dem Vier-Augen-Prinzip erfolgt über Maker/Checker, und die für Meldungen mit Aussetzungsantrag erforderlichen Dokumente und Begründungen werden dem Fall beigefügt. Der Entwurf der Meldung wird aus denselben Falldaten erstellt, und die Zeichnungsberechtigung verbleibt beim Institut.
Das Gegenstück auf der Seite der Zahlungsdienste finden Sie auf der Seite Zahlungsinstitute. Relevante Prozesse: Kunden-Onboarding, Fortlaufendes Monitoring, Überweisungen und Meldewesen. Den regulatorischen Rahmen finden Sie auf der Seite MASAK-Pflichten und Informationen zur Bereitstellung auf der Seite On-Premise-Deployment.
Quelle
MASAK, „Leitfaden für Verdachtsmeldungen für Zahlungsinstitute und E-Geld-Institute“, MSK-RHB-ŞİB-006, 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 Risikorichtlinie und den Verpflichtungen des Instituts konfiguriert.
Häufige Fragen
- Wie werden Einzahlungen auf Konten verschiedener Personen von derselben IP-Adresse erkannt?
- IP-Daten müssen beim Onboarding erfasst, im Kundendatensatz gespeichert und kontenübergreifend verglichen werden. Truvali ermittelt das Beziehungsnetzwerk zwischen Konten über gemeinsam genutzte IPs, Geräte, Telefonnummern und E-Mail-Adressen. Dies entspricht der Typologie T-006-2.62 im Leitfaden.
- Kann eine Änderung des Guthabens im Vergleich zum langfristigen Durchschnitt als Regel definiert werden?
- Ja. Die Rule Engine unterstützt flexible Aggregationsfenster. Das bedeutet, dass Regeln, die einen Vergleich mit dem historischen Durchschnitt des Kontos durchführen, in einer einzigen Regel eingerichtet werden können. Der Schwellenwert wird durch die eigene Risikorichtlinie des Instituts bestimmt.
- Wie wird die Nutzung einer Prepaid-Karte zum Kauf von Edelmetallen oder Luxusgütern erkannt?
- Händlerkategoriedaten (Merchant Category Codes) müssen zusammen mit dem Transaktionsdatensatz analysiert werden. Sobald die Kategoriedaten verknüpft sind, kann die Typologie T-006-2.27 aus dem Leitfaden als Regel eingerichtet werden.
- Verlassen Kundendaten das Institut?
- Nicht bei einem On-Premise-Deployment. Die Software läuft auf der eigenen Infrastruktur des Instituts, die Daten verbleiben in den Informationssystemen des Instituts, und die Schlüssel sowie der Audit Trail stehen unter der Kontrolle des Instituts.
- Wer ist die Aufsichtsbehörde für E-Geld-Institute?
- Die operative Aufsichtsbehörde ist die TCMB. Für Geldwäschepflichten ist die Behörde MASAK zuständig.
- Warum konzentriert sich das Risiko auf das Konto und nicht auf die Transaktion?
- Einzelne Ein- und Auszahlungen können unauffällig erscheinen; das Muster zeigt sich erst im auf dem Konto aufgelaufenen Guthaben und im Verhältnis zwischen Ein- und Auszahlungen.
- Wie wird Strukturierung (Structuring) erkannt?
- Die Anhäufung von Beträgen unterhalb der Meldeschwelle über dasselbe Konto oder verknüpfte Konten wird über Aggregationsfenster berechnet, und auch versuchte Transaktionen verbleiben in den Aufzeichnungen.
- Können beim Onboarding erfasste Daten nachträglich generiert werden?
- Nein. E-Mail- und IP-Scores dienen als Input für nachfolgende Regeln und können nicht rückwirkend ermittelt werden, wenn sie nicht bereits beim Onboarding erfasst wurden.