Eine KYT-API-Integration ruft bei jeder Ein- und Auszahlung den Screening-Endpunkt auf, wertet den Risikoscore aus und steuert die Transaktion, bevor Gelder bewegt werden. Batch-Screening und laufende Überwachung ergänzen die Abdeckung historischer Adressen und veränderlicher Adressrisiken. Die API gehört in den Transaktionsfluss statt daneben. Echtzeitprüfungen erfassen riskante Aktivitäten vor der Abwicklung, während Batch-Aufgaben und Überwachung die Zwischenräume abdecken. Dieser Leitfaden erläutert alle drei Modi für eine Kryptobörse. Den übergeordneten Workflow beschreibt Phalcon Compliance. Diese Seite ist Teil des AML-Compliance-Wissensportals.
Warum Börsen Echtzeit-Screening auf API-Ebene brauchen
Mit dem gewählten Screening-Rhythmus akzeptiert eine Börse zugleich ein Geldwäschefenster. Ein wöchentlicher oder täglicher Batch-Job prüft jede Adresse zum Ausführungszeitpunkt. Jede zwischen zwei Durchläufen eintreffende Einzahlung gelangt jedoch ungeprüft in die Wallet. In dieser Lücke können Gelder eintreffen, weiterbewegt und ausgezahlt werden. Echtzeit-Screening auf API-Ebene schließt sie, weil jede Ein- und Auszahlung vor der Freigabe geprüft wird.
Der Antrieb ist nicht nur betrieblich. FinCEN verlangt von Money Services Businesses einschließlich Kryptobörsen ein AML-Programm (31 CFR 1022.210) und die Meldung verdächtiger Transaktionen (31 CFR 1022.320), zusammen mit den Leitlinien zu virtuellen Währungen von 2019 (FIN-2019-G001). Diese Kombination macht in der Praxis laufende Überwachung nötig, schreibt aber keinen festen Echtzeit-Grenzwert vor. Der risikobasierte Ansatz der FATF für Anbieter von Dienstleistungen für virtuelle Vermögenswerte führt zur gleichen Anforderung: VASPs müssen Transaktionen laufend überwachen statt nur einmal beim Onboarding zu prüfen. Eine Börse erfüllt beides mit einer aktiven Kontrolle für jede Ein- und Auszahlung, wie sie der unten beschriebene Echtzeit-API-Modus bietet. Ein reiner Batch-Rhythmus lässt eine erkennbare Lücke zwischen Überwachungspflicht und tatsächlich laufender Kontrolle. Prüfer sehen darin eine Programmlücke, keine Präferenz bei der technischen Umsetzung.
Die Entwicklerseite bringt eine eigene Einschränkung mit. Keine Kombination fertiger Drittanbieter-Tools passt zum Anwendungsfall einer Börse, bis die Tools tatsächlich auf interne Systeme zugreifen können. Die unterschätzte Herausforderung ist daher Integration statt Funktionszahl. Eine Screening-Engine ohne Verbindung zu Einzahlungen, Auszahlungen und Alarmweiterleitung verändert nicht, was die Börse erkennen kann. Sie verändert nur ein Dashboard. Erst die Integration macht aus einer Screening-Funktion ein Screening-Programm.
Vor der Integration: Risikoschwellen, Alarmweiterleitung und Systemzugriff
Bevor ein API-Aufruf implementiert wird, müssen drei Entscheidungen feststehen. Sie bestimmen das Verhalten der produktiven Integration. Spätere Änderungen erfordern eine Überarbeitung von API-Client und nachgelagertem Alarmweg. Diese Entscheidungen gehören zum umfassenderen AML-Compliance-Programm für eine Kryptobörse, das Risikobewertung, Screening, Triage und prüfbare Aufzeichnungen behandelt. Diese Seite konzentriert sich auf dessen API-Integration statt auf den Programmaufbau.
Die erste Entscheidung betrifft das Regelwerk der Risikoschwellen. Eine KYT-API liefert einen Risikoscore. Dieser bewirkt aber nichts, bevor die Börse festlegt, welche Score-Bereiche welche Maßnahmen auslösen. Üblich sind drei Bereiche: Bei niedrigem Risiko wird die Transaktion automatisch freigegeben, bei mittlerem zur manuellen Prüfung zurückgehalten und bei hohem blockiert; zusätzlich wird bei hohem Risiko ein Alarm ausgelöst. Die Schwellen müssen als Code statt nur als Richtlinie definiert sein, weil der API-Client sie programmatisch verwendet.
Die zweite Entscheidung betrifft die Alarmweiterleitung. Überschreitet ein Score eine Schwelle, muss der Alarm einen Menschen oder eine Warteschlange erreichen. Das Routing legt den Kanal fest: etwa einen Webhook in einen Slack- oder Telegram-Kanal, ein Ticket im Fallmanagement oder einen Eintrag in einer internen Warteschlange. Die Plattform unterstützt mehrere Benachrichtigungskanäle einschließlich Webhook. Der Weg muss vor dem Produktivstart feststehen und darf nicht erst nach dem ersten verpassten Alarm ergänzt werden.
Die dritte Entscheidung betrifft die Tarifvoraussetzungen. API-Zugriff gibt es ausschließlich ab Scale für $699 pro Monat und in Enterprise. Free, Screening Packages und Essential enthalten keinen API-Zugriff. Wer Screening in eigene Ein- und Auszahlungsabläufe einbetten will, muss zuerst Scale erreichen. Die Bestätigung vor Integrationsbeginn verhindert, dass Code für einen nicht nutzbaren Tarif geschrieben wird. Zusammenarbeit über mehrere Nutzerplätze, falls mehrere Personen im Tool arbeiten müssen, ist nur in Enterprise verfügbar. Wie diese Voraussetzung in die umfassendere Krypto-AML-Compliance eingebettet ist, erläutert das Wissensportal.
Die KYT- und KYA-API von Phalcon Compliance integrieren: Drei Modi
Die API von Phalcon Compliance unterstützt Echtzeitprüfungen, asynchrones CSV-Batch-Screening und kontinuierliche Überwachung. Echtzeitprüfungen decken Ein- und Auszahlungen ab, Batch-Screening historische Adressen und Rückstände. Monitor beobachtet bereits geprüfte Adressen auf Risikoänderungen. Börsen können die Modi je nach Ort und Zeitpunkt des Screening-Bedarfs kombinieren.
Ein Ein- und Auszahlungsablauf hat drei getrennte Screening-Bedarfe. Eine laufende Transaktion braucht eine Antwort vor der Freigabe, also einen synchronen Aufruf mit geringer Latenz. Ein Bestand noch ungeprüfter historischer Adressen muss gesammelt geprüft werden, ohne den laufenden Betrieb zu blockieren, also asynchron. Und eine bei der ersten Prüfung unauffällige Adresse kann später mit einer riskanten Gegenpartei interagieren. Das verlangt fortlaufende Beobachtung bereits geprüfter Adressen statt einer einmaligen Bewertung.
Phalcon Compliance stellt drei passende API-Modi bereit. Der Echtzeit-Einzelprüfungsmodus deckt die Ein- und Auszahlungsfreigabe ab. Ein asynchroner CSV-Batch-Modus prüft Rückstände und historische Bestände. Ein laufender Monitor-Modus analysiert bereits geprüfte Adressen nach einem dynamischen Zeitplan erneut. Die drei Modi nutzen eine gemeinsame authentifizierte Schnittstelle. Ein einziger API-Schlüssel steuert den Zugang, und die Börse wählt den Modus pro Aufruf statt separate Integrationen zu pflegen.
| Modus | Auslöser | Latenz | Kontingent und Rate-Limit | Anwendungsfall |
|---|---|---|---|---|
| Echtzeit-Einzelprüfung | Einzelne Adresse oder Transaktion | Millisekundenbereich | 50 Aufrufe pro Minute je API-Schlüssel | Laufendes Ein- und Auszahlungs-Screening |
| Asynchroner CSV-Batch | CSV-Upload | Asynchron | Adress-CSV bis 100 je Datei; Transaktions-CSV bis 400 je Batch | Rückstände und historische Bestände |
| Monitor | Kontinuierlich | Dynamischer Zeitplan | Verbraucht kein Screening-Kontingent | Neuanalyse bereits geprüfter Adressen bei Risikoänderung |
Die Integrationsfolge ist in allen Modi gleich. Der Client authentifiziert sich mit dem von der Plattform ausgestellten API-Schlüssel. Er ruft den Screening-Endpunkt mit der Adresse oder Transaktionskennung auf. Er wertet den Risikoscore einschließlich der zugehörigen Risikoindikatoren und Expositionswerte aus. Er leitet anhand der zuvor definierten Schwellenregeln weiter. Wird eine Schwelle überschritten, gibt er den Alarm über den konfigurierten Webhook oder Benachrichtigungskanal aus. Die Screening-API ist auf 50 Aufrufe pro Minute je API-Schlüssel begrenzt. Weitere Aufrufe erhalten HTTP 429. Der Client muss auf HTTP 429 mit schrittweise verlängerten Wartezeiten statt sofortigen Wiederholungen reagieren.
BlockSec gibt für Echtzeit-Einzelprüfungen Latenzen im Millisekundenbereich an. Bestätigen Sie diesen Wert anhand Ihres eigenen Datenverkehrs. Bauen Sie die Integration so, dass sie Latenz toleriert, statt einen bestimmten Millisekundenwert vorauszusetzen. Messen Sie jede interne SLA unter produktivem Datenverkehr.
Rate-Limits, Kontingente und Tarifvoraussetzungen: Hinweise für die Entwicklung
Das Rate-Limit ist die erste technische Begrenzung. Die Screening-API erlaubt 50 Aufrufe pro Minute je API-Schlüssel; darüber folgt HTTP 429. Für laufende Einzahlungen ist das selten bindend, weil Einzahlungen einzeln eintreffen und eine Echtzeitprüfung vor dem nächsten Aufruf endet. Bei Massenoperationen ist es relevant: Tausende historische Adressen synchron zu prüfen würde das Limit binnen Minuten ausschöpfen. Der CSV-Batch-Modus verlagert diese Last deshalb vom synchronen Pfad. CSV-Adress-Screening akzeptiert bis zu 100 Adressen pro Datei, CSV-Transaktions-Screening bis zu 400 Transaktionen pro Batch. Rückstände werden so asynchron verarbeitet, ohne mit der laufenden Freigabe um das Aufrufbudget zu konkurrieren.
Das Kontingentmodell ist die zweite Begrenzung. Screenings verbrauchen Guthaben in einer festgelegten Reihenfolge. Zuerst wird das Abonnementkontingent verbraucht, das pro Zyklus zurückgesetzt wird. Danach werden Top-up Screenings, dann Referral Rewards und zuletzt Screening Packages genutzt. Die Integration muss nicht auswählen, welches Guthaben verwendet wird. Das budgetverantwortliche Compliance-Team muss die Reihenfolge jedoch kennen, weil sie bestimmt, welcher Bestand zuerst aufgebraucht wird und wann eine Aufladung nötig ist. Monitor ist die Ausnahme. Es analysiert bereits geprüfte Adressen bei Risikoänderungen nach einem dynamischen Zeitplan erneut, ohne das Screening-Kontingent zu verbrauchen. Ein dauerhaft aktiver Monitor belastet daher nicht das Einzelprüfungsbudget.
Tarifvoraussetzungen sind die dritte, nicht verhandelbare Begrenzung. API-Zugriff erfordert wie beschrieben Scale ab $699 pro Monat oder Enterprise. Free, Screening Packages und Essential enthalten keinen API-Zugriff. Daneben bestimmen Zusatzfunktionen den Umfang: Webhooks sind in Scale oder Enterprise verfügbar. Die individuelle Konfiguration von Risk Engines ist ab Screening Packages möglich – 3 bei Screening Packages, 10 bei Essential, 20 bei Scale und unbegrenzt bei Enterprise. Zusammenarbeit über mehrere Nutzerplätze ist eine Enterprise-Funktion. Preisdetails behandelt der eigene Preisleitfaden. Hier geht es nur um Voraussetzungen, die die API-Integrationsplanung beeinflussen.
Die API-Dokumentation von Phalcon Compliance lesen
Eine KYT-API-Integration ist nicht abgeschlossen, wenn der erste Aufruf einen Score liefert. Sie ist abgeschlossen, wenn Echtzeitfreigabe, Rückstandsverarbeitung und Monitor-Beobachtung in die Ein- und Auszahlungsabläufe der Börse eingebunden sind. Schwellenwerte sind als Code definiert, Alarme erreichen eine echte Warteschlange, und Tarifvoraussetzungen sind vor dem ersten Aufruf bestätigt. Lesen Sie die API-Dokumentation von Phalcon Compliance für Endpunktreferenz, Webhook-Spezifikation und den Testweg über den Scale-Tarif.