Ein DeFi-Protokoll erfüllt seine AML-Verpflichtung, indem es Risiken genau dort prüft, wo Nutzer Vermögenswerte einzahlen, als Kredit aufnehmen, tauschen oder auszahlen. Eine zentrale Compliance-Abteilung muss dafür nicht aufgebaut werden. Das Integrationsmuster besteht aus Echtzeit-API-Prüfungen an diesen Ein- und Ausstiegspunkten und der laufenden Überwachung von Adressen nach der ersten Interaktion. Diese Kombination schließt die Lücke zwischen DeFi- und Börsen-Compliance. Dieser Leitfaden zeigt, wo die Prüfungen eingebunden werden und wie sich der Workflow von dem einer zentralen Börse unterscheidet. Den übergeordneten Workflow erläutert Phalcon Compliance. Diese Seite ist Teil des AML-Compliance-Wissensportals.
Der neue Compliance-Druck auf DeFi-Protokolle
Die regulatorische Einbeziehung von DeFi ist nicht mehr nur theoretisch. Das FATF-Rahmenwerk für virtuelle Vermögenswerte erstreckt Geldwäschepräventionspflichten auf jede Entität, die wirksame Kontrolle über Finanzdienstleistungen ausübt. Diese Formulierung erfasst DeFi-Protokolle mit Kontrolle über Nutzergelder, pausierbare Pools oder Administratorschlüssel. Immer mehr Rechtsräume haben Empfehlung 15 in nationales Recht umgesetzt. Die Screening-Pflicht erreicht DeFi-Protokolle daher unabhängig davon, ob im Team jemand einen Compliance-Titel trägt. FinCENs Regel zur Kundensorgfaltspflicht setzt in den Vereinigten Staaten dieselbe Erwartung und behandelt kontinuierliche Überwachung als Voraussetzung der Compliance-Programme erfasster Institute. In der EU sind die Screening- und Meldepflichten für Krypto-Vermögenswerttransfers gesondert in der Geldwäscheverordnung (AMLR) und der Geldtransferverordnung (TFR) geregelt. MiCA selbst beschränkt sich auf Zulassungs- und Marktverhaltensregeln. Beide Rahmenwerke führen zur gleichen praktischen Anforderung: Belegen Sie, dass das Protokoll Gegenparteirisiken vor Geldbewegungen prüft – und zwar fortlaufend.
Die Onchain-Kriminalität verschärft diesen Druck. FATF und nationale Aufsichtsbehörden haben wiederholt darauf hingewiesen, dass inzwischen ein erheblicher Anteil illegaler Krypto-Gelder über DeFi-Plattformen fließt. Protokolle ohne Screening sind damit nicht nur regelwidrig, sondern riskieren auch, als Durchleitungskanal benannt zu werden. Die Aufsicht muss ein DeFi-Protokoll nicht als reguliertes Institut im klassischen Sinne behandeln. Sie verlangt entsprechendes Verhalten auf Transaktionsebene – genau dort, wo DeFi-Teams die wenigsten integrierten Werkzeuge haben.
Die personelle Lage bildet die andere Hälfte des Problems. Ein DeFi-Team hat meist keine eigenen Compliance-Mitarbeiter, ein knappes Budget und Bedarf an Echtzeit-Risikokontrollen an den tatsächlich geldbewegenden Transaktionspunkten. Compliance-Aufgaben landen bei Entwicklern oder Sicherheitsingenieuren, die bereits Protokoll-Upgrades ausliefern, Oracle-Risiken steuern und Vorfälle bearbeiten. Ein Programm, das eine Vollzeit-Compliance-Stelle voraussetzt, ist daher für eine Organisationsstruktur entworfen, die das Protokoll nicht besitzt. Der realistische Weg besteht darin, Screening in den Smart-Contract-Ablauf selbst zu integrieren, sodass das Protokoll standardmäßig prüft, statt sich auf Personal zu stützen.
Wie sich DeFi-Compliance von CEX-Compliance unterscheidet
Die meisten öffentlichen Leitfäden zur Krypto-Compliance richten sich an zentrale Börsen und setzen ein Käuferprofil voraus, das nicht zu DeFi-Teams passt. Zentrale Börsen unterhalten eigene Compliance-Abteilungen, integrieren Screening-Anbieter vollständig im Backend und können sechsstellige Jahresabonnements mit ihrem Volumen rechtfertigen. DeFi-Protokolle stehen in jeder dieser Dimensionen am entgegengesetzten Ende. Wer das CEX-Modell unverändert übernimmt, schafft ein Programm, das das Protokoll personell nicht tragen, nicht bezahlen und nicht fertig integrieren kann.
| Dimension | Zentrale Börse (CEX) | DeFi-Protokoll |
|---|---|---|
| Compliance-Personal | Eigenes Compliance-Team | Meist keines; Entwickler oder Sicherheitsingenieure übernehmen die Aufgabe |
| Integrationsfläche | Vollständige Backend-Integration für Batch und Echtzeit | API an Smart-Contract-Interaktionspunkten für Einzahlungen, Kreditaufnahmen und Swaps |
| Budget | Sechsstellige Jahresabonnements tragbar | Knapp; nutzungsbasierte Kosten nötig |
| Screening-Rhythmus | Vollständige Echtzeitprüfung aller Abläufe | Echtzeit an Hochrisikopunkten, laufender Monitor für den Rest |
Ein DeFi-Protokoll sollte daher nicht versuchen, überall alles zu prüfen. Es sollte die Smart-Contract-Interaktionspunkte prüfen, an denen Exposition tatsächlich eintritt. Einzahlung, Kreditaufnahme und Swap sind die drei Punkte, an denen über die Gegenparteiadresse Risiken in das Protokoll gelangen. Screening dort ist die praktikable Mindestabdeckung. Alles Weitere lässt sich durch kontinuierliche Überwachung bereits bekannter Adressen und bedarfsweise Prüfung von Sonderfällen behandeln. Diese Aufteilung macht DeFi-Compliance für ein kleines Team mit knappem Budget handhabbar.
Beim Budget führen CEX-orientierte Leitfäden DeFi-Teams am stärksten in die Irre. Ein starres Jahresabonnement setzt stabiles, planbares Screening-Volumen voraus – das Gegenteil der DeFi-Realität. Onchain-Aktivitäten schwanken mit Marktzyklen, neuen Pools und Anreizprogrammen. Ein Vertrag mit fester Kapazität verschwendet in ruhigen Phasen Geld oder verursacht in Spitzenzeiten Zusatzkosten. Zu DeFi passt ein Modell, bei dem die Ausgaben dem Volumen folgen, statt das Volumen ein Jahr im Voraus vorhersagen zu müssen.
DeFi-Integration: API-Screening bei Einzahlungen, Kreditaufnahmen und Swaps
DeFi-Teams können mit der KYA- und KYT-API von Phalcon Compliance Adressen an Einzahlungs-, Kreditaufnahme- und Swap-Punkten prüfen. Die Anwendung wertet die zurückgegebene Risikobewertung aus, bevor sie die Transaktion zulässt oder zurückhält. Monitor beobachtet die Adresse anschließend auf spätere Risikoänderungen.
Der Integrationspunkt liegt im Smart-Contract-Ablauf, nicht im Dashboard. Wenn ein Nutzer in einen Pool einzahlt, gegen Sicherheiten einen Kredit aufnimmt oder über einen Aggregator tauscht, kann das Protokoll vor der Freigabe die KYT- und KYA-API-Endpunkte von Phalcon Compliance aufrufen. Diese liefern an den entsprechenden Smart-Contract-Interaktionspunkten in Echtzeit einen Adressrisikoscore und Risikoindikatoren. Anhand des Scores entscheidet das Protokoll, ob die Interaktion freigegeben, zurückgehalten oder blockiert wird. Die Indikatoren fügen nachverfolgbare Belege bei, damit die Entscheidung später einem Audit standhält. Dieselbe API, die eine zentrale Börse in ihre Ein- und Auszahlungsfreigabe integriert, greift hier an Smart-Contract-Interaktionspunkten statt am Orderbuch. Die Börsenintegration ist im KYT-API-Integrationsplan für Kryptobörsen dokumentiert.
Die Kostenabstimmung macht diese Integration für ein DeFi-Budget realistisch. PAYG-Guthaben für Screening Packages beginnt bei $95 für 50 bis 2000 Credits mit 12 Monaten Gültigkeit. Ein Protokoll, dessen Screening-Volumen mit den Anreizzyklen schwankt, kann bei hoher Aktivität Guthaben kaufen und es bei geringer Aktivität liegen lassen. Es gibt keine vertragliche Bindung. Stabilisiert sich das Volumen, kann es zu einem Abonnement wechseln. API-Integration ist ausschließlich ab Scale für $699 pro Monat und im Enterprise-Tarif verfügbar. Wer API-Aufrufe an Smart-Contract-Interaktionspunkten plant, muss die Tarifvoraussetzung vor dem Programmieren bestätigen. Zusammenarbeit über mehrere Nutzerplätze und Empfehlungsprämien behandelt die FAQ unten.
Für Protokolle, die noch nicht für eine API-Integration bereit sind, gibt es eine leichtgewichtige Alternative. Interaktives Screening über die Plattformoberfläche prüft Gegenparteiadressen bei Bedarf ohne API-Integration und eignet sich für einfache oder Audit-Szenarien. Sicherheitsingenieure, die eine markierte Adresse manuell prüfen, oder Treasury-Multisig-Unterzeichner vor einem großen Transfer können diesen Weg ohne Integration nutzen.
Einführungsmuster: Screening an Smart-Contract-Interaktionspunkten, Monitor und selbstständige Prüfung
Das vollständige Einführungsmuster für ein DeFi-Protokoll hat drei Ebenen mit jeweils eigener Screening-Frage. Keine ist optional, wenn das Programm einer Prüfung standhalten soll. Jede verursacht jedoch unterschiedlichen Entwicklungsaufwand und Kontingentbedarf.
Die erste Ebene ist Screening an den geldbewegenden Smart-Contract-Interaktionspunkten. Vor der Freigabe eines Einzahlungs-, Kreditaufnahme- oder Swap-Aufrufs ruft das Protokoll die KYT- und KYA-API mit der Gegenparteiadresse auf und liest den Risikoscore. Die schwellenwertbasierte Weiterleitung ist im Smart Contract oder in einem Offchain-Keeper definiert, auf den sich der Smart Contract stützt. Adressen mit niedrigem Risiko werden freigegeben, Adressen mit mittlerem Risiko zur manuellen Prüfung zurückgehalten und Adressen mit hohem Risiko direkt blockiert. Diese Ebene schließt das Echtzeit-Geldwäschefenster und verbraucht als einzige das Kontingent für Einzelprüfungen.
Die zweite Ebene ist die kontinuierliche Überwachung bereits kontaktierter Adressen. Der Monitor-Modus analysiert bereits geprüfte Adressen bei Risikoänderungen nach einem dynamischen Zeitplan erneut und verbraucht kein Screening-Kontingent. Für DeFi erfasst diese Ebene Adressen, die bei der ersten Einzahlung unauffällig waren, später aber mit sanktionierten Entitäten oder bekannten problematischen Akteuren interagieren. Ohne Verbrauch des Screening-Kontingents kann das Protokoll Monitor für den gesamten historischen Adressbestand aktiv lassen, ohne das Einzelprüfungsbudget linear zu erhöhen.
Die dritte Ebene ist die selbstständige Prüfung bei Bedarf über die Plattformoberfläche. Sicherheitsingenieure nutzen sie bei Vorfällen, manuellen Prüfungen oder Gegenparteiprüfungen eines neuen Oracles oder Smart Contracts eines Partners vor der Bereitstellung. Sie braucht keine API-Integration und deckt einmalige Prüfungen ab, für die sich die Einbindung auf Smart-Contract-Ebene nicht lohnt. Gemeinsam ergeben die drei Ebenen ein Programm, das an den entscheidenden Punkten in Echtzeit prüft, den Rest kontinuierlich kostenlos beobachtet und dem Team einen manuellen Weg für Sonderfälle bietet.
Mit Phalcon Compliance für DeFi-Protokolle starten
Ein DeFi-Protokoll braucht keine zentrale Compliance-Abteilung, um seine AML-Pflichten zu erfüllen. Es braucht Screening an geldbewegenden Smart-Contract-Interaktionspunkten, laufende Überwachung bereits kontaktierter Adressen und ein volumenabhängiges Kostenmodell statt eines festen Jahresvertrags. Phalcon Compliance bietet alle drei Elemente durch eine gemeinsame KYT- und KYA-API, einen Monitor-Modus ohne Verbrauch des Screening-Kontingents und einen PAYG-Einstieg ab $95. Starten Sie mit Phalcon Compliance für DeFi-Protokolle und ordnen Sie vor dem nächsten Protokoll-Upgrade das Screening den Einzahlungs-, Kreditaufnahme- und Swap-Punkten zu.