Banken fordern FDIC: Stablecoin-Emittenten sollen Wallet-Screening selbst übernehmen

Jeder Entwickler, der eine Sanctions-Screening-Pipeline aufgebaut hat, kennt die harte Wahrheit: Der Kontrollkreislauf funktioniert nur, wenn die Transaktion sichtbar ist, bevor sie abgerechnet wird. Stablecoins werden in Sekunden grenzüberschreitend abgewickelt, und die FDIC hat in einer Kommentierungsphase gerade festgestellt, dass ihre beaufsichtigten Banken den Großteil dessen, was gescreent werden muss, gar nicht sehen können. Die letzte Woche eingereichten Kommentare machen diese Lücke explizit, und die operativen Folgen treffen die Engineering-Teams der Emittenten direkt.

Das Problem

Der FDIC-Regelgebungsentwurf integriert FinCEN- und OFAC-Pflichten in den eigenen Aufsichtsrahmen für zugelassene Payment-Stablecoin-Emittenten, die mit staatlichen Nicht-Mitgliedsbanken und staatlichen Sparkassen verbunden sind. Wie PYMNTS.com berichtete, endete die Kommentierungsphase am Dienstag, dem 4. August 2026, und die Antworten teilen eine gemeinsame Botschaft: Banken unterstützen regulierte Stablecoin-Emissionen, wollen aber nicht für Wallet-Aktivitäten haften, die sie nicht beobachten können.

Die Independent Community Bankers of America zog eine klare Grenze. Eine Gemeinschaftsbank, die Reserve- oder Betriebskonten führt, sollte ihre eigenen Kunden, Konten und Transaktionen überwachen – nicht aber Sekundärmarkttransfers, Aktivitäten auf Wallet-Ebene oder produktspezifische Risiken außerhalb ihres Einflussbereichs. Blockchain-Analytics, Wallet-Screening und stablecoin-spezifisches Transaktionsmonitoring, so die ICBA, gehören zum Emittenten.

Das klingt auf einer Folie ordentlich. In der Produktion ist es das nicht. Ein Stablecoin-Emittent hat typischerweise einen direkten Einblick in Mint- und Burn-Ereignisse. Alles dazwischen findet auf öffentlichen Chains, über Börsen, Custodians und Wallet-Apps statt, mit denen der Emittent keine Vertragsbeziehung hat. Die ICBA verlangt dennoch, dass Emittenten verbotene Aktivitäten identifizieren, blockieren, einfrieren oder ablehnen – und dabei Mixer, Wallet-Verschleierung, Chain-Hopping, sanktionierte Jurisdiktionen sowie Transfers zwischen On-Chain- und Off-Chain-Systemen berücksichtigen. Periodisches Screening von Sanktionslisten, so das Schreiben, reicht nicht aus.

International Bancshares Corp. äußerte eine weitergehende Sorge. Starke AML- und Sanktionsstandards sind notwendig, aber der Vorschlag deckt nur eine Komponente des Stablecoin-Risikos ab. Betrug, Verbraucherschäden, Sanktionsumgehung, Einlagenverdrängung und breitere Instabilität werden nicht gelöst, indem bestehende Compliance-Regeln auf ein neues Produkt aufgepfropft werden.

Kommentatoren wiesen auch darauf hin, dass überschneidende Aufsichtszuständigkeiten von FDIC, FinCEN und OFAC Entscheidungen verlangsamen könnten, während die zugrunde liegenden Netzwerke Wert in Sekunden über Grenzen hinweg bewegen. Aus Produktionsvorfällen, die ich bei Fintechs mit Multi-Regulator-Exposition erlebt habe, weiß ich: In dieser Latenzverzögerung akkumulieren sich tatsächlich Betrugsverluste. Das Regelwerk setzt menschliche Prüfzeit voraus, die das Abrechnungssystem nicht bietet.

Optionen auf dem Tisch

Aus den Kommentarschreiben ergeben sich drei unterschiedliche Compliance-Architekturen, die zu sehr unterschiedlichen Engineering-Roadmaps führen.

Option eins: Emittent als Full-Stack-Überwacher. Das ist die ICBA-Position. Der Emittent übernimmt Blockchain-Analytics, Wallet-Screening, Transaktionsmonitoring, Notfallverfahren für Rücknahmen, Dokumentation von Alert-Schwellenwerten, Bewertung von False Positives und False Negatives sowie die Aufbewahrung von Untersuchungsprotokollen. Reservebanken beschränken sich auf die Überwachung ihres direkten Kunden – der Emittenten-Einheit. Klare Trennlinien, aber es zwingt jeden Emittenten dazu, einen Chain-Analytics-Stack aufzubauen oder einzukaufen, der mit dem mithalten kann, was Chainalysis und TRM an Strafverfolgungsbehörden verkaufen. Kleine Emittenten können diesen Aufwand nicht stemmen. Das entspricht dem Headcount von zwei Entwicklern, bevor überhaupt eine Regel geschrieben wird.

Option zwei: Geteilte Sekundärmarktpflichten. Das ist die Position des Bank Policy Institute und The Clearing House in ihrem gemeinsamen Schreiben. Der vorgeschlagene Rahmen, so ihre Argumentation, lässt eine Lücke, sobald Payment-Stablecoins über den Emittenten hinaus in den Sekundärmarkt übergehen. Börsen, Custodians, digitale Asset-Dienstleister und andere Intermediäre, die Sekundärmarkttransaktionen abwickeln, sollten ebenfalls klareren AML- und Sanktionspflichten unterliegen. Andernfalls bleiben Banken für Risiken verantwortlich, die durch Aktivitäten entstehen, die sie nicht sehen können.

Diese Option ist engineering-ehrlich. Wer die Kundenbeziehung hält, führt das Screening durch. Sie erfordert aber auch, dass die FDIC mit Plattformen koordiniert, die sie nicht direkt beaufsichtigt – was politisch schwieriger ist als Regeln für die eigenen Banken zu schreiben. Die laufenden Zuständigkeitsüberschneidungen der SEC mit Krypto-Intermediären zeigen, wie schnell diese Koordination ins Stocken gerät.

Option drei: Accountability durch Design. Vergraben im ICBA-Schreiben findet sich der schärfste Satz des gesamten Kommentarprotokolls: Wenn ein PPSI ein Produkt entwirft, das Wert über Wallets, Plattformen oder Jurisdiktionen hinweg schneller bewegen kann, als seine Sanktionskontrollen arbeiten können, sollte diese Design-Entscheidung nicht zur Grundlage für reduzierte Verantwortlichkeit werden. In Engineering-Sprache übersetzt: Es ist nicht zulässig, ein ERC-20 zu veröffentlichen, das L2s in unter einer Sekunde wechselt, und dann zu argumentieren, dass das OFAC-Screening als nächtlicher Batch-Job läuft.

Meine Einschätzung: Option drei ist die einzige, die dem Kontakt mit realer Abrechnungslatenz standhält. Optionen eins und zwei streiten darüber, wer aufräumt. Option drei zwingt das Produktdesign, mit der Kontrollgeschwindigkeit Schritt zu halten – das ist die eigentliche Engineering-Einschränkung.

Was Krypto und DeFi tatsächlich tun sollten

Engineering-Teams von Emittenten, die das Kommentarprotokoll lesen, sollten aufhören, Compliance als nachgelagerte Angelegenheit zu behandeln, und sie in das Protokolldesign einbeziehen. Das ICBA-Schreiben verlangt faktisch Echtzeit-Sanktionsdurchsetzung, keine periodischen Listenaktualisierungen. Das bedeutet, dass die Freeze-Funktion, das Blocklist-Oracle, die Mint/Burn-Autorität und der Rücknahme-Identifikations-Workflow erstklassige Komponenten sein müssen – keine Nachgedanken.

Konkret sind drei Maßnahmen jetzt sinnvoll. Erstens: Mint und Burn gegen einen Live-Sanktions-Feed instrumentieren statt gegen einen nächtlichen Job, und jede Entscheidung mit dem auslösenden Alert-Schwellenwert protokollieren. Die ICBA forderte ausdrücklich dokumentierte Schwellenwerte, die Bewertung von False Positives und False Negatives sowie die Aufbewahrung von Untersuchungsprotokollen. Das ist eine Audit-Trail-Anforderung, kein Nice-to-have.

Zweitens: Den Rücknahme-Identifikationspfad aufbauen, bevor er gebraucht wird. Das Schreiben von BPI und Clearing House hob das Szenario hervor, in dem ein Inhaber Stablecoins über eine Börse ohne direkte Emittenten-Beziehung erwirbt und dann zur Barauszahlung erscheint, wenn diese Börse ausfällt oder Auszahlungen aussetzt. Der Emittent muss jemanden identifizieren und screenen, dem er nie gedient hat – potenziell in großem Volumen. Wenn der KYC-Onboarding-Prozess einen optimalen Account-Erstellungsablauf voraussetzt, wird er unter einem Rücknahme-Run zusammenbrechen.

Drittens: Drittanbieter als Erweiterungen des eigenen Compliance-Perimeters behandeln. Die ICBA war deutlich: Das Auslagern von Identitätsprüfungen, Screening oder Monitoring entbindet den Emittenten nicht von der Verantwortung. Welcher Analytics-Anbieter oder KYC-Vendor auch immer im Stack sitzt – seine SLAs, Abdeckungslisten und Eskalationsverfahren fließen nun in die Regulierungsbeziehung ein.

Die unbequeme Erkenntnis: Die meisten Stablecoin-Emittenten, die ich beobachtet habe, behandeln Blocklist-Management als Governance-Ticket, nicht als latenzktitischen Service. Diese Denkweise überlebt den Rahmen nicht, auf den die FDIC zusteuert.

Fallstricke und Grenzfälle

Das Rücknahme-Run-Szenario verdient eine vollständige Failure-Mode-Analyse. Wenn eine Börse Auszahlungen einfriert, treffen Rücknahmeanfragen den Emittenten in einem Spike – von Wallets ohne vorherige Beziehung. Der Anbieter für Identitätsprüfung erreicht sein Rate-Limit. Die Sanctions-Screening-API erreicht ihr Rate-Limit. Die Kundensupport-Warteschlange explodiert. Die ICBA forderte die FDIC auf, Notfallverfahren für Identifikation, Sanctions-Screening, Eskalation verdächtiger Aktivitäten, Personalbesetzung, Liquidität und Kommunikation vorzuschreiben. Diese Liste sollte als Runbook gelesen werden, das heute entworfen werden sollte.

Chain-Hopping ist das zweite Minenfeld. Die ICBA nannte ausdrücklich Mixer, Wallet-Verschleierung, Chain-Hopping und Transfers von On-Chain zu Off-Chain als Dinge, die Emittenten berücksichtigen müssen. Wenn ein Token über mehrere L2s und Bridges deployt wird, muss das Monitoring Adressen über diese Umgebungen hinweg nahezu in Echtzeit abgleichen. Analytics-Anbieter variieren hier erheblich in ihrer Abdeckung. Testen Sie, bevor Sie unterschreiben.

Dritter Fallstrick: Die FDIC muss FinCEN mindestens 30 Tage vor bestimmten Aufsichts- oder Durchsetzungsmaßnahmen benachrichtigen. Dieses Koordinationsfenster klingt verfahrenstechnisch, bedeutet aber, dass der effektiv zuständige Regulator bei einem bestimmten Vorfall möglicherweise erst klar ist, nachdem das Rechtsteam bereits geantwortet hat. Erstellen Sie Incident-Response-Pläne, die eine Beteiligung mehrerer Behörden voraussetzen.

Schließlich lehnte die ICBA Ausnahmen ab, es sei denn, sie bieten gleichwertige Transparenz, Rückverfolgbarkeit und Durchsetzungswert. Jedes Angebot eines Anbieters, der eine leichtgewichtige Compliance-Carve-out-Lösung für Ihr Produkt verspricht, sollte als rechtliches Risiko behandelt werden – nicht als Abkürzung.

Wichtigste Erkenntnisse

• Banken erklärten der FDIC klar: Reservekonto-Anbieter überwachen den Emittenten, der Emittent überwacht die Wallets. Bauen Sie Ihren Stack um diese Aufteilung herum.
• Sanktionskontrollen müssen mit Abrechnungsgeschwindigkeit arbeiten. Periodisches Listen-Screening wird den Standard nicht erfüllen, den die ICBA anstrebt.
• Rücknahmen sind der Stresstest. Wenn ein Inhaber, dem Sie nie gedient haben, bei einem Börsenausfall zur Barauszahlung erscheinen kann, brauchen Sie einen Identifikations- und Screening-Workflow, der unter Spike-Last skaliert.
• Outsourcing an Dritte überträgt keine Verantwortung. Due-Diligence-Prüfungen von Anbietern, Dokumentation von Alert-Schwellenwerten und Aufbewahrung von Untersuchungsprotokollen sind nun emittenteneigene Artefakte.
• Produktdesign-Entscheidungen, die Ihre Compliance-Kontrollen überholen, sind laut ICBA keine Verteidigung. Passen Sie die Protokollfähigkeit an die Kontrolllatenz an – oder reduzieren Sie die Fähigkeit.