Bir POS cihazında kart geçtiğinde müşteri en fazla bir-iki saniye bekler. Bu sürenin içinde işlem; ağ, kart şeması, core banking ve fraud kontrolü dahil onlarca adımdan geçer. Fraud skorlama servisine düşen bütçe genellikle 100 milisaniyenin altındadır. Bu yazı o 100 ms'in nasıl harcandığını ve mimarinin nasıl kurulduğunu ele alıyor.
Gecikme bütçesi
Gerçek zamanlı fraud skorlamada tipik bir bütçe dağılımı:
- Ağ + deserialize: 10 ms
- Feature lookup (feature store): 20-30 ms
- Model inference: 20-40 ms
- Kural motoru + karar: 10 ms
- Logging + response: 10 ms
Toplam ~80 ms hedeflenir; p99'da 100 ms aşılmamalıdır. Bütçe aşımı işlemin senkron reddi yerine asenkron izlemeye düşmesine yol açar — bu da fraud yakalama oranını düşürür.
İki katmanlı karar: kural + model
Olgun bir fraud sistemi tek başına ML değildir:
- Kural motoru (deterministik): kara liste, ülke/limit kuralları, velocity (son 1 dakikada 5 işlem) gibi hızlı, açıklanabilir kontroller. Mikrosaniyeler.
- ML modeli (olasılıksal): gradient boosting (XGBoost/LightGBM) veya kompakt bir sinir ağı. Geçmiş davranıştan öğrenir, kuralların kaçırdığını yakalar.
Karar ikisinin birleşimidir: kural kesin-ret derse model çalışmaz; aksi halde model skoru eşikle birleştirilir.
Feature store: sıcak ve soğuk
Fraud modelinin ihtiyaç duyduğu özellikler iki hızda gelir:
- Sıcak (online): 'son 1 dakikadaki işlem sayısı', 'son 5 dakikadaki toplam tutar' gibi gerçek zamanlı sayaçlar. Redis veya benzeri düşük-gecikmeli store'da tutulur.
- Soğuk (offline): 'müşterinin 90 günlük ortalama harcaması', 'tipik işlem saati' gibi batch hesaplananlar. Günlük/saatlik beslenir.
Feast gibi feature store'lar bu iki katmanı tek tanımdan üretir; eğitim ve serving aynı feature mantığını kullanır (train-serve skew engellenir).
Stream omurgası
İşlem olayları Kafka (veya benzeri) üzerinden akar. Tipik akış:
- İşlem event'i Kafka topic'ine düşer.
- Stream processor (Flink/Kafka Streams) sıcak feature'ları günceller.
- Skorlama servisi senkron çağrıda online feature'ları okur, model çalıştırır, skor döner.
- Karar ve skor audit topic'ine yazılır; downstream raporlama ve model yeniden-eğitimi buradan beslenir.
Model güncel kalmalı
Fraud paternleri haftalar içinde değişir. Mimaride iki döngü olmalı:
- Online: skor anında döner.
- Offline: etiketli sonuçlar (chargeback, manuel inceleme) toplanır; model haftalık/aylık yeniden eğitilir; champion-challenger ile yeni model gölgede test edilir, başarılıysa terfi eder.
Açıklanabilirlik ve uyum
BDDK ve EU AI Act, fraud gibi yüksek-etkili kararlarda açıklanabilirlik ister. Her ret kararı için modelin en etkili 3-5 feature'ı (SHAP değerleriyle) kaydedilmelidir. 'İşlem normalden 8 kat yüksek tutarda ve alışılmadık ülkede' gibi bir gerekçe hem denetime hem müşteri itirazına cevap verir.
Tipik sonuç
Kural+model hibrit mimaride saha gözlemi: tek başına kural sistemine göre fraud yakalama %30-45 artarken, false-positive (gerçek müşterinin reddi) oranı doğru eşik kalibrasyonuyla %20-30 düşer. False-positive doğrudan müşteri memnuniyeti ve kayıp gelirdir; bu yüzden eşik kalibrasyonu en az model kadar önemlidir.
Sonuç
Gerçek zamanlı fraud skorlama bir model değil, bir gecikme bütçesi problemidir. 100 ms içinde feature lookup, model inference ve kural kararı sığmalı; model güncel kalmalı; her karar açıklanabilir olmalıdır. Doğru kurulduğunda hem fraud kaybı hem de yanlış-ret azalır.
