Das Whitelable-Modell: Krypto-Dienstleistungen nach MiCAR (ohne eigene Lizenz)
Veröffentlicht am 9th Juli 2026
Ein Haftungsdach nach dem Vorbild des Tied-Agent-Modells gibt es unter der MiCAR nicht. Wer Kryptowerte-Dienstleistungen ohne eigene Zulassung anbieten will, muss auf das Whitelabel-Modell setzen – mit einem zugelassenen CASP als alleinigem Vertragspartner des Kunden und einer klaren Trennung zwischen regulierter Dienstleistung und technischer Unterstützung. Die Grenze zwischen zulässiger Auslagerung und unerlaubter Erbringung von Kryptowerte-Dienstleistungen verläuft dabei entlang einer einzigen Frage: Wer erbringt die Dienstleistung faktisch?
Das Tied-Agent-Modell: Bewährt im deutschen Recht, aber nicht übertragbar
Unternehmen, die Kryptowerte-Dienstleistungen wie den Handel mit Kryptowerten anbieten möchten, benötigen hierfür grundsätzlich eine Zulassung als Anbieter von Kryptowerte-Dienstleistungen (Crypto-Asset Service Provider, „CASP“) nach Art. 59 MiCAR. Mit dem Ablauf der MiCAR-Übergangsfrist am 1. Juli 2026 haben diese Fragen weiter an Dringlichkeit gewonnen. Die Nutzung nationaler Übergangsregelungen (sog. „Grandfathering") ist nunmehr ausgelaufen und nicht mehr möglich.
Ebenso wenig stellt die sog. Reverse Solicitation einen tragfähigen Ausweg dar. Art. 61 Abs. 1 MiCAR nimmt Drittstaaten-CASPs von der Zulassungspflicht aus, sofern eine Dienstleistung ausschließlich auf Initiative des Kunden erbracht wird – ein Konzept, das der passiven Dienstleistungsfreiheit nachgebildet ist. Diese Ausnahme entfällt jedoch nach Art. 61 Abs. 2 MiCAR, sobald der Anbieter in der EU aktiv Kunden wirbt oder akquiriert. Da sie allenfalls Einzelfälle reiner Eigeninitiative des Kunden erfasst und keinen Aufbau dauerhafter Kundenbeziehungen erlaubt, scheidet die Reverse Solicitation als skalierbare Grundlage für den Vertrieb von Kryptowerte-Dienstleistungen gegenüber EU-Kunden aus.
Die ESMA hat in ihrem Public Statement vom 23. Juni 2026 (ESMA75-113276571-1710) unmissverständlich klargestellt, dass nicht zugelassene CASPs ihre Tätigkeit gegenüber EU-Kunden unverzüglich und geordnet einzustellen haben. Konkret verlangt sie: einen sofortigen Stopp des Onboardings neuer Kunden, das Unterlassen jeglicher Marketing- und Akquisetätigkeiten in der EU sowie die Beschränkung auf Maßnahmen zur geordneten Abwicklung – namentlich den Verkauf oder Transfer von Kryptowerten und die Schließung offener Positionen. Darüber hinaus ist es CASPs untersagt, bestimmte Kryptowerte-Dienstleistungen, insbesondere die Verwahrung, an nicht zugelassene Unternehmen auszulagern. Für Unternehmen ohne eigene MiCAR-Zulassung ist die Wahl eines konformen Kooperationsmodells damit nicht mehr optional, sondern zwingend.
Im deutschen Aufsichtsrecht existiert für solche Konstellationen eine bewährte Lösung: das Tied-Agent- bzw. Haftungsdach-Modell. Nicht lizenzierte Unternehmen können als vertraglich gebundene Vermittler (sog. „Tied Agents") eines lizenzierten Instituts tätig werden. Der Tied Agent handelt dabei nicht im eigenen Namen, sondern als Vertreter des haftenden Instituts: Er erbringt regulierte Finanz- oder Wertpapierdienstleistungen ausschließlich im Namen, für Rechnung und unter der Haftung des Instituts. Seine Tätigkeit wird dem Institut aufsichtsrechtlich zugerechnet, sodass er selbst keiner eigenen Erlaubnis bedarf und vollständig in die Aufsichtssphäre des Instituts integriert wird (sog. „Liability Umbrella“). Der Gedanke, dieses Modell auf die MiCAR zu übertragen, liegt nahe – doch die Verordnung sieht ein solches „MiCAR-Haftungsdach" nicht vor.
Warum das Tied-Agent-Modell unter der MiCAR nicht funktioniert
Das Tied-Agent-Modell beruht auf folgendem Grundsatz: Ein Unternehmen mit Sitz im Inland, das bestimmte regulierte Dienstleistungen – namentlich die Anlagevermittlung, die Anlageberatung oder das Platzierungsgeschäft – ausschließlich für Rechnung und unter der Haftung eines lizenzierten Instituts erbringt, bedarf keiner eigenen Erlaubnis. Die Tätigkeit des vertraglich gebundenen Vermittlers wird dem haftenden Institut zugerechnet (§ 2 Abs. 10 S. 2 KWG bzw. § 3 Abs. 2 S. 2 WpIG).
Diesen Mechanismus kennt die MiCAR nicht. Art. 59 ff. MiCAR verfolgen einen funktionalen Ansatz: Wer Kryptowerte-Dienstleistungen im Sinne des Art. 3 Abs. 1 Nr. 16 lit. a–j MiCAR erbringen will, bedarf einer eigenen Zulassung als CASP. Eine Zurechnungsnorm, die es einem zugelassenen CASP erlauben würde, die Tätigkeit eines nicht zugelassenen Dritten als eigene gelten zu lassen, existiert nicht. Plattformbetreiber im rechtlichen Sinne ist daher stets der CASP selbst – er betreibt die Plattform, über die Kryptowerte-Dienstleistungen erbracht werden, und trägt die aufsichtsrechtliche Verantwortung. Ein Modell, bei dem ein Kooperationspartner eigene MiCAR-Dienstleistungen erbringt, dies aber vertraglich als Handeln „für den" CASP ausgestaltet, wäre kein zulässiges Geschäftsmodell – es würde den Kooperationspartner selbst als erlaubnispflichtigen CASP qualifizieren. Ermöglicht etwa ein Kooperationspartner seinen Nutzern, über seine Plattform Kryptowerte von CASPs zu erwerben, so stellt dies eine erlaubnispflichtige Annahme und Übermittlung von Aufträgen im Sinne des Art. 3 Abs. 1 Nr. 16 lit. d MiCAR dar.
Art. 73 MiCAR: Der gesetzliche Rahmen für Kooperationen
Auch wenn die MiCAR ein solches Haftungsdach nicht kennt, eröffnet sie dennoch einen Rahmen für Kooperationen: Nach Art. 73 MiCAR können CASPs bestimmte betriebliche Aufgaben und Tätigkeiten unter den dort normierten Voraussetzungen an Dritte auslagern.
Ausgelagert werden können betriebliche Funktionen – nicht jedoch die aufsichtsrechtliche Verantwortung. Der CASP bleibt in vollem Umfang für die Erfüllung seiner regulatorischen Pflichten verantwortlich. Kooperationspartner unterstützen ihn typischerweise durch technische Leistungen wie IT-Infrastruktur, Frontend-Entwicklung oder Schnittstellenanbindung. Voraussetzung ist stets ein schriftlicher Auslagerungsvertrag nach Art. 73 Abs. 3 MiCAR.
Die Auslagerungsregelungen ermöglichen so ein arbeitsteiliges Kooperationsmodell, bei dem der Partner neben der technischen Infrastruktur auch die Marke (Brand) und ggf. Unterstützung beim Kundensupport (Entgegennahme von Kundenanfragen zur Weiterleitung an den CASP) beisteuert, während sämtliche regulierten Tätigkeiten und die aufsichtsrechtliche Verantwortung beim CASP verbleiben. Auf dieser Grundlage baut das sogenannte Whitelabel-Modell auf.
Das Whitelabel-Modell in der Praxis
Im Whitelabel-Modell ist der CASP Plattformbetreiber im rechtlichen Sinne: Er erbringt die Kryptowerte-Dienstleistungen im eigenen Namen und auf eigene Rechnung und trägt die aufsichtsrechtliche Verantwortung. Der Kooperationspartner fungiert demgegenüber allenfalls als technischer Dienstleister – er stellt ggf. die technische Infrastruktur einschließlich des Frontends bereit, das unter seiner eigenen Marke erscheint, und erbringt Wartungs- sowie IT-Sicherheitsleistungen, ohne selbst regulierte Tätigkeiten auszuüben oder die Plattform im rechtlichen Sinne zu betreiben.
Juristisch lassen sich drei Ebenen unterscheiden:
B2C-Ebene (CASP – Kunde)
Alleiniger Vertragspartner des Kunden ist der CASP. Er erbringt die Kryptowerte-Dienstleistungen im eigenen Namen und auf eigene Rechnung – etwa Verwahrung und Verwaltung von Kryptowerten, Ausführung von Aufträgen oder deren Annahme und Übermittlung. Die Vertragsbedingungen werden vom CASP gestellt und weisen ihn ausdrücklich als Vertragspartner aus. Der Kooperationspartner tritt gegenüber dem Kunden nicht als Vertragspartei in Erscheinung.
B2B-Ebene (CASP – Kooperationspartner)
Zwischen CASP und Kooperationspartner besteht ein Kooperations- und Auslagerungsvertrag – das sogenannte Outsourcing Agreement nach Art. 73 Abs. 3 MiCAR. Gegenstand sind typischerweise die Bereitstellung und der Betrieb der technischen Infrastruktur, Wartungs- und Aktualisierungsleistungen, IT-Sicherheitsmaßnahmen sowie die Unterstützung beim Kundensupport (insbesondere die Entgegennahme und Weiterleitung von Kundenanfragen an den CASP). Der Vertrag muss ausdrücklich klarstellen, dass der Kooperationspartner keine Kryptowerte-Dienstleistungen im eigenen Namen erbringt und nicht Vertragspartner des Kunden wird.
Dienstleistungen in der Sphäre des CASP
Entscheidend für die aufsichtsrechtliche Einordnung – und damit für die Frage, ob der Kooperationspartner selbst einer Zulassung als CASP bedarf – ist, wer die Dienstleistung faktisch erbringt. Ordererfassung, -verarbeitung und -ausführung müssen ausschließlich durch den CASP erfolgen. Ebenso muss der CASP im rechtlichen Sinne als Plattformbetreiber auftreten – insbesondere im Impressum, in den rechtlichen Pflichtangaben und in der Anbieterkennzeichnung – und die Nutzungsbedingungen unmittelbar mit dem Kunden vereinbaren. Das Frontend des Kooperationspartners bildet lediglich die technische Oberfläche für die Interaktion zwischen Kunde und CASP.
Kritisch wird es, wenn der Kooperationspartner Aufträge eigenständig entgegennimmt, zwischenspeichert oder eine eigene Logik zur Orderannahme und -weiterleitung betreibt. In diesem Fall erbringt er faktisch selbst Kryptowerte-Dienstleistungen und bedürfte einer eigenen Zulassung als CASP.
Die vom Kooperationspartner erbrachten Leistungen sind als Auslagerung im Sinne des Art. 73 MiCAR zu qualifizieren. Daraus folgen konkrete Anforderungen: sorgfältige Auswahl, laufende Steuerung und Überwachung des Kooperationspartners, vertragliche Kontroll-, Informations- und Kündigungsrechte sowie die Sicherstellung, dass die Auslagerung die wirksame Beaufsichtigung des CASPs nicht beeinträchtigt.
Risiken: „Verdecktes“ Haftungsdach vermeiden
Das zentrale Risiko besteht darin, dass das Modell faktisch als verdecktes Tied-Agent-Modell genutzt wird. Der Kooperationspartner tritt nach außen als Anbieter auf – „unser Krypto-Service" –, nimmt Aufträge entgegen, steuert Orderflüsse oder verfügt über Zugriff auf Kundenguthaben, während der CASP nur in den Vertragsbedingungen erscheint. Nach dem funktionalen Ansatz der MiCAR ist entscheidend, wer die Kryptowerte-Dienstleistung faktisch erbringt – unabhängig von der vertraglichen Etikettierung. Die Bafin kann den Kooperationspartner in einem solchen Fall als unerlaubten CASP einstufen. Die Folge: eine eigene Zulassungspflicht nach Art. 59 Abs. 1 MiCAR. Je mehr operative Kontrolle über kryptobezogene Prozesse beim Kooperationspartner liegt, desto schwieriger lässt sich das Modell als bloße Auslagerung einordnen.
Diese Einschätzung wird durch das eingangs dargestellte ESMA Public Statement vom 23. Juni 2026 gestützt, das insbesondere das Verbot hervorhebt, bestimmte Kryptowerte-Dienstleistungen – namentlich die Verwahrung – an nicht zugelassene Unternehmen auszulagern. Wer ein Whitelabel-Modell so ausgestaltet, dass der nicht zugelassene Kooperationspartner faktisch Verwahrungsleistungen oder andere regulierte Kryptowerte-Dienstleistungen erbringt, verstößt gegen Art. 73 MiCAR.
Zur Risikominimierung bedarf es einer Auslagerungsstrategie, die gemäß Art. 73 Abs. 7 MiCAR Notfallpläne und Ausstiegsstrategien umfasst. Zudem sind nicht nur der CASP, sondern auch der Kooperationspartner gemäß Art. 73 Abs. 4 MiCAR verpflichtet, der Bafin auf Anfrage alle zur Beurteilung der MiCAR-Konformität erforderlichen Informationen bereitzustellen.
Um die Erkennbarkeit des CASPs als Vertragspartner gegenüber Kunden sicherzustellen, sollten insbesondere folgende Punkte beachtet werden:
- klarer Hinweis im Frontend, in den AGB und in den Datenschutzhinweisen auf den CASP als Vertragspartner
- deutliche Kennzeichnung, z. B. „Krypto-Dienstleistungen powered by [CASP]"
- konsistente Rollenbeschreibung in sämtlichen Kundenunterlagen: CASP als Plattformbetreiber, Kryptowerte-Dienstleister und alleiniger Vertragspartner, Kooperationspartner als technischer Dienstleister
Fazit
Ein Haftungsdach nach dem Vorbild des Tied-Agent-Modells gibt es unter der MiCAR nicht. Das Whitelabel-Modell bietet jedoch eine tragfähige Alternative – sofern drei Voraussetzungen konsequent eingehalten werden:
- Der CASP tritt als alleiniger Anbieter der Kryptowerte-Dienstleistungen und als Plattformbetreiber im rechtlichen Sinne auf – einschließlich Impressum, Anbieterkennzeichnung und Abschluss der Nutzungsbedingungen mit dem Kunden.
- Der Kooperationspartner beschränkt sich auf nicht regulierte Unterstützungsleistungen – insbesondere technische Infrastruktur, Frontend-Bereitstellung, Bereitstellung der Marke und Kundensupport-Weiterleitung.
- Die Rollenverteilung wird in Verträgen, Außenkommunikation und sämtlichen Kundenunterlagen konsistent abgebildet.
Für Unternehmen, die Kryptowerte-Dienstleistungen gegenüber Kunden anbieten möchten, bedeutet dies: Entweder sie erlangen eine eigene MiCAR-Zulassung oder sie gestalten ihre Zusammenarbeit mit einem zugelassenen CASP als rechtssicheres Whitelabel-Modell mit klarer Verantwortungsverteilung aus.
Wer stattdessen ein „verdecktes Haftungsdach" konstruiert – bei dem der Kooperationspartner faktisch regulierte Kryptowerte-Dienstleistungen erbringt, ohne selbst zugelassen zu sein –, riskiert die Einstufung als unerlaubter CASP durch die Bafin mit den entsprechenden aufsichtsrechtlichen Konsequenzen.
Vielen Dank an Jule Honf für die Mitwirkung bei der Erstellung dieses Insights.