Blockchain AML ve Kripto Cüzdan Taraması Rehberi

Bir kripto borsasının uyum birimi sabah 09:00'da panele baktığında ne görmeli? Geçen gece gelen 4.200 yatırımdan dördünün mixer çıkışından üç hop uzakta olduğunu, ikisinin Lazarus Group atribüsyonlu bir kümeye değdiğini ve bir tanesinin OFAC SDN listesindeki adresle aynı cluster'a düştüğünü. Blockchain AML budur — adres listesi sorgulamanın çok ötesinde, gerçek zamanlı bir on-chain istihbarat katmanı. Bu rehber bir borsa, custody sağlayıcı veya kripto kabul eden bir ödeme kuruluşunun bu katmanı sıfırdan nasıl tasarlayacağını anlatıyor: hangi sinyaller gerçek anlamda risk taşıyor, cluster heuristikleri nasıl çalışıyor, hop-mesafesi analizi neyi söyler ve operatör ekiplerinin günlük iş akışını bozmadan nasıl entegre edilir.

Blockchain AML neden geleneksel AML'den farklı?

Geleneksel AML'de banka bir transferin "kimden kime" bilgisini SWIFT, IBAN veya benzeri bir merkezi sistemden alır. Yaptırım taraması statiktir: tarafların adı, kimliği ve ülkesi belli, listeye bakarsın. Kripto yatırımında ise üç temel farklılık var:

1. Pseudonymity. Adres bir kimliğe değil, bir kriptografik anahtar çiftine bağlı. Bir cüzdanın arkasında kim olduğunu blockchain söylemez. Bu kimliği inşa etmek için cluster heuristikleri ve etiketleme veritabanları kullanılır.

2. Tarihsel şeffaflık. Bir bankada müşterinin geçmiş yıllardaki transferlerinin %0.01'ini bile görmezsin. Bitcoin veya Ethereum'da her transfer 2009'a/2015'e kadar geriye dönük açıktır. Yatırım yapan bir cüzdanın 18 ay önce hangi mixer'a girdiğini, hangi darknet market satıcısından çıktığını bulabilirsin.

3. Programatik para. DeFi, atomic swap, cross-chain bridge ve flash loan akışları geleneksel ödeme akışlarının tasarlayamayacağı topolojiler yaratır. Bir cüzdan üç saniyede dört zincir, iki DEX ve bir bridge geçebilir.

Bu üç fark yüzünden blockchain AML, geleneksel AML taraması rehberimizde anlattığımız liste tabanlı yaklaşımın yerine değil üstüne kurulur. Liste taraması hâlâ var (OFAC SDN'inde 2022'den beri yüzlerce kripto adresi yayımlanıyor), ama esas iş cluster atribüsyonu ve davranışsal sinyaldedir.

Mimari: dört katman

Pratik bir blockchain AML mimarisi dört katmandan oluşur. Bu katmanları ya tek bir sağlayıcıdan alırsın ya da içeride parça parça kurarsın — çoğu borsa için ikincisi 12-18 aylık bir mühendislik yatırımıdır ve genelde ekonomik değildir.

Katman 1: Adres normalizasyonu ve cluster lookup

Her gelen adres önce normalize edilir: Bitcoin için checksum doğrulama, segwit/legacy/taproot formatlarının ortak bir gösterime çevrilmesi, EVM zincirlerinde EIP-55 checksum, Solana için base58 doğrulama. Sonra bir cluster lookup yapılır: bu adres bilinen bir kümeye ait mi? Eğer cluster ID dönerse — örneğin "Binance hot wallet 12", "Hydra Market satıcı kümesi", "OFAC SDN listesindeki Lazarus küme 3" — risk değerlendirmesi cluster düzeyinde yapılır.

Cluster heuristiklerinin iki temeli vardır:

• Common-input ownership: Bitcoin'de bir transaction birden çok input içeriyorsa, normalde aynı cüzdan/sahip imzalıyordur (Schnorr ve PayJoin gibi istisnaları unutma).
• Change-address detection: Output'lardan biri "kalan para" olarak geri dönüyorsa, o adres genellikle gönderen kümeye dahildir. Modern heuristikler change'i miktar, sıra, script tipi ve harcama davranışı kombinasyonundan tespit eder.

EVM zincirlerinde common-input geçerli değildir; bu yüzden EVM cluster'ları daha çok behavioral footprint, contract-deployer eşleşmesi ve cross-chain bridge giriş/çıkış eşleştirmesi üstüne kurulur.

Katman 2: Risk sinyali sınıflandırma

Cluster identify edildikten sonra, sisteme önceden eklenmiş risk etiketleri kontrol edilir. Endüstri standardında 8 ana kategori vardır:

1. Sanctions — OFAC SDN, BM, AB ve UK yaptırım listelerinde adı geçen veya bu listelerdekilere bağlı cüzdanlar
2. Mixer / tumbler — Tornado Cash (Ağustos 2022'de OFAC SDN'e eklendi), Wasabi/Samourai, ChipMixer (Mart 2023'te Almanya/ABD koordineli müdahale ile kapatıldı) ve benzeri privacy tool çıkışları
3. Darknet market — Hydra (Nisan 2022'de Alman makamlarınca kapatıldı), AlphaBay v2, Genesis Market, ASAP Market, vb.
4. Ransomware — Conti, LockBit, Hive, ALPHV/BlackCat, Cl0p ödeme adresleri ve bunların cash-out yapan kümeleri
5. Scam / fraud — Rug pull token sözleşmeleri, romance scam ortak adresleri, pig butchering depozit cüzdanları
6. Stolen funds — Hack çıkışları (Lazarus Group atribüsyonlu hareketler özellikle), exchange exploit tahsilatları
7. Gambling — Lisanssız kumar siteleri (lisanslı olanlar düşük-orta risk; ülke regülasyonuna göre filtrelenir)
8. Child exploitation material (CSAM) — Bilinen CSAM bağışı toplayan adresler; bu kategoride hop-distance ne olursa olsun otomatik decline tipiktir

Bu sinyallerin doğrudan eşleşme (direct match — yatırım yapan cüzdanın kendisi etiketli) ile indirect exposure (bir hop uzaklıkta veya daha uzak temas) arasındaki fark mimarinin kalbidir. Bunu sonraki katmanda işleyeceğiz.

Katman 3: Hop-mesafesi ve exposure analizi

Bir yatırım yapan cüzdan tek başına temiz görünebilir; ama 24 saat önce bir mixer'dan çıkmış ve iki hop sonra borsaya gelmiş olabilir. Sağlıklı bir sistem her gelen cüzdan için forward ve reverse hop trace yapar — genellikle 5-10 hop derinliğinde.

Pratik bir exposure aggregation kuralı:

Bu tablo bir başlangıç noktasıdır; her operatörün risk iştahına ve regülatör beklentilerine göre kalibre edilmelidir. Türkiye'de KVHS (Kripto Varlık Hizmet Sağlayıcı) düzenlemesi yürürlüğe girdiğinde MASAK bu eşiklere dair beklentilerini netleştirecek.

Exposure %'sini hesaplama: Eğer bir cüzdana gelen 10 ETH'in 0.4 ETH'i iki hop önce Tornado Cash çıkışıysa, exposure %4'tür. Pratik bir eşik: tek bir riskli kategoride %10'u aşan exposure → manuel review, %30'u aşan → otomatik decline. Bu yüzdeler değer-ağırlıklıdır, transaction sayısı değil.

Katman 4: Karar ve audit log

Son katman aslında en kritik olanıdır — regülatör soruşturmasında varlığını ispatlayan tek şey audit trail'in olgunluğudur. Her tarama kararı için kaydedilmesi gereken minimum alan seti:

• screening_id (immutable UUID)
• timestamp (UTC, milisaniye)
• address (normalize edilmiş)
• cluster_id ve cluster_name
• risk_categories (etiketler)
• direct_match_flag (bool)
• exposure_percent ve exposure_breakdown (kategori bazında)
• hop_distance_min (en yakın riskli temas)
• final_score (0-100)
• decision (auto_clear / manual_review / auto_decline)
• decision_threshold_version (eşik politikası sürümü)
• analyst_id (manuel kararsa)
• analyst_notes (manuel kararsa)
• data_provider_response_raw (sağlayıcı API'sinin yanıtı; hash ile bütünlük doğrulama)

Bu log'lar tarama anından itibaren 8-10 yıl saklanmalı (Türkiye 5549 sayılı Kanun kapsamında 8 yıl, AB MiCA ve AMLD6 yorumlarında 10 yıla kadar). Saklama formatı immutable append-only olmalı — S3 Object Lock, Azure Blob Storage immutability policy veya benzeri bir WORM (Write Once, Read Many) konfigürasyonu.

Pratik tarama akışı: bir yatırım nasıl işlenir?

Bir kullanıcı borsa hesabına 0.5 BTC yatırırken arka planda gerçek bir kripto borsasında olan şu:

1. Memberpool dinleyici zincire düşmemiş ama broadcast edilmiş işlemi yakalar. Henüz block onayı yok ama tarama başlar — bu işlem-öncesi (pre-trade) tarama.
2. Yatırım yapan adres normalize edilir, cluster lookup koşar (~50-150 ms).
3. Cluster bilinen bir borsadan geliyorsa (örn. başka bir tier-1 borsanın hot wallet'i) düşük risk olarak işaretlenir, kullanıcıya "yatırımın geliyor" bildirimi gider.
4. Cluster bilinmiyor veya etiketsiz ise, hop trace tetiklenir (5-10 hop derinliği, ~500 ms - 2 s arası).
5. Exposure hesaplanır, eşik politikası çalışır, karar dönülür.
6. Block onayları biriktikçe (6 onay BTC, 12-32 onay ETH) işlem-sonrası (post-trade) yeniden tarama koşar — bu önemli, çünkü bazen ilk tarama sonrası 1-2 hop derinlikteki bir adres yeni bir riskli etikete bağlanır ve cüzdan retroaktif olarak yüksek riske geçer.
7. Karar auto_clear ise yatırım kullanıcının bakiyesine geçer. manual_review ise yatırım onaya kadar tutulur (genelde 4-24 saat SLA). auto_decline ise para geri gönderilir veya regülatör direktifine göre tutulur ve STR (şüpheli işlem raporu) hazırlanır.

Bu akışın detayını ve uçtan uca implementasyon adımlarını kripto cüzdan taraması nasıl yapılır rehberinde işliyoruz.

Çıkış (withdrawal) tarafı: counterparty riski

Borsadan dışarı çekilen para da taranır — çünkü bir kullanıcı temiz para yatırıp, çekim yaparken bilinen bir scam toplama adresine, mixer'a veya yaptırımlı bir cüzdana gönderiyor olabilir. Çıkış taraması üç şey ekler:

1. Counterparty (alıcı) cluster taraması — yatırım tarafı ile aynı sinyaller, ters yönde.
2. Kullanıcı davranış profili — bu kullanıcı normalde ne tarz adreslere çekim yapıyor? Birden gelen yeni bir destination + yüksek tutar = atipik sinyali.
3. Travel Rule yükümlülüğü — alıcı başka bir borsa (VASP) ise, FATF Travel Rule kapsamında yatırımcı/alıcı bilgileri iletilmeli. FATF Travel Rule rehberimiz ve Travel Rule entegrasyonu nasıl yapılır makalemiz bu yükümlülüğün teknik detayını veriyor.

Çıkış tarafında yapılacak hata maliyeti yatırım tarafına göre daha yüksektir: regülatör için "yaptırımlı bir adrese para gönderdin" çok daha somut bir bulgudur "yaptırımlı kaynaklı parayı kabul ettin"den.

Cluster heuristik sınırları ve hataları

Cluster heuristikleri olasılıksaldır, kesin değil. Üç tipik hata kaynağı:

1. CoinJoin ve PayJoin yanlış kümeleme. Wasabi/Samourai gibi CoinJoin'ler birden çok kullanıcının fonlarını ortak bir transaction'da birleştirir; eski common-input heuristiği bu işlemleri tek bir kümeye sokar — yanlış. Modern sistemler CoinJoin imzasını tanır ve kümeyi parçalamaz.

2. Custodial vs non-custodial yanlış sınıflandırma. Bir borsanın hot wallet'i milyonlarca kullanıcıyı kapsar; o kümeyi "yüksek riskli" olarak işaretlemek ciddi yanlış olur. Tier-1 borsa kümeleri allow-list ile bilinçli ayrılır.

3. EVM contract sahipliği. Bir DeFi protokolünün havuz cüzdanı binlerce kullanıcıyı temsil eder; havuza giren yaptırımlı bir adres havuzun tamamını "yaptırım exposure'lı" yapmaz. Bu yüzden contract addresses için exposure hesaplama farklı kurallarla yapılır.

DEX ve DeFi AML zorlukları makalemiz bu son noktayı detaylandırıyor ve protokol seviyesinde AML'in neden hâlâ açık bir problem olduğunu anlatıyor.

Veri sağlayıcı seçimi: değerlendirme matrisi

Kendi etiketleme veritabanını sıfırdan kurmak mantıklı değil; sektörde 5-6 büyük data provider var. Seçim kriterleri:

• Etiket kapsama: Hangi zincirler, kaç kategori, etiketlenen cüzdan sayısı, son güncelleme tarihi.
• Etiket kalitesi: False positive oranı (kendi örnek setinizde test edin), kategori netliği (örn. "high risk" gibi gri etiket var mı?), atribüsyon kaynak gösterimi.
• API latansı ve uptime: Tarama akışınızın SLA'ı tipik olarak <500 ms p99 — sağlayıcı bunu garantileyebiliyor mu?
• Audit ve compliance kabulü: Sağlayıcının raporları regülatöre delil olarak sunulabilir mi? Sertifikasyon (SOC 2, ISO 27001) var mı?
• Türkçe destek ve veri yerleşimi: MASAK bilgi talepleri Türkçe karşılanabiliyor mu? Müşteri verisi AB/Türkiye'de mi tutuluyor?
• Fiyatlama modeli: Tarama-başına, MAU-bazlı, custom enterprise? Hacim arttıkça birim maliyet nasıl davranıyor?

Pratik bir öneri: bir sağlayıcıya tam bağımlılık riski yaratır. İki sağlayıcılı (primary + fallback) bir mimari hem latans hem etiket-kapsamaması açısından sağlamdır.

Sıkça Sorulan Sorular

Tornado Cash yaptırımı sonrası ne değişti?

ABD Hazine Bakanlığı OFAC, 8 Ağustos 2022'de Tornado Cash protokol kontratlarını ve ilişkili ETH/USDC adreslerini SDN listesine ekledi. Bu, ABD kişilerinin (ve geniş yorumla US-bağlantılı tüm finansal kuruluşların) Tornado Cash ile etkileşimini yasakladı. Pratikteki sonucu: hiçbir saygın borsa Tornado Cash çıkışlarını doğrudan kabul etmez, 1-2 hop exposure'ı bile manuel reviewa düşer. Eylül 2024'te bir ABD temyiz mahkemesi OFAC'ın akıllı sözleşmeleri "mülk" olarak yaptırıma alma yetkisini sorgulayan bir karar verdi, ancak Hazine listeyi geri çekmedi — etkin yaptırım statüsü devam ediyor. Operatörler için doğru yaklaşım Tornado Cash etiketini yüksek risk olarak işlemeye devam etmek.

Cluster heuristikleri yanlış sonuç verirse sorumluluk kimde?

Sağlayıcı sözleşmelerinde bu sorumluluk genelde operatöre bırakılır — "veriler 'as-is' sunulur". Pratikte regülatör de sizden cluster verisinin doğruluğunu değil, karar süreçlerinizin makullüğünü ister: hangi sinyallere bakıldı, hangi eşikler uygulandı, manuel review nasıl yapıldı. Cluster verisi yanlış olsa bile, due diligence süreci sağlamsa savunulabilir bir pozisyondasınız. Bu yüzden audit log'un kalitesi cluster verisinin kalitesinden daha kritik bir savunma katmanıdır.

Mixer çıkışı her zaman yasadışı mı?

Hayır. Privacy araçlarının meşru kullanımları vardır (gazeteci, aktivist, kurumsal cüzdanın işlem mahremiyeti). Ancak operatör bakış açısından mixer çıkışını ayrıştırmak teknik olarak imkânsız — meşru ile yasadışı kullanıcının fonu zaten karıştırılmış. Bu yüzden çoğu kuruluş risk-iştahı kararı olarak mixer çıkışını yüksek risk işaretler ve ya manuel review ya da decline uygular. CSAM ve sanctions kategorilerinde tartışma yok; mixer'da tartışma daha çok eşik politikasında.

Cross-chain bridge geçişi tarama akışını nasıl kırıyor?

Bir cüzdan ETH'ten BNB Chain'e bridge ettiğinde kaynak ve hedef adresler farklıdır; naif bir sistem geçmiş zinciri görmez. Sağlam bir bridge tracking için sağlayıcının (a) major bridge'lerin (Wormhole, LayerZero, Stargate, Across, vb.) wrapping transaction'larını tanıması, (b) source/destination eşleştirmesi yapması ve (c) bu eşleşmeyi cluster grafiğine düğüm olarak eklemesi gerekir. Bridge tracking olgunluğu sağlayıcı seçiminde en fazla farkı yaratan kriterlerden biridir.

Türk regülatörü blockchain AML için ne bekliyor?

KVHS düzenlemesi yürürlüğe girdiğinde MASAK'ın asgari beklentilerinin OFAC + BM yaptırım listeleri tarama, on-chain risk skorlama altyapısı, manuel review ekibi ve 8 yıllık denetim izi olacağı sektör görüşü. Pratik bir hazırlık: bugünden itibaren bu altyapıyı kuran kuruluşlar yürürlük tarihinde kapısı kapanmayanlar olacak. Detaylar için KVHS düzenlemesi açıklayıcımıza bakın.

Legichain ile blockchain AML

Legichain'in blockchain AML altyapısı bu rehberde anlattığımız dört katmanı tek bir API çatısı altında sunar: 12+ zincirde adres normalizasyonu ve cluster lookup, 8 risk kategorisinde sürekli güncellenen etiket veritabanı, yapılandırılabilir hop-mesafesi/exposure eşikleriyle karar motoru ve immutable audit log. Türkiye'deki operatörler için MASAK bilgi talebi destekli Türkçe ekip, AB/UK pazarına açılan kuruluşlar için TFR ve MiCA uyumlu Travel Rule entegrasyonu yan yana çalışır. Mevcut tarama altyapınızı korumak isteyenler için fallback/secondary provider olarak da konuşlandırılabilir — sözleşmeli pilot süreçleri 4-6 hafta içinde production'a alınıyor.

Sonraki adımlar

• Kripto cüzdan taraması nasıl yapılır: on-chain risk sinyalleri — uçtan uca tarama akışı, kod ve kararlar
• Mixer, tumbler ve darknet AML sinyalleri — privacy araçlarının teknik anatomi ve risk yorumu
• DEX ve DeFi AML çerçevesi — protokol-seviyesi ve front-end-seviyesi controls
• Kripto borsası cüzdan taraması: işlem-öncesi vs sonrası — borsa operatörleri için BOFU vakası
• Genel AML taraması rehberi — geleneksel AML temelleri