Wenn manuelles Screening an seine Grenzen stößt
Manuelles Screening scheitert an drei Problemen, die gleichzeitig auftreten. Das Volumen wächst, bis Kopieren und Einfügen nicht mehr ausreichen. Die Prüfwarteschlange staut sich, und Auszahlungen verzögern sich, während Nutzer warten. Und sobald eine Prüfung abgeschlossen ist, behält niemand die Adresse mehr im Blick. Eine Risikoänderung drei Wochen später bleibt deshalb unbemerkt. Automatisierung setzt an allen drei Punkten zugleich an.
Der erste Engpass ist die schiere Menge. Einzahlungen und Auszahlungsanfragen treffen gebündelt ein. Wer sie einzeln abarbeitet, wird schnell zum langsamsten Glied im Prozess. Der zweite Engpass ist die Warteschlange selbst. Jede Minute, die eine Adresse auf ihre Prüfung wartet, wartet auch ein Nutzer auf sein Geld. So entsteht der Eindruck, Compliance stehe dem Produkt im Weg. Der dritte Faktor ist die Zeit. Eine manuelle Prüfung endet mit ihrem Abschluss; sie läuft danach nicht weiter.
Die Financial Action Task Force erwartet im Rahmen eines risikobasierten Ansatzes eine fortlaufende Überwachung, nicht nur eine Eingangskontrolle. Zudem ändern sich Sanktionslisten nach ihrem eigenen Zeitplan. Das zeigt die Seite der jüngsten OFAC-Maßnahmen deutlich: Eine Adresse kann an jedem beliebigen Morgen auf einer Liste erscheinen, unabhängig davon, ob gerade jemand hinsieht. Diese beiden Tatsachen sind die zentralen Gründe, Screening in Ihre Systeme einzubinden, statt es in einem Browser-Tab zu belassen.
Automatisierung verändert den Ort der Prüfung. Als Teil des Verarbeitungsprozesses läuft sie unabhängig davon, ob jemand daran denkt. Sie legt an die zehntausendste Adresse denselben Maßstab an wie an die erste und protokolliert ihre Ergebnisse ohne gesonderte Aufforderung. Gerade dieser letzte Punkt, die Dokumentation, macht aus einem Audit kein eigenes Projekt mehr, sondern eine gezielte Abfrage.
| Aspekt | Manuelles Screening | Automatisierter Prozess |
|---|---|---|
| Ort der Prüfung | Ein Browser-Tab, den jemand rechtzeitig öffnen muss | Direkt im Ein- und Auszahlungsablauf |
| Einheitlichkeit bei hohem Volumen | Abhängig von Person und Tageszeit | Derselbe Maßstab für jede Adresse |
| Überwachung nach der Freigabe | Endet mit dem Abschluss der Prüfung | Webhooks melden Änderungen der Risikostufe |
| Dokumentation | Wird auf Anfrage für ein Audit rekonstruiert | Entsteht laufend im Verarbeitungsprozess |
Die Anzeichen für einen nötigen Wechsel sind eindeutig: tägliche Prüfungen, bei denen kein Tag ausfallen darf, Audits, die Nachweise für jede Entscheidung verlangen, und eine Überwachungspflicht, die Ihr Team nur noch dem Anspruch nach erfüllt.
Batch-Screening über die API
Die API macht aus Einzelprüfungen einen Prozessschritt. Anfragen gehen an die Basisadresse https://api.blocksec.com mit dem Pfadpräfix /phalcon/compliance/v2/. Zur Authentifizierung dient ein API-Schlüssel, den Sie unter System, dann API und anschließend Generate Key erzeugen. Für Screening-Anfragen gilt ein Limit von 50 pro Minute und Schlüssel, für andere Aufrufe von 10 pro Sekunde. code=0 kennzeichnet eine erfolgreiche Antwort.
Vier Screening-Endpunkte übernehmen die Arbeit: /address/screen für eine einzelne Adresse, /addresses/screen für Adress-Batches, /transaction/screen für eine einzelne Transaktion und /transactions/screen für Transaktions-Batches. Dank der Einzel- und Batch-Varianten kann Ihr Prozess dasselbe Werkzeug sowohl für den gelegentlichen manuellen Fall als auch für einen nächtlichen Auftrag mit zehntausend Einträgen nutzen.
Rund um diese Endpunkte gelten die üblichen Grundregeln für zuverlässige Verarbeitung. Berücksichtigen Sie das Anfragelimit bereits bei der Planung, statt sich davon überraschen zu lassen: Stellen Sie Batches in eine Warteschlange, verlängern Sie bei Erreichen des Limits die Wartezeit und sehen Sie Wiederholungen für fehlgeschlagene Aufrufe vor. Prüfen Sie im Moment der Entscheidung, also bei einer Ein- oder Auszahlung, und speichern Sie das Ergebnis zusammen mit der zugehörigen Transaktion. So bleibt die Zuordnung erhalten.
Schlüssel werden projektbezogen verwaltet. Sämtliche Details zu Anfragen und Antworten finden Sie Feld für Feld in der offiziellen API-Dokumentation. Diese Seite bleibt auf der Ebene des Arbeitsablaufs, statt sie zu wiederholen.
Ein Punkt gehört in Ihre Zeitplanung: Die API steht in den Tarifen Scale und Enterprise zur Verfügung, nicht in jedem Tarif. Falls Ihr Rollout API-Zugriff voraussetzt, prüfen Sie zuerst, ob Ihr Tarif diesen umfasst. Das ist eine echte Voraussetzung, keine Formalität. Klären Sie sie besser in Woche eins als in Woche sechs.
Änderungen mit Webhooks überwachen
Webhooks übernehmen die laufende Überwachung. Sie registrieren einen Endpunkt, und der Dienst sendet zwei Arten von Nachrichten dorthin: notification-Nachrichten vom Typ 1 mit Alarmen der Risiko-Engine und monitorEvent-Nachrichten vom Typ 2 mit Monitor-Ereignissen. Letztere melden, wenn sich bei einer bereits freigegebenen Wallet etwas geändert hat.
Für einen Compliance-Ablauf sind Änderungen der Risikostufe besonders wichtig: Risk Level Increased und Risk Level Decreased. Beide enthalten prevLevel und newLevel, damit Ihr System den Sprung erkennt, sowie die Risk Timeline der Adresse. Eine Wallet, die beim Onboarding unauffällig war und später mit sanktionierten Geldern in Berührung kommt, löst genau dieses Ereignis aus. Das ist die maschinenlesbare Antwort auf die häufige Frage, ob eine unauffällige Wallet später riskant werden kann. Ja, und genau so wird diese Änderung gemeldet.
Ein Feldname verdient einen ausdrücklichen Hinweis, weil er wie ein Tippfehler aussieht, aber keiner ist: targetIdentifiter steht in den offiziellen Payloads exakt in dieser Schreibweise. Übernehmen Sie ihn genauso aus der Dokumentation, einschließlich der ungewöhnlichen Buchstabenfolge. Andernfalls scheitert Ihre Integration an einem Fehler, dessen Suche einen ganzen Nachmittag kosten kann.
Die Zustellung endet nicht bei Ihrem Server. Dieselben Alarme werden über 7 Benachrichtigungskanäle verteilt, darunter Telegram, E-Mail und Lark. Wer handeln muss, ist so über die ohnehin genutzten Kanäle erreichbar, statt über ein Dashboard, das um 2 Uhr nachts niemand beobachtet.
Legen Sie zusammen mit den Kanälen auch die Zuständigkeiten fest. Ein Alarm an alle ist oft ein Alarm, für den sich niemand verantwortlich fühlt. Jeder Kanal sollte einer Person oder einem Bereitschaftsdienst zugeordnet sein. Halten Sie schriftlich fest, wie schnell eine Änderung der Risikostufe aufgegriffen werden muss und welche erste Reaktion vorgesehen ist.
Was Automatisierung insgesamt bewirkt
Sobald Screening Teil des Verarbeitungsprozesses ist, greifen drei Dinge ineinander. Jede Einzahlung wird vor der Annahme geprüft, sodass Entscheidungen auf Belegen beruhen. Jede freigegebene Wallet bleibt unter Beobachtung, sodass Risikoänderungen von selbst sichtbar werden. Und jede Prüfung hinterlässt einen Nachweis. Für Audits werden Unterlagen dann abgerufen statt rekonstruiert.
Die Kapazität ist auf diese Arbeitsweise ausgelegt: Screening-Antworten in unter 100 Millisekunden und mehr als 200 Risikosignale, die in den Score einfließen, laut BlockSec. Das Preismodell beginnt mit einer kostenlosen Stufe. Hinzu kommen bei Bedarf Guthabenpakete oder, bei wachsendem Arbeitsaufkommen, ein monatliches Abonnement.
Die ehrliche Grenze lautet: Automatisierung erweitert und beschleunigt die Abdeckung, lässt Risiken aber nicht verschwinden. Eine falsche Richtlinie bleibt falsch, auch wenn sie schnell und lückenlos protokolliert angewandt wird. Die oben genannten Anfragelimits und Tarifvoraussetzungen bilden die praktischen Grenzen. Planen Sie innerhalb dieser Grenzen, erweitern Sie bei Bedarf Ihre Kapazität und überprüfen Sie die Richtlinie regelmäßig, nicht erst, wenn etwas schiefgeht.
Die Grundlagen dahinter, also was Labels und Signale tatsächlich sind und wie ein Score entsteht, erklärt Was ist Adress-Screening in der Krypto-Compliance?. Einen Überblick über das gesamte Thema, von der ersten Prüfung über die Überwachung bis zur Dokumentation, bietet der Wallet-Screening-Hub.