Echtzeit-KYT-API für das Screening vor Transaktionen

Eine Echtzeit-KYT-API beantwortet eine Frage genau dann, wenn sie das Ergebnis noch verändern kann: vor der Freigabe der Transaktion. Onchain-Übertragungen sind unumkehrbar. Sobald eine Ein- oder Auszahlung gesendet wurde, bleiben nur Untersuchung und Meldung. Screening vor der Transaktion verlagert die Entscheidung in das Zeitfenster, in dem eine Hochrisiko-Gegenpartei noch blockiert oder zurückgehalten werden kann. Dieser Leitfaden bleibt in diesem Zeitfenster: Bedeutung, Latenzanforderung, API-Ergebnis, Blockieren/Zurückhalten/Zulassen, Abgrenzung von Echtzeit, Batch und Monitor sowie eine Integrationscheckliste. Die gesamten KYT-Funktionen erläutert Phalcon Compliance. Diese Seite ist Teil des KYT-Wissensportals.

Warum Screening vor Transaktionen wichtig ist

Die Unumkehrbarkeit von Onchain-Übertragungen ist der strukturelle Grund für vorgelagertes Screening. Eine Fiat-Überweisung kann über Korrespondenzbanken rückgängig gemacht, zurückgerufen oder eingefroren werden. Eine Blockchain-Übertragung nicht. Nach der Bestätigung gehören die Gelder dem Empfänger. Es bleiben nachträgliche Untersuchung, Strafverfolgungsersuchen oder eine STR-Meldung. Bis dahin sind die Gelder oft weiterbewegt. Eine erst nach der Abwicklung laufende Kontrolle greift faktisch nach dem Schaden.

Nachgelagerte Transaktionsüberwachung ersetzt keine vorherige Prüfung. Der risikobasierte Ansatz der FATF für Anbieter von Dienstleistungen für virtuelle Vermögenswerte verpflichtet VASPs zu laufender, risikoorientierter Überwachung statt einer einzelnen Onboarding-Prüfung. FinCEN formuliert fortlaufende AML-Überwachungspflichten in seiner Vorschrift für Money Services Businesses (31 CFR 1022.210) in derselben Richtung für Kryptobörsen und andere US-amerikanische Money Services Businesses. Keines der Rahmenwerke nennt eine feste Latenzzahl. Beide erwarten aber, dass die Kontrolle tatsächlich auf die betreffende Transaktion angewendet wird. Ein Programm, das Risiken erst nach dem Geldabfluss erkennt, hat eine Lücke, die Prüfer als Programmschwäche statt als Umsetzungspräferenz bewerten.

Auch wirtschaftlich spricht viel für die frühere Entscheidung. Eine Hochrisiko-Einzahlung an der Freigabe zu blockieren kostet einen API-Aufruf. Dieselbe Einzahlung über drei Schritte durch Mixing-Dienste zu verfolgen kostet Analysten Tage, und eine Rückgewinnung ist selten. Vorgelagertes Screening unterscheidet eine präventive Kontrolle von einer rein berichtenden.

Wie schnell ein Screening-Aufruf antworten muss

Die Grenze setzt die Nutzererfahrung, nicht die Anbieterfähigkeit. Eine Auszahlung mit zwei Sekunden Wartezeit auf eine Prüfung wirkt defekt. Eine zehn Sekunden zur Analystenprüfung zurückgehaltene Einzahlung wirkt eingefroren. Das Latenzbudget ist daher knapp und wird in Hunderten Millisekunden statt Sekunden gemessen. Eine übliche praktische Obergrenze liegt bei etwa 500 Millisekunden über den gesamten Ablauf, vom Eintritt in die Freigabelogik bis zur Entscheidung Zulassen, Zurückhalten oder Blockieren. Darunter bleibt die Prüfung für Nutzer unsichtbar. Darüber wirkt sie als Reibung, die Nutzer zur Umgehung der Kontrolle drängt.

Der ideale Zielwert liegt niedriger. Eine API-Antwort unter 100 Millisekunden lässt Raum für die übrige Freigabelogik. Netzwerkumlaufzeit, interne Weiterleitung, Protokollierung und Schwellenwertentscheidung verbrauchen zusätzlich Zeit. Beansprucht die API allein 300 Millisekunden, bleibt dem übrigen System kein Spielraum. Latenz ist kein Datenblattmerkmal. Sie entscheidet, ob die Kontrolle mit der Transaktion läuft oder ihr hinterhereilt.

BlockSec gibt für seine Echtzeit-Screening-API Latenzen im Millisekundenbereich an. Bestätigen Sie den Zielwert unter produktivem Datenverkehr, bevor Sie eine interne SLA darauf aufbauen. Eine Freigabelogik, die 50 Millisekunden annimmt und 400 erlebt, verschlechtert sich vor dem ersten Alarm. Sie muss den realen Wert messen und bei Überschreitung kontrolliert auf einen Ersatzpfad wechseln.

Wie eine Echtzeit-KYT-Screening-API funktioniert

Eine Echtzeit-KYT-Screening-API liegt im Entscheidungspfad der Transaktion, nicht daneben. Vier Schritte müssen innerhalb des Latenzbudgets enden. Der Client authentifiziert sich und übermittelt Adresse oder Transaktionskennung. Die API gleicht sie mit ihren Risikodaten ab und liefert einen Score mit Belegen. Die Freigabelogik des Clients ordnet ihn anhand als Code definierter Schwellen dem Blockieren, Zurückhalten oder Zulassen zu und gibt die Transaktion frei oder fängt sie ab. Der Aufruf ist synchron und adressbezogen, weil die Antwort vor der Freigabe vorliegen muss.

Phalcon Compliance stellt seine Echtzeit-Screening-API genau so bereit. Ein einzelner API-Schlüssel steuert den Zugang. Der Aufruf liefert Risikoscore, Expositionswerte und die ausschlaggebenden Risikoindikatoren. Die Risikodaten beruhen auf mehr als 600 Millionen gekennzeichneten Adressen und über 17 Risikoindikator-Kategorien für Verhaltensmuster, Exposition gegenüber bekannten illegalen Diensten und Gegenparteirisiken. Der Score steuert die Freigabe. Indikatoren und Expositionswerte dienen Analysten bei zurückgehaltenen Transaktionen zur Prüfung und machen die Entscheidung prüfbar statt undurchsichtig.

Zwei Begrenzungen prägen die Nutzung. Erstens ist der Zugang Scale ab $699 pro Monat und Enterprise vorbehalten. Free, Screening Packages und Essential bieten interaktives Screening über die Plattformoberfläche, keine Einbettung in die Transaktionsfreigabe. Wer vorgelagertes Screening entwickelt, braucht Scale oder Enterprise vor dem ersten Aufruf. Zweitens entscheidet die tatsächliche Latenz im Millisekundenbereich darüber, ob die API für eine vorgelagerte Freigabe geeignet ist oder auf nachgelagerte Überwachung zurückgegriffen werden muss. Die Bestätigung unter eigener Last gehört zum Produktivstart und ist keine spätere Formalität.

Blockieren, zurückhalten oder zulassen: Vor der Geldbewegung entscheiden

Echtzeit-Screening ist nur nützlich, wenn die Freigabelogik das Ergebnis verarbeiten kann. Passend ist ein dreistufiges Modell statt eines binären Freigeben-oder-Markieren-Ansatzes. Die Score-Bereiche sind jeweils mit einer konkreten Maßnahme verknüpft, die ohne Warten auf einen Menschen ausgeführt wird.

Erstens Zulassen: Risikoarme Adressen werden automatisch innerhalb des Latenzbudgets freigegeben. Dieser Bereich muss den Großteil des Volumens ausmachen. Zweitens Zurückhalten: Adressen mit mittlerem Risiko werden weder freigegeben noch blockiert. Die Transaktion pausiert, ein Alarm geht in die Prüfwarteschlange, und ein Analyst entscheidet anhand von Indikatoren und Expositionswerten. Dies erfasst uneindeutige Scores, bei denen menschliches Urteil die Verzögerung rechtfertigt. Drittens Blockieren: Hochrisiko-Adressen werden vor der Freigabe abgefangen, die Transaktion wird nicht gesendet, und ein Alarm mit vollständiger Beweiskette entsteht. Diese Prävention kann nachgelagerte Überwachung nicht leisten.

Die Stärke liegt in der Prüfkette, nicht nur in der Entscheidung. Jede Entscheidung muss reproduzierbar sein: Score, zugehöriger Bereich, ausschlaggebende Indikatoren und ausgeführte Maßnahme. Eine Blockierung muss sich als beleggestützte Entscheidung statt als Faustregel begründen lassen. Ein Zurückhalten muss als tatsächlich geprüfte und entschiedene Pause prüfbar sein, nicht als still verworfene Transaktion. Risikoindikatoren und Expositionswerte vervollständigen die Kette. Ohne sie ist die Bearbeitung ein Urteil, mit ihnen eine dokumentierte, für Prüfer lesbare Entscheidung.

Echtzeit, Batch oder Monitor: Wann welcher Modus passt

Vorgelagertes Screening ist nicht der einzige Modus. Ihre Verwechslung ist ein häufiger Fehler. Eine Echtzeit-KYT-API bietet drei Modi mit unterschiedlichen Fragen. Die Echtzeit-Einzelprüfung beantwortet: „Kann diese Transaktion jetzt sicher freigegeben werden?“ Batch-Screening fragt: „Welches Risikoprofil hat dieser Rückstand?“ Monitor fragt: „Hat sich das Risiko einer bereits geprüften Adresse seit der letzten Betrachtung verändert?“ Die Modi sind nicht austauschbar. Der falsche verbraucht unnötig Kontingent oder übersieht Risiken.

Die Echtzeit-Einzelprüfung ist synchron, latenzarm und läuft einmal je Transaktion an der Freigabe. Batch-Screening läuft asynchron für CSV-Uploads historischer Bestände außerhalb des Transaktionspfads. Monitor läuft fortlaufend. Es analysiert bereits geprüfte Adressen nach einem dynamischen Zeitplan erneut und reagiert auf Risikoänderungen bisher unauffälliger Adressen, etwa bei späterer Sanktionierung einer Gegenpartei.

Die praktische Aufteilung: Echtzeit bearbeitet die laufende Freigabe, Batch den Rückstand, Monitor die Veränderung. Nur Echtzeit bleibt blind für später entstehende Risiken. Nur Monitor bietet keine vorgelagerte Entscheidung. Nur Batch bietet keines von beidem. Eine tragfähige Konfiguration nutzt alle drei für ihre jeweilige Aufgabe. Monitor verbraucht kein Screening-Kontingent und belastet daher nicht das Einzelprüfungsbudget von Echtzeit und Batch. Diese Seite behandelt den Echtzeitpfad. Die Einbindung aller drei in Börsenabläufe ist ein eigenes Integrationsthema.

Integrationscheckliste für Screening vor Transaktionen

Eine vorgelagerte Screening-Freigabe ist fertig, wenn sie für jede Transaktion Maßnahme, Grund und Entscheidungsdauer nennen kann. Die folgende Checkliste konzentriert sich auf die Echtzeitfreigabe selbst.

1. API-Tarif bestätigen. Echtzeit-API-Zugriff erfordert Scale ab $699 pro Monat oder Enterprise. Bestätigen Sie dies vor dem ersten Aufruf.

2. Latenzbudget im Code festlegen. Definieren Sie die Obergrenze des vollständigen Pfads – häufig etwa 500 Millisekunden – und messen Sie die tatsächliche Umlaufzeit unter produktivem Datenverkehr. Die veröffentlichte Antwortzeit ist ein zu bestätigender Zielwert, keine Annahme.

3. Schwellenbereiche als Code definieren. Blockieren, Zurückhalten und Zulassen müssen programmatisch am Score ausgerichtet sein. Eine nur dokumentierte, aber nicht implementierte Richtlinie läuft nicht auf der Transaktion.

4. Alarmweg vor dem Produktivstart einbinden. Zurückhalten und Blockieren müssen eine echte Warteschlange erreichen: Webhook, Ticket oder internen Kanal. Ein erst nach dem ersten verpassten Alarm ergänztes Routing ist bereits ein Fehler.

5. Belege bei jeder Entscheidung speichern. Score, Schwellenbereich, Risikoindikatoren und Expositionswerte gehören in den Transaktionsdatensatz. Die Entscheidung muss Monate später reproduzierbar sein.

6. Ersatzpfad bei Störungen aufbauen. Überschreitet die API das Latenzbudget oder meldet Fehler, muss die Freigabelogik definiert reagieren: zur Prüfung zurückhalten oder mit nachgelagerter Überwachungsmarkierung zulassen, statt die Transaktion still zu verwerfen.

7. Rate-Limits behandeln. Die Screening-API begrenzt Aufrufe je Schlüssel; darüber folgt HTTP 429. Der Client muss Wartezeiten verlängern statt sofort erneut zu versuchen.

8. Monitor für Risikoänderungen aktivieren. Vorgelagertes Screening erkennt das Risiko an der Freigabe, Monitor später entstehende Risiken. Es verbraucht kein Screening-Kontingent und kann ohne Belastung des Echtzeitbudgets aktiv bleiben.

Eine Freigabelogik, die diese Checkliste erfüllt, trifft Entscheidungen im Transaktionspfad mit wirksamen Schwellen, erreichbaren Menschen, dauerhaften Belegen und einem sicheren Ersatzpfad. Das bedeutet Echtzeit-Screening vor Transaktionen in der Praxis. Lesen Sie die KYT-API-Dokumentation von Phalcon Compliance für Endpunktreferenz, Scale-Einstieg und vollständiges Risikoindikator-Schema.