Kripto Borsası Siber Saldırılarında Müşteri Varlıklarının İadesi Taleplerinde Uygulamada Gördüğümüz Kritik Nokta: Saklama Yükümlülüğünün "Teknik İmkânsızlık" Savunmasıyla Aşınması

Son dönemde büromuza gelen dosyalarda ortak bir örüntü dikkatimizi çekiyor: kripto varlık hizmet sağlayıcısına yönelik bir siber saldırı iddiasının ardından müşteriler, platformdaki bakiyelerinin iade edilmediğini, hesaplarına erişimin kısıtlandığını veya zararın "kullanıcı hatası" ya da "protokol kaynaklı" gerekçelerle reddedildiğini görüyor. Bu dosyalarda hukuki tartışma çoğu zaman tüketici hukuku ekseninde açılıyor; oysa uygulamada asıl kırılma noktası, hizmet sağlayıcının saklama yükümlülüğünü ne ölçüde yerine getirdiği ve saldırı sonrası ortaya çıkan teknik anlatının hukuki sorumluluğu nasıl dönüştürdüğüdür. Bu yazıda, dosyalarda tekrar tekrar karşılaştığımız bu kritik noktayı, somut süreç adımları ve tipik hata örüntüleri üzerinden ele alıyoruz.

Saldırı Sonrası İlk 72 Saatte Kurulan "Teknik Anlatı" ve Hukuki Sonucu

Uygulamada gördüğümüz en belirgin örüntü, saldırının kamuoyuna duyurulması ile müşteriye yapılan bireysel bildirimin farklı zamanlarda ve farklı içeriklerle gerçekleşmesi. Hizmet sağlayıcı önce kısa bir duyuruyla "sistem bakımı" veya "olağan dışı hareketlilik" ifadesini kullanıyor; ardından günler içinde teknik bir rapor paylaşıyor ve zararın kapsamını daraltan bir çerçeve çiziyor. Bu çerçevede en sık karşılaştığımız ifadeler şunlar:

  • Zararın "üçüncü kişilerin hukuka aykırı fiilinden" kaynaklandığı ve şirketin kusurunun bulunmadığı,
  • Saldırının "protokol düzeyinde" gerçekleştiği ve saklama altyapısının bunu önleyemeyeceği,
  • Etkilenen bakiyelerin "teknik olarak geri alınamaz" durumda olduğu,
  • Kullanıcının cihaz güvenliğini veya şifresini korumadığı yönünde genel bir ima.

Bu anlatının hukuki işlevi, sorumluluğun sözleşmesel çerçevede "mücbir sebep" veya "kullanıcı kusuru" başlıklarına kaydırılması. Ancak dosyalarda gördüğümüz kritik nokta şu: teknik raporun kendisi çoğu zaman bağımsız bir denetime elverişli değil; olayın ne zaman tespit edildiği, hangi müdahalenin ne zaman yapıldığı ve müşteri varlıklarının hangi cüzdanlarda tutulduğu bilgisi parça parça veriliyor. İade talebinin kaderi, büyük ölçüde bu bilgi asimetrisi içinde belirleniyor.

Saklama Yükümlülüğünün Kapsamı: "Hesapta Görünen Bakiye" ile "Fiilen Saklanan Varlık" Arasındaki Fark

Müşteri dosyalarında en sık yaptığımız tespit, platformun müşteri varlıklarını kendi cüzdanlarında mı yoksa emanet (custodial) yapıda mı tuttuğunun sözleşmede ve kullanım koşullarında yeterince açık olmaması. Uygulamada bu belirsizlik, iade talebinin hukuki niteliğini doğrudan etkiliyor:

  • Emanet saklama ilişkisi varsa, müşterinin varlığı şirketin malvarlığından ayrı bir havuzda tutulmalı; saldırı sonrası bu havuzun durumu, ayrıştırılabilirliği ve varsa sigorta/rezerv mekanizması incelenmeli.
  • Kullanıcı adına tutulan ama şirket altyapısında yönetilen cüzdan yapısında ise, özel anahtarların kimde olduğu ve çoklu imza düzeninin nasıl işlediği sorumluluğun yönünü değiştiriyor.
  • Kaldıraçlı işlem veya emanet dışı yapı iddiası varsa, müşteri bakiyesinin hukuken "alacak" mı yoksa "eşya" mı olduğu tartışması iade talebinin tabi olacağı usulü belirliyor.

Dosyalarda gördüğümüz tipik hata, müvekkilin yalnızca ekran görüntüsü ve işlem geçmişiyle başvurması, buna karşılık platformun saklama yapısına ilişkin sözleşmesel ve teknik belgelerin talep edilmemesi. Oysa iade talebinin temellendirilmesinde ilk adım, varlığın hukuki niteliğini ve saklama rejimini netleştirmek olmalı.

İade Talebinde Usul: Tüketici Merciine mi, Ticari Dava Yoluna mı?

Uygulamada en çok zaman kaybettiğimiz noktalardan biri, başvurunun yanlış mercide açılması. Kripto varlık alım satımı çoğu dosyada tüketici işlemi olarak nitelendiriliyor ve tüketici hakem heyeti yolu deneniyor. Ancak saldırı sonrası iade talebi, salt bir ayıplı hizmet uyuşmazlığı değil; saklama yükümlülüğünün ihlali, vekâlet benzeri ilişkinin gereği gibi ifa edilmemesi ve zararın tazmini boyutlarını da içeriyor. Bu nedenle:

  • Talep, yalnızca "hizmet bedeli iadesi" olarak kurgulandığında maddi sınırlar ve görev kuralları dosyayı daraltıyor;
  • Zararın tazmini ve varlığın aynen iadesi talepleri birlikte ileri sürülmediğinde, sonradan bu taleplerin eklenmesi usul tartışmasına yol açıyor;
  • Şirketin tacir olması ve işlemin ticari iş niteliği taşıması hâlinde, ticari dava yolu ve arabuluculuk dava şartı gündeme geliyor; bu ayrımın baştan doğru yapılmaması süreyi ve masrafı artırıyor.

Büromuzda bu tür dosyalarda izlediğimiz yöntem, önce sözleşmesel ilişkinin niteliğini ve tarafların tacir sıfatını netleştirmek, ardından talebi tek bir merciye sıkıştırmadan, asli ve fer'i talepleri birlikte kurgulamak. Aksi hâlde dosya, görevsizlik veya husumet tartışmasıyla aylarca yerinde sayabiliyor.

Bloke Edilen Stablecoin Bakiyelerinde Hak Sahipliği Sorunu

Siber saldırı sonrası stablecoin bakiyelerinin bloke edildiği durumlarda ayrı bir kritik nokta ortaya çıkıyor: bloke kararının kim tarafından, hangi gerekçeyle ve hangi hukuki dayanakla alındığı müşteriye açıkça bildirilmiyor. Uygulamada gördüğümüz örüntüde platform, "risk kontrolü" veya "ihraççı talimatı" gibi genel ifadelerle bakiyeyi donduruyor; müşteri ise ne kadar süreyle ve hangi koşulda çözüleceğini bilmiyor. Bu tabloda iade talebi, yalnızca platforma karşı değil, bloke kararının kaynağına göre farklı hukuki zeminde ele alınmalı:

  • Bloke, platformun kendi iç risk prosedüründen kaynaklanıyorsa, orantılılık ve ölçülülük değerlendirmesi öne çıkıyor;
  • Bloke, üçüncü bir aktörün talimatına dayanıyorsa, müşterinin bu aktöre karşı başvuru yolu ve bilgi edinme hakkı ayrıca tartışılmalı;
  • Bloke süresince müşterinin zararı artıyorsa (örneğin piyasa hareketi nedeniyle), zararın kapsamı ve faiz talebi dosyaya eklenmeli.

Bu noktada sık yapılan hata, bloke kararının gerekçesinin yazılı olarak talep edilmemesi ve yalnızca çağrı merkezi yazışmalarıyla yetinilmesi. Oysa iade talebinin hukuki temellendirilmesi ve olası icra takibi riskinin yönetilmesi için yazılı gerekçe kritik önemde.

İcra Takibi ve Teminat Riski: İade Talebinin Ters Yönde Kullanılması

Dosyalarda dikkatimizi çeken bir başka pratik risk, platformun müşteriye karşı "hesap borcu" veya "işlem zararı" gerekçesiyle takip başlatma veya teminat talebiyle karşı karşıya bırakma ihtimali. Saldırı sonrası bakiyelerin negatife düşmesi veya işlemlerin iptal edilmesi hâlinde, müşterinin iade talebi ile platformun alacak iddiası aynı dosyada karşı karşıya gelebiliyor. Bu nedenle iade talebini ileri sürerken:

  • Hesap ekstresi ve işlem kayıtlarının tamamının yazılı olarak istenmesi,
  • Takas ve mahsup iddialarına karşı ihtirazi kayıt konulması,
  • Olası takibe karşı itiraz süresinin kaçırılmaması,
  • Varlıkların aynen iadesi mümkün değilse bedel talebinin hangi tarih ve kur üzerinden hesaplanacağının baştan belirlenmesi

gerekiyor. Uygulamada bu adımların atlanması, sonradan ciddi bir usul ve ispat dezavantajı yaratıyor.

Sonuç: İade Talebini "Tek Bir Dilekçe" Olarak Değil, Bir Dosya Stratejisi Olarak Kurmak

Büromuzda bu tür dosyalarda edindiğimiz deneyim şunu gösteriyor: kripto borsası siber saldırılarında müşteri varlıklarının iadesi talebi, tek bir başvuruyla çözülecek bir mesele değil. İlk adım, saklama yapısının ve varlığın hukuki niteliğinin netleştirilmesi; ikinci adım, saldırı sonrası teknik anlatının yazılı ve denetlenebilir biçimde talep edilmesi; üçüncü adım ise doğru merci, doğru talep kurgusu ve takip riskine karşı hazırlıklı olmak. Müvekkillerimize bu süreçte, mevzuat çerçevesinde hukuki haklarını koruyacak şekilde rehberlik ediyoruz; ancak her dosyanın kendi sözleşmesel ve teknik gerçekliğiyle değerlendirilmesi gerektiğini özellikle vurguluyoruz. Zira iade talebinin sonucu, büyük ölçüde başlangıçta atılan bu üç adımın ne kadar sağlam kurulduğuna bağlı.