Häufig gestellte Fragen

Die aktive Liveness-Erkennung erfordert eine zufällige Aktion des Nutzers, wie Lächeln, Kopfdrehen oder Blinzeln. Die passive Liveness-Erkennung hingegen analysiert Mikroexpressionen, Tiefe und Reflexionen auf einem einzigen Selfie und trifft dieselbe Entscheidung, ohne dass der Nutzer etwas tun muss. Die passive Methode erhöht die Abschlussquote, während die aktive Methode bei risikoreichen Anträgen zusätzliche Sicherheit bietet.

Das aus dem Chip ausgelesene Foto und die Identitätsdaten sind staatlich signiert und weitaus fälschungssicherer als ein Foto der Dokumentenvorderseite. Wenn der Abgleich mit dem Selfie auf Basis dieses offiziellen Fotos erfolgt, ist der Match-Score wesentlich zuverlässiger.

Nein. Dokumentenprüfung, Chip-Verifizierung, Liveness-Erkennung, Gesichtsabgleich und die regulatorisch konforme Video-Identifikation sind direkt in der Plattform integriert. Sie müssen kein zusätzliches Budget für separate Lizenzen einplanen.

Die gesamte Verifizierung erfolgt in der eigenen Infrastruktur des Unternehmens. Selfies, Dokumentenbilder und Chipdaten werden nicht an externe Cloud-Umgebungen gesendet, was die Erfüllung der Verpflichtungen für sensible Daten im Rahmen der KVKK erleichtert.

Dies ist die natürliche Person, die eine juristische Person letztendlich kontrolliert oder tatsächlich von ihr profitiert. In der Praxis wird in der Regel eine Beteiligung von 25 % oder mehr als Schwellenwert herangezogen. Jedoch werden auch Personen bewertet, die trotz einer geringeren Beteiligungsquote die Kontrolle über Zeichnungsberechtigungen oder die Geschäftsführung ausüben.

KYC verifiziert Privatkunden mittels Ausweisdokumenten, Biometrie und Screening. KYB hingegen verifiziert juristische Personen und erfordert zusätzlich die Entschlüsselung der Eigentümerstruktur, um die dahinter stehenden natürlichen Personen zu ermitteln. Der KYB-Prozess umfasst auch KYC-Prüfungen für jede natürliche Person in der Beteiligungskette.

Sobald eine Änderung erkannt wird, berechnet das System den Risikoscore des Unternehmens neu. Sollte ein neuer Gesellschafter auf einer Sanktionsliste stehen oder als PEP eingestuft sein, wird sofort ein Alarm ausgelöst – ohne dass die nächste periodische Überprüfung abgewartet werden muss.

Die Kette wird so lange verfolgt, bis natürliche Personen erreicht sind; es gibt keine feste Begrenzung für die Anzahl der Ebenen. Strukturen, die nicht aufgelöst werden können oder Schleifen bilden, werden nicht einfach ignoriert, sondern zur manuellen Überprüfung markiert.

Nein. Das Unternehmen legt die Übergabebedingungen basierend auf dem eigenen Risikoappetit fest. In der Regel wird das Gespräch nur bei einem niedrigen Score beim Gesichtsabgleich, Verdachtsmomenten bei Dokumenten oder Treffern bei Screenings ausgelöst. Andere Anträge werden vollständig im automatisierten biometrischen Prozess abgeschlossen.

Wenn Kunden oder Mitarbeiter den Gesprächspartner frei wählen könnten, würde dies die notwendige Sicherheit der Remote-Identitätsprüfung untergraben. Die zufällige Zuweisung aus einem Pool schließt diese Möglichkeit aus, und das Zuweisungsprotokoll dient bei Audits als revisionssicherer Nachweis.

Screenshots und Audioaufzeichnungen werden in der eigenen Infrastruktur des Unternehmens direkt verknüpft mit der jeweiligen Kundenakte gespeichert. Sie werden nicht an Drittanbieter übertragen und bleiben über die gesamte gesetzliche Aufbewahrungsfrist hinweg abrufbar.

Der Eintrag auf einer Sanktionsliste stellt eine rechtliche Einschränkung dar: Transaktionen mit dieser Person sind gesetzlich verboten. Ein PEP-Status hingegen ist kein Verbot, sondern ein Risikoindikator. Die Zusammenarbeit mit einer politisch exponierten Person ist zulässig, erfordert jedoch verstärkte Sorgfaltspflichten (Enhanced Due Diligence).

Schwerwiegende Anschuldigungen gegen eine Person können in der Presse auftauchen, lange bevor sie in offiziellen Listen erfasst werden. Das Adverse-Media-Screening schließt diese Lücke und ermöglicht die vom risikobasierten Ansatz geforderte Früherkennung.

Der Schwellenwert für Übereinstimmungen kann segmentweise angepasst werden, zuvor als Fehlalarm geschlossene Einträge werden gespeichert und Treffer werden dem Compliance-Beauftragten direkt mit einer Voranalyse präsentiert. Das Ziel ist nicht, die Anzahl der Treffer pauschal zu senken, sondern diejenigen hervorzuheben, die tatsächlich geprüft werden müssen.

Globale Sanktionslisten werden täglich aktualisiert. Der gesamte Kundenbestand wird jede Nacht neu gescannt, sodass ein neuer Treffer bereits am nächsten Tag als Warnmeldung vorliegt.

Beide Ansätze sind eng miteinander verwandt. Adverse Media Screening basiert in der Regel auf vorkonfigurierten Inhalten von Datenanbietern. Bei OSINT definiert das Institut die Quellen selbst, sodass auch lokale Medien und Branchenberichte überwacht werden können, die in Standard-Datenpaketen oft fehlen.

Der Abgleich basiert nicht allein auf dem Namen, sondern bezieht weitere vorliegende Identitätsdaten mit ein. Die Ergebnisse werden mit einem Score versehen. Da jeder Befund direkt mit dem Quellartikel verknüpft ist, können Compliance-Beauftragte die Treffer zudem manuell verifizieren.

Das Institut kann dies so konfigurieren. Standardmäßig wird das Profil jedoch als hohes Risiko markiert und ein Alert zur manuellen Überprüfung generiert. Die endgültige Entscheidung hängt von den individuellen Regeln und Szenarien des Instituts ab.

Das zu verfolgende Link-Muster, die Tiefe und die maximale Seitenzahl werden separat definiert. Das Screening erfasst nicht die gesamte Website, sondern nur den durch das Muster definierten Bereich und ist somit klar begrenzt.

Ja. Der Status des Prozesses und der Abschlusszeitpunkt sind einsehbar. Zudem wird die Rohantwort gespeichert, sodass nachträglich überprüft werden kann, was bei der Extraktion ausgelesen wurde.

Ja. Voreinstellungen für Analyse-Prompts sind Strukturen mit einem Namen und einem Template. Sie werden mit Quellen, Feeds und Dokumenten verknüpft. Diese Unterscheidung ist notwendig, da sich beispielsweise die Extraktion von Namen aus einem Amtsblatt grundlegend von der aus einer Kaderliste unterscheidet.

Nein. Es werden Vorname, Nachname, Firmenname, Aliase, Geschlecht, Geburtsdatum, Geburtsjahr und Stadt erfasst. Das Geburtsjahr ist ein separates Feld, da in offiziellen Quellen oft nur das Jahr angegeben ist.

Nein. Ein Datensatz kann entsprechend markiert werden und beide fließen in denselben Screening-Workflow ein. Die Quelle des Eintrags und die zugehörige Behörde bleiben jedoch stets eindeutig unterscheidbar.

Die schwellenwertbasierte Überwachung betrachtet ausschließlich den Betrag, und Betrüger können diese Schwellenwerte leicht herausfinden. Bei der Echtzeit- und risikobasierten Überwachung wird der Betrag zusammen mit dem Kontext des Verhaltens bewertet: Die Historie des Kunden, die Transaktionszeit, die Branche, das Gerät und die Beziehung zur Gegenpartei werden ebenfalls berücksichtigt.

Dies sind Ereignisse, die keinen Geldfluss beinhalten, aber das Risiko verändern: z. B. Logins von einem neuen Gerät, E-Mail-Änderungen oder die Aktualisierung der Gesellschafterstruktur. Ein Großteil der Fälle von Account Takeover beginnt mit einem solchen Ereignis, noch bevor Geld abfließt.

Truvali ist für den Betrieb in Umgebungen mit täglich Millionen von Transaktionen ausgelegt und liefert Entscheidungen in Millisekunden. Rechenintensive Berichtsaufgaben werden im Hintergrund ausgeführt, um den Benutzer nicht zu verzögern.

Eine Warnung wird generiert, wenn ein Ereignis die Bedingungen eines vom Institut definierten Szenarios erfüllt. Die Warnung wird in einen strukturierten Fall zur Untersuchung umgewandelt, in dem ersichtlich ist, welche Regel durch welche Daten ausgelöst wurde.

Nicht periodisch, sondern ereignisbasiert. Bei einer neuen Transaktion, einer Geräteänderung, einer Profilaktualisierung oder einem Screening-Treffer wird der Score sofort neu berechnet.

Ja. Die zum Score beitragenden Signale und deren Gewichtung werden lückenlos protokolliert. Warum eine Entscheidung getroffen wurde, lässt sich direkt im jeweiligen Fall nachvollziehen. Dies ist entscheidend für die Dokumentation des risikobasierten Ansatzes.

Ja. Die Signalwichtungen und Entscheidungsschwellen werden gemäß der Risikopolitik des Instituts konfiguriert. Änderungen können vor der Liveschaltung anhand historischer Daten getestet werden.

Die regelbasierte Erkennung prüft vordefinierte Bedingungen und macht Entscheidungen nachvollziehbar. Die KI-basierte Erkennung hingegen kann unbekannte Muster erkennen, lässt sich jedoch schwerer begründen. Truvali kombiniert beide Ansätze: Ein von der KI gefundenes Muster wird in eine Regel umgewandelt, die vom Menschen freigegeben werden muss.

Meist an Signalen, die dem Geldabfluss vorausgehen: Anmeldung von einem unbekannten Gerät oder einer unbekannten IP, unmittelbar gefolgt von einer Änderung der E-Mail-Adresse oder Telefonnummer sowie Transaktionsversuchen zu ungewöhnlichen Zeiten. Da Truvali auch diese nicht-finanziellen Ereignisse überwacht, kann die Kette noch vor der Geldbewegung unterbrochen werden.

Sie werden in derselben Regel-Engine geschrieben, können jedoch in separate Regelsätze und Berechtigungsgruppen unterteilt werden. So nutzen das Betrugspräventionsteam und das Compliance-Team dieselbe Infrastruktur, ohne die Regeln des jeweils anderen zu beeinflussen.

Nein. Szenarien werden über die Benutzeroberfläche durch das Zusammenstellen von Logikblöcken oder in alltäglicher Arbeitssprache erstellt. Der Expression-Editor ist nur für fortgeschrittene Fälle gedacht, die spezielle Berechnungen erfordern.

Sie sind nicht auf vorgegebene Zeiträume wie Tage oder Monate beschränkt. Es können sowohl freie Zeitfenster wie „die letzten 73 Stunden“ als auch anzahlbasierte Fenster wie „die letzten 15 Transaktionen“ definiert werden.

Ja. Durch das Auslösen eines Callbacks aus der Regel an Ihr Kernsystem kann eine Transaktion ausgesetzt, eine zusätzliche Verifizierung angefordert oder das Konto eingeschränkt werden. Die Liveschaltung der Entscheidung kann je nach den Maker-Checker-Einstellungen Ihres Instituts einer Freigabe unterliegen.

Nein. Eine Regel kann vorab auf Ihren historischen Daten ausgeführt werden, um das zu erwartende Warnungsvolumen und die Falsch-Positiv-Rate (False-Positive-Rate) zu prognostizieren. Weitere Details finden Sie auf der Seite zu Rule Sandbox und Simulation.

Bei der Implementierung werden Ihre historischen Daten in das System migriert, sodass bereits ab dem ersten Tag aussagekräftige Tests möglich sind. Sie wählen den Testzeitraum selbst; längere Zeiträume eignen sich besonders, um saisonale Effekte zu berücksichtigen.

Die Alarme, die eine Regel in der Vergangenheit generiert hätte, werden mit dem tatsächlichen Ausgang ähnlicher Fälle aus diesem Zeitraum abgeglichen. Das Ergebnis ist eine Prognose, bietet jedoch eine weitaus verlässlichere Entscheidungsgrundlage, als eine Regel völlig ungeprüft live zu schalten.

Ja. Das Ausführen einer Regel mit verschiedenen Schwellenwerten und der anschließende Vergleich der Ergebnisse ist der primäre Anwendungsfall der Simulation. So werden Schwellenwerte datenbasiert und nicht durch bloßes Schätzen festgelegt.

Ja. Regeln mit einer dauerhaft hohen Falsch-Positiv-Rate werden automatisch markiert, und das System schlägt Optimierungen für die Schwellenwerte vor. So bleibt Ihr Regelsatz stets präzise und aktuell.

Die generierte Regel geht nicht direkt live. Sie wird mit ihren Parametern auf dem Bildschirm angezeigt, sodass Sie sie korrigieren und auf historischen Daten simulieren können. Zudem unterliegt die Aktivierung einem Freigabeprozess.

Compliance- und Risikoterminologie: Ausdrücke wie Altersgrenzen, Formatierungen von Identifikationsnummern, Aktivitätscodes, Zeitfenster und Betragsschwellenwerte werden aus dem Kontext erschlossen. Der Begriff „minderjährig“ wird in eine Altersbedingung übersetzt, „ausländische Identität“ in Bedingungen bezüglich Identifikationsnummer und Staatsangehörigkeit.

Die meisten Szenarien erfordern keinen Code. Für fortgeschrittene Fälle, die spezielle Berechnungen erfordern, bietet die Rule Engine einen Formeleditor – dies ist jedoch keine Pflicht, sondern eine zusätzliche Option.

Ein Alert ist ein technisches Ergebnis, das anzeigt, dass eine Regel ausgelöst wurde. Ein Case ist ein Vorgang, der zur Untersuchung dieses Alerts erstellt wird und einen zugewiesenen Bearbeiter, eine Frist sowie eine Entscheidungsbegründung enthält. Bei Prüfungen wird nicht nach der Anzahl der Alerts gefragt, sondern danach, wie die Fälle gelöst wurden.

Wenn ein Spezialist (Maker) einen Fall schließt oder eine Regel veröffentlicht, geht der Vorgang zur Genehmigung an einen vordefinierten Pool von Freigabeberechtigten (Checker). Ohne diese Genehmigung wird die Entscheidung nicht wirksam; im Moment der Freigabe wird ein Callback an das Hauptsystem gesendet.

Das Alter der Fälle wird überwacht, bald ablaufende Fälle werden markiert und bei Bedarf an das Management eskaliert. Da die Warteschlange nach Risikoscore sortiert werden kann, lässt sich die begrenzte Zeit gezielt für die risikoreichsten Fälle nutzen.

Nein. Alerts, die auf derselben Ursache beruhen, können gesammelt geschlossen werden, wobei die gemeinsame Begründung für alle übernommen wird. Dies verhindert, dass wiederkehrende Ereignisse die Untersuchungskapazitäten blockieren.

Nein. Die Voranalyse ist eine Empfehlung. Die Entscheidung trifft der Compliance-Beauftragte, der auch seinen eigenen Kommentar hinzufügt. Bei risikoarmen Fällen kann ein Schließen mit einem Klick vorgeschlagen werden, was jedoch ebenfalls einem Genehmigungsprozess unterliegt.

Ja. Es wird klar dargelegt, auf welchen Signalen die Bewertung basiert: ausgelöste Regel, Kundenhistorie, IP- und Gerätemuster. Dies ermöglicht es, bei Audits die Entscheidungsfindung lückenlos nachzuvollziehen.

Nein. Die Analyse läuft lokal in der eigenen Infrastruktur des Unternehmens. Kundendaten, Transaktionsdetails und Fallinhalte werden nicht an externe Cloud-Umgebungen übermittelt.

Sie sollten als Entwürfe verwendet werden. Meist sind sie zu eng oder zu weit gefasst; die Schwellenwerte müssen an den Risikoappetit des Unternehmens angepasst und mittels Simulation getestet werden.

Ein Muster kann bereits aus einem einzigen Fall abgeleitet werden. Werden jedoch mehrere ähnliche Fälle bereitgestellt, lassen sich gemeinsame Elemente zuverlässiger isolieren, was zu präziseren Regeln führt.

Eine vorgefertigte Bibliothek deckt allgemeine Branchentypologien ab. Regeln, die aus historischen Fällen generiert werden, basieren hingegen auf tatsächlichen Angriffen auf Ihr Produkt und Ihren Kundenstamm. Beide Ansätze schließen sich nicht aus, sondern ergänzen einander.

Nein. Es wird lediglich ein Entwurf erstellt, den der Compliance-Officer prüft, korrigiert und freigibt. Das Institut trägt die alleinige Verantwortung für den Inhalt und die Übermittlung der Meldung; das System übernimmt diese Verantwortung nicht.

Nein. Sie können Berichte direkt über die Benutzeroberfläche durch Auswahl von Feldern und Filtern erstellen oder sie einfach in natürlicher Sprache beschreiben. Das System generiert die Abfrage automatisch.

Ja. Berichte können für eine tägliche, wöchentliche oder monatliche Ausführung geplant und als PDF oder Excel an die entsprechenden Empfänger weitergeleitet werden.

Das Unternehmen legt fest, welche Aktionen einer Freigabe bedürfen. Die Veröffentlichung von Regeln und das Schließen von Fällen sind die beiden am häufigsten genutzten Schritte. Berechtigungsgruppen und Freigabepools werden gemäß der eigenen Hierarchie des Unternehmens definiert.

Nein. Die Protokolle werden revisionssicher aufbewahrt, und die Integrität des Archivs wird durch Hash-Werte überprüft. Freigaben werden mit einem rechtlich gültigen Zeitstempel versehen.

Bis auf Bildschirm-, Schaltflächen- und Datenebene. Ein Benutzer kann beispielsweise einen Bildschirm sehen, aber eine bestimmte Aktion darauf nicht ausführen; sensible Felder können maskiert dargestellt werden.

Ja. Datenquellen werden unabhängig voneinander verwaltet, und jede Abteilung sieht nur ihre eigenen Quellen, Regelsätze und Warnmeldungen.

Ja. Die gesamte Analyseebene, einschließlich Fallvoranalyse, Open-Source-Recherche und Berichterstellung, läuft auf den eigenen Servern des Unternehmens. Kundendaten werden nicht an externe Dienste übermittelt.

Die Plattform ist darauf ausgelegt, große Datenmengen mit begrenzten Ressourcen zu verarbeiten. Das Scoring von Millionen von Datensätzen wird mit einer moderaten Serverkonfiguration in Millisekunden abgeschlossen. Die genauen Anforderungen werden gemeinsam auf Basis Ihres Transaktionsvolumens ermittelt.

Diese werden vor dem Go-Live in das System migriert. So arbeiten Ihre Szenarien, die historische Zeitfenster (z. B. „die letzten 6 Monate“) nutzen, vom ersten Tag an mit Ihren echten Daten.

Neue Versionen werden während geplanter Wartungsfenster in der eigenen Umgebung des Unternehmens eingespielt. Dass die Installation ohne Internetverbindung betrieben wird, steht dem Update-Prozess nicht im Weg.

Ja. Das Field Mapping ist dynamisch und stellt Verbindungen her, ohne das eigene Datenmodell der Bank zu verändern. Auch Karten-, Kredit- und Filialdaten können mit derselben Kundenansicht verknüpft werden; ein Teil der Typen im Leitfaden erfordert bereits die gemeinsame Analyse dieser Systeme.

Der Leitfaden besagt das Gegenteil: Verpflichtete sollten sich nicht auf die aufgelisteten Typen beschränken und müssen jede Transaktion melden, die einen Verdacht erregt, selbst wenn sie mit keinem der Typen übereinstimmt. Die Typen stellen eine Mindestbasis dar, keine Obergrenze.

Nicht bei einer On-Premise-Bereitstellung. Die Software läuft auf der bankeigenen Infrastruktur, die Daten verbleiben in den Informationssystemen der Bank, und Schlüssel sowie der Audit Trail stehen unter der Kontrolle der Bank. Cloud und Private Cloud sind ebenfalls Optionen; die Entscheidung liegt bei der Bank.

Ja. Die Regel wird in einer Regelsimulation auf historischem Datenverkehr ausgeführt, um das zu erwartende Alert-Volumen zu sehen. Sie können auch ein beliebiges Datum angeben und das Ergebnis für den Datenverkehr dieses Tages anzeigen lassen.

Die Aufsichtsbehörde für Bankaktivitäten ist die BDDK. Der Partner für Verpflichtungen zur Bekämpfung von Geldwäsche und Terrorismusfinanzierung ist MASAK.

Die meisten Indikatoren erfordern die gemeinsame Analyse von Kunden-, Konto-, Transaktions- und Kanaldaten; bei Banken befinden sich diese Daten in der Regel in separaten Systemen.

Das Beziehungsnetzwerk zwischen Konten wird über gemeinsame IPs, Geräte, Telefonnummern, Adressen und Gegenparteien abgebildet; dies macht Cluster sichtbar, die bei der Betrachtung einzelner Konten nicht erkennbar wären.

Die Anwendung sendet Ereignisse, und das System gibt den Score und die Entscheidung zurück. Auch nicht-finanzielle Ereignisse durchlaufen denselben Pfad und werden in Regeln verwendet.

Das hängt von Ihrer Lizenz ab: die TCMB für E-Geld und Zahlungsdienste, die BDDK für Kreditvergabe und Finanzierung sowie die SPK für Krypto-Assets und Kapitalmarkt-Brokerage. Für Geldwäschepflichten ist stets die MASAK zuständig.

Indem sichergestellt wird, dass Regeländerungen keine Entwickler-Tickets erfordern. Kontrollen werden in eigenen Worten verfasst, Entwürfe in einer Simulation getestet und nach der Freigabe direkt in die Produktion übernommen.

Mit wachsendem Kundenstamm steigt die Anzahl der Alerts. Ab einem bestimmten Punkt kann das Team diese nicht mehr realistisch prüfen. Alerts werden dann geschlossen, jedoch ohne ausreichende Begründung, was bei Audits auffällt.

Nicht, wenn sich die Kontrolltiefe dem Risiko anpasst. Für Anträge mit geringem Risiko wird eine vereinfachte Sorgfaltspflicht angewendet, während für Anträge mit hohem Risiko verstärkte Sorgfaltspflichten gelten – wobei der Unterschied als Regel definiert ist.

Der Anbieter und die Struktur der E-Mail-Adresse, ob die IP-Adresse ein Proxy oder VPN ist und ob sich andere Anwendungen vom selben Gerät oder derselben Adresse aus verbinden.

Nein. Sie erstellt bei der Fallbearbeitung eine erste Einschätzung, während die endgültige Entscheidung beim Menschen verbleibt und mitsamt Begründung dokumentiert wird.

Wenn Onboarding-Akte, Transaktionshistorie und Fall im selben Datensatz liegen, entfallen Integrationskosten und der Aufwand für die Datenerfassung bei Audits.

Ja. Der neue Schwellenwert wird mit historischem Datenverkehr abgeglichen, um vor dem Live-Gang zu sehen, wie viele Alerts er erzeugen wird.

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.

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.

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.

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.

Die operative Aufsichtsbehörde ist die TCMB. Für Geldwäschepflichten ist die Behörde MASAK zuständig.

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.

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.

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.

Nein. Die meisten Händlertypen im Leitfaden werden aus Daten abgelesen, die erst nach der Anbindung des Händlers entstehen: Chargeback-Quoten, die Dichte runder Beträge, das Volumen im Verhältnis zum Branchenmittelwert und der Transfer von Guthaben an Dritte. KYB beginnt mit dem Onboarding und setzt sich in der kontinuierlichen Überwachung fort.

Ja. Wenn eine Website-Adresse angegeben wird, kann die Seite vollständig gescannt, ihr Inhalt extrahiert und Adverse-Media- sowie Open-Source-Einträge über den Händler nach Risikotyp klassifiziert werden. Die Typen T-006-2.28, T-006-2.35 und T-006-2.40 im Leitfaden erfordern dies.

Nicht bei einer On-Premise-Bereitstellung. 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.

Der Leitfaden besagt das Gegenteil: Verpflichtete sollten sich nicht auf die aufgelisteten Typen beschränken und müssen jede Transaktion melden, die einen Verdacht erregt, selbst wenn sie auf keinen der Typen zutrifft. Die Typen stellen eine Mindestbasis dar, keine Obergrenze.

Die operative Aufsichtsbehörde ist die TCMB. Für Geldwäscheverpflichtungen ist die zuständige Behörde MASAK.

Das Institut ist für die Aktivitäten des Händlers und deren Rechtmäßigkeit verantwortlich; das Risiko konzentriert sich weitgehend darauf, was der Händler verkauft.

Dies ist ein bekanntes Problem in der Branche und einer der ersten Punkte, die bei der Überwachung geprüft werden: Abweichungen beim Volumen, der Produktkategorie und den Chargeback-Quoten verändern die Risikoklassifizierung.

Abweichungen des Transaktionsvolumens von den Angaben, steigende Chargeback-Quoten, Änderungen der Produktkategorien und Änderungen der Eigentümerstruktur.

Ja. MASAK veröffentlicht einen speziellen Leitfaden für Verdachtsmeldungen für diesen Sektor und erwartet, dass Meldungen elektronisch über MASAK.Online eingereicht werden.

Der Leitfaden besagt das Gegenteil: Verpflichtete dürfen sich nicht auf die aufgelisteten Typen beschränken und müssen auch dann eine Meldung einreichen, wenn eine verdächtige Transaktion mit keinem von ihnen übereinstimmt. Die Typen sind eine Mindestbasis, keine Obergrenze.

Nein. Wenn der Server, auf dem das Konto eröffnet wurde, und die IP des ersten Logins in diesem Moment nicht erfasst werden, können sie nachträglich nicht mehr abgerufen werden. Ein Teil der Typen im Leitfaden stützt sich direkt auf diese Erstkontaktdaten.

T-010-2.36 betrachtet einen Kunden, der eine Rolle oder Position innehat, die das Ergebnis des von ihm gespielten Spiels beeinflussen könnte, als Verdachtsindikator. Truvali unterstützt die Erstellung interner Listen für diese Personen und deren Integration in den Screening-Workflow.

Ja. Betreiber im Bereich Glücksspiel und Wetten sind Verpflichtete nach dem Gesetz Nr. 5549 und unterliegen dem branchenspezifischen Leitfaden von MASAK.

Bei einem aus der Ferne eröffneten Spielerkonto sind E-Mail, Telefon und IP oft die einzigen verifizierbaren Informationen, die zur Verfügung stehen: Wenn diese Daten beim Onboarding nicht erfasst werden, können sie nachträglich nicht mehr generiert werden.

Der Leitfaden führt die Berufsangabe als Indikator auf: Ein Missverhältnis zwischen dem angegebenen Beruf und dem Spielvolumen erregt Verdacht. Der Beruf ist kein Feld, das einfach im Onboarding-Formular verbleibt, sondern dient als Input für Regeln.

Cluster von Konten, die sich über dasselbe Gerät, dieselbe IP, dasselbe Zahlungsmittel und ähnliche E-Mail-Adressen verbinden, werden über Beziehungsnetzwerke aufgedeckt.

Ja. Der Screening-Workflow verarbeitet die Wallet-Adresse neben dem Namen der Person, und das Institut kann eigene Adresslisten erstellen. Typ T-010-2.8 des Leitfadens deckt Transferversuche an Personen oder Adressen auf Verbots- oder Fahndungslisten ab.

Über die Zieladresse muss ein Beziehungsnetzwerk zwischen den Kunden ermittelt werden. Dies kann nicht durch die Betrachtung eines einzelnen Kontos erkannt werden. Dies entspricht Typ T-010-2.27 des Leitfadens.

Die Adresse und die Plattform der Gegenpartei müssen klassifiziert werden. Diese Daten stammen aus den eigenen Systemen des Instituts oder integrierten Datenquellen; die Rule-Engine kombiniert dies mit zeitabhängigen Bedingungen.

Nicht bei einer On-Premise-Bereitstellung. 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.

In der Türkei ist die SPK die operative Aufsichtsbehörde. In Bezug auf Geldwäscheverpflichtungen ist MASAK die zuständige Behörde.

Nein. Die Wallet-Adresse wird im Screening-Workflow als eigenständiges Objekt neben dem Namen der Person verarbeitet; On-Chain- und Off-Chain-Daten fließen in derselben Kundenansicht zusammen.

Direkte Sanktionstreffer, die Nähe zu einer gelisteten Adresse, die Interaktion mit Mixern, Cluster-Beziehungen und der Weg der Gelder.

Ja. Die Definition der direkten Aufsicht in der Verordnung (EU) 2024/1620 listet Kryptodienstleister explizit auf.

Der Leitfaden definiert seinen Anwendungsbereich um Vermittlungsdienstleister, also Plattformen, auf denen Dritte Verkäufe tätigen. Ein Unternehmen, das seine eigenen Produkte auf der eigenen Website verkauft, ist nicht das direkte Ziel, aber die meisten der aufgeführten Indikatoren haben Entsprechungen in jeder E-Commerce-Struktur, die Zahlungen akzeptiert.

Der Leitfaden listet unter T-020-2.21 eine ungewöhnlich hohe Anzahl von Retourentransaktionen auf, und unter T-020-2.31 die Verwendung gefälschter Karten zusammen mit der Aufdeckung von Käufen gefälschter Produkte. Betrugsprävention und Geldwäschebekämpfung betrachten dieselben Daten.

Vier Typen im Leitfaden stehen in direktem Zusammenhang mit Produkten und Preisen: der Verkauf verbotener Produkte, Preise außerhalb des Marktwerts, häufige und plötzliche Preisänderungen sowie der Versand anderer oder gefälschter Produkte anstelle des bestellten Artikels. Ein System, das nur den Zahlungsfluss betrachtet, wird keinen dieser Indikatoren erkennen.

Nicht bei einer On-Premise-Bereitstellung. 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.

Ja. Sie sind Verpflichtete nach dem Gesetz Nr. 5549 und unterliegen dem entsprechenden Branchenleitfaden von MASAK.

Nicht in der Transaktion selbst, sondern in der Echtheit des Produkts, dem Preis und den beteiligten Parteien. Die Zahlung für ein Produkt, das tatsächlich nie geliefert wird, wird als regulärer Verkauf verbucht.

Ja. Produktkategorie, Preis und Warenkorbinhalt sind Regeleingaben; ein Preis, der erheblich vom Marktwert abweicht, ist ein Indikator.

Ja. Das Beziehungsnetzwerk zwischen den Parteien wird über gemeinsam genutzte Geräte, IPs, Zahlungsmittel und Adressen abgebildet.

Nein. Das Kreditrisiko betrifft die Frage, ob der Kreditnehmer den Betrag zurückzahlen wird, während das Betrugsrisiko prüft, ob der Antrag echt ist. Ein Antrag mit hervorragender Bonität kann dennoch mit einer gestohlenen Identität gestellt worden sein.

Eine Identität, die aus echten und erfundenen Informationen kombiniert wird, baut zunächst eine Kredithistorie auf und leistet eine Zeit lang regelmäßige Zahlungen. Daher bilden Geräte-, Netzwerk- und E-Mail-Signale eine von der Kredithistorie unabhängige Kontrollschicht.

Sie beginnt mit dem Auslesen von Dokumenten: Das Auslesen von Chips via NFC bei Ausweisdokumenten, Liveness-Prüfungen (Lebenderkennung) und Gesichtsabgleich validieren sich gegenseitig. Wer ein Dokument kopiert, kann dennoch nicht sowohl die Chip- als auch die Liveness-Prüfung umgehen.

Der Text des hochgeladenen Dokuments wird ausgelesen. Die darin enthaltenen Beträge, Daten und Parteiinformationen werden in strukturierte Daten umgewandelt, um sie direkt mit den Angaben im Antrag abzugleichen.

Ja. Anträge, die vom selben Gerät, derselben IP-Adresse oder mit ähnlichen E-Mail-Adressen eingehen, werden über ein Beziehungsnetzwerk aufgeschlüsselt: Ist ein Antrag verdächtig, werden auch alle damit verknüpften Anträge überprüft.

Ja. Die Identitätsprüfung, die Ermittlung des wirtschaftlich Berechtigten (UBO), Sanktions- und PEP-Screening sowie Verdachtsmeldungen sind obligatorisch. Die zuständige Aufsichtsbehörde des Instituts ist die BDDK.

Eine unerwartete vorzeitige Rückzahlung in einer Summe wirft Fragen zur Herkunft der Mittel auf und unterliegt der Überwachung.

Ja. Wie viele Anträge eine neue Regel ablehnen wird und wie viele davon tatsächlich Betrugsversuche sind, wird vor der Liveschaltung anhand des historischen Antragsaufkommens gemessen.

Ja. Der Kunde tritt die Forderung ab, aber der Debitor ist die Partei, die sie bezahlt. Daher werden beide gegen Sanktions- und PEP-Listen geprüft und beide erhalten einen Risikoscore. Bei einem Scheck oder Wechsel werden auch der Aussteller und die Indossanten überprüft.

Der Kunde wird einmalig onboarded, aber sein Debitorenportfolio ändert sich mit jeder Abtretung. Eine beim Onboarding geprüfte Liste ist schon bei der zweiten Transaktion veraltet. Daher läuft die Überprüfung kontinuierlich und wird erneut ausgelöst, sobald ein Name nachträglich auf einer Liste erscheint.

Der Text der Rechnung wird ausgelesen, und Betrag, Datum sowie Parteiinformationen werden in strukturierte Daten umgewandelt. Diese werden mit der angegebenen Branche und dem Umsatz des Kunden sowie dem Rest seines Portfolios abgeglichen. Ein wiederkehrender Betrag, der zwischen verbundenen Unternehmen zirkuliert, wird durch Regeln für Kreisgeschäfte (Circular Invoicing) erkannt.

Ja. Identitätsprüfung, Feststellung des wirtschaftlich Berechtigten, Sanktions- und PEP-Prüfung, kontinuierliches Monitoring und Verdachtsmeldungen sind Pflichten, und jede einzelne muss mit einem Protokoll darüber nachgewiesen werden, wann und von wem sie durchgeführt wurde.

Eine Schuld, die lange vor Fälligkeit oder von einem Dritten statt dem eigentlichen Debitor beglichen wird, wirft Fragen zur Herkunft der Mittel auf. Beide Fälle sind als Regeln hinterlegt, sodass sie automatisch als Alerts gemeldet werden, anstatt manuell aufzufallen.

Ja. Screening, KYB, Monitoring und Case Management nutzen dieselbe Rule Engine und denselben Audit Trail. So wird verhindert, dass Entscheidungen über einen Kunden und seinen Debitor in zwei voneinander isolierten Systemen getroffen werden.

Die Richtlinie definiert ihren eigenen Anwendungsbereich für Versicherungs- und Rückversicherungsmakler. Die meisten der aufgeführten Indikatoren ergeben sich aus der Natur der Maklerbeziehung und gelten für die gesamte Versicherungskette, aber die Richtlinie richtet sich speziell an Makler.

Eine Änderung des Begünstigten, des Vertreters oder der Zahlungsquelle löst eine neue Überprüfung und eine neue Risikobewertung aus. Die am ersten Tag getroffene Entscheidung bleibt nicht statisch.

Ja. Alle vier, einschließlich des Vertreters, werden als separate Parteien erfasst und gegen Sanktions-, PEP- und interne Listen geprüft. Bei juristischen Personen wird die Eigentümerstruktur aufgelöst, um den wirtschaftlich Berechtigten (UBO) zu identifizieren.

Die Zahlungsquelle wird erfasst und zusammen mit der Parteienstruktur verglichen. Die Typen T-012-2.15 und T-012-2.16 der Richtlinie decken den Zweck der Verschleierung der Mittelherkunft und Zahlungen über Einheiten in Ländern ab, die als Steueroasen bekannt sind.

Nicht bei einer On-Premise-Bereitstellung. 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.

Die entsprechende MASAK-Richtlinie richtet sich in Bezug auf ihren Anwendungsbereich speziell an Versicherungs- und Rückversicherungsmakler.

Nicht in der Zahlung der Prämie, sondern darauf, in wessen Namen, mit wessen Mitteln und aus welchem Grund die Police abgeschlossen wird. Vorzeitige Stornierung und Übertragung sind ebenfalls Indikatoren.

Der Versicherungsnehmer, der Versicherte und der Begünstigte werden als separate Parteien erfasst und jeweils gegen Sanktions-, PEP- und interne Listen geprüft.

Nein. Änderungen der Begünstigten, vorzeitige Stornierungen, Zusatzprämien und Übertragungen finden später statt und unterliegen dem Monitoring.

Die Mehrheit der sektorspezifischen Typen des Leitfadens konzentriert sich auf den Händler. Umsatzspitzen, unvollständige oder fehlerhafte Registrierungsdaten, manipulierte Bewertungen, Untätigkeit bei Beschwerden und plötzliche Aktivität nach längerer Inaktivität werden einzeln aufgeführt.

Unter T-020-2.26 betrachtet der Leitfaden die Erkennung von unrealistischen positiven Bewertungen oder manipuliertem Feedback über einen Händler als Verdachtsindikator. Dies bedeutet, dass das eigene Reputationssystem der Plattform ebenfalls eine zu überwachende Datenquelle darstellt.

Ja. Die Verschleierung des wirtschaftlich Berechtigten (UBO), die Steuerung der Transaktion durch eine dritte Partei, die nicht in den Dokumenten aufgeführt ist, und komplexe, länderübergreifende Strukturen sind separate Typen im Leitfaden. Sie können nicht gelöst werden, ohne die Eigentümerstruktur des Unternehmens hinter dem Shop aufzudecken.

Nicht bei einer On-Premise-Bereitstellung. Die Software läuft auf der eigenen Infrastruktur der Plattform, die Daten verbleiben in den Informationssystemen der Plattform, und die Schlüssel sowie der Audit Trail werden von der Plattform kontrolliert.

Da er Transaktionen für Waren erleichtert, die er nicht selbst verkauft, ist er für die Überprüfung der Echtheit sowohl des Händlers als auch des Käufers verantwortlich; er ist ein Verpflichteter nach dem Gesetz Nr. 5549.

Identität und Eigentümerstruktur, Aktivitätskategorie, Übereinstimmung zwischen den deklarierten Informationen und dem öffentlichen Auftritt sowie Verbindungen zu zuvor geschlossenen Händlerkonten.

Ja. Ein Beziehungsnetzwerk, das über gemeinsam genutzte Geräte, IPs, Zahlungsmethoden und Adressen aufgebaut wird, deckt diese Verbindungen auf.

Ja. Plattformspezifische Felder wie Produktkategorie, Preis, Versand und Rücksendeverhalten werden als Regeleingaben verwendet.

Nicht durch seine Höhe, sondern durch die Beziehung zwischen den Parteien. Sender, Empfänger, Häufigkeit, Land, Transaktionshistorie und Zeitfenster werden gemeinsam analysiert.

Unternehmen, die Geldtransferdienste anbieten, arbeiten in der Regel unter einer Zahlungsinstitutslizenz und unterliegen den MASAK-Richtlinien für Zahlungs- und E-Geld-Institute.

Ja. Die Richtlinie deckt auch Versuche beim Structuring ab; abgelehnte und unvollständige Transfers verbleiben in den Aufzeichnungen. Da Ereignisse mittels Upsert-Logik erfasst werden, erzeugen Aktualisierungen keine neuen Datensätze, sondern bewerten den bestehenden Datensatz neu.

Ja. Beide werden als separate Parteien erfasst und gegen Sanktionslisten, PEP und interne Listen abgeglichen.

Ja, aber nicht durch die Betrachtung eines einzelnen Senderkontos. Das Beziehungsnetzwerk um das Ziel herum muss anhand von gemeinsamen IPs, Geräten, Telefonnummern, E-Mails und Gegenparteien extrahiert werden.

Der Transfer von Geldern, die an Geldautomaten in verschiedenen Provinzen eingezahlt und auf ein einziges Konto geleitet wurden, sowie die Abhebung von Einzahlungen auf ein inaktives Konto an Geldautomaten im Höchstbetrag sind in der Richtlinie separate Typologien; sie können ohne Kanalinformationen nicht analysiert werden.

E-Mail- und IP-Scores. Die Richtlinie betrachtet das Einzahlen von Geldern auf Konten verschiedener, nicht miteinander verbundener Personen von denselben IPs aus als Indikator, und diese Daten können später nicht mehr generiert werden.

Aus denselben Falldaten. Die Entscheidung wird mit ihrer Begründung und den Beweisen mit dem Fall verknüpft, und die Zeichnungsberechtigung verbleibt beim Institut.

Im KYB-Flow wird die Struktur entschlüsselt, um den wirtschaftlich Berechtigten (UBO) zu identifizieren, und jede Ebene wird einzeln erfasst. Die Typen T-011-2.11 und T-011-2.13 des Leitfadens erfordern dies.

Nein, sie werden nicht durch eine automatisierte Regel erzeugt. Die Beobachtung des Kundenbetreuers wird dem Fall als Notiz hinzugefügt, zusammen mit den Beweisen gespeichert und in die Begründung der Meldung aufgenommen.

Nein, er deckt Investmentfonds ab. Das Gewicht der aufgeführten Indikatoren weist jedoch auf eine gemeinsame Herausforderung für Kapitalmarktinstitute hin: die Identifizierung der tatsächlichen Person hinter der Transaktion.

Nicht bei einer On-Premise-Bereitstellung. 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.

Die operative Aufsichtsbehörde ist die SPK. In Bezug auf die Verpflichtungen zur Bekämpfung der Geldwäsche ist die Behörde die MASAK.

Nicht im Gewinn der Transaktion, sondern darin, auf wessen Namen das Konto eröffnet wird, und in der wirtschaftlichen Logik der Transaktion. Mit Verlust oder ohne wirtschaftliche Rechtfertigung durchgeführte Transaktionen sind Indikatoren.

Sie wird Ebene für Ebene bis zum wirtschaftlich Berechtigten (UBO) entschlüsselt; jede natürliche Person in der Kette wird einer Sanktions- und PEP-Prüfung unterzogen.

Ja. Ein Bulletin, ein Entscheidungstext oder eine PDF-Liste wird hochgeladen; der Text wird ausgelesen und die darin enthaltenen Personen und Einheiten werden in strukturierte Datensätze umgewandelt.

Der Evaluierung des MONEYVAL-Ausschusses des Europarates zur Bekämpfung von Geldwäsche und Terrorismusfinanzierung.

Nein. Jedes Land wird als separate Datenquelle definiert: Dieselbe Bereitstellung hostet unterschiedliche Regelsätze, und der Schwellenwert eines Landes hat keinen Einfluss auf den eines anderen.

Der risikobasierte Ansatz, die Kundenidentifizierung, die Identifizierung des wirtschaftlich Berechtigten (UBO) und Verdachtsmeldungen teilen einen gemeinsamen Rahmen. Meldeschwellen, Berichtsformate, Aufbewahrungsfristen und die Erwartungen der Behörden variieren.

Ja. Da sich beide im Prozess der Angleichung an den EU-Besitzstand befinden, setzt der durch die Verordnungen (EU) 2024/1620, (EU) 2024/1624 und die Richtlinie (EU) 2024/1640 geschaffene Rahmen ihr Compliance-Ziel.

Ab dem 1. Juli 2025. Sie beaufsichtigt direkt ausgewählte Verpflichtete im Finanzsektor, einschließlich Krypto-Dienstleistern.

Dies wird in der Rule Engine abgebildet: Verschachtelte Logik, benannte Aggregationsdefinitionen und Callbacks aus Regeln werden unterstützt. Die Regel kann in Ihrer eigenen Sprache beschrieben und vor der Liveschaltung mit historischem Datenverkehr getestet werden.

Bitrelic hat ein Team in Podgorica: Durch unsere physische Präsenz in der Region verfolgen wir regulatorische Änderungen und die Erwartungen der Behörden direkt vor Ort.

Bei einer On-Premise-Bereitstellung in den eigenen Informationssystemen des Instituts: Schlüssel und der Audit Trail stehen unter der Kontrolle des Instituts. Da die Regeln zur Datenresidenz von Land zu Land variieren, ist dies ein entscheidender Faktor bei regionalen Bereitstellungen.

Nein. Jedes Land wird als separate Datenquelle definiert; dieselbe Implementierung unterstützt unterschiedliche Regelsätze, und der Schwellenwert eines Landes hat keinen Einfluss auf ein anderes.

Es ist die Diversität, nicht die Einhaltung einer einzelnen Regulierung. Meldeschwellen, Anforderungen an die Identitätsprüfung, Aufbewahrungsfristen und die Erwartungen der Behörden variieren von Land zu Land.

Nein. Der Anteil ausländischer Kunden, das Gewicht von Rücküberweisungen von Arbeitsmigranten und die Bargeldgewohnheiten variieren selbst innerhalb der Region; ein Transaktionsvolumen, das in einem Land normal ist, kann in einem anderen ein Verdachtsmoment darstellen.

Überweisungen in oder aus Hochrisikoländern, die innerhalb eines bestimmten Zeitrahmens ohne plausible Erklärung erhebliche Beträge erreichen, sind ein gängiger Indikator; der Kontext von Sender und Empfänger, das Zeitfenster und die Wiederholungsrate werden gemeinsam analysiert.

Ja. Wenn Überweisungs- und Transferströme mehrere Jurisdiktionen durchlaufen, muss die Transaktion unter Umständen parallel an zwei unterschiedlichen regulatorischen Systemen gemessen werden.

Dies wird in der Rule Engine abgebildet: Verschachtelte Logik, benannte Aggregationsdefinitionen und Callbacks aus Regeln werden unterstützt. Die Regel wird vor dem Live-Gang mit historischem Datenverkehr getestet.

Kundenakten, Screening-Infrastruktur, Case Management, Audit Trail und Berichtserstellung verbleiben an einem zentralen Ort; es wird kein separates System für jedes Land implementiert.

Bei einer On-Premise-Implementierung innerhalb der eigenen Informationssysteme des Instituts; Schlüssel und der Audit Trail stehen unter der Kontrolle des Instituts.

Das Gesetz Nr. 6698 regelt den Schutz personenbezogener Daten, die bei Analysen verwendet werden. Die Einstufung biometriser Daten als besondere Kategorie und die Beschränkung internationaler Übertragungen auf einen Angemessenheitsbeschluss sind zwei entscheidende Punkte.

Ja. Der zweite Absatz von Artikel 12 des Gesetzes sieht eine gesamtschuldnerische Haftung bei der Ergreifung von Maßnahmen vor, wenn Daten von einer anderen Partei im Auftrag des Datenverantwortlichen verarbeitet werden.

Ja. Artikel 6 des Gesetzes stuft biometrische Daten als besondere Kategorie ein und verbietet im Prinzip deren Verarbeitung: Eine Verarbeitung ist nur unter einer der festgelegten Bedingungen zulässig.

Gemäß Artikel 9 können Daten übertragen werden, wenn eine der Bedingungen in den Artikeln 5 und 6 erfüllt ist und ein Angemessenheitsbeschluss für das Land, den Sektor oder die internationale Organisation vorliegt, in die die Übertragung erfolgen soll.

Er wird von der Behörde erlassen, im Amtsblatt veröffentlicht und mindestens alle vier Jahre neu bewertet.

Der fünfte Absatz von Artikel 12 des Gesetzes verlangt, dass im Falle einer unrechtmäßigen Erlangung von Daten die Situation der betroffenen Person und der Behörde so schnell wie möglich gemeldet werden muss.

Ja. Zugriffe werden im Audit-Trail erfasst: Rollen- und Berechtigungsdefinitionen, Genehmigungsrichtlinien und Kompetenzdelegationen werden separat protokolliert, und das Protokoll kann an ein separates Ziel exportiert werden.

Das Dokumentenbild, die aus dem Chip ausgelesenen Daten, das Selfie, das Liveness-Video und die Gesprächsaufzeichnung werden separat aufgezeichnet: Erfassungszeitpunkt, die Prüfung, in der sie verwendet werden, und die Aufbewahrungsfrist können für jedes Element individuell verwaltet werden.

Artikel 25, der den Datenschutz durch Technikgestaltung (Data Protection by Design) regelt; Artikel 32, der die Sicherheit der Verarbeitung auflistet; und Artikel 9, der biometrische Daten als besondere Kategorie einstuft.

Die Verwendung von Pseudonymen und Verschlüsselung; die Fähigkeit, die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit von Systemen und Diensten sicherzustellen; die Fähigkeit, den Zugang bei einem Zwischenfall rasch wiederherzustellen; und ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der Maßnahmen.

Es ist nicht ausreichend. Artikel 32 Absatz d fordert eine regelmäßige Überprüfung, Bewertung und Evaluierung der Wirksamkeit der Maßnahmen.

Ja. Artikel 9 untersagt im Prinzip die Verarbeitung von biometrischen Daten zur eindeutigen Identifizierung einer natürlichen Person und erlaubt sie nur unter bestimmten Bedingungen.

Artikel 25 fordert, dass bereits zum Zeitpunkt der Festlegung der Verarbeitungsmittel Maßnahmen getroffen werden; die Wahl des Bereitstellungsmodells fällt in diesen Bereich. Bei einer On-Premise-Bereitstellung verbleiben die Daten in den Informationssystemen der Organisation und die Schlüssel stehen unter der Kontrolle der Organisation.

Durch Zugriffs-, Entscheidungs- und Genehmigungsprotokolle. Da das Audit-Log an ein separates Ziel exportiert werden kann, kann es auch innerhalb der eigenen Protokollierungsinfrastruktur der Organisation ausgewertet werden.

Das Dokumentenbild, die aus dem Chip ausgelesenen Daten, das Selfie, das Liveness-Video und die Gesprächsaufzeichnung werden separat aufgezeichnet; Erfassungszeitpunkt, die jeweilige Prüfung, in der sie verwendet werden, und die Aufbewahrungsdauer werden für jedes Element einzeln verwaltet.

Die Rule Engine zeigt, welches Feld in welcher Regel verwendet wird; wenn nachvollziehbar ist, in welche Entscheidung ein Feld einfließt, lässt sich erkennen, ob ein unnötiges Feld verarbeitet wird.

Nein. Die Beiträge sollen die operativen Auswirkungen von Regulierungen erläutern und ersetzen keine Rechtsberatung. Für die Verpflichtungen Ihres Unternehmens ist die Bewertung Ihrer eigenen Rechts- und Compliance-Abteilung maßgeblich.

Nicht nach einem festen Zeitplan, sondern orientiert am regulatorischen Geschehen. Wir berichten, sobald eine wichtige Mitteilung, ein Leitfaden oder ein Sanktionsbeschluss veröffentlicht wird. In ruhigeren Phasen widmen wir uns ausführlicheren Hintergrundthemen.

Nein. Der Schwerpunkt liegt zwar auf der Türkei, aber wir decken auch das EU-AML-Paket, AMLA- und FATF-Entwicklungen ab. Zudem werden Themen behandelt, die für in Südosteuropa und im Nahen Osten tätige Institute relevant sind.

Nein. Die Inhalte sind ohne Registrierung zugänglich. Wir glauben, dass es niemandem hilft, einem prüfenden Team ein Formular in den Weg zu stellen.

Der Großteil sind allgemeine Praxisleitfäden, die auch für Teams relevant sind, die andere Plattformen nutzen. Wenn der Ansatz von Truvali zu einem bestimmten Thema erläutert wird, weisen wir explizit darauf hin.

Verwenden Sie für Server-zu-Server-Aufrufe das Bearer-Token, das Sie mit Ihrem API-Schlüssel erhalten. Für KYC-Aufrufe aus dem Browser des Endnutzers wird ein signiertes Sitzungstoken verwendet; Ihr API-Schlüssel darf niemals an das Gerät des Endnutzers übermittelt werden.

Nein. `status` zeigt an, dass die Anfrage verarbeitet wurde; das Ergebnis des Datensatzes und die getroffene Entscheidung werden im Datenteil der Antwort zurückgegeben. Bei Batch-Anfragen können einige Datensätze übersprungen worden sein, weshalb die Ergebnisse auf Datensatzebene separat überprüft werden müssen.

Ja. Felder außerhalb der definierten Felder werden weder abgelehnt noch erzeugen sie Warnungen; sie werden im Rohdatenfeld des Datensatzes gespeichert und können als Variablen in Regelszenarien verwendet werden.

Nein. Eine leere Liste bedeutet 'keine IP zulassen', und alle Anmeldeversuche werden abgelehnt. In Ihren Anmeldedaten muss mindestens eine IP-Adresse definiert sein.

Die Ergebnisse der Dokumentenprüfung werden über den Echtzeit-Benachrichtigungskanal übermittelt. Nach dem Verbindungsaufbau und der Registrierung für die Sitzung gehen die Ergebnisse von Schritten wie MRZ-Auslesung, Gesichtsabgleich und Liveness-Erkennung als Nachrichten ein.

Es ist möglich, wird aber nicht empfohlen. Schwellenwerte sollten an den Kundenstamm und das Transaktionsprofil Ihres Instituts angepasst werden. Jedes Szenario sollte vor dem Go-Live anhand historischer Daten simuliert werden.

Ja. Die relevanten Typologien in den Bereichen Banking, Payments, Gaming und Krypto unterscheiden sich; die Szenarien sind entsprechend dieser Segmente gruppiert.

Ja. Neu veröffentlichte regulatorische Leitlinien und in der Praxis beobachtete neue Methoden werden kontinuierlich als Szenarien in die Bibliothek aufgenommen.

Nein, die Teilnahme ist kostenlos. Sie müssen sich lediglich registrieren.

Ja. Die Sessions werden aufgezeichnet und stehen nach Abschluss zur Verfügung.

Ja. Wir können geschlossene Sessions organisieren, die auf die spezifischen Themen Ihres Teams zugeschnitten sind. Senden Sie uns Ihre Anfrage einfach über das Kontaktformular.

Nein. Die Plattform läuft in der eigenen Infrastruktur des Unternehmens. Kundendaten werden für Analyse- oder KI-Prozesse nicht an externe Cloud-Umgebungen übermittelt.

Nein. Die Protokolle werden revisionssicher und unveränderbar aufbewahrt. Die Archivintegrität wird durch Hashwerte überprüft und Freigaben werden mit einem Zeitstempel versehen.

Ja. Da die Installation in Ihrer eigenen Infrastruktur erfolgt, können Sie Ihren eigenen Testzeitplan anwenden. Regelmäßige Penetrationstests und Schwachstellenscans werden voll unterstützt.

Die Fragebögen werden gemeinsam von unseren Abteilungen für Engineering und Compliance beantwortet. Sobald Sie uns diesen über die Kontaktseite zukommen lassen, wird der Prozess gestartet.

Nein. Es handelt sich um ein technisches Mapping-Dokument, das zeigt, wie Verpflichtungen erfüllt werden; es ersetzt nicht die Bewertung durch die Compliance- und Rechtsabteilung Ihres Instituts.

Ja. Die geltenden Verpflichtungen für Banken, Zahlungsinstitute, E-Geld-Institute und regulierte Glücksspielanbieter sind unterschiedlich; der Anhang wird entsprechend angepasst.

Das Dokument ist dafür gedacht, Sie bei der Erstellung Ihrer internen Dokumentation zur Audit-Vorbereitung zu unterstützen. Die Verantwortung für die endgültige Dokumentation, die dem Prüfer vorgelegt wird, liegt beim Institut.

Da die Installation in Ihrer eigenen Infrastruktur erfolgt, hat der Anbieter keinen routinemäßigen Zugriff auf die Kundendaten. Im Supportfall erfolgt der Zugriff nur mit Ihrer ausdrücklichen Freigabe und wird vollständig protokolliert.

Nein. Die gesamte Analyseebene, einschließlich Fall-Voranalysen, Open-Source-Recherchen und Berichterstellung, läuft lokal (On-Premise) im Unternehmen.

Ja, sofern die gesetzlichen Mindestaufbewahrungsfristen eingehalten werden. Nach Ablauf dieser Frist wird die Archivierung oder Löschung der Daten gemäß den Richtlinien Ihres Unternehmens konfiguriert.

Nein. Es erfüllt zwar alle AML-Verpflichtungen, ist aber im Kern eine Entscheidungs-Engine: Sie bewertet Transaktionen noch vor deren Abschluss und gibt Entscheidungen wie Genehmigung, Ablehnung, Überprüfung oder Callback an das Kernsystem zurück. Compliance-Regeln schützen das Unternehmen vor den Strafen von morgen; vor dem finanziellen Schaden von heute schützt die Entscheidung in Echtzeit.

Nein. Truvali wird als Entscheidungsebene in Ihren bestehenden Workflow integriert. Es kann sowohl als Vorabprüfung vor der Kundenregistrierung als auch als Letztprüfung im Moment der Transaktion positioniert werden. Vor dem Live-Gang werden Ihre historischen Daten migriert, sodass Regeln, die historische Zeitfenster nutzen, vom ersten Tag an mit echten Daten arbeiten.

Ja. Truvali ist für die On-Premise-Installation konzipiert und übermittelt keine Kundendaten an externe Cloud-Umgebungen. Auch die KI-gestützten Analysen laufen in dieser geschlossenen Umgebung.

Nein. Sie beschreiben das Szenario einfach in Ihrer täglichen Arbeitssprache. Das System übersetzt dies in eine parametrisierte Regel und legt sie vor der Aktivierung zur menschlichen Freigabe vor. Teams, die dies wünschen, können über einen Formeleditor auch eigene Berechnungsblöcke erstellen.

Die API-Dokumentation und die Integrationsleitfäden sind frei zugänglich, um Teams in der Evaluierungsphase einen reibungslosen Einstieg zu ermöglichen. Für den Zugriff auf Beispieldaten und eine Testumgebung können Sie uns einfach kontaktieren.

Die Seiten unter der Rubrik „Vertrauen“ decken diese Themen ab: Sicherheitspraktiken, On-Premise-Bereitstellungsmodelle und die Konformität mit den türkischen Regularien. Wenn Ihr Unternehmen einen eigenen Fragenkatalog zur Informationssicherheit hat, können Sie uns diesen gerne zur Beantwortung zukommen lassen.

Die Haftung ist ebenso persönlich wie korporativ. Wenn Prüfer Fragen stellen, richten sie sich direkt an diese Person. Ist die Antwort nicht in den Aufzeichnungen dokumentiert, gibt es keine Verteidigungslinie.

Warum eine Regel mit diesem spezifischen Schwellenwert erstellt wurde, warum ein Fall geschlossen wurde, warum eine Meldung nicht eingereicht wurde, wer die Entscheidung genehmigt hat, welches Regelwerk in der Vergangenheit aktiv war und wer auf die Daten zugegriffen hat.

Nein. Kontrollen können in eigenen Worten formuliert werden, und der entsprechende Regelentwurf wird automatisch generiert. Der Entwurf geht nicht ohne Freigabe live und wird vorab in einer Simulation getestet.

Wenn das Team überlastet ist, werden Alerts nicht mehr wirklich geprüft, obwohl die Protokolle eine durchgeführte Untersuchung ausweisen. Dies ist das am schwersten zu verteidigende Szenario bei einer Prüfung.

Nein. Sie generiert eine erste Einschätzung aus den Falldaten, aber die Entscheidung verbleibt beim Menschen und wird mitsamt Begründung protokolliert.

Nein. Es können Genehmigungsrichtlinien, Mehrfachfreigaben und Delegationsregelungen definiert werden, wobei die Delegation selbst mitsamt Dokumentation erfasst wird.

Direkt aus dem Fall selbst. Zeitraum, Gesamtbetrag, Aufschlüsselung nach Kanälen und Verdachtskategorie sind bereits im Fall hinterlegt. Die Freigabe und die Entscheidung zur Meldung liegen beim Compliance Officer.

Unser Team aus Compliance- und Fraud-Experten hat diese Arbeit selbst über fünfzehn Jahre lang in Banken ausgeübt. Sie erreichen bei uns jemanden, der genau diese Frage schon vom eigenen Schreibtisch aus beantwortet hat.

Es ist nicht das Erkennen der Bedrohung, sondern das Übertragen dieser Erkenntnis in das System. Wenn der Regelersteller und der Risikoexperte unterschiedliche Personen sind, landet jede Änderung in einer Warteschlange.

Nein. Sie formulieren die Kontrollvorgabe in Ihren eigenen Worten, um einen Regelentwurf zu erstellen, der niemals ohne Freigabe live geht.

Nein. Ein Beitrag zu einem Score, das Hinzufügen eines Warngrundes oder das bloße Markieren der Transaktion sind ebenfalls zulässige Ergebnisse. So können Sie aggressive Regeln überwachen, bevor Sie sie in der Produktion einsetzen.

Ja. Auch Ereignisse ohne monetären Wert wie Logins, Gerätewechsel, Dokumenten-Uploads und Einstellungsänderungen werden in Regeln verwendet.

Die Regel wird vor der Liveschaltung anhand historischer Transaktionsdaten getestet. Dies zeigt, wie viele Transaktionen sie blockiert hätte, wie viele Warnmeldungen generiert worden wären und wie viele davon tatsächlich Betrugsfälle waren.

Ja. Die Regel kann für den Datenverkehr dieses Tages simuliert werden, um genau zu sehen, wie das Ergebnis ausgefallen wäre.

Ja. Das Signalmuster innerhalb des Falls kann extrahiert und in eine Regel umgewandelt werden. Dadurch bleibt das institutionelle Wissen im Unternehmen verankert, anstatt an einzelne Personen gebunden zu sein.

Ja. Die Reihenfolge, in der die Regeln ausgewertet werden, kann definiert werden. Zudem werden der Eigentümer der Regel und die Freigabeberechtigungen erfasst.

Ihre Anwendung sendet ein Event und das System gibt den Score, die ausgelösten Regeln und die Entscheidung zurück. Die Entscheidung wird so schnell zurückgegeben, dass sie direkt inline im laufenden Prozess genutzt werden kann.

Nein. Logins, Geräteänderungen, Dokumenten-Uploads, Einstellungsänderungen und Kontoeröffnungen sind ebenfalls Events und werden in den Regeln auf exakt dieselbe Weise verwendet.

Nein. Datenquellen werden getrennt gehalten und Regeln können pro Quelle definiert werden.

Anzahl, Summe und Durchschnitt der Transaktionen eines Kunden innerhalb eines Zeitraums sind vordefiniert und werden in den Regeln namentlich referenziert.

Nein. Regeln existieren als Daten, nicht als Code. Compliance- und Betrugserkennungsteams können Regeln ändern, ohne die Entwickler-Pipeline zu belasten.

Das spezifische Regelwerk und die ausgeführte Version werden zusammen mit dem Ergebnis jedes Events gespeichert, sodass sich genau nachvollziehen lässt, welche Regel die Änderung verursacht hat.

Es kann auf der eigenen Infrastruktur des Unternehmens gehostet werden. Daten verlassen niemals das Unternehmen, Protokolle verbleiben auf Ihren eigenen Systemen und der Audit-Trail kann an ein separates Ziel gesendet werden.

Mit einem einzelnen Prozess, der die meisten Verluste verursacht oder die meisten Warnmeldungen generiert. Events für diesen Prozess werden gesendet, Regeln in der Simulation ausgeführt und die Ergebnisse mit Ihrem bestehenden System verglichen.

Kontrollsysteme sind lebendige Systeme; Regeln und Schwellenwerte ändern sich. Eine vor sechs Monaten getroffene Entscheidung anhand des heutigen Regelsatzes zu erklären, führt zu falschen Ergebnissen.

Wenn die spezifische Regel und die Version, die sie ausgelöst hat, nicht zusammen mit dem Ereignis gespeichert werden, lässt sich die Begründung für eine vergangene Entscheidung nicht mehr rekonstruieren.

Mithilfe von Filtern wird eine Teilmenge aus den Fällen eines bestimmten Zeitraums ausgewählt. Berichtsvorlagen werden ohne Programmieraufwand erstellt, Ergebnisse gespeichert und dieselbe Definition kann im folgenden Zeitraum erneut ausgeführt werden.

Nein. Bei einer On-Premise-Bereitstellung verbleiben alle Protokolle in der eigenen Infrastruktur des Instituts, sodass die Revision selbst kein Datenrisiko darstellt.

Entscheidungen, die von derselben Person vorbereitet und genehmigt wurden, können gezielt abgefragt werden. Genehmigungsrichtlinien, Mehrfachunterschriften und Delegationsrechte bleiben in den Protokollen dokumentiert.

Es wird gemessen, wie oft sie ausgelöst wurde, in wie viele Fälle sie mündete, wie viele an das Meldewesen weitergeleitet und wie viele ohne Begründung geschlossen wurden. Eine Regel, die nie anschlägt, und eine Regel, die bei allem anschlägt, sind gleichermaßen Revisionsbefunde.

Ja. Die Regel wird auf dem historischen Datenverkehr ausgeführt, sodass die Situation vor und nach der Änderung verglichen werden kann.

Er ist unveränderlich. Protokolle können zudem an ein separates Ziel gesendet werden, sodass eine Änderung innerhalb der Plattform den Audit Trail nicht beeinflusst.

Die Leitfäden besagen das Gegenteil: Verpflichtete dürfen sich nicht auf die aufgelisteten Typen beschränken und müssen auch dann eine Meldung einreichen, wenn eine verdächtige Transaktion keinem davon entspricht. Die Typen stellen einen Mindeststandard dar, keine Obergrenze.

Ja. Vorgänge wie verdächtige Kontoeröffnungen und -schließungen, Besuche von Schließfächern oder Vollmachts- und Garantiegeschäfte werden im Beschreibungsabschnitt des Formulars erfasst. Der Case muss in der Lage sein, diese Arten von Ereignissen abzubilden.

Bei der Einreichung einer Meldung wird der Verdacht einer der 38 Kategorien in der Referenztabelle von MASAK zugeordnet, und jede Kategorie wird mit einer gesetzlichen Regelung abgeglichen. Das Case Management muss mit dieser Taxonomie arbeiten und nicht mit beliebigen benutzerdefinierten Tags.

Die Leitfäden legen eine klare Schwelle fest: Es müssen Dokumente oder schwerwiegende Indizien vorliegen, die den Verdacht stützen und über einen bloßen Verdacht hinausgehen, und die Meldung muss mit Begründungen eingereicht werden. Dies erfordert, dass dem Case Beweismittel beigefügt werden und die Identität des Entscheidungsträgers erfasst wird.

Das Gesetz Nr. 5549 stuft ein breites Spektrum von Institutionen als Verpflichtete ein: Darunter fallen unter anderem Banken, Zahlungs- und E-Geld-Institute, Kapitalmarktinstitute, Versicherungsgesellschaften, Krypto-Dienstleister und Betreiber im Bereich von Glücksspielen.

Die Leitfäden listen branchenspezifische Indikatoren auf und legen einen Mindeststandard fest. Wenn ein nicht im Leitfaden aufgeführte Muster Verdacht erregt, besteht die Meldepflicht weiterhin.

Antragsverfahren und alle Einreichungen von Verdachtsmeldungen werden elektronisch über das System MASAK.Online abgewickelt.

Ja, das ist möglich. Eine Regel kann in eigenen Worten beschrieben werden, um einen Entwurf zu erstellen, vor der Liveschaltung anhand historischer Daten getestet und nach der Genehmigung in Kraft gesetzt werden.

Sie ist die Behörde der Europäischen Union zur Bekämpfung von Geldwäsche und Terrorismusfinanzierung, die durch die Verordnung (EU) 2024/1620 errichtet wurde.

Die Verordnung wurde am 31. Mai 2024 verabschiedet und ist seit dem 1. Juli 2025 anwendbar. Bestimmte Artikel sind bereits seit dem 26. Juni 2024 in Kraft, und ein Artikel wird ab dem 31. Dezember 2025 gelten.

Ausgewählte Verpflichtete im Finanzsektor, einschließlich Krypto-Dienstleistern. Zudem koordiniert und überwacht sie die Aufsichtsbehörden des Finanz- und Nichtfinanzsektors.

Die Verordnung (EU) 2024/1620, die Verordnung (EU) 2024/1624, die Richtlinie (EU) 2024/1640 und die Verordnung (EU) 2023/1113, welche die Übermittlung von Angaben bei Geldtransfers und bestimmten Krypto-Werten regelt.

Die Aufsicht ist keine Angelegenheit mehr, die ausschließlich mit nationalen Behörden geregelt wird; ausgewählte Verpflichtete werden direkt von der AMLA beaufsichtigt.

Ja. Länder und Geschäftseinheiten werden als separate Datenquellen definiert; die Isolierung von Regeln und Daten wird über diese Trennung verwaltet, sodass eine einzige Bereitstellung die Regelsätze verschiedener Jurisdiktionen unterstützen kann.

Nein. Im Screening-Workflow wird eine Wallet-Adresse wie eine Entität neben dem Namen der Person behandelt; On-Chain- und Off-Chain-Daten verschmelzen zu einer einzigen Kundenansicht.

Die Begründung für jede Entscheidung muss auditierbar sein. Details darüber, wer die Entscheidung unter welcher Befugnis, mit welchen Daten und wann getroffen hat, werden in einem unveränderlichen Audit Trail festgehalten; zudem wird aufgezeichnet, welche Regel durch welches Ereignis ausgelöst wurde.

OCR- und MRZ-Auslesung aus Dokumentenbildern, Chipleistung via NFC bei Ausweisen mit Chip, Liveness-Prüfungen, Gesichtsabgleich sowie Video-Ident, sofern regulatorisch vorgeschrieben. Die verschiedenen Ebenen verifizieren sich gegenseitig; eine einzelne Prüfung ist nie die alleinige Grundlage für das Onboarding.

Die aus dem Chip ausgelesenen Daten stammen direkt vom Dokument selbst. Während bildbasierte Prüfungen durch eine hochwertige Kopie getäuscht werden können, lässt sich das Auslesen des Chips nicht manipulieren.

Die Eigentümerstruktur wird Ebene für Ebene bis zur natürlichen Person aufgelöst. Jede in der Kette identifizierte natürliche Person wird zudem einem Sanktions- und PEP-Screening unterzogen, wobei jeder Schritt des Pfades dokumentiert wird.

Der Anbieter wird mit Listen vertrauenswürdiger, temporärer und datenschutzorientierter Anbieter abgeglichen. Es wird geprüft, ob die Adresse den Vor- oder Nachnamen, das Geburtsdatum oder die Initialen der Person enthält, und es wird eine unscharfe Suche nach ähnlichen oder fortlaufend nummerierten Adressen im System durchgeführt.

Durch die Analyse von Geolokalisierung, Eigentümerinformationen und rDNS-Einträgen ermittelt das System, ob es sich um einen Proxy, ein VPN oder einen privaten Internetanbieter handelt. Das Erkennen anderer Konten, die dieselbe IP nutzen, ist ein separates Risikosignal.

Ja. Bei geringem Risiko und sofern regulatorisch zulässig, werden weniger Dokumente angefordert; ein hohes Risiko löst verstärkte Sorgfaltspflichten aus. Welcher Schwellenwert zu welchem Ergebnis führt, wird durch die eigenen Regeln des Instituts definiert.

Anträge, die den Schwellenwert überschreiten, werden zur manuellen Überprüfung weitergeleitet. Entscheidungen werden mit ihrer Begründung dokumentiert, unterliegen der Funktionstrennung und werden im Audit-Trail erfasst.

Bei einer On-Premise-Bereitstellung auf der eigenen Infrastruktur des Instituts. Dokumentenbilder, Gesprächsaufzeichnungen und Screening-Ergebnisse bleiben mit der Entscheidung verknüpft und können später als Nachweis vorgelegt werden.

Beim Kunden-Onboarding, im Moment der Transaktion, für den gesamten bestehenden Kundenstamm bei Listenänderungen sowie bei periodischen Überprüfungen basierend auf der Risikoklassifizierung.

Aliase und Transliterationen, Geburtsdatum, Ausweis- und Passnummern, Staatsangehörigkeit und Stadtinformationen werden gemeinsam ausgewertet. Das Foto wird aus der Quelle abgerufen und mit einem Konfidenzwert angezeigt, zudem wird das Gültigkeitsdatum des Datensatzes überprüft.

Nein. Die Gültigkeitsdaten des Datensatzes werden ausgelesen, und eine aufgehobene Sanktion erzeugt keinen Alert.

Ja. Jeder Datensatz wird mit der ausstellenden Behörde und deren Land gespeichert, und auch der Quellenlink bleibt erhalten.

Ja. Über offizielle Quellendefinitionen, Feed-Abfragen oder Dokumenten-Uploads fließen die institutseigenen Listen in denselben Screening-Workflow ein.

Da Verifizierungssignale im Datensatz gespeichert sind, erzeugt eine reine Namensähnlichkeit keine Warnmeldungen. Wo der Schwellenwert angesetzt wird, ist als Regel definiert, und wie viele Warnmeldungen ein neuer Schwellenwert im historischen Datenverkehr erzeugen wird, lässt sich per Simulation vorab prüfen.

Ein Treffer öffnet einen Fall. Die Prüfungs-, Entscheidungs- und Genehmigungskette wird mit ihrer Begründung protokolliert und in einen unveränderlichen Audit Trail geschrieben. Wenn eine Meldung erforderlich ist, wird der Fall in einen Bericht umgewandelt.

Nicht bei einer On-Premise-Bereitstellung. Listen, Screening und Entscheidungen verbleiben vollständig in der eigenen Infrastruktur des Instituts.

Sender, Empfänger, die Bank des Empfängers und alle zwischengeschalteten Institute. Auch Namens- und Adressangaben in Freitextfeldern werden erfasst, da eine sanktionierte Partei häufig in der Verwendungszweckzeile auftaucht.

Das Screening ist direkt in die Transaktions-Pipeline integriert und arbeitet innerhalb eines strengen Latenzbudgets. Das Ergebnis muss schnell genug vorliegen, um Teil der Entscheidung zu sein; andernfalls ist das Screening praktisch wirkungslos.

Sie wird nicht abgelehnt, sondern vorübergehend ausgesetzt. Die blockierte Transaktion wird mit einem Fall verknüpft, und ein Mensch trifft die Entscheidung.

Bestätigungssignale wie Aliase, Geburtsdatum, Ausweis- und Passnummern, Staatsangehörigkeit und Stadt sind im Datensatz gespeichert, sodass ein häufiger Name allein eine Zahlung nicht stoppt. Zudem wird das Gültigkeitsdatum des Datensatzes geprüft.

Ja. Sanktionsregime richten sich ebenso gegen Länder und Sektoren wie gegen Einzelpersonen; der Weg der Überweisung kann eine Überprüfung erfordern, selbst wenn alle Parteien unbedenklich sind.

Ja. Mittels Simulation wird vor dem Live-Gang gemessen, wie viele Transaktionen der neue Schwellenwert im historischen Zahlungsverkehr stoppen würde.

Ja. Sowohl die Freigabe als auch das Stoppen sind Entscheidungen; beide werden mit ihrer Begründung im unveränderlichen Audit Trail protokolliert und unterliegen der Funktionstrennung (Segregation of Duties).

Ja. Die institutseigenen Listen fließen über die Definition offizieller Quellen, Feeds oder Dokumenten-Uploads in denselben Screening-Prozess ein.

Sie bewertet Transaktionen im Vergleich zur eigenen Historie des Kunden, seiner deklarierten Aktivität, Peer-Groups, unterschwelligen Strukturierungsmustern sowie Netzwerkbeziehungen, die über gemeinsam genutzte Geräte, IPs oder Konten bestehen.

Ja. Ein neuer Sanktionseintrag, negative Medienberichte, eine Reihe von Transaktionen, die nicht mit den Angaben übereinstimmen, oder eine Änderung der Eigentümerstruktur erhöhen die Risikoklasse. In der Folge passen sich die Überwachungsfrequenz und die Überprüfungsintervalle entsprechend an.

Ja. Da sich Sanktions- und Watchlists ständig ändern, wird der bestehende Kundenstamm fortlaufend neu überprüft (Re-Screening), da ein heute unauffälliger Datensatz morgen einen Treffer erzielen kann.

Bevor eine Regel live geht, wird sie auf historische Transaktionsdaten angewendet, um das zu erwartende Alert-Volumen zu messen. Ein Schwellenwert, der das Team überlastet, ist ebenso problematisch wie einer, der echte Risiken übersieht.

Nein. Die gewünschte Kontrolle kann in natürlicher Sprache formuliert werden. Daraus wird automatisch ein entsprechender Regelentwurf generiert, der erst nach Freigabe live geschaltet wird.

Ja. Die genaue Version der Regel, die den Alert ausgelöst hat, wird direkt beim Ereignis dokumentiert. So lässt sich eine frühere Entscheidung jederzeit auf Basis des an jenem Tag aktiven Regelsatzes auditierungssicher begründen.

Aus einer Warnmeldung wird ein Fall (Case). Nach der Untersuchung wird dieser geschlossen, vorübergehend stummgeschaltet oder als Meldung eskaliert. Die Begründung und die Entscheidung werden revisionssicher im Audit Trail protokolliert.

Nein. Die beim Onboarding erfassten Angaben und Profile dienen als Referenzlinie (Baseline) für die Überwachung. Ohne diese Ausgangsdaten lassen sich Abweichungen im Verhalten nicht messen.

Weil der Login erfolgreich ist. Das Passwort ist korrekt, und in den meisten Fällen wurde auch die Multi-Faktor-Authentifizierung umgangen; die Übernahme wird erst im Verhalten nach dem Login sichtbar.

Neue Geräte-ID, der Proxy- oder VPN-Status der IP, unmögliche Reisezeit zwischen zwei Sitzungen, gemeinsam genutzte Geräte, abfließende Gelder nach einer Einstellungsänderung und ungewöhnliche Transaktionsgeschwindigkeit.

Nein. Erst die Kombination der Signale macht eine Übernahme sichtbar; ein neues Gerät, ein VPN und abfließende Gelder nach einer IBAN-Änderung bilden zusammen ein einziges starkes Muster.

Ja. Konten-Cluster, die über dasselbe Gerät, dieselbe IP oder dasselbe E-Mail-Muster verbunden sind, werden durch die Link-Analyse aufgedeckt; ein verdächtiges Konto zieht die Untersuchung anderer Konten nach sich, die dasselbe Gerät nutzen.

Ob der Anbieter seriös, ein Wegwerf-Dienst oder auf Privatsphäre ausgerichtet ist, generiert einen Risikowert. Die Ähnlichkeit der Adresse zu anderen Adressen im System mittels Fuzzy-Matching sowie Cluster von Adressen mit fortlaufenden Endungen dienen als zusätzliche Indikatoren.

Die Bewertung läuft inline direkt im Transaktionsfluss ab und ist schnell genug, um eine Entscheidung zu treffen. Eine langsame Prüfung liefert die richtige Antwort erst, wenn das Geld bereits weg ist, was keinen praktischen Nutzen hat.

Der neue Schwellenwert wird mit dem historischen Sitzungs- und Transaktionsverkehr abgeglichen. So wird vor dem Live-Gang der Regel aufgezeigt, wie viele legitime Nutzer blockiert würden.

Ja. Das Signalmuster innerhalb des Falls kann extrahiert und in eine Regel umgewandelt werden, sodass derselbe Pfad nicht zweimal ausgenutzt werden kann.

Weil sich ein einzelnes Konto regelkonform verhält: Der Nutzer registriert sich, beansprucht den Bonus und erfüllt die Bedingungen. Der Verstoß liegt in der Beziehung zwischen den Konten.

Geräte-ID, IP und Netzwerk, Zahlungsmethode, E-Mail-Muster, Kombinationen von Identitätsdaten und Verhaltenssynchronität.

Adressen werden mittels Fuzzy Matching miteinander abgeglichen; dies deckt sehr ähnliche oder fortlaufend nummerierte E-Mail-Cluster auf. Die Nutzung von Wegwerf-E-Mail-Anbietern dient als zusätzliches Signal.

Nein, das ist nicht der Fall. Die Eigenschaften der IP-Adresse sind nur eines von vielen Signalen; die endgültige Entscheidung hängt von der Kombination der Signale und den vom Institut definierten Regeln ab.

Dieses Risiko ist real. Deshalb wird vor dem Liveschalten einer Regel gemessen, wie viele Konten ein neuer Schwellenwert im historischen Datenverkehr erfasst hätte.

Nein, das ist nicht erforderlich. Sie können in eigenen Worten beschreiben, wie die Prüfung aussehen soll, und der entsprechende Regelentwurf wird generiert; der Entwurf geht nicht ohne Freigabe live.

Das Cluster löst einen Fall (Case) aus, in dem die Konten, die Verbindungen zwischen ihnen, die ausgelöste Regel und die Begründung des Prüfers zusammengeführt werden. Der Entzug des Bonus oder die Freigabe des Clusters wird als Entscheidung protokolliert.

Ja. Welche Regel und Version ausgelöst wurde und wer die Entscheidung mit welcher Begründung getroffen hat, wird in einem unveränderlichen Audit Trail aufgezeichnet.

Für jede Transaktion fällt zusätzlich zum Erstattungsbetrag eine Disput-Gebühr an. Zudem verhängt der Zahlungsabwickler Sanktionen, wenn die Chargeback-Quote einen bestimmten Schwellenwert überschreitet. Letzteres ist am teuersten, da es die Betriebslizenz des Händlers gefährden kann.

Geräte-ID, Proxy- oder VPN-Status der IP, Übereinstimmung von Rechnungs-/Lieferadresse und IP-Standort, Karten-Frequenz (Velocity), E-Mail-Attribute und das Verhalten im Warenkorb.

Nein. Die Entscheidung hängt von der Aggregation der Signale und dem vom Institut festgelegten Schwellenwert ab.

Ja. Mithilfe der Link-Analyse werden Cluster von Konten und Transaktionen aufgedeckte, die über dieselbe Karte, dasselbe Gerät oder dasselbe E-Mail-Muster miteinander verknüpft sind.

Nein. Ein höherer Schwellenwert reduziert zwar Chargebacks, verringert aber auch legitime Umsätze. Der optimale Schwellenwert wird durch das Abwägen dieser beiden Kostenfaktoren ermittelt.

Ja. Die Regel wird auf historischen Transaktionsdaten getestet. So sehen Sie vor dem Live-Gang, wie viele Transaktionen abgelehnt worden wären und wie viele davon tatsächlich zu einem Disput geführt hätten.

Geräte- und IP-Informationen zum Zeitpunkt der Transaktion, Adressabgleich, Sitzungsverlauf und Liefernachweise. Die Speicherung dieser Daten direkt bei der Transaktion sichert Ihre Verhandlungsposition im Disput-Verfahren.

Ja. Das Muster des Falls kann extrahiert und in eine Regel umgewandelt werden, sodass derselbe Pfad nicht erneut ausgenutzt werden kann.

Nein. Die Mittelherkunft fragt nach dem Ursprung des Geldes bei einer bestimmten Transaktion, während die Vermögensherkunft fragt, woher das Gesamtvermögen einer Person stammt. Ein Kunde kann unter Umständen sein Vermögen erklären, scheitert jedoch daran, die Mittel für eine einzelne Transaktion nachzuweisen.

Ein Betrag, der in keinem Verhältnis zum angegebenen Profil steht, eine plötzliche Verhaltensänderung, eine risikoreiche Gegenpartei oder ein Hochrisikoland, eine PEP-Beziehung sowie negative Medienberichte.

Nachweise, die die Erklärung stützen: wie ein Kaufvertrag, eine Gehaltsabrechnung, ein Erbschein, ein Beschluss über eine Gewinnausschüttung oder ein Darlehensvertrag. Der Text des Dokuments wird ausgelesen, wodurch Parteien, Beträge und Daten in strukturierte Daten umgewandelt werden.

Nein. Erklärung, Dokument und Transaktionsverhalten werden gemeinsam bewertet; das Dokument stützt die Erklärung, während das Transaktionsverhalten diese überprüft.

Ja. Absender, Zwischenkonten und verbundene Personen werden untersucht; Verbindungen, die über ein gemeinsam genutztes Gerät, eine IP-Adresse oder einen Standort hergestellt werden, können Strukturen aufdecken, die bei isolierter Betrachtung unsichtbar bleiben.

Die Prüfung verlagert sich auf die Wallet: Die Historie der Adresse, von der die Gelder stammen, ihre Interaktionen mit Mixing-Diensten und ihre Nähe zu sanktionierten Adressen werden analysiert.

Die Erklärung wird als ausreichend erachtet und der Fall wird geschlossen, es werden zusätzliche Dokumente angefordert und der Fall wird zurückgestellt, oder die Erklärung bleibt unzureichend und führt zu einer Meldung.

Die Erklärung, Dokumente, Screening-Ergebnisse, die Transaktionshistorie und die Begründung des Prüfers befinden sich alle im selben Fall. Die Frage bei einer Prüfung lautet meist, warum der Fall geschlossen wurde, und die Antwort liegt direkt im Fall vor.

Er wird nicht auf einem separaten Meldebildschirm von Grund auf neu ausgefüllt, sondern direkt aus dem Fall selbst generiert. Der Datumsbereich, der Gesamtbetrag, die Unterscheidung nach Kanal und Typ, die Parteiinformationen und die Verdachtskategorie befinden sich bereits im Fall.

Nein. Die Richtlinie verlangt nicht, alle Finanztransaktionen des Kunden mit dem Verpflichteten, die nicht als verdächtig eingestuft werden, in das Formular einzutragen: Der Bericht enthält eine Auswahl, keinen vollständigen Datenexport, und die Begründung für diese Auswahl ist im Fall dokumentiert.

Ja. Verdächtige Kontoeröffnungen und -schließungen, Schließfachbesuche sowie Garantie- oder Vollmachtstransaktionen werden im Beschreibungsabschnitt des Formulars erfasst, während der Abschnitt für verdächtige Transaktionen leer bleibt.

Ja. Wenn der Verdacht auf mehreren Transaktionen innerhalb eines bestimmten Zeitraums beruht, werden der Gesamtbetrag und der Datumsbereich zusammen als Mehrfachtransaktion gemeldet.

Er wird einer der 38 Kategorien der MASAK-Referenztabelle zugeordnet, und jede Kategorie ist mit der entsprechenden gesetzlichen Regelung verknüpft: Beispielsweise sind Wucher und POS-Wucher mit Artikel 241 des Gesetzes Nr. 5237 verknüpft.

Nach der auf Artikel 19/A des Gesetzes Nr. 5549 basierenden Verordnung müssen Dokumente oder schwerwiegende Indizien vorliegen, die den Verdacht stützen, und nicht bloße Vermutungen, dass der Vermögenswert mit der Straftat der Geldwäsche oder der Terrorismusfinanzierung in Zusammenhang steht.

Antragsverfahren und alle Einreichungen bezüglich Verdachtsmeldungen werden elektronisch über das MASAK.Online-System abgewickelt.

Ja. Berichtskonfigurationen erfolgen ohne Code, und die Ergebnisse sind gespeichert und reproduzierbar: Herkunft und Entstehung jeder Zahl aus Fällen und Ereignissen bleiben lückenlos nachvollziehbar.

Ja. Welche Version welcher Regel das Ereignis ausgelöst hat, wird zusammen mit dem Ereignis gespeichert.

Keine Person, sondern eine Blockchain-Adresse. Bewertet werden der direkte Abgleich der Adresse mit Sanktionseinträgen, ihre Distanz zu einer sanktionierten Adresse, Mixer-Interaktionen, Cluster-Beziehungen und der Pfad der Gelder.

Sie gibt an, wie viele Schritte die Adresse von einer sanktionierten Adresse entfernt ist. Gelder, die direkt eingehen, und Gelder, die über drei Zwischenstationen fließen, sind nicht dasselbe – Letztere gelten jedoch ebenfalls nicht als unbelastet.

Das jeweilige Institut. Der Risikoappetit wird als Regel definiert, und die Auswirkungen des Schwellenwerts werden vor dem Live-Gang anhand des historischen Transaktionsvolumens gemessen.

Nein. Die Adressbewertung fließt in den Kunden-Risiko-Score ein; zudem beeinflusst das eigene Profil des Kunden den Schwellenwert, mit dem die Adresse bewertet wird.

Die Adresshistorie ist Teil der Antwort, nicht die Gesamtheit. Erklärungen und unterstützende Dokumente sind weiterhin erforderlich; alle drei Aspekte werden zusammen bewertet.

Sie ist für sich genommen kein Entscheidungsgrund, aber der Durchlauf durch einen Dienst zur Verschleierung der Mittelherkunft ist ein starkes Signal und kann die Transaktion je nach Schwellenwert des Instituts aussetzen.

Ein Treffer öffnet einen Fall (Case); Adresse, übereinstimmender Datensatz, Distanz, Pfad der Gelder und die Begründung des Prüfers werden zusammengeführt, und die Entscheidung wird in einem unveränderlichen Audit Trail protokolliert.

Bei einer On-Premise-Bereitstellung nicht; Bewertungen und Aufzeichnungen verbleiben vollständig in der eigenen Infrastruktur des Instituts.

Das Risiko konzentriert sich nicht auf das Unternehmen selbst, sondern auf die ausgeübten Aktivitäten und die tatsächliche Person dahinter. Die Eigentümerstruktur wird abgebildet und die Branche separat bewertet.

Die Eigentümerstruktur wird Schicht für Schicht bis zur natürlichen Person aufgeschlüsselt. Jede natürliche Person in der Kette wird einer Sanktions- und PEP-Prüfung unterzogen.

Änderungen können die Onboarding-Entscheidung hinfällig machen. Aus diesem Grund wird die Struktur nicht nur einmalig erfasst, sondern kontinuierlich überwacht.

Die angegebene Branche und die tatsächlich verkauften Produkte können voneinander abweichen. Die Registrierung unter einer genehmigten Kategorie und der Verkauf in einer anderen ist eine bekannte Herausforderung in der Branche.

Wenn die Zeitspanne zwischen Zahlungseingang und Lieferung lang ist, fallen bei einer Insolvenz des Unternehmens die Chargebacks für nicht gelieferte Bestellungen auf das Zahlungsinstitut zurück.

Ja. Anträge, die über dasselbe Gerät, dieselbe IP-Adresse, dasselbe E-Mail-Muster oder dieselben Identitätsdaten eingehen, werden über Beziehungsnetzwerke sichtbar.

Abweichungen des Transaktionsvolumens von den Angaben, steigende Chargeback-Quoten und Änderungen der Produktkategorien. Diese Abweichungen verändern die Risikoklassifizierung.

Eingeholte Dokumente, die erfasste Eigentümerkette, durchgeführte Prüfungen, der resultierende Score und die genehmigende Person werden aufgezeichnet. Aufgrund der Funktionstrennung sind Prüfer und Genehmiger meist nicht dieselbe Person.

Nein. Es handelt sich um die Anwendung derselben Infrastruktur für das Kunden-Screening auf ein anderes Subjekt. Sanktionseinträge, interne Listen und Adverse-Media-Einträge befinden sich am selben Ort.

Sanktionslisten, PEP- und Angehörigen-Einträge, Adverse Media und die eigenen Watchlists der Organisation. Organisationen können ihre eigenen Listen über offizielle Quellendefinitionen, Feed-Streams oder Dokumenten-Uploads hinzufügen.

Eine Namensähnlichkeit allein ist keine ausreichende Entscheidungsgrundlage. Aliase und Transliterationen, Geburtsdatum, Ausweis- und Passnummern, Staatsangehörigkeit und Stadt sowie eine Fotobestätigung werden gemeinsam ausgewertet; zudem wird das Gültigkeitsdatum des Datensatzes überprüft.

Das Screening ist dasselbe, aber die Rechtsgrundlage und die Aufbewahrungsfristen unterscheiden sich. Bewerberdaten werden für die Dauer des Rekrutierungsprozesses verarbeitet, während Mitarbeiterdaten für die Dauer des Beschäftigungsverhältnisses und gemäß den gesetzlichen Vorschriften verarbeitet werden.

Ja. Ein Re-Screening wird durchgeführt, wenn sich Listen ändern, und jeder neue Treffer erzeugt eine neue Warnmeldung. Eine Person, die das Screening heute erfolgreich durchläuft, kann mit einer später veröffentlichten Entscheidung übereinstimmen.

Drei Methoden greifen ineinander: Offizielle Quellenseiten werden in definierten Intervallen ausgelesen, Adverse-Media-Feeds werden regelmäßig abgefragt und regulatorische Bulletins werden hochgeladen und in strukturierte Datensätze umgewandelt. Jeder Datensatz wird mit seinem Quellenlink gespeichert.

Ja. Der Zugriff ist durch Berechtigungen eingeschränkt, und wer wann auf Mitarbeiterdaten zugegriffen hat, wird in den unveränderlichen Audit-Trail geschrieben.

Nicht bei einer On-Premise-Bereitstellung. Alle Screenings und Protokolle verbleiben vollständig in der eigenen Infrastruktur der Organisation.