Wenn bei Krypto-Betrug das Konto „durchläuft“, ist nicht nur die Tat entscheidend, sondern das Risikosystem, das sie hätte erkennen können.

Einleitung

Krypto-Betrug ist selten „nur“ ein einzelner Trickmoment. In vielen Fällen ist er ein Prozess: Zugriff, Vorbereitung, schrittweise Autorisierung, Verdichtung – und am Ende ein Abfluss, der in der Plattformlogik als „normal“ verarbeitet wird. Genau an diesem Punkt rückt eine Ebene in den Fokus, über die in der öffentlichen Diskussion häufig zu grob gesprochen wird: interne Risikosysteme. Gemeint sind Policy Scores, Fraud Scores, Velocity-Regeln, Device-Checks, Geolokations- und IP-Anomalien, Risiko-Klassifizierungen von Auszahlungsadressen oder schlicht die Entscheidung, ob eine Transaktion frictionlos freigegeben oder mit Schutzmechanik gebremst wird.

Für Betroffene wirkt das nach dem Schadenseintritt oft paradox: Man erlebt offensichtlich atypische Vorgänge – neue Geräte, ungewöhnliche Beträge, Serien in kurzer Zeit, neue Adressaten – und trotzdem passiert nichts, keine Verzögerung, keine „zweite Stufe“, kein Sicherheitsdialog, kein Withdrawal-Lock. Der Reflex „Dann war die Plattform doch schuld“ ist ebenso unpräzise wie das Gegenextrem „Autorisiert ist autorisiert“. Juristisch tragfähig wird die Analyse erst, wenn man die Risikosysteme als das versteht, was sie sind: eine organisatorisch-technische Sicherheitsarchitektur, die Entscheidungen strukturiert – und damit auch die Frage aufwirft, ob Schutzpflichten verletzt wurden, ob Kommunikation irreführend war, ob ein Datenleck als Risikoquelle unterschätzt wurde oder ob eine Plattform in relevanten Situationen bewusst „friktionsarm“ optimiert hat.

Dieser Beitrag ordnet die Policy-Score-Ebene nüchtern ein: nicht als Zauberformel, aber als zentrale Schnittstelle zwischen IT-Security, Compliance, Produktdesign und zivilrechtlicher Verantwortlichkeit. Er ist bewusst wissenschaftlich angelegt, aber prozesspraktisch geschrieben: Ziel ist, dass Leserinnen und Leser am Ende nicht „mehr Meinung“, sondern eine belastbare Prüfarchitektur haben.

Über den Autor

Max Nikolas Mischa Hortmann ist Rechtsanwalt mit Schwerpunkt Krypto-Betrug, Plattformverantwortung und digitale Forensik. Er ist Autor für juris, jurisPR-ITR und AZO (AnwZert ITR). Seine anwaltliche Arbeit und Einschätzungen zu Krypto-Scams, Bankhaftung und modernen Betrugsmodellen wurden unter anderem von BR24, WirtschaftsWoche+ und Business Insider Deutschland aufgegriffen.

‍

1. Ausgangspunkt: Warum „Policy Score“ keine Blackbox-Ausrede sein darf

In Krypto-Betrugsfällen wird der Schadenseintritt technisch häufig als „normaler“ Prozess verarbeitet: Login, Order, Konvertierung, Auszahlung. Aus Sicht der Plattform sind es Events; aus Sicht der Betroffenen ist es eine Eskalation. Diese Differenz ist keine bloße Wahrnehmung, sondern ein juristisch relevanter Schnittpunkt. Denn moderne Plattformen steuern Transaktionen nicht ausschließlich über starre Regeln („Passwort richtig = Auszahlung raus“), sondern über Risikologik: Scores, Heuristiken, Machine-Learning-Klassifikatoren, Rate Limits, Risk Engines.

Ein Policy Score ist dabei nicht zwingend ein einzelner Zahlenwert. Er kann ein Bündel aus Signalen sein: Device-Fingerprint neu oder bekannt, IP-Reputation, Geolocation-Drift, Session-Anomalien, SIM-Swap-Indizien, Zahlungsquellen- und Auszahlungsziele, Historie der Nutzerinteraktionen, Chat-/Support-Kontakte, Velocity (Taktung), Betragshöhen im Vergleich zum individuellen Profil, KYC-Kohärenz, On-Chain-Risikoindikatoren (z. B. Nähe zu Mixer-Clustern, Sanktionslisten, Scam-Labels), aber auch interne „Trust Levels“.

Die zentrale Frage lautet nicht: „Hätte die Plattform den Betrug verhindern müssen?“ Diese Frage ist zu grob. Die juristisch belastbare Frage lautet: Welche Schutz- und Organisationspflichten bestehen bei der Bereitstellung einer sicherheitsrelevanten Finanz-/Krypto-Infrastruktur, wie konkretisieren sich diese Pflichten im jeweiligen Systemdesign – und was bedeutet es, wenn die Plattform trotz objektiv atypischer Konstellation keinerlei Schutzfriktion auslöst?

🔗 Vertiefende Analyse auf anwalt.de

Anwalt: Krypto-Betrug & Datenleck – DSGVO-Auskunft, Logfiles und Forensik gegen Crypto-Plattformen

Wenn nach einem Krypto-Betrug unklar ist, wer wann wie Zugriff hatte, sind Logfiles und DSGVO-Auskunft oft der entscheidende Schritt zur Rekonstruktion.

Der vollständige Fachbeitrag erläutert,

• welche Daten Sie konkret anfordern sollten,
• wie IP-Logs und Event-Records forensisch einzuordnen sind,
• und warum Informationsasymmetrien prozessual eine Rolle spielen.

👉 https://www.anwalt.de/rechtstipps/anwalt-krypto-betrug-und-datenleck-dsgvo-auskunft-logfiles-und-forensik-gegen-crypto-plattformen-slug-264485.html

2. Begriffe und Abgrenzungen: Fraud, AML, Risk – nicht alles ist dasselbe

Wissenschaftlich sauber ist zunächst zu trennen, welche Risikosysteme überhaupt gemeint sind. In der Praxis werden drei Ebenen oft vermischt.

Erstens gibt es Compliance-getriebene Systeme, insbesondere AML/CTF (Geldwäsche, Terrorismusfinanzierung). Diese Systeme zielen vorrangig auf regulatorische Pflichten, Verdachtsmeldungen, KYC/EDD-Prozesse, Travel-Rule-Mechanismen und Sanktionsscreenings. Sie sind nicht identisch mit Betrugsprävention.

Zweitens gibt es Fraud-Prevention-Systeme, die auf Kontoübernahmen, Social Engineering, Device-Anomalien und Transaktionsmuster reagieren. Diese Systeme sind in Betrugsfällen meist der eigentliche Drehpunkt.

Drittens gibt es Produkt- und Experience-Systeme, die Friktion minimieren: möglichst wenige Abbrüche, schnelle Auszahlungen, „Instant“-Features. Gerade hier entsteht in der Praxis das Spannungsfeld, das später juristisch relevant wird: Wenn eine Plattform ein Sicherheitsversprechen kommuniziert, aber in kritischen Situationen friktionsarm optimiert, kann das zu einer Diskrepanz zwischen Erwartung und tatsächlichem Schutz führen.

Ein Datenleck wirkt in allen drei Ebenen, aber unterschiedlich. Im AML-Kontext ist ein Leak eher mittelbar; im Fraud-Kontext ist es häufig unmittelbare Angriffsvoraussetzung; im Experience-Kontext erhöht ein Leak die Risiko-Last, die eigentlich zu mehr Friktion führen müsste.

3. Warum Datenleck und Betrug häufig zusammengehören

Das klassische Bild „Datenleck = Datenschutz, Betrug = Strafrecht“ ist in modernen Scam-Lagen zu kurz. Datenlecks sind oft der Zünder für Account Takeover und Social Engineering. Wer Name, E-Mail, Telefonnummer, Adressdaten, KYC-Fragmente oder Transaktionsbezüge kennt, kann Sicherheitsnarrative glaubwürdig bauen.

Juristisch ist das doppelt relevant. Einerseits ist die Datenverarbeitungsebene über Datenschutzrecht (Sicherheitsmaßnahmen, Art. 32 DSGVO; ggf. Informationspflichten bei Verletzungen, Art. 33/34 DSGVO) strukturiert. Andererseits wirkt ein Leak als Risikofaktor, der im Sicherheitsdesign berücksichtigt werden muss. Eine Plattform, die weiß oder wissen muss, dass bestimmte Datensätze kompromittiert sind oder dass im Markt gerade massenhaft ATO-Kampagnen laufen, kann sich schwerer darauf zurückziehen, ein konkreter Vorfall sei „unvorhersehbar“ gewesen.

4. Zivilrechtlicher Kern: Schutzpflichten und Organisationspflichten als Maßstab

Die zivilrechtliche Haftungsanalyse in Plattformfällen läuft in der Praxis häufig über vertragliche oder vertragsähnliche Pflichtenkreise. Ohne in eine dogmatische Vollvermessung zu gehen, kann man das so strukturieren: Wer einem Nutzer eine Plattform zur Verfügung stellt, auf der Vermögenswerte verwahrt, gehandelt oder transferiert werden, übernimmt typischerweise Pflichten, die über bloße „Bereitstellung von Software“ hinausgehen. Diese Pflichten ergeben sich nicht aus einem abstrakten „Sicherheitsversprechen“, sondern aus dem Zweck des Vertragsverhältnisses und dem Schutzinteresse des Nutzers.

Wissenschaftlich gesprochen geht es um die Frage, welche Sicherheits- und Sorgfaltsanforderungen als vertragliche Schutzpflichten (insbesondere im Bereich der Integrität der Kontonutzung) konkretisiert werden müssen. Das ist kein Garantiedenken. Es ist ein Maßstabdenken: Was ist bei angemessener Organisation, im Stand der Technik, unter Berücksichtigung der typischen Gefahrenlage, vernünftigerweise zu implementieren und in kritischen Situationen auch zu aktivieren?

In Betrugsfällen stellt sich diese Frage besonders scharf, weil das „Ereignis“ nicht ein technischer Zufall ist, sondern eine gezielte Manipulation. Gerade dann ist es aber in Plattformarchitekturen üblich, auf Muster zu reagieren: Verdichtung, Atypik, Anomalie. Wenn eine Plattform in solchen Lagen keinerlei Schutzfriktion aktiviert, entsteht eine prüfungsbedürftige Diskrepanz.

‍

5. Die technische Wahrheit: Wie Risk Engines real entscheiden

Wer Policy Scores juristisch verwerten will, muss die Systemlogik wenigstens in Grundzügen verstehen, ohne sich in Technik zu verlieren. In der Praxis sind Risk Engines häufig mehrstufig.

Eine erste Stufe ist die Identitäts- und Session-Integrität: Ist das Gerät bekannt? Ist der Browser-Fingerprint kohärent? Ist die Session frisch? Gab es ungewöhnliche Token-Refreshes? Stimmen IP-Geolocation und historische Nutzung zusammen?

Eine zweite Stufe ist Verhaltens- und Mustererkennung: Wird plötzlich in kurzer Zeit eine Serie ausgelöst? Werden neue Auszahlungadressen angelegt? Wird 2FA deaktiviert oder umgestellt? Werden API Keys erstellt? Erfolgt kurz nach einem Passwort-Reset ein Abfluss?

Eine dritte Stufe ist Transaktionsrisiko: Beträge, Asset-Wechsel, On-Chain-Zieladressen, interne Transfermechaniken.

Entscheidend: Solche Systeme erzeugen nicht nur „Entscheidungen“, sondern auch Artefakte: Flags, Event-Logs, Entscheidungen („allow“, „challenge“, „deny“), manuelle Overrides, Risk-Notes, interne Tickets. Das ist prozessual Gold – wenn man es sauber adressiert.

6. Juristische Schwelle: Wann wird ein Scoring-Fehler haftungsrelevant?

Ein Policy Score ist nicht haftungsrelevant, weil er „existiert“, sondern weil er als Teil der Sicherheitsorganisation die Frage aufwirft, ob Schutzmechanik angemessen implementiert und eingesetzt wurde. Haftungsrelevant wird das typischerweise in drei Konstellationen.

Erstens, wenn die Plattform Sicherheitsfriktion als Produktbestandteil kommuniziert (z. B. „ungewöhnliche Aktivitäten werden erkannt“, „wir schützen vor unbefugtem Zugriff“, „zusätzliche Sicherheitsstufen“) und das System in einer offensichtlich atypischen Lage trotzdem frictionlos durchläuft. Dann geht es nicht um einen „Erfolg“ des Betrügers, sondern um die Frage, ob die Plattform ihren eigenen Sicherheitsrahmen praktisch entleert.

Zweitens, wenn Datenlecks oder bekannte Betrugslagen objektiv erhöhte Risiken schaffen und die Plattform keine angemessene Risikoadaption vornimmt. In solchen Lagen ist es wissenschaftlich plausibel, dass der „Stand der Organisation“ nicht statisch ist. Sicherheit ist dynamisch: Gefahr erkannt, Maßnahmen angepasst.

Drittens, wenn die Plattform sich im Prozess pauschal auf „Authorization“ oder „User fault“ zurückzieht, obwohl sie die relevanten Sicherheitsdaten kontrolliert. Dann wird die Darlegungsebene zentral: Wer behauptet, alles sei normal gewesen, muss erklären können, warum es normal war – zumindest im Rahmen dessen, was im Zivilprozess zumutbar ist.

7. Prozesspraxis: Warum Policy Scores selten direkt, aber oft indirekt gewinnen

In der Praxis wird man selten erreichen, dass eine Plattform ihren „Fraud Score“ als Zahl offenlegt. Zum einen wegen Geschäftsgeheimnissen, zum anderen weil Systeme nicht auf eine Zahl reduzierbar sind. Was man aber regelmäßig verwertbar bekommt, sind die strukturellen Tatsachen, die den Score speisen oder die Entscheidung dokumentieren: Login-Historie, IP- und Device-Wechsel, Zeitpunkte von Änderungen, Auszahlungsadressanlage, ggf. „risk events“, manuelle Bearbeitung, Supportkontakte, Security-Notifications, angewandte Locks oder deren Nichtanwendung.

Damit verschiebt sich die Strategie: Nicht „Gib mir deinen Score“, sondern „Lege die Ereignisse offen, aus denen sich die Risikokonstellation ergibt“. Aus dieser Ereigniskette kann man plausibel machen, dass eine Schutzpflichtprüfung überhaupt eröffnet ist.

8. Typische Verteidigungslinien – und wie man sie wissenschaftlich sauber einordnet

Plattformen verteidigen sich in Betrugsfällen häufig entlang wiederkehrender Narrative.

Ein Standardnarrativ lautet: „Die Transaktionen waren autorisiert.“ Das ist als Tatsache relevant, aber kein Endpunkt. Autorisierung beantwortet nicht automatisch die Frage, ob die Autorisierung in einem System erfolgte, das bei atypischen Risikolagen angemessene Schutzmechanismen aktiviert, ob Sicherheitskommunikation irreführend war oder ob Kontoübernahmen zu leicht möglich waren.

Ein zweites Narrativ lautet: „Betrug ist nicht vollständig verhinderbar.“ Das stimmt. Aber es ist wissenschaftlich banal. Juristisch geht es nicht um Vollverhinderung, sondern um angemessene Organisation und zumutbare Schutzmechanismen.

Ein drittes Narrativ lautet: „Unsere Systeme sind geheim.“ Auch das ist nachvollziehbar. Es entbindet aber nicht von der Notwendigkeit, im Prozess die entscheidungserheblichen Tatsachen offenzulegen, soweit dies zur Rechtsverteidigung erforderlich ist und ohne dass Geschäftsgeheimnisse inhaltlich preisgegeben werden müssen.

Ein viertes Narrativ lautet: „Der Nutzer hat Sicherheitsvorgaben verletzt.“ Das kann im Einzelfall relevant sein, aber es darf nicht als Pauschalformel jede Atypik neutralisieren. Wissenschaftlich sauber ist hier die Frage: Welche konkrete Pflichtverletzung, wie kausal, wie gravierend, und wie verhält sich das zu der Risikolage, die die Plattform gleichzeitig sehen konnte?

9. Praktische Methodik für Betroffene und Berater: Wie man den „Score“ in Tatsachen übersetzt

Wenn du Policy-Score-Fälle seriös bearbeiten willst, brauchst du eine Chronologie, die nicht nur Vermögensabfluss dokumentiert, sondern die sicherheitsrelevanten Vorstufen. Wissenschaftlich brauchbar ist ein Dreischritt:

Erstens die Ereignisachse: Wann Login, wann Device-/IP-Wechsel, wann Passwort/2FA-Änderung, wann neue Auszahlungadresse, wann Auszahlungen, wann Supportkontakt.

Zweitens die Atypikachse: Was weicht vom bisherigen Profil ab? Beträge, Frequenz, Assetwechsel, Adressaten, Uhrzeiten, geografische Muster.

Drittens die Schutzachsen: Welche Schutzmechanismen waren vorhanden, welche waren aktiviert, welche hätten typischerweise bei solchen Signalen greifen können, und was ist tatsächlich passiert?

Aus dieser Struktur entsteht keine „Schuldthese“, sondern eine prüffähige Tatsachenbasis.

‍

‍

10. Ergebnis: Policy Scores sind keine Beweise, aber sie markieren die Verantwortungsebene

Der wissenschaftliche Kern dieses Mutterschiffs ist schlicht: In Krypto-Betrugslagen sind Risk Engines die Stelle, an der sich Plattformorganisation materialisiert. Der juristische Vorwurf ist selten „falscher Algorithmus“, sondern „unzureichende Sicherheitsorganisation“, „nicht aktivierte Schutzmechanik“, „irreführende Sicherheitskommunikation“ oder „nicht nachvollziehbare Freigabe atypischer Risikolagen“.

Wer seriös arbeiten will, muss deshalb weg von Pauschalen. Policy Score ist kein Haftungsautomatismus. Aber Policy Score ist auch kein Nebel, hinter dem man sich verstecken kann. Entscheidend ist, ob die Plattform ihre eigenen Sicherheits- und Risikoprozesse so organisiert, dass atypische und hochriskante Lagen nicht wie Normalbetrieb behandelt werden.

Sie müssen diese Struktur nicht allein klären.
Wenn Sie von Krypto-Betrug oder einem möglichen Datenleck betroffen sind, prüfen wir Ihren Fall technisch, juristisch und strategisch – strukturiert und ohne Schnellschüsse.

📞 0160 9955 5525
🌐 hortmannlaw.com/contact

Eine frühzeitige, geordnete Analyse verhindert Fehlentscheidungen – und sichert Beweise.

FAQ

1. Was bedeutet „Policy Score 100“ bei einer Kryptoplattform?
Ein Policy- oder Risk-Score ist eine interne Risikobewertung. Ein hoher Score bedeutet nicht automatisch, dass kein Risiko vorlag – sondern nur, dass das System die konkrete Transaktion als unauffällig eingestuft hat. Juristisch relevant wird das, wenn objektive Auffälligkeiten trotzdem nicht zu einer Schutzreaktion führten.

2. Muss eine Plattform jeden ungewöhnlichen Vorgang stoppen?
Nein. Es besteht keine generelle Rettungspflicht. Entscheidend ist, ob sich atypische Signale so verdichtet haben, dass eine Intervention technisch vorgesehen und zumutbar gewesen wäre.

3. Ist eine autorisierte Transaktion automatisch haftungsfrei?
Nicht zwingend. Autorisierung beendet nicht jede Prüfung. Wenn sie in einem atypischen, manipulierten Kontext erfolgte, kann die Risikologik der Plattform haftungsrelevant werden.

4. Kann ich interne Risikodaten einsehen?
Direkte Score-Werte selten. Aber Login-Daten, Event-Logs, Gerätewechsel und sicherheitsrelevante Änderungen sind regelmäßig über DSGVO-Auskunft zugänglich.

Mini-FAQ

• Zählt Social Engineering als „eigene Schuld“? → Nicht automatisch.
• Sind Risk-Engines rechtlich relevant? → Ja, als Teil der Organisationspflicht.

‍

Weiterführende Analysen – Serie „Anwalt | Krypto | Betrug | Datenleck“

Diese Artikel sind Teil einer strukturierten Analyse-Reihe zu Krypto-Betrug, Plattformverantwortung und Datenleck-Konstellationen:

1. Policy Score & Risikosysteme
www.hortmannlaw.com/articles/anwalt-krypto-betrug-datenleck-policy-score-haftung

2. Withdrawal Lock & Whitelisting
www.hortmannlaw.com/articles/anwalt-krypto-betrug-datenleck-withdrawal-lock-whitelisting

3. Custody-Realität & Plattformverantwortung
www.hortmannlaw.com/articles/anwalt-krypto-betrug-datenleck-custody-realitaet

4. IP-Logs, DSGVO-Auskunft & Beweislast
www.hortmannlaw.com/articles/anwalt-krypto-betrug-datenleck-ip-logs-beweislast

5. Verdichtungszeitpunkt & Warnpflichten
www.hortmannlaw.com/articles/anwalt-krypto-betrug-datenleck-verdichtungszeitpunkt-warnpflicht

6. Klage in Deutschland trotz Schiedsklausel
www.hortmannlaw.com/articles/anwalt-krypto-betrug-datenleck-klage-deutschland-schiedsklausel-og-titel

Weiterführende Fachbeiträge und vertiefende Analysen

Die nachfolgenden Beiträge vertiefen einzelne rechtliche Parameter, die in diesem Leitfaden bewusst nur systematisch eingeordnet wurden. Sie dienen der inhaltlichen Vertiefung, der Beweisarchitektur sowie der Einordnung spezieller Konstellationen. Alle Verlinkungen führen zu bereits veröffentlichten Fachartikeln.

1. Transaktionsmuster und Zahlungsstrukturen

Diese Beiträge analysieren objektive Auffälligkeiten im Zahlungsverkehr, die als erste haftungsrelevante Prüfungsstufe dienen können:

• Transaktionsmuster bei Krypto-Betrug – Haftung der Bank und Geld-zurück-Ansätze
  https://www.hortmannlaw.com/articles/krypto-betrug-transaktionsmuster-haftung-bank-geld-zurueck-teil-1
• Haftung der Empfängerbank bei Krypto-, Love-Scam- und Anlagebetrug
  https://www.hortmannlaw.com/articles/krypto-betrug-love-scam-anlagebetrug-empfaengerbank-haftung-anwalt
• Überweisung, Rückforderung und Geldwäscheanhörung nach Krypto-Betrug
  https://www.hortmannlaw.com/articles/krypto-betrug-anwalt-ueberweisung-rueckforderung-geldwaesche-anhoerung-polizeianzeige

2. Verhaltensmuster, Manipulation und fehlende Autonomie

Diese Beiträge befassen sich mit Konstellationen, in denen das Verhalten von Betroffenen für Banken erkennbar nicht mehr autonom war:

• Verhaltensmuster bei Krypto-Betrug – Haftung der Bank bei erkennbarer Manipulation
  https://www.hortmannlaw.com/articles/krypto-betrug-verhaltensmuster-haftung-bank-geld-zurueck-teil-2
• Love-Scam und Plattformhaftung – wenn Warnsignale ignoriert werden
  https://www.hortmannlaw.com/articles/love-scam-plattformhaftung-opfer-anwalt
• Beweissicherung bei Love-Scam – Krypto-Analyse und forensische Dokumentation
  https://www.hortmannlaw.com/articles/beweissicherung-love-scam-krypto-detektei-kanzlei

3. Risikomuster, AML-Signale und Organisationsversagen

Diese Beiträge vertiefen die dritte und regelmäßig entscheidende Haftungsstufe: interne Risikomuster und bankseitige Organisation:

• Risikomuster bei Krypto-Betrug – interne Bankwarnsignale und Organisationsverschulden
  https://www.hortmannlaw.com/articles/krypto-betrug-risikomuster-haftung-bank-geld-zurueck-teil-3
• Geldwäschevorwürfe gegen Opfer von Krypto-Betrug – rechtliche Einordnung
  https://www.hortmannlaw.com/articles/krypto-betrug-geldwaeschevorwuerfe
• Verstoß gegen Geldwäschevorschriften im Krypto-Betrug
  https://www.hortmannlaw.com/articles/krypto-betrug-einordnen-verstoss-gegen-geldwasche-vorschriften

4. Plattformen, Wallets und technische Beweisfragen

Diese Beiträge sind relevant für die Beweisführung, insbesondere bei Krypto-Transfers und Plattformbezug:

• Wallet-Beweise bei Krypto-Betrug – Blockchain-Analyse und Anspruchsdurchsetzung
  https://www.hortmannlaw.com/articles/krypto-betrug-wallet-beweise-opfer-anwalt
• Krypto-Betrug analysieren – Layering, Chain-Hopping und Geldverschleierung
  https://www.hortmannlaw.com/articles/krypto-betrug-analysieren-anwalt-erklart-layering
• On-Chain-Ermittlungen bei Krypto-Betrug
  https://www.hortmannlaw.com/articles/on-chain-ermittlungen-krypto-betrug-anwalt

5. Plattformverantwortung und Sonderkonstellationen

Diese Beiträge behandeln Konstellationen jenseits der klassischen Bankhaftung:

• Crypto.com – Haftung bei Betrugsopfern und AGB-Grenzen
  https://www.hortmannlaw.com/articles/crypto-com-agb-haftung-betrugsopfer-wallet-uebernahme
• Klage gegen Crypto.com wegen Plattformversagen
  https://www.hortmannlaw.com/articles/klage-gegen-crypto-com-plattform-betrug
• Plattformverantwortung bei DeFi-Betrug
  https://www.hortmannlaw.com/articles/plattform-verantwortung-defi-krypto-betrug-anwalt

6. Verfahrensrecht, Durchsetzung und flankierende Maßnahmen

Diese Beiträge betreffen die prozessuale und strategische Umsetzung:

• Adhäsionsverfahren und Schadensersatz im Krypto-Betrugsfall
  https://www.hortmannlaw.com/articles/adhasionsverfahren-und-schadensersatz-im-krypto-betrugsfall
• Klage gegen die Bank bei Betrug – Gerichtspraxis
  https://www.hortmannlaw.com/articles/klage-gegen-die-bank-betrug

‍