Kripto Cüzdan Taraması Nasıl Yapılır: On-Chain Risk Sinyalleri

Kripto cüzdan taraması, "adresi listede ara, varsa engelle" cümlesinden çok daha karmaşık. Gerçek bir borsanın gerçek bir kullanıcısının yatırdığı 0.5 BTC için arka planda yedi farklı adımı çalıştırmanız gerekir — normalizasyondan, cluster lookup'tan, hop-mesafesi analizinden, skor aggregation'dan ve nihai karara, sonra da audit log'a kadar. Bu rehber bu yedi adımı operasyon ekiplerinin doğrudan uygulayabileceği şekilde anlatıyor; her adımda gerçek hata kaynaklarını, ölçeklenebilirlik tuzaklarını ve makul SLA hedeflerini paylaşıyoruz.

Bu rehber blockchain AML pillar makalemizin operasyonel bir tamamlayıcısı; teorik çerçeveyi orada işledik, burada implementasyon adımları var.

1. Adım: Adres normalizasyonu

Bir tarama çağrısı yapmadan önce gelen adresin formatını doğrulayın ve normalize edin. Bu hem provider API'sine yanlış string göndermenin önüne geçer hem de aynı adresin farklı gösterimleri yüzünden cache miss yaşamanızı engeller.

Zincire özgü kurallar:

• Bitcoin: Bech32 (bc1...), Legacy P2PKH (1...), P2SH (3...) ve Bech32m taproot (bc1p...) formatları için checksum doğrula. Bech32 ve taproot için BIP-173/BIP-350 standardı, mixed-case girişi reddet.
• EVM (Ethereum, BNB Chain, Polygon, Arbitrum, Optimism, Base): 42 karakter, 0x öneki, EIP-55 checksum doğrulama. Lowercase girişler tehlikeli — bazı sistemler bunları geçerli sayar ama checksum yapısı zayıftır.
• Solana: 32-byte ed25519 public key, base58 encode. Curve point validation yap.
• TRON: Base58Check, "T" başlangıcı. Hex prefix farkı (0x41) sürpriz çıkarabilir.

Pratik uygulama: Provider API'sine yollamadan önce kendi normalize ettiğiniz adresi cache anahtarı yapın. Aynı kullanıcının aynı adresi tekrar yatırması durumunda 24 saatlik cache hit, hem provider maliyetini hem latansı çok ciddi düşürür.

2. Adım: Cluster lookup

Normalize edilmiş adresle data provider'a cluster sorgusu atın. Tek bir API çağrısı yeterli; tipik latans 50-150 ms.

Provider'dan beklenecek dönen yapı (örnek):

{
  "address": "bc1q...",
  "cluster_id": "cluster_a8f3b2",
  "cluster_name": "Binance hot wallet 14",
  "cluster_type": "exchange",
  "cluster_size": 4827193,
  "risk_categories": [],
  "direct_match": false,
  "last_updated": "2026-05-22T08:14:00Z"
}

cluster_type'ı (exchange, custody, mining_pool, defi_pool, mixer, darknet_market, unknown) erken oku — bu tek alan otomatik fast-path açmanı sağlar:

• exchange veya custody: Bilinen tier-1 borsa veya kurumsal custody → low risk, fast clear. Tier-2/3 borsalar için kendi allow-list'ini kullan; tüm "exchange"leri eşit kabul etme.
• mining_pool: Genelde temiz çıkış, ama pool çıkışları için ayrı kalibrasyon (bazı poollar mixer benzeri etki yapar).
• mixer veya darknet_market: Hop-mesafesi 0 → otomatik decline.
• unknown veya defi_pool: Sonraki adımlara geç.

3. Adım: Risk sinyali sınıflandırması

Provider yanıtında risk_categories boş değilse, doğrudan eşleşme (direct_match: true) var demektir. Bu durumda sekiz ana kategoriyi hiyerarşik olarak değerlendirin:

Birden çok kategori aynı anda gelirse en yüksek öncelikli karar uygulanır. Karar log'una tüm kategorileri yaz; sadece "en yüksek riskli" değil — denetim sırasında ne gördüğünüzü ispatlamanız gerekir.

4. Adım: Hop-mesafesi (hop trace)

Doğrudan eşleşme yoksa veya cluster unknown ise bu adım çalışır — gerçek işin yapıldığı yer. Cüzdana gelen fonların kaynak grafiğini (forward trace from origin) ve cüzdandan çıkan fonların ulaştığı yerleri (reverse trace from terminus) 5-10 hop derinliğinde tara.

Pratik bir yapılandırma:

• Depth: 5 hop deposit tarafı için minimum, 8-10 hop ileri analiz için. Daha derin gitmek sinyali sulandırır (sektörde "noise floor" denen olgu).
• Time horizon: 12 ay öncesine kadar — daha eskisi büyük çoğunlukla yanlış pozitif kaynağı.
• Min transaction value: Toz işlemleri (dust) ele — örn. 1 USD altı transfer'leri filtreden geç. Bu sistemli bir saldırı vektörü: kötü niyetli aktörler temiz cüzdana 0.01 USD "kirli" göndererek o cüzdanı boyamaya çalışır.

Provider yanıtı tipik olarak şu yapıyı döner:

{
  "exposure": [
    {
      "category": "mixer",
      "label": "Tornado Cash",
      "exposure_pct": 4.2,
      "exposure_value_usd": 421,
      "min_hop": 2,
      "transactions_count": 3,
      "first_seen": "2026-05-20T14:11:00Z"
    },
    {
      "category": "darknet_market",
      "label": "Hydra (historical)",
      "exposure_pct": 0.8,
      "exposure_value_usd": 80,
      "min_hop": 6,
      "transactions_count": 1,
      "first_seen": "2024-11-03T09:22:00Z"
    }
  ]
}

5. Adım: Skor aggregation

Yukarıdaki exposure verisini tek bir karar-ölçer skora çevirmeniz gerek. Basit ama sağlam bir formül:

score = Σ ( base_weight[category] × hop_decay(min_hop) × exposure_pct )

Tipik ağırlık tablosu:

hop_decay fonksiyonu olarak 1 / hop basit ve makul: 0 hop = 1.0, 1 hop = 0.5, 2 hop = 0.33, 3 hop = 0.25, 5 hop = 0.20. Daha gelişmiş kalibrasyonlarda exponential decay (e^(-k×hop)) kullanılır.

Yukarıdaki örnek için skor: (65 × 0.33 × 4.2) + (75 × 0.17 × 0.8) ≈ 90 + 10 = 100. Sınır vakaya yakın — ama eşik politikası buradan başlar.

6. Adım: Karar eşikleri

Toplam skoru üç gruba çevirin:

• 0-30: auto_clear — yatırım kabul, kullanıcıya hemen yansıt.
• 31-70: manual_review — yatırımı tut, analist kuyruğuna düşür. SLA: 4-24 saat (kuruluşa göre).
• 71-100: auto_decline — yatırımı reddet veya tut, regülatör direktifine uygun davran. STR hazırla.

Bu eşikler yazılı bir politika olmalı ve sürümlenmeli. Politika değişikliği geçmiş kararları değiştirmemeli — log'ta hangi decision_threshold_version'ın çalıştığı görünmeli. Regülatör soruşturması "neden bu karar verildi" sorusunu sorduğunda, o tarihteki politikayı gösterebilmeniz gerek.

Eşikler ayrıca müşteri risk profiline göre dinamik olabilir: kurumsal müşteriler için daha sıkı, retail için daha gevşek; yüksek-değerli işlemler için (örn. >$50k) eşik bandı daraltılır. Bu nüansları da politikada belge.

7. Adım: Karar uygulaması ve audit log

Karar dönüldükten sonra üç şey aynı anda olur:

1. Sistem aksiyonu — yatırım kullanıcıya geçer, kuyruğa düşer veya iade edilir.
2. Audit log yazımı — immutable append-only depoya. Blockchain AML pillar rehberimizde tam audit log şemasını verdik.
3. Bildirim — manuel review ise analyst takımına; auto_decline ise hem kullanıcıya hem compliance MLRO'suna.

Audit log'unun kritik özelliği immutable olması: yazıldıktan sonra silinemez veya değiştirilemez. S3 Object Lock, Azure Blob Storage immutability policy veya benzeri WORM (Write Once, Read Many) konfigürasyonu kullanın. Hash chain veya benzeri bütünlük doğrulaması ek savunma katmanı.

Saklama süresi: Türkiye 5549 sayılı Kanun çerçevesinde 8 yıl asgari; AB'de MiCA ve AMLD6 yorumlarında 10 yıla kadar.

Bonus: post-trade re-screen

İlk tarama (pre-trade) sadece o anki etiket veritabanını yansıtır. Provider 6 saat sonra yeni bir Lazarus Group cluster'ı yayınladığında, sabah temiz görünen yatırımcı cüzdanı yüksek riske geçebilir. Bu yüzden olgun sistemler post-trade re-screen çalıştırır:

• Block onaylama tamamlandığında (6 BTC, 12-32 ETH onayı) tekrar tara.
• 24 saat sonra üçüncü kez tara (provider'ın etiketleme gecikmesi için).
• Sonuç değişirse yeni karar uygula — gerekirse kullanıcı bakiyesini retroaktif olarak freeze et (kullanıcı sözleşmenizin bu yetkiyi vermesi şart).

Re-screen log'ları orijinal screening_id'nin altına re_screen_history[] olarak eklenmeli; aynı işlem için karar değişikliklerini bütüncül izleyebilirsiniz.

Yaygın hatalar ve nasıl önlenir

Hata 1: Provider yanıtını saklamamak. Pek çok ekip provider'dan dönen skoru log'a yazar, ham yanıtı atar. 6 ay sonra "şu adres için ne dönmüştü?" sorulduğunda provider farklı yanıt verir (etiketler güncellendi). Ham JSON'ı immutable depoya alın.

Hata 2: Karar eşiklerini kodun içine gömmek. Eşikler bir database tablosundan veya config dosyasından okunmalı, sürümlenmeli. Geliştirici değişikliği = audit trail bozulması.

Hata 3: Manuel review kuyruğunu izlememek. Manuel review oranı bir KPI: %5'in altındaysa eşikler çok gevşek, %25'in üstündeyse çok sıkı (analyst burnout). %10-15 sağlıklı bir bant.

Hata 4: Allow-list'i revize etmemek. Bilinen borsa cluster'ları zamanla değişir; tier-1 borsa exit-scam yaparsa (Mt. Gox, FTX) allow-list'iniz size yardımcı olmaz. Çeyreklik allow-list review zorunlu.

Sıkça Sorulan Sorular

Bir cüzdan tarama API çağrısı kaç saniye sürmeli?

Pre-trade kararı (cluster lookup + hızlı sinyal değerlendirme) için p99 < 500 ms makul. Full hop trace gereken durumda p99 < 2 saniye. Bunun üstüne çıkan provider'lar kullanıcı deneyimini bozar — yatırım yapan kullanıcı "ekran döndü" deneyimini yaşamamalı. Yüksek hacimli operatörler için provider'dan SLA committment iste; SOC 2 raporlarında bu açıklanır.

Cache stratejim ne olmalı?

Aynı adres için 24 saatlik in-memory + 7 günlük persistent cache makul başlangıç. Ama dikkat: bir cüzdanın etiketi her an değişebilir, cache TTL'i etiket-kategori'sine göre kalibre edin. Sanctions ve CSAM kategorileri için 1 saatlik TTL, exchange/custody için 7-30 günlük TTL.

Aynı kullanıcı farklı zincirlerden farklı cüzdanlarla yatırım yapıyorsa nasıl ilişkilendiririm?

Cross-chain bridge tracking + KYC tarafından gelen kullanıcı identity'si birlikte çalışır. Cüzdan-kullanıcı eşleşmesi sizin tarafınızda (deposit_address_assigned_to_user_id) yapılır; cross-chain cluster eşleşmesi provider tarafında. İki katmanı birleştirip "bu kullanıcının tüm-zincir risk profili" oluşturursunuz. Detay için DEX ve DeFi AML çerçevemize bakın.

Manuel review'da analyst neye bakmalı?

Asgari: (1) provider'ın ham yanıtı (etiket gerekçesi, kaynak atribüsyon), (2) hop trace grafiği görselleştirmesi, (3) müşterinin geçmiş tarama kararları (örneklem büyüklüğü), (4) kullanıcının KYC profili ve risk skoru, (5) işlem hacmi/büyüklüğü, (6) varsa müşteriden gelmiş "kaynak fonu açıklayan" ek belge talebi. Karar verdikten sonra notes alanı zorunlu — ne gördü, neden bu kararı verdi.

Bir false positive yaşandığında ne yapmalıyım?

İki şey: (a) o spesifik karar için provider'a feedback gönder — saygın provider'lar bunu cluster atribüsyonunu iyileştirmek için kullanır, (b) kendi local override'ını kaydet (allow-list'e ekle veya skor düşür) ve override'ı yetkili onayına bağla. Override'lar zamanla birikmemeli — çeyreklik review ile genel politikaya yansıtılır.

Legichain ile cüzdan taraması

Legichain blockchain AML API'si bu yedi adımı tek bir REST endpoint'inde sunar: POST /v1/wallet/screen çağrısı normalize-cluster-classify-hop trace-skor aggregation-karar yanıtını <500 ms p99'da döner. Eşik politikası dashboard'dan yönetilir, sürümlenir ve log'lara otomatik bağlanır; manuel review kuyruğu admin paneline gelir; immutable audit log standart AWS S3 Object Lock veya Azure WORM blob depoda tutulur. Türkiye operatörleri için MASAK bilgi taleplerine Türkçe yanıt verebilen compliance ekip yan masa.

Sonraki adımlar

• Blockchain AML rehberimiz (pillar) — mimari ve katmanların kavramsal çerçevesi
• Mixer ve darknet AML sinyalleri — bu adımlarda gördüğünüz etiketlerin teknik anatomisi
• Kripto borsa cüzdan taraması: işlem-öncesi vs sonrası — borsa-spesifik vaka