İşlem İzleme

İşlem izleme, tek bir işleme bakarak değil, bir öznenin zaman içindeki davranışına bakarak çalışır. Lunixi bunu beş sayım düğümüyle yapar; her biri bir soruya karşılık gelir:

Düğüm	Cevapladığı soru
`velocity-check`	Bu özne, şu pencerede kaç işlem / ne kadar hacim yaptı?
`event-count-check`	Şu olay, şu pencerede kaç kez oldu?
`distinct-count-check`	Kaç farklı alıcı / gönderen / IP / kart gördük?
`inter-arrival-check`	Ardışık iki işlem arasında ne kadar süre geçti?
`history-aggregate-check`	Geçmiş dönemin toplamı/ortalaması neydi, bugünkü ondan ne kadar sapıyor?

Bu düğümlerin gücü birlikte kullanıldığında ortaya çıkar. "Yapılandırma" (structuring) tek başına bir sayım değildir: eşik altı tutar + gün içinde çok sayıda işlem + kısa ara — üçünün birleşimidir.

Hazır kural şablonları

Fraud motoru 53 hazır kural şablonuyla gelir. Bunlar pazarlama listesi değil, düzenleyici metinlere eşlenmiş çalışır kurallardır; kendi eşiklerinizle uyarlayıp yayınlarsınız.

Şablon paketi	Şablon
TCMB 3.1.x	37
Hesap ele geçirme (ATO)	5
Havale / remittance	5
UK APP / PSR	6

JMLSG — para aklama tipolojileri

Şablon	Desen
`jmlsg_mt_structuring_daily_count`	Yapılandırma — gün içinde eşik altı çok sayıda işlem
`jmlsg_mt_funnel_senders_daily`	Hunileme — bir günde çok sayıda farklı gönderenden aynı hesaba giriş
`jmlsg_mt_fanout_beneficiaries_daily`	Dağıtım — bir günde çok sayıda farklı alıcıya çıkış (para taşıyıcı deseni)
`jmlsg_mt_inter_arrival`	Katmanlama — gelen paranın dakikalar içinde yönlendirilmesi
`jmlsg_mt_cumulative_exposure_90d`	Birikimli maruziyet — 90 günlük toplamın eşiği aşması

TCMB Risk Yönetimi Rehberi

Bölüm	Kapsam	Örnek şablonlar
3.1.1	Müşteri ve IP hız kontrolleri	`tcmb_3_1_1_1_txn_out_daily`, `tcmb_3_1_1_2_distinct_payees_daily`, `tcmb_3_1_1_8b_ip_distinct_accounts_daily`, `tcmb_3_1_1_13_risky_country_ip`
3.1.2	İşyeri risk göstergeleri	`tcmb_3_1_2_1_own_turnover_4x`, `tcmb_3_1_2_4_night_ratio_monthly`, `tcmb_3_1_2_5_flat_ratio_monthly`, `tcmb_3_1_2_iban_change_3_in_90d`, `tcmb_3_1_2_domain_age_lt_90`
3.1.3	Fatura ödeme ve havale	`tcmb_3_1_3_1a_bill_payment_customer_monthly`, `tcmb_3_1_3_6_remittance_inter_arrival`, `tcmb_3_1_3_9_related_party_self_funding`
3.1.4	GSM/telefon tabanlı desenler	`tcmb_3_1_4_ghs_a_phone_txn_1h`, `tcmb_3_1_4_ghs_b_phone_multi_merchant_1h`

Her şablon kendi neden kodu önekini taşır (JMLSG, TCMB), böylece tetiklenen kural yanıttaki reasonCodes üzerinden doğrudan düzenleyici maddeye izlenebilir.

Tipolojiler nasıl kurulur

Yapılandırma (structuring / smurfing)

Eşik altı tutarların bölünerek gönderilmesi.

event-count-check   →  gün içinde N+ işlem
+ rule              →  her biri eşiğin altında
+ inter-arrival     →  aralarında kısa süre
⇒ review

Hunileme (funnel)

Çok sayıda farklı gönderenden tek hesaba toplama. distinct-count-check ile gönderen sayısı, history-aggregate-check ile bu sayının müşterinin normalinden sapması ölçülür.

Dağıtım (fan-out)

Tek hesaptan çok sayıda farklı alıcıya çıkış — para taşıyıcı ağlarının klasik deseni. Bkz. Mule Hesap Tespiti.

Katmanlama (layering)

Gelen paranın kısa sürede yönlendirilmesi. inter-arrival-check giriş ile çıkış arasındaki süreyi ölçer; payment-lookup önceki işlemi getirir.

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

⚠️

Fraud motorunda eğitilmiş ML desen modeli yoktur ve fraud tarafında grafik veritabanı üzerinde işlem ağı analizi çalışmaz. Yukarıdaki tipolojilerin hepsi sayım düğümleri ve kurallarla, deterministik olarak kurulur.

Grafik analizi yaptırım tarafında vardır ve farklı bir işi yapar: kimlik/varlık ilişki grafiği üzerinden dolaylı maruziyet hesaplar. Akıştan sanction-indirect-exposure düğümüyle çağrılır. Bkz. Yaptırım Taraması.
İşlem izleme sonucu ayrı bir transactionMonitoring objesi olarak dönmez. Sonuç, standart karar yanıtına karışır: decision, score, reasonCodes, flowPath. Alan sözleşmesi: Karar API'si.

İlgili

Akışlar ve Çözümleme — şablonları hangi kapsamda yayınlayacağınız
Mule Hesap Tespiti — dağıtım ve hunileme desenlerinin derinleştirilmiş hâli
Karar API'si — sayım düğümlerinin okuduğu alanlar

Mule Hesap Tespiti Vaka Yönetimi