Kripto Borsası için Cüzdan Taraması: İşlem-Öncesi vs İşlem-Sonrası

Bir kripto borsasında cüzdan tarama mimarisinde verilen en pahalı yanlış karar, tüm akışları "işlem-öncesi" (pre-trade) veya tüm akışları "işlem-sonrası" (post-trade) olarak tek bir bantta toplamaktır. Gerçek operatör pratiği hibrit: yatırımlar (deposit) için çoğunlukla post-trade, çekimler (withdrawal) için kesinlikle pre-trade. Bu makale bu ayrımın neden mantıklı olduğunu, hangi senaryoda hangi taramanın işe yaradığını, manuel review queue'sunun nasıl boyutlandırılacağını ve eşik politikanızın hangi bantları içermesi gerektiğini Türk operatörler için pratik düzeyde anlatıyor.

Tanımlar: pre-trade ve post-trade nedir?

Pre-trade (işlem-öncesi) tarama: Tarama transaction borsanın deposit address'ine onaylanmadan veya kullanıcıya bakiyesi credit edilmeden önce yapılır. Karar olumlu çıkmazsa fon kullanıcının bakiyesinde hiç görünmez.

Post-trade (işlem-sonrası) tarama: Tarama transaction onaylandıktan ve bakiye credit edildikten sonra çalışır. Karar olumlu çıkmazsa fon zaten kullanıcının kontrolünde — geri freeze etmek, çekimi engellemek veya hesap kısıtlama uygulamak operasyonel iş yükü.

Bu iki tanım yüzeyel olarak basit ama altında kritik bir tradeoff var: latans bütçesi vs risk penceresi.

İlk bakışta pre-trade tüm akışlar için "doğru" görünebilir. Ama gerçek mimaride iki kısıt vardır: (a) mempool taraması güvensizdir — bir transaction broadcast edilip henüz onaylanmamışken, sender değişebilir veya RBF (Replace-By-Fee) ile farklı bir transaction'a dönüşebilir, (b) deposit address sahipliği kullanıcıya aittir — pre-trade decline ettiğiniz fonu "geri göndermek" teknik olarak başka bir transaction maliyeti getirir. Bu iki gerçeklik post-trade tarafına meyletmeyi pratik kılar — deposit akışında.

Withdrawal akışında ise tablo tersine döner. Çekim talebi borsanın kontrolündedir; çekimi durdurmak veya iletmemek tek karar noktasıdır. Burada pre-trade neredeyse her zaman doğru cevap.

Hibrit mimari: yaygın operatör pratiği

Türkiye'deki ve uluslararası tier-1 ve tier-2 kripto borsalarda en yaygın gözlenen mimari şu:

DEPOSIT akışı:
  1. Mempool listener (opsiyonel) — broadcast'i takip et, henüz karar verme
  2. Block onayı geldiğinde post-trade screening çalıştır
  3. Düşük risk → bakiye anında credit
  4. Orta risk → bakiye credit, hesap üzerine "review pending" flag
  5. Yüksek risk → bakiye credit ama freeze, manuel review queue'ya gönder
  6. (24-72 saat sonra) Periyodik yeniden tarama — exposure değişti mi?

WITHDRAWAL akışı:
  1. Kullanıcı withdraw butonuna bastığında pre-trade screening
  2. Destination address normalize, cluster lookup
  3. Düşük risk → withdrawal onayla, broadcast
  4. Orta risk → manuel review (genelde 1-4 saat SLA)
  5. Yüksek risk → otomatik decline + STR (şüpheli işlem raporu) tetikle

Bu hibrit mimarinin rasyoneli: deposit tarafında riskli fon zaten gelmiş (mempool RBF ile geri çekilebilir ama kullanıcının bakiyesine yansıma çoğunlukla anlık beklentiye karşı pre-trade'in latans maliyeti haksız UX bedeli). Withdrawal tarafında riskli destination'a fon göndermenin maliyeti çok daha yüksek — bu regülatör bakışında "actively facilitated sanctions evasion" gibi yorumlanabilir, sadece "tainted funds accepted" değil.

Blockchain AML pillar rehberimizde bu mimari kararın altyapı katmanlarını detaylandırıyoruz.

Eşik politikası: pratik bir başlangıç tablosu

Hibrit mimaride uygulanacak eşik politikası iki tarafı ayrı ayrı modeller. Tier-2 bir borsa için makul başlangıç eşikleri:

Deposit eşikleri (post-trade)

Withdrawal eşikleri (pre-trade)

Withdrawal'da eşikler daha sıkıdır — riski "kabul etmek" yerine "aktif iletmek" anlamına geldiği için:

Travel Rule yükümlülüğü için: destination başka bir VASP ise FATF Travel Rule rehberimiz ve Travel Rule entegrasyonu makalemizdeki akış uygulanır — yatırımcı/alıcı bilgileri counterparty VASP'a aktarılır.

Bu tablolar bir başlangıç noktasıdır; her operatörün risk iştahına, yargı yetkisine ve müşteri tabanına göre kalibre edilmelidir.

Manuel review queue: nasıl boyutlandırılır?

Manuel review queue'su tarama mimarisinin "insan katmanı". Boyutlandırma pratik bir mühendislik problemi. Tipik benchmark'lar:

Tier-2 Türk borsası örneği (anonimleştirilmiş):

• Günlük 10.000 deposit
• ~0.02-0.04% (yani 2-4 deposit) yüksek risk sinyali tetikler
• Bu 2-4 vakanın ~80%'i mixer exposure'lı (2-3 hop), kalan ~20% sanctions/scam/darknet
• Günlük 6.000 withdrawal
• ~0.05-0.10% (yani 3-6 withdrawal) manuel review queue'ya düşer (withdrawal threshold'u sıkı olduğu için)

Toplam günlük queue: 5-10 vaka. Bir analist günde 20-40 vaka değerlendirebilir (her vaka için 15-20 dk ortalama). Yani 1 senior compliance analist yeterli — ama bu sadece "baseline" durum.

Volatil dönemlerde (büyük hack, regülatör eylemi, mixer kapanması) queue 5-10x büyüyebilir. SLA hedefiniz "queue'ya düşen her vaka 4 saat içinde değerlendirilir" gibi netse, kapasite tasarımınız zirve yükü kaldıracak şekilde olmalı — ya tam zamanlı 2-3 analist + ortak bir on-call, ya hibrit (1-2 in-house + bir provider'dan outsource backstop).

Bu kapasite hesabı false positive nasıl azaltılır makalemizde anlattığımız match-grouping ve eşik kalibrasyonu pratikleriyle birlikte çalışır — eşikler iyi kalibre edildiğinde manuel queue 30-50% düşebilir.

Eşik politikası versiyonlama ve audit log

Eşik politikanız zamanla değişir — yeni etiketler eklenir, regülatör güncellemeleri olur, false positive analizinden sonra band'lar gevşetilir veya sıkılaştırılır. Her tarama kararının hangi politika versiyonuyla verildiği audit log'da kaydedilmeli.

Minimum kayıt seti her tarama için:

• screening_id (immutable UUID)
• timestamp (UTC, milisaniye)
• flow_type (deposit / withdrawal)
• screening_mode (pre_trade / post_trade / periodic_rescreen)
• address (normalize edilmiş)
• cluster_id ve cluster_name
• risk_categories ve direct_match_flag
• exposure_percent ve exposure_breakdown
• hop_distance_min
• decision (auto_clear / manual_review / auto_decline / freeze)
• threshold_policy_version — hangi politika sürümü uygulandı
• analyst_id ve analyst_notes (manuel kararsa)
• travel_rule_message_id (withdrawal başka VASP'aysa)

Bu log'ların retention süresi Türkiye için 5549 sayılı Kanun gereği 8 yıl. Saklama formatı immutable append-only olmalı (S3 Object Lock, Azure Blob immutability policy, benzeri WORM konfigürasyonu).

Periyodik yeniden tarama: post-trade'in eklentisi

Post-trade mimarisinin önemli bir parçası: periyodik yeniden tarama. Bir kullanıcının bakiyesinde duran deposit'lerin kaynak cluster'ı zamanla risk profilini değiştirebilir — bir kümeye sonradan yaptırım gelir, bir cüzdan retroaktif olarak Lazarus atribüsyonu alır.

Pratik bir periyodik tarama akışı:

• Her aktif bakiyenin kaynak deposit'leri 24 saatte bir yeniden taranır (yüksek-değer hesaplar için 4 saatte bir tercih edilir)
• Bir cluster yeni bir riskli etikete bağlandığında, o cluster'dan gelmiş tüm deposit'ler işaretlenir
• İşaretlenen hesaplar üzerinde withdrawal hold uygulanır, manuel review'a düşer

Bu mekanizma "retroaktif risk" senaryolarına karşı borsayı korur — bir kullanıcı 3 ay önce temiz görünen bir yatırım yapmış olabilir, ama o yatırımın 2 hop önceki cüzdanı dün OFAC SDN'e eklenmiş olabilir.

Türkiye perspektifi: KVHS sonrası ne değişiyor?

KVHS (Kripto Varlık Hizmet Sağlayıcı) düzenlemesi yürürlüğe girdiğinde MASAK ve SPK'nın borsa operatörlerinden beklediği asgari tarama altyapısının olmasını beklediğimiz unsurlar:

1. Hibrit mimari uyumluluğu. OFAC + BM + AB + UK yaptırım listeleri tarama (deposit ve withdrawal), 8 risk kategorisinde on-chain risk skorlama, yazılı eşik politikası, manuel review SLA.
2. Audit log retention. 5549 sayılı Kanun kapsamında 8 yıl, immutable format.
3. STR (şüpheli işlem raporu) entegrasyonu. Auto-decline veya freeze kararı tetiklendiğinde 10 iş günü içinde MASAK'a elektronik raporlama.
4. Travel Rule kapasitesi. Withdrawal başka bir VASP'a gidiyorsa IVMS 101 standardında counterparty veri değişimi. Travel Rule entegrasyonu nasıl yapılır bunu detaylıca açıklıyor.
5. MLRO (Money Laundering Reporting Officer) veya Türkiye karşılığı uyum sorumlusu. Politikayı imzalayan, denetimde regülatör muhatabı isim.

Bu altyapıyı bugünden inşa eden operatörler KVHS yürürlüğünde kapısı kapanmayacak olanlar — geriye dönük inşa retrospective olarak zordur.

Sıkça Sorulan Sorular

Pre-trade tarama tüm deposit'lerde uygulanabilir mi?

Teknik olarak evet, ama pratik maliyeti yüksek. Mempool listener ile broadcast'i yakalarsınız, ama (a) bazı zincirlerde mempool gizli veya kısa-ömürlü (Solana, Ethereum L2'lerin bazıları), (b) RBF transaction'ları decision'ı geçersiz kılabilir, (c) latans bütçeniz onboarding UX'inizi etkiler. Yaygın pratik: yüksek-tutarlı deposit'ler için pre-trade ek katman (örn. >100k USD eşik üstünde), düşük-tutarlı deposit'ler için sadece post-trade. Bu hibrit-içi-hibrit yapı operasyonel olarak yönetilebilir.

Withdrawal manuel review SLA'sı ne olmalı?

Sektör pratiği: yüksek risk withdrawal'lar için 1-4 saat manuel SLA, orta risk için 4-24 saat. Daha uzun SLA müşteri şikâyeti üretir; daha kısa SLA queue boyutu için ek kapasite gerektirir. Türkiye'de KVHS yürürlüğe girdiğinde MASAK'ın spesifik SLA beklentisi olabilir — taslakta henüz açık değil. Pratik bir kararla 2-saat (yüksek) / 8-saat (orta) hedefleyip metrik takip etmek makul başlangıç.

Freeze edilen deposit'i ne kadar tutabilirim?

Türkiye 5549 sayılı Kanun ve MASAK rehberi kapsamında, STR raporlanan fonlar MASAK'tan blokaj kararı geldiğinde tutulur — kararsız durumda fonu kullanıcıya iade etmek tipik. Tutma süresi belirsizdir; sektör pratiği 7-30 gün arası MASAK yanıtı beklemek, sonra hesabın durumuna göre iade veya devam eden blokaj. Hukuk müşaviriniz veya MLRO'nuz vaka bazında karar vermeli. Sözleşmenizdeki kullanıcı şartlarının bu tür blokaj durumlarını açıkça öngörmesi savunulabilirliğinizi artırır.

Withdrawal Travel Rule data exchange'inde counterparty VASP yanıt vermezse ne olur?

Bu klasik "sunrise problem" — counterparty VASP henüz Travel Rule altyapısına sahip değil. Pratik yaklaşımlar: (a) eşik altı withdrawal'ları (örn. 1000 EUR/eşdeğeri altı) data exchange olmadan iletmek (FATF guidance bu eşiği destekler), (b) eşik üstü ama counterparty bilinmeyense hold + müşteri açıklama talep, (c) müşteriye alternatif çekim yöntemi sunma. Travel Rule sunrise problem makalemiz bu senaryoları detaylandırıyor.

Risk altyapısını in-house mu kursam, dışarıdan mı alsam?

10.000+ deposit/gün hacimde ve regülatör beklentilerinin sıkılaştığı bir ortamda in-house etiketleme veritabanı kurmak 12-18 ay mühendislik + 4-6 senior analist + sürekli güncelleme yatırımıdır. Çoğu tier-2 ve tier-3 borsa için ekonomik değil. Provider seçimi rasyonel — ama tek-provider'a tam bağımlılık riski. İki-provider mimarisi (primary + fallback, etiket-coverage gap'lerini ve API outage'ları absorbe eder) en yaygın pratik. Blockchain AML pillar rehberimiz provider seçim matrisini detaylandırıyor.

Legichain ile borsa cüzdan taraması

Legichain blockchain AML altyapısı hibrit mimari için tasarlandı: deposit tarafında post-trade ve periyodik yeniden tarama, withdrawal tarafında pre-trade ile düşük-latans karar motoru tek API çatısı altında. 12+ zincirde adres normalizasyonu, 8 risk kategorisinde sürekli güncellenen etiketler, yapılandırılabilir eşik politikası (versiyonlanır, audit log'a işlenir) ve manuel review queue arayüzü dahil. Türkiye'deki kripto borsa müşterileri için KVHS yürürlüğüne hazırlık aşamasında MASAK bilgi talebine destek veren Türkçe ekip mevcut; AB pazarına açılanlar için TFR/MiCA uyumlu Travel Rule entegrasyonu yan yana çalışır. Mevcut tarama altyapınız varsa Legichain primary olmadan secondary/fallback provider olarak da konuşlandırılabilir — pilotlar genelde 4-6 hafta içinde production'a alınır.

Sonraki adımlar

• Blockchain AML rehberimiz (pillar) — dört katmanlı mimari ve genel çerçeve
• Kripto cüzdan taraması nasıl yapılır — uçtan uca tarama akışı, kod ve kararlar
• Kripto borsa müşterileri için Legichain çözüm sayfası — borsa altyapı bileşenleri
• Kripto borsası için dijital KYC — onboarding akışı tasarımı
• Travel Rule entegrasyonu nasıl yapılır — withdrawal counterparty veri değişimi