Mule Hesap Tespiti

Para taşıyıcı (mule) hesap, suç geliri fonlarını alıp hızla yönlendiren hesaptır — sahibi ya devşirilmiştir ya da suç ortağıdır. Tespiti tek bir işlemden yapılamaz; fon akışının şekline bakmak gerekir.

Lunixi bunu iki bağımsız yoldan destekler:

Akış içinde desen tespiti — dağıtım, hunileme ve hızlı yönlendirme desenlerini sayım düğümleriyle yakalarsınız.
Hesap risk taraması — bir hesabın bilinen taşıyıcı etiketleri ve geçmiş ihbarları üzerinden skorlanması.

⚠️

Yanıtta muleDetection diye ayrı bir obje yoktur. Tespit sonucu standart karar yanıtına karışır: decision, score, reasonCodes, flowPath. Bkz. Karar API'si.

1. Akış içinde desen tespiti

Taşıyıcı hesapların üç imzası vardır ve üçü de hazır şablonla gelir:

Desen	Şablon	Nasıl ölçülür
Dağıtım (fan-out) — tek gönderen, gün içinde çok sayıda farklı alıcı	`jmlsg_mt_fanout_beneficiaries_daily`	`distinct-count-check` — benzersiz alıcı sayısı
Hunileme (funnel) — çok sayıda farklı gönderen, tek alıcı hesap	`jmlsg_mt_funnel_senders_daily`	`distinct-count-check` — benzersiz gönderen sayısı
Hızlı yönlendirme (pass-through) — gelen paranın dakikalar içinde çıkması	`jmlsg_mt_inter_arrival`	`inter-arrival-check` — giriş/çıkış arası süre

Bunlara ek olarak faydalı iki sinyal:

Uyku bozulması — uzun süre hareketsiz kalan hesabın aniden aktifleşmesi. history-aggregate-check ile geçmiş dönem ortalamasından sapma olarak yazılır.
Birikimli maruziyet — jmlsg_mt_cumulative_exposure_90d; tek tek eşiği aşmayan ama 90 günde toplamı aşan akış.

Şablonlar JMLSG neden kodu önekiyle gelir. Tetiklendiğinde yanıttaki reasonCodes üzerinden hangi tipolojinin çalıştığı doğrudan görünür — vaka açıldığında analistin işini kısaltır.

Örnek kurgu

distinct-count-check   →  1 günde 5+ farklı alıcı            (fan-out)
+ inter-arrival-check  →  gelen ile giden arası < 10 dakika  (pass-through)
+ history-aggregate    →  hesap son 30 gündür hareketsizdi   (uyku bozulması)
⇒ block + case-open

case-open düğümü aynı akış içinde vakayı açar; ayrı bir çağrı gerekmez.

2. Hesap risk taraması

Akıştan sanction-account-screen düğümüyle bir hesabı (IBAN veya hesap numarası) doğrudan tarayabilirsiniz. Hesap risk skoru şu bileşenlerden üretilir:

Bileşen	Katkı
Fraud ihbar sayısı	işlem başına +25, en fazla +80
Chargeback sayısı	işlem başına +10, en fazla +30
`mule_account` etiketi	+40
`fraud_payout` etiketi	+30
`masak_reported` etiketi	+50
Yaptırımlı hesap	skor doğrudan 100
Kara listeli hesap	skor en az 85

Skor 100'de tavanlanır ve şu bantlara ayrılır:

Bant	Skor
`sanctioned`	yaptırım eşleşmesi
`blacklisted`	kara liste eşleşmesi
`critical`	≥ 80
`high`	≥ 50
`medium`	≥ 25
`low`	< 25

Ne yapmadığımızı da söyleyelim

⚠️

Fraud tarafında canlı işlem grafiği üzerinden ağ yayılımı yoktur — yani "bilinen bir taşıyıcıdan para almış tüm hesapların riski otomatik yükselir" diye bir mekanizma çalışmıyor. Bağlantı analizi yaptırım tarafında, kimlik/varlık grafiği üzerinde ve dolaylı maruziyet hesabı olarak vardır (sanction-indirect-exposure düğümü).

Ağ yayılımı istiyorsanız bugün kurulabilir yolu şudur: taşıyıcı doğrulandığında hesabı mule_account etiketiyle işaretleyin; sonraki taramalar bu etiketi +40 olarak görür ve blacklist-lookup ile de yakalanır.

İlgili

İşlem İzleme — sayım düğümleri ve 53 şablonun tamamı
Akışlar ve Çözümleme — akışı hangi kapsamda yayınlayacağınız
Yaptırım Taraması — dolaylı maruziyet ve grafik analizi

Davranışsal Risk Sinyalleri İşlem İzleme